ANALISIS Y DISEÑO I

Metodologías, técnicas y
herramientas
Metodologías, técnicas y herramientas
Hoy en día la necesidad para los sistemas y software es
grande, la gente en la industria y academias tienen
desarrollados métodos de trabajo que hacen del análisis y
diseño una disciplina de procesos.
La meta es ayudar al conocimiento y habilidades para que se
entienda y siga tales diseños de procesos en la ingeniería de
software, por lo que existen varias metodologías, técnicas y
herramientas que se tienen desarrollados, verificados y ampliamente
usados para ayudar a las personas durante el análisis y diseño de
sistemas.
Metodologías, técnicas y herramientas
Son procesos particulares que usted como analista seguirá
METODOLOGÍAS para ayudar a asegurar que ese trabajo este bien pensado,
completo y comprensible a los otros en su equipo de su
proyecto.

Análisis y
Diseño de S.I
HERRAMIENTAS Técnicas

Las metodologías son comprensivas, de

Las herramientas son típicamente programas de
computación de forma que hacen fácil de usar y
beneficiar las técnicas y seguir fielmente la metodología
del desarrollo del sistema.
múltiples pasos que dirigen a uno en el
desarrollo de sistemas y que guiará su
trabajo e influenciará en la calidad de su
producto final: el Sistema de Información
 METODOLOGÍAS
Las metodologías son sistemas completos de técnicas que
incluyen procedimientos paso a paso, productos resultante,
funciones, herramientas y normas de calidad para la
terminación del ciclo de vida completo del desarrollo de
sistemas.
 METODOLOGÍAS
Una Metodología para el Desarrollo de SI es un
conjunto de actividades llevadas a cabo para
desarrollar y poner en marcha un Sistema de
Información.
 OBJETIVOS Y TIPOS DE METODOLOGÍAS

• Definir actividades a llevar a cabo en un proyecto de

Objetivos de S.I.
las • Unificar criterios en la organización para el desarrollo
metodologías de S.I.
• Proporcionar puntos de control y revisión.

• Estructurada
Tipos de • Evolutiva-Incremental
Metodología • Prototipos
s • Orientada a objetos
 MIEMBROS DE UN PROYECTO DE SISTEMAS
Miembros de un proyecto de Sistemas
• Líder (Gerencia el proyecto).
• Analista (recoge información
• inicial y
define requerimientos).
• Diseñador de S.I.
• Diseñador de Bases de Datos (B.D.).
• Programador (Codifica/Prueba).
AGENDA PARA EL DESARROLLO

• Planificación de Proyectos
• Justificación
• Control de Proyectos
• Estudio de Factibilidad
• Análisis
• Diseño
• Implantación
• Actualización
 EL CICLO DE VIDA Y ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS

Definición de un Modelo de Ciclo de Vida

 
Un modelo de ciclo de vida de software es una vista de las
actividades que ocurren durante el desarrollo de software,
intenta determinar el orden de las etapas involucradas y los
criterios de transición asociadas entre estas etapas.
 EL CICLO DE VIDA Y ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS

Un modelo de ciclo de vida del software:

 
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definición de un detallado proceso de
desarrollo de software.
 
Así, los modelos por una parte suministran una guía para los ingenieros de
software con el fin de ordenar las diversas actividades técnicas en el proyecto,
por otra parte suministran un marco para la administración del desarrollo y el
mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de
control intermedios, monitorear el avance, etc.
 ELEMENTOS DEL CICLO DE VIDA

Un ciclo de vida para un proyecto se compone de fases

sucesivas compuestas por tareas planificables. Según el
modelo de ciclo de vida, la sucesión de fases puede
ampliarse con bucles de realimentación, de manera que lo
que conceptualmente se considera una misma fase se pueda
ejecutar más de una vez a lo largo de un proyecto,
recibiendo en cada pasada de ejecución aportaciones de los
resultados intermedios que se van produciendo
(realimentación).
ELEMENTOS DEL CICLO DE VIDA
 ELEMENTOS DEL CICLO DE VIDA
A continuación presentamos los distintos elementos que integran un ciclo de
vida
Fases. Una fase es un conjunto de actividades relacionadas con un
objetivo en el desarrollo del proyecto. Se construye agrupando
tareas (actividades elementales) que pueden compartir un tramo
determinado del tiempo de vida de un proyecto. La agrupación
temporal de tareas impone requisitos temporales correspondientes
a la asignación de recursos (humanos, financieros o materiales). 
Cuanto más grande y complejo sea un proyecto, mayor detalle se
necesitará en la definición de las fases para que el contenido de
cada una siga siendo manejable. De esta forma, cada fase de un
proyecto puede considerarse un “micro-proyecto” en sí mismo,
compuesto por un conjunto de micro-fases. 
 ELEMENTOS DEL CICLO DE VIDA

