Ingeniería de Software

1

Ingeniería de Software

Mª Angélica Caro Gutiérrezhttp://www.face.ubiobio.cl/~mcaro/

[email protected]

Departamento deCiencias de la Computación y Tecnologías de Información

Universidad del Bío-BíoSede Chillán

Ingeniería Civil Informática UBB 2009

2/18Angélica Caro Ingeniería Civil Informática UBB 2009

Programa de la Asignatura

Descripción y ObjetivosContenidosMetodologíaEvaluaciónBibliografía Otros

2


Descripción y ObjetivosDescripción:

La Ingeniería de Software (ISw) es una disciplina que ofrece métodos y técnicas para especificar, desarrollar, administrar y mantener software (Sw) de calidad que resuelva problemas concretos. La construcción de software de calidad implica el reconocimiento, definición y aplicación de muchos elementos, que van desde la comprensión de lo que significa calidad en el Sw hasta la formalización de los medios para alcanzarla (actividades, métodos, herramientas y estándares, entre otros).Esta asignatura teórico/práctica busca la aplicación de todas las temáticas relevantes de la Ingeniería de Sw como disciplina, en el contexto de los proyectos de Sw y la gestión/dirección de éstos.


Descripción y Objetivos

Objetivo General:

Al finalizar el curso los alumnos deberán ser capaces de desarrollar/gestionar un proyecto de Sw de manera sistemática y eficiente para la obtención de un producto de calidad, aplicando elementos claves de la ISw

3


Descripción y Objetivos

Objetivos Específicos:

Comprender las principales áreas de la ISw.Gestionar un proyecto de Sw, que resuelva una problemática concreta, en el cual deberán:

Seleccionar un modelo de proceso de Sw y definir las actividades necesarias para un proceso de desarrollo de Swparticular.Aplicar técnicas de estimación, planificación, gestión de riesgos y de control de calidad del producto de Sw generado.

Incentivar soluciones, basadas en estándares de calidad, creativas e innovadoras.


Presentación


4


Contenidos

10Evolución del Software Unidad 4

80Total de horas

10Otros tópicos en Ingeniería del SwUnidad 5

20Métodos para la Ingeniería del SwUnidad 3

35Gestión de proyectos de desarrollo de software

Unidad 2

05IntroducciónUnidad 1 HORASUNIDADES


Presentación


5


MetodologíaLa metodología utilizada se basará en 3 estrategias: Clases teóricas, desarrollo de un proyecto de Sw y lectura/estudio personal.Mediante clases teóricas se introducirán los distintos conceptos y temas relevantes en ISw. Dichas clases incluirán la discusión y reflexión de los temas por parte de los alumnos; y, en algunas ocasiones, la entrega de documentos con el resultado de sus discusiones. Paralelamente los alumnos deberán llevar a cabo un proyecto de desarrollo Sw, el cual se realizará en varias etapas. En cada etapa del proyecto habrá documentos que cada grupo deberá ir entregando de acuerdo a fechas determinadas, tales documentos serán prerrequisito para la entrega final del documento del proyecto.


Presentación


6


Evaluación

Instrumentos de evaluación:

2 certámenes. A lo menos 2 controles de lectura y/o investigación y presentaciones orales. Proyecto de desarrollo, que incluye presentaciones orales, entrega de informes y entrega de un producto software.


Evaluación

Cálculo de la Nota Final:

Donde,NC= Certamen 1 * 40% + Certamen 2 * 40% + Controles * 20% NP = ((∑ Informei)/Cantidad de entregas+(∑ Presentaciónj) /Cantidad de Presentaciones) * 90% + Apreciación Profesora * 10% Si no se entrega uno de los informes= NCR

50%Nota de ProyectoNP

50%Nota de CátedraNC

PonderaciónDescripciónSigla

7


Presentación



Bibliografía

Básica:

PRESSMAN, R. 2005. Ingeniería del Software, un enfoque práctico. Editorial McGraw Hill. 6ta edición.PFLEEGER, S. L. 2002. Ingeniería de software, teoría y práctica. Pearson Education. 1ra Edición.SOMMERVILLE, I. 2002. Ingeniería de software. Editorial Pearson Educación, 6ta edición.

8


Bibliografía

Complementaria :

Braude, E., Ingeniería de Software: Una perspectiva orientada a objetos,2003, Alfaomega.Larman, C. 2002. Applying UML and Patterns. And Introduction to Object Oriented Analysis and Design and the Unified Process, 2da. edición. Prentice Hall.Booch, G., 1994. Análisis y Diseño Orientado a Objetos con Aplicaciones. Addison Wesley.


Presentación


9


Otros

Horario:

Clases TeóricasMartes: 9:40 a 11:50 hrs.

Clases Teórico/PrácticasJueves: 9:40 a 11:00 hrs.

Atención de Alumnos:Jueves: 15:00 a 17:00 hrs.


Otros

Medios de Comunicación:

PVA: http://pva.face.ubiobio.cl/pva/Correo electrónico: [email protected]éfono: 253411Personal: 2° piso edificio FACE (previo acuerdo)

1



[email protected]





Unidad 1: Introducción

Conceptos generalesSoftware e Ingeniería de SoftwareNormas y EstándaresCiclo de vida del Software

2


¿Cuál es la relevancia actual del software (SW) en nuestras vidas?

¿Cómo se puede relacionar un microondas con el SW, en el contexto de nuestras vidas?

Menciona algunas situaciones en las cuales te relacionas con SW Indica aspectos positivos de estas experiencias y aspectos negativos de ellas como usuario

Algunas cuestiones…


¿Qué es el software?

Producto creado por los ingenieros de software con el fin de resolver un problema concreto, que luego se debe mantener a largo plazo.

El software se forma por:

Las instrucciones (programas)

Estructuras de datos

Documentación (operación y uso) Programa ≠ Software

El Software

3


Otras definiciones…“Programas de computadoras y la documentación asociada. Los productos de software se pueden desarrollar para un cliente en particular o para un mercado en general”

“Producto que diseñan y construyen los ingenieros del software. Esto abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura, documentos que comprenden formularios virtuales e impresos y datos que combinan números y texto y también incluyen representaciones de información de audio, vídeo e imágenes”

Sommerville

Pressman

El Software


¿Cuál es el actual rol del Software?

Producto, ofrece la potencia de cómputo que incorpora el hardware o más ampliamente una red de computadoras que es accesible por hardware local.

Vehículo para entregar un producto, el software actúa como base del control del computador (sistema operativo) y la creación y control de otros programas (herramientas de software y entornos).

El software entrega el producto más importante de nuestro tiempo: Información

El Software

4


Desde años 50-60:Hardware sufrió continuos cambios, el software se consideraba como adicional.

Desarrollo sin planificación.

Orientación por lotes (procesamiento Batch)

Software a medida para cada aplicación.

Se desarrollaba y era utilizado por la misma persona.

Diseño realizado en la mente de alguien.

Documentación escasa, poco formal o inexistente.

Desarrollo de Sw: Evolución


Desde años 60- finales 70:Multiprogramación y multiusuario.

Técnicas interactivas (hombre-máquina).

Sistemas de tiempo real.

Sistema de gestión de bases de datos.

Software como producto, llegada de las casas de software.

Desarrollado para una amplia distribución en un mercado multidisciplinario.

¿Crisis del Software?


5


Desde años 80Uso de microprocesadores y computadoras personales.Hardware de bajo costo.Sistemas de procesamientos distribuidos.Redes de área local y global.Creciente demanda de acceso instantáneo a los datos.Tecnologías orientadas a los objetos.Sistemas expertos.Redes neuronales artificiales (reconocimiento de formas y habilidades de procesamiento de información).Computación paralela.



¿Interrogantes asociadas a la construcción de Software?

¿Porqué tarda tanto la construcción del software terminado?¿Porqué son tan altos los costos del desarrollo de software? ¿Porqué es imposible encontrar todos los errores en el software antes de entregarlo a los clientes? ¿Porqué se gastan tanto tiempo y esfuerzo en el mantenimiento de los programas complejos? ¿Porqué es difícil medir el progreso al desarrollar y darle mantenimiento al software?

Construcción del Sw

6


El trabajo de un ingenieroConstruir productos de alta calidad bajo restricciones de tiempo y dineroUtilizar e integrar componentes existentes en el mercadoEnfrentar problemas pobremente definidosAceptar soluciones parcialesEvaluación de posibles soluciones en base a métodos empíricos

Esto es igual ya sea se trate de construir un avión de pasajeros, un puente o un sistema de reserva de pasajes de avión


El software es complejo

Algunas características:Muchas funcionalidadesDebe satisfacer diversos objetivosMuchos participantesMuy difícil de entender por una sola personaEtc.

7


Lo más difícil: manejar cambios

Es muy difícil generar un conjunto de requerimientos correctos desde el comienzoCambios en el ambiente en que operará el softwareCambios tecnológicos

En el caso del software no es posible congelar los requerimientos ya que eso llevaría a completar un sistema o producto innecesario


8



Es una disciplina de la ingeniería que se preocupa de todos los aspectos de la producción de softwareLos ingenieros de software deben adoptar un enfoque sistemático y organizado en su trabajo, y usar las herramientas y técnicas apropiadas dependiendo del problema a resolver, las restricciones de desarrollo y los recursos disponibles




9


Software de sistemas Colección de programas escritos para servir a otros programas.Ejemplos: Editores, compiladores, s. operativo, controladores, procesadores de telecomunicaciones

Software de aplicaciónQue resuelve una necesidad de negocio específica, facilitando las operaciones de negocio y toma de decisiones.


I. de Software, Ideas y Conceptos

Categorías de Sw


Software científico y de ingenieríaDesarrollado para aplicarse en áreas como astronomía, sismología, vulcanología, espacial, etc.

Software empotrado o incrustado Reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo.Ejecuta funciones limitadas (control de las teclas de un microondas) y también funciones significativas y con capacidad de control (funciones digitales en un automóvil tales como control de gasolina,sistema de frenado, temperatura, etc.)

Categorías de Sw

10


Software de línea de productosDesarrollado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes.

Software basadas en Web En su forma más simple, como un conjunto de archivos de hipertexto ligados, que presentan información y gráficas.Hasta aplicaciones de comercio electrónico y B2B, con ambientes computacionales más sofisticados, integradas a bases de datos corporativas y aplicaciones de negocios.

Categorías de Sw


Software de inteligencia artificialHace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo.

Ultimas tendencias:Software computación ubicua. Software de sistema y de aplicación que permita que dispositivos pequeños, computadores personales y sistemas de empresas se comuniquen a través de grandes redes. Alimentación del WWWCódigo abierto

Categorías de Sw

11


¿Qué la motiva?



Planificación y estimación de costos son frecuentemente muy imprecisas

Se ha errado en la planificación en meses o años.La productividad de la comunidad del Software no corresponde con la demanda de sus servicios.Se ha hecho muy poco para mejorar la productividad de los trabajadores del Software.La calidad del Software no llega a ser a veces ni aceptable.Insatisfacción y falta de confianza en los clientes, el Swno satisface sus requerimientos.

Problemas del desarrollo de Sw

12


Informe CHAOS (Standish Group) 1994….Base de 175.000 proyectos por US$250.000 millones31% cancelado antes de tiempo 53% tenían defectos Sólo 16% completados a tiempo En promedio los proyectos costaron 189% más de lo presupuestado

Pero hay algunos detractores…

2000

23%49%

28%

43%



Dificultad v/s EstimaciónNo tenemos tiempo de recoger datos sobre el proceso de desarrollo del Software.Sin datos históricos como guía, la estimación no ha sido buena y los resultados previstos muy pobres.Sin una indicación sólida de la productividad, no podemos evaluar con precisión la eficacia de las nuevas herramientas, técnicas o estándares.


13


Dificultad v/s Satisfacción:La insatisfacción del cliente con el sistema “terminado” se produce demasiado frecuentemente.Los proyectos de desarrollo del software se realizan frecuentemente con sólo una vaga indicación de los requisitos del cliente.Normalmente, la comunicación entre el cliente y el que desarrolla el software es muy escasa.



Dificultad v/s Calidad:La calidad del Software es normalmente cuestionable.Hemos empezado a comprender recientemente la importancia de la prueba sistemática y técnicamente completa del software.Están comenzando a emerger conceptos cuantitativos sólidos sobre la fiabilidad del software y las garantías de calidad.


14


Dificultad v/s Mantención:El software existente puede ser muy difícil de mantener.La tarea de mantenimiento del software se lleva la mayor parte de todo el dinero invertido en el software.El mantenimiento no se ha considerado un criterio importante en la aceptación del software.



La clave o solución:Todas las dificultades descritas se pueden corregir.Se debe dar un enfoque de ingeniería al desarrollo de software.Junto con la mejora continua de las técnicas y de las herramientas.


15


Mitos de Gestión

Mitos del Clientes

Mitos de los Desarrolladores

Mitos del Sw


Mitos de Gestión:

Los administradores con responsabilidades sobre el software a menudo están:

(1) bajo la presión de cumplir los presupuestos, (2) hacer que no se retrase el proyecto y, (3) mejorar la calidad.

Estos los hace aferrarse a ciertos mitos con la creencia que esto disminuirá la presión, aunque sea temporalmente.

Mitos del Sw

16


Mitos de Gestión:

Se cuenta con los estándares y procedimientos para construir Software. ¿Esto proporcionará a mi gente todo lo que necesita saber?Si estamos atrasados en los plazos es posible contratar más programadores para así terminar a tiempo. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa empresa lo construya.

Mitos del Sw


Mitos del Cliente:

El cliente cree en mitos acerca del porque tanto los profesionales como administradores del software hacen muy poco para corregir la desinformación.

Los mitos conducen a expectativas falsas (del cliente) y en definitiva a insatisfacción con el desarrollador.

Mitos del Sw

17


Mitos del Cliente:

Un enunciado general de los objetivos es suficiente para comenzar a escribir los programas; los detalles se pueden afinar más adelante.Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.

Mitos del Sw


Mitos del Desarrollador:

Los mitos que aún subsisten entre los desarrolladores han permanecido a través de 50 años de “cultura de programación”.

Durante los primeros años la programación era vista como un arte, por esto es que las viejas formas y actitudes tardan en desaparecer.

Mitos del Sw

18


Mitos del Desarrollador:

Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo ha terminado.Hasta que no tengo el programa “ejecutándose”, realmente no tengo forma de comprobar su calidad. El único producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa funcionado.La ingeniería de SW obligará a emprender la creación de una documentación voluminosa e innecesaria y de manera invariable hará más lento el proceso.

Mitos del Sw




19


Ley de las aleaciones de metales preciosos

Ley de las aleaciones de metales preciosos

Emisiones gases de escape, vehículos a motor

Emisiones gases de escape, vehículos a motorRequisitos para los

focos de motocicletas

Requisitos para los focos de motocicletas

Requisitos de seguridad de los neumáticos y llantas de motocicletas

Requisitos de seguridad de los neumáticos y llantas de motocicletas

Cascos de protección para usuarios de ciclomotores

Cascos de protección para usuarios de ciclomotores

Generalidades de neumáticos, llantas y válvulas para motocicletas

Generalidades de neumáticos, llantas y válvulas para motocicletas

Ruido emitido por ciclomotores en movimiento

Ruido emitido por ciclomotores en movimiento

IEEE – Institute ofElectrical and ElectronicsEngineers

AENOR

INN

http://www.iso.org

Imagen facilitada por el Dr. Felix García

La Normalización


Investigación

En grupos de 2 personas

Averiguar qué normas o estándares se relacionan con la construcción de Sw y quéaspecto de esta abordan

Normas y Estándares

20


Pressman Roger . 2005. “Ingeniería del Software, un enfoque práctico”. Editorial McGraw Hill. 6ta edición.

PFLEEGER, S. L. 2002. Ingeniería de software, teoría y práctica. Pearson Education. 1ra Edición.

SOMMERVILLE, I. 2002. Ingeniería de software. Editorial Pearson Educación, 6ta edición.

Bibliografía

1



[email protected]





Unidad 2: Gestión de proyectos de Sw

Modelos del Proceso del softwarePlanificación de proyectos de softwareMétodos de estimaciónEstimación de costo/precioMétricas de proyectosAnálisis y gestión de riesgosSeguimiento de proyectosGarantía de calidad de software

2


Contexto:

El desarrollo de un sistema de Swestá enmarcado por los recursos, eltiempo y un conjunto de requerimientos. Para lograrlo debe existir una planeacióny un seguimiento de ésta.Una planeación está conformada por actividades, recursos y tiempoEsas actividades se llevan a cabo dentro de un proceso definido

Modelos de proceso de Sw


Proceso de construcción de Sw:

“El conjunto completo de actividades de ingeniería de software necesarias para transformar los requerimientos del usuario en software.” [Humphrey]


3


Unidad 2: Gestión de Proy. de SW

Modelos de proceso de SwIngeniería del Sw, una tecnología estratificada:

Cómo construir técnicamente el software(análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento)

La base de cualquier ingeniería es un compromiso con la calidad

Define un marco de trabajo para las áreas clave de procesoLas áreas forman la base del control de gestión y establecen el contexto donde se aplican los métodos técnicos, se obtienen productos de trabajo, se establecen los fundamentos, se asegura la calidad y el cambio se gestiona adecuadamente

Proporcionan un enfoque automático o semi-automático para el proceso y los métodos. Ingeniería de software asistida por computadoras (CASE)

Un Enfoque de Calidad

Proceso

Métodos

Herramientas


Tareas

Productos

Puntos de aseguramiento de la calidad

Conjunto de tareas (n)

Actividades del marco de trabajo (n)

Marco de trabajo del proceso

PROCESO DEL SOFTWARE

Actividades paraguas

Fundamentos del proyecto

Un marco de trabajo establece la base para un proceso de Sw completo, ya que establece un número pequeño de actividades aplicables a todos los proyectos de Sw, sin importar su tamaño o complejidad. Además abarca un conjunto de actividades “paraguas” aplicables en todo el proceso del Sw.


4


Implícita o Explícitamente todos los modelos de proceso cuentan por lo menos con las siguientes actividades:


Representa todas las actividadesy artefactos (productos

intermedios) necesarios para desarrollar una aplicación

Cada modelo determina el proceso que se sigue para construir, entregar y hacer

evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema.


Marco genérico del proceso (Pressman, 2005)

Comunicación

Planeación

Modelado

Construcción

Despliegue

Esta actividad implica una intensa colaboración y comu-nicación con los clientes. Abarca también la investigación de requisitos y otras actividades relacionadasEstablece un plan de trabajo con las tareas técnicas, riesgos probables, recursos que serán requeridos, productos que se generarán y un programa de trabajo

Comprende la la creación de modelos que permitan al desarrollador y al cliente entender mejor los requi-sitos del Sw y el diseño que logrará satisfacerlos.

Combina la generación del código y la realización de las pruebas necesarias para descubrir errores en el código

Entrega del Sw al cliente (como una entidad completa o incremento completo), este evalúa el producto recibido y proporciona información basada en su evaluación


5


Por ejemplo:Modelado

Análisis Diseño

Investigaciónelaboraciónnegociaciónespecificaciónvalidación requisitos

Diseño de datosDiseño arquitectónicodiseño de interfazdiseño de componentes

Modelo de análisiso especificación de requisitos

Modelo de de diseño o especificación de diseño

actividad

Acciones de ISw

Tareas de trabajo

El conjunto de tareas a realizar debe ser el quemejor se ajuste a lasnecesidades del proyecto y características del equipo



Un conjunto de tareas define el trabajo real que debe realizarse para cumplir los objetivos de una acción de Sw, por ejemplo:

Objetivo: entender quédesean los distintos clientes del Sw que se va a desarrollar

Actividad de Comunicación

Acción de recopilación de requisitos

Conjunto de Tareas (proy. pequeño)

1. Hacer una lista de los clientes del proyecto

2. Invitar a todos los clientes a una reunión

3. Pedir a cada cliente una lista con características y funciones requeridas

4. Establecer un debate sobre los requisitos y elaborar una lista final

5. Priorizar los requisitos

6. Advertir las áreas de incertidumbre


6


Actividades “paraguas”, enfocadas a la gestión, rastreo y control del proyecto. (Pressman, 2005)

Seguimiento y control del proyecto de Sw. Permite que el equipo Sw evalúe el progreso comparándolo con el plan del proyecto y asítomar las acciones necesarias para mantener el plan.

Gestión del riesgo. Evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto

Aseguramiento de la calidad del Sw. Define y conduce las actividades requeridas para asegurar la calidad del Sw

Revisiones técnicas formales. Evalúa los productos del trabajo para descubrir y eliminar los errores antes que se propaguen a la siguiente acción o actividad.



Actividades “paraguas” (Pressman, 2005)

Medición. Define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar un Sw que satisfaga las necesidades del cliente.

Gestión de la configuración del software. Maneja los efectos del cambio a través del proceso del Sw

Gestión de la reutilización. Define los criterios para la reutilización de productos del trabajo y establece mecanismos para la creación de componentes reutilizables.

Preparación y producción del producto de trabajo. Actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas


7


Resumiendo (1/2):

Propuestos con la idea de ordenar el desarrollo de Sw.

Definen un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para desarrollar Sw de calidad.

Cada organización a través de los ing. de Sw y gerentes adaptan estos modelos a sus necesidades



Resumiendo (2/2):

Proporcionan estabilidad, control y organización a una actividad que si no se controla puede volverse caótica.

Conducen a un equipo de Sw a través de un conjunto de actividades que se organizan en un flujo de proceso que puede ser lineal, incremental o evolutivo.


8


¿Cómo estar seguros de que el proceso de Sw se ha hecho correctamente ?

Usando mecanismos para la evaluación del proceso de Sw que permita a las organizaciones determinar la “madurez” de sus respectivos procesos.

Sin embargo, los mejores indicadores de la eficacia del proceso que se utiliza son la calidad, el tiempo de entrega y la viabilidad a largo plazo del producto que se construye.



