ANALISIS Y DISEÑO ESTRUCTURADO DE SISTEMAS

ING. NEHEMIAS ISRAEL VALLE PINEDA

 CONCEPTOS
• Dato
• Concepto aislado
• Ítem de datos
• Es la pieza elemental de información, que define un atributo dentro de una entidad
y posteriormente de una tabla.
• Puede tener su propio dominio mediante una restricción.
• Puede tener asignado un dominio global tipo objeto.
• Información
• Conceptos relacionados
• Requerimiento
• Funcional y no funcional
• Registro o tupla
• Información coherente agrupada en una estructura de datos
• Tabla
• Contenedores de Información estructurada en registros o tuplas,
• Proceso
• Función dentro de un sistema, esta compuesto de entrada, proceso y salida.
• Sistema
• Conjunto de procesos estructurados para lograr objetivos en común
 CONCEPTOS
• Reglas del Negocio
• Se Convertiran en relaciones o dominios
• Items de Datos
• Se convertirán en atributos de Entidades
• Dominios
• Son los valores que puede tomar un dato o variable.
• Conjunto de valores bajo una misma restricción
• Entidades
• Pueden ser contenedores de datos que se convertirán en las Tablas o organizaciones.
• Atributos
• Tipos de variables
• Identificador de Entidad
• Atributos que identifican una Entidad. Llave primaria.
• Relación
• Ley de asociación entre dos dominios
 Regla de Negocio

Expresión escrita de como opera el negocio.

Reglas de Negocio
Definiciones
• Un autor es identificado por un nombre y una dirección.
• El monto de Regalías es un porcentaje de las ventas e incrementa de
acuerdo a el monto de las ventas.
• El porcentaje de regalías pagado a todos los autores de un libro
debe sumar el 100% de las regalías..
• El modelo debe ser diseñado para que el monto de regalías no debe
exceder del 10% de las ventas.
• La fecha de inicio de las ventas debe ser inferior a la fecha final del
proceso de publicación.
https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
https://es.wikipedia.org/wiki/Rational_Software
https://es.wikipedia.org/wiki/Rational_Software
https://es.wikipedia.org/wiki/Rational_Software
Ciclo de vida RUP
Mapa origen, propiedad y producto
Mapa relación a UML
Mapa Principios de desarrollo
Mapa Relación de nivel de abstracción
Objetivos

• Mejorar sus habilidades de estimación y planeación.

• Hacer compromisos que se puedan cumplir.
• Administrar la calidad de sus procesos.
• Reducir la cantidad de defectos en sus productos.
PSP Personal Software Process

• El proceso personal de software, PSP, es un conjunto de prácticas

disciplinadas para la gestión del tiempo y mejora de la productividad
personal de los programadores o ingenieros de software, en tareas
de desarrollo y mantenimiento de sistemas, mediante el seguimiento
del desempeño predicho frente al desempeño real. Está alineado y
diseñado para emplearse en organizaciones con modelos de procesos
CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y
estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del
libro "An introduction to the Personal Software Process" se dirige
ahora a ingenieros juniors.
• Con PSP los ingenieros de software pueden adquirir las habilidades
necesarias para trabajar en un proceso de software en equipo TSP.

https://es.wikipedia.org/wiki/Personal_Software_Process
PSP Personal Software Process

• Se puede considerar como la guía de trabajo personal para ingenieros

de software en organizaciones que emplean un modelo CMMI con
nivel de madurez o de capacidad de procesos que implica la medición
cualitativa y mejora de procesos.
• Uno de los mayores problemas que tiene es la gran cantidad de datos
que hay que tomar. El PSP tiene obsesión por la toma de datos y
elaboración de tablas. El PSP se orienta el conjunto de áreas clave del
proceso que debe manejar un desarrollador cuando trabaja de forma
individual.

https://es.wikipedia.org/wiki/Personal_Software_Process
Niveles