Otro motivo para descomponer una fase en subfases menores puede ser el
interés de separar partes temporales del proyecto que se subcontraten a
otras organizaciones, requiriendo distintos procesos de gestión.

Cada fase viene definida por un conjunto de elementos

observables externamente, como son las actividades con
las que se relaciona, los datos de entrada (resultados de
la fase anterior, documentos o productos requeridos para
la fase, experiencias de proyectos anteriores), los datos
de salida (resultados a utilizar por la fase posterior,
experiencia acumulada, pruebas o resultados efectuados)
y la estructura interna de la fase.
ESQUEMA GENERAL DE OPERACIÓN DE UNA FASE

Procedente de la A la fase
Fase anterior
Tareas propias de la Fase
posterior

Documento Documentos
s y productos
y productos Validación del trabajo de salida
de entrada

Re planificación y/o
realimentación

Experiencia
acumulada
 MODELOS DE DESARROLLOS

• Modelo en cascada o Clásico (modelo tradicional)

• Modelo Contractual
• Modelo de técnicas de Cuarta generación
• Modelo de prototipos.
• Modelo en espiral.
• Modelos Agiles (XP, RAD, SCRUM)
• Modelo RUP
 MODELOS DE DESARROLLOS

Concepto de ciclo de vida.

Por ciclo de vida, se entiende la sucesión de etapas por
las que pasa el software desde que un nuevo proyecto
es concebido hasta que se deja de usar.
Cada una de estas etapas lleva asociada una serie de
tareas que deben realizarse, y una serie de
documentos (en sentido amplio: software) que serán la
salida de cada una de estas etapas y servirán de
entrada en la etapa siguiente.
 MODELO CASCADA

Este paradigma es el más antiguo de los

.

empleados en la IS y se desarrolló a partir

del ciclo convencional de una ingeniería. No
hay que olvidar que la IS surgió como copia
de otras ingenierías, especialmente de las
del hardware, para dar solución a los
problemas más comunes que aparecían al
desarrollar sistemas de software.
 CICLO DE VIDA DEL MODELO CASCADA
Ingeniería del
.
Sistema
Análisis

Diseño

Codificación

Prueba

Utilización

Mantenimiento

Sustitución
 CARACTERISTICAS DEL MODELO CASCADA
1.Es el modelo mas utilizado.
2.El proceso es secuencial.
.

3.Los requerimientos deben estar bien establecidos de forma

objetiva y clara.
4.Cuenta con un mecanismo de retroalimentación
5.El Desarrollador tiene la mayor responsabilidad.
6.Es una visión del proceso de desarrollo de software como una
sucesión de etapas que produce un proyecto intermedio.
7.Para que el proyecto tenga éxito deben desarrollarse todas
las fases pero las fases continúan hasta que todos los
objetivos se hallan cumplido.
8.Si se cambian las fases, el producto será de menor calidad.
 ESPECIFICACION DE REQUERIMIENTOS

Utilizar
.

OBTENCION DE Normas de
INFORMACION
MEDIANTE
ESPECIFICACIO especificación
CUESTIONARIO CLASIFICACION
N DE como ser
S SOFTWARE • IEEE830
ENTREVISTAS • CMMI
OBSERVACION
• ISO
• SPACE
 FASES DEL MODELO CASCADA

. • El análisis de requisitos debe ser más detallado para

aquellos componentes del sistema que vamos a
implementar mediante software. El ingeniero del
software debe comprender cuáles son los datos que se
van a manejar, cuál va a ser la función que tiene que
cumplir el software, cuáles son los interfaces
requeridos y cuál es el rendimiento y otros requisitos
ANALISIS DE no funcionales que se esperan lograr. Los requisitos,
tanto del sistema como del software deben
REQUISITOS documentarse y revisarse con el cliente. Como
resultado del la fase de análisis, obtendremos la
especificación de requisitos del software.
 FASES DEL MODELO CASCADA

. • El software es siempre parte de un sistema mayor, por lo que

