ANÁLISIS Y DISEÑO DE

SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS

Virginia Montilla
Objetivo General Análisis y Diseño de
Sistemas

• Entender los procedimientos que preceden a la

fase de codificación en el proceso de
desarrollo de software. Se busca que el
alumno tenga la capacidad de levantar
información de manera adecuada sobre la
necesidad de software que presenta una
empresa, para posterior a un análisis proceder
a diseñar los planos del software que
posteriormente será codificado y probado bajo
rigurosos estándares.
Objetivos Específicos Análisis y Diseño de
Sistemas

– Fomentar el razonamiento crítico en los

estudiantes.
– Fortalecer la capacidad de manejar
entidades abstractas.
– Comprender las técnicas más utilizadas en
la industria para levantar información y ser
capaz de escoger la técnica más
apropiada en cada caso.
– Crear la capacidad de crear diseños de
sistema posterior a la fase de análisis
– Comprender el modelo unificado
Sistemas de Información Análisis y Diseño de
Sistemas

Tecnologías de
Información

Información Recursos
Humanos

Sistemas
Componentes de un Sistema de Información Análisis y Diseño de
Sistemas

s en Ba Re
ano a s ses cu
m list de r so
H u c i a sd
s pe da
s o e s tos eD
r y yd ato
cu es
Re ec
l Control s
a
s fin del desempeño o
no
o cim
u ari del sistema
ien
Us to
SI
Pro

Procesamiento de
gra

datos en

are
ma

información
Rec

ios
Entrada de recursos Salida de productos
sy

dw
de datos de información

med
pro

Har
u
rso

ced

de
inas
s

imie
de

os
u
Máq
nto
Sof

urs
Almacenamiento de
s

recursos de datos
twa

Rec
re

Medios de comunicación y soporte de redes

Recursos de Redes
 Componentes de un Sistema de Información Análisis y Diseño de
Sistemas

• Recursos Humanos
– Usuarios o clientes Finales: Son
personas que utilizan un sistema de
información o la información que éste
genera
– Especialistas de Sistemas de
Información (SI): son las personas que
desarrollan y operan los sistemas de
información

• Recursos de Hardware
– Sistemas de computador: Unidad de Procesamiento Central
(CPU), quien contienen los microprocesadores, entre otros
dispositivos.
– Periféricos del computador: Dispositivos como el teclado, mouse,
pantalla, impresora
Componentes de un Sistema de Información Análisis y Diseño de
Sistemas

• Recursos de Software
– Software de Sistemas: controla las
operaciones de un sistema computacional,
como el sistema operativo
– Software de aplicación: dirigen el
procesamiento para un uso particular de
computadores por parte de usuarios
finales.
– Procedimientos: son instrucciones
operacionales para utilizar un sistema de
información
 Componentes de un Sistema de Información Análisis y Diseño de
Sistemas

• Recursos de Datos
– Bases de datos: contienen los datos
procesados y organizados
– Bases de conocimiento: incluyen
conocimiento sobre una variedad de formas
como hechos, reglas y ejemplos de casos sobre
prácticas empresariales exitosas

• Recursos de Redes:
– Medios de Redes: El medio en que se transmite la información
de un lugar a otro
– Soporte de redes: Los recursos que respaldan las operaciones
y el uso de una red de comunicación
 Clasificaciones de Sistemas de Información Análisis y Diseño de
Sistemas

Sistemas de
Información

Sistemas de Sistemas de
Apoyo a las Apoyo
Operaciones Gerencial

Sistemas de Sistemas de Sistemas de Sistemas de Sistemas de Sistemas de

Proc. de Control de Colaboración Información Apoyo a las Información
Transacciones
Procesos Empresarial Gerencial Decisiones Ejecutiva
 Clasificaciones de Sistemas de Información Análisis y Diseño de
Sistemas

