Ingeniera de Software

1
Ingeniería de Software

• Resumen del libroIngeniería de Software de Roger
  Pressman, 6ta ed.
• Prof. Gorka Llona
• UBV PFGIGS
• Abril 2006

2
Capítulo 1Software e Ingeniería de Software

3
SoftwareQué es el Software?

• Es el conjunto de
• Las instrucciones (programas) que proporcionan
  las características y funciones
• Las estructuras de datos que le permiten
  manipular información
• Los documentos que describen la operación y uso

4
Características del Software

• El software se desarrolla, no se manufactura
• Los costos del software se concentran en la
  ingeniería
• El software no se desgasta, pero sí se deteriora
• La mayoría del software se construye a la medida
• La reutilización de componentes recién ha empezado

fallas
cambio
curva real
curva idealizada
tiempo
5
Tipos de Software

• Por función
• Software de sistemas
• Software de aplicación
• Software científico y de ingeniería
• Software empotrado (embeeded)
• Software de línea de productos
• Software de inteligencia artificial
• Juegos

• Por origen
• Software nuevo
• Software heredado
• Software de integración
• Por arquitectura
• Monolítico
• Cliente/servidor
• Aplicaciones basadas en web
• Etc...

6
Mitos del Software

• Mitos del administrador
• Nuestros estándares y procedimientos para la
  construcción de software nos proporcionarán todo
  el conocimiento necesario
• Si el cronograma va atrasado es posible contratar
  más programadores para terminar a tiempo
• Si decido subcontratar el proyecto de software a
  un tercero, puedo relajarme y dejar que lo
  construya
• Mitos del cliente
• Un enunciado general de objetivos es suficiente
  para comenzar a escribir programas, los detalles
  se pueden afinar después
• Los requerimientos del proyecto cambian de manera
  continua, pero el cambio puede ajustarse con
  facilidad porque el software es flexible

• Mitos del desarrollador
• Una vez que el programa ha sido escrito y puesto
  a funcionar, el trabajo está terminado
• Mientras el programa no se esté ejecutando, no
  existe forma de evaluar su calidad
• El único producto del trabajo que puede
  entregarse para tener un proyecto exitoso es el
  programa en funcionamiento
• La ingeniería de software acarreará una
  documentación voluminosa e innecesaria que hará
  más lento el proyecto

7
Capítulo 2El Proceso del Software Visión General

8
Qué es un Proceso?

• Un proceso define quién está haciendo qué, cuando
  y cómo lograr cierta meta

9
El Proceso del Softwarey la Ingeníería del
Software

• El Proceso del Software es un marco de trabajo
  para las tareas que se requieren en la
  construcción de software de alta calidad
• El Proceso del Software define el enfoque que se
  adopta mientras el software está en desarrollo
• El Proceso del Software es parte de la Ingeniería
  del Software. La Ingeniería del Software también
  abarca métodos técnicos y herramientas
  automatizadas
• La Ingeniería del Software es el uso de
  principios sólidos de la Ingeniería para obtener
  económicamente un software confiable y que
  funcione de manera eficiente en máquinas reales

10
Estratos de laIngeniería del Software
Herramientas
Métodos
Proceso
Un enfoque de calidad
11
Marco de trabajopara el Proceso de Software

• Marco de trabajo
• Actividad 1
• Acción 1.1
• Tareas del trabajo
• Productos del trabajo
• Puntos de aseguramiento de la calidad
• Fundamentos del proyectos
• Acción 1.2
• ...
• Actividad 2
• ...
• ...
• Actividades paraguas

12
Marco de Trabajo Genérico del Proceso

• Cinco actividades principales
• Comunicación
• Planeación
• Modelado
• Construcción
• Despliegue

• Actividades paraguas
• Seguimiento y control del proyecto
• Gestión del riesgo
• Aseguramiento de la calidad
• Revisiones técnicas formales
• Gestión de la configuración del software
• Gestión de la reutilización
• Preparación y producción del producto de trabajo

13
Patrones del Proceso