• PSP0, PSP0.1 (Introduce la disciplina y la medición al proceso)

• PSP1, PSP1.1 (Introduce estimación y planeación)
• PSP2, PSP2.1 (Introduce manejo de calidad y diseño)
PSP0, PSP0.1 (Introduce la disciplina y la
medición al proceso)
PSP1, PSP1.1 (Introduce estimación y
planeación)
PSP2, PSP2.1 (Introduce manejo de calidad y
diseño)
Detalle de niveles

• PSP 0:
• Proceso actual.
• Registro de tiempos.
• Registro de defectos.
• PSP 0.1 :
• Estándares de código.
• Medición de tamaño.
• PSP 1 - Inicial:
• Estimación de tamaño.
• Reporte de pruebas.
• PSP 1.1:
• Calendario de planeación de tareas.
• PSP 2 - Repetible:
• Revisión de diseño y código.
• PSP 2.1:
• Plantillas de Diseño.
• (TSP).
TSP Team Software Process

• Ir a la búsqueda En combinación con el Personal Software Process (PSP), el

llamado Team Software Process (TSP) proporciona un marco de trabajo de
procesos definidos que está diseñado para ayudarle a equipos de gerentes e
ingenieros a organizar y producir proyectos de software de gran escala, que
tengan tamaños mayores a varios miles de líneas de código. El objetivo del
TSP es mejorar los niveles de calidad y productividad de un proyecto de
desarrollo de software de un equipo, con el fin de ayudarlos a alcanzar los
acuerdos de costos y tiempos en dicho desarrollo.
• La versión inicial del TSP fue desarrollada por Watts Humphrey en 1996, y el
primer Reporte Técnico para TSP fue publicado en el año 2000, patrocinado
por el Departamento de Defensa de los Estados Unidos. El libro de Watts
Humphrey llamado "Introduction to the Team Software Process" (Addison
Wesley Professional, Massachusetts, 1999), presenta el TSP en detalle y se
enfoca en el proceso de la construcción de un equipo productor de software,
estableciendo objetivos del equipo, distribuyendo los roles, y otras
actividades de trabajo en equipo.

https://es.wikipedia.org/wiki/Team_Software_Process
CMMI Capability Maturity Model Integration

• Ir a la búsqueda Integración de sistemas modelos de madurez de

capacidades o Capability Maturity Model Integration (CMMI) es un
modelo para la mejora y evaluación de procesos para el desarrollo,
mantenimiento y operación de sistemas de software. Administrado
por el Instituto CMMI, una subsidiaria de ISACA, se desarrolló en la
Universidad Carnegie Mellon (CMU). Es requerido por muchos
contratos del Departamento de Defensa de los Estados Unidos (DoD)
y del Gobierno de los Estados Unidos, especialmente en el desarrollo
de software. CMU pretende que CMMI pueda ser usado para guiar la
mejora de procesos en un proyecto, división o una organización
completa. CMMI define los siguientes niveles de madurez para los
procesos: Inicial, Repetible, Definido, Gestionado y Optimizado. La
versión 2.0 se publicó en 2018 (la versión 1.3 se publicó en 2010 y es
el modelo de referencia para la información restante en este artículo
de wiki). CMMI está registrada en la Oficina de Patentes y Marcas de
Estados Unidos por CMU.

https://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration
Niveles CMMI
MODELOS DE DESARROLLO

• PROTOTIPOS
• CICLO DE VIDA
• INCREMENTAL
• EN ESPIRAL
• CONCURRENTES
• EN COMPONENTES
• DRA (DESARROLLO RAPIDO DE APLICACIONES)
• METODOLOGIAS AGILES
PROTOTIPOS

ARMAR
PROTOTIPO
ENTREVISTA
NO HAY
ANALISIS
DISEÑO
NI DOCMENTACION

OPERAR NO ESTRUCTURADO
PROTOTIPO CRECE SIN ORDEN
CICLO DE VIDA
ANALISIS
PRELIMINAR

ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