Sistemas de Apoyo
a las Operaciones
• Sistemas de Procesamiento de
Transacciones: Procesan datos resultantes de
transacciones empresariales, actualizan bases de datos
Procesan operacionales y generan documentos empresariales
datos – Dolencias:
generados por • Información repetida o faltante
operaciones
• Necesidad de procesos alternos para validar el flujo
empresariales
• Errores de procedimiento
• Pocos datos almacenados sobre el flujo de la información en los
procesos
• Se requiere de tiempo extra de los usuarios para presentar reportes
rutinarios y de toma de decisiones
• Los procesos que utilizan en papel son ineficaces o propensos a
errores
 Clasificaciones de Sistemas de Información Análisis y Diseño de
Sistemas

• Sistemas de control de procesos: Supervisan y

Sistemas de Apoyo controlan procesos industriales
– Dolencias:
a las Operaciones
• Dificultad para medir y controlar la producción

• Necesidad de mucho personal en supervisión de procesos

• Mucho tiempo invertido en recolectar datos para analizar calidad y
rendimiento de la producción o del proceso

Procesan
datos
• Sistema de Colaboración Empresarial:
generados por respaldan el equipo, el trabajo de grupo, la
operaciones colaboración y las comunicaciones empresariales
empresariales – Dolencias
• Falta de control sobre la información electrónica

• Creación de documentos por múltiples miembros del equipo es

ineficiente debido a la falta de administración de documentos

• Los empleados no pueden obtener la información que necesitan para

realizar sus trabajos y servir a sus clientes

• Falta de control en la comunicación interdepartamental o con los

clientes
 Clasificaciones de Sistemas de Información Análisis y Diseño de
Sistemas

Sistemas de Apoyo
Gerencial
• Sistema de Información Gerencial:
Proporcionan a los gerentes información en forma de
informes y presentaciones especificadas previamente
Proporcionan la
información y el • Sistemas de Apoyo a las Decisiones:
respaldo Suministran apoyo ad hoc interactivo para el proceso
necesarios para
de toma de decisiones de los gerentes
que los gerentes
tomen decisiones
efectivas • Sistemas de Información Ejecutiva: Brindan
información crítica adaptada a las necesidades de
información de los ejecutivos
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida Lineal
Consiste en
descomponer la
actividad global
del proyecto en
etapas separadas
que son realizadas
de manera lineal,
es decir, cada
etapa se realiza
una sola vez, a
continuación de la
etapa anterior y
antes de la etapa
siguiente
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
en Cascada
Admite
iteraciones,
después de cada
etapa se realiza
una o varias
revisiones para
comprobar si se
puede pasar a la
siguiente. Es un
modelo poco
flexible y con
muchas
restricciones
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
en V
Contiene las
mismas etapas que
el ciclo de vida
cascada, con la
diferencia de que
posee dos
subetapas de
retroalimentación
entre las etapas de
análisis y
mantenimiento y
entre las de diseño
y debugging
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida tipo Sashimi
Contiene las
mismas etapas que
el ciclo de vida
cascada, con la
diferencia de que
se pueden solapar
las etapas.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida en Cascada con
Subproyectos
Cada una de las
cascadas se divide
en subetapas
independientes
que se pueden
desarrollar en
paralelo
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida Iterativo
Es la iteración de varios
ciclos de vida en
cascada. Al final de cada
iteración se le entrega al
cliente una versión
mejorada o con mayores
funcionalidades del
producto. El cliente es
quien luego de cada
iteración evalúa el
producto y lo corrige o
propone mejoras. Estas
iteraciones se repetirán
hasta obtener un
producto que satisfaga al
cliente.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida por Prototipo
No es exclusivo del ciclo
de vida iterativo, se
utilizan para validar los
requerimientos de los
usuarios en cualquier
ciclo de vida. Si no se
conoce exactamente
como desarrollar
determinado producto o
cuales son las
especificaciones de
forma precisa, suele
recurrirse a definir
especificaciones para
hacer un prototipo; o sea,
un producto parcial o
provisional.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida Evolutivo
Los requerimientos del
usuario pueden cambiar
en cualquier momento.
Este modelo afronta este
problema mediante la
iteración de los ciclos
requerimientos-
desarrollo-evaluación.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida Incremental
Se basa en la filosofía de
construir incrementando
las funcionalidades del
programa. Se realiza
construyendo por
módulos que cumplen
funciones del sistema,
esto permite ir
aumentando
gradualmente las
capacidades del
software. Es una
repetición del ciclo de
vida en cascada,
aplicándose este ciclo en
cada funcionalidad del
programa a construir.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida en Espiral
Se basa en una serie de ciclos
repetitivos para ir ganando
madurez en el producto final.
Toma los beneficios de los ciclos
de vida incremental y por
prototipos, pero se tiene mas en
cuenta el concepto de riesgo que
aparece debido a las
incertidumbres e ignorancias de
los requerimientos
proporcionados al principio del
proyecto o que surgirán durante
el desarrollo. A medida que el
ciclo se cumple (el avance del
espiral), se van obteniendo
prototipos sucesivos que van
ganando la satisfacción del
cliente o usuario.
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de
vida en Espiral
Hay cuatro actividades que
envuelven a las etapas:
Planificación: Levantamiento de
requerimientos iniciales y luego
de una iteración
Análisis de riesgo: Deacuerdo
con el relevantamiento de
requerimientos decidimos si
continuamos con el desarrollo
Implementación: desarrollamos
un prototipo basado en los
requerimientos
Evaluación: El cliente evalúa el
prototipo, si da su conformidad,
termina el proyecto, de lo
contrario, incluimos los nuevos
requerimientos solicitados en la
siguiente iteración
 Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de vida

