El Producto y el Proceso (Cap. I y II ,

1
El Producto y el Proceso (Cap. I y II , Ing.
del Software - Un Enfoque Práctico, Roger S.
Pressman, 5ta Edición).

• Qué es la Ingeniería del Software?
• (1) La aplicación de un enfoque sistemático,
  disciplinado y cuantificable hacia el desarrollo,
  operación y mantenimiento del Software es decir
  la aplicación de la Ingeniería al Software.
• (2) El estudio de enfoques como (1).IEEE, 1993

2
El Producto Características del SW

• Producto y vehículo.
• Lógico, no físico.
• Se desarrolla, no se fabrica.
• No se desgasta, se deteriora.
• Mayoría hecho a medida, tendencia a reusar.
• En los 60s, subrutinas de cálculos numéricos.
• Actualidad, biliotecas de componentes (objetos).

3
El Producto Aplicaciones del SW

• Dificil establecer compartimientos netamente
  separados.
• SW de Sistemas
• SW de Tiempo Real
• SW de Negocio o Gestión
• SW de Ingeniería o Científico
• SW Embebido o Empotrado
• SW de PC
• SW de IA
• SW basado en la Web

4
El Producto - Mitos del Software

• Propagaron confusión e información errónea.

Del administrador del proyecto Mitos del SW
Del usuario final o cliente Del desarrollador
5
El Producto - Mitos del Software Ejemplos

• Si fallamos en la planificación, podemos añadir
  más programadores y adelantar el tiempo perdido
  (MA)
• Los requisitos cambian continuamente, pero los
  cambios pueden acomodarse fácilmente porque el SW
  es flexible (MC)
• Lo único que se entrega al terminar el proyecto
  es el programa funcionando (MD).

6
El Proceso

• Qué es?
• Marco de trabajo de tareas a realizar para
  desarrollar SW de alta calidad.
• Es sinónimo de Ingeniería del Software?
• Define un enfoque para desarrollar SW en forma
  ingenieril, pero la ISW comprende, además de un
  Proceso, Métodos y Herramientas.

7
Qué es la Ingeniería del Software?

• Pressman Tecnología multicapa

Herramientas
Métodos
Capa fundamental
Proceso
Un enfoque de calidad
8
El Proceso Visión Genérica
Ing. Sistemas Planificación Análisis de req.
Definición (QUE)
Desarrollo (COMO)
Diseño G. de Código Prueba
Mant. Correctivo Mant. Adaptativo Mant.
Perfectivo Mant. Preventivo o Reingeniería del
Software
Soporte (CAMBIOS)
9
El Proceso Modelo de Capacidad de Madurez (CMM)

• Nivel 1 Inicial
• Nivel 2 Repetible
• Nivel 3 Definido
• Nivel 4 Gestionado
• Nivel 5 Optimizado

10
Modelo Lineal Secuencial

• Ciclo de vida clásico, modelo en cascada
• antiguo, usado
• Enfoque sistemático secuencial

Análisis
Diseño
Codif.
Ing. de Sistemas
Prueba
Mant.
11
Modelo Lineal Secuencial

• Críticas
• Proyectos reales raras veces se ajustan.
• Raras veces cliente expone todos los req. de
  entrada.
• Producto operativo al final gt Paciencia
  (cliente) alta.
• Consejo
• Usar cuando todos los requerimientos han sido
  establecidos claramente de entrada.

12
Modelo de Construcción de Prototipos

• No están claros los reqs. de entrada
• Iterativo. Hasta cuando se itera?
• Working prototype, desechar y empezar con
  desarrollo de sistema.

13
Modelo de Construcción de Prototipos

• Críticas
• Cliente cree que es el sistema.
• Peligro de familiarización con malas elecciones
  iniciales (quick and dirty).
• Consejo
• Usar cuando inicialmente no están claros los
  requerimientos.
• Definir claramente de entrada las reglas de juego
  con el cliente.
• No ceder a presión del cliente.

14
Modelo DRA (Desarrollo Rápido de Aplicaciones)

• Lineal secuencial con ciclo extremadamente corto.
• Candidatos sistemas que se pueden modularizar gt
  equipos de desarrollo paralelos.
• Basado en el uso de componentes y T4G.

15
Modelo DRA
Qué información? Quién la genera? A dónde va?
Identificación de Objetos y relaciones
Descripciones de procesos de negocio para ABM de
objetos de MD
T4G Reusabilidad de Componentes
Prueba de Comp. Nuevos e interfaces.
Tiempo
16
Modelo DRA

• Críticas
• Proyectos grandes gt gran nro. de personas.
• Alto compromiso en tiempo.
• No apto para todo tipo de sistema (ej. no
  modularizable, baja reusabilidad de componentes).
  
• Desaconsejable cuando riesgos tecnológicos altos
  (ej. Uso de nuevo lenguaje) o alta
  interoperatividad con programas ya existentes.

17
Modelos Evolutivos

• Se adaptan más fácilmente a los cambios
  introducidos a lo largo del desarrollo.
• Iterativos
• En cada iteración se obtienen versiones más
  completas del SW.
• Modelos Evolutivos
• Modelo Incremental ()
• Modelo en Espiral ()
• Modelo de Desarrollo Basado en Componentes ()
• Modelo WINWIN
• Modelo de Desarrollo Concurrente

18
Modelo Incremental

• Iteración de Lineal Secuencial.
• Cada iteración devuelve un Incremento o versión
  operativa. (Ej. Editor de texto).
• Util cuando no se está seguro de cumplir con
  plazos de tiempo o se tiene una fecha imposible
  de cambiar.

19
Modelo Incremental
Tiempo
20
Modelo en Espiral
21
Modelo en Espiral

• Util para proyectos grandes.
• Permite usar el prototipado en todas las etapas
  de la evolución para reducir el riesgo.
• Mantiene el enfoque sistemático de los pasos
  sugeridos por el lineal secuencial, pero lo
  incorpora dentro de un marco iterativo más real.
• Críticas
• Dificil de convencer a los clientes de que es
  controlable.
• Requiere mucha habilidad para el análisis de
  riesgos y de esta habilidad depende su éxito.
• No ha sido utilizado tanto como el lineal
  secuencial o el de prototipos.

22
Desarrollo Basado en Componentes

• Basado en modelo en Espiral (evolutivo e
  iterativo) Tecnologías de Objetos.
• Enfatiza la Reusabilidad.

23
Modelo de Métodos Formales

• Usan notación rigurosa.
• Especificaciones sin ambigüedades.
• Utiles para sistemas críticos.
• Demostraciones formales de propiedades.
• Dificulta validación con cliente gt combinación
  con otras técnicas semi-formales.
• Alto nivel de experticia en lógica y matemática.

24
Técnicas de Cuarta Generación (T4G)

• Herramientas que facilitan la realización de
  especificaciones a alto nivel -gt código fuente.
• Basadas en Lenguajes de 4ta Generación (L4G).
• Ventajas Reducción en tiempo de desarrollo.

25
Técnicas de Cuarta Generación (T4G)

• Críticas
• Código ineficiente.
• No mas fáciles de usar que L3G.
• Mantenimiento cuestionable.
• Consejo Aunque se usen T4G se debe hacer
  análisis, diseño y pruebas (sino mala calidad,
  mantenimiento pobre, baja aceptación por el
  cliente).