Modelos Clásicos

5/6/2018 Modelos Clásicos - slidepdf.com

http://slidepdf.com/reader/full/modelos-clasicos 1/38

Los modelos de proceso dependen de las opinioneso creencias de las personas involucradas en unproyecto.

�Es necesario comprender el problema antes dedesarrollar una solución.

�El proceso para resolver un problema debe dar un

resultado predecible, sin importar que individuo haceel trabajo.�Es indispensable planear y calcular el proceso congran precisión.



ElEl modelomodelo dede cascadacascada sese desarrollódesarrolló entreentre loslos

sesentasesenta yy setentasetenta..

Se define como una secuencia deactividades, donde la estrategia principal esseguir el progreso del desarrollo de softwarehacia puntos de revisión bien definidos.



Especificación derequisitos

Análisis

Diseño

Implementación

Prueba parciales

Integración

Mantenimiento



Los documentos técnicos son compresibles parausuarios y administradores no técnicos.Cada detalle de los requisitos se conoce deantemano antes de desarrollar el software, y losdetalles son estables durante el desarrollo.

Los documentos técnicos son compresibles parausuarios y administradores no técnicos.Cada detalle de los requisitos se conoce deantemano antes de desarrollar el software, y losdetalles son estables durante el desarrollo.

Las metas se logran mejor cuando se tienen puntosde revisión, bien preestablecidos y documentados,

dividiendo el desarrollo en actividades secuencialesbien definidas.



El modelo incremental es un desarrolloinicial de la arquitectura completa

del sistema, seguido de incrementosy versiones parciales del mismo.

Durante cada incremento, el sistema seevalua con respecto al desarrollo de

versiones futuras.



La administración de proyectos es mas fácil delograr en incrementos más pequeños.

Es mas fácil comprender y probar incrementos defuncionalidad más pequeños.

La funcionalidad inicial se desarrolla más temprano,logrando resultados de inversión en menor tiempo.

Hay mas probabilidad de satisfacer el cambio enlos requisitos de usuario mediante incrementos desoftware en el tiempo.



Es una extensión del modelo incremental,

donde los incrementos se hacen de manerasecuencial en lugar de en paralelo.El sistema evoluciona según se vanentregando los incrementos

Los requerimientos que son claros al principiodel proyecto dictaran el incremento inicial.



El modelo evolucionario es también conocido como desarrollorápido de aplicaciones, se basa tradicionalmente en el uso deprototipos.Un prototipo de software se considera como un medio paraespecificar los requisitos y un enlace de comunicación entre elusuario final y el diseñador.

Primer ciclo de desarrollo

Delta 1

Delta 1

Delta 2

Delta 3



� Extensión del modelo de Cascada

� Cada ciclo del modelo termina con unadiscusión que discute los logros actualesy los planes para el siguiente ciclo.



Las creencias del Modelo Espiral son:

�Una Actividad comienza cuando se entiendenlos objetivos y riesgos involucrados.

�Basado en la evaluación de soluciones alternas,se usan las herramientas que mejor reduzcan los

riesgos.�Todo el personal relacionado debe involucrarseen una revisión que determine cada actividad,planeando y comprometiéndose con las

siguientes actividades.�El desarrollo se implementa en cada etapa,permitiendo prototipos sucesivos del producto.



Extensión del modelo espiral, haciendo énfasis

en la identificación de las condiciones deganancia, para todas las partes; creando un planpara alcanzar las condiciones ganadoras y losriesgos correspondientes.

No necesita mucho tiempo de gestión, lo quepermite utilizarlo tanto en proyectos pequeños,como mayores.



1. Elaborar los objetivos, restricciones y alternativasdel proceso y producto del sistema y subsistema.

2. Evaluar las alternativas con respecto a los objetivosy restricciones. Identificar y resolver las fuentesprincipales de riesgo en el proceso y en elproducto.

3. Elaborar la definición del producto y del proceso.

4. Planear el siguiente ciclo de vida, incluyendo lapartición del sistema en subsistemas para ser considerados en ciclos paralelos.



� Ciclo 0. Grupos de Aplicación:

¾ Se determina la viabilidad de un grupo apropiado deaplicaciones.

� Ciclo 1. Objetivos del ciclo de vida de la aplicación:¾ Se desarrollan los objetivos del ciclo de vida, incluyendo

prototipos, planes y especificaciones de aplicacionesindividuales, y se verifica la existencia de al menos unaarquitectura viable para cada aplicación.

� Ciclo 2. Arquitectura del ciclo de vida de la aplicación:

¾ Se verifica la viabilidad y determina que no existen riesgosmayores en satisfacer los planes y especificaciones.

� Ciclo 3. Capacidad de operación inicial:¾ Alcanzar una capacidad operacional inicial para cada etapa