Orientado a Objetos
Cada funcionalidad o
requerimiento solicitado
por el usuario, es
considerado un objeto.
Los objetos están
representados por un
conjunto de propiedades,
a los cuales
denominamos atributos,
por otra parte, al
comportamiento que
tendrán los objetos los
denominamos métodos.
Modelo de Ciclo de Vida del Software Análisis y Diseño de
Sistemas

Modelo de ciclo de vida Orientado a Objetos

La característica principal de este modelo es la abstracción de los requerimientos
de usuario, por lo que este modelo es mucho mas flexible que los restantes, que
son rígidos en requerimientos y definición. La abstracción es lo que nos permite
analizar y desarrollar las características esenciales de un objeto,
despreocupándonos por los menos relevantes.

Utilizan las fichas CRC (Clase-responsabilidades-colaboración) como herramienta

para obtener las abstracciones y mecanismos clave de un sistema analizando los
requerimientos del usuario. En la ficha CRC se escribe el nombre de la clase y
objeto, sus responsabilidades (métodos) y sus colaboradores (otras clases u objetos
de los cuales necesita). Estas fichas, además, nos ayudan a confeccionar los casos
de uso.
Proceso Unificado Análisis y Diseño de
Sistemas

USDP (Proceso Unificado de Desarrollo de Software, Unified

Software Development Process )
Es una metodología completa para el desarrollo de software.
Es una metodología adaptable, es decir, puede modificarse para el
producto software específico que se va a desarrollar
No es una serie especifica de pasos que si se siguen darán como resultado
la construcción de un producto de software.
UML (Lenguaje Unificado de Modelado, Unified Modeling
Language)
Es un estándar internacional para representar los productos de software
orientados a objetos
Es la herramienta que utilizamos para representar (modelar) el producto
de software elegido
Permiten a los profesionales de software comunicarse entre si con mayo
rapidez y exactitud que si nada mas utilizaran descripciones verbales
Proceso Unificado Análisis y Diseño de
Sistemas

Modelo
Es una serie de diagramas UML que representan uno o mas aspectos del
producto software que se va a desarrollar

Paradigma Orientado a Objetos

