10/09/2013

Objetivo

El alumno elegir la metodologa para desarrollar un sistema de informacin

INGENIERA DE SOFTWARE I
UNIDAD I. Metodologas de desarrollo de software
MC Ricardo Israel Roque Covarrubias

Resultado de Aprendizaje

Contenido
1. 2.

Elaborar un ensayo que contenga la justificacin de la metodologa a emplear para el sistema.

Clasificacin Ventajas y desventajas

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

Definicin

Realidad de la Industria del sw

El 55% de los sistemas cuestan ms de lo esperado, el 68% superan la fecha de entrega y el 88% tuvieron que ser sustancialmente rediseados

Ingeniera de Software

Una disciplina tecnolgica y administrativa dedicada a la produccin sistemtica de los productos de programacin, que son desarrollados y modificados a tiempo, y dentro de un presupuesto definido.

Informe de IBM (1994)

Cada 6 nuevos sistemas puestos en funcionamiento, 2 son cancelados, la probabilidad de cancelacin est alrededor del 50% para sistemas grandes, la media de proyectos que sobrepasa el calendario es del 50%, 3 de cada 4 sistemas son considerados como fallos de operacin

Bureau of Labor Statistics (1997)

MC Ricardo Israel Roque Covarrubias MC Ricardo Israel Roque Covarrubias

10/09/2013

Realidad de la Industria del sw

El 52,7% de los proyectos relacionados con las tecnologas de la informacin cuestan el 189% de su coste inicial estimado

Caractersticas de un producto de software

El software se desarrolla, no se fabrica en el sentido clsico

The Standish Group, as reported by Solutions Integrator (Junio de 1999)

El 31,1% de los proyectos se cancelan antes de completarse

Los costes del software se encuentran en la ingeniera [Pressman, 2006]

El software deteriora

no

se

estropea,

se

The Standish Group, as reported by Solutions Integrator (Junio de 1999)

Cambios en las fases de mantenimiento No hay piezas de repuesto para el software

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

Problemas del software

Actividades del Modelo de ciclo de vida de un proyecto

Anlisis y definicin requerimientos Diseo del sistema Diseo de programas Escritura de los programas Prueba unitaria Prueba de integracin Prueba del sistema Mantenimiento

MC Ricardo Israel Roque Covarrubias

Calidad cuestionable
Mal funcionamiento Insatisfaccin de los clientes

de

Cmo desarrollar software

Imprecisin en la planificacin y la estimacin

Cmo mantener el volumen creciente de software existente Cmo afrontar la incesante demanda de software MC Ricardo Israel Roque Covarrubias

Caractersticas del Modelo de Desarrollo

Caractersticas del Modelo de Desarrollo

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final. Un modelo de desarrollo establece el orden en el que se harn las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades. Es necesario diferenciar el ciclo de vida del proyecto y el modelo de desarrollo.

El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo. No existe un modelo universal Los modelos no son rgidos Son una gua respecto al orden en que deben adelantarse las actividades Establece el ciclo de vida del software.

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

10/09/2013

Modelo de Desarrollo
El Modelo de Cascada El Modelo de Espiral El Modelo de Prototipos El Modelo de Desarrollo Rpido de Aplicaciones El Modelo XP El Modelo RUP

Modelo de Cascada
Requirements definition

System and software design

Documento especificacin requerimientos

MC Ricardo Israel Roque Covarrubias

Secuencia de fases en la que al final de cada una de ellas se rene la documentacin que garantiza el cumplimiento de las especificaciones y requisitos antes de pasar a la fase siguiente

Modelo que comenz a disearse en 1966 y se termin alrededor de Documento de diseo 1970. de software Implementation Cdigo fuente y and unit testing documentacin de comentarios Integration and Sistema y system testing documentacin de las pruebas Operation and Documento maintenance de cambios

de de

El Modelo de Cascada

El Modelo de Cascada

Este modelo tiene una secuencia ordenada. 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. El trabajo de una etapa previa es la entrada del siguiente proceso. Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto

Provee de un gran control sobre las fechas de entrega y entregables. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costos esperados. Establece criterios de entrada y salida en cada fase claramente definidos. Dado que provee pocos puntos de visibilidad, da la impresin de que es lento.

A Favor...

En Contra...

Excelente cuando se tiene un producto estable y se conoce la tecnologa. Es un mtodo muy estructurado que funciona bien con gente de poca experiencia. Provee estabilidad en los requerimientos. La planeacin anticipadamente. se puede hacer

Tiene poca flexibilidad. Los proyectos en la prctica raramente siguen un flujo secuencial. Siempre es difcil para el cliente mostrar todos los requerimientos explcitamente y con mucha anticipacin. El cliente debe tener paciencia. No refleja realmente desarrollo del software el proceso de

10/09/2013

En Contra...

En Contra...

Se tarda mucho tiempo en pasar por todo el ciclo Acenta el fracaso de la industria del software en su comunicacin con el usuario final Las revisiones de proyectos complejidad son muy difciles de gran

Los usuarios limitada.

tienen

una

participacin

Dificultad de responder a los cambios de los requerimientos del cliente El gran problema de este modelo es la dificultad de realizar cambios despus que el proceso ha avanzado Los costos al descubrir errores en etapas avanzadas son muy altos

Es inflexible y no motiva al cambio. Poco apropiado para aplicaciones para la toma de decisiones.

Principios para seleccionar una metodologa

Presentacin de todos los equipos

Principio 1. A equipo ms grande, metodologa ms grande. Lo expresado en este principio es que no se puede suponer que la metodologa utilizada por un equipo pequeo funcione bien para un equipo grande y viceversa.

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

Principios para seleccionar una metodologa

Principio 2. Mientras ms crtico el sistema se requiere mayor visibilidad en la construccin. Se definen 4 niveles de criticidad en relacin al impacto que tiene una falla de sistema

Principios para seleccionar una metodologa

Prdida discreta de dinero: Se pierde dinero pero es recuperable o no perjudica en gran manera. La falla en un sistema de facturacin. Prdida irremplazable de dinero: Una falla en el sistema de la bolsa de Nueva York. -Prdida de Vidas: Una falla en el sistema que regula una planta atmica.

Prdida de confort: Alguien tendr que realizar la tarea manualmente

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

10/09/2013

Principios para seleccionar una metodologa

Principios para seleccionar una metodologa

Principio 3. Un relativo pequeo aumento en el tamao de la metodologa aade un relativo gran aumento en el costo del proyecto. Aadir elementos e instancias de control tienen impacto sobre los costos, se consume tiempo y la concentracin sobre el trabajo productivo se ve afectada.

MC Ricardo Israel Roque Covarrubias

En este sentido el principio indica que se puede justificar una metodologa ms pesada en funcin de la criticidad del proyecto dado que el costo de asegurar la ausencia de defectos comparado al costo de la existencia de defectos se justifica al incrementar el nivel de criticidad.

MC Ricardo Israel Roque Covarrubias

Principios para seleccionar una metodologa

Este principio no cuestiona que aadir ms elementos a una metodologa se de un beneficio o un dao sino pretende establecer que produce un incremento en el costo. Importante es sealar que estos costos pueden ser justificados si se utiliza el principio nmero dos.

Principios para seleccionar una metodologa

Principio 4. La forma ms efectiva de comunicacin es la forma interactiva cara a cara, por ejemplo frente a una pizarra. Este principio recuerda que no importando cuales sean los mecanismos y artefactos establecidos por la metodologa nada ser ms efectivo que la comunicacin presencial.

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias

Clasificacin de Modelos de Desarrollo

Clasificacin de Modelos de Desarrollo

Desarrollo convencional
No existan metodologas No anlisis, slo programacin

Desarrollo orientado al objeto

Centrado en los datos Procesos y datos como conjunto

Desarrollo estructurado
Se establecen mtodos de ingeniera Centrado en las funciones Programacin estructurada Diseo estructurado: concepto de mdulos Anlisis estructurado: especificaciones funcionales grficas

MC Ricardo Israel Roque Covarrubias

MC Ricardo Israel Roque Covarrubias