MANTENIMIENTO
 CICLO DE VIDA

ANALISIS DE DISEÑO BASE DE CONSTRUCCION

DATOS DATOS BD
PRUEBAS
ANALISIS
ASEGURAMIEN
PRELIMINAR
TO DE CALIDAD
ANALISIS DE DISEÑO DE CONSTRUCCION
PROCESOS PROCESOS PROCESOS

IMPLEMENTACI
MANTENIMIENTO
ON
INCREMENTAL
ANALISIS
FASE IV
PRELIMINAR

ANALISIS

DISEÑO

FASE III
CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

ANALISIS
MANTENIMIENTO
PRELIMINAR

ANALISIS

FASE II DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD
ANALISIS
PRELIMINAR IMPLEMENTACION

MANTENIMIENTO

FASE I ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
ANALISIS DE CALIDAD
PRELIMINAR
IMPLEMENTACION

MANTENIMIENTO

ANALISIS

DISEÑO

CONSTRUCCION

ASEGURAMIENTO
DE CALIDAD

IMPLEMENTACION

MANTENIMIENTO
 INCREMENTAL

IV PARA CUANDO A D
LA DOTACION
DE PERSONA
ES
III INSUFICIENTE A D C P I

II
A D C P I

I A D C P I

T
Evolución por prototipos
Proceso Evolutivo
Framework de Zachman

• El Marco de Trabajo Zachman es un marco de trabajo (framework)

de Arquitecturas empresariales creado por John A. Zachman en 1984
y publicado por primera vez en el IBM Systems Journal en 1987. Es
uno de los marcos de trabajo más antiguos y de mayor difusión en la
actualidad.
Marco de Trabajo Zachman - Wikipedia, la enciclopedia libre

• Ver videos
https://www.youtube.com/watch?v=qVEf16fVHX0

https://www.youtube.com/watch?v=5CI3dj2WvN4
Que es un
Framework?

https://www.youtube.com/watch?v=qVEf16fVHX0
Framework de Zachman

https://www.youtube.com/watch?v=qVEf16fVHX0
Que es un
Framework?

https://www.youtube.com/watch?v=qVEf16fVHX0
Principios

https://www.youtube.com/watch?v=qVEf16fVHX0
 Marco de la arquitectura empresarial de
Zachman QUESTIONES COMPONENTES
PERSPECTIVAS

https://www.youtube.com/watch?v=5CI3dj2WvN4
Pilares
• Ciclo de vida incremental
• Reuniones a lo largo del
proyecto
Herramientas
• Sprint
• Producto Back Log
• Sprint Back log
• Tablero de gestion
Metodologías
Agiles

El Manifiesto
Agil
 Historias de usuario

El objetivo es convertir las

necesidades de negocio del
cliente o usuario en historias
de usuario lo suficientemente
sencillas como para que se
puedan transformar
posteriormente en tareas de
desarrollo para el equipo.
Información de la historia de usuario
Product
Owner
Pila de producto
Sprint Log
Roles
Equipo de
trabajo
XP eXtreme
Programming
 Planning Game

Entregas pequeñas
XP
Buenas Metáfora (idea conceptual)
prácticas
Clientes On-Site

Programación Estándar
 Ciclo de vida XP

• Ciclo de vida iterativo

incremental
• Una primera versión
rápida
• Versiones sucesivas
• Aceptación de cambios
constantes
• Tiempo de retiro
Lean

• Eliminar desperdicios (Eliminating Waste).

• Amplificar el aprendizaje (Amplifying Learning).
• Decidir lo más tarde posible (Deciding as Late as Possible
• Entregar lo más rápido posible (Delivering as Fast as
Possible).
• Capacitar y potenciar al equipo (Empowering the Team).
• Construir con calidad (Building Quality In).
• Ver el todo (Seeing the Whole).