Aunque un proceso sea prescriptivo, no se debe asumir que éste es estático.

Los modelos prescriptivos se deben adaptar a las personas, al problema y al proyecto

Un modelo prescriptivo del proceso llena el marco de trabajo con conjuntos de tareas explícitas para

las acciones de la ingeniería de software


9



CascadaIterativo IncrementalDRAEvolutivosProceso UnificadoOtros


Modelo Cascadaciclo de vida clásico, lineal, lineal secuencial o básico.

Royce, 1970

10


Características :Cada fase empieza cuando se ha terminado la fase anterior

Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa

Ayuda a prevenir que se sobrepasen las fechas de entrega y los costos esperados

Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto

Este modelo es apropiado cuando los requerimientos están muy definidos y son razonablemente estables. (adaptaciones, mejorías, algunos proyectos nuevos)

Modelo Cascada


Comunicación Inicio del proyecto recopilación de requisitos

Planeación Estimación itinerario seguimiento

Modelado análisis diseño Construcción

código prueba

Despliegue entrega soporte retroalimentación

En su propuesta Pressman hace notar que a pesar que el modelo original propuesto por Royce propone “ciclos de

retroalimentación”, en la práctica la mayoría de las organizaciones que lo aplica lo trata como si fuera

estrictamente lineal

Modelo Cascada, Pressman

11


Operación y Mantenimiento

Integración y prueba del sistema

Implementación y prueba de unidades

Diseño de sistemas y software

Definición de Requerimientos

Sommerville afirma que en la práctica estas etapas se traslapan y

proporcionan información a las otras. El proceso del software no es un proceso lineal simple e implica realizar iteraciones, pero estas son muy costosas y requieren rehacer

trabajo.

Modelo Cascada, Sommerville


Fácil entendimiento e implementación

Ampliamente utilizado y conocido ( En teoría )

Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar

Identifica entregables e hitos.

Orientado a documentos.

Funciona bien en productos maduros y equipos débiles

Modelo Cascada, Ventajas

12


Los proyectos reales raras veces siguen el modelo secuencial propuesto. Como resultado, los cambios pueden causar confusión cuando el equipo de proyecto comienza.

A menudo es difícil que el cliente exponga explícitamente todos los requisitos. Este modelo lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.

El cliente debe tener paciencia. Una versión del producto final no estará disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el producto.

Dificultar para integrar administración del riesgo

Modelo Cascada, Desventajas




13


...

Combina elemen-tos del modelo en cascada con la filosofía iterativa de la construcción de prototipos

Se aplican secuencias lineales de forma escalonada mientras progresa el calendario

Modelo Incremental


...Características (1/2)

Cuando se utiliza este modelo, el primer incremento a menudo es un producto esencial, es decir, se afrontan los requisitos básicos pero quedan sin extraer muchas funciones complementarias (conocidas o no).

El cliente utiliza el producto esencial y como resultado de uso o evaluación se desarrolla un plan para el incremento siguiente.

El proceso se repite hasta elaborar el producto completo. Se diferencia de la construcción de prototipos en que en cada incremento se centra en entregar un producto operacional.

Los primeros incrementos son versiones incompletas, pero que proporcionan al usuario la funcionalidad que precisa, y una plataforma para la evaluación.

Modelo Incremental

14


...Características (2/2)

Corrige la necesidad de una secuencia no lineal de pasos de desarrollo y combina elementos del modelo de cascada aplicados en forma iterativa

El sistema se crea añadiendo componentes funcionales incrementos

El sistema no se ve como una entidad monolítica con una fecha fija de entrega, sino que es una integración de resultados sucesivos obtenidos después de cada iteración

Modelo Incremental


...Se ajusta a entornos de alta incertidumbre

Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia

El usuario se involucra más

Mayor retorno de la inversión

Modelo Incremental, Ventajas

15


Difícil de evaluar el costo total

Requiere gestores experimentados

Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo

Los errores en los requisitos se detectan tarde y su corrección resulta costosa

Modelo Incremental, Desventajas




16


Características (1/2)Desarrollo rápido de aplicaciones, en inglés RAD (RapidApplication Development).

Adaptación a alta velocidad del modelo en cascada, logrando el desarrollo rápido mediante un enfoque de construcción basado en componentes

Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo cree un “sistema completamente funcional” dentro de un periodo muy corto 60-90 días.

Varios equipos de desarrollo trabajan en paralelo

La construcción considera el empleo de componentes existentes.

Modelo DRA


Una secuencia de etapas del DRA podría ser:

Modelado de gestión

Modelado de datos

Modelado de proceso

Generación de aplicaciones

Prueba de entregas

Modelo DRA

17


Comunicación

Planeación

Despliegue integración entrega retroalimentación

Modelado del negocio de los datos del proceso

Construcción reutilización de componentes generación de código automático pruebas

Equipo # 1

Equipo # 2





(Pressman, 2005)

Equipo # n

60-90 días

Modelo DRA


Tiempos cortos de Desarrollo

El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear Sw con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Como el proceso DRA enfatiza la reutilización, y esto reduce tiempo de pruebas. Aunque se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

Modelo DRA, Ventajas

18


Necesita un alto número de recursos humanos, para crear el número correcto de equipos DRA.

Se requiere a desarrolladores y clientes comprometidos con las actividades rápidas.

Si un sistema no se puede modular apropiadamente, la construcción de componentes será problemática.

No es apropiada cuando los riesgos técnicos son altos (una nueva aplicación que usa muchas tecnologías nuevas).

Modelo DRA, Desventajas





Bibliografía

1



[email protected]







2


...

Combina elemen-tos del modelo en cascada con la filosofía iterativa de la construcción de prototipos

Se aplican secuencias lineales de forma escalonada mientras progresa el calendario

Modelo Incremental


Características (1/2)Cuando se utiliza este modelo, el primer incremento a menudo es un producto esencial, es decir, se afrontan los requisitos básicos pero quedan sin extraer muchas funciones complementarias (conocidas o no).

El cliente utiliza el producto esencial y como resultado de uso o evaluación se desarrolla un plan para el incremento siguiente.

El proceso se repite hasta elaborar el producto completo. Se diferencia de la construcción de prototipos en que en cada incremento se centra en entregar un producto operacional.

Los primeros incrementos son versiones incompletas, pero que proporcionan al usuario la funcionalidad que precisa, y una plataforma para la evaluación.

Modelo Incremental

3


Características (2/2)Corrige la necesidad de una secuencia no lineal de pasos de desarrollo y combina elementos del modelo de cascada aplicados en forma iterativa

El sistema se crea añadiendo componentes funcionales incrementos

El sistema no se ve como una entidad monolítica con una fecha fija de entrega, sino que es una integración de resultados sucesivos obtenidos después de cada iteración

Modelo Incremental


Se ajusta a entornos de alta incertidumbre

Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia

El usuario se involucra más

Mayor retorno de la inversión

Modelo Incremental, Ventajas

4


Difícil de evaluar el costo total

Requiere gestores experimentados

Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo

Los errores en los requisitos se detectan tarde y su corrección resulta costosa

Modelo Incremental, Desventajas




5


Características (1/2)Desarrollo rápido de aplicaciones, en inglés RAD (RapidApplication Development).

Adaptación a alta velocidad del modelo en cascada, logrando el desarrollo rápido mediante un enfoque de construcción basado en componentes

Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo cree un “sistema completamente funcional” dentro de un periodo muy corto 60-90 días.

Varios equipos de desarrollo trabajan en paralelo

La construcción considera el empleo de componentes existentes.

Modelo DRA


Una secuencia de etapas del DRA podría ser:

Modelado de gestión

Modelado de datos

Modelado de proceso

Generación de aplicaciones

Prueba de entregas

Modelo DRA

6


Comunicación

Planeación

Despliegue integración entrega retroalimentación



Equipo # 1

Equipo # 2





(Pressman, 2005)

Equipo # n

60-90 días

Modelo DRA


Tiempos cortos de Desarrollo

El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear Sw con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

El proceso DRA enfatiza la reutilización, y esto reduce tiempo de pruebas. Aunque se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

Modelo DRA, Ventajas

7


Necesita un alto número de recursos humanos, para crear el número correcto de equipos DRA.

Se requiere a desarrolladores y clientes comprometidos con las actividades rápidas.

Si un sistema no se puede modular apropiadamente, la construcción de componentes será problemática.

No es apropiada cuando los riesgos técnicos son altos (una nueva aplicación que usa muchas tecnologías nuevas).

Modelo DRA, Desventajas




8


El Sw, como otro tipo de sistemas, evoluciona en el tiempo.

Los requisitos de los negocios y productos a menudo cambian conforme se realiza el desarrollo….

Se tiene claro un conjunto de requisitos del producto o sistema principal, pero todavía se deben definir los detalles de las extensiones o del producto o sistemas.

Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de Swdesarrollen versiones cada vez más completas del Sw, es decir permiten que el Sw evolucione con el tiempo.

Modelo Evolutivos


Modelos Evolutivos

Algunos modelos evolutivos:Modelo de prototipos Modelo EspiralModelo Espiral WinWinModelo Concurrente

9


Normalmente cliente define conjunto de objetivos generales; no identifica requisitos detallados de entrada, proceso o salida.

El responsable del desarrollo puede no estar seguro de la eficiencia de un algoritmo o de la adaptabilidad de un sistema operativo o de la forma en que debiera tomarse la interacción hombre - máquina.

Cuando el cliente tiene una necesidad legitima, pero estádesorientado sobre los detalles, el primer paso es desarrollar un prototipo

Ayuda al ingeniero y al cliente a entender mejor cuál seráel resultado de la construcción cuando los requisitos estén satisfechos.

Modelo EvolutivosConstrucción de Prototipos


Plan rápido

Modelado Diseño rápido

Construcción del prototipo

Desarrollo Entrega y retroalimentación

Comunicación

Definición de objetivos globales, identificación de requisitos conocidos y áreas que requieren más definición

Centrado en aquellos aspectos del Sw que serán visibles al usuario final o cliente

El prototipo es evaluado por el usuario y con la retroalimentación se refinan los requisitos

Desarrollo del Sw, a veces desechando el prototipo (Brooks)


10


Paradigma de construcción de Prototipos:Escuchar al cliente

Construir/revisar maqueta

Probar maqueta

Los prototipos tienen una doble función:El cliente ve el producto y refina sus requisitos

El desarrollador comprende mejor lo que necesita hacer



Tipos de Prototipado:Prototipado rápido: No modifica el ciclo básico y es usado básicamente para Prototipo de la interfaz de usuario y Prototipo del rendimiento

Prototipado evolutivo: Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema

Prototipado Operacional: Mezcla de los dos anteriores


11


Prototipado Operacional:En algunos sistemas ni el prototipado rápido ni el evolutivo por sí solos son aceptables porque los requisitos son:

Críticos al diseño y bien entendidosNo críticos al diseño y pobremente entendidosDesconocidos




12


Desventajas:El cliente ve lo que parece una versión de trabajo y desconoce que con la construcción acelerada no se hizo consideraciones de la calidad global del software o de las facilidades mantenimiento. Es difícil explicar que el prototipo no es el producto final

El desarrollador hace compromisos para una implementación rápida. Se puede utilizar un lenguaje o sistema operativo inadecuado sólo porque estádisponible o porque se conoce.

El cliente y el desarrollador debieran estar claros que idealmente el prototipo debiera servir para identificar requisitos



Modelos Evolutivos


13


Combina la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.

El Sw se desarrolla en una serie de versiones incrementales.

Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo.

Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

Este modelo se puede adaptar y aplicar a través del ciclo de vida completo, desde el desarrollo del concepto hasta el mantenimiento

Modelo Espiral (Boehm, 1988)


Cada ciclo empieza identificando:Los objetivos de la porción correspondienteLas alternativasRestricciones

Durante la primera vuelta alrededor del espiral se definen los objetivos, las alternativas, restricciones y se identifican los riesgos.

Se formula una estrategia efectiva para resolver las fuentes de riesgos (simulación, prototipado, etc.)

Se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos.

Modelo EspiralFuncionamiento (1/2)

14


Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente.

El cliente evalúa el trabajo de ingeniería y sugiere modificaciones.

En base a los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo.

En cada bucle del espiral, la culminación del análisis de riesgo resulta en una decisión de “seguir o no seguir”.

Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto.



Plan de Requisitos

Plan del Ciclo de Vida

Plan deDesarrollo

Plan deIntegracióny Pruebas

Planificar lasfases siguientes

Determinarobjetivos,alternativas,restricciones

Evaluar alternativas,identificar y resolverlos riesgosAnálisis

de RiesgosAnálisis

Análisis

Análisis de

de Riesgos

de Riesgos

Riesgos Prototipo 1

Prototipo 2Prototipo 3

PrototipoOperativo

Concepto deOperación Requisitos

Sw

Validación deRequisitos

DiseñoProductoSw

V & V deldiseño

Simulaciones, modelos, benchmarks

Diseñodetallado

CódigoPruebasunitarias

Integracióny pruebaPrueba de

aceptaciónImple-menta-ción

Desarrollar, Verificar elproducto del siguiente nivel


15


Permite acomodar otros modelos

Incorpora objetivos de calidad y gestión de riesgos

Elimina errores y alternativas no atractivas al comienzo

Permite iteraciones, vuelta atrás y finalizaciones rápidas

Puede permanecer operativo hasta que el Sw se retire

Es un enfoque realista para sistemas a gran escala

Es difícil de adaptar a los contratos

Modelo EspiralCaracterísticas esenciales


Diferencias con los métodos tradicionales:

Existe un reconocimiento explícito de las diferentes alternativas para alcanzar los objetivos de un proyecto

La identificación de riesgos asociados con cada una de las alternativas

La división de los proyectos en ciclos

El modelo se adapta a cualquier tipo de actividad

Es posible incorporar otros modelos como parte de él.


16





Bibliografía

1



[email protected]





Modelos Evolutivos


2


Combina la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.

El Sw se desarrolla en una serie de versiones incrementales.

Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo.

Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

Este modelo se puede adaptar y aplicar a través del ciclo de vida completo, desde el desarrollo del concepto hasta el mantenimiento



Cada ciclo empieza identificando:Los objetivos de la porción correspondienteLas alternativasRestricciones

Durante la primera vuelta alrededor del espiral se definen los objetivos, las alternativas, restricciones y se identifican los riesgos.

Se formula una estrategia efectiva para resolver las fuentes de riesgos (simulación, prototipado, etc.)

Se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos.


3


Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente.

El cliente evalúa el trabajo de ingeniería y sugiere modificaciones.

En base a los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo.

En cada bucle del espiral, la culminación del análisis de riesgo resulta en una decisión de “seguir o no seguir”.

Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto.



Plan de Requisitos

Plan del Ciclo de Vida

Plan deDesarrollo

Plan deIntegracióny Pruebas

Planificar lasfases siguientes

Determinarobjetivos,alternativas,restricciones

Evaluar alternativas,identificar y resolverlos riesgosAnálisis

de RiesgosAnálisis

Análisis

Análisis de

de Riesgos

de Riesgos

Riesgos Prototipo 1

Prototipo 2Prototipo 3

PrototipoOperativo

Concepto deOperación Requisitos

Sw

Validación deRequisitos

DiseñoProductoSw

V & V deldiseño

Simulaciones, modelos, benchmarks

Diseñodetallado

CódigoPruebasunitarias

Integracióny pruebaPrueba de

aceptaciónImple-menta-ción

Desarrollar, Verificar elproducto del siguiente nivel


4


Permite acomodar otros modelos

Incorpora objetivos de calidad y gestión de riesgos

Elimina errores y alternativas no atractivas al comienzo

Permite iteraciones, vuelta atrás y finalizaciones rápidas

Puede permanecer operativo hasta que el Sw se retire

Es un enfoque realista para sistemas a gran escala

Es difícil de adaptar a los contratos



Diferencias con los métodos tradicionales:

Existe un reconocimiento explícito de las diferentes alternativas para alcanzar los objetivos de un proyecto

La identificación de riesgos asociados con cada una de las alternativas

La división de los proyectos en ciclos

El modelo se adapta a cualquier tipo de actividad

Es posible incorporar otros modelos como parte de él.


5


Modelos Evolutivos



Fue propuesto por Boehm (1998)

Se concentra en resolver el problema de negociación entre cliente y desarrollador

El cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.

Victoria - Victoria

Modelo Espiral Win Win

6


Este modelo define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente, se definen las siguientes actividades:

Identificación del sistema o subsistemas claves de los “directivos”

Determinación de las “condiciones de victoria” para los directivos

Negociación de las condiciones de “victoria” de los directivos para compatibilizarlas con las condiciones de “victoria” de los demás afectados (incluyendo el equipo del proyecto de software)



2. Identificar las condiciones de victoria de los directivos

3a. Reunir las condiciones de victoria

3b. Establecer los objetivos, restricciones y alternativas del siguiente nivel

4. Evaluar las alternativas del producto y del proceso y resolución de riegos

1. Identificar el siguiente nivel para los directivos

5. Definir el siguiente nivel del producto y del proceso incluyendo particiones

6. Validar las definiciones del producto y del proceso


7


Puntos de fijación:En cada paso evolutivo del proceso se consideran puntos de fijación.

Corresponden a una combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral

Son hitos dentro del proceso que representan tres visiones diferentes del progreso mientras el proyecto recorre el espiral.



Visiones asociadas a los puntos de fijación:(1) Objetivos del ciclo de vida: define un conjunto de objetivos para cada actividad principal de ingeniería de software (por ejemplo: un conjunto de objetivos asociados a la definición de los requisitos del producto/sistema del más alto nivel).

(2) Arquitectura del ciclo de vida: establece los objetivos que se deben conocer mientras se define la arquitectura del software y del sistema (ejemplo: el equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizable y que ha considerado su impacto en las decisiones de arquitectura).


8


Visiones asociadas a los puntos de fijación:(3) Capacidad operativa inicial: corresponde a un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previa a la instalación y la asistencia precisada por todas las partes que utilizarán o mantendrán el software



Modelos Evolutivos


9


El uso de modelos simples como el ciclo de vida lineal para controlar actividades complejas como el desarrollo de Sw, hace que los gestores de proyectos no tengan idea del estado de los mismos.

Está demostrado que existe concurrencia de tareas en el desarrollo de software (por ejemplo una persona puede estar codificando, escribiendo requisitos, diseñando).

La mayoría de los modelos de proceso de desarrollo de software está dirigidos por tiempo, esto es, mientras más tarde sea más retrasado estará el proyecto.

Un modelo de procesos concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

Modelo Concurrente


Puede ser representado por una serie de actividades técnicas importantes, tareas y estados asociadas a ellas.

Todas las actividades existen concurrentemente pero pueden encontrarse en estados diferentes

Por ejemplo, al principio de un proyecto, la actividad comunicación del cliente ha finalizado su primera iteración y está en el estado cambios en espera, la actividad análisis que estaba en estado ninguno hace una transición al estado bajo desarrollo. Si el cliente pide cambios en los requisitos la actividad análisis cambia de bajo desarrollo a cambio en espera.

Modelo Concurrente

10


Representa un estado (modo observable del comportamiento) de una actividad o tarea de ingeniería de software

En espera de cambios

En revisión

En modificación

En línea de base

Bajodesarrollo

Realizado

Actividad de modelado Ninguno

Modelo Concurrente


Este modelo se utiliza a menudo para el desarrollo de aplicaciones Cliente/Servidor.

Cuando se aplica a cliente/servidor el modelo define actividades en dos dimensiones; dimensión de sistemas y una dimensión de componentes.

En la primera de ellas se realizan tres actividades Diseño, Ensamblaje y Uso.

En la segunda se llevan a cabo dos actividades: Diseño y Realización.

Es aplicable a todo tipo de desarrollo de Sw y proporciona una imagen exacta del estado actual de un proyecto.

Modelo Concurrente

11





Bibliografía

1



[email protected]







2


Presentado por Booch, Jacobson y Rumbaughen 1999RUP es un proceso de desarrollo de software que provee:

Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo

Quién hace qué, cuándo y cómoBasado en componentesObjetivo:

Garantizar la producción de software de calidaddentro de plazos y presupuestos predecibles.

Proceso Unificado


Utiliza como lenguaje de modelado UML (Lenguaje Unificado de Modelado)

Características Clave:1. Dirigido por Casos de Uso2. Centrado en la Arquitectura3. Iterativo e Incremental

Proceso Unificado

3


Proceso Unificado

CaracterísticasCiclo de VidaConceptos ImportantesFlujos de TrabajoFases


1. Dirigido por casos de UsoObjetivo Software: Servicio a los UsuariosCasos de Uso:

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importanteRepresentan los requisitos funcionales.No sólo inician el proceso de desarrollo, sino que le proporcionan un hilo conductor.

El proceso avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de uso finales son la fuente a partir de la cual se constituyen los casos de prueba.

Proceso UnificadoCasos de UsoArquitectura

guía

conduce

4


2. Centrado en la ArquitecturaLa Arquitectura del Sw incluye los aspectos estáticos y dinámicos más significativos del sistema y La vista del diseño completo con las características más importantes resaltadasRelación Arquitectura-Casos de Uso:

Cada producto tiene tanto una función (cdu) como una forma (arq). No es suficiente con una sola.Ambas fuerzas deben equilibrarse para lograr un producto de éxitoLos casos de uso y la arquitectura deben evolucionar en paralelo (desde el comienzo hasta el fin del desarrollo).

Proceso Unificado

Casos de UsoArquitecturaguía

conduce


2. Centrado en la ArquitecturaPara la creación inicial de la arquitectura, el Arquitecto Software:

Crea un esquema (borrador) de la arquitectura no dependiente de los casos de usoSe especifican en detalle los Casos de Uso Clave(entre el 5 y 10 % del total) del sistema en forma de subsistemas, clases y componentesA medida que se especifican y maduran los casos de uso:

Se descubre más de la arquitecturaSe maduran más casos de uso

Proceso Unificado

5


3. Iterativo e IncrementalDesarrollo Software Complejo Esfuerzo

