Ingeniería del Software - sistemamid.com€¦ · Ingeniería del Software: un enfoque práctico....

M.C. Martín Olguín (C) 2004

Análisis Orientado a ObjetosIngeniería del Software

M.C. José Martín Olguín Espinoza


Contenido del Curso1.Introducción a la Ingeniería de Software

1.1. Definiciones de Ingeniería de Software1.2. Características del Software1.3. Aplicaciones del Software1.4. Fases básicas del desarrollo del software

(definición, desarrollo, mantenimiento).


…Contenido del Curso2.Modelos de Proceso del Software

2.1. Modelo en Cascada (ciclo de vida clásico)2.2. Modelo en “V”2.3. Modelo de Construcción de Prototipos 2.4. Modelos Evolutivos

2.4.1. Modelo Incremental2.4.2. Modelo Espiral2.4.3. Modelo Espiral WIN-WIN


...Contenido del Curso3.El Proceso Unificado de Desarrollo (RUP)

3.1. Antecedentes3.2. Dirigido por casos de uso3.3. Centrado en la Arquitectura3.4. Iterativo e Incremental


…Contenido del Curso4.Administración de proyectos de software

4.1. Componentes de un proyecto de software4.2. Personal4.3. Producto4.4. Proceso4.5. Proyecto


…Contenido del Curso5.Conceptos del Paradigma OO

5.1. El paradigma orientado a objetos5.2. Clases y Objetos5.3. Atributos5.4. Operaciones, métodos y servicios5.5. Mensajes5.6. Encapsulamiento5.7. Herencia5.8. Polimorfismo


…Contenido del Curso6.El UML

6.1. Vistas6.1.1. Vista de Casos de Uso6.1.2. Vista lógica6.1.3. Vista de Componentes6.1.4. Vista de la Implementación6.1.5. Clasificadores y mecanismos de

extensión


...Contenido del Curso6.2. Diagramas

6.2.1. Diagramas de caso de uso6.2.2. Diagramas de clases6.2.3. Diagramas de objetos6.2.4. Diagramas de estado6.2.5. Diagramas de secuencia6.2.6. Diagramas de colaboración6.2.7. Diagramas de actividad6.2.8. Diagramas de componentes6.2.9. Diagramas de implementación


...Contenido del Curso7.Ingeniería de Requisitos y Análisis OO

7.1. Especificación de Requisitos7.2. Modelo de Análisis

8.Diseño OO8.1. Modelo de Diseño8.2. Arquitectura del Software8.3. Patrones de Diseño


...Contenido del Curso9.Implementación

9.1. Programación Orientada a Objetos9.2. Modelo de Implementación

10. Pruebas OO10.1. Conceptos10.2. Pruebas del modelo de análisis y el de diseño10.3. Pruebas de unidad10.4. Pruebas de integración10.5. Pruebas de validación


...Contenido del Curso11. Métricas OO

11.1. Conceptos11.2. Métricas para el modelo de diseño OO11.3. Métricas orientadas a clases11.4. Métricas orientadas a operaciones


Bibliografía1. Ingeniería del Software: un enfoque

práctico. 5ta edición.Roger PressmanMcGraw-Hill

2. Ingeniería de Software Orientado a ObjetosBernd BrueggePearson Educación

3. The Rational Unified ProcessPhilippe KrutchenAddison-Wesley


...Bibliografía1. The Unified Modeling Language. User Guide

Grady Booch, James Rumbaugh, Ivar JacobsonAddison-Wesley

2. Design PatternsErich GammaAddison-Wesley

3. El Proceso Unificado de Desarrollo de SoftwareIvar Jacobson, Grady Booch y James RumbaughAddison-Wesley


Unidad 1

Introducción a la Ingeniería del Software


Software Es el conjunto de programas de

cómputo, documentos asociados y esquemas de configuración necesarios para que estos programas operen.[Sommerville, 2001]


Ingeniería del Software Definiciones del prólogo a la cuarta

edición en español de “Ingeniería del Software: un enfoque práctico” de Roger Pressman:

Definición 1: Ingeniería del Software es el estudio de los

principios y metodologías para desarrollo y mantenimiento de sistemas de software. [Zelkovitz, 1978]


Ingeniería del Software Definición 2:

Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software. [Bohem, 1976]