siempre va a interrelacionarse con otros elementos, ya sean
hardware, máquinas o personas. Por esto, el primer paso del
ciclo de vida de un proyecto consiste en un análisis de las
características y el comportamiento del sistema del cual el
software va a formar parte. En el caso de que queramos
construir un sistema nuevo, por ejemplo un sistema de control,
deberemos analizar cuáles son los requisitos funciones del
sistema, y luego asignaremos un subconjunto de estos
ANALISIS requisitos y funciones al software. En el caso de un sistema ya
existente (supongamos, por ejemplo, que queremos
informatizar una empresa) deberemos analizar el
funcionamiento de la misma, - las operaciones que se llevan a
cabo en ella -, y asignaremos al software aquellas funciones
que vamos a automatizar.
 FASES DEL MODELO CASCADA
• El diseño se aplica a cuatro características distintas del software:
.
la estructura de los datos, la arquitectura de las aplicaciones, la
estructura interna de los programas y las interfaces.
• El diseño es el proceso que traduce los requisitos en una
DISEÑO representación del software de forma que pueda conocerse la
arquitectura, funcionalidad e incluso la calidad del mismo antes
de comenzar la codificación.

• La codificación consiste en la traducción del diseño a un

formato que sea comprensible para la máquina. Si el diseño es
lo suficientemente detallado, la codificación es relativamente
CODIFICACION sencilla, y puede hacerse - al menos en parte - de forma
automática, usando generadores de código.
 FASES DEL MODELO CASCADA

• Una vez que ya tenemos el programa ejecutable, comienza la

fase de pruebas. El objetivo es comprobar que no se hayan
producido errores en alguna de las fases de traducción
anteriores, especialmente en la codificación. Para ello deben
probarse todas las sentencias, no sólo los casos normales y
todos los módulos que forman parte del sistema.diseño es lo
suficientemente detallado, la codificación es relativamente
sencilla, y puede hacerse - al menos en parte - de forma
PRUEBAS automática, usando generadores de código.
• Métodos de pruebas(caja negra, caja blanca)
• Estrategias de pruebas (pruebas unitarias, pruebas de
validación, pruebas de integración, pruebas alfa y beta….)
 FASES DEL MODELO CASCADA

• La implementación es la puesta en marcha

Implementación del software

• Que, durante la utilización, el cliente detecte errores en el software: los errores

latentes.
• Que se produzcan cambios en alguno de los componentes del sistema
informático: por ejemplo cambios en la máquina, en el sistema operativo o en
los periféricos.
Mantenimiento
• Que el cliente requiera modificaciones funcionales (normalmente ampliaciones)
no contempladas en el proyecto.
REQUERIMIENTOS
Expresan las necesidades del usuario, las reglas del negocio, la disponibilidad de tecnología,
características requeridas, diseño, ambiente, especificaciones de hardware, performance, planes de
control de calidad, casos de prueba, prototipos, etc.
REQUERIMIENTO

Datos Interfaz
Ambiente Otros
Humano
5% 6% 6% 7%
5%
Documentación
2%
Diseño Lógico Errores de
Requerimientos

28%

“Los errores de 42%

requerimientos son la clase
más frecuente de error.”
PROCESO

Estudio de Análisis de
Viabilidad Requerimientos

Definición de
Requerimientos
Informe de Modelo del
Viabilidad Sistema Especificación
Requerimientos
Definición de
Requerimientos
Documento Especificación
Requerimientos Requerimientos
INVOLUCRADOS

Usuario
Lider
Personal de
Mantenimiento

Usuario
Final

Comunicación efectiva entre

clientes y desarrolladores
Personal de
Prueba

Otros
Analistas y
Personal de
Programadores
Mantenimiento
DIFICULTADES

Sistema
?
Existente

Nuevo
Sistema
Barreras de Comunicación El sistema Evoluciona

Documentación de
requerimientos
Actividades

 Análisis del Problema.

 Evaluación y Negociación.
 Especificación (SRS).
 Validación.
 Evolución.
ANÁLISIS DEL PROBLEMA
Necesidades
Iniciales de todos
los involucrados
del proyecto

?
Acuerdo entre Problemas
in volucrados del Negocio

Definir los límites y

Comprender el Problema
restricciones del Sistema
EVOLUCIÓN Y NEGOCIACIÓN DE REQUERIMIENTOS
Req. Ambiguos

Definir los problemas potenciales Req. Incompletos

Req. Inconsis tentes

Clasificar los requerimientos

Madatorio Evaluar y Analizar $ y
Deseables Complejidad
Inncesarios

Incluir los mandatorios

Describir los deseables
Descartar los innecesarios
Fac. Económica

Evaluar factibilidades y riesgos Fac. Técnica

Fac. Operacional
IR: Especificación de Requerimientos (SRS)

Requisitos de Hardware
Necesidades
Requisitos de Software

Funcionalidades
Modelos de Sistemas

Diagramas