Es práctico dividir el desarrollo en miniproyectosMiniproyecto:

Iteración que acaba en un incrementoIteración Paso en el flujo de trabajoIncremento Crecimiento del producto

Iteración (análisis-diseño-implementación-prueba)Trata un grupo de casos de uso que amplían la utilidad del productoTrata los riesgos más importantes (se trabaja poco a poco)

Proceso Unificado


3. Iterativo e IncrementalBeneficios:

Se reduce el costo de los riesgos a los costos de un solo incremento. Se reduce el riesgo de no sacar el producto en el calendario previsto. Se acelera el ritmo de esfuerzo de desarrollo en su totalidad La iteración controlada reconoce una realidad que a menudo se ignora: Los requisitos no se definen NUNCA completamente al principio.

Proceso Unificado

6


Proceso Unificado



Proceso UnificadoCiclo de Vida

7


Se compone de varios ciclos. Al final de cada uno, un producto es entregado al clienteCada ciclo consiste de cuatro fases:

Inicio: Establecer la planificación del proyecto (análisis de negocio).Elaboración: Establecer un plan y una arquitectura correcta.Construcción: Desarrollo del sistema.Transición: Proporcionar el sistema a los usuarios finales.

Cada fase puede tener varias iteracionesUna iteración construye un conjunto de casos de uso relacionados o mitiga algún riesgo de los identificados



Cada ciclo constituye una versión del producto

Inicio Elaboración Construcción Transición

Iteración #1 -----Iteración

#2 -------------------- ----------

Versiones

Tiempo


8


El Producto: Cada ciclo produce una nueva versión que es un producto preparado para la entregaEl producto incluye:

Código fuente, Manuales, Requisitos, Casos de UsoEspecificaciones no funcionalesCasos de PruebaModelo de la arquitecturaModelo visual…



La vida del proceso Unificado. El Producto:


9




Proceso Unificado


10


Actividad: Unidad tangible de trabajo realizada por un trabajador en un flujo de trabajo de forma que:

Implica una responsabilidad bien definida para el trabajadorProduce un resultado bien definido basado en una entrada bien definidaRepresenta una unidad de trabajo con límites bien definidos

Proceso UnificadoConceptos Importantes


Artefacto: Pieza de información tangible que:Es creada, modificada y usada por los trabajadores al realizar las actividadesEs candidato a ser considerado para el control de la configuración. Puede ser un modelo, un elemento de un modelo o un documento

Dos clases de artefactos:De Ingeniería: Artefactos creados en las diferentes fases De Gestión: Análisis de negocio, plan de desarrollo, etc..


11


Modelo: Es una abstracción del sistema, especificando el sistema modelado desde un cierto punto de vista y en un determinado nivel de abstracción

Son abstracciones del sistema que construyen los arquitectos y desarrolladores

Un modelo es el artefacto más importante del proceso unificado.Un modelo siempre identifica el sistema que estámodelando



Trabajador:

Define el comportamiento y las responsabilidades de un individuo.Es el rol que desempeña una persona en un momento dado a lo largo del proyectoResponsabilidades:

Hacer una serie de actividadesSer el responsable de una serie de artefactos


12


Recurso Trabajador Actividad

Pablo Diseñador Diseño de Objetos

María Autor de Casos de Uso Detallar un Caso de Uso

José Diseñador de Casos de Uso Diseñar un Caso de Uso

Silvia Revisor de Diseño Revisar el Diseño

Eduardo Arquitecto Análisis de Arquitectura Diseño de Arquitectura

Crean M

odelos y Artefactos



Proceso Unificado


13


Un Flujo de trabajo es la realización de un caso de negocio o parte de élSe pueden describir con diagramas de actividad:

Muestran qué trabajadores ejecutan qué actividades y qué artefactos producen

Tipos:Flujo de Trabajo de una Iteración

La integración de los flujos de trabajo fundamentalesFlujo de Trabajo Fundamental

Requisitos, análisis, diseño, implementación y pruebas

Proceso UnificadoFlujos de trabajo


Proceso UnificadoFlujos de trabajo: Requisitos

14


Enumerar Requisitos Candidatos Lista de Características* (que irá evolucionando)

Estado (proceso, aprobado,…)Costo estimado de ImplementaciónPrioridadNivel de Riesgo de su implementación

Comprender el Contexto del SistemaModelo de Dominio* más centrado en los conceptosModelo de Negocio* más centrado en los procesos

Capturar:Requisitos Funcionales* Casos de UsoRequisitos no Funcionales* mediante restricciones asociadas a los casos de uso (ej. Rendimiento)

* Artefactos generados en este flujo

Proceso UnificadoFlujos de trabajo: Requisitos


Proceso UnificadoFlujos de trabajo: Análisis

15


Se analizan los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos

Para ello se utiliza el modelo de análisis, que ayuda a refinar los requisitos y permite razonar sobre los aspectos internos del sistema.



ArtefactosTrabajadores

Paquete del análisis

Clase del análisisIngeniero de Componentes

Realización de casos de uso-análisis

Ingeniero de Casos de Uso

Arquitectura del modelo de análisis

Modelo de análisisArquitecto


16


Proceso UnificadoFlujos de trabajo: Diseño


Se modela el sistema y se encuentra su forma para que soporte todos los requisitos que se le suponen. Una entrada esencial en el diseño es la salida del análisis. El diseño es el centro de atención al final de la fase de elaboración y el comienzo de las iteraciones de construcción.


17


Subsistema de diseño

Ingeniero de Componentes

Descripción de la Arquitectura


Interfaz

Clases de diseño

Realización de casos de uso-diseño

Ingeniero de Casos de Uso

Modelo de Despliegue

Modelo de DiseñoArquitecto



Proceso UnificadoF. de trabajo: Implementación

18


Comienza con el resultado del diseño y se implementa el sistema en términos de componentes.Es el centro durante las iteraciones de construcción, aunque también se lleva a cabo trabajo de implementación durante la fase de elaboración, para crear la línea base ejecutable de la arquitectura, y durante la fase de transición, para tratar defectos tardíos como los encontrados con distribuciones beta del sistema



Implementación de subsistemaIngeniero de Componentes

Descripción de la Arquitectura


Interfaz

ComponenteIntegración del SistemaIntegrador de Sistemas

Modelo de Despliegue

Modelo de ImplementaciónArquitecto


19


Proceso UnificadoFlujos de trabajo: Pruebas


Se verifica el resultado de la implementación probando cada construcción Se llevan a cabo sobre todo cuando una construcción es sometida a pruebas de integración y de sistema.Artefactos fundamentales:

Modelo de pruebas, el caso de pruebas, el procedimiento de prueba, el componente de prueba, el plan de prueba, el defecto y la evaluación de pruebas

Proceso UnificadoFlujos de trabajo: Pruebas

20


Proceso Unificado



Proceso UnificadoFase de Inicio

21


Objetivo: Desarrollar el análisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto

Es necesario en función del alcance tener una idea de la arquitecturaPreguntas típicas en esta fase:

¿Compensarán las ganancias del uso o venta del producto software?¿Llegará el producto al mercado a tiempo de obtener esas ganancias?



Productos:Una lista de características (requisitos)Una primera versión del modelo de negocio (o del dominio) que describe el contexto del sistemaUn esbozo de los modelos que representan una primera versión del modelo de casos de uso, el modelo de análisis y el modelo de diseño. Un primer esquema de la descripción de una arquitectura candidata, que perfila las vistas de los modelos de casos de uso, análisis, diseño e implementación


22


Productos:Posiblemente, un prototipo exploratorio que muestra el uso del nuevo sistemaUna lista inicial de riesgos y una clasificación de casos de usoLos rudimentos de un plan para el proyecto en su totalidad, incluyendo el plan general de las fasesUn primer borrador del análisis de negocio, que incluye:

Contexto del negocio y Criterios de éxito.



Proceso UnificadoFase de Elaboración

23


Objetivos: Recopilar la mayor parte de los requisitos pendientes Establecer una base de la arquitectura sólida (línea base) para guiar el trabajo durante la fase de construcción y transición Continuar la observación y control de los riesgos críticos que aún queden Completar los detalles del plan del proyecto

Al comienzo de la fase de elaboración, se recibe de la fase de inicio:

Un plan para la fase de elaboraciónUn modelo de casos de uso parcialmente completo Una descripción de la arquitectura candidata. Un prototipo que muestre el funcionamiento del sistema.



Productos:Preferiblemente un modelo completo de negocio que describe el contexto del sistemaUna nueva versión de todos los modelos: casos de uso, análisis, diseño, despliegue e implementación. Una línea base de la arquitecturaUna descripción de la arquitectura, incluyendo vistas de los modelos de casos de uso, análisis, diseño, despliegue e implementaciónUna lista de riesgos actualizada


24


Productos:El plan del proyecto para las fases de construcción y transiciónUn manual de usuario preliminarEl análisis de negocio completo, incluida la apuesta económica



Proceso UnificadoFase de Construcción

25


Objetivo: Preparar un producto software en su versión operativa inicial (versión beta)

Debe tener la calidad adecuada para su aplicación Debe cumplir los requisitos

Para cumplir el objetivo:Se parte de la línea base de la arquitecturaSe detallan los casos de uso y escenarios resultantesSe cierran los métodos de análisis-diseño-implementaciónSe integran los subsistemas y se pruebanSe integra el sistema completo y se prueba



Productos:El plan de proyecto para la fase de transiciónEl sistema software ejecutableTodos los artefactos, incluyendo los modelos del sistemaLa descripción de la arquitectura, mínimamente modificada y actualizadaUna versión preliminar del manual de usuario, lo suficientemente detallado como para guiar a los usuarios de la beta


26


Proceso UnificadoFase de Transición


Objetivo: Cumplir los requisitos establecidos en las fases anteriores hasta la satisfacción de todos los usuariosGestionar los aspectos relativos a la operación en el entorno del usuario

Se recibe información de los usuarios para:Determinar si el sistema hace lo que debe hacerDescubrir riesgos inesperadosAnotar problemas no resueltos, Encontrar fallasEliminar ambigüedades y lagunas en la documentación del usuarioCentrarse en áreas en las que los usuarios muestren deficiencias y necesiten información o formación

La transición finaliza con el lanzamiento del Producto


27


Productos:El propio Sw ejecutable, incluyendo el Sw de instalaciónDocumentos legales como contratos, licencias, renuncias de derechos y garantíasLa versión completa y corregida de línea base de la versión del producto, incluyendo todos los modelos del sistemaLa descripción completa y actualizada de la arquitecturaManuales y material de formación del usuario final, del operador y del administrador del sistemaReferencias para la ayuda del cliente, acerca de dónde encontrar más información, cómo informar de defectos o dónde encontrar información sobre defectos y actualizaciones.





28


Modelos de proceso de SwModelos especializados de Procesos:

Desarrollo basado en componentesModelo de métodos formales (sala límpia)Desarrollo de Sw orientado a aspectosProgramación Extrema Desarrollo Adaptativo de Software Método de desarrollo de sistemas dinámicos MeléDesarrollo conducido por característicasTeam Software Process


Modelos de proceso de SwModelos especializados de Procesos:

Investigar acerca de los modelos especializados.Entregar un informe con los resultados de la investigación el día 8-9-2009, durante todo el día en secretaría de carrera y además en formato digital por e-mail a la profesora.Describir de que se trata el modelo, características principales, su aplicación, ventajas y desventajas. Complementar con esquemas gráficos.Hacer una comparativa con los modelos Cascada, Iterativo Incremental y Espiral.Realizar una exposición del resultado de la investigación a partir del 10-9-2009.Desarrollar el trabajo en grupo de 3 personas.

29


Proyecto de la Asignatura

Definir grupos de máximo 5 personas para desarrollar el proyecto de I. de Sw.Cada grupo deberá elegir quien serásu líder y presentarse el día jueves 27 de agosto para la asignación de los proyectos.





Bibliografía

1



[email protected]







2


Desarrollo de un proyecto Sw :

Hasta ahora hemos visto que el ciclo de desarrollo de Sw incluye varias etapas que se van repitiendo hasta que la aplicación se completa y los clientes y usuarios están satisfechos.Sin embargo, el desarrollo de Sw no se limita sólo a eso:

El desarrollo de Sw es parte de un proyecto que incluye otras actividades, también muy importantes, previas y paralelas al desarrollo y que son claves para lograr un objetivo concreto de desarrollo.

Planificaciónde Proyectos de Sw


Desarrollo de un proyecto Sw :Un proyecto de desarrollo de Sw parte cuando un cliente plantea una necesidad y termina cuando se obtiene un Sw útil


Necesidades

Producto Útil

Desarrollo

Propuesta de Solución

3


Desarrollo de un proyecto Sw :

En la fase inicial los clientes tienen muchas dudas a las que debemos contestar:

¿Se entiende el problema y las necesidades? ¿Se puede crear un sistema que satisfaga las necesidades? ¿Cuánto tiempo demorará el desarrollo del Sistema?¿Cuánto costará el Sistema?¿Debo participar en el desarrollo?¿Cómo?

Contestar estas y otras preguntas no siempre es sencillo



Algunas preguntas…

¿Cuánto tiempo demorará el desarrollo del Sistema?¿Cuánto costará el Sistema?Para responderlas debemos, entre otros tener claro:

El cronograma del proyecto

Estimar los recursos de personal, hardware y software

Estimar el costo

Esto implica una Planificación del proyecto


4


Para realizar exitosamente un proyecto de Swdebemos entender:

El alcance del trabajo a realizarseLos riesgos que estamos enfrentandoLos recursos requeridosLas tareas a realizarseLos eventos importantes a observarEl esfuerzo (costo) a invertirEl calendario a seguir



La GESTIÓN comienza antes que el trabajo técnico, continúa con la transformación del Sw desde que es una idea hasta que es una realidad, y termina cuando el Sw es descontinuado.La gestión eficaz de un proyecto de software se harácentrando la atención en las 4P:

Personal, “factor humano”, motivado y calificadoProducto, objetivo y ámbitoProceso, marco de trabajoProyecto, ejecución planificada y controlada

Gestiónde Proyectos de Sw

5


PersonalProductoProcesoProyecto



El factor humano es importante en el desarrollo de proyectos de Sw

El Software Engineering Institute creó un Modelo de Madurez de la Capacidad para la Gestión de Personal (MMCGP) que define áreas claves prácticas para el personal que desarrolla Sw:

Reclutamiento, Selección, Gestión del desempeño, Entrenamiento, Retribución, Desarrollo de la carrera,Diseño de la organización y el trabajo, Desarrollo de la cultura del equipo

Gestión de Proyectos de SwPersonal

6


Los participantes de un proceso de desarrollo de software pueden clasificarse en cinco categorías:

Gestores Ejecutivos: definen los aspectos del negocio que a menudo tiene una importancia significativa sobre el proyectoGestores (técnicos) del proyecto: Deben planificar, motivar, organizar y controlar a los profesionales que hacen el trabajo de SwProfesionales: que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación Clientes: que especifican los requisitos para la ingeniería del software. Usuarios finales: que interaccionan con el software una vez que se ha entregado para producción

Gestión de Proyectos de SwPersonal: Los Participantes


Suele suceder con mucha más frecuencia de la deseada que los gestores de proyectos de Sw llegan allí de manera accidental. Por otra parte, ser profesional del Sw parece no ir de la mano con la gestión de proyectos de Sw.Un modelo de liderazgo técnico (MOI, Weinberg):

Motivación: Habilidad para motivar al personal técnico para que produzca de acuerdo a sus mejores capacidadesOrganización: Habilidad para amoldar los procesos existentes (o inventar nuevos) que permita al concepto inicial transformarse en un producto final.Ideas e innovación: Habilidad para motivar al personal a crear y sentirse creativos incluso cuando deban trabajar dentro de límites establecidos para un producto o aplicación en particular

Gestión de Proyectos de SwPersonal: Los Jefes

En términos

simples,

un líder

es aquel

que sabe

donde

quiere ir, se

levanta y va.

(Erskine)

7


Otras características que definen a un gestor eficiente:Resolución de problemas: debe diagnosticar a tiempo, estructurar soluciones o motivar para que otros lo hagan, aplicar las lecciones aprendidas, ser flexible en la búsqueda de la solución.Dotes de gestión: debe tener la confianza de asumir el control cuando es necesario y la seguridad para que otros lo sigan.Incentivos: debe saber recompensar las iniciativas y logros y demostrar por acciones propias que no se castigará si se corren riesgos controlados.Influencia y fomento de la cultura de equipo: debe ser capaz de “leer” a la gente, debe entender el lenguaje verbal y no verbal y reaccionar ante estos mensajes. Debe además saber mantener el control ante situaciones de estrés.

Gestión de Proyectos de SwPersonal: Los Jefes

Un experto de software puede no

tener temperamento

o deseo de ser jefe de

equipo. No se debe forzar.


¿Cómo debiera ser organizado un equipo de trabajo?. Mantei (1981) sugiere tres organigramas genéricos:

Descentralizado Democrático (DD): No tiene jefe permanente sino coordinadores de áreas a corto plazo que serán sustituidos por otros para diferentes tareas. Las decisiones se toman por consenso existiendo una fuerte comunicación horizontal.Descentralizado Controlado (DC): Tiene jefe definido para tareas y jefes secundarios que coordinan subtareas. La implementación de la solución se reparte en los subgrupos. En los subgrupos hay comunicación horizontal y la vertical se da a lo largo de la jerarquía de control Centralizado Controlado (CC): El jefe se encarga de la resolución de problemas a alto nivel y de la coordinación interna del equipo. La comunicación es vertical.

Gestión de Proyectos de SwPersonal: El equipo de Sw

8


Mantei siguiere siete factores ha considerar cuando se planifica el organigrama de equipos de ingeniería de Sw:

La dificultad del problema que hay que resolverEl tamaño del programa(s) resultante en líneas de código o puntos de funciónEl tiempo que el equipo estará juntoEl grado en que el problema puede ser modularizadoLa calidad requerida y fiabilidad del sistema que se va a construirLa rigidez de la fecha de entregaEl grado de sociabilidad (comunicación) requerido para el proyecto


Frecuentemente es mejor tener pocos equipos pequeños

bien centrados que un solo gran equipo


Para conseguir equipos de alto rendimiento:

Los miembros del equipo deben confiar uno en los otrosLa distribución de habilidades debe adecuarse al problemaPara mantener la unión del equipo, excluir a los inconformistas


9


Toxinas para los equipos de trabajo:Atmósfera de trabajo frenética que impide concentrarse en los objetivos del trabajoFrustración causada por factores tecnológicos, de negocio o personales que provocan fricciones entre los miembros del equipoProcedimientos pobremente coordinados o fragmentadosDefinición confusa de los roles produciendo falta de responsabilidadExposición repetida al fallo que implica una pérdida de confianza y una caída de la moral



Técnicas de coordinación de las acciones entre los miembros de equipo de proyectos (Kraul y Streeter - 1995): (1/2)

Formal, enfoque impersonal: Documentos y entregas (código fuente), memos, etc.Formal, procedimientos interpersonales: se centra en actividades de garantía de calidad. Reuniones de revisión de estado e inspecciones de diseño y de código.Informal, procedimientos interpersonales: reuniones de grupo para la divulgación de información y resolución de problemas


10


Técnicas de coordinación de las acciones entre los miembros de equipo de proyectos (Kraul y Streeter - 1995): (2/2)

Comunicación electrónica: Correo electrónico, boletines de noticias electrónicos y por extensión sistemas de vídeo conferencias.Red interpersonal: Discusiones informales con los miembros del equipo y personas que no están en el proyecto pero que pueden ayudar.



Los 10 mandamientos + 1, Ford Motor Company:Busca formas de que las nuevas ideas funcionen, no razones para que no funcionen.Si tienes dudas, pregunta! No hagas conjeturas negativas acerca de los demás.Ayuda a los otros a ganar, y siéntete orgulloso del triunfo del otro.Habla positivamente de los demás en el equipo y de tu organización cada vez que puedas.Mantén una actitud mental positiva, no importa las circunstancias.Actúa con iniciativa y coraje, como si todo dependiera de ti.Hazlo todo con entusiasmo, éste es contagioso.Cualquier cosa que quieras, déjala pasar.En cualquier circunstancia, mantén la fe.Diviértete!


1



[email protected]







2


Aclarar el ámbito del software involucra contestar:

Contexto: ¿cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultado del contexto?

Objetivos de la información: ¿qué objetivos de datos visibles al cliente se obtienen del software? ¿qué objetos de datos son requeridos de entrada?

Función y rendimiento: ¿qué función realiza el software para transformar la información de entrada en una de salida? ¿hay características de rendimiento especiales que abordar?

Gestión de Proyectos de SwProducto: Ámbito del Sw


Aplicación del principio: Divide y vencerásLa descomposición se aplica en dos áreas principales:

La funcionalidad que debe entregarse. Las funciones de Sw descritas en el ámbito del problema se evalúan y refinan para proporcionar más detalles. Esto es esencial para la estimación y planificación.El proceso que se empleará para entregarla.

Gestión de Proyectos de SwProducto: Descomposición

3





El gestor del proyecto debe decidir cuál modelo de proceso es más adecuado para:

Los clientes que han solicitado el producto y el personal que hará el trabajo.Las características el producto mismoEl ambiente del proyecto en el que trabaja el equipo de Sw

Gestión de Proyectos de SwProceso

4


¿Qué modelo de desarrollo de software se aplicará?

Lineal secuencial, Prototipos, Desarrollo rápido de aplicaciones DRA, Incremental, Espiral, EspiralWINWIN, Desarrollo Concurrente, Basado en componentes, Métodos formales, Técnicas 4G …..

Una vez definido el modelo de proceso el equipo puede desarrollar un plan de proyecto preliminar que refleje las tareas de trabajo requeridas para cubrir las actividades del marco de trabajo.



En el plan del proyecto…Combinación del producto y del proceso, cada función a desarrollar debe pasar por el conjunto de actividades del marco de trabajo Descomposición del proceso. Comienza cuando el jefe del proyecto pregunta ¿cómo logramos esta actividad del marco de trabajo? Por ejemplo: Comunicación