Ingeniería del software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales. [Bauer, 1972]



1. La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software. 2. El estudio de enfoques como en (1) [IEEE, 1993]



Es una disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. [Sommerville, 2001]


Ingeniería de Software e Ingeniería de Sistemas

Ingeniería de Sistemas

Ingeniería de

Software

Teoría de Sistemas


Sistema Un sistema es una colección de

componentes interrelacionados que trabajan conjuntamente para cumplir algún objetivo.


Ingeniería de Sistemas La ingeniería de sistemas consiste en la

actividad de especificar, diseñar, implementar, validar, distribuir y mantener sistemas como un todo.

Los ingenieros de sistemas no sólo están relacionados con el software, sino también con el hardware y las interacciones del sistema con los usuarios y su entorno.


Características del Software El software se desarrolla, no se fabrica. El software no se descompone, se echa a

perder. Aunque la industria tiende a ensamblar

componentes, la mayoría del software es hecho a la medida.


Atributos de un buen software Mantenibilidad

El software debe poder evolucionar para cumplir con las necesidades de cambio de los clientes.

Confiabilidad El software debe ser fiable, seguro, no debe causar daños físicos o

económicos en el caso de una falla del sistema. Eficiencia

El software debe aprovechar al máximo los recursos del sistema. Usabilidad

El software debe ser fácil de utilizar.


Aplicaciones del Software Software de sistemas Software de tiempo real Software de gestión Software de ingeniería y científico Software empotrado Software de PC’s Software basado en Web Software de IA


Tarea Leer de Pressman la sección 1.4 Mitos del

Software y discutir en clase cada uno de los mitos presentados.


Unidad 2

Modelos de Proceso del Software


Proceso de Software Es un conjunto de actividades y

resultados asociados, que generan un producto de software, las cuales son llevadas a cabo por los ingenieros de software.


Actividades comunes a todo Proceso de Software

Especificación Diseño e implementación Validación Evolución

Distintos procesos organizan estas actividades de diferentes formas y las describen a diferente nivel de detalle.

Organizaciones diferentes utilizan procesos diferentes


Modelos de Proceso del software Es una descripción de un proceso del

software que se presenta desde una perspectiva particular. Es una abstracción de un proceso real.

Existe una gran variedad de modelos o paradigmas de desarrollo de software: Enfoque de Cascada Desarrollo Evolutivo Desarrollo Formal Desarrollo basado en la reutilización


Modelo de Cascada

Definición de requerimientos

Diseño de sistemas y de software

Implementación yPrueba de unidades

Integración yprueba del sistema

Operación ymantenimiento

Royce, 1970“Managing the development ofLarge software systems: ConceptsAnd techniques”IEEE Conference, Los AngelesAdoptado por el DoD


Modelo en “V”

Definición de requerimientos

Diseño de sistemas

Diseño de programas

Codificación

Pruebas de unidadY de integración

Pruebas de sistema

Pruebas deaceptación

Operación ymantenimiento


Desarrollo Evolutivo Modelo Construcción de prototipos

Bosquejo de ladescripción

Especificación

Desarrollo

Validación

Versión inicial

Versiones intermedias

Versión final

Versiones intermediasVersiones intermedias


Modelo Incremental

Bosquejo de los

requisitos

Definir incrementos

Diseñar la arquitectura

Diseñar incremento

Validarincremento

Integarincremento

Validarsistema

Sistema

finalOrigen del Extreme Programming (XP)

The management of software engineeringMills et al., 1980I BM Systems Journal

Embracing change with extreme programmingBeck, K. 1999IEEE Computer


Modelo en espiral

A spiral model of software development and enhancementBohem, 1988I EEE Computer


Tarea Hacer un ensayo explicando las ventajas y

desventajas de los modelos de proceso de software analizados en clase.


Tarea

Preparar una exposición sobre los siguientes temas: Agile Methods Scrum XP Crystal Test-Driven Design Agile Modeling

Referencia inicial:http://www.agilealliance.org/programs/roadmaps/RoadmapPresentación el miércoles 25 de agosto


CMM (Capability Maturity Model) Desarrollado por el SEI (Software Engineering

Institute) Es un modelo completo basado en un

conjunto de funciones de ingeniería del software que deberían de estar presentes conforme organizaciones alcanzan diferentes niveles de madurez de su proceso.