• El proceso del software es una colección de
  patrones que definen un conjunto de actividades,
  acciones y tareas que requiere el desarrollo de
  un software
• Plantilla de un patrón Ambler
• Nombre
• Tipo (de tarea / de escenario / de fase)
• Contexto inicial
• Problema
• Solución
• Contexto resultante
• Patrones relacionados
• Usos conocidos / ejemplos

14
Evaluación y Mejoramiento del Proceso
Proceso delsoftware
Identificamodificaciones a
Identificacapacidadesy riesgo de
Evaluación del proceso delsoftware
Conduce a
Conduce a
Determinaciónde la capacidad
Mejoramiento delprocesode software
Motiva a
15
Evaluación y Mejoramiento del Proceso
Hacer
Planear

• Marco de trabajo
• Actividad 1
• Acción 1.1
• Tareas del trabajo
• Productos del trabajo
• Puntos de aseguramiento de la calidad
• Fundamentos del proyectos
• Acción 1.2
• ...
• Actividad 2
• ...
• ...
• Actividades paraguas

Actuar
Revisar
ISO 90012000
16
Procesos de software personalesy en equipo (PSP
/ PSE)

• El mejor proceso de software es el que está más
  cerca de la gente que realizará el trabajo
• PSP/PSE vs procesos prescriptivos
• PSP
• Planeación
• Diseño de alto nivel
• Revisión del diseño de alto nivel
• Desarrollo
• Análisis de resultados

• PSE
• Lanzamiento
• Diseño de alto nivel
• Implementación
• Integración y pruebas
• Análisis de resultados

17
Capítulo 3Modelos Prescriptivos del Proceso

18
Modelos Prescriptivos

• Llenan el marco de trabajo con conjuntos de
  tareas explícitas para las acciones de la
  Ingeniería del Software
• Son poco flexibles
• El equipo de trabajo debe adaptarse al proceso

19
Modelo en Cascada
Comunicación
Planeación
Modelado
Construcción

• Inicio del proyecto
• Recopilación de requisitos

Despliegue

• Estimación
• Cronograma
• Seguimiento

• Análisis
• Diseño

• Código
• Prueba

• Entrega
• Soporte
• Retroalimentación

Se considera el modelo clásico del desarrollo
de software
20
Modelo incremental
Avance
Incremento n
Incremento 2
Incremento 1
Tiempo
21
Modelo DRADesarrollo Rápido de Aplicaciones
Comunicación
Planeación
Despliegue
60-90 días
22
Modelo Evolutivo deConstrucción de Prototipos
Plan rápido
Comunicación
Diseño rápido
Entrega yretroalimentación
Construcciónde Prototipo
Desarrollo
23
Modelo Evolutivoen Espiral
Planeación estimación cronograma análisis
de riesgos
Comunicación
Modelado análisis diseño
inicio
Despliegue entrega retroalimentación
Construcción código prueba
24
Dificultades de los Modelos Evolutivos

• La planeación es un problema debido al número
  incierto de ciclos de iteración requeridos para
  completar el software
• Los procesos evolutivos no establecen la
  velocidad máxima de la evolución calibrar el
  ritmo es un problema
• El fin del proyecto puede estar determinado por
  alta calidad, pero se debe priorizar la
  flexibilidad, extensibilidad y entrega a tiempo

25
Desarrollo Basado en Componentes

• Se hace una investigación de los componentes
  disponibles
• Se consideran los aspectos de integración de
  componentes
• Se diseña una arquitectura de software para
  acoplar los componentes
• Los componentes se integran en la arquitectura
• Se realizan pruebas detalladas
• 70 de reducción del tiempo del ciclo de
  desarrollo
• 84 de reducción del costo del proyecto

26
Modelo de DesarrolloOrientado a Aspectos

• Aspectos
• No funcionales propiedades de alto nivel de los
  sistemas
• Funcionales aspectos de reglas del negocio
• Aspectos no funcionales o sistémicos
• Interfaces de usuario
• Trabajo en colaboración
• Distribución (flujo y transporte de eventos)
• Persistencia (almacenamiento, recuperación e
  indexación de datos)

