clase 2: introducción a la ing. de software. modelos de

CLASE 2:
INTRODUCCIÓN A LA ING. DE
SOFTWARE.
MODELOS DE PROCESOS.
MEJORES PRÁCTICAS
USB – Ing. De Software. Prof. I. C. Martínez
Ing. De Software
Ingeniería de Software
• La Ingeniería de Software es la ciencia y el
arte de construir sistemas de software
significativos, que sean:
1) Desarrollados a tiempo
2) Desarrollados dentro del presupuesto
3) Con un desempeño aceptable
4) Con operación correcta.
Ingeniería de Software
 La Ingeniería de Software se ocupa de las teorías,
métodos y herramientas para el desarrollo
profesional de software.
El Proceso de Software
Conjunto estructurado de actividades y resultados
que se requieren para desarrollar un sistema de
software.
 Existen 4 acividades fundamentales:
  Especificación
 Desarrollo
 Validación
 Evolución
 Estas actividades se organizan de forma diferente y
presentan diferentes niveles de detalle, dependiendo
del tipo de sistema que se desarrolla.
Modelo del Proceso de Ingeniería
Especificación: Precisar los requerimientos y las
restricciones del sistema.
 Diseño: Producir un modelo del sistema.
 Manofactura: Construcción del sistema.
 Pruebas: Chequeo de que el sistema cumple con las
especificaciones.
 Instalación: Entregar el sistema a los clientes y
asegurarse que está operativo.
 Mantenimiento:Reparar las fallas en el sistema a
medida que son encontradas.
 Diferencias de la Ingeniería de
Software
Normalmente, las especificaciones son incompletas.
 La separación entre la especificación, el diseño y la
construcción es muy difusa.
 No hay una manifestación física del sistema para
probar.
 El software no de desgasta con el uso - su
mantenimiento no significa reemplazar
componentes.
 Modelos de Procesos de Desarrollo
Modelos del proceso de software
 Cascada
 Separa
y distingue las diferentes fases de especificación y
desarrollo
 Evolutivo
 La
 especificación y el desarrollo son alternados.
Transformaciones Formales
 Un
modelo matemático del sistema se trasforma
formalmente en una implementación
 Basados en Reusabilidad
 El
sistema se ensamble a partir de componentes existentes
Modelo de Cascada
Modelo Evolutivo
Concurrent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
Transformaciones Formales
Requirements
definition
Formal
specification
Formal
transformation
Integration and
system testing
Desarrollo Basado en
Re-usabilidad
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
System
validation
Problemas de los Modelos del
Proceso
 Cascada
 Alto
riesgo para sistemas nuevos debido a problemas
de especificación y diseño.
 Bajo riesdo para desarrollos bien-conocidos usando
tecnologías familiares.
 Prototipos
 Bajo
riesgo para nuevas aplicaciones debido a
especificaciones y programas por pasos
 Alto riesgo debido a la falta de visibilidad del
proceso.
Problemas de los Modelos del
Proceso
 Transformacional
 Alto
riesgo debido a la necesidad de tecnologías
avanzadas y conocimiento altamente especializado del
personal.
 Basado en Reusabilidad
 Desorganización
en el diseño e implementación.
 Poca experiencia.
Modelos de Proceso Híbridos
Los sistemas grandes usualmente están conformados
por varios subsistemas.
 El mismo modelo de proceso no necesariamente
debe ser usado para todos los subsistemas.
 Prototipos para especificaciones de alto riesgo.
 Cascada para desarrollos bien conocidos.
 Iteración de Procesos
Los sistemas SIEMPRE evolucionan en el transcurso del
proyecto, luego la iteración del proceso donde las
etapas tempranas son re-trabajadas es parte del
proceso para grandes sistemas.
 Las iteraciones pueden ser aplicadas a cualquier
modelo de proceso.
 Dos aproximaciones relacionadas:
  Desarrollo
incremental
 Desarrollo en espiral
Desarrollo Incremental
En lugar de liberar el sistema como un todo, el
desarrollo y entrega se subdivide en incrementos.
Cada incremento entrega parte de la
funcionalidad requerida.
 Los requerimientos de los usuarios se prioritizan y
los de mayor prioridad se incluyen en los
incrementos tempranos.
 Una vez que se da inicio al desarrollo de un
incremento, los requerimientos para el mismo se
congelan aunque los requerimientos para futuros
incrementos pueden seguir evolucionando.
 Desarrollo Incremental
Define outline
requirements
Develop system
increment
Assign requirements
to increments
Validate
increment
Design system
architecture
Integrate
increment
Validate
system
Final
system
System incomplete
Ventajas del Desarrollo Incremental
Elementos de valor al cliente pueden ser entregados
en cada incremento, luego la funcionalidad del
sistema está disponible más temprano.
 Los incrementos tempranos actúan como prototipos