Es una metodología iterativa e incremental.
Cada flujo de trabajo consiste en diversos pasos, y para llevar a cabo ese
flujo de trabajo, los pasos de este se realizan en repetidas ocasiones hasta
que los miembros del equipo de desarrollo estén convencidos de que
tienen un modelo de UML exacto del producto de software que se desea
desarrollar.
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo
centrales del
proceso unificado
Flujo de trabajo:
• De los
requerimientos
• Del análisis
• Del diseño
• De la
implementación
• De las pruebas
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de los requerimientos:

Flujo de trabajo
centrales del • Su objetivo es que la empresa de desarrollo determine las
proceso unificado necesidades del cliente
Flujo de trabajo: • La primera tarea es adquirir buena comprensión del
• De los
requerimientos
dominio de la aplicación, es decir, el entorno en el que
• Del análisis operara.
• Del diseño
• De la • En una reunión inicial entre el cliente y desarrolladores, el
implementación cliente delinea el producto como lo conceptualiza. Debe
• De las pruebas determinarse con exactitud lo que el cliente necesita, y
cuales son las restricciones que existen.

• Algunas restricciones pueden ser: Limite de tiempo,

Confiabilidad y Costo.
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de los requerimientos:

Flujo de trabajo
centrales del • A la investigación preliminar del cliente muchas veces se
proceso unificado le conoce como exploración del concepto.
Flujo de trabajo: • En reuniones ulteriores entre los miembros del equipo de
• De los
requerimientos
desarrollo y el del cliente se afina y analiza, en sucesión,
• Del análisis la funcionalidad del producto propuesto en cuanto a la
• Del diseño posibilidad técnica y la justificación financiera
• De la
implementación• Un aspecto fundamental en el desarrollo de software es el
• De las pruebas modelo de negocio, un documento que demuestra la
relación costo-eficacia del producto solicitado.
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo del análisis:

Flujo de trabajo
centrales del • Es analizar y afinar los requerimientos, con el fin de
proceso unificado conseguir la comprensión detallada de los requerimientos
primordiales para desarrollar un producto de software
Flujo de trabajo:
• De los correcto y de fácil mantenimiento.
requerimientos
• Del análisis • Los artefactos del flujo de trabajo de los requerimientos
• Del diseño deben estar expresados en el lenguaje del cliente.
• De la
implementación• El flujo de trabajo de análisis, en un lenguaje mas preciso
• De las pruebas que garantice que se efectúen correctamente los flujos de
trabajo de diseño e implementación.

• Se añaden detalles durante el flujo de trabajo del análisis,

no importante para la comprensión del cliente del producto
software objetivo, pero esenciales para los profesionales
de la programación que desarrollaran el producto software
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo del análisis:

Flujo de trabajo • Las especificaciones del producto constituyen un contrato
centrales del
proceso unificado • Una vez el cliente ha aprobado las especificaciones,
comienza la planeación y estimación detalladas. Es
Flujo de trabajo:
requerido por el cliente conocer el tiempo y el costo del
• De los
requerimientos
proyecto antes de aprobarlo
• Del análisis
• Del diseño
• Equivocaciones que se cometen en un análisis clásico
• De la son:
implementación
• – Ambigüedad
De las pruebas
– Incompletas

– Contradicciones

• Los desarrolladores necesitan que se asigne el personal

adecuado para los diferentes flujos de trabajo del proceso
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo del análisis:

Flujo de trabajo • Es necesario redactar un plan de administración de
centrales del proyecto de software (SPMP, Software Project
proceso unificado Management Plan) que muestre los flujos de trabajo
independientes del proceso de desarrollo y muestre que
Flujo de trabajo:
• De los miembros de la organización están involucrados en cada
requerimientos tarea, así como los limites de tiempo para determinar cada
• Del análisis una
• Del diseño
• De la • Una vez el cliente haya aprobado las especificaciones,
implementación iniciara la preparación del plan de administración de
• De las pruebas proyecto de software