• Seguridad (autenticación, codificación y derechos
  de acceso)
• Procesamiento de transacciones (atomicidad,
  control de concurrencia)
• Integridad (de datos, de transacciones)
• Manejo de memoria
• Etc.

27
Proceso Unificado (PU)

• Es un proceso de software guiado por los casos de
  uso, centrado en la arquitectura, iterativo e
  incremental
• Reune los mejores rasgos de los modelos
  prescriptivos de software, pero incorpora
  prácticas de los modelos ágiles
• Rumbaugh, Booch y Jacobson establecieron el UML
  (Unified Modeling Language) a principios de los
  90, y se convirtió en un estándar de la
  industria en 1997 para desarrollo orientado a
  objetos
• UML no incorpora la definición del proceso de
  software
• En los años siguientes los autores desarrollaron
  el PU, basado en UML

28
PU Fases
Elaboración
Planeación
Inicio
Comunicación
Modelado
Construcción
Construcción
Despliegue
Incrementodel software
Producción
Transición
29
PU Fases (2)

• Inicio
• Documento de la visión
• Modelo inicial de caso de uso
• Glosario inicial del proyecto
• Caso inicial de negocio
• Evaluación inicial del riesgo
• Plan de proyecto, fases e iteraciones
• Modelo del negocio (opcional)
• Uno o más prototipos

• Elaboración
• Modelo de casos de uso
• Requisitos suplementarios
• Modelo de análisis
• Arquitectura del software
• Prototipo arquitectónico ejecutable
• Modelo de diseño preliminar
• Lista revisada de riesgos
• Plan de proyecto - iteraciones - flujos de
  trabajo - fundamentos - productos técnicos
  - manual preliminar de usuario

• Construcción
• Modelo de diseño
• Componentes del software
• Incremento integrado del software
• Plan y procedimiento de pruebas
• Casos de prueba
• Documentación - del soporte - manuales de
  usuario - manuales de instalación -
  descripción del incremento actual

• Transición
• Incremento integrado de software
• Reportes de las pruebas beta
• Retroalimentación general del usuario

30
Capítulo 4Desarrollo Agil

31
Manifiesto para elDesarrollo Agil de Software

• Hemos descubierto mejores formas de desarrollar
  software al construirlo por nuestra cuenta y
  ayudar a otros a hacerlo. Por medio de este
  trabajo hemos llegado a valorar
• A los individuos y las interacciones sobre los
  procesos y herramientas
• Al software en funcionamiento sobre la
  documentación extensa
• A la colaboración del cliente sobre la
  negociación del contrato
• A la respuesta al cambio sobre el seguimiento de
  un plan
• Beck y otros, 2001

32
Principios del Desarrollo Agil

• Nuestra mayor prioridad es satisfacer al cliente
  mediante la entrega temprana y continua de
  software valioso
• Bienvenidos los requisitos cambiantes, incluso en
  fases tardías del desarrollo. La estructura de
  los procesos ágiles cambia para la ventaja
  competitiva del cliente
• Entregar con frecuencia software en
  funcionamiento, desde un par de semanas hasta un
  par de meses, con una preferencia sobre la escala
  de tiempo más corta

• La gente de negocios y los desarrolladores deben
  trabajar juntos a diario a lo largo del proyecto
• Construir proyectos alrededor de individuos
  motivados. Darles el ambiente y el soporte que
  necesitan, y confiar en ellos para obtener el
  trabajo realizado
• El método más eficiente y efectivo de transmitir
  información hecia y dentro de un equipo de
  desarrollo es la conversación cara a cara

33
Principios del Desarrollo Agil (2)

• El software en funcionamiento es la medida
  primaria de progreso
• Los procesos ágiles promueven el desarrollo
  sustentable. Los patrocinadores de
  desarrolladores y usuarios deben ser capaces de
  mantener un paso constante de manera indefinida