...CMM

El enfoque del SEI proporciona una medida de la efectividad global de las prácticas de la ingeniería del software de una compañía y establece 5 niveles de madurez del proceso.

Nivel 1: Inicial. Nivel 2: Repetible. Nivel 3: Definido. Nivel 4: Administrado. Nivel 5: Optimización.


Nivel 1: Inicial

El proceso se define ad hoc. Es caótico. El éxito depende del esfuerzo individual.


Nivel 2: Repetible

Se establecen los procesos de administración del proyecto para dar seguimiento a los costos, la planificación y la funcionalidad.

Se toman en cuenta experiencias anteriores para repetir las actividades necesarias en el proceso.


Nivel 3: Definido

Se documenta el proceso para las actividades de administración y de ingeniería.

Se estandariza e integra en un proceso para toda la organización.

Todos los proyectos utilizan una versión documentada y aprobada del proceso.


Nivel 4: Administrado

Se implementan métricas detalladas para los proyectos.

Se establecen estándares de calidad. Mediante la utilización de las métricas se

comprenden y se controlan cuantitativamente tanto los productos como el proceso.


Nivel 5: Optimización

El proceso se mejora continuamente mediante la retroalimentación cuantitativa del proceso, ideas y tecnologías innovadoras.


Auditores CMM

Requisitos: Haber participado en una evaluación en los dos

años anteriores a su solicitud de cursos. Cursar las asignaturas. Ser líder en una evaluación CMM a una

organización dentro de los dos años siguientes a los cursos, asesorado por un tutor certificado.

Obtener la aprobación del tutor.


Tarea

Investigar información sobre organizaciones de software con certificación CMM. Tamaño Tiempo requerido para lograr la certificación Costo


Unidad 3

El Proceso Unificado de Desarrollo (RUP)


El RUP

Rational Unified Process El Proceso Unificado es un proceso de software

genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.


Estructura del RUP


RUP y UML

El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par.


Características clave del RUP

Dirigido por casos de uso (use-case driven).

Centrado en la arquitectura (architecture-centric).

Iterativo e incremental.


Unidad 4

Administración de Proyectos


Exito en proyectos de software en 1994

Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified.

Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.

Resolution Type 3, or project impaired: The project is canceled at some point during the development cycle. Fuente: www.standishgroup.com


Exito en Proyectos de Software en 1998

26%

46%

28%Fracaso Total

Excedido (tiempo y/ocosto)Exitoso

Fuente: “Critical Succes Factors in Software Projects”Reel, J.S. IEEE Software mayo de 1999


Administración de proyectos de software Implica la planificación, supervisión y control

del personal, del proceso y de los eventos que ocurren mientras evoluciona el software, desde la fase preliminar hasta la implementación operacional.


Características de los proyectos de software El producto es intangible. No existen procesos de software estándar. Comúnmente los proyectos grandes son

“únicos”.


Las cuatro P's de la administración de proyectos Personal

El factor humano Producto

Objetivos y el ámbito del producto Proceso

Estructura de apoyo para la planeación Proyecto

Administración de la complejidad


Personal Sin duda el elemento más valioso en la

Ingeniería del Software ¿Quiénes participan en un proyecto de

software? Programadores Líder de proyecto Arquitectos de software Usuarios Analistas/Diseñadores Clientes Ingenieros de requerimientos Ingenieros de proceso Ingenieros de pruebas


...Personal

¿Cuáles son las características deseables de un líder de proyecto? Motivador Organizado Innovador Problem Solver


...Personal

¿Cómo se organiza el equipo de trabajo? Marilyn Mantei en “The effect of Programming

Team Structures on Programming Tasks”, 1981, sugiere tres tipos genéricos de organización: Centralizado Controlado (CC): El jefe del equipo se

encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical.


...Personal

Descentralizado Controlado (DC): Un jefe definido que coordina tareas específicas y jefes secundarios con responsabilidades sobre subtareas. La resolución de problemas es una actividad del grupo, la comunicación es horizontal y vertical.

Descentralizado Democrático (DD) o “Egoless”: No tiene un jefe permanente, se nombran de acuerdo a la tarea. La solución de problemas se hacen por consenso. La comunicación es horizontal.


...Personal