• Los principales componentes son: Los disponibles (que va

a conseguir el cliente), los hitos (cuando los consigue el
cliente) y el presupuesto (cuanto va a costar)
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo del análisis:

Flujo de trabajo • El plan describe el proceso del software con todo detalle.
centrales del Incluye aspectos como el modelo del ciclo de vida que se
proceso unificado va a utilizar, la estructura organizacional de la empresa de
desarrollo, las responsabilidades del proyecto, los
Flujo de trabajo:
• De los objetivos y prioridades gerenciales, las técnicas y
requerimientos herramientas CASE que se van a utilizar y los calendarios,
• Del análisis presupuestos y asignaciones de recursos detallados.
• Del diseño Sustentando todo el plan están los estimados de duración
• De la y costo.
implementación
• De las pruebas
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de Diseño:

Flujo de trabajo • Las especificaciones muestran qué va a hacer el producto;
centrales del el diseño muestra cómo lo hará
proceso unificado
• El objetivo del flujo de trabajo de diseño es afinar los
Flujo de trabajo:
artefactos del flujo de trabajo del análisis hasta que el
• De los
requerimientos
material se encuentre en tal forma que pueda ser
• Del análisis implementado por los programadores
• Del diseño
• De la • Durante la fase de diseño clásica, el equipo de diseño
implementación determina la estructura interna del producto. Los
• De las pruebas diseñadores descomponen en módulos, piezas de código
independientes, con interfaces bien definidas para el resto
del producto. Debe especificarse con detalle la interface
de cada modulo (argumentos que pasan al módulo y los
que regresa al módulo)
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de Diseño:

Flujo de trabajo • Una vez el equipo haya terminado la descomposición del
centrales del módulo (diseño arquitectónico), se lleva a cabo el
proceso unificado diseño detallado; se seleccionan los algoritmos y se
eligen las estructuras de datos de cada módulo
Flujo de trabajo:
• De los
• En el Paradigma Orientado a Objetos la base de ese
requerimientos
• Del análisis paradigma es la clase, un tipo de módulo específico. Las
• Del diseño clases se extraen durante el flujo de trabajo del análisis y
• De la se diseñan durante el flujo de trabajo del diseño
implementación
• De las pruebas • Razones por la que el equipo de diseño debe tener un
registro meticuloso de las decisiones de diseño que se
tomen:
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de Diseño:

Flujo de trabajo • Cuando se está diseñando el producto, en ocasiones se
centrales del llega a un punto muerto, y el equipo de diseño deberá
proceso unificado regresar sobre sus pasos y rediseñar algunas piezas
Flujo de trabajo: • En teoría, el diseño del producto debe ser abierto, lo que
• De los
requerimientos
significa que se podrán hacer mejoramientos futuros
• Del análisis (mantenimiento postentrega) añadiendo nuevas clases y
• Del diseño sustituyendo las existentes sin afectar todo el diseño
• De la
implementación
• De las pruebas
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de Implementación

Flujo de trabajo • Su objetivo es implementar el producto software objetivo
centrales del en él o los lenguajes de programación elegido
proceso unificado
• Un producto de software pequeño puede ser
Flujo de trabajo:
implementado por el diseñador
• De los
requerimientos
• Un producto de software grande se reparte en
• Del análisis
• Del diseño subsistemas pequeños (componentes o artefactos de
• De la código implementados por un solo programador), los
implementación cuales son implementados en paralelo por equipos de
• De las pruebas codificación

• La única documentación que se les proporciona al

programador es el artefacto de diseño pertinente
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de las pruebas