critica del proyecto en el ciclo de vida de software.



Algunas creencias del Modelo Ganar-Ganar son:

� Escribir software reutilizable para hacer eficiente el proceso del desarrollo.

� Medir la calidad del sistema como aspectoclave del desarrollo del producto.

� Usar tecnologías basadas en objetos como

aspecto básico para lograr la calidad.� Producir sistemas rápidamente, sencillos,

confiables y de calidad, empleando procesosbien definidos.

� Utilizar el proceso de espiral como base del

proceso.� Involucrar al cliente mediante el manejo de

prototipos.



� Modelo de proceso de software que tomalos principios y practicas aceptadas, y laslleva aniveles extremos.

� Tiene como objetivos reducir el riesgo en elciclo de vida del software mediante gruposde desarrollo pequeños.

� Aunque la XP define varias practicas a

seguir, quizás la mas representativa delproceso XP es la programación en pares(pair programming), donde todo desarrollorequiere de 2 programadores que trabajan

juntos.



� El modelo considera varios aspectosproblemáticos del desarrollo de software,como son los retrasos, proyectoscancelados, cambios en el negocio y larotación de personal. Para ello se definen 4variables de control en el desarrollo desoftware: costo, tiempo, calidad y alcance.

Mientras que las fuerzas externas asignanlos valores para 3 de estas variables, elequipo de desarrollo escoge el valor de lacuarta.



Las creencias del Modelo XP son:

� Los cambios en un sistema sonfrecuentes.

� Se deben manejar los cambios demanera incremental.

� Se deben apoyar los cambios.

� Se debe logar una rápidaretroalimentación.

� Se debe lograr un trabajo de calidad.

� Se debe buscar la simpleza.

� Dado un conjunto apropiado depracticas y tecnología, la curva decosto puede aplanarse.



*Es una extensión al proceso objectory que tiene sus orígenes en ladécada de 1980.

*su aspecto esencial del desarrollo de software una visión queparte de la arquitectura del sistema , siguiendo un proceso iterativoe incremental.

Integra aspectos :

* Ciclo.* Fases.* Flujo de trabajo.

* Mitigación de riesgos.* Control de calidad.* Administración de proyecto.* Producto.* Proceso.

Proceso Unificado



EL PROCESO UNIFICADO SE BASA EN LASSIGUIENTES CREENCIAS:

*se debe conocer que quieren y necesitan los

usuarios potenciales.

*permite diseñar edificios desde múltiple puntosde vista, estructura, electricidad, etc..

*es practico dividir el trabajo en etapas, dondecada iteración resulta en un incremento delproyecto.



*Esta directamente relacionada con su proceso de desarrollo.*Se considera que un proceso bien conocido y ampliamente utilizado,sustentado en medición y predicción de eventos, permite controlar en

buena medida la producción de software de calidad

LOS FACTORES QUE AFECTAN LA OBTENCION DE UN PRODUCTO DE CALIDAD SONLOS SIGUIENTE:

*EL CLIENTE O USUARIO

*EL DESARROLLADOR

*PROCESO

*PRODUCTO

CALIDAD DE SOFTWARE Y MODELOS DE

MADUREZ DEL PROCESO



Tiene como objetivo evaluar los procesos ensus niveles de madurez e identificar los nivelesque una organización debe formar paraestablecer una cultura de excelencia en la

ingeniería de software.

Que es?

*Identificar fortalezas y debilidades en laorganización.*ponderar los riesgos de seleccionar entrediferentes contratos y monitorear los mismos.

MODELO DE MADUREZ DE

CAPACIDADES



CRONOLOGIA DE ESTANDAREZ Y MODELO DE MADUREZ PARA LA CALIDAD DESOFTWARE

Año Descripción

2000 ISO 9000-2000SEI CMM V 1.0

1999 PEMM V 1.0

1998 ISO 15504 (SPICE)(Lanzamiento al publico como reportes técnicos´tipo 2µ)

TickiT V 4.0

1997 ISO 9000-3 (Nuevo lanzamiento)SEI para las revisiones de SW-CMM apoyando a CMM integración

(CMMI)

1996 IEEE/EIA 12207 (corresponde a ISO 12207)TSP

1995 ISO 12207(Lanzamiento inicial)ISO 15504 (SPICE) (Lanzamiento inicial)

PSP

1994 ISO 9001 (Nuevo lanzamiento)



5 NIVELES DE MADUREZ DEL PROCESO DESOFTWARE



Organizacion Internacional para laOrganizacion Internacional para laEstandarización (ISO)Estandarización (ISO)

Existe diversas normas de organización

Internacional para la estandarización(ISO) aplicables en el desarrollo desoftware como se muestra acontinuación.



Es una familia de normas internacionalesrelacionadas con la administración de