¿Qué factores se deben considerar cuando se estructura un equipo de software? Complejidad del proyecto (dificultad del problema,

tamaño del software) Tiempo de desarrollo. Modularidad. Calidad. Comunicación requerida.


...Personal

Discusión sobre ventajas y desventajas de cada tipo de organización.


...Personal

¿Cómo creamos un equipo de alto rendimiento? Según Constantine, L. en “Work Organization:

Paradigms for Project Management and Organization, 1993: Confianza entre los miembros del equipo. Distribución de habilidades de acuerdo al problema. Los inconformistas deben ser excluidos.


...Personal

¿Qué factores pueden contaminar el desempeño de un equipo? Según Jackman, M. en “Homeopathic Remedies

for Team Toxicity”, 1998: Atmósfera de trabajo frenética, malgastan energía y se

descentran de los objetivos Alta frustración causada por factores tecnológicos, del

negocio o personales que provocan fricción entre los miembros del equipo.


...Personal

Procedimientos coordinados pobremente o fragmentados o una definición pobre o impropiamente elegida del modelo de procesos que se convierte en un obstáculo a saltar.

Definición confusa de los papeles a desempeñar produciendo una falta de responsabilidad y la acusación correspondiente.

Continua y repetida exposición al fallo que conduce a una pérdida de confianza y una caída de la moral.


...Personal

¿Cómo evitamos las toxinas que afectan a los equipos de software?

¿Cómo coordinar las acciones de los miembros del equipo?


Tarea

Leer el capítulo 3 del Pressman 5ta. edición Realizar los problemas 3.1, 3.4, 3.6 al 3.11


Tareas de la Administración de Proyectos Estimación del tamaño del proyecto

LDC PF COCOMOII

Planificación temporal Barras de Actividad Red de actividades

Administración del Riesgo Supervisión y Control


Métricas para Estimación Se clasifican en dos:

Medidas relacionadas al tamaño Se relacionan con el tamaño de la salida de alguna

actividad. La métrica más común es Líneas de Código (LDC) Dependen del lenguaje de programación y en general

no es una buena medida para POO. Medidas relacionadas a la función


Medidas Relacionadas a la Función Son medidas que se relacionan con la

funcionalidad del software. Las más comunes son:

Puntos de Función (PF) Puntos de Objeto (PO)


Puntos de Función Es una medida de la funcionalidad entregada

por la aplicación. Es una medida indirecta, a diferencia de

LDC. Propuesta por primera vez en:

Albretch, A.J., “Measuring Application Development Productivity”, Proceedings IBM Application Development Symposium, Octubre 1979.

Consultar en www.ifpug.org versión 4.1


Cálculo de PFFactor de ponderación

Conteo Total (UFP)

=[ ]x10[ ]x7[ ]x5Número de interfaces externas

=[ ]x15[ ]x10[ ]x7Número de archivos

=[ ]x6[ ]x4[ ]x3Número de peticiones de usuario

=[ ]x7[ ]x5[ ]x4Número de salidas de usuario

=[ ]x6[ ]x4[ ]x3Número de entradas de usuario

ComplejoMedioSimpleCuentaParámetros de medición


...Cálculo de PF El UFP (Unadjusted Function Point count) se

multiplica por factores de complejidad del proyecto para obtener el PF final:

PF = UFP x [0.65 + 0.01 x (Fi)]


Fi

14. ¿El diseño facilita los cambios y la usabilidad?

13. ¿El diseño incluye soporte para múltiples instalaciones en diferentes orgs.

12. ¿El diseño incluye conversión e instalación?

11. ¿El diseño del código es reutilizable?

10. ¿Es complejo el procesamiento interno?

9. ¿Son complejas las entradas, salidas, archivos y peticiones?

8. ¿Se actualizan los archivos maestros de forma interactiva?

7. ¿Las entradas interactivas se harán en múltiples pantallas y operaciones?

6. ¿Requiere el sistema entradas de datos interactivas?

5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?

4. ¿Es crítico el rendimiento?

3. ¿Existen funciones de procesamiento distribuido?

2. ¿Se requiere comunicación de datos?

0-51. ¿Requiere el sistema copias de seguridad y de recuperación fiables?


Relación entre LDC y PF