• La atención continua a la excelencia técnica y al
  buen diseño mejora la agilidad

• La simplicidad el arte de maximizar la cantidad
  de trabajo no realizado- es esencial
• Las mejores arquitecturas, los mejores requisitos
  y los mejores diseños emergen de equipos
  autoorganizados
• A intervalos regulares el equipo refleja la forma
  en que se puede volver más efectivo entonces su
  comportamiento se ajusta y adecúa en concordancia

34
Qué es un Proceso Agil?

• Se refiere a tres suposiciones clave
• Resulta difícil predecir cuáles requisitos del
  software persistirán y cuáles cambiarán. De igual
  forma, es difícil presagiar cómo cambiarán las
  prioridades del cliente mientras se ejecuta un
  proceso
• Para muchos tipos de software, el diseño y la
  construcción están intercalados. Esto es, ambas
  actividades se deben realizar de manera conjunta,
  de modo que los modelos de diseño sean probados
  conforme se crean. Resulta difícil predecir
  cuánto diseño se necesita antes de que la
  construcción se utilice para probar el diseño
• El análisis, el diseño y la construcción no son
  predecibles (desde el punto de vista de la
  planeación), lo que sería deseable

35
Factores Humanosen los Procesos Agiles

• Competencia
• Enfoque común
• Colaboración
• Habilidad para la toma de decisiones
• Capacidad de resolución de problemas confusos
• Confianza y respeto mutuo
• Organización propia

36
Programación Extrema (PE)

• Historias del usuario
• Valores
• Criterios de las pruebas de iteración
• Plan de iteración

• Diseño simple
• Cartas CRC
• Soluciones pico
• Prototipos

Diseño
Planeación
Refabricación
Codificación
Prueba
Lanzamiento

• Programación en pareja
• Integración continua

• Incremento de software
• Velocidad calculada del proyecto

• Pruebas de unidad
• Pruebas de aceptación

37
Desarrollo Conducidopor Características (DCC)
Desarrollar unmodelogeneral
Elaborar unalista decaracterísticas
Plan porcaracterística
Diseño porcaracterística
Construcciónporcaracterística
Plan de desarrollo Propietarios
declase Propietarios delconjunto
decaracterísticas
Paquete dediseño(secuencia)
Funcióncliente-valorcompletada
Lista de caracte-rísticas agrupadasen conjuntos
yáreas de desarrollo

• Características
• Agregar el producto a un carrito de supermercado
• Desplegar las especificaciones técnicas de un
  producto
• Almacenar la información de navegación para un
  cliente

38
Capítulo 7Ingeniería de Requisitos

39
Etapas

• Inicio del proceso
• Obtención de requisitos
• Elaboración de requisitos
• Negociación de requisitos
• Validación de requisitos
• Gestión de requisitos

40
Inicio

• Identificación de los stakeholders
• Reconocimiento de los múltiples puntos de vista
• Trabajo en el área de la colaboración
• Formulación de las primeras preguntas
• Generales
• Quiénes están detrás de la solicitud de este
  trabajo?
• Quién usará la solución?
• Cuál será el beneficio económico de una solución
  exitosa?
• Existe otra fuente para la solución requerida?
• Comprensión del problema y las percepciones
• Cómo podría caracterizarse un buen resultado
  generado por una solución exitosa?
• Cuáles problemas debería atacar esta solución?
• En qué ambiente de negocios se usará esta
  solución?
• Comunicación
• Cuáles son las personas adecuada para contestar
  las preguntas?
• Son las preguntas relevantes, o demasiadas?
• Qué otras preguntas deberían hacerse?

41
Obtención de requisitos

• Recopilación conjunta de requisitos
• Reuniones, usando técnicas de trabajo en grupo
• La meta es identificar el problema, proponer
  elementos de solución, negociar diferentes
  enfoques e identificar requisitos preliminares
• Tipos de requisitos
• Requisitos normales
• Si estos requisitos están presentes, el cliente
  estará satisfecho