Desarrollo de una lista de conflictos a aclararReunión con los clientes para abordar los conflictos Desarrollar en conjunto un enunciado del ámbitoRevisar el enunciado del ámbito con todos los implicadosModificar el enunciado del ámbito según se requiera


5





Diez señales que indican que un proyecto está en peligro.No se entiende las necesidades de los clientesEl ámbito del producto está pobremente definidoLos cambios están mal realizadosLa tecnología elegida cambiaLas necesidades del negocio cambian (o están mal definidas)Las fechas de entrega no son realistasLos usuarios se resistenSe pierde el apoyo político (o nunca lo hubo)El equipo de trabajo es técnicamente débilLos gestores evitan las buenas prácticas y las sabias lecciones

Gestión de Proyectos de SwProyecto

Al menos siete de

ellas pueden ser

determinadas

antes del

desarrollo de un

diseño o antes de

escribir una línea

de código

6


Otras razones de atraso en la entrega:Cambios en los requerimientosSub-estimación en la planeación de recursosErrores no consideradosDificultades técnicas no predeciblesDificultades humanas no predeciblesFalta de comunicación en el equipoFalta de reconocimiento por parte de la administración de retrasos y falta de medidas para corregir el problema.



Boehm (1996) sugiere un enfoque que trate los objetivos, hitos, planificación, responsabilidades, enfoque técnico y de gestión, y los recursos requeridos por el proyecto.

Propone para esto W5HH:(W) Por qué se desarrolla el sistema? Dicho de otra forma justifica el propósito del negocio la inversión en personal, tiempo y dinero?(W) Qué se hará? Tareas que se requieren para el proyecto(W) Cuándo se hará? Ayuda a planificar identificando las áreas claves e hitos


7


W5HH:

(W) Quién es el responsable de una función? Definición del rol y responsabilidad de cada miembro del equipo(W) Dónde están ubicados en la organización? Identifica a clientes, usuarios y desarrolladores(H) Cómo se hará el trabajo desde el punto de vista técnico y de gestión? Conocido esto se debe definir una estrategia técnica y de gestión.(H) Cuánto se necesita de cada recurso?



El Airlie Council (expertos en ingeniería de software) desarrolló una lista de las “prácticas críticas de software para la gestión basada en el rendimiento”. Estás prácticas han sido utilizadas por organizaciones y proyectos de software con éxito. (1999)Entre las prácticas críticas podemos mencionar:

Gestión formal del riesgoCosto empírico y estimación de la planificación Gestión de proyectos basada en métricas. Seguimiento del valor ganado (calendarización)Seguimiento de defectos frente a objetivos de calidadGestión del personal


8


Para comunicar a los clientes el análisis y la gestión del riesgo, el cronograma y la organización, generalmente se escribe un documento llamado: plan de proyecto. El plan deja por escrito las necesidades del cliente y como se espera satisfacerlas.El cliente puede informarse en el plan del las actividades del proceso de desarrollo y seguir el avance del proyecto.El plan también sirve para corroborar las suposiciones realizadas, por ejemplo sobre costos y el cronograma.

Gestión de Proyectos de SwPlan del Proyecto


Un buen plan debe incluir (Pfleeger):Alcance del proyectoCronograma del proyectoOrganización del equipo del proyectoDescripción técnica del sistema propuestoEstándares del proyecto, procedimientos y técnicas y herramientas propuestas.Plan de aseguramiento de la calidadPlan de gestión de la configuraciónPlan de la documentación Plan de gestión de datosPlan de gestión de recursosPlan de pruebaPlan de entrenamientoPlan de seguridadPlan de gestión de riesgoPlan de mantenimiento

Gestión de Proyectos de SwPlan del Proyecto

9


Supongamos que tenemos la siguiente situación en relación al desarrollo de un proyecto de Sw:

Se ha seleccionado un modelo de proceso apropiadoSe han identificado las tareas de Ing. de Sw que deben realizarseSe estimó la cantidad de trabajo y el número de personas Se conoce la fecha límite del proyecto.

Ahora, es hora de:Crear una red de tareas de Ing. de Sw que permitirán terminar el trabajo a tiempo. Asignar responsables a cada tarea, asegurarse que éstas se realicen y adaptar la red en la medida que los riesgos se vuelven realidad.

Es decir, se debe hacer la calendarización y seguimiento del proyecto de Sw.

Gestión de Proyectos de SwCalendarización


Algunas frases para meditar…


“Cualquier comandante en jefe que pretenda llevar a cabo un plan que considera defectuoso comete un error; debe exponer sus razones, debe insistir en que el plan debe cambiarse y finalmente presentar su renuncia en lugar de ser el instrumento de destrucción de su ejercito”.

Napoléon Bonaparte

Si las mejores estimaciones indican que la fecha límite es irrealizable, un gestor de proyectos competente debe proteger a su equipo de la presión excesiva de la calendarización y devolver la presión a quienes la originan.

Page-Jones

10


Respecto a la planificación temporal de un proyecto surgen interrogantes como:

Cómo hacer corresponder el tiempo cronológico con el esfuerzo humano?Qué tareas y qué paralelismo se pueden encontrar?Qué hitos se pueden establecer para la evaluación de progreso?Se dispone de métodos de análisis para la planificación temporal?Cómo representamos físicamente una agenda y seguimos el progreso del proyecto cuando éste comienza?



Principios básicos que guían la calendarización:Descomposición: el proyecto y el proceso deben dividirseInterdependencia: determinar que tareas deben realizarse en secuencia, cuáles pueden realizarse en paraleloAsignación de tiempo: cada tarea debe tener asociado un número de unidades de trabajo (personas-día), fecha de inicio y término.Validación del esfuerzo: no asignar más tareas de las que se pueden ejecutar por el equipo Definición de responsabilidades: Toda tarea del calendario debe ser asignada a un miembro del equipoDefinición de resultados: Toda tarea debe tener un resultado definidoDefinición de hitos: Toda tarea o grupo de tareas debe estar relacionado con algún hito del proyecto


11


Distribución del esfuerzo:Las técnicas de estimación de proyectos nos llevan a estimar el esfuerzo en personas-mes (o año) requerido para completar el desarrollo del software.Una distribución recomendada para la distribución del esfuerzo es la regla 40-20-40.


20 %40 %

40 %

Análisis y diseño(40-50 %)

Prueba y depuración(30-40%)

Codificación(15-20 %)


Algunas consideraciones (1/2):La regla 40-20-40 sólo es una directriz. Las características de cada proyecto deben ser las que impongan la distribución del esfuerzo.El esfuerzo en la planificación raramente es más del 2 o 3%, a menos que el plan comprometa a la organización a grandes gastos con altos riesgos.El análisis de requisitos puede suponer entre el 10 y el 25%.El análisis o creación de un prototipo debe crecer en proporción directa al tamaño y a la complejidad del proyecto.


12


Algunas consideraciones (2/2):Normalmente, se establece un 20 o 25% para el diseño.Hay que considerar el tiempo invertido en la revisión del diseño y la consiguiente iteración. La codificación puede suponer entre 15 y 20% del esfuerzo global.Las pruebas y la consiguiente depuración pueden requerir entre el 30 y 40% del esfuerzo de desarrollo del Sw. Dependiendo de lo crítico que sea el Sw asíserá la cantidad de pruebas que se requiera. Si el funcionamiento del Sw conlleva riesgos humanos (p.ej: si un fallo del Sw puede provocar la pérdida de una vida), se deberán considerar porcentajes más altos.



Métodos usados para la calendarización:La planificación temporal de un proyecto de software no difiere mucho de la de cualquier otro esfuerzo de desarrollo multitarea.Se puede utilizar:

La técnica de evaluación y revisión de programas (Program Evaluation Review Technique, PERT).El método del camino crítico (Critical Path Method, CPM).

Ambas técnicas desarrollan una descripción de la red de tareas del proyecto, es decir, una representación gráfica o tabular de las tareas que deben realizarse desde el principio hasta el final del proyecto.


13


La red se define desarrollando:Una lista de todas las tareas asociadas con el proyecto específico, llamada estructura de descomposición de trabajos.Una lista de secuenciamientos que indica en qué orden deben realizarse las tareas, llamada lista de restricciones.

Proporcionan herramientas cuantitativas que permiten:

Determinar el camino crítico, la secuencia de tareas que determina la duración total del proyecto.Establecer las estimaciones de tiempo más probables para las tareas individuales con la aplicación de modelos estadísticos.Calcular los límites de tiempo que definen una “ventana temporal” para cada tarea individual.



PERT. Etapas:1. Elaboración del grafo (diagrama de flechas).2. Ordenación del grafo por niveles. (opcional)3. Cálculo de los tiempos PERT.4. Cálculo de los tiempos más tempranos posibles ('early').5. Cálculo de los tiempos más tardíos posibles ('late').6. Cálculo de las holguras (total, libre e independiente).7. Determinación del camino crítico.8. Definición de fechas.


14


PERT. Relaciones de Precedencia:


RELACIONES DEPRECEDENCIA

LINEALES

RELACIONES DEPRECEDENCIADIVERGENTES

1 2 3

RELACIONES DEPRECEDENCIA

CONVERGENTES

A B

Para iniciar la actividad B esnecesario haber finalizado laactividad A. El suceso 2 es suceso final de A y suceso inicio de B.

1

2

3

4 5

A

B

C

D

Para iniciar la actividad D esnecesario haber finalizado lasactividades A, B y C.

1

3

2

5

4A

B

C

D

Para poder iniciar cualquierade las actividades B, C, o D, esnecesario que haya finalizado la actividad A.


PERT. Relaciones de Precedencia:Actividades Ficticias (Duración 0)Ejemplo: Las actividades A y B preceden a la actividad D y las actividades A, B y C preceden a la actividad E.


A

B

C

D

E

A

B

C

D

E

F

15


PERT. Ejemplo:Proyecto con actividades: A, B, C, D, E, F, G y H.Relaciones Precedencia


3

9

7

6

5

6

5

8

Duración

E, FH

DG

CF

BE

AD

AC

AB

-A

ActividadesPrecedentesActividades

1 2

5

4

3

6

7

A

B

C

D

E

F

G

H


PERT. Estimación de tiempos:Estimación de tiempo pesimista (tP): tiempo máximo en que podría finalizarse la actividad si aparecen todas las circunstancias negativas que pueden darse durante su ejecución.Estimación de tiempo más probable (tn): tiempo normal de duración de la actividad considerando que hay problemas durante las actividades, pero no aparecen en su totalidad.Estimación de tiempo optimista (to):tiempo mínimo si no aparece ningún problema durante la ejecución de la actividad.


ATEi TLi TEj TLj

suceso i suceso j

Tiempo más temprano para comenzar la actividad A (tiempo early de comienzo de A)

Tiempo más tardío paracomenzar la actividad A

Tiempo más temprano parafinalizar la actividad A

Tiempo más tardío parafinalizar la actividad A

16


PERT. Ejemplo:Cálculo de los Tiempos Early:

TEj = Para todo j: máx [ TEi + Tij ]


3

4

5

6

7A1 2

B

C

D

E

FH

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22

TE6 = máx [14+7, 13+6] = 21


PERT. Ejemplo:Cálculo de los Tiempos Late:

TLi = Para todo j: min [ TLj - Tij ]


3

4

5

6

7A1 2

B

C

D

E

FH

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22

24

21

15

15

1480

10

21

248

TL2 = min [15-5, 14-6, 15-5] = 8

Camino Crítico

Holgura:- Suceso = TLi – TEi- Actividad = TLj – TEi - Tij

17


CPM:

Elaboración del grafo igual que en PERT:Los nodos se identifican por un número.Si i<j significa que el nodo i precede al j.Las actividades sin predecesor tienen su origen en el nodo 1.Las actividades sin sucesor tienen su final en el último nodo (el de mayor número).



CPM. Ejemplo:


18


CPM v/s PERT:Aunque CPM y PERT tuvieron un origen completamente diferente, resultan muy similares en sus aspectos esenciales. Básicamente la diferencia entre ellas es:

Al calcular la duración de cada actividad, PERT utiliza una media ponderada de tres valores (lo que permite un tratamiento probabilístico) en lugar del valor más probable empleado en CPM.La notación y terminología:


Notación PERT Notación CPM Suceso Nudo

Actividad Trabajo Holguras Flotantes

Tiempo ‘early’ Tiempo más bajo de iniciaciónTiempo ‘late’ Tiempo más alto de iniciación


Cronogramas:Normalmente una carta Gantt.Puede reflejar la planificación de todo el proyecto o parte de él. Este cronograma indica fecha específicas para cada tarea del proyecto. Ejemplo:


1



[email protected]







2


Un gestor de proyectos debe idealmente tener la “capacidad de saber que es lo que va a salir mal antes de que ocurra .... y tener la valentía para hacer estimaciones cuando el futuro no está claro”Una estimación de recursos, costos y tiempo es un esfuerzo que requiere experiencia, acceder a buena información histórica. Toda estimación tiene un riesgo inherente: la incertidumbre

Estimaciónde Proyectos de Sw


La complejidad del proyecto, el tamaño y el grado de incertidumbre estructural afectan la fiabilidad de la estimación. La complejidad de un proyecto depende en gran medida de las experiencias anteriores de los desarrolladoresLas medidas propuestas para la medición de este factor están más relacionadas con la parte de diseño y codificación, por lo que la estimación resulta poco adecuada para usarla en la planificación


3


Tamaño del proyecto:

Afecta la precisión y la eficiencia de la estimaciónEn proyectos grandes el enfoque de descomposición puede resultar insuficiente dado el tamaño de los elementos descompuestosSi hay más cosas que pueden fallar, más cosas fallarán



Grado de incertidumbre estructural:

Tiene que ver con la definición de requisitos facilidad para subdividir las funciones y la naturaleza jerárquica de la información que ha de procesarse


4


La Planificación del proy. proporciona un marco de trabajo que permite al gestor hacer estimaciones razonables de recursos, costos y tiempo.La planificación debe hacerse al principio del proyecto y en un tiempo limitado.El proceso de planificación contempla diversas etapas, en las cuales se deben realizar distintos tipos de estimaciones, la primera de ellas es:

El ámbito del software debe delimitarse al principio de la proyecto y comprende el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad



La Planificación del proy. proporciona un marco de trabajo que permite al gestor hacer estimaciones razonables de recursos, costos y tiempo.La planificación debe hacerse al principio del proyecto y en un tiempo limitado.El proceso de planificación contempla diversas etapas, en las cuales se deben realizar distintos tipos de estimaciones, la primera de ellas es:

El ámbito del software debe delimitarse al principio de la proyecto y comprende el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad


5


El ámbito del Sw se define usando técnicas como:

Comunicación con todos los participantes y desarrollando una narrativa descriptiva del ámbito del SwLos usuarios finales desarrollan un grupo de casos de uso

En ambos casos, es útil preparar cuestionarios para formular preguntas a los usuarios



Cuestionarios para la definición del ámbito del Sw. Tipo de preguntas:

¿quién está detrás de esta solicitud?¿quién utilizará esta solución?¿cuál será el beneficio económico de una buena solución?¿hay otros caminos para la solución?


6


Para establecer mayor claridad sobre lo que el cliente percibe de la solución:

¿cómo caracterizaría el cliente un resultado “correcto”que se generaría con una solución satisfactoria?¿Con qué problemas se enfrentará esta solución?¿Cuál es el entorno en que se utilizará la solución?¿Hay aspectos o limitaciones de rendimiento que afecten a la forma en que se aborda la solución?



Metacuestiones, que se centran sobre la efectividad de la reunión:

¿Es usted la persona apropiada para responder estas preguntas, son oficiales sus respuestas?¿Son relevantes mis preguntas para su problema?¿Estoy realizando muchas preguntas?¿Hay alguien más que pueda proporcionar información adicional?¿Hay algo más que debiera preguntarle?

Estas preguntas y respuestas sirven para “romper el hielo”. Se recomienda usarlas sólo en etapas iniciales del proy.


7


Identificado el ámbito del Sw, debe preguntarse si es factible el proyecto de construcción de Sw.Putnam y Myers (1997) proponen determinar la factibilidad del Sw considerando 4 dimensiones:

Tecnología: ¿es técnicamente factible, está dentro del estado actual de la técnica?Financiación: ¿es factible financieramente, puede hacerse con un costo que la organización y el cliente pueda asumir?Tiempo: ¿pueden los proyectos adelantarse a los de la competencia?Recursos: ¿la organización cuenta con los recursos suficientes para tener éxito?



Una segunda etapa de la planificación corresponde a estimación de los recursos necesarios para el desarrollo del Sw.Las tres grandes categorías de recursos en Ing. de Software son:


Personas Componentes reutilizables

Entorno

PROYECTOPROYECTO

8


Recursos Humanos. Dado el ámbito se deben evaluar las habilidades requeridas para el desarrollo.Se debe especificar la posición dentro de la organización (gestor, ingeniero de software experimentado) y la especialidad (telecomunicaciones, bases de datos, cliente/servidor)


PersonasComponentes reutilizables

Entorno

PROYECTOPROYECTO

El número de personas que requiere un proyecto se determina después de hacer una estimación del esfuerzo del desarrollo.


Recursos de Componentes Reutilizables. Es importante tener una noción de que podemos reutilizar en un proyecto, antes del desarrolloTipos de componentes:



Entorno

PROYECTOPROYECTO

Componentes ya desarrollados (Cots)Componentes ya experimentados(desarrollados para proyectos similares que requieren modificaciones parciales)Componentes con experiencia parcial: (desarrollado para proyectos anteriores que tiene relación pero requerirán de modificación sustancial)Componentes nuevos: (desarrollados para las necesidades del proyecto actual)

9


Recursos de Entorno. El planificador del proyecto debe determinar el hardware y software requerido y además verificar si estos recursos estarán disponiblesEl Hw proporciona la plataforma que soporta las herramientas de Sw usadas para el desarrollo.



Entorno

PROYECTOPROYECTO

En algunos casos se pueden requerir recursos no para apoyar el desarrollo, sino para el funcionamiento del software, por ej:Lector de código de barras


“En sistemas complejos, personalizados, un gran error en la estimación del costo puede hacer la diferencia entre beneficio y pérdida. Rebasar el costo puede ser desastroso para el desarrollador.”

(Pressman)


10


Opciones para hacer la estimación de costo y esfuerzo:

Dejar la estimación para más adelante (al finalizar el proyecto podemos tener una estimación 100% fiable)Basar la estimación en proyectos similares ya terminadosUtilizar “técnicas de descomposición” relativamente sencillas para hacer la estimación de costo y esfuerzoUtilizar uno o más “modelos empíricos” para la estimación de costo y esfuerzo del software



Técnicas de descomposición:Estimación basada en el tamaño del softwareEstimación basada en el problemaEstimación basada en el procesoEstimación basada en Casos de Uso

Modelos empíricos: COCOMO (Constructive Cost Model)


11


Estimación basada en el Tamaño del software:La estimación del proyecto se hace basándose en:

Grado de precisión con que el planificador estimó el tamañoHabilidad para traducir la estimación del tamaño en esfuerzo humano, tiempo y dinero Grado en que el plan de proyectos refleja las habilidades del equipoLa estabilidad de los requisitos y el entorno que soporta el esfuerzo de ingeniería de software.

La estimación será tan buena como la estimación que se haga del tamaño del software utilizando para ello un enfoque directo (LDC) o indirecto (PF)



Estimación basada en el Tamaño del software:

Putnam y Myers (1992) sugieren cuatro enfoques para determinar el tamaño:

Tamaño en “lógica difusa”Tamaño en puntos de funciónTamaño de componentes estándarTamaño del cambio


12



Tamaño en “lógica difusa”: Utiliza técnicas aproximadas de razonamiento. Para aplicar este enfoque el planificador debe tener claro el tipo de aplicación, establecer su magnitud en una escala cuantitativa y refinar la magnitud dentro del rango original. Idealmente debe existir una base histórica para establecer comparaciones.

Tamaño de Punto de Función: El planificador debe hacer estimaciones de las características del dominio de la aplicación.




Tamaño de componentes estándar: los componentes estándar son: subsist., módulos, pantallas, informes, programas interactivos, programas por lotes, archivos, LDC e instrucciones para objetos. Han de estimarse el número de ocurrencias de cada componente estándar y utilizar datos históricos para determinar el tamaño de entrega de cada componentes estándar.

Tamaño del cambio: Se utiliza cuando hay Sw existente que se modificará como parte del proyecto. Se estima el número y tipo de modificaciones (reutilización, añadir código, cambiar código, suprimir código)


13






Estimación basada en el Problema:Los datos de LDC y PF se emplean de dos formas durante la estimación del proyecto de software:

Como variables de estimación utilizadas para calibrar cada elemento del softwareComo métricas de base recogidas de anteriores proyectos, utilizadas junto con las variables de estimación para desarrollar proyecciones de costo y esfuerzo.

Valor esperado (VE) de LDC o de PF,


Donde:Sopt es el escenario optimistaSm es el escenario probable y Spess es el escenario pesimista

VE = (Sopt + 4Sm +Spess) / 6

14


Estimación basada en el Problema:La obtención de valores optimista y pesimista da cuenta de un rango de valores que en definitiva proporciona una indicación implícita del grado de incertidumbre.

Cualquier técnica de estimación , no importa lo sofisticada que sea, se debe volver a comprobar con otro enfoque. Incluso entonces va a prevalecer el sentido común y la experiencia.



LDCFunción Abvtr estimadasInterface usuario y facilidades de control IUFC 2,300Análisis geométrico dos dimensiones AG2D 5,300Análisis geométrico tres dimensiones AG3D 6,800Gestión de bases de datos GBD 3,350Facilidades representación gráfica FPGC 4,950Control de periféricos CP 2,100Módulos de análisis del diseño MAD 8,400Líneas de código estimadas 33,200

Estimación basada en el Problema:Ejemplo en LDC:


VE = (Sopt 4Sm+Spess) / 6

Si la productividad media histórica es de 620 LDC/pm a 8.000 unidades monetarias por mes cuanto esEl costo línea código mes ?

El costo total del proyecto

El esfuerzo estimado

12.90 ≈ 13um (8000/620)

431,600um (33200*13)

53.54 ≈ 54 pm (33200/620)

VE= (4600+4*6900+8600)/6

15


Valor de dominio factor de pondearación Cuenta Cuentade información Optimista Probable Pesismista estimada Peso PFNúmero entradas usuario 20 3 24 4 30 6 24 4 96Número salidas usuario 12 4 15 5 22 7 16 5 80Número peticiones usuario 16 3 22 4 28 6 22 4 88Número de archivos 4 7 4 10 5 15 4 10 40Número interfaces externas 2 5 2 7 3 10 2 7 14Cuenta Total 318

Estimación de los valores del dominio:

El factor de ponderación se obtiene desde las medidas originales

La cuenta estimada se obtiene usando la fórmula de VE

La Cuenta PF es la cuenta estimada por peso

El peso corresponde al VE de los factores de ponderación

Estimación basada en el Problema:Ejemplo PF:



Estimaciónde Proyectos de SwFactor Valor

1 ¿Requiere el sistema copias de seguridad y derecuperación fiables? 4

2 ¿Se requieren comunicaciones de datos? 23 ¿Existen funciones de procesamiento distribuido? 04 ¿Es crítico el rendimiento? 45 ¿Será ejecutado el sistema en un entorno operativo

existente y frecuentemente utilizado? 36 ¿Requiere el sistema entrada de datos interactiva? 47 ¿Requiere la entrada de datos interactiva que las

transacciones de entrada se lleven a cabo sobremúltiples pantallas o variadas operaciones? 5

8 ¿Se actualizan los archivos maestros de formainteractiva? 3

9 ¿Son complejas las entradas, las salidas, losarchivos o las peticiones? 5

10 ¿Es complejo el procesamiento interno? 511 ¿Se ha diseñado el código para ser reutilizable? 412 ¿Están incluidas en el diseño la conversión y la

instalación? 313 ¿Se ha diseñado el sistema para soportar múltiples

instalaciones en diferentes organizaciones? 514 ¿Se ha diseñado la aplicación para facilitar los

cambios y para ser fácilmente utilizada por elusuario? 5Factor de ajuste de la complejidad 1.17

Pf estimado= (factor ajuste*cuenta total) 372

Si la productividad media histórica es de 6.5 PF/pm a 8.000 unidades monetarias por mes se tiene que cuánto es el :

Costo PF mes

Costo total del proyecto

Esfuerzo estimado

PF = cuenta-total x [ 0,65 + 0,01 x Σ( Fi ) ]

1230.76 ≈ 1,231um (8000/6.5)

457,932 um (372*1,231)

57.23 ≈ 57 pm (372/6.5)



[email protected]




http://www.face.ubiobio.cl/~mcaro/




Estimación de Proyectos de Sw


Estimación basada en el Proceso:

La técnica más común para estimar un proyecto es basar la estimación en el proceso que se empleará.El proceso se descompone en un pequeño conjunto de tareas y luego se definen las funciones del Sw. Con estos se construye una matriz.Luego, se estima el esfuerzo requerido para lograr cada función-tarea, por ejemplo en personas-mes.



Estimación basada en el Proceso, un ejemplo:


Tabla de estimación (esfuerzo en personas mes)

Actividad Cliente Planificación Riesgo Cliente TotalesTarea Análisis Diseño Códi go PruebaFunciónInterface usuario y facilidades de control 0.50 2.50 0.40 5.00 8.40Análisis geométrico dos dimensiones 0.75 4.00 0.60 2.00 7.35Análisis geométrico tres dimensiones 0.50 4.00 1.00 3.00 8.50Gestión de bases de datos 0.50 3.00 1.00 1.50 6.00Facilidades representación gráfica 0.50 3.00 0.75 1.50 5.75Control de periféricos 0.25 2.00 0.50 1.50 4.25Módulos de análisis del diseño 0.50 2.00 0.50 2.00 5.00Totales 0.25 0.25 0.25 3.50 20.50 4.75 16.50 45.25% Esfuerzo 1% 1% 1% 8% 45% 10% 36%

EntregaIngenieria

El 53% del esfuerzo se aplica en las tareas de anal de req. y diseño. A 5,000 um por mes, el Costo total del proyecto será: 226,250 (5,000*45.25)Esfuerzo estimado 45.25 ≈

45 personas mes


Estimación basada en Casos de Uso:

Desarrollar un enfoque de estimación basado en casos de uso (CU), tiene algunos problemas:

No existe un formato estándar para describir los CURepresentan una visión externa del Sw (la del usuario) y pueden estar escritos con distintos grados de abstracciónNo abordan la complejidad de las funciones ni de las características que describenNo describen el comportamiento complejo que involucran muchas funciones y características

Hasta ahora no existe un método de estimación probado.



Modelos empíricos de estimación:

Un modelo común de estimación de Sw utiliza fórmulas obtenidas empíricamente para predecir el esfuerzo como una función de LDC o PFEste modelo se deriva a partir de un análisis de regresión sobre los datos recopilados de proyectos anteriores



Modelos empíricos de estimación:

La estructura global de estos modelos es:

E = A + B* (ev)C

Donde A, B y C son constantes obtenidas empíricamente, E es el esfuerzo en personas-mes y ev es la variable de estimación (LDC o PF)E puede ser ajustado a partir otras características del proyecto como: complejidad del problema, experiencia del personal, entorno de desarrollo



Algunos modelos empíricos de estimación, orientados a LDC:


E=5.2*(KLDC)0.91 Walston-Felix

E=5.5+0.73*(KLDC)1.16 Bailey-Basili

E=3.2*(KLDC)1.05 Simple de Boehm

E=5.288*(KLDC)1.047 Doty para KLDC>9


Algunos modelos empíricos de estimación, orientados a PF:


E=13.39+0.0545PF Albretch y Gaffney

E=60.62*7.728*10-8PF3 Kemerer

E=585.7+15.12PF Matson, Barnett y Mellichamp

Los modelos presentados entregarán valores diferentes para iguales valores de LDC y PF por lo que estos modelos deben calibrarse para necesidades locales


COCOMO

Es un modelo empírico de estimación (Boehm, 1981), fundamentado en tres niveles para la estimación de esfuerzo y plazos para el desarrollo de software, que recibe el nombre genérico de COCOMO (COnstructive COst MOdel)COCOMO81, proceso en cascada y desarrollo desde cero.El modelo original ha evolucionado a un modelo más completo llamado COCOMO II (Boehm,1996,2000)Es uno de los modelos de estimación de costos más utilizados y estudiados en la industria



COCOMO II, considera 3 niveles:

Nivel de construcción de prototipos inicial: Se utiliza en las primeras etapas de la ingeniería del software donde el prototipado de las interfaces de usuarios, la interacción del sistema y del software, la evaluación del rendimiento y la evaluación de la madurez de la tecnología son de suma importancia.Nivel de diseño inicial: Utilizado una vez que se han estabilizado los requisitos y que se ha establecido la estructura básica del softwareNivel postarquitectónico: Utilizado durante la construcción del software



COCOMO II requiere información del tamaño para lo cual puede utilizar:

Puntos objeto, Puntos de función o Líneas de códigoEl COCOMO II utiliza puntos objeto (PO) que es una medida indirecta de software que se calcula utilizando el total de:

Pantallas de la interfase de usuarioInformesComponentes que probablemente se utilicen para construir la aplicación

Cada instancia de objeto se clasifica en uno de tres niveles de complejidad, aplicando criterios sugeridos por Boehm.



COCOMO II :La complejidad es una función del número y origen de las tablas de datos y el servidor necesario para generar la pantalla o el informe, y el número de vistas o secciones presentadas como parte de la pantalla o del informe. Ejemplo:


Tipo de objeto Básico Intermedio Avanzado

Pantalla 1 2 3

Informe 2 5 8

Componente L3G 10

Peso de la Complejidad


COCOMO II :La cuenta de PO se obtiene multiplicando el número original de instancias de objeto por el factor de ponderación y se suma para obtener una cuenta total de PO.

Cuando se va a usar desarrollo basado en componentes o cuando se reutilizará software hay que estimar un % de reutilización y se ajusta la cuenta total de Puntos Objeto.


TPO=(PO)* [(100-%reutilización)/100]


COCOMO II :Luego para calcular el esfuerzo en personas mes (PM) se aplica la fórmula:

Donde PROD es la productividad, deducida desde una tabla como:


PM =(TPO/PROD)

Experiencia y Capacidad de los desarrolladores

Muy Baja

Baja Media Alta Muy Alta

Madurez y Capacidad Muy Baja

Baja Media Alta Muy Alta

PROD (TPO/mes) 4 7 13 25 50


COCOMO II, Otras fórmulas del modelo aplicables a los otros niveles:Nivel de diseño inicial:

Donde,A = 2.5Tamaño, es expresado en míles de líneas de código fuenteB, refleja el esfuerzo en relación al tamaño del proyecto. Este varía entre 1 y 1.24, dependiendo de algunos factores (novedad, flexibilidad de desarrollo, gestión de riesgos, cohesión del equipo, madurez del proceso de la organización.M, factor derivado de un conjunto de 7 conductores de proyectosPM, factor asociado a la generación de código automático y que para su cálculo considera la productividad bajo este esquema.


P = A x TamañoB x M + PMm


COCOMO II, otras fórmulas del modelo aplicables a los otros niveles:Nivel postarquitectónico:

Donde la fórmula se basa en la misma del nivel anterior, con las siguientes variantes:

M, factor derivado de un conjunto de 17 conductores de proyectosLa estimación del número total de líneas de código se ajusta considerando la Volatilidad de los requerimientos y la Amplitud de la posible reutilización.

Para más detalles sobre COCOMO II:

Ingeniería de Software, Somerville.


P = A x TamañoB x M + PMm

http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html


Algunas Reflexiones (1/4):

Es difícil estimar Tamaño en una primera etapa de un proyecto cuando sólo se tiene la especificación. PF y PO son más fáciles de producir pero más imprecisas.Algunas estimaciones son subjetivas y varían de una persona a otra, dependiendo de su conocimiento y experiencia.Las LDC de un sistema terminado son la métrica básica para la estimación.



Algunas Reflexiones (2/4) :

El planificador del proyecto tiene que estimar 3 cosas antes que comience el proyecto:

Cuánto duraráCuánto esfuerzo requeriráCuánta gente estará implicada

Además, debe predecir los recursos (Hardware y Software) que se requerirán y el riesgo asociadoLa especificación del ámbito ayuda al planificador a desarrollar estimaciones mediante: descomposición, modelización empírica y herramientas automatizadas.




Las técnicas de descomposición, requiere un esbozo de las principales funciones del software, seguido de estimaciones del número de LDC o de PF, o el número de personas-mes requeridas para implementar cada función.Las técnicas empíricas, usan expresiones derivadas empíricamente para determinar el esfuerzo y tiempo, con las que se predicen estos valores en el proyecto.Las herramientas automáticas, implementan un determinado modelo empírico.En cualquier caso, para estimaciones precisas, se recomienda utilizar al menos dos de las tres técnicas.




Resulta conveniente disminuir el esfuerzo aplicado a los proyectos, disminuyendo el tamaño de los mismos o aumentando la calidad del ambiente de desarrollo o aumentando el plazo de desarrollo. Por tanto es recomendable considerar:

Adquisición de paquetes Uso de lenguajes de cuarta generación PrototiposMejorar la oficina de programaciónDisminuir las interrupcionesReutilizar el códigoUsar componentes



¿Comprar o Desarrollar?

En muchas áreas de aplicación del software, a menudo es más barato adquirir un software que desarrollarlo. Los gestores se enfrentan a una decisión de hacer o comprar:

se puede comprar software (o licencia de uso) ya desarrollado.se puede comprar componentes de software “totalmente experimentado” o “parcialmente experimentado”, acomodándolo a las necesidades específicasse puede encargar a terceros la construcción considerando los requerimientos propios de la empresa



Adquisición de Sw:

Los pasos a seguir en la adquisición de software estarán dados por el grado crítico del software a comprar y por el costo final.

En el caso de paquetes de software de bajo costo, es menos caro comprarlo y experimentar con él, que llevar a cabo una larga evaluación del mismo.Para paquetes de software caros, se puede aplicar una serie de directrices que ayuden a resolver el problema



Directrices para adquirir Sw (1/2):

Hacer una especificación de la función y el rendimiento deseado para el Sw. Definir características medibles (si es posible).

Estimar el costo del desarrollo interno y la fecha de entrega.

Seleccionar:los tres o cuatro software que mejor se ajusten a la especificación.componentes de software reutilizables



Directrices para adquirir Sw (2/2):

Desarrollar una matriz que presente comparaciones de las funciones claves. Realizar el seguimiento de las pruebas de evaluación para comparar el software candidato

Evaluar cada paquete basándose en la calidad de anteriores productos, en el soporte de ventas, reputación, etc.

Contactarse con otros usuarios del software y pedirles su opinión.




La decisión de hacer o comprar debe tomarse teniendo en cuenta las siguientes preguntas:

¿Será, el producto de software, entregado con anterioridad al software desarrollado internamente?

¿Será el costo de adquisición, junto con el de adaptación, menor que el costo del desarrollo interno del software?

¿Será menor el costo del soporte externo (p.e. un contrato de mantenimiento) que el costo del soporte interno?




Se puede utilizar técnicas estadísticas como el análisis de árboles decisión.Ejemplo:

Una organización puede:

• Construir el sistema X desde el principio• Reutilizar un sistema existente realizando alguna modificación• Comprar un producto de software disponible y modificarlo para

que se ajuste a las necesidades concretas.• Contratar el desarrollo del software a un externo




Sistema X

Construir

Contratar

Comprar

Reusar

Sencillo (0,30)

Dificil (0,70)

Sencillo (0,20)

Pocos cambios (0,40)

Muchos cambios (0,60)

$380.000

$450.000

$275.000

$310.000

Complejo (0,80)

$490.000

$210.000

$400.000

$350.000

$500.000



Con cambios (0,40)

Sin cambios (0,60)



Si se construye hay un 70% que el trabajo sea complicado. Mediante las técnicas de estimación se estima que un esfuerzo de desarrollo difícil costará $450.000 y uno sencillo costará $380.000.El valor esperado para el costo para cualquier camino del árbol de decisión es:

costo esperado = Σ

(probabilidad del camino)i * (costo estimado del camino)i

Donde i es el camino del árbol de decisión




Sistema X

Construir

Contratar

Comprar

Reusar

Sencillo (0,30)

Dificil (0,70)

Sencillo (0,20)



$380.000

$450.000

$275.000

$310.000

Complejo (0,80)

$490.000

$210.000

$400.000

$350.000

$500.000



Con cambios (0,40)

Sin cambios (0,60)

Costo esperado construir = (0.40 * $380K) + (0.70 * $450K)= $429K

Costo esperado construir = (0.40 * $380K) + (0.70 * $450K)= $429K

Costo esperado de construir = Σ

(probabilidad del camino)i * (costo estimado del camino)i



Sistema X

Construir

Contratar

Comprar

Reutilizar

Sencillo (0,30)

Dificil (0,70)

Sencillo (0,20)



$380.000

$450.000

$275.000

$310.000

Complejo (0,80)

$490.000

$210.000

$400.000

$350.000

$500.000



Con cambios (0,40)

Sin cambios (0,60)

Costo esperado reutilizar = (0.30 * $275K) + 0.60*((0.20 * $310K)+ (0.80*$490K)) = $382K

Costo esperado reutilizar = (0.30 * $275K) + 0.60*((0.20 * $310K)+ (0.80*$490K)) = $382K



Sistema X

Construir

Contratar

Comprar

Reusar

Sencillo (0,30)

Dificil (0,70)

Sencillo (0,20)



$380.000

$450.000

$275.000

$310.000

Complejo (0,80)

$490.000

$210.000

$400.000

$350.000

$500.000



Con cambios (0,40)

Sin cambios (0,60)

Costo esperado comprar = (0.70 * $210K) + (0.30 * $400K) = $267K

Costo esperado comprar = (0.70 * $210K) + (0.30 * $400K) = $267K

$380.000



Sistema X

Construir

Contratar

Comprar

Reusar

Sencillo (0,30)

Dificil (0,70)

Sencillo (0,20)



$380.000

$450.000

$275.000

$310.000

Complejo (0,80)

$490.000

$210.000

$400.000

$350.000

$500.000



Con cambios (0,40)

Sin cambios (0,60)

Costo esperado contratar = (0.60 * $350K) + (0.40 * $500K) = $410K

Costo esperado contratar = (0.60 * $350K) + (0.40 * $500K) = $410K

1



[email protected]







2


El objetivo de la Ing. de Software es la mejora de procesos, recursos y métodos que permitan producir y mantener mejores productos.Las métricas son un aspecto relevante en I. de Sw, permiten generar descripciones cuantitativas de dónde se está parado y a dónde se pretende ir.Cuantificar donde se pueda y lo que se pueda permite describir nuestras acciones y sus resultados en un lenguaje común que permite evaluar nuestros progresos.La medición es una herramienta eficaz para tratar de solucionar problemas del mundo real.

Métricasde Proyectos de Sw


Medida: proporciona una indicación cuantitativa, de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto. (ej.: número de errores descubiertos en la revisión de un módulo)Medición: acto de determinar una medida (ej.: se investiga el número de revisiones de módulos para recopilar medidas del número de errores encontrados durante cada revisión)Métrica: medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE-1993) (ej.:promedio errores encontrados por revisión o promedio de errores encontrados por persona y hora en revisiones)Indicador: es una métrica o combinación de métricas que proporcionan una visión profunda del proceso de software, del proyecto o del producto


3


Las razones para crear métricas del software, de los productos y los recursos son:

Caracterizar: para comprender mejor y establecer la base para comparaciones con futuras mediciones.Evaluar: para determinar el estado respecto del diseño y para valorar la consecución de objetivos de calidad, el impacto de la tecnología y las mejoras del proceso.Predecir: para planificar. Constituyen la base para la comprensión de relaciones entre procesos y productos y construir modelos de dichas relaciones, y a futuro la extrapolación de tendencias para la estimación de costo, tiempo y calidadMejorar: para identificar barricadas, causas raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el desempeño del proceso



Las métricas del proceso se recopilan en el curso de todos los proyectos durante largos periodos.Se mide para obtener un conjunto de indicadores de proceso que conduzcan a la mejora de los procesos de Sw a largo plazo.Los indicadores de proyectos permiten:

evaluar el estado del proyectoseguir la pista de riesgos potencialesdetectar áreas de problemas antes de que se conviertan en “críticas”ajustar el flujo y las tareas del trabajoy evaluar la habilidad del equipo de proyectos en controlar la calidad de los productos de trabajo de Sw


4


En resumen, la medición del proceso y de los proyectos de Sw se justifica:

Para conocer la calidad del productoPara evaluar la productividad de las personas que lo producenPara evaluar los beneficios de nuevas herramientas de softwarePara formar una base a fin de estimarPara justificar nuevas herramientas o entrenamientos adicionales.



El proceso de medición se caracteriza por 5 actividades (Roche, 1994):

Formulación: Derivación de medidas y métricas apropiadas para la representación del Sw que se considera.Recolección: Mecanismo con el que se acumulan datos para derivar las medidas formuladas.Análisis: Cálculo de las métricas, uso de herramientas matemáticas.Interpretación: Evaluación de las métricas y los valores calculados para ellas.Retroalimentación: Recomendaciones derivadas de la interpretación de las métricas del producto y transmisión de éstas al equipo del software.


5


Entre otros, los datos recopilados en un proceso de Sw permite obtener métricas tales como:

medidas de errores detectados antes de la entrega del software,defectos detectados e informados a los usuarios finales,productos de trabajo entregados (productividad),esfuerzo humano y tiempo consumido,ajuste a la panificación, etc.



Las métricas pueden ser:

Métricas privadas: aquellas que corresponden a datos propios de un individuo que deben ser usados privadamente por ejemplo, índices de defectos, errores por módulo, errores encontrados en el desarrollo

Métricas públicas: asimilan información que originalmente era privada de particulares y equipos. Por ejemplo, índice de defectos a nivel de proyecto (no atribuidos absolutamente a un particular)


6


Algunos lineamientos a aplicar cuando se recopilan métricas de Sw:

Utilice el sentido común y una sensibilidad organizativa para interpretar los datos de las métricasProporcione retroalimentación a particulares y equipos que hayan participado en la recopilación de medidas y métricasNo utilice métricas para evaluar a particularesTrabaje con profesionales y equipos para establecer objetivos claros y métricas que se vayan a utilizar para alcanzarlos.No utilice nunca métricas que amenacen a particulares y equiposLos datos de métrica que indiquen un área problema no se debieran considerar “negativos”, son sólo un indicador de mejora en el proceso.No se obsesione con una sola métrica y excluya otras métricas importantes.



Las medidas puede ser directas (longitud de un objeto determinado) o indirectas (calidad de un determinado objeto):

Medidas directas: el costo, el esfuerzo aplicado, las líneas de código producidas (LDC), la velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado periodo de tiempo.Medidas Indirectas: funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento.


7


Métricas orientadas al tamaño:Son medidas directas del software y del proceso por el cual se desarrolla.Si una organización mantiene registros sencillos se puede crear una tabla con datos orientados al tamaño.

Métricas: Errores por KLDC, defectos por KLDC, $ por LDC, páginas de documentación por LDC, Errores por persona-mes, LDC por persona-mes, $ por página de documentación


Proyecto LD C Esfuerzo C osto Pag. D oc. Errores D efectos PersonasAlfa 12,100 24 168 365 134 29 3Beta 27,200 62 440 1,224 321 86 5G am m a 20,200 43 314 1,050 256 64 6