Flujo de trabajo • Toda persona de desarrollo es responsable de garantizar
centrales del que si trabajo sea correcto
proceso unificado
• Una vez el profesional de software esta convencido de
Flujo de trabajo:
que un artefacto esta correcto, será manejado por el grupo
• De los
requerimientos
de garantía de calidad de software para pruebas
• Del análisis independientes
• Del diseño • Artefactos de los requerimientos
• De la – Si se tienen que probar durante el ciclo de vida del producto
implementación de software, entonces una propiedad que deben tener es la
• De las pruebas posibilidad de seguimiento
– Si los requerimientos han sido presentados en forma
metódica, se han numerado adecuadamente, tienen las
referencias y los índices adecuados, entonces los
desarrolladores tendrán poca dificultad en rastrear a través
de los artefactos ulteriores y garantizar que estos en realidad
son un reflejo real de los requerimientos del cliente
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de las pruebas

Flujo de trabajo • Artefactos del análisis
centrales del
– Para comprobarlo se realiza una revisión por los
proceso unificado representantes del equipo de análisis y del cliente, dirigido
Flujo de trabajo: por un representante del grupo SQA (Garantía de Calidad de
• De los Software, Software Quality Assurance)
requerimientos
• Del análisis – Cuando inicia la planificación detallada puede revisarse las
• Del diseño estimaciones de costo y duración
• De la • Artefactos del diseño
implementación – Cada parte del diseño puede estar vinculada a un artefacto
• De las pruebas
de análisis
– Entre los tipos de fallas que se buscan están las fallas de la
lógica, de interfase, falta de manejo de excepciones (el
procesamiento de las condiciones de error) y la no
conformidad con las especificaciones
 Proceso Unificado Análisis y Diseño de
Sistemas

Flujo de trabajo de las pruebas

• Artefactos de la implementación
Flujo de trabajo – Cada componente debe ser probado durante su
centrales del implementación (comprobación de escritorio) y después
proceso unificado que se ha implementado, se corre contra pasos de prueba.
Flujo de trabajo: Estas son realizadas por el programador
• De los – Pruebas Unitarias: El grupo de garantía de calidad prueba
requerimientos el componente de forma metódica
• Del análisis – Pruebas de integración: comprueban que los componentes
• Del diseño se combinan correctamente para obtener un producto que
• De la satisfaga sus especificaciones
implementación – Pruebas al producto: se verifica la funcionalidad de todo el
• De las pruebas producto contra las especificaciones, en particular deben
probarse las restricciones listadas en las especificaciones
– Pruebas de aceptación: se entrega al cliente, quien lo
prueba en el hardware real y con datos reales
– Versión alfa: luego de realizado las pruebas se entrega los
posibles clientes futuros seleccionados
– Versión beta: es la versión alfa corregida
Proceso Unificado Análisis y Diseño de
Sistemas

Mantenimiento Posentrega
• Es una parte integral del proceso de programación que debe ser
planificada desde el principio
• Todo el esfuerzo de desarrollo del software ha de llevarse a cabo en
tal forma para llevar al mínimo el efecto del mantenimiento posentrega
futuro
• Probar cambios realizados el producto:
– Verificar que los cambios requeridos hayan sido implementados
correctamente
– Garantizar que no se hizo ningún otro cambio inadvertido. Esto se realiza
haciendo pruebas al producto contra casos anteriores para cerciorarse que
no se haya comprometido la funcionalidad del resto del producto (pruebas
de regresión)
• Debe crearse un registro de todos los cambios hechos, junto con el
motivo para cada cambio.
Proceso Unificado Análisis y Diseño de
Sistemas

Retiro
• Es la etapa final del ciclo de vida del software
• Etapa en que ya no se consigue una buena relación de costo
eficacia para mantenimiento posentrega:
– Cuando los cambio sugeridos son tan exhaustivos que tendría que
cambiarse todo el diseño
– Tal vez se hicieron tantos cambios al diseño original que se
construyeron interdependencias inadvertidas del producto
– Tal vez se realizo un mantenimiento inadecuado de la
documentación, aumentando así el riesgo de una falla de regresión
a hasta le grado que seria mas seguro recodificar que mantener
– El hardware (y el sistema operativo) en el que corre el producto va
a ser sustituido; puede ser mas económico volver a escribir desde
cero que modificar
 Proceso Unificado Análisis y Diseño de
