Mod 6.2 introducción al análisis

03-23-05
Universidad Andrés Bello
Facultad de Ingeniería
Modelamiento
de
Sistemas

Metodologías de desarrollo de software
Definición
• Conjunto de pasos y procedimientos que deben seguirse para el
desarrollo de software.
• Conjunto de filosofías, fases, procedimientos, reglas, técnicas,
herramientas, documentación y aspectos de formación para los
desarrolladores de SI [Maddison, 1983]
• Conjunto de procedimientos, técnicas, herramientas y soporte
documental que ayuda a los desarrolladores a realizar nuevo
software

Definición
• Un metodología de desarrollo por lo tanto representa el camino a
seguir para desarrollar software de manera sistemática y persigue
algunos de los siguientes objetivos:
• Mejores Aplicaciones
• Un mejor Proceso de Desarrollo que identifique salidas (o
productos intermedios) de cada fase de forma que se pueda
planificar y controlar el proyecto
• Contar con un proceso Estándar en la organización

Definición
• En la actualidad debiéramos contar con metodologías que nos
permitan resolver los problemas del desarrollo de software y que
debieran contar con.
– Técnicas de desarrollo que minimicen la complejidad de un
sistema software.
– Métodos y conceptos que permitan al productor y al cliente
explorar la naturaleza del sistema software lo antes posible.
– Técnicas que minimicen los efectos devastadores de las
modificaciones durante el desarrollo y la explotación.

Metodología vs Ciclo de vida
• Existen varias diferencias entre Metodología, Ciclo de Vida y Método
– Una Metodología puede ser aplicada a uno o varios modelos de Ciclo
de Vida
– Un Ciclo de Vida indica qué obtener, pero no cómo
– Una Metodología es un concepto más amplio que Método , se puede
considerar como un conjunto de métodos. Una metodología puede
incluir un conjunto de métodos (de análisis, diseño, programación,
etc.) para abarcar el ciclo de vida completo

Ciclo de vida
El marco del ciclo de vida del software cubre desde la
conceptuación de las ideas iniciales del producto hasta el fin
de su uso (retirada).

Ciclo de vida del software
Análisis
Diseño
Implementación
Pruebas
Mantenimiento

Modelo Lineal o secuencial
Análisis
Diseño
Implementación
Pruebas
Mantenimiento

Modelo Lineal o secuencial
Este modelo refleja un desarrollo marcado por la sucesión
escalonada de las etapas que lo componen.
Es necesario terminar por completo cada etapa para pasar a la
siguiente
Este modelo, identificado ya a principios de la década de los 50,
resulta muy rígido porque cada fase requiere como elemento de
entrada el resultado completo de la anterior.
Al aplicarlo en situaciones reales su rigidez genera problemas,
porque muchas veces resulta difícil poder disponer de requisitos
completos o del diseño pormenorizado del sistema en las fases
iniciales.
Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas legados en los que el desconocimiento
de las necesidades de los usuarios, o del entorno de operación no plantea riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo.
El modelo prácticamente idéntico, que evita esta rigidez es el de
cascada.

Modelo en cascada
Cascada

Modelo en cascada

Modelos del ciclo de vida
Cascada
• En 1970 Winston Royce definió flujos de retorno sobre el modelo
secuencial, acuñando así el modelo en cascada.
• Refleja la necesidad real de retornar desde una fase hacia las anteriores
con la información generada al avanzar el desarrollo.
• Un representaciones permite retorno posible entre una fase y la anterior, el
otra permite el retorno en cualquier fase para modificar cualquiera de las
anteriores.
• Reconoce la importancia de disponer de los requisitos y diseño antes de
comenzar con la codificación del sistema, lo anterior puede actuar como
una barrera que bloquee el comienzo de la siguiente fase.
• Se puede caer en la tentación de comenzar con el diseño o incluso con la
codificación, sin tener un conocimiento suficiente de los requisitos.
• Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas legados en los que el desconocimiento
de las necesidades de los usuarios, o del entorno de operación no plantean
riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo.