para ayudas a elicitar requerimientos para futuros
incrementos.
 Baja el riesgo de falla del proyecto
 Los servicios del sistema de mayor prioridad son
probados más.
 Modelo Espiral
El proceso se representa como una espiral, en lugar
de una secuencia de actividades con “backtracking”.
 Cada ciclo en el espiral representa una fase en el
proceso.
 No hay fases fijas, tales como especificación o diseño,
los ciclos en la espiral se escogen de acuerdo a lo
que se requiere.
 Los riesgos se determinan explícitamente y se
resuelven a través del proceso.
 Modelo Espiral
Determine objectives
alternatives and
constraints
Risk
analysis
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Plan next phase
Prototype 3
Prototype 2
Risk
analysis Prototype 1
Operational
protoype
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Development
plan
Requirement
validation
Integration
and test plan
Design
V&V
Product
design
Detailed
design
Code
Unit test
Integration
test
Acceptance
test
Develop, verify
Service
next-level product
Ventajas del Modelo Espiral
Enfoca la atención en la reusabilidad.
 Se enfoca en la eliminación temprana de los
errores,
 Coloca los objetivos de calidad en primer plano
 Integra desarrollo y mantenimiento.
 Proporciona un marco de trabajo para el desarrollo
de hardware y software.
 Problemas del Modelo Espiral
El desarrollo por contrato usualmente especifica el
modelo del proceso y los “entregables” por
adelantado.
 Requiere experticia en la evaluación de riesgos.
 Mejores Prácticas
– Desarrollo iterativo del software
– Manejo de requerimientos
– Uso de arquitecturas basadas en
componentes
– Modelaje visual del software
– Verificación de la calidad del software
– Control de cambios del software
• Facilita el entendimiento incremental del
problema a través de “Refinamientos
sucesivos”
• Produce la solución efectiva en “Múltiple
iteraciones”
• Reduce el “Perfil de riesgos del proyecto” en
c/etapa del desarrollo
• Provee “Progreso demostrable” con la
participación efectiva del usuario
• Cada iteración culmina con una “Versión ejecutable
– Concentración del equipo en la producción de resultados
– Chequeos frecuentes del estado aseguran seguimiento al
plan de trabajo
– Ajuste de cambios tácticos en los requerimientos,
lineamientos o plan
• Enfoque de Cascada presenta limitaciones en el
proceso de desarrollo total del SW
– Desde los Requerimientos hasta las Pruebas finales
• RUP describe cómo:
– Obtener los requerimientos
– Organizarlos
– Documentar requerimientos de funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar requerimientos del negocio
• Los casos de uso y los escenarios indicados por el proceso han
probado ser una buena forma de captar requerimientos y guiar
el diseño, la implementación y las pruebas.
• El proceso construye al inicio una
“Arquitectura ejecutable robusta” antes
de comprometer recursos de gran escala.
• Los componentes son módulos y
subsistemas con una función
• Define arquitecturas ensamblando
componentes existentes y nuevos
• La arquitectura debe ser:
– Flexible
– Fácil de modificar
– Intuitivamente comprensible
– Promueve la reutilización de componentes
• RUP apoya el desarrollo basado en componentes,
tanto nuevos como preexistentes.
• Modelado visual de la estructura y el comportamiento
de la arquitectura y los componentes.
• Esconde los detalles y el código usando “bloques
gráficos de construcción”
• La abstracción visual asiste en la comunicación de
varios aspectos del SW:
– Apreciar como los elementos de relacionan entre sí
– Asegurar la consistencia de su código con los bloques de
construcción
– Mantener la consistencia entre el diseño y su implementación
– Promover la comunicación sin ambigüedades
• UML es la base del modelamiento visual de RUP.
• No sólo la funcionalidad es esencial, también el
rendimiento y la confiabilidad.
• Evita el pobre desempeño y la ocurrencia de fallas de las
aplicaciones resultantes.
• La calidad es revisada con relación a los requerimientos:
• No ocurrencia de fallas
• Funcionalidad esperada
• Desempeño de la aplicación y del sistema.
• La evaluación de la calidad está construida en el proceso,
no es opcional:
• En todas las actividades
• Involucra a todos los participantes
• Usa medidas y criterios objetivos de forma natural
• Los cambios son inevitables, pero es necesario evaluar si
éstos son necesarios y rastrear su impacto.
• Habilidad para el manejo del cambio en ambientes de
cambio
• Factor Crítico de Éxito al Desarrollo Iterativo
• Demanda control, seguimiento y monitoreo de los cambios a
implementar
• Mantiene Áreas de Trabajo seguras para cada
desarrollador:
• Aísla los cambios hechos en otras áreas de trabajo
• Controla los cambios de todos los artefactos de SW : Modelos,
Código, Documentos, etc