SRS

FUENTE BASICA DE COMUNICACIÓN

VALIDACIÓN DE REQUISITOS

ESTANDARES DE CALIDAD

IEEE ISO9000
OK
CMM
SRS
SPICE

SRS LIBRE DE ERRORES

EVOLUCIÓN DE LOS REQUERIMIENTOS

Requerimientos Cambian

Cambió el
mercado en el
cual se desarrolla
el Negocio
SRS
Cambió el
ambiente del
negocio

Los usuarios
cambiaron su
forma de pensar
No se realizaron o sus
las preguntas percepciones
correctas a las
personas
correctas
 PLANTILLA
ESPECIFICACION DE REQUERIMIENTOS 3.2.3.1 SECUENCIA ESTIMULO/RESPUESTA
1. INTRODUCCION 3.2.3.2 REQUERIMIENTOS FUNCIONALES
1.1 PROPOSITO ASOCIADAS
1.2 ALCANCE 3.2.3.2.1 REQUERIMIENTO FUNCIONAL 1
1.3 DEFINICIONES, SIGLAS, Y 3.2.3.2.2 REQUERIMIENTO FUNCIONAL 2
ABREVIACIONES ..............
1.4 VISTA GENERAL / RESUMEN ..............
2. DESCRIPCION GENERAL
2.1 PERSPECTIVA DEL PRODUCTO 3.2.4 CASO DE USO 4
2.1.1 INTERFACES DEL SISTEMA 3.2.4.1 INTRODUCION / PROPOSITO
2.1.2 INTERFACES CON EL USUARIO 3.2.4.2 SECUENCIA ESTIMULO/RESPUESTA
2.1.3 INTERFACES CON EL HARDWARE 3.2.4.3 REQUERIMIENTOS FUNCIONALES
2.1.4 INTERFACES CON OTROS SOFTWARE ASOCIADAS
2.1.5 INTERFACES CON DISPOSITIVOS DE 3.2.4.3.1 REQUERIMIENTO FUNCIONAL 1
COMUNICACIÓN
2.1.6 OPERACIONES ..............
2.1.7 REQUERIMIENTOS DE ADAPTACION A ..............
AL UBICACIÓN
2.2 FUNCIONES DEL PRODUCTO 3.2.5 CASO DE USO 5
2.3 CARACTERISTICAS DEL USUARIO 3.2.5.1 INTRODUCION / PROPOSITO
2.4 RESTRICCIONES 3.2.5.2 SECUENCIA ESTIMULO/RESPUESTA
2.5 SUPOSICIONES Y DEPENDENCIAS 3.2.5.3 REQUERIMIENTOS FUNCIONALES
3. REQUERIMIENTOS ESPECIFICOS ASOCIADAS
3.1 INTERFACES EXTERNAS 3.2.5.3.1 REQUERIMIENTO FUNCIONAL 1
3.1.1 INTERFACES DE USUARIO ..............
3.1.2 INTERFACES DE HARDWARE ..............
3.1.3 INTERFACES DE SOFTWARE 3.2.6 CASO DE USO 6
3.1.4 INTERFACES DE COMUNICACIÓN REGISTRAR SEGUIMIENTO ACTIVO FIJO
3.2 CARACTERISTICA DEL SISTEMA 3.2.6.1 INTRODUCION / PROPOSITO
3.2.6.2 SECUENCIA ESTIMULO/RESPUESTA
3.2.1 CASO DE USO 1 3.2.6.3 REQUERIMIENTOS FUNCIONALES
3.2.1.1 INTRODUCION / PROPOSITO ASOCIADOS
3.2.1.2 SECUENCIA ESTIMULO/RESPUESTA ..............
3.2.1.3 REQUERIMIENTOS FUNCIONALES ..............
ASOCIADAS .......
3.2.1.3.1 REQUERIMIENTO FUNCIONAL 1 .......
.............. 3.3 REQUERIMIENTOS DE RENDIMIENTO
.............. 3.4 RESTRICCIONES DE DISEÑO
3.5 ATRIBUTOS DEL SISTEMA SOFTWARE
3.2.2 CASO DE USO 2 3.6 OTROS REQUERIMIENTOS
3.2.2.1 INTRODUCION / PROPOSITO
3.2.2.2 SECUENCIA ESTIMULO/RESPUESTA
3.2.2.3 REQUERIMIENTOS FUNCIONALES
ASOCIADAS
3.2.2.3.1 REQUERIMIENTO FUNCIONAL 1
..............
..............

3.2.3 CASO DE USO 3

INTRODUCION / PROPOSITO
.