calidad en productos y servicios.Existen tres estándares:

ISO-9001 ISO-9003ISO-9002



Es una familia de normas internacionalesrelacionadas con la administración decalidad en los procesos del ciclo de vida delsoftware.

Esta dirigida a lograr acuerdos o contratosentre los desarrolladores y clientes

Es una norma de alto nivel y Se describen

cinco procesos primarios:

adquisición suministro Desarrollo Mantenimiento operación



Se dividen en actividades y las actividadesen tareas y se agregan los siguientes

requisitos:

Documentación

Apoyo

Administr ación deconfigur

ación

Verificación

Aseguramiento

decalidad

Validación

Auditoria

Resolución del

problema



Procesos organizacionales:

infraestructuraadministración

mejora entrenamiento



El modelo de madurez de ingeniería de desempeño(PEMM, performance Engineering Maturity Model)Evalúa los niveles de integración, aplicación,ejecución y diseño.Cuenta con cinco niveles:

El modelo de madurez de ingeniería de desempeño(PEMM, performance Engineering Maturity Model)Evalúa los niveles de integración, aplicación,ejecución y diseño.Cuenta con cinco niveles:



Fue desarrollado por el departamento de comercio eindustria del reino unido

Es una guía con estrategias para lograr la certificación enla producción de software según los estándares del ISO-

9000.esta guía se compone de :I. Un capitulo de conceptos de calidad

II. La norma del ISO-9003

III. Una serie de proveedores y compradores

IV. Una guía para la auditoria del sistema de calidad

V. El proceso de certificación

VI. Guías complementarias



o Es un modelo de evaluación odeterminación de la capacidad de los

procesos conocido también como lanorma ISO-15504.

o Combina los enfoques de CMM con losdel ISO-9000

o Su objetivo es lograr gananciassignificativas en productividad y calidad.





Parte 9.- Vocabulario.

Parte 8.- Guía de uso para determinar la capacidad del proceso de un proveedor.

Parte 7.- Guía para uso en mejora del proceso

Parte 6.- Guía para calificación y entrenamiento de asesores.

Parte 5.- Modelo de evaluación y guía de indicadores.

Parte 4.- Guía para realización de evaluación.

Parte 3.-Realización de evaluación.

Parte 2.-Modelo de referencia de procesos y capacidad.

Parte 1.- Conceptos y guía introductoria.



Es un modelo para la mejora del proceso de desarrollo desoftware

Esta basado en que la calidad del software depende deltrabajo de cada uno de los ingenieros

El proceso ayuda a controlar, manejar y mejorar el trabajo deestos.

Su objetivo es mejorar la planeación del trabajo, conocer conprecisión el desempeño, medir la calidad de los productos ymejorar técnicas para su desarrollo.



Se siguen ciertos pasos:

-PSP0 y PSP0.1 : (Lineas base)

-PSP1 y PSP1.1 : (Proceso de planeación)

-PSP2 y PSP2.1 : (Manejo personal de calidad)-PSP3 : (Proceso personal cíclico)



Mejora la planeación introduciendo la estimacióndel tamaño del producto e introduce los reportes de

pruebas. PSP1.1.- Introduce las estimaciones de recursos eintroduce la calendarización.

PSP0.- Define el proceso de trabajo personal identificandoy ordenando las principales actividades, introduce larecolección de datos para medir la productividad ycalidad a través del registro de tiempos y defectos.PSP0.1.-Registra el tamaño del producto utilizando puntosfuncionales, registra los problemas y propuestas de mejora.

Mejora la planeación introduciendo la estimacióndel tamaño del producto e introduce los reportes de

pruebas. PSP1.1.- Introduce las estimaciones de recursos eintroduce la calendarización.



PSP3.- Introduce el proceso cíclico para crear programas de mayor tamaño, introduce el registro

de segumiento de asuntos y lleva el resumen de laplaneacion y registro de tiempo, tamaño y defectospor ciclo.

PSP2.- Introduce las actividades de deteccióntemprana de defectos mediante revisiones de

diseño, código y uso de listas de verificación.

PSP2.1.- Introduce formas para el diseño detallado,facilitando la relación del diseño.

PSP3.- Introduce el proceso cíclico para crear programas de mayor tamaño, introduce el registro

de segumiento de asuntos y lleva el resumen de laplaneacion y registro de tiempo, tamaño y defectospor ciclo.



Extiende el modelo PSP e integra los aspectos deldesarrollo de software realizados por equipos de trabajo.

Se definen aspectos como la asignacion y el control detareas para los diversos miembros del equipo.

Objetivos:1. Desarrollar productos en varios ciclos.2. Proporcionar métricas para equipos3. Evaluar roles y equipos4. Ofrecer guías para la solución de problemas

Documents

Modelos Clásicos