Métricas orientadas a la función:Se centran en la funcionalidad o utilidad del programa como un valor de normalización.La funcionalidad no es medida directamente por lo que debe ser derivada indirectamente desde otras medidas.Los puntos de Función (PF) se derivan de una relación empírica desde medidas contables (directas) del dominio de la información del software y de las evaluaciones de la complejidad del software.Puntos de función: Número de entradas de usuario, Número de salidas de usuario, Número de peticiones, Número de archivos, Número de interfaces externas


8


Métricas orientadas a la función:Mediante cuestionarios se ajustan los puntos de función dependiendo de la complejidad que presentan.Una vez calculados los puntos de función, se usan de forma análoga a las LDC como medida de la productividad y calidad. Ej.: Productividad = PF / personas-mes, Calidad = errores / PF, Costos = $ / PF,Documentación = páginas de documentación / PFMétricas ampliadas de Puntos de función :

Los puntos de características (Jones,1991) permiten una más adecuada descripción de aplicaciones de complejidad algorítmica alta, de tiempo real, de control de procesos y de sistemas empotrados.

Los puntos de función 3D (Whitmire, 1995): integra la dimensión de datos, funcional y de control



Relación entre LDC y PFs: Depende del lenguaje


Lenguaje de programación LDC/PF (media)Ensamblador 320C 128CoBOL 106FORTRAN 106Pascal 90C++ 64Ada95 53Visual Basic 32Small Talk 22Powerbuilder (generador de código) 16SQL 12

Una LCD en C++ proporciona aproximadamente 1,6 veces la funcionalidad que una LDC de FORTRAN

Visual Basic proporciona 3 veces la funcionalidad que una LDC de un lenguaje convencional

Número medio de LDC por cada punto de función

9


Métricas orientadas a objetos:Las métricas convencionales (LDC y PF) no proporcionan suficiente granularidad para la planificación y los ajustes de esfuerzo que se requieren en un proceso incremental.Entre otras métricas podemos mencionar las sgtes. (Lorenz y Kidd)

Número de guiones de escenarioNúmero de clases claveNúmero de clases de apoyoNúmero promedio de clases de apoyo por clase claveNúmero de subsistemas



Métricas de proyectos de ingeniería Web:Las medidas y métricas de proyectos tradicionales de Ing. de Sw son difíciles de traducir directamente a aplicaciones Web. Entre otras métricas que se pueden utilizar:

Número de páginas Web estáticasNúmero de páginas Web dinámicasNúmero de vínculos internos de páginaNúmero de objetos de datos persistentesNúmero de objetos con contenido estático Número de objetos con contenido dinámico Número de funciones ejecutables


10


Métricas para la calidad del Sw:

Métricas previas a la entrega del software, incluyen:Complejidad del programaModularidad efectivaTamaño del programa global.

Métricas post-distribución incluyen:CorrecciónFacilidad de mantenimientoIntegridadFacilidad de uso



Línea base:Sirve como base para la estimación.Consiste en datos recogidos de anteriores proyectos de desarrollo de Sw, pudiendo ser muy sencilla Además, de simples medidas orientadas al tamaño o a la función, la línea de base se puede completar con métricas de calidad.


11


Línea base:Para que sea una ayuda efectiva en la planificación estratégica y/o en las estimaciones de costo y esfuerzos, los datos de la línea base tienen que poseer los siguientes atributos:

Los datos deben ser razonablemente precisos, han de evitarse “suposiciones” sobre proyectos anteriores.

Los datos deben obtenerse de tantos proyectos como sea posible.

Las medidas tienen que ser consistentes.Las aplicaciones deben ser similares a la que vaya a ser

estimada.



Línea base:Proceso para establecer una línea base:

Recolección de datos, requiere una investigación histórica de proyectos pasados para reconstruir los datos requeridos.

Cálculo de métricas, LDC o PF.Evaluación de los datos, se centra en las razones intrínsecas de

los resultados obtenidos. ¿Son relevantes las métricas calculadas para el proyecto actual?, ¿Qué circunstancias atenuantes invalidan ciertos datos a ser utilizados en esta estimación?

El modelo incluye datos de costo, datos orientados al tamaño y datos orientados a la función, permitiendo el cálculo tanto de métricas orientadas al LDC como a PF.


12


Proceso de recopilación de métricas:


Proyectode software

Procesode ingenieríade software

Productode software

Recopilaciónde datos

Recopilaciónde datos

Evaluaciónde métricasEvaluaciónde métricas

Cálculode métricas

Cálculode métricas

Medidas

Métricas

Indicadores





Bibliografía

1



[email protected]







2


Identificar, analizar y dar respuesta a los riesgos del proyecto Maximizar la probabilidad y consecuencias de eventos positivos, yMinimizar las de eventos negativos

Análisis y Gestión de Riesgos


Tipos de riesgos (1/2):Riesgos estratégicos de la empresa: pérdidas, inversiones, imagen, etc.Riesgos comerciales: problemas con la venta del producto, seguimiento del cliente, precio, pérdida de cliente, venta por debajo del precio real, etc.Riesgos contractuales y financieros: relacionados con los términos contractuales negociados ante la firma del contrato (penalizaciones, niveles de calidad, calendario de pagos, impagos, aumento de trabajo sin compensación, etc.)Riesgos de gestión: recursos, equipo, calendario, estimaciones, subcontratas, etc.


3


Tipos de riesgos (2/2):Riesgos técnicos: especificación, diseño, realización, integración, etc.Riesgos de explotación: fallos del sistema que conducen a accidentes graves.Riesgos de mantenimiento: sobrecostos en mantenimiento



Estrategias para enfrentar los riesgos:Reactivas:

Indiana Jones, “no te preocupes pensaré en algo”Modo Bombero, no hacer nada hasta que algo salga mal

Proactivas:Comienza antes de que se inicie el trabajo técnicoSe genera un plan para gestionar el riesgo (evitarlo o responder en forma controlada y efectiva).


4


Procesos (1/4):

Planificación de la gestión de riesgos: decidir cómo abordar las actividades de gestión de riesgos y planificarlas.

Identificación de riesgos: determinar los riesgos que podrían afectar al proyecto y documentar sus características. Un método, es crear una lista de verificación de riesgos. Luego estos pueden identificarse y clasificarse en algún subconjunto de riesgos conocidos y predecibles.



Procesos(2/4):

Identificación de riesgos: Los riesgos puede clasificarse en las categorías:

Tamaño del productoImpacto en el negocio (restricciones de la empresa o mercado)Características del ClienteDefinición del procesoEntorno del desarrolloTecnología que construirTamaño y experiencia del personal


5


Procesos (3/4):Análisis cualitativo de los riesgos: analizar cualitativamente los riesgos y condiciones para priorizar sus efectos sobre los objetivos del proyecto.Análisis cuantitativo de los riesgos: determinar la probabilidad y consecuencias de los riesgos y estimar sus implicaciones para los objetivos del proyecto. Uso de plantillas que crucen riesgos, impacto, probabilidades de ocurrencia. Datos que servirán de base para afrontar la ocurrencia efectiva de ciertos hechos.



Procesos (4/4):Planificar respuestas frente a los riesgos: establecer procedimientos y técnicas para aprovechar las oportunidades de mejorar y reducir las amenazas a los objetivos del proyecto.Supervisión y control de riesgos: supervisar riesgos residuales, identificar nuevos riesgos, ejecutar planes de reducción de riesgos, y evaluar sus efectividad a lo largo de la vida del proyecto.


6


Ejemplo:Identificación: Integración de componentes para reutilización 70%, el porcentaje restante se debe desarrollar.Probabilidad: 80%Impacto: Si se planificaron 80 componentes, 18 deben desarrollarse desde cero, lo que tendrá un impacto económico en el proyecto (800 u. monetarias)Exposición al riesgo:

ER= P x C (Prob x Costo)ER = 0.8 x 800 u.m -> 640 u.m.



Ejemplo 1 Plantilla:


Planes de Mitigación Nivelar a los miembros del grupo en relación a los conocimientos técnicos importantes para la evolución del proyecto. Planear capacitaciones de tecnología en el área que se considere necesario. Rotación de los integrantes del equipo entre las diferentes capas de desarrollo: vista, lógica y persistencia.

Descripción y Explicación Si alguno o algunos de los miembros del grupo no tienen el conocimiento técnico necesario para desarrollar el proyecto, el proyecto se puede ver afectado ya que se requiere mayor cantidad de tiempo y esfuerzo por parte de los demás miembros del equipo.

Baja Probabilidad:

Medio Impacto:

1Prioridad:

Retrasos y problemas debido a temas técnicos (tecnología, plataforma elegida, etc.)

Nombre:

7


Ejemplo 2 Plantilla:


Planes de Mitigación En cada reunión, los miembros del grupo deben hacer aportes para la realización del proyecto, con miras al bien común del equipo. Se deben utilizar herramientas que faciliten la comunicación entre los miembros del grupo. Todo lo pactado debe quedar registrado por escrito y publicado en la página web del grupo.

Descripción y Explicación Si se presentan problemas de comunicación dentro del grupo, el proyecto se ve afectado, ya que se pierde efectividad y la comprensión global y específica acerca del mismo disminuye. De igual manera puede resultar en una mala interpretación del contexto del problema, una incorrecta interpretación de las estrategias de solución; puede además propiciar inconvenientes entre los miembros del grupo y generar problemas a la hora de asignar y desarrollar actividades.

Media Probabilidad:

Alto Impacto:

2 Prioridad:

Problemas de comunicación al interior del grupo Nombre:




8


Los proyectos se salen de la agenda día a día.Un descuido de un día raramente será fatal para el proyecto, pero los días se van acumulando…Si se ha definido en forma adecuada, la calendarización del proyecto define las tareas e hitos que se deben seguir y controlar conforme avanza el proyecto

Seguimientode Proyectos de Sw


Formas de seguimiento (1/2):Realizando reuniones periódicas para valorar el estado del proyecto, en las cuales cada miembro del equipo informa de los progresos y de los problemas.Evaluando los resultados de todas las revisiones realizadas en todo el proceso de ingeniería de software.Determinando si los hitos formales se han alcanzado en la fecha programada.


9


Formas de seguimiento (2/2):Comparando la fecha de comienzo real con la planificada, para cada tarea del proyecto.Reuniéndose informalmente con los técnicos para conocer sus valoraciones subjetivas acerca del progreso de cada momento y los problemas que acechan en el horizonte.Usando el análisis del valor obtenido para evaluar el progreso cuantitativamente.





10


El problema de la calidad del software es un problema tan antiguo como el mismo software.No es necesario ser un experto en control de calidad para darse cuenta que uno de los aspectos fundamentales está dado por los errores que éste pueda presentar en tiempo de explotación.Es claro que si un producto software presenta errores al momento de ser utilizado, ese producto pierde confiabilidad a ojos del usuario hasta el nivel que podría ser desechado como un producto defectuoso.

Garantía de Calidad del Sw


La calidad del software no es adecuado consignarla solamente a su aspecto dado por los errores de tiempo de explotación, también hay otros aspectos que son importantes al hablar de calidad en un software.

Uno puede ser el soporte.


11


Soporte:El soporte define el respaldo organizacional que tiene un producto.Corresponde a todos aquellos elementos organizacionales que apoyan la introducción y el mantenimiento de un producto en su ambiente de trabajo, como:

la capacitación,la asistencia de problemas inesperados,el mantenimiento permanente, yla rápida respuesta a emergencias por nombrar algunos



Validación & Verificación:Si nos remitimos a la distinción problema-solución, la calidad la identificamos con la noción de solución.Esto nos remite a su vez a dos aspectos:

por un lado a la solución software, al producto y, por otro lado, al uso que se haga del software.

Esto se ha consignado en la literatura especializada como la dualidad Verificación y Validación (V&V).


12


Validación & Verificación:La verificación se refiere al conjunto de actividades que aseguran que el software describe correctamente lo operación que realiza.¿Estamos construyendo el producto correctamente?

La validación se refiere a un conjunto de actividades que aseguran que el software construido se ajusta a los requerimientos del cliente.¿Estamos construyendo el producto correcto?



Validación & Verificación:

Verificar comprende comprobar que el software esté de acuerdo con su especificación. Comprueba que el sistema cumple con sus requerimientos funcionales y no funcionales especificados.Se debe asegurar que el software cumple las expectativas del cliente (validación). Va más allá de comprobar si el sistema está acorde con su especificación.


13


Verificación: Las actividades de verificación se pueden pensar como controles intermedios que puedan ser activados en cada etapa de desarrollo, por ejemplo:

Al construir módulos de programa, el uso de nombres significativos, la programación estructurada, la eficiencia en el uso de memoria u otro que se considere importante para el tipo de aplicación que se está desarrollando. Establecer de procesos de prueba en cada una de las etapas de desarrollo, situación que es muy aconsejable ya que reduce significativamente la tasa de errores acumulados en el proceso, con el beneficio de una reducción importante de los costos.



Validación: Al estar relacionada con el uso que hacen de él los usuarios plantea formas distintas de ver la calidad en el desarrollo.

La calidad desde ésta perspectiva esta más relacionada con aspectos comunicacionales que técnicos, La calidad es algo que ya no es medible y perfectible desde el seno de la organización que desarrolla Sw sino que ahora es motivo de un diálogo entre ésta y la organización usuaria.Los elementos que aportan calidad al desarrollo desde esta perspectiva son, por ejemplo, el prototipo, el uso en condiciones reales del software, el desarrollo de un lenguaje común de especificación y diseño, la visualización amplia del problema de software, etc. Todos elementos que están orientados a aportar en la validación del Sw como solución.


14


Proceso de Validación& Verificación:Es importante llevar a cabo la validación de los requerimientos del sistema de forma inicial.Es fácil cometer errores y omisiones en los requerimientos del sistema, y en tales casos, el SW final no cumplirá las expectativas de los clientes.Sin embargo, la validación no puede descubrir todos los problemas de requerimientos, algunas veces hay defectos y deficiencias en los requerimientos que sólo se pueden descubrir cuando la implementación se completa.



Eliminación Temprana de Defectos:Independiente de que se aplique un conjunto de pruebas al Sw que requieran que este esté completo para hacerlo, la gestión de calidad es más beneficiosa en la medida que es posible incorporar elementos de ella en etapas más tempranas del ciclo de desarrollo de Sw.Es claro que un error de desarrollo entre más cerca de su fuente de origen se detecte será más fácil de corregir y por lo mismo su costo será mucho menor.Es importante notar que según estudios, las actividades de diseño son las que introducen el mayor porcentaje de defectos en las fases de desarrollo del proceso de ingeniería de software, alrededor de un 60%.


15


Eliminación Temprana de Defectos:La importancia de lo anterior radica en, como decíamos, el impacto que tienen las actividades tempranas de detección de errores, según estudios la proporción del costo de un error se puede describir como:

un error no descubierto durante el diseño cuesta corregirlo 1,0 unidades monetarias. de acuerdo a este valor, el mismo error descubierto justo después de que comienza la prueba costará6,5 unidades; durante la prueba, 15 unidades;y tras lanzar el software, 67 unidades.



Eliminación Temprana de Defectos: Ejemplo Fig.1


16







17







18


Ejemplo Tabla Costo:Ahora si lo anterior lo vemos desde la perspectiva de los costos, recordando los valores relativos que significa corregir un error en cada etapa el costo total comparativo entre estás dos estrategias


Sin revisiones

Errores Encontrados Número Costo Unitario deCorrección

Total

Antes de la prueba 22 6.5 143Durante la prueba 82 15.0 1.230Tras la emisión 12 67.0 804

Total 2.177

Con revisiones tempranas

Errores Encontrados Número Costo Unitario deCorrección

Total

Durante el diseño 22 1.5 33Antes de la prueba 36 6.5 234Durante la prueba 15 15.0 315Tras la emisión 3 67.0 201

Total 783


Proceso de Validación & Verificación: Se utilizan 2 técnicas de comprobación y análisis de sistemas:

Inspecciones del software, analizan y comprueban las representaciones del sistema como el documento de requerimientos, los diagramas de diseño y el código fuente. Se consideran técnicas estáticas de V&V ya que no requieren que el sistema se ejecute.Pruebas del software, comprender llevar a cabo una implementación del Sw con los datos de prueba y examinar las salidas del Sw y su comportamiento operacional para comprobar que se desempeñe conforme a lo requerido. Esta es una técnica dinámica de V&V ya que se lleva a cabo en una representación ejecutable del sistema.


19


Proceso de Validación & Verificación:Las técnicas estáticas sólo pueden comprobar la correspondencia entre un programa y su especificación (verificación); no pueden comprobar las características no funcionales, como desempeño y fiabilidad.Por lo tanto, para validar un sistema se requieren llevar a cabo algunas pruebas.Aunque en la actualidad las inspecciones de software se usan ampliamente, las pruebas de programas es aún la técnica de V&Vpredominante.



Proceso de V & V: Pruebas del softwareLlevar a cabo pruebas comprende hacer prácticas con los programas utilizando datos similares a los datos reales procesados por el programa.La existencia de defectos o insuficiencias se obtiene examinando las salidas del programa y buscando las anomalías.Las pruebas se pueden llevar a cabo durante la fase de implementación para verificar que el Sw se comporta tal como lo pretendió el diseñador.Y después de que la implementación estécompleta.


20


Proceso de V & V: Pruebas del software

Existen 2 tipos de pruebas:

Las pruebas de defectos, pretenden encontrar las inconsistencias entre un programa y su especificación, por lo general se deben a fallas o defectos del programa.Las pruebas se diseñan para revelar la presencia de defectos en el sistema más que para simular su utilización operacional.



Proceso de V & V: Pruebas del software

Existen 2 tipos de pruebas:

Las pruebas estadísticas, se utilizan para probar el desempeño y la fiabilidad del programa y comprobar como trabaja bajo condiciones operacionales.Las pruebas se diseñan para reflejar las entradas de los usuarios y su frecuencia.El desempeño del sistema se valora midiendo el tiempo de ejecución y el tiempo de respuesta del sistema al momento de procesar los datos


21


Validación & Verificación:

El objetivo final del proceso de V&V es generar la confianza de que el sistema de software “se ajusta a los propósitos”.Esto no quiere decir que el sistema está libre de defectos, más bien que es suficientemente bueno para la utilización que se pretende.El nivel de confianza depende de:

propósito del sistema,las expectativas de los usuarios,el entorno actual del mercado para el sistema



Proceso de Depuración:Los defectos descubiertos deben ser corregidos.Este proceso no necesariamente tiene que estar integrado con el proceso de V&V:

V&V es un proceso que establece la existencia de defectos en un sistema de software.La depuración es un proceso que localiza y corrige estos defectos.

Para localizar la falla, se deben diseñar programas que repliquen la falla original y que ayuden a descubrir la fuente de la falla.Es necesario rastrear el programa manualmente y simular la ejecución.


22


Proceso de Depuración: Pruebas de RegresiónDespués que se descubre un defecto, debe corregirse y luego reevaluar el sistema.Esto implica volver a hacer la inspección al programa o repetir las pruebas anteriores (pruebas de regresión).Las pruebas de regresión se utilizan para comprobar que los cambios realizados a un programa no introdujeron nuevas fallas en el sistema.La experiencia muestra que una proporción alta de las reparaciones de fallas son reparaciones incompletas o introducen nuevas fallas.



Proceso de Depuración: Pruebas de Regresión

En principio, durante las pruebas de regresión, se repiten todas las pruebas de cada reparación del defecto.Como esto es muy caro, en la práctica como parte del plan de pruebas, se identifican las dependencias entre las partes del sistema y las pruebas asociadas con cada parte.Se ejecuta un subconjunto de todo el conjunto de datos de prueba para comprobar el componente modificado y sus dependientes.


23


Verificación & Validación: Plan de Pruebas

El proceso de prueba: descripción de las fases principales del proceso de prueba.Requerimientos de seguimiento: los usuarios están más interesados en que el sistema cumpla sus requerimientos por lo que se planean las pruebas de tal forma que se puedan probar individualmente todos los requerimientos.Elementos probados: se especifican los productos del proceso del software a probar.Calendarización de las pruebas: agenda de todas las pruebas y una asignación de recursos.



Verificación & Validación: Plan de Pruebas

Procedimiento de registro de las pruebas: se deben registrar los resultados de las pruebas en forma sistemática.Requerimientos de hardware y software: indicar las herramientas de software requeridas y la utilización del hardware estimado.Restricciones: se anticipan las restricciones que afectan el proceso de prueba como el de escasez de personal.


24


Inspecciones de Software:Es más barato encontrar errores a través de la inspección que por medio de pruebas extensivas del programas.El proceso de inspección también puede considerar otros atributos de calidad como el ajustamiento a los estándares, la portabilidad y mantención.Varios defectos se detectan en una sola sesión de inspección. Las pruebas a menudo pueden detectar sólo un error por prueba.



Inspecciones de Software:Reutilizan el conocimiento del dominio y del lenguaje de programación. Es más probable que se vean los tipos de errores que comúnmente ocurren en lenguajes de programación particulares.A menudo no es práctico inspeccionar un sistema completo compuesto de varios subsistemas diferentes. Las pruebas son la única técnica de V&V posible en el nivel del sistema.Las pruebas son necesarias para la valoración de la fiabilidad, del análisis de desempeño, la validación de la interfaz de usuario y para comprobar que los requerimientos de Sw son los que el usuario realmente quiere.


25


Inspecciones de Software: Clases de Fallas

Fallas de datos

¿Se inicializan todas las variables antes de que se utilicen sus valores?¿Todas las constantes tienen nombre?¿El límite superior de los arreglos es igual al tamaño del arreglo?Si se utilizan string, ¿se asigna explícitamente un delimitador?¿Existe alguna posibilidad de que el buffer se desborde?




Fallas de entrada/salida

¿Se utilizan todas las variables de entrada?Antes de que salgan, ¿a todas las variables de salida se les asigna un valor?¿Provocan corrupción de los datos las entradas no esperadas?


26



Fallas de control