Sistemas

Las fases del

proceso unificado
• Fase de
comienzo
• Fase de
elaboración
• Fase de
construcción
• Fase de
transición
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Comienzo
• Su objetivo es determinar si vale la pena desarrollar el
Las fases del producto objetivo
proceso unificado • Debemos comprender el propio dominio
• Fase de
• Como opera la organización cliente de este dominio
comienzo
• Fase de • Delimitar el alcance del proyecto
elaboración • Identificar riesgos:
• Fase de – Riegos técnicos
construcción
• – No obtener los requerimientos correctos
Fase de
transición – No obtener arquitectura correcta
• El objetivo del flujo de trabajo de prueba en esta fase es
garantizar que se determinen con exactitud los
requerimientos
• La planificación es una parte esencial en cada fase. Los
desarrolladores en esta fase tienen suficiente información
al principio de la fase para planificar todo el desarrollo
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Comienzo
• Entregables:
Las fases del – Versión inicial del modelo del dominio
proceso unificado – Versión inicial del modelo de negocio
• Fase de – Versión inicial de los artefactos para los requerimientos
comienzo
– Una versión preliminar de los artefactos para el análisis
• Fase de
elaboración – Una versión preliminar de la arquitectura
• Fase de – La lista inicial de los riesgos
construcción – Los casos de uso iniciales
• Fase de – El plan para la fase de elaboración
transición
– La versión inicial del caso de negocios (incluye descripción
del alcance del producto y los detalles financieros)
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Comienzo
Las fases del
proceso
unificado
• Fase de
comienzo
• Fase de
elaboración
• Fase de
construcción
• Fase de
transición
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Elaboración
• Su objetivo es afinar los requerimientos iniciales, afinar la
Las fases del arquitectura, vigilar los riesgos y afinar sus prioridades,
proceso unificado afinar el caso de negocio y producir el plan de
• Fase de administración de proyecto.
comienzo • Las principales actividades son las depuraciones y
• Fase de
elaboraciones de la fase anterior
elaboración
• Fase de • Entregables:
construcción – El modelo del dominio terminado
• Fase de – El modelo de negocio terminado
transición
– Artefactos de requerimientos terminado
– Los artefactos del análisis terminado
– Una versión actualizada de la arquitectura
– La lista actualizada de los riesgos
– El plan de administración de proyecto de software (para el
resto del proyecto)
– Caso de negocios terminado
Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Elaboración
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Construcción
• Su objetivo es producir la primera versión con calidad
Las fases del operativa del producto de software, denominada versión
proceso unificado beta
• Fase de • Se codifican los diversos componentes y se prueba la
comienzo unidad
• Fase de
elaboración • Se compilan y vinculan (integran) para formar
• Fase de subsistemas, los cuales se prueban para su integración
construcción • Se combinan los subsistemas en el sistema general, el
• Fase de cual se prueba como producto
transición
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Construcción
• Entregables:
Las fases del – Manual de usuario inicial y otros manuales, según sea
proceso unificado adecuado
• Fase de – Todos los artefactos (las versiones de emisión beta)
comienzo – Arquitectura completa
• Fase de
– La lista de riesgos actualizada
elaboración
• Fase de – El plan de administración de proyecto de software (para el
construcción resto del proyecto)
• Fase de – Si es necesario, Caso de negocios actualizado
transición
Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Construcción
 Proceso Unificado Análisis y Diseño de
Sistemas

Fase de Transición
• Su objetivo es garantizar que en realidad se hayan
Las fases del cumplido los requerimientos del cliente
proceso unificado • Es accionada por la retroalimentación desde los lugares
• Fase de donde se ha instalado la versión beta
comienzo
• Fase de
• Se corrigen las fallas del producto software
elaboración • Se terminan todos los manuales
• Fase de • Se intenta descubrir todos los riesgos que no se habían
construcción identificado antes
• Fase de
transición • Entregables:
– Todos los artefactos (versiones finales)
– Los manuales terminados
Tarea Análisis y Diseño de
Sistemas

