requerimientos de sistemas primer cuatrimestre de...
Post on 21-Sep-2018
219 Views
Preview:
TRANSCRIPT
R de S – Primer Cuatrimestre 2015
¿Por qué lleva tanto tiempo finalizar un SW?
¿Por qué los costos de desarrollo son tan altos?
¿Por qué los errores no se detectan hasta que el
SW es entregado a los clientes/usuarios?
¿Por qué es necesario destinar tanto tiempo y
esfuerzo al mantenimiento de programas existentes?
¿Por qué es tan difícil medir progreso durante el
desarrollo?
…
Problemas que persisten:
R de S – Primer Cuatrimestre 2015
Características del SW:
El software es lógico y no físico.
El software es maleable.
El software se desarrolla no se fabrica.
La industria tiende a ensamblar componentes, pero aún la mayor parte del software se construye es a medida.
El software no se “gasta” (pero se deteriora).
R de S – Primer Cuatrimestre 2015
Define la relación entre las actividades, acciones y tareas
Existen diferentes modelos de procesos, incluso con algunas variaciones, pero la mayoría se basa en unos pocos paradigmas.
Estructura para las actividades, acciones y tareas que se requieren con el fin de construir software de alta calidad (Pressman)
R de S – Primer Cuatrimestre 2015
Organizan la tarea de desarrollo de software.
Dan el marco para la planificación y control del desarrollo.
Permiten asegurar calidad en el producto.
Dan visibilidad al proceso de desarrollo
R de S – Primer Cuatrimestre 2015
Estructura general:
1. Comunicación
2. Planificación
3. Modelado
4. Construcción
5. Despliegue
Además existen actividades “sombrilla” a lo largo de todo el proyecto
R de S – Primer Cuatrimestre 2015
Define la manera en que están organizadas las actividades estructurales, las acciones y las tareas con respecto a la secuencia y el tiempo Flujo de proceso lineal: secuencia de actividades
Flujo de proceso iterativo: repite una o más de las
actividades antes de pasar a la siguiente
Flujo de proceso evolutivo: realiza las actividades en forma circular. Cada circuito lleva a una versión más completa del sw.
Flujo de proceso paralelo: se ejecutan una o más actividades en paralelo
R de S – Primer Cuatrimestre 2015
Dado un sistema particular, su ciclo de vida comprende desde la primera la idea de desarrollo del software, hasta que es implementado, entregado, y aún después hasta que deje de usarse.
El sistema pasa por un ciclo de vida compuesto de varias
etapas.
R de S – Primer Cuatrimestre 2015
Idea /
Necesidad
Proceso de
desarrollo
Operación y
Mantenimiento
Ciclo de Vida del Sistema
Propuesta de desarrollo
El sistema de utiliza hasta que se decide reemplazarlo o abandonarlo
Sistema nuevo desarrollado
ISO/IEC 12207 Information Technology / Software Life Cycle Processes
”Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”
R de S – Primer Cuatrimestre 2015
Idea/ Necesidad
Desarrollo Operación y
mantenimiento Extinción o reemplazo
Análisis Diseño Implementación Construcción
Modelado de
negocioNecesidad
Ingeniería de requerimientos
Diseño arquitectónicoNec
esidad
Diseño de componentes
R de S – Primer Cuatrimestre 2015
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Administración de Requerimientos
Captura
Análisis
Especificación
Validación
Estudio de Factibilidad
R de S – Primer Cuatrimestre 2015
Una forma de identificar las actividades del proceso es según el eje del tiempo (no excluyente)
Varían según los distintos autores, pero la idea la misma
R de S – Primer Cuatrimestre 2015
1- Estudio de factibilidad
2- Elicitación, análisis y especificación de requerimientos
3- Diseño
4- Codificación y testeo de módulos.
5- Integración y testeo de sistemas.
6- Distribución, entrega y mantenimiento.
7- Otras actividades.
Actividades (según diferentes autores)
R de S – Primer Cuatrimestre 2015
1- Estudio de factibilidad
2- Análisis
3- Diseño
4- Codificación
5- Testeo
6- Entrega
7- Mantenimiento
1- Definición de requerimientos
2- Análisis y diseño
3- Implementación y pruebas unitarias
4- Integración y pruebas del sistema
5- Operación y mantenimiento
Actividades (según diferentes autores)
R de S – Primer Cuatrimestre 2015
Recordemos… Proceso: Estructura para las actividades, acciones y tareas que se requieren con el fin de construir software de alta calidad
Cada modelo define un conjunto de elementos y un flujo entre ellos
R de S – Primer Cuatrimestre 2015
Primeros modelos…
TRADICIONALES o CLÁSICOS
Surgen para poner orden al “caos” del proceso de desarrollo de sw
Introducen “estructura” y “road maps” (hojas de ruta)
R de S – Primer Cuatrimestre 2015
También llamado “clásico”, “secuencial”
El trabajo fluye de manera lineal desde la primera etapa hasta la última
Las etapas de desarrollo se organizan en cascada, una después de otra. Cada una debe estar terminada antes de pasar a la siguiente.
Cada actividad produce un documento de salida (entregable) que es el ingreso para la siguiente actividad y que debe ser aprobado y cerrado antes de seguir
Algún cambio durante la ejecución de una cualquiera de las etapas en este modelo secuencial implicaría reiniciar desde el principio todo el ciclo completo.
R de S – Primer Cuatrimestre 2015
Ventajas Aportó disciplina al proceso
Retrasa la implementación hasta tener objetivos claros y bien definidos
Define puntos de control en cada etapa
Simple
Desventajas: Es demasiado rígido.
Es lineal y los proyectos reales raras veces siguen un modelo lineal. No refleja la realidad más frecuente
Retrasa la detección de problemas críticos.
El usuario interviene al principio y al final del proyecto. Requiere que el cliente pueda enunciar todos los requerimientos al principio y no maneja incertidumbre.
R de S – Primer Cuatrimestre 2015
Desventajas (continúa): No provee anticipación al cambio.
Basado en documentación. Parece burocrático.
Los costos se trasladan al mantenimiento fácilmente.
No permite implementaciones parciales.
Puede generar situaciones de bloqueos entre miembros del equipo de desarrollo (esperas por finalización de la etapa anterior)
El cliente debe esperar por una versión funcional. “Gap” temporal (brecha)
El proceso de creación del software puede tardar mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera.
R de S – Primer Cuatrimestre 2015
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Administración de Requerimientos
Captura
Análisis
Especificación
Validación
Estudio de Factibilidad
R de S – Primer Cuatrimestre 2015
Desarrollo de Requerimientos En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir.
Se realiza la captura, análisis, especificación y validación de todos los requerimientos (Desarrollo de Requerimientos completo)
De esta fase surge un documento SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema
Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y esto servirá de base en las siguientes etapas, no pudiéndose incorporar o modificar requerimientos a mitad del proceso de elaboración del software.
Administración de Requerimientos No hay gestión del cambio
R de S – Primer Cuatrimestre 2015
Puede aplicarse en los siguientes casos:
Requerimientos bien definidos
Proyectos pequeños y cortos
Entorno estable
Mejora de sistema existente.
R de S – Primer Cuatrimestre 2015
Permite alguna retroalimentación entre etapas, que no es completamente predecible ni rígida
Lo normal en el modelo cascada será entonces la aplicación del mismo con sus etapas realimentadas de alguna forma, permitiendo retroceder de una a la anterior (e incluso poder saltar a varias anteriores) si es requerido.
R de S – Primer Cuatrimestre 2015
En una primera etapa se capturan y especifican los requerimientos
Los requerimientos son priorizados y validados y se inicia el diseño
Durante el diseño se pueden realizar ajustes en los requerimientos (aunque sean mínimos), ya sea por fallas detectadas, ambigüedades o bien por que los propios requisitos han cambiado o evolucionado; con lo cual se debe retornar a la primera o previa etapa, hacer los reajuste pertinentes y luego continuar nuevamente con el diseño; esto último se conoce como realimentación.
Lo mismo puede ocurrir en cualquiera de las etapas posteriores
R de S – Primer Cuatrimestre 2015
Desarrollo de requerimientos
Es posible ajustar requerimientos existentes o capturar nuevos requerimientos en etapas posteriores
Ajustes en especificación
Revalidación
Administración de requerimientos
Seguimiento y control (más complejo)
Incorpora gestión del cambio
R de S – Primer Cuatrimestre 2015
Problemas del modelo en cascada
“gap” (brecha) entre la definición de requerimientos y la distribución de la
aplicación.
Los requerimientos del negocio y el producto cambian durante el desarrollo
Plazos ajustados de mercado
Proyectos grandes sin resultados “visibles” a corto o mediano plazo
A veces los detalles o extensiones al producto básico no están definidos en una etapa temprana
Fracasos debido a que el producto entregado no satisface las necesidades/expectativas del cliente o ya no es necesario
R de S – Primer Cuatrimestre 2015
Estrategia
Entregar algo y medir el valor agregado.
Ajustar diseño y objetivos.
Iterar. Evolucionar
PROCESO DISEÑADO PARA ADAPTARSE A UN PRODUCTO QUE EVOLUCIONA CON EL TIEMPO
…
R de S – Primer Cuatrimestre 2015
Iterativo – hacemos varias veces lo mismo.
Incremental – el producto se “incrementa” a medida que se avanza. También son llamados “evolutivos”.
Soluciona la necesidad de una secuencia no lineal
Combina elementos de flujo del proceso lineal y paralelo
Secuencias lineales aplicadas de manera escalonada
Puede haber un grado de paralelismo entre las distintas secuencias
Cada secuencia produce “incrementos” en el software
Es útil cuando no se dispone de personal suficiente
para la implementación completa o no se cuenta con todos los detalles en la etapa incial->Entregas parciales
Ayuda a la administración de riesgos técnicos
R de S – Primer Cuatrimestre 2015
Primer Incremento: producto esencial o fundamental Requisitos básicos esenciales
R de S – Primer Cuatrimestre 2015
El cliente usa y evalúa el producto fundamental y en base al resultado se desarrolla el plan para el incremento siguiente (mejora del producto fundamental + características adicionales)
EN CADA INCREMENTO SE ENTREGA UN PRODUCTO QUE OPERA (no es una versión de prueba o prototipo)
Requiere de un cliente involucrado durante todo el curso del proyecto.
R de S – Primer Cuatrimestre 2015
Ventajas El usuario ve algo rápidamente. Se admite que se está construyendo “el sistema” y se piensa en su
calidad desde el principio. Los ciclos van mejorando con las experiencias de los anteriores. Los trabajadores del equipo de desarrollo se especializan en ciertas
actividades. Desventajas Es difícil mantener el foco. Los primeros incrementos entran en
mantenimiento mientras se está desarrollando nuevos. Si los errores en los requisitos propuestos se detectan tarde, su
corrección resulta tan costosa como en el modelo en cascada.
R de S – Primer Cuatrimestre 2015
Un ejemplo de desarrollo siguiendo el modelo iterativo incremental para un procesador de textos:
Incremento #1: administración de archivos básicos y
producción de documentos.
Incremento #2: funciones de edición más sofisticadas (gráficos, tablas, etc.)
Incremento #3: corrección gramatical y ortográfica.
R de S – Primer Cuatrimestre 2015
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Administración de Requerimientos
Captura
Análisis
Especificación
Validación
Estudio de Factibilidad
R de S – Primer Cuatrimestre 2015
En una primera etapa se capturan y validan los requerimientos
Se selecciona el conjunto de requerimientos para la primer iteración (req. básicos o esenciales). Se analizan, especifican, priorizan y validan (IR-Desarrollo de Req)
Se desarrolla la primer entrega (“producto esencial”)
Iterar
o Se analizan los ajustes (feedback del cliente/usuario)
o Se selecciona el conjunto de requerimientos de la próxima iteración, se analizan, especifican, priorizan y validan (IR-Desarrollo de req)
o Se desarrolla el incremento y los ajustes
o Se entrega una nueva versión
R de S – Primer Cuatrimestre 2015
En cada iteración se debe garantizar la consistencia de TODOS los requerimientos (actuales y de iteraciones anteriores)
En cada iteración (2 en adelante): Desarrollo de Req + Administración de Req (gestión del cambio)
R de S – Primer Cuatrimestre 2015
¿Cómo se seleccionan los requerimientos de la primer iteración? (y posteriores…)
o Impacto funcional
o Impacto económico
o Impacto político
oCantidad de casos/escenarios cubiertos
oDefinición/Indefinición de requerimientos
oFactibilidad (tecnológica, funcional, económica)
R de S – Primer Cuatrimestre 2015
Primer desarrollo: se elabora un prototipo para descartar. El prototipo sirve para validar los requerimientos y resolver aspectos críticos del diseño.
Objetivos
o Investigación repetida de requerimientos y diseño.
oReducir el riesgo de que la solución no se ajuste a las necesidades del cliente.
La revisión del prototipo puede resultar en revisar los requerimientos anteriores.
Es útil cuando inicialmente el cliente solo define objetivos generales y no identifica requerimientos detallados
Algunos prototipos se descartan, otros Evolucionan
R de S – Primer Cuatrimestre 2015
Se elabora un diseño rápido, centrado en los aspectos del software que son visibles a los usuarios (enfoques de entrada y formatos de salida).
Ventajas
Dar una idea real más temprana al usuario
Obtener mejor definición de los requerimientos
Permite la retroalimentación por parte del usuario.
Desarrollo rápido.
Desventajas
Riesgo de perder de vista que lo que se obtiene es un prototipo y no el producto definitivo
Diseños prematuros
R de S – Primer Cuatrimestre 2015
Modelo de
Prototipos
Definir
Requerimientos
Diseñar
Prototipo
Implementar
Prototipo
Usar
prototipo
Desarrollar el Sistema
R de S – Primer Cuatrimestre 2015
Ingeniería de Requerimientos
Desarrollo de Requerimientos
Administración de Requerimientos
Captura
Análisis
Especificación
Validación
Estudio de Factibilidad
R de S – Primer Cuatrimestre 2015
El paradigma de construcción de prototipos comienza con la recolección de requisitos.
El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido.
El diseño rápido lleva a la construcción de un prototipo.
R de S – Primer Cuatrimestre 2015
El cliente/usuario evalúa el prototipo y lo utiliza para refinar los requisitos del software a desarrollar.
El prototipo permite:
Identificar requisitos
Validar requisitos
(Etapa: IR-Desarrollo)
Los ajustes al prototipo permiten mejor entendimiento al analista y visualización de resultados al cliente
La construcción de prototipos se puede usar como un modelo en sí o en alguna etapa de otros modelos
R de S – Primer Cuatrimestre 2015
Las aplicaciones con requerimientos críticos de interfaz o requerimientos críticos de rendimiento desarrollan prototipos para su validación antes de implementar el producto final
R de S – Primer Cuatrimestre 2015
Modelo Espiral - combina las actividades de desarrollo con la gestión del riesgo, para minimizar y controlar el riesgo.
Estrategia: comenzar por los desarrollos de mayor riesgo.
◦ Riesgo: circunstancias potencialmente adversas que pueden perjudicar el proceso de desarrollo y la calidad del producto.
◦ Administración del riesgo: disciplina cuyos objetivos son manejar y eliminar los ítems de riesgo (del software) antes que se transformen en amenaza.
Es iterativo
Es un meta-modelo.
R de S – Primer Cuatrimestre 2015
Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo
Las primeras iteraciones pueden producir modelos o prototipos
En cada iteración se ajustan todos los documentos:
plan, definición, modelos, costos, incluso el número
de iteraciones necesarias
Demanda una consideración directa de los riesgos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.
R de S – Primer Cuatrimestre 2015
Uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
Si los requerimientos se entienden bien, podría pensarse el modelo de cascada, como un modelo de espiral de una sola vuelta
R de S – Primer Cuatrimestre 2015
Ventajas Enfoque realista del desarrollo de software de gran escala.
Desarrollador y cliente identifican y manejan mejor los riesgos en cada evolución
Combina el enfoque sistemático de los pasos sugeridos por el ciclo de vida de cascada con en una estructura iterativa
Considera los riesgos técnicos en todas las etapas, y aplicado adecuadamente, logra reducirlos.
Desventajas Requiere de habilidades para la evaluación del riesgo, si un riesgo
importante no se descubre pierde eficacia.
No existe demasiada experiencia en su uso.
Genera mucho tiempo en el desarrollo del sistema Modelo costoso
R de S – Primer Cuatrimestre 2015
Lo característico del modelo es espiral es que incluye un “análisis de riesgo” es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
R de S – Primer Cuatrimestre 2015
Modelo iterativo e incremental
Colaboración continua entre participantes (Reconoce que al
software lo desarrollan individuos trabajando en equipo, la colaboración es clave)
Comunicación continua con el cliente
Adopción del cliente como parte del equipo
La prioridad más alta es satisfacer al cliente mediante la
entrega pronta y continua de software valioso.
R de S – Primer Cuatrimestre 2015
Entregar software funcional rápidamente (restando importancia a la documentación intermedia)
Desarrollo de incrementos de funcionalidad frecuentes y pequeños
Minimizar la documentación (solo la necesaria)
Responder de manera apropiada a los cambios
Planificaciones flexibles
R de S – Primer Cuatrimestre 2015
Suposiciones Es difícil predecir: persistencia de los requerimientos, cambios de prioridades del cliente En muchos tipos de software el diseño y la construcción se superponen:
deben ser simultáneos
Análisis, diseño, construcción y pruebas no son tan predecibles como quisiéramos: es difícil planificar El proceso debe ser adaptable, debe hacerlo incrementalmente y debe permitir la retroalimentación con el cliente
R de S – Primer Cuatrimestre 2015
Intenta combinar las características positivas de procesos tradicionales y los principios del desarrollo ágil
El trabajo de Rumbaugh, Booch y Jacobson en un “método unificado” resulta en la definición del “Lenguaje de modelado unificado” (UML)
Desarrollan el “proceso unificado”, estructura para la ingeniería de software orientado a objetos que utiliza UML
Flujo de proceso iterativo e incremental
R de S – Primer Cuatrimestre 2015
Recomendamos repasar los contenidos aprendidos en la materia Introducción a la Ingeniería de Software:
Cascada
• Modelo en V
Incremental Iteraciones: modelo evolutivo
• Prototipos • Espiral
Concurrente Modelos de procesos especializados
• Desarrollo basado en componentes • Métodos formales • Orientado a aspectos
Proceso Unificado Metodologías Ágiles
top related