Requerimientos de Sistemas Primer Cuatrimestre de...

R de S – Primer Cuatrimestre 2015

Requerimientos de Sistemas

Primer Cuatrimestre de 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:


Una imagen vale más que mil palabras…


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).


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)


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


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


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


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.


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”


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


Ingeniería de Requerimientos

Desarrollo de Requerimientos

Administración de Requerimientos

Captura

Análisis

Especificación

Validación

Estudio de Factibilidad


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


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)


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)


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


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)


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.


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.


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.





Captura

Análisis

Especificación

Validación



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


Puede aplicarse en los siguientes casos:

Requerimientos bien definidos

Proyectos pequeños y cortos

Entorno estable

Mejora de sistema existente.


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.


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


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


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


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

…


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


Primer Incremento: producto esencial o fundamental Requisitos básicos esenciales


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.


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.


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.





Captura

Análisis

Especificación

Validación



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


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)


¿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)


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


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


Modelo de

Prototipos

Definir

Requerimientos

Diseñar

Prototipo

Implementar

Prototipo

Usar

prototipo

Desarrollar el Sistema





Captura

Análisis

Especificación

Validación



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.


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


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


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.


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.


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


Iterar ordenadamente

Conducido por el riesgo


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


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.


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.


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


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


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


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

Requerimientos de Sistemas Primer Cuatrimestre de...

Documents

Transcript of Requerimientos de Sistemas Primer Cuatrimestre de...