Para cada instrucción condicional, ¿es correcta la condición?¿Todos los ciclos terminan?¿Están puestas correctamente entre llaves las instrucciones compuestas?En las instrucciones case, ¿se han tomado en cuenta todos los casos posibles?Si se requiere una instrucción break después de cada case en las instrucciones, ¿se incluyó?




Fallas de interfazLas llamadas a funciones tienen el número correcto de parámetros?¿Concuerdan los tipos de parámetros reales y formales?¿Están en el orden correcto los parámetros?Si los componentes acceden a memoria compartida, ¿tienen el mismo modelo de estructura de la memoria compartida?


27



Fallas de administración de excepciones¿Se toman en cuenta todas las condiciones de error posible?

Fallas de administración de almacenamientoSi una estructura vinculada se modifica, ¿se reasignan correctamente todos los vínculos?Si se utiliza almacenamiento dinámico, ¿se asigna correctamente el espacio?¿Se desasigna explícitamente el espacio después de que no se requiere?






Bibliografía

1



[email protected]





IntroducciónInicio de un proyecto (i)

INICIO INICIO PROYECTOPROYECTO

Objetivos

Nivel Empresa

Gestor:- Establece Entorno Inicial

SelecciónGestor Proyecto

Decisión Emprender Proyecto

Nivel Proyecto

Identificar Áreas de RiesgoCalendariosPlanes de TrabajoAsignaciones de Tareas

Plan del Proyecto (versión inicial)

CaracterísticasDeseables

Orígenes ¿Qué quieres hacer?Estudio Viabilidad

Considerar AlternativasEvaluar Alternativas

Económica, Técnica, Legal, Operativa Especificación detallada de la alternativa

seleccionadaEstablecimiento de fechas y compromisos (Plan

Proyecto)

2


Origen de la idea:Cambio de requisitosPetición de un cliente/usuarioPropuesta generada dentro de la organización de desarrolloNecesidad detectada por el Departamento de MarketingRecomendación del personal de mantenimientoDetección a partir de la información obtenida de los usuarios

IntroducciónInicio de un proyecto (ii)


Identificación de alternativasSe debe analizar:

Consideraciones sobre las diferentes alternativasComprar un producto software comercialDesarrollar el producto internamenteDesarrollarlo de forma externa mediante un contratoAutomatizar sólo parcialmente el sistema

La evaluación de cada una de las alternativasEstudio de viabilidad

La especific. detallada de la alternativa seleccionadaEl establecimiento de fechas y de compromisos de trabajo

IntroducciónInicio de un proyecto (iii)

3


Estudio de viabilidad (evaluación de alternativas)“Todos los proyectos son realizables con recursos ilimitados y un tiempo infinito”Aspectos a abordar:

Económico: ¿El beneficio compensa los costos?Técnico: ¿La funcionalidad, el rendimiento y las restricciones son alcanzables?Legal: ¿Los requisitos atentan alguna ley/reglamento?Operativo: ¿Se puede implantar de manera efectiva en la empresa?

Se le suele prestar más atención al análisis costo-beneficio

IntroducciónInicio de un proyecto (iv)


Selección del gestor del proyectoEl gestor debe intervenir desde el principio (decisión de emprenderlo)Características deseables del gestor, entre otras:

LiderazgoComprensión técnicaCompetencia en la gestiónPresteza y decisiónVersatilidad y flexibilidadPrevisiónIntegridad

IntroducciónInicio de un proyecto (v)

4


Estudio de viabilidadAnálisis costo/beneficio

Permite seleccionar la alternativa más beneficiosa y prever las necesidades financierasSe deben tener en cuenta:

Elementos tangiblesElementos intangibles

Costos a considerar:Personal InformáticoConsultoríaSoftware adicionalHardwareInfraestructuraDebidos al usuario

-Beneficios-Automatización-Menos errores-Más velocidad-Más fiabilidad


¿Y después de iniciar el proyecto qué?

5


Unidad 3: Métodos para la Ingeniería de Sw

Ingeniería de requisitosAnálisisDiseño ArquitectónicoDiseño detalladoPrueba de software


Ingeniería de RequisitosEs el proceso de establecer los servicios que el cliente requiere de un sistema y los límites bajo los cuales opera y se desarrolla.

Lo anterior involucra descubrir, documentar y mantener esta información.

Los requisitos son descripciones de servicios del sistema y restricciones que son generadas durante el proceso de ingeniería de requisitos

6


EjemplosSupóngase que hay que desarrollar el software para un sistema de control de una caldera de vapor.

En este contexto:

1. El agua entra en ebullición a 100 Grados Centígrados y a 1 atm de presión

2. El sistema evitará que el agua entre en ebullición

¿Cuál de las afirmaciones es un requisito?

Es decir expresa un deseo u objetivo. Algo que el sistema deberá realizar.


EjemplosPor otro lado, las afirmaciones:

3. El sistema leerá la temperatura del agua por medio del sensor

4. El sistema podrá subir la temperatura del agua por medio del regulador

Describen la conexión del software con el entorno, es decir, describen el comportamiento externo del software. No son metas ni objetivos, pero son necesarios para conseguir las metas y los objetivos (p.ej. para conseguir 2).

Aunque propiamente hablando tan sólo 2) sea un requisito, a la Ingeniería de Requisitos le interesan todas las afirmaciones anteriores, ya que todas aportan información relevante para construir el sistema y

para que el sistema funcione de la manera deseada.

7


Más ejemplosEl sistema mantendrá la temperatura de la caldera entre 70º y 80º.

El sistema mantendrá un registro de todos los materiales de la biblioteca incluyendo libros, periódicos, revistas, videos y CD.

El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN.

El interfaz de usuario se implementará sobre un navegador Web.

El sistema deberá soportar al menos 20 transacciones por segundo.

El sistema permitirá que los nuevos usuario se familiaricen con su uso en menos de 15 minutos.

(req. Entorno)

(req. muy general)

(req. funcional)

(req. implementación)

(req. rendimiento)

(req. Usabilidad)


Tipos de RequisitosRequisitos de usuario

Sentencias en lenguaje natural y diagramas de los servicios que provee el sistema y sus límites operacionales. Escrito para clientes.Expresan las necesidades del usuario.

Requisitos de software o sistemaDescripciones detalladas de los servicios del sistema. Escrito como un contrato entre el cliente y el contratista.Expresan las capacidades que debe tener el software para poder satisfacer los requisitos de usuario.

8


Requisitos funcionales y no funcionales

Requisitos funcionalesSentencias de los servicios que el sistema debe proveer, cómo el sistema debe reaccionar a entradas particulares y cómo se debe comportar el sistema en situaciones particulares.En esencia, qué debe hacer el sistema.

Requisitos no-funcionalesRestricciones sobre los servicios o funciones ofrecidas por el sistema, tales como restricciones de tiempo, del proceso de desarrollo, estándares, etc.En esencia, cuán bien debe hacer las cosas el sistema (-> requisitos de calidad).


Requisitos no funcionales

Requisitos No Funcionales

Requisitos del Producto

Requisitos del Proceso

Requisitos Externos

Usabilidad

Eficiencia

Ejecución

Espacio

Portabilidad

Fiabilidad

Entrega

Implementación

Estándares

Interacción

Ética

Legislación

Privacidad

Seguridad

Algunas Clasificaciones: IEEE 830-1993:

RendimientoInterfazOperacionalesRecursosVerificaciónAceptaciónDocumentaciónSeguridadPortabilidadCalidadFiabilidadMantenibilidadSeguridad Física

9


Problemas en requisitos

La obtención de requisitos es una tarea difícil, por:

Problemas de ámbito. Límite del sistema mal definido. Problemas de comprensión. Los clientes/usuarios no están seguros de lo que necesitan.Problemas de volatilidad. Los problemas cambian a medida que transcurre el tiempo.


Obtención de requisitos

Para minimizar los problemas, la recopilación de requisitos se debe realizar de manera organizada:

Pressman:InicioObtenciónElaboraciónNegociaciónEspecificaciónValidaciónGestión de requisitos

Sommerville:Identificación de los requisitosAnálisis de requisitos y negociaciónEspecificación de requisitosModelado del sistemaValidación de requisitosGestión de requisitos

10


Ingeniería de requisitosIdentificación de requisitos(Elicitación): Determinación de qué es lo que quiere el cliente/usuario.Análisis y negociación de requisitos: Se deben entender los requerimientos de los diferentes clientes/usuarios y relacionarlos de manera que sea posible alcanzar un resultado final exitoso.Especificación de requisitos: Construcción de un modelo tangible de requisitos.


Ingeniería de requisitosModelado del sistema: Construcción de una representación de los requisitos para que pueda ser evaluada por su correctitud, completitud y consistencia.Validación de requisitos: Revisión de las especi-ficaciones para asegurar que todos los requisitos han sido establecidos sin ambigüedad, en forma consistente, sin omisiones, que los errores detectados han sido corregidos y que el resultado del trabajo se ajusta a estándares establecidos para el proceso , el proyecto y el producto

11


Ingeniería de requisitosGestión de requisitos: Conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y hacer un seguimiento de los requisitos y los cambios en cualquier momento


ConclusionesEl establecimiento de requisitos es fundamental para un proyecto exitoso.La Ingeniería de Requisitos considera actividades para establecer claramente los servicios que debe proveer un sistema, y las limitaciones de desarrollo y operación.El documento de requisitos usualmente tiene el status de contrato entre el cliente y el desarrollador

12




Desarrollo de Software

Estructurado


Desarrollo de Sw Estructurado

Análisis Estructurado de RequisitosTécnicas de Especificación

Modelado de FuncionesDiagramas de Flujo de Datos (DFDs)Diagramas de Descomposición Funcional

Modelado de DatosModelado de ControlComprobaciones de los elementos de análisis

13


Desarrollo de Sw Estructurado Análisis

Técnicas de Especificación: Clasificación

Según la forma de representación:GráficasTextualesMarcos o plantillas

Según el enfoque de modelado:FunciónInformaciónTiempo

INFORMACION

FUNCION TIEMPO


Desarrollo de Sw EstructuradoAnálisis

Técnicas de Especificación: Ejemplo de Marco

14


Desarrollo de Sw EstructuradoAnálisis

Técnicas de Especificación: Ej. Según enfoque de modelado

INFORMACION

FUNCION TIEMPO

ER

DFDLista de eventos

- Diagrama de historia de vida- Matriz entidad-evento

- DFD- Matriz Entidad-función

- Diagrama Transición-estado

- Redes de petri






15


Desarrollo de Sw EstructuradoModelado de Funciones

Diagrama de Flujo de Datos (DFD): Diagrama en forma de red que representa el flujo de datos y las transformaciones que se aplican sobre ellos al moverse desde la entrada hasta la salida del sistema.

Componentes:ProcesosAlmacenesEntidades externasFlujos de datos

Yourdon, DeMarco Gane y Sarson

Flujos de datos

Procesos

Almacenes dedatos

Entidades externas

SSADMMÉTRICA



Conexiones permitidas mediante flujos de datos:

NONO *SÍENTIDADEXTERNA

NO *NOSÍALMACÉNSÍSÍSÍPROCESO

ENTIDADEXTERNA

ALMACÉNPROCESODestino/Fuente

Paso de datos síncrono

Permitida sólo en el Diagrama de Contexto

16



Flujo de diálogo y de actualización

USUARIOGESTIONAR PETICIONES DE USUARIO

LIBROS

PRESTAMOS

Petición de libro

Flujo de diálogo y de consulta

CLIENTEGESTIONAR PETICIONES DE USUARIO

INFORMES

CLIENTES

Petición de informe

Informe a cliente



Modelado de Funciones (DFD)DFD no caben en una página se representan por capas.Aproximación top-down.Ventajas:

Ayuda a construir especificaciones de arriba abajo.Distintos niveles dirigidos a distintas personas.Facilita el trabajo de los analistas.Facilita la documentación del sistema.

Diagramade Contexto

Diagramade Sistema

Distintos niveles, distintas personas

17


Desarrollo de Sw EstructuradoModelado de FuncionesEJEMPLO DFD (1/4)EJEMPLO DFD (1/4)

• Diagrama de Contexto

0 Gestionar Biblioteca

Usuario

Bibliotecario

Petición_Libros

Devol_Libros

Sanción

Altas_Bajas_Libros



• Diagrama de Sistema

EJEMPLO DFD (2/4)EJEMPLO DFD (2/4)

1 G e s tio n a r P e tic io n e s

2 G e s tio n a r

D e v o lu c io n e s

3 A c tu a liz a r

L ib ro s

P e t ic ió n _ L ib ro sD e v o l_ L ib ro s

S a n c ió n

A lta s _ B a ja s _ L ib ro s

P ré s ta m o s

L ib ro s

18



• Gestionar Peticiones

1.1 Validar

Préstamo

1.2 Realizar Préstamo

Préstamos

Libros

Petición_Libros

Préstamo_Validado




• Gestionar Devoluciones

2.1 Recoger

Libros

2.2 Gestionar Fin de Préstamo

Devol_Libros

Sanción

Préstamos

Libros Devueltos

Libros

Devol_Libros


19



Diccionario de Datos: Lista organizada de los datos utilizados por el sistema, que gráficamente se encuentran representados por los flujos de datos y almacenes presentes en el conjunto de DFD.

Las entradas son de tres tipos:Flujos de datosAlmacenesDatos elementales

Se sigue una aproximación top-down.



Diccionario de Datos:SIMBOLO SIGNIFICADO

= Composición : está compuesto de, o es equivalente a+ Inclusión: y[ ] Selección: selección una de la opciones encerradas entre corchetes, y

separadas por el símbolo “|”{ } Iteración: iteraciones del componente encerrado entre llaves( ) Opción: significa que el componente encerrado es opcional (puede

estar presente o ausente)* texto * Comentario: el texto entre asteriscos es un comentario aclarativo de

una entrada del DD@ Identificador: se utiliza para señalar un campo o conjunto de campos

que identifican cada ocurrencia de un almacénEjemplo:

PETICION_LIBROS = CARNET_BIBLIOTECA + FICHA_LIBROSCARNET_BIBLIOTECA = NUM_CARNET + APELLIDOS + NOMBRE + TIPO_CARNETLIBROS_DISPONIBLES = @SIGNATURA + TITULO + AUTOR + NUMERO UNIDADES

20



Especificación de Procesos :Técnica que define el procedimiento que realiza un proceso primitivo. Debe describir de una manera más o menos formal cómo se obtienen los flujos de datos de salida a partir de los flujos de datos de entrada más quizás una información local del proceso.Alternativas:

Lenguaje estructuradoÁrboles de decisiónTablas de decisiónDiagramas de acciónPre-post condiciones



Diagrama de Descomposición Funcional:Técnica para representar la descomposición de las funciones que realiza un sistema.Representa jerárquicamente procesos en diferentes niveles de abstracción. GESTIÓN DE

ALQUILERESDE UN VIDEOCLUB

GESTIÓN DECLIENTES

GESTIÓN DEPROVEEDORES

GESTIÓN DEPELÍCULAS

GESTIONARPEDIDOS

GESTIONARENTREGAS

GESTIONARFACTURAS

GESTIONARPAGOS

GESTIONARALTAS/BAJAS

GESTIONARALQUILERES

GESTIONARDEVOLUCIONES

GESTIONARRESERVAS


GESTIONARINFORMES


21



Comprobaciones de una especificación Estructurada:Compleción: Si los modelos son completos.Integridad: Si no existen contradicciones ni inconsistencias.Exactitud: Si los modelos cumplen los requisitos del usuario.Calidad: Estilo, legibilidad y facilidad de mantenimiento de los productos producidos.Las herramientas CASE resuelven automáticamente la mayoría de estos aspectos






22


Desarrollo de Sw EstructuradoModelado de Datos

TécnicasModelado Entidad/Interrelación (Chen, 1976)

Entidad: Objeto del que se quiere almacenar información.Relación: Asociación entre entidades.

Cardinalidad.

Atributo: Propiedad o característica de una entidad o relación.Generalización: Subtipos de entidades.

Diagrama de Estructura de Datos:Más sencillo y de menor nivel de abstracción.Formado únicamente por relaciones 1:n.






23


Desarrollo de Sw EstructuradoModelado de Control

TécnicasEn los sistemas se aprecia una perspectiva de aspectos funcionales y de datos y otra de control.

Para describir el control se requieren técnicas adicionales:

Listas de EventosDiagramas de Transición de EstadosRedes de Petri

INFORMACION

FUNCION TIEMPO



Lista de EventosEvento: Algo que ocurre en la vida real y causa un cambio en los datos.Generalmente, el “disparador” se representa como un flujo de datos que entra en el sistema.Tipos:

Generados externamente flujo que entra en el sistema (petición de libro).Reconocidos internamente flujo que va desde un almacén al proceso (validación de un préstamo).Basados en el tiempo flujo que va desde el proceso al almacén (caducidad de un préstamo).

24



Diagrama de Transición de EstadosTécnica que se enfoca en el comportamiento dependiente del tiempo de un sistema.

Definición (IEEE): Diagrama que representa los estados que puede tomar un componente o un sistema y que, además, muestra los eventos o circunstancias que implican el cambio de un estado a otro.Estado: Representa un modo externo de comportamiento.Transición: Obliga al paso de un estado a otro (o al mismo) si se cumple una condición.

ESTADO 1

ESTADO 2

Condición de transición

Acción, o acciones de transición

Transición



Ejemplo Diagrama de Transición de Estados (1/4):Se trata de representar el comportamiento de un controlador de un paso a nivel. El acercamiento o alejamiento de los trenes se detecta por unos sensoressituados a una cierta distancia. Cuando llega un tren se cierra la barrera de cada lado de la calzada. Cuando se detecta la salida de todos los trenes se abre la barrera. Hay que accionar una alarma cada vez que se abra o cierre la barrera para alertar a los automovilistas.

25



Ejemplo Diagrama de Transición de Estados (2/4):

Vias del Tren

Sensor Aproximación Izquierdo

Sensor Salida Derecha

Sensor Salida Izquierdo

Sensor Aproximación Derecho




Controlde Paso a

Nivel

Tren sale izda.

Tren sale dcha.

Tren aprox. dcha.

Tren aprox. izda.

Barrera abierta

Barrera cerrada

Activar alarma

Desactivar alarma

Abrir barrera

Cerrar barrera

26



BARRERAABIERTA

ABRIENDOBARRERA

CERRANDOBARRERA

BARRERACERRADA

Tren aprox. dcha. o izda.

Cerrar barreraActivar alarm a T=1

Barrera abierta

D esactivar alarm a


T=1cerrar barrera

Barrera cerrada

D esactivar alarm a

(Tren sale dcha. o izda.) y T=1

T=0A brir barreraA ctivar alarm a


T=T+1

(Tren sale dcha. o izda.) y T>1

T=T-1




Redes de PetriTécnica muy apropiada para la descripción del control en sistemas de comportamiento asíncrono y concurrente.Componentes del modelo:

Un conjunto finito de lugares, representados por círculos.Un conjunto finito de transiciones, representados por segmentos.Un conjunto finito de conexiones o arcos de un lugar con una transición o viceversa, representadas por flechas.

27



Redes de Petri

Op.1

a y b

ba

c

Op.1

a y b

ba

c

Disparo de Op.1

l1 l2 l3

l4 l5

l6 l7

t1 t2

t3



Ejemplo Redes de Petri (1/3):

Evolución del estado de la red Regla de disparo de transiciones:

Cada transición consta de lugares de entrada y de salida. Se habilita cuando existe al menos una marca en cada uno de sus lugares de entrada.Una transición habilitada puede dispararse. Cuando se dispara se consume la marca de cada lugar de entrada y se produce una marca en cada lugar de salida.

28




T6

P1

T1

P2

P3

T2

P4

T3 T4

P5P6

P7

T5

T6

P1

T1

P2

P3

T2

P4

T3 T4

P5P6

P7

T5

T6

P1

T1

P2

P3

T2

P4

T3 T4

P5 P6

P7

T5




T6

P1

T1

P2

P3

T2

P4

T3 T4

P5 P6

P7

T5

T6

P1

T1

P2

P3

T2

P4

T3 T4

P5P6

P7

T5

T6

P1

T1

P2

P3

T2

P4

T3 T4

P5 P6

P7

T5

29







Desarrollo de Sw EstructuradoComprobaciones

Comprobaciones:Dimensión de función Especificación Estructurada (DFD, DD y Especificación de procesos)Dimensión de información D E/R y DEDDimensión del tiempo Lista de Eventos

Plano información-función:Comprobar que todos los elementos (o datos elementales) definidos en los D E/R están definidos como entradas en el DD, es decir, están en algún flujo de datos o almacén.Realizar la misma comprobación con los DED.Comprobar que cada entidad o interrelación del D E/R es consultada y actualizada al menos una vez por alguna función primitiva del DFD.

30


Desarrollo de Sw EstructuradoComprobaciones

Plano información-tiempo:Comprobar que por cada entidad existe un evento que la crea.Comprobar que en las HVE de las entidades maestro se tratan las posibles repercusiones que tiene el borrado de dicha entidad sobre las entidades detalle.

Plano tiempo-función:Comprobar que existe un proceso primitivo dentro de los DFD que trate cada uno de los eventos identificados en la HVE.

Técnicas Matriciales: Se utilizan principalmente para ayudar a verificar la consistencia entre los componentes de distintos modelos de un sistema, ya sea centrada en las funciones, en la información o en el aspecto temporal (dinámico).





Bibliografía

1



[email protected]








Estructurado

2


Desarrollo de Sw EstructuradoArquitectura

La arquitectura del Software representa la estructura de datos y los componentes del programa necesarios para construir un sistema computacional.Corresponde al estilo arquitectónico que tomará el sistema, la estructura y las propiedades de los componentes que constituyen el sistema y las relaciones entre todos los componentes arquitectónicos de un sistema.La arquitectura del software debe modelar la estructura de un sistema y la manera en que los datos y los componentes procedimentales colaboran entre sí.