• Requisitos esperados
• Implícitos, fundamentales, el cliente no los
  percibe explícitamente
• Requisitos estimulantes
• Características que van más allá de las
  expectativas del cliente
• Escenarios de usuario
• Generales o particulares (casos de uso)

42
Obtención de requisitos (2)

• Problemas
• De ámbito
• El límite del sistema está mal definido o los
  clientes especifican detalles innecesarios que
  pueden confundir los objetivos generales del
  sistema
• De comprensión
• Los clientes no están seguros de qué es lo que se
  necesita, no comprenden el dominio del problema,
  tienen dificultades para comunicarse con el
  equipo de desarrollo, omiten información que
  consideran obvia, especifican requisitos
  contradictorios, ambiguos o inestables
• De volatilidad
• Los problemas cambian conforme transcurre el
  tiempo

43
Obtención de requisitos (3)

• Productos
• Enunciado de necesidad y factibilidad
• Enunciado que limita el ámbito del sistema o
  producto
• Lista de stakeholders que participaron en la
  obtención de requisitos
• Descripción del ambiente técnico del sistema
• Lista de requisitos (organizados por función) y
  restricciones que aplican
• Conjunto de escenarios de uso
• Prototipos desarrollados para definir mejor los
  requisitos

44
Elaboración de requisitosCasos de uso

• Identificar los actores
• Preguntas que deben responderse (para cada caso)
• Quiénes son los actores primarios?
• Cuáles son las metas del actor?
• Qué condiciones previas deben existir para
  activar el caso?
• Qué tareas o funciones principales realiza el
  actor?
• Qué excepciones y variaciones al procedimiento
  existen?
• Qué información del sistema podrá el autor
  adquirir, producir o cambiar?
• Qué información desea el actor que le provea el
  sistema?
• El actor quiere ser informado acerca de cambios
  inesperados?

45
Elaboración de requisitosCasos de uso (2)

• Estructura
• Nombre del caso de uso
• Actores (enfatizando el primario)
• Meta dentro del contexto
• Condiciones previas
• Activación del caso
• Escenario (procedimiento funcional)
• Excepciones
• Asuntos pendientes
• Diagrama de casos de uso (UML)
• Combina gráficamente los diferentes casos de uso

46
Elaboración de requisitosModelado de análisis

• Elementos basados en escenarios
• Diagramas de actividades (UML)
• Elementos basados en clases
• Diagramas de clases (UML)
• Elementos basados en comportamiento
• Diagramas de estado (UML)
• Elementos basados en flujo
• Modelado de flujo

47
Negociación de requisitos

• Identificación de los interesados clave en el
  sistema o subsistema
• Determinación de las condiciones ganadoras de
  los interesados
• Negociación de las condiciones ganadoras de los
  interesados para integrarlas en un conjunto de
  condiciones ganar-ganar para todos los
  involucrados (incluyendo el equipo de software)

• El arte de la negociación
• No es una competencia
• Diseñar una estrategia
• Escuchar de manera activa
• Enfocarse en los intereses de la otra parte
• No dejar que se vuelva personal
• Ser creativo
• Estar listo para pactar

48
Validación de requisitos

• Cada requisito es consistente con el objetivo
  general del sistema?
• Todos los requisitos han sido especificados con
  el grado apropiado de abstracción?
• El requisito es necesario o no genera valor?
• Cada requisito está limitado y no es ambiguo?
• Cada requisito tiene una fuente bien
  determinada?
• Algunos requisitos entran en conflicto con
  otros?
• Cada requisito es alcanzable en el ambiente
  técnico que sustentará la solución?
• Cada requisito se puede probar al haber sido
  implementado?
• El modelo de requisitos refleja de manera
  apropiada la información, la función y el
  comportamiento del sistema que será construido?
• El modelo de requisitos se ha sometido a
  partición funcional?

49
Gestión de requisitos

• Tablas de rastreabilidad
• De las características del sistema
• De la fuente
• De dependencias entre requisitos
• De los subsistemas
• De las interfaces (entradas y salidas)