Mejoramientos del proceso de Software

 Mejoramiento del Proceso del software Análisis y Diseño de
Sistemas

CMMI
• Nivel de Madurez. Nivel inicial
– Es el mas bajo
– Todo se hace sobre la marcha y para un propósito
– Patrón común exceso de tiempo y costo causado por una falta de
gestión en general y participación en particular
– La mayor parte de las actividades reaccionan a las crisis y no a las
tareas preplanificadas
• Madurez nivel 2. Nivel repetible
– Se realizarán prácticas básicas de la gestión del proyecto del software
– Las técnicas de gestión y planificación se basan en a experiencia con
productos semejantes
– Se toman mediciones, un primer paso primordial en la consecución de
un proceso adecuado
– Las mediciones comunes incluyen el seguimiento meticuloso de los
costos y calendarios
– Los gerentes identifican los problemas cuando surgen y toman acción
correctiva inmediata para evitar que se conviertan en crisis
 Mejoramiento del Proceso del software Análisis y Diseño de
Sistemas

CMMI
• Madurez nivel 3. Nivel definido
– El proceso para la producción de software se documenta por completo
– Los aspectos gerenciales y técnicos del proceso están muy bien
definidos y se hacen esfuerzos continuos para mejorar el proceso
cuando es posible
– Se utilizan revisiones para conseguir objetivos de calidad de software
– Tiene sentido introducir nuevas tecnologías, como los ambientes
CASE, para aumentar la calidad y productividad
• Madurez nivel 4. Nivel estabilizado
– Determina los objetivos de calidad y productividad para cada proyecto
– Estas dos cantidades se miden de forma continua y se toma la acción
correctiva cuando hay una desviación inaceptable del objetivo
– Se utilizan controles estadísticos de calidad para habilitar a la
gerencia para distinguir una desviación aleatoria de una falta
significativa de las normas de productividad y calidad
 Mejoramiento del Proceso del software Análisis y Diseño de
Sistemas

ISO 9001 (Organización Internacional para la

Normalización)
• Esta normativa es la que mas puede aplicarse al desarrollo de software

• Exige que se documente el proceso tanto con dibujos como con palabras,
para garantizar conformidad y detalle

• Indica que la adhesión a las normas no garantiza un producto de buena

calidad, pero reduce el riesgo de un producto de baja calidad

• Es necesaria la gestión del compromiso de calidad, capacitación intensa

de los trabajadores, y el establecimiento y consecución de metas para el
mejoramiento de la calidad
 Diagramas Análisis y Diseño de
Sistemas

DFD
• Diagrama de Flujo de procesos

Entidad Proceso
Responsable

Proceso

Secuencia o
Nivel
Entidad
Flujo

Almacen
 UML Análisis y Diseño de
Sistemas

Use Case (Casos de Uso)

• Un caso de uso es un modelo de la iteración entre los usuarios externos
de un producto de software y el producto de software en si

• Un diagrama de casos de uso es un conjunto de casos de uso

Notación

Actores: es un usuario que Estereotipos: es una forma de

desempeña una función extender el UML, es decir, si
especifica necesitamos definir una
construcción que no este en el
UML.
Proceso: Actividad
<<Include>> Representa una
Nombre sistema funcionalidad común
Representa el sistema <<Extend>> Representa una
variación de un caso de uso
estándar
 UML Análisis y Diseño de
Sistemas

Diagrama de Clases
• Definición:

• Agregación:

• Multiplicidad

• Composición

• Generalización

• Asociación: se refiere a una relación de algún tipo entre dos clases

aparentemente• no relacionadas.
Nota: Para incluir un comentario en un diagrama UML, lo
colocamos dentro de una nota (un rectángulo con la
esquina superior derecha doblada)