12SQL16PowerBuilder32Visual Basic64C++90Pascal106FORTRAN106COBOL128C320Ensamblador

LDC/PF (media)Lenguaje de Programación

Jones, C. Estimating Software Costs, McGraw-Hill, 1998


Puntos de Objeto También es una medida indirecta del

software. NO es una medida de las clases necesarias

para construir la aplicación. Los elementos que toma en cuenta son:

Pantallas Informes (reportes) Componentes (o código en 3GL)


Cálculo de Puntos ObjetoPeso de la complejidad

Puntos Objeto

=[ ]x10Componente 3GL

=[ ]x8[ ]x5[ ]x2Informes

=[ ]x3[ ]x2[ ]x1Pantallas

ComplejoMedioSimpleTipo de Objeto

Bohem, B., “Anchoring de software process”, IEEE Software, julio 1996


Técnicas de Estimación de Costos

Establece que el trabajo se expande para llenar el tiempo disponible. El costo se determina más por los recursos disponibles que por los objetivos logrados.

Ley de Parkinson

Cuando se han completado proyectos del mismo dominio de la aplicación se estima en base a la experiencia.

Estimación por analogía

Se consultan expertos en las técnicas de desarrollo propuestas y el dominio de la aplicación. Cada uno estima el costo y se consensa después de varias iteraciones.

Opinión de expertos

Utiliza un modelo con información histórica de costos, relaciona una métrica con el costo del proyecto. Se estima la métrica y se predice el esfuerzo.

Modelado del algoritmo de costos


El modelo COCOMO Constructive Cost Model Es un modelo de estimación empírico desarrollado

por Bohem. Se obtuvo recolectando datos de varios proyectos

de software grandes. Como resultado del análisis de los datos se

obtuvieron fórmulas y tablas que se ajustan a las observaciones.

Es muy utilizado y ha tenido seguimiento desde su aparición en 1981.


COCOMO II Es el modelo más reciente Consta de estimación en tres niveles:

Construcción de propotipo inicial Se usa al inicio del proyecto

Diseño inicial Se aplica cuando se tienen la mayoría de los

requisitos y diseño preliminar Postarquitectónico

Se aplica cuando ya se tiene la arquitectura


COCOMO II Nivel Inicial PM = (PO x (1 - Reutilización))/PRODDonde:

PM = Esfuerzo Persona-MesPO = Puntos ObjetoReutilización = %reutilización/100PROD = 4, 7, 13, 25, 50 dependiendo de la experiencia y

capacidad de los desarrolladores y/o Madurez del proceso (Muy baja, baja, normal, alta, muy alta) dada en PO/mes


...COCOMO II Estimación de calendario

TC = 3 x PM(0.33+0.2*(B-1.01))

Para el nivel inicial: B=1

TC = 3 x PM(0.328)

TC está dada en meses.


Planificación Temporal Es la actividad que distribuye el esfuerzo

estimado a lo largo de la duración prevista del proyecto.

Evoluciona con el tiempo. “El proyecto se ha completado en un 90%”


Gráficas de Barras de Actividad


Red de Actividades


Administración del Riesgo Etapas

Identificación de riesgos Análisis de riesgos

Valorar las probabilidades y consecuencias Planeación de riesgos

Planes para evitar o minimizar el impacto Supervisión de riesgos

Valoración constante, revisión de planes de mitigación conforme se vaya presentando información del riesgo.


Ejemplos de Riesgos

NegocioCambio de tecnología

ProductoBajo desempeño de la herramienta CASE

Proyecto y productoSubestimación del tamaño

Proyecto y productoRetrasos en la especificación

Proyecto y productoCambio de requerimientos

ProyectoNo disponibilidad del hardware

ProyectoCambio de administración

ProyectoRotación de personalTipoRiesgo


Proceso de Administración del Riesgo

Identificación deRiesgos

Análisis deRiesgos

Planeación deRiesgos

Supervisión deRiesgos

Listado de Riesgos potenciales

Listado de prioriza-ción de riesgos

Anulación de Riesgos y planes de

contingencia

Valoración de Riesgos

Ingeniería del Software - sistemamid.com€¦ · Ingeniería del Software: un enfoque práctico....

Documents

Transcript of Ingeniería del Software - sistemamid.com€¦ · Ingeniería del Software: un enfoque práctico....