Su representación permite la comunicación entre todas los partes interesadas en el desarrollo del Sw.Destaca las decisiones iniciales relacionadas con el diseño que tendrán impacto en todo el trabajo de Ing. de Sw y en el éxito del sistema como entidad operacional. Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo esta estructurado el sistema y como trabajan sus componentes Los modelo y patrones arquitectónicos son transferibles, y por tanto pueden ser aplicables al diseño de otros sistemas.

3



Algunas arquitecturas:Centrada en datos el componente central es un repositorio de datos y todo el resto de los componentes interactúan con élDe flujo de datos, los datos de entrada se transforman en datos de salida mediante una serie de componentes para el cálculo o la manipulación.De llamada y retorno, Programa Principal y subprogramas.Orientada a objetos, los componentes del sistema encapsulan los datos y las operaciones para manipular los datos. La comunicación y coordinación se consigue mediante el paso de mensajes.Estratificada, divide las actividades y responsabilidades del sistema en capas.





Estructurado

4


Desarrollo de Sw EstructuradoDiseño

ObjetivoDesarrollar la Estructura de Programa, así como las relaciones entre los elementos, denominados Módulos, que componen esta estructura.

Diseño orientado al flujo de datos:Transición de DFD Diagrama de estructura (DE)

C

opción

1Leer Opción 2 3

1 2

3

b

c

d

a

A1

A2



Diagrama de EstructuraTabla de InterfazEstrategias de Diseño

Análisis de TransformaciónAnálisis de Transacción

Atributos de la Calidad de un DiseñoAcoplamientoCohesión

5



Diagrama de Estructura:

Muestra la descomposición de un sistema en módulos

Jerarquía de Control Llamadas entre MódulosParámetros que se intercambian en las llamadas

Elementos Principales: 1. Módulos 2. Conexiones entre Módulos3. Comunicación entre Módulos



Diagrama de Estructura:Módulo

Módulo Predefinido

Datos

Control (flag)

LEERPETICION

PRESTAMO

GESTIONARPETICIONES

PET_ACEPTADAINFORME

PRESTAMOPET_ACEPTADA

INFORMARPETICION

TRATARPETICION

CONSULTARSTOCK

PET_PRESTAMO PET_RECHAZADA

RECHAZARPETICION

INFORMEPRESTAMO

EOF

IteraciónDecisión

6



Diagrama de Estructura: MódulosDefiniciones

la parte lógica separable de un programa [AECC, 1986] una secuencia contigua de sentencias de programa, limitada por delimitadores y que tiene un identificador global [YOURDON y CONSTANTINE, 1979]cualquier objeto que, en un nivel de abstracción dado, queramos considerar como un concepto simple [FENTON, 1991] es aquella parte de código que se puede llamar (teoría del diseño estructurado) [PAGE-JONES, 1988]

Módulo Predefinido:Disponible en la biblioteca del sistema o de la aplicación (puede ser de un SO, BD, ...)




Conexiones entre módulos:Un sistema está compuesto por módulos organizados jerárquicamente, cooperando y comunicándose entre síLa llamada de un módulo se representa con una flecha

La dirección indica quién llama a quién.

Orden Llamadas en un DE:Arriba- Abajo e Izquierda-Derecha

A

B

C

Orden Ejecución:

C-B-A

7




Comunicaciones entre módulos:Se realiza a través de:

Sólo importan para la comunicación de información

Están relacionados con el problema y son importantes para el mundo exterior

Sólo sirven como valores de condición para comunicar condiciones entre los módulos.

Se Procesan

Flags (Control) Datos






8



Diagrama de Estructura: Tabla de Interfaz: Representan los parámetros que se pasan entre módulosComponentes:

1. El módulo llamado2. Cada parámetro formal3. Si el parámetro es de entrada (columna correspondiente)4. Si el parámetro es de salida (columna correspondiente)5. El uso de cada parámetro6. El significado de cada parámetro

EdadMSíNoy

Fecha de NacimientoPNoSíxF(x,y)

Significado ParámetroUsoSalidaEntradaParámetro

FormalMódulo



Diagrama de Estructura: Uso de parámetros

El parámetro es TRANSFERIDO por el módulo llamado a otro módulo que éste llama sin modificar su valorT

El parámetro es PROCESADO a= b + 2P

El parámetro es usado como una VARIABLE DE CONTROL, quizás para actuar como un índice conmutador, como un valor de un flag, o para la especificación de

una función que es usada por el módulo llamado C

El parámetro es TRANSFERIDO a otro módulo y es MODIFICADO en este segundo móduloI

El parámetro es MODIFICADO a = 3 + bM

SignificadoNemotécnico

Petición AceptadaPNoSíPet_AceptadaTratar Petición

Informe de PréstamoTSíNoInforme_Préstamo

Informe de PréstamoPNoSíInforme_PréstamoInformar Petición

Significado ParámetroUsoSalidaEntradaParámetro

FormalMódulo

9







Estrategias de Diseño:

FLUJO DESALIDA

FLUJO DELLEGADA

FLUJO DETRANSFORMACIÓN

1.1

2.1

1.2

2.2

3

4.1

4.2 1

2.1

4.1

3.1

2.2

3.2

4.2

CENTRO DETRANSACCIÓN

Camino de acción 3

Camino de acción 2

Camino de acción 1

Análisis de TransacciónAnálisis de Transformación


10


Análisis de TransformaciónConjunto de pasos de diseño que permite a un DFD obtenido en la fase de análisis, con características de flujo de transformación, convertirse en una estructura predefinida del sistema.Pasos:

1. Revisión del modelo fundamental del sistema: Debe haberse aplicado análisis estructurado (DFD)Hay que tener 3 niveles de profundidad.

2. Determinar si el DFD tiene características de Transformación o de Transacción: La mayoría de flujos se representan como transformaciones. Si existe un proceso con salidas exclusivas entonces se trata de un problema de transacción. A veces estos procesos están ocultos (no vienen reflejados en el DFD pero si en la ERS)



Entrada Salida

Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

3. Aislar el Centro de Transformación: Es la parte del DFD que contiene las funciones esenciales del sistemaLos límites están abiertos a interpretación (diseñador)

4. Realizar el Primer Corte del DE:Cm Módulo Principal CoordinadorCe Módulo Controlador del Procesamiento de la Información de Entrada al sistemaCt Módulo Controlador del Centro de Transformación (operaciones sobre datos)Cs Módulo Controlador del Procesamiento de la Información de Salida del Sistema


11


5. Ejecución del 2º Nivel de Factorización: Conversión de las transformaciones individuales de un DFD en los módulos correspondientes del DE.Se empieza en los límites y se dirige hacia fuera.Las transformaciones se convierten en módulos.Es necesario introducir módulos predefinidos que proporcionen las diferentes E/S que necesita/genera el sistema.

Entrada Salida

Transformación

Cm

Ce Ct Cs1.1

2.1

1.2

2.2

34.1

4.2

1.2 2.2

2.11.1

3 4.1

4.2

escribir zleer a leer b

a

b z



6. Refinar la Estructura del Sistema utilizando medidas y guías de diseño:

Se pueden aumentar/disminuir el nº de módulos para producir una factorización lógica:

Buena calidad, fácil de implementar/probar/mantener.Refinamientos basados en consideraciones prácticas, sentido común y requisitos del software.

Típicos reducir el nº de niveles del DE.Reflejar los parámetros:

datos=flujos de información del DFDflags=se obtienen de las descripciones de procesos

El acceso a los almacenes debe reflejarse en el DE (módulos predefinidos)

7. Asegurarse del Trabajo Realizado por el Diseño ObtenidoFuncionalidad CorrectaComprobación del orden de ejecución


12


En muchas aplicaciones un dato determina caminos alternativospor los que transita el flujo de información:

El centro del flujo se llama centro de transacciónEn un flujo orientado a transacción, el flujo de información a lo largo de un camino de acción puede ser de transformación o de transacción

Pasos:1. Revisión del modelo fundamental del sistema: 2. Determinar si el DFD tiene características de Transformación o de

Transacción:

1

2.1

4.1

3.1

2.2

3.2

4.2

CENTRO DETRANSACCIÓN

Camino de acción 3

Camino de acción 2

Camino de acción 1



3. Identificar el Centro de Transacción y las características:

La posición puede descubrirse inmediatamente a partir del DFD

El centro está ligado al origen de varios caminos radiales.

A veces el proceso correspondiente a la transacción no se refleja en el DFD

Hay que conocer el sistema para detectar si hay entradas exclusivas entre sí

Aislar los caminos de llegada y de acciónCada camino de acción debe evaluarse en función de si son de transformación o transacción

Camino 3

A

D

R

P

Q

Camino 1Camino 2

a

z

b


13


4. Realizar el 1º Corte del DE:Convertir el flujo de transacción en una estructura de sistema con una bifurcación de entrada y una bifurcación de salida

B. Entrada Igual que en análisis de transformación. B. Salida Se añade un módulo controlador por cada camino de flujo de acción.

El módulo del centro de transacción refleja la exclusividad (rombo)

Camino 3

Cm

Ce D

C1 C2 C3

A

D

R

P

Q

Camino 1Camino 2

a

z

b



5. Realizar el 2º Nivel de Factorización:Se desarrolla cada camino de acción dependiendo de su tipo de flujoEl camino 1 sigue un flujo de transformación

AD

R

PQ

Camino 1Camino 3

Camino 2

Cm

Ce D

C1 C2 C3

P Q R

A

a

Leeraz

b

Leerb Escribirz6. Refinar la Estructura del Programa7. Asegurarse del Trabajo Realizado por el Diseño obtenido


14







Atributos de Calidad del DiseñoAcoplamiento:

Grado de Independencia entre los MódulosObjetivo: Minimizar el AcoplamientoVentajas Bajo Acoplamiento:

A menor número de conexiones entre dos módulos, menos riesgo de que un defecto en un módulo afecte al otro.Los cambios realizados en un módulo afectarían lo menos posible a otros módulosMayor facilidad de mantenimiento

No es necesario conocer los detalles internos de otros módulos

Cohesión:Relación existente entre los elementos de un mismo móduloObjetivo: Maximizar la CohesiónIdealmente un módulo sólo debe hacer una única tarea (alta cohesión)La cohesión influye en un menor coste al programar y en una mayor calidad en el sistema


15


Escala de Acoplamiento:

NORMAL MEJOR

- de datos

- por estampado

- de control

EXTERNO

COMÚN

POR CONTENIDO PEOR



Acoplamiento Normal:A invoca a BB retorna el control a ANo existe paso de parámetros

A

B


16


Acoplamiento de Datos:Comunicación mediante Parámetros de Datos

Unidades Elementales DatosEvitar pasar parámetros no necesarios

OBTENERDNI

CLIENTE

LEERDNI

CLIENTE

DNICLIENTE



Acoplamiento por Estampado:

Hacen referencia a la misma Estructura de Datos (local)

Se necesita el DNI y se pasan todos los datos del Cliente

OBTENERDNI

CLIENTE

LEERCLIENTE

CLIENTE


17


Acoplamiento de Control:Un módulo pasa a otro elementos de control (flags, código de función, etc.)Un módulo controla a otroAconsejable dividir el módulo llamado en varios

OBTENERDATOS

CLIENTE

LEERCLIENTE

CLIENTE TIPO DATO



Acoplamiento Externo:Dos módulos tienen acoplamiento externo si ambos hacen referencia a una variable global, pero las referencias entre módulos consisten en registros individuales de datos y no en la estructura global de datos.Una modificación en módulos con este acoplamiento requiere revisar todo el sistemaSe produce cuando se tiene una variable global a la que puede acceder más de un módulo


18


Acoplamiento Común (Global):

Un grupo de módulos están acoplados comúnmente cuando comparten una estructura global de datos (entorno común)Se produce cuando se define como global una Estructura de Datos a la que puede acceder más de un módulo



Acoplamiento por Contenido:

Dos módulos presentan acoplamiento por contenido si uno hace una referencia al interior del otroInaceptable (patológico) Hay que evitarlo a toda costaTipos de Referencias Internas:

Un módulo modifica algún elemento en el otro módulo.Un módulo utiliza una variable local del otro.Desde un módulo se salta a otro pero la sentencia a la que se pasa no está definida como punto de entrada.Dos módulos comparten los mismos contenidos.

Los Lenguajes de Alto Nivel evitan este tipo de acoplamiento

Posible en lenguaje Ensamblador


19


Escala de Cohesión:

Mayor Cohesión

módulo como caja negraFUNCIONALSECUENCIALCOMUNICACIONALPROCEDURALTEMPORALLÓGICACOINCIDENTAL módulo transparente

Menor Cohesión



Cohesión Funcional:Todos los elementos que componen el módulo están relacionados en el desarrollo de una única función

Para reutilizar un módulo no es necesario en absoluto conocer los detalles internos

Ejemplo: Función Matemática, Escribir un Registro, etc..

Cohesión Secuencial:El módulo representa el empaquetamiento físico de varios módulos con cohesión funcional (dentro del módulo, la salida de un submódulo es la entrada del siguiente – orden predefinido)Varios módulos con cohesión funcional trabajan sobre la misma estructura de datos, pero han de existir tantos puntos de entrada como número de funciones realice dicho módulo


20


Cohesión Comunicacional:Un módulo con cohesión comunicacional es aquel cuyos elementos o actividades utilizan los mismos datos de entrada y salida.

Los módulos con cohesión comunicacional y los que tienen cohesión secuencial parecen similares, ya que contienen actividades organizadas en torno a los datos del problema

Diferencia:Secuencial Orden EspecíficoComunicacional El orden no es importante



Cohesión Procedimental:Este tipo de cohesión se da cuando el módulo tiene una serie de elementos (funciones) relacionados por un procedimiento efectuado por el código

Cohesión Temporal:Un módulo con cohesión temporal es aquel cuyos elementos están implicados en actividades que están relacionadas en el tiempo


21


Cohesión Lógica:Un módulo tiene cohesión lógica cuando existe alguna relación entre los elementos del módulo, y en algunos casos puede dar lugar a confusiones por no estar bien definidas las fronteras entre los diferentes elementos del módulo

Cohesión Coincidental:Se dice que en un módulo existe cohesión coincidental cuando entre los elementos que lo componen no existe ninguna relación con sentido.No hay relación entre los elementos del módulo ni mediante flujos de datos ni de control






Estructurado

22


Desarrollo de Sw EstructuradoDiseño-Pruebas

Enfoques de Diseño de PruebasEnfoque Estructural (Caja blanca)Enfoque Funcional (Caja negra)Pruebas AleatoriasEstrategia de Aplicación de las Pruebas

Pruebas de UnidadPruebas de IntegraciónPruebas de Sistema Pruebas de Aceptación


Activid.1

Activid.2 …......... PruebasActiv.

N-1

Ciclo de vida software

Controles

….........

Pretenden una evaluación de la calidad de los

productos generados

Todo Sistema debe haber sido probado exhaustivamente a través de una ejecución controlada antes de ser

entregado al cliente

Cuando ya dispongamos del código ejecutable de la aplicación

Explotación / Mantenimiento


23


Defecto (calidad)

Sistema de gestión de aeropuerto

Fallo (fiabilidad)

¡Xyx//???

S.Aproximación

Accidente(seguridad)

2 + 2 = 5

ErrorEquivocacióndel programador

Relación entre Error, Defecto y Fallo:

Error Defecto Fallo Efectos negativos(del programador) (en el software) (el sistema no se (dependiendo de la

comporta como debería) criticidad del sistema)

Se Plasma Da lugar a Que provoca



Técnicas de Diseño de Pruebas:Imposibilidad de Prueba Exhaustiva del Software

Se deben seguir determinados criterios para seleccionar los casos de prueba

Objetivo Técnicas Diseño de Pruebas:Garantizar con el mayor grado de confianza posible en que se detectarán los defectos del softwareEquilibro entre Recursos y Garantía para descubrir los defectos existentes


24


Enfoques principales para el diseño de casos:

1. El enfoque estructural o de caja blanca

2. El enfoque funcional o de caja negra

Caja blanca

Entrada Salida

3. El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

Caja negra

Entrada Salida

Funciones






25


Enfoque EstructuralUsa la estructura de control del diseño procedimental para obtener los casos de pruebaPara la representación del flujo de control se utilizan Grafos de Flujo

x

x

x

Secuencia Si x entonces...(If x then...else...)

Mientras x hacer...(While x do...)

Hacer... hasta x(Do...until x)

Estructuras Básicas de Programa



1

7a 7b

12,13

2

3

4

5

6

Abrir archivos;

Leer archivo ventas, al final indicar no más registros;

Limpiar línea de impresión;

WHILE (haya registros ventas) DO

Total nacional = 0;

Total extranjero = 0;

WHILE (haya reg. ventas) y (mismo producto)

IF (nacional) THEN

Sumar venta nacional a total nacional

ELSE

Sumar venta extranjero a total extranjero

ENDIF;

Leer archivo ventas, al final indicar no más registros;

ENDWHILE;

Escribir línea de listado;

Limpiar área de impresión;

ENDWHILE;

Cerrar archivos.10,11

8,9

Enfoque EstructuralGrafo de Flujo de un Programa (Pseudocódigo) El diseño de casos

de prueba tiene que estar basado en la elección de caminos importantes que ofrezcan una seguridad aceptable de que se descubren defectos (un programa de 50 líneas con 25 sentencias ifanidadas en serie da lugar a 33.3 millones de secuencias posibles).


26


Criterios de Cobertura:Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez.Cobertura de decisiones. Se debe escribir casos suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso.Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. NO incluye la cobertura de decisiones.Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea.

(a=1) and (c=4)

then

else

then

else

(a=1) (c=4)Descomposición de una Decisión Multicondicional



Complejidad Ciclomática (McCabe):

Métrica del Software de la complejidad lógica de un programa que proporciona:

Número de caminos independientes que existen en un grafo de flujoMínimo número de casos de prueba necesarios para satisfacer criterio Decisiones

Formas alternativas de cálculo a partir de un Grafo de Flujo:1. V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el

número de nodos2. V (G) = r, siendo r el número de regiones cerradas del grafo.3. V(G) = c + 1, siendo c el número de nodos de condición.


27






Pruebas centradas en los requisitos funcionales del softwareUn Caso de Prueba bien elegido es el que:

Cubre un conjunto extenso de otros casos posiblesNos indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros conjuntos similares

Reduce el número de otros casos necesarios para que la prueba sea razonable

Implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos

Técnicas de Pruebas de Caja Negra:Particiones o Clases de EquivalenciaAnálisis de Valores Límite Conjetura de Errores


28


Particiones o Clases de Equivalencia:

Método que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.Cada caso debe cubrir el máximo número de entradasDebe tratarse el dominio de valores de entrada dividido en un número finito de clases de equivalencia que cumplan la siguiente propiedad:

La prueba de un valor representativo de una clase permite suponer «razonablemente» que el resultado obtenido (existan defectos o no) será el mismo que el obtenido probando cualquier otro valor de la clase.



Análisis de Valores Límite:Complementa a la técnica de Particiones o Clases de Equivalencia

Diferencias:En lugar de seleccionar «cualquier» elemento como representativo de una clase de equivalencia, se requiere la selección de uno o más elementos tal que los márgenes se sometan a prueba

Más que concentrarse únicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando también el espacio de salida


29


Conjetura de Errores:El valor cero es una situación propensa a error tanto en la salida como en la entradaEn situaciones en las que se introduce un número variable de valores, conviene centrarse en el caso de no introducir ningún valor y en el de un solo valor. También puede ser interesante una lista que tiene todos los valores igualesEs recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificaciónTambién interesa imaginar lo que el usuario puede introducir como entrada a un programa






30


En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entradaen la secuencia y con la frecuencia con las que podrían aparecer en la práctica






31


Estrategias de Aplicación de PruebasSe comienza en la prueba de cada módulo, que normalmente la realiza el propio personal de desarrollo en su entorno Prueba de Unidad

Con el esquema del diseño del software, los módulos probados seintegran para comprobar sus interfaces en el trabajo conjunto Prueba de Integración

El software totalmente ensamblado se prueba como un conjuntopara comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimiento, seguridad, etc. Prueba Funcional



Estrategias de Aplicación de PruebasEl software ya validado se integra con el resto del sistema (porejemplo, elementos mecánicos, interfaces electrónicas, etc.) para probar su funcionamiento conjunto Prueba del Sistema

El producto final se pasa a la prueba de aceptación para que el usuario compruebe en su propio entorno de explotación si lo acepta como está o no Prueba de Aceptación


32





Bibliografía

1



[email protected]





Reflexiones acerca del futuro de la Ing. de Software

Ing. de Software afectada por el cambio

I. de Sw

Limitaciones de los primeros modelos

Tiempo de puesta en el mercado

Conectividad de red, Internet

Personas con nuevas necesidades

Computación de escritorio, personal

Cambios en la economía

Interfaz de usuario

Tecnología de objetos

Nuevas Tecnologías

2


Wasserman afirma que hay 8 principios básicos sobre los que se sustenta la Ingeniería del software:

AbstracciónMétodos y Notaciones de análisis y DiseñoPrototipado de la Interfaz de UsuarioArquitectura del SoftwareEl proceso del Software ReutilizaciónMedidasHerramientas y ambientes integrados



Responsabilidad de la Ingeniería del Software: Código de ética y práctica profesional para los ingerierosde Sw (ACM/IEEE-CS)

PúblicoClientes y EmpleadoresProductoJuicioGestiónProfesiónColegasCompromiso Personal


3


Responsabilidad de la Ingeniería del Software: Nunca Robar datos para beneficio personalNunca vender o distribuir información patentada que haya obtenido como parte de su trabajoNunca destruir o modificar maliciosamente los programas, archivos o datos de otra persona.Nunca violar la privacidad de un individuo, grupo u organizaciónNunca atacar un sistema por deporte o beneficioNunca crear o difundir un virus o gusano en una computadoraNunca usar la tecnología de computación para facilitar la discriminación o el hostigamiento.


Ingeniería de Software

Documents

Transcript of Ingeniería de Software