Consideraciones
• Aportes
– Muy utilizado para adaptaciones o mejoras de sistemas
existentes.
– Útil cuando los requisitos están fijos.
• Desmedros
– Es raro que los proyectos reales sigan el flujo secuencial.
– Es difícil que el cliente sepa de manera explícita todos los
requisitos de manera explícita.
– El cliente debe tener paciencia.

Actividad en la que se analizan y clarifican los diferentes
aspectos del problema que debe ser resuelto por la
aplicación, con el fin de establecer claramente qué debe ser
construido
El resultado es, normalmente, un documento de requisitos
software que especifica claramente las funcionalidades de la
aplicación
Análisis

• Actividad en la que se decide la organización y la
estructura de una aplicación que satisfaga los diferentes
requisitos establecidos en la fase de análisis
• El resultado es uno (o varios) documentos de diseño que
especifican claramente cómo construir la aplicación
• Mientras que el análisis se ocupa de qué hay que hacer, el
diseño se ocupa de cómo hacerlo
• Hay varias técnicas de diseño, en la actualidad se utiliza
UML a través de algunos de los diagramas propuestos
Diseño

• Actividad en la que se construye (codifica) la aplicación
utilizando un lenguaje de programación concreto, y
siguiendo, las directrices marcadas por los documentos de
diseño
• Si las actividades anteriores han sido realizadas
correctamente, la fase de implementación debería ser
bastante trivial
• La implementación se encarga de concretar el diseño
teniendo en cuenta un lenguaje y herramienta de
desarrollo concreta
Implementación

• Actividad en la que se asegura que la aplicación construida
satisface los requisitos del usuario
• Se debe invertir mucho tiempo en hacer pruebas (mucho
más que en su implementación!)
• Dos pasos diferenciados
• Verificación: ¿Se ajusta la aplicación construida a los requisitos
establecidos?
• Validación: ¿Resuelve la aplicación el problema que realmente tenía
el usuario?
Pruebas

Actividad en la que la aplicación se modifica para satisfacer
cambios o ampliaciones en los requisitos del usuario, corregir
errores, etc.
Es la actividad más costosa en el desarrollo de software
(Consisderar que hay programas que están muchos años en
funcionamiento y lo usan miles de personas)
Estos costes pueden aliviarse si se hacen bien todo lo
anterior
Mantenimiento

Consideraciones
• Una solución informática no consiste sólo en programar.
• Se requiere conocer cuáles son las necesidades del cliente.
– Identificar los requisitos, anotarlos, analizarlos, validarlos, etc.
• Diseñar una solución y definir de que manera se realizará el
software, es decir confeccionar los “planos” del software:
– Diseño de la arquitectura, detallado, de datos, …
• Asegurarse de que el software funciona:
– Pruebas de unidad (a nivel de método y clase), de integración, del
sistema de aceptación etc. sistema, de aceptación, etc.
• Mantener coherencia entre las fase por las fases que componen el
desarrollo de software

Modelos de construcción por prototipos
• Este paradigma se basa en la producción de una versión
operacional del software, para un conjunto de requisitos
limitado (excluyéndose parte de la funcionalidad).
• El prototipado consiste en la construcción de modelos de
prueba, que simulen el funcionamiento que se pretende
conseguir en el sistema.
• Los prototipos pueden ser:
Ligeros: dibujos de pantallas de interfaz con simulación de
funcionamiento por enlaces a otros dibujos…
Operativos: Módulos de software con funcionamiento propio
que se desarrollan sin cubrir las funcionalidades completas del
sistema, normalmente en entornos RAD (rapid application
development”.

Esta forma de trabajo previo suele tener como principal objetivo la
experimentación con un entorno similar al deseado, para obtener
retro-información del usuario o cliente que ayuda a los
desarrolladores en la obtención de los requisitos.
Aunque ofrece muchas ventajas, deben conocerse los riesgos que
implica el uso de prototipado:
 Como puede parecer que se ha desarrollado un interfaz de usuario
sofisticado y elaborado, el cliente puede llegar a pensar que ya se ha
realizado el grueso del trabajo.
 Si se trata de un prototipo operativo, puede empezar a crecer al
margen de la planificación, más allá de los objetivos previstos,
desbordando agendas y recursos.
 Si se trata de un prototipo ligero desarrollado fuera del departamento
de desarrollo (ej. Marketing), puede mostrar al cliente funcionalidades
no implementables.
 El prototipo puede llegar a ofrecer funcionalidades superiores a lo
conseguible, por estar construido en un entorno diferente al de
desarrollo, o no incluir toda la funcionalidad del sistema.

Prototipo Evolutivo

Ventajas:
• Los usuarios tienen la posibilidad de interactuar con el
prototipo y realimentar a los desarrolladores.
• Para los usuarios es mas confortable enfrentarse a un
prototipo que a una especificación (mayor identificación).
• Decrece el esfuerzo de desarrollo entre un 40% y un 70%.
Un diseño rápido es posible cuando los requisitos son claros.

Desventajas:
• Se puede adicionar funcionalidad intrascendente bajo presiones de
uso normal.
• Posibilidad de pensar que es en sí una especificación (sólo es parte).
• Puede demostrar funcionalidad que no es posible bajo apremios
reales.
• El usuario puede creer que tiene frente a sí el sistema completo y
operable.
• Posibilidad de subestimar el proyecto, ya que las salidas están
pronto disponibles.

Modelo Espiral

Modelo Espiral
Espiral
Definido por Boehm en 1988, presenta un desarrollo evolutivo, en contraste a
la linealidad del cascada. También introduce como elemento distintivo la
actividad de “análisis de riesgo” para guiar la evolución del proceso de
desarrollo.
El ciclo de iteración de este modelo evolutivo se convierte en una espiral, que
al representarse sobre ejes cartesianos muestra en cada cuadrante una clase
particular de actividad: Planificación, Análisis de riesgo, Ingeniería y
Evaluación, que se suceden de forma consecutiva a lo largo del ciclo de vida
del desarrollo. La dimensión angular representa el avance relativo en el
desarrollo de las actividades de cada cuadrante. En cada ciclo de la espiral se
realiza una parte del desarrollo total, a través de los cuatro tipos de
actividades.
En la planificación de cada vuelta se establece el contexto del desarrollo y se
decide qué parte del mismo se abordará en el ciclo siguiente.
Las actividades de análisis de riesgo evalúan las alternativas posibles para la
ejecución de la siguiente parte del desarrollo, seleccionando la más ventajosa
y previendo los riesgos posibles.

Modelo Espiral
Espiral
Las actividades de ingeniería corresponden a las indicadas en los modelos
lineales (secuencial y cascada): análisis, diseño, codificación, etc.
Las actividades de evaluación analizan los resultados de la fase de ingeniería,
tomando el resultado de la evaluación como punto de partida para el análisis
de la siguiente fase.
Este modelo permite múltiples combinaciones ya que en la planificación de
cada ciclo se determina el avance que se va a ejecutar durante la vuelta,
puede consistir en la obtención y validación de requisitos, o en el desarrollo
del diseño, o el diseño junto con la codificación, o en la obtención de un
subsistema completo (cascada de requisitos  diseño, codificación, pruebas e
integración).
En función de las combinaciones empleadas se podría argumentar que un
desarrollo en espiral puede acabar siendo idéntico a otro modelo. Así por
ejemplo si cada vuelta realizase exactamente una de las fases del modelo en
cascada, al final se podría argumentar que se ha seguido una cascada. Si por
el contrario en cada vuelta se desarrollara una parte del sistema global, se
podría decir que se ha seguido no un modelo de ciclo de desarrollo, sino de
ciclo de vida, y concretamente el modelo incremental.

Modelo Espiral
Ventajas:
• Demanda una consideración directa de los riesgos técnicos
en todas las etapas del proyecto.
• Permite la utilización de la creación de prototipos como un
mecanismo de reducción del riesgo.
• Permite utilizar el enfoque de creación de prototipos en
cualquier etapa de evolución del producto.
Desventajas
• Criticidad del análisis de riesgo
• Difícil de “vender” como algo controlable

Consideraciones para aplicar un ciclo de vida
Al iniciar el proyecto, el responsable de la arquitectura de procesos debe
realizar los siguientes pasos:
 Análisis de las circunstancias ambientales del proyecto.
 Diseño del modelo específico de ciclo de vida para el proyecto (sobre las bases de
los diseños más apropiados, para el desarrollo y la evolución del sistema de
software.
 Mapeo de las actividades sobre el modelo.
 Desarrollo del plan para la gestión del ciclo de vida del proyecto.
Debe considerar aspectos como:
 Posibilidad de descomposición del sistema en subsistemas de software, con
agendas y entregas diferenciadas.
 Estabilidad esperada de los requisitos.
 Novedad del proceso o procesos gestionados por el sistema en el entorno del
cliente.
 Criticidad de las agendas y presupuestos.
 Grado de complejidad del interfaz de operación, criticidad de la usabilidad.
 Grado de conocimiento y familiaridad con el entorno de desarrollo, componentes
externos empleados, etc.

Que Modelo a utilizar
Proyecto de software
Un proyecto es una organización transitoria de individuos
dedicados a alcanzar un objetivo especifico dentro de un
periodo de tiempo, un presupuesto, y un objetivo técnico.
Un proyecto:
• Tiene un principio y un fin.
• Debe de tener un objetivo (debe de ser medible).
• Requiere de un líder y de un equipo.
Por lo tanto, podemos indicar que:
• Es Temporal y Único, ya que involucra hacer algo
que no se ha hecho antes.

Que modelo usamos
• Dado que cada proyecto es único, no existe un modelo que
se aplique al 100% a todos los proyectos de una
organización.
• Una organización puede contar con uno o más modelos de
desarrollo para ser utilizados dependiendo del tipo de
proyecto.
• El modelo seleccionado tendrá influencia en el éxito del
proyecto y en el tipo de decisiones que se deberán hacer.

Como sabremos cual es el más adecuado
Para seleccionar el modelo a adoptar habrá que
hacerse una serie de cuestionamientos:
– ¿Qué tantos son los riesgos del proyecto?
– ¿Qué tan claros están los requerimientos?
– ¿Se conoce bien la tecnología ha utilizar?
– ¿Visibilidad que requiere el proyecto?
– ¿Qué tanta planeación hacia adelante es requerida?
– ¿Qué restricciones se tienen?

Criterios de éxito
• Contar con un modelo debidamente documentado. (entradas,
salidas, entregables, aprobaciones)
• Los documentos deben de estar actualizados.
• La gente que participa en el proyecto debe estar capacitada en su
uso.
• Se debe de reforzar el uso del modelo mediante auditorias y
revisiones.
• La alta gerencia debe soportar la utilización de un modelo.
• Cualquier desviación al modelo debe ser documentada y aprobada.
• Se debe de medir la eficiencia del modelo.
• Retroalimentar y ajustar.

Lecciones aprendidas por el profesor
• No existe una formula que indique cual es el modelo más
adecuado, Ud. debe ser capaz de definir el más apropiado, de
acuerdo al proyecto. Ningún proyecto es igual a otro.
• Un modelo no plantea un solución única, complementar modelos
puede ser la mejor solución.

Fases del Análisis OO
• Centrarse en el “qué”.
• Identificar los requisitos: documentos de análisis.
– Entrevistas.
– Identificar requisitos funcionales y no funcionales (ej.:
rendimiento, fiabilidad)
• Especificar los requisitos: documento de especificación de requisitos.
– Documentos técnicos. Organización y clasificación de los
requisitos.
• Analizar: Modelos de análisis.
– Estudio de posibles escenarios: casos de uso.
– Otras técnicas: fichas CRC, orientados al flujo, etc.
• Validar

Fases del Análisis OO
– La especificación de
requisitos describe el
sistema, en lenguaje
natural.
– Sirve de comunicación
entre desarrolladores y
clientes, “contrato”.
– El modelo de análisis usa
notación formal (ej.: Z,
Alloy) o semi-formal).
– Sirve de comunicación
entre desarrolladores.

Modelos de Análisis OO

Mod 6.2 introducción al análisis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Mod 6.2 introducción al análisis

Ähnlich wie Mod 6.2 introducción al análisis (20)

Mehr von Pedro Montecinos Gaete

Mehr von Pedro Montecinos Gaete (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Mod 6.2 introducción al análisis