CAPITULO II

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

2.1

GENERALIDADES

Las organizaciones pequeas tienden a ser relativamente informales; los proyectos de desarrollo de sistemas nacen de conversaciones entre el usuario y el administrador del proyecto (que puede ser a la vez analista, programador, operador, etc) y el procede desde el anlisis hasta la implementacin sin ningn problema. Sin embargo, en las organizaciones ms grandes las cosas se llevan a cabo de una forma mucho ms formal, la comunicacin entre los usuarios, la administracin y el equipo del proyecto suele ser por escrito. Actualmente, tanto las organizaciones grandes como las pequeas estn adoptando un ciclo de vida uniforme para sus proyectos. Esto a veces se conoce como: Plan del Proyecto, Metodologa del Desarrollo de sistemas, Ciclo de vida del desarrollo de sistemas; Modelos del Proceso de Software, Paradigmas de la Ingeniera de software; que proporciona un procedimiento comn a seguir para desarrollar un sistema informtico que puede orientar a cualquier miembro de la organizacin en el desarrollo de sistemas. De lo anteriormente expuesto se puede decir que: El ciclo de vida del desarrollo de sistemas, es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de informacin y aplicaciones informticas. Es una herramienta de gestin de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistemas.

2.2

PRINCIPIOS GENERALES

Los principios generales que deberan sostener todos los desarrollos de sistemas son los siguientes:

Implicar al usuario Aplicar un mtodo de resolucin de problemas. El mtodo clsico es el siguiente: Identificar el problema (u oportunidad de mejora) Comprender el contexto del problema y las causas y efectos del mismo Definir los requisitos para alcanzar una solucin adecuada Hallar soluciones alternativas Elegir la mejor solucin Disear e implementar la solucin

INGENIERA DE SOFTWARE I Gloria Arcos Medina

Observar y evaluar el impacto de la solucin Definir fases y actividades Establecer normas para un desarrollo y una documentacin consistentes Justificar los sistemas como inversiones de capital Dividir el sistema si el caso lo amerita Disear sistemas que puedan crecer o cambiar

2.3

MODELOS DE PROCESO DE SOFTWARE

En este punto se tratan diferentes modelos de procesos para la ingeniera de software, que se los ha clasificado de la siguiente manera: Modelos Tradicionales o Modelo Genrico o Modelo Secuencial (Cascada o Waterfall) o Modelo de Construccin de Prototipos Modelos Evolutivos o Modelo en Espiral o Modelo Incremental Modelos giles o DRA (Desarrollo Rpido de Aplicaciones RAD Rapid Application Development) o MSF (Microsoft Solutios Framework) o RUP (Rational Unified Process) o XP (Extrem Programming)

Los modelos aqu expuestos, no son todos, pero s los ms difundidos; a continuacin detallaremos los ms importantes.

2.3.1 MODELO GENERICO DE DESARROLLO DE SOFTWARE

El proceso de desarrollo de software tiene tres fases genricas; independientemente del paradigma elegido, del rea de aplicacin, del tamao del proyecto o de la complejidad, estas son: Definicin Desarrollo Mantenimiento.

DEFINICION La fase de definicin se centra sobre el qu. En esta fase se intenta identificar los requisitos claves del sistema y del software: Qu informacin ser procesada Qu funcin y rendimiento se desea Qu interfaces se van a establecer Qu criterios de validacin se necesita

INGENIERA DE SOFTWARE I Gloria Arcos Medina

Los pasos a realizarse en esta fase son los siguientes: Anlisis del Sistema: Define el papel de cada elemento del sistema informtico, asignando finalmente al software el papel que va a desempear. Planificacin del proyecto de software: Se analizan riesgos, se asignan recursos, se estiman costos, se definen las tareas y se planifica el trabajo. Anlisis de Requisitos: Obtener informacin ms detallada del mbito de informacin y de funcin del software. DESARROLLO La fase de desarrollo se centra en el cmo, durante esta fase el que desarrolla el software deber determinar: Cmo disear las estructuras de datos y la arquitectura del software Cmo se implementan los detalles procedimentales Cmo se traduce el diseo a un lenguaje de programacin. Cmo se realizan las pruebas

Los pasos que se realizan en esta fase son los siguientes: Diseo del Software: El diseo traduce los requisitos del software a un conjunto de representaciones que describen la estructura de los datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz. Codificacin: Es la traduccin del diseo a un lenguaje de programacin. Prueba del software: Una vez que el software ha sido implementado en un lenguaje de programacin, ste debe ser probado para descubrir los errores que puedan existir en la funcin, en la lgica y en la implementacin. MANTENIMIENTO La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a reforzar o ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y desarrollo, pero en el contexto de un software ya existente. Durante la fase de mantenimiento se encuentran tres tipos de cambios: Correccin: Permite determinar los defectos del software. correctivo cambia el software para corregir estos defectos. El mantenimiento

Adaptacin: Con el paso del tiempo es probable que cambie el entorno original para el que se desarroll el software (sistema operativo, perifricos, etc). El mantenimiento adaptativo permite modificar el software para acomodarlo a los cambios de su entorno externo.
INGENIERA DE SOFTWARE I Gloria Arcos Medina

Mejora: Cuando el cliente propone funciones adicionales que deben ser incorporadas en el software. El mantenimiento perfectivo ampla el software ms all de sus requisitos funcionales originales Prevencin: El software se deteriora debido al cambio, y por esto el mantenimiento preventivo tambin llamado reingeniera de software, en esencia, hace cambios en los programas a fin de que se puedan corregir, adaptar y mejorar ms fcilmente.

2.3.2 MODELO SECUENCIAL

El Modelo Secuencial, llamado tambin Modelo en Cascada o Waterfall, exige un enfoque sistemtico y secuencial del desarrollo del software. Este paradigma abarca las actividades representadas en la Figura No. 2.1
Ingeniera del Sistema Anlisis Diseo Codificacin Prueba Mantenimiento

Figura No. 2.1. Modelo Secuencial

Ingeniera y Anlisis del Sistema Establecer los requisitos de todos los elementos del sistema Asignar algn subconjunto de estos requisitos al software Este planteamiento del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como: hardware, personas, bases de datos Abarca los requisitos globales a nivel del sistema con una pequea cantidad de anlisis y de diseo a un nivel superior

Anlisis de los requisitos del software Se centra en la especificacin de requisitos para el software

INGENIERA DE SOFTWARE I Gloria Arcos Medina

El analista debe comprender, el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas. Los requisitos tanto del sistema como del software se revisan con el cliente.

Diseo Se enfoca sobre los siguientes atributos del programa: Estructura de los datos Detalle procedimental Diseo de las interfaces Arquitectura del software

El diseo es una representacin del software, de tal forma que se obtenga la calidad requerida antes de que se inicie la codificacin.

Codificacin La codificacin es la traduccin del diseo a un lenguaje de programacin. Prueba Las pruebas se centran en la lgica interna del software; las pruebas deben asegurar que la entrada definida produzca los resultados que realmente se requieren. Mantenimiento Ocurren despus que el software se entregue al cliente. Los cambios ocurren debido a: Que se encuentran errores Que el software debe adaptarse a cambios del entorno externo (por ejemplo: uso de un nuevo perifrico) Ampliaciones funcionales o de rendimiento requeridas por el cliente. El mantenimiento aplica cada uno de los pasos del ciclo de vida a un programa existente en vez de a uno nuevo. PROBLEMAS DEL MODELO Los proyectos reales raramente siguen un flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicacin del paradigma. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

El cliente debe tener paciencia, hasta llegar a las etapas finales del desarrollo, no existir una versin operativa del programa.

VENTAJAS
Son similares a los pasos genricos aplicables a todos los paradigmas de la ingeniera del software.

2.3.3 CONSTRUCCION DE PROTOTIPOS

Un cliente normalmente define un conjunto de objetivos generales para el software, pero no identifica los requerimientos detallados de entrada, proceso o salida y el programador no puede estar seguro de la eficiencia de los programas o de la forma de la correcta interaccin hombre-mquina. En estas situaciones puede ser un mejor mtodo de ingeniera del software la construccin de un prototipo. La construccin de prototipos es un proceso que facilita al programador la creacin del modelo de software a construir. Los prototipos pueden ser:

Prototipo que describa la interaccin hombre-mquina (entradas y salidas) Prototipo que implementa algunas funciones requeridas por el usuario Un programa existente que ejecute parte o toda la funcin deseada, pero que tenga otras caractersticas que deben ser mejoradas en el nuevo sistema.

La Figura No. 2.2 muestra los pasos a seguir en la aplicacin del paradigma de construccin de prototipos.

Inicio Fin
Recoleccin y Refinamiento de Requisitos

Producto de Ingeniera

Diseo Rpido

Refinamiento del Prototipo

Construccin del Prototipo Evaluacin del Prototipo por el Cliente

Figura No. 2.2. Modelo de Construccin de Prototipos

INGENIERA DE SOFTWARE I Gloria Arcos Medina

La construccin de prototipos comienza con la recoleccin de requisitos, en esta etapa, el tcnico y el cliente se renen y definen los objetivos globales para el software, identifican todos los requisitos conocidos y perfilan las reas en donde ser necesario un mayor definicin. Luego se produce un diseo rpido que se enfoca sobre la presentacin de los aspectos del software visibles al usuario (por ejemplo, mtodos de entrada y formatos de salida). El diseo rpido conduce a la construccin de un prototipo. El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es afinado de tal forma que satisfaga las necesidades del cliente. PROBLEMAS DEL MODELO El cliente ve funcionando lo que parece ser una primera versin del software. El ignora que se han obviado muchos aspectos de calidad del software. Cuando se le informa que el producto debe ser reconstruido, el cliente puede solicitar que se apliquen nuevas mejoras, que no estuvieron planificadas al inicio. El cliente y el tcnico deben estar de acuerdo en que el prototipo servir solo como mecanismo de definicin de requisitos, posteriormente debe ser descartado y debe construirse el software real. El tcnico de desarrollo puede utilizar un sistema operativo o un lenguaje de programacin inadecuado para demostrar las capacidades del prototipo; despus de algn tiempo, el tcnico puede haberse familiarizado con esta herramienta y puede llegar a formar parte integral del sistema. Los prototipos suelen pasar las fases de anlisis y diseo con demasiada rapidez. Ello empuja al analista a pasar demasiado rpido a la codificacin, sin haber comprendido bien las necesidades y los problemas.

VENTAJAS Los usuarios se hacen participantes ms activos en el desarrollo de sistemas El prototipo sirve como mecanismo para identificar los requisitos del software Para hacer un prototipo se usa fragmentos de programas existentes o aplica herramientas que facilitan la rpida generacin de programas.

2.3.4 MODELO EN ESPIRAL

El modelo en espiral ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico como de la creacin de prototipos; aadiendo un nuevo elemento que es el Anlisis de Riesgos. El modelo en espiral define cuatro actividades principales: Planificacin. Determinacin de objetivos, alternativas y restricciones Anlisis de riesgo. Anlisis de alternativas e identificacin y resolucin de riesgos Ingeniera. Desarrollo del producto de siguiente nivel. Evaluacin del cliente. Valoracin de los resultados de la ingeniera.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

Figura No. 2.3. Modelo en Espiral

Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior) se construyen sucesivas versiones del software, cada vez ms completas. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones y se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera para definir ms el problema y refinar los requisitos. El cliente evala el trabajo de ingeniera y sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto; Sin embargo en la mayora de los casos se sigue avanzando a travs de la espiral y ese camino lleva a un modelo ms completo del sistema. Cada vuelta alrededor de la espiral requiere ingeniera que se puede llevar a cabo mediante el enfoque del ciclo de vida clsico o de la creacin de prototipos PROBLEMAS Requiere de una considerable habilidad para valorar el riesgo, ya que si no se descubre un riesgo importante, pueden surgir problemas.

VENTAJAS El modelo en espiral es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

Permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la creacin del producto. Nos ayuda a reducir los riesgos antes de que se conviertan en problemas.

2.3.5 MODELO INCREMENTAL

El Modelo incremental combina elementos del modelo secuencial con la filosofa interactiva del la construccin de prototipos. Como muestra la Figura No. 2.4, el modelo incremental aplica secuencias lineales en forma escalonada durante el transcurso del tiempo.

Figura No. 2.4. Modelo Incremental

Cada secuencia produce un incremento del software. El primer incremento a menudo es un producto esencial (ncleo), generalmente orientado a la gestin de la base de datos. El cliente utiliza el producto central y como resultado de su utilizacin y/o evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central para implementar funciones y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento hasta que se elabore el producto completo. El modelo de proceso incremental se centra en la entrega de un producto operacional con cada incremento, que lo diferencia del modelo de construccin de prototipos.. Este mtodo es til cuando no existe personal disponible para la una implementacin completa. Los primeros incrementos se puede implementar con menos personas; luego se podra incrementar ms personal para el desarrollo de los incrementos siguientes.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

Los incrementos se pueden plantear para gestionar riesgos tcnicos, por ejemplo, un sistema podra requerir la disponibilidad de hardware nuevo; podra ser posible planificar primeros incrementos de forma que se evite la utilizacin de este hardware y por lo tanto, el proyecto no sufrira retrasos exagerados.

2.3.6 DESARROLLO RPIDO DE APLICACIONES

El Desarrollo Rpido de Aplicaciones (DRA) es una adaptacin a alta velocidad del proceso de desarrollo del software lineal secuencial, que enfatiza un ciclo de desarrollo extremadamente corto. En el modelo DRA se logra un desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se comprenden bien los requisitos y se limita bien el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de perodos cortos de tiempo ( por ejemplo de 30 a 60 das).
Equipo No. 3 Equipo No. 2 Equipo No. 1
Modelado de Gestin
Modelado de Gestin
Modelado de Gestin

Modelado de Datos

Modelado de Datos

Modelado de Procesos Generacin de Aplicaciones Pruebas y entrega

Modelado de Datos

Modelado de Procesos Generacin de Aplicaciones Pruebas y entrega

Modelado de Procesos Generacin de Aplicaciones Pruebas y entrega

De 60 a 90 das Figura No. 2.5. Modelo DRA

DRA comprende las siguientes fases: Modelado de Gestin Responde a preguntas como: Qu informacin conduce el proceso de gestin?, Qu informacin se genera?, Quin lo genera? A dnde va la informacin? Quin la procesa?.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

10

Modelado de Datos El flujo de informacin definido en la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen los atributos de cada uno de los objetos y las relaciones entre estos objetos. Modelado del Proceso En esta fase se implementa las funciones de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir o recuperar un objeto de datos. Gestin de Aplicaciones En esta fase se asume la utilizacin de tcnicas de cuarta generacin, el proceso DRA vuelve a utilizar componentes de programas ya existentes o crear componentes reutilizables. Se utilizan herramientas CASE para facilitar la construccin del software. Pruebas y entrega El hecho de enfatizar en la reutilizacin de componentes reduce el tiempo de pruebas; sin embargo se deben probar todos los componentes nuevos y las interfases. Las limitaciones de tiempo impuestas por DRA demandan un mbito de escalas, como se muestra en la Figura No. 2.5. Si una aplicacin puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses, es un candidato DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto. PROBLEMAS DEL MODELO Para proyectos grandes, DRA requiere recursos humanos suficientes como para crear el nmero correcto de equipos para desarrollar el proyecto. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades, si no hay compromiso, el proyecto DRA fracasar. Si un sistema no puede modularizarse adecuadamente, ser problemtico aplicar DRA. DRA no es adecuado cuando los riesgos tcnicos son altos; esto ocurre cuando una nueva aplicacin hace uso de tecnologas nuevas o cuando el nuevo software requiere un alto grado de interoperatividad con sistemas ya existentes

2.3.7 PROCESO UNIFICADO DE RATIONAL

En este punto se resume los elementos del Proceso Unificado de Rational propuesto por Booch; es uno de los enfoques del ciclo de vida que se adapta especialmente bien a UML. Consta de las cuatro fases siguientes:

INGENIERA DE SOFTWARE I Gloria Arcos Medina

11

INGENIERA DE SOFTWARE I Gloria Arcos Medina

12

FASE Iniciacin Elaboracin Construccin Transicin

OBJETIVO Establecer la planificacin del proyecto Establecer un plan para el proyecto y una arquitectura correcta Desarrollar el sistema Proporcionar el sistema a sus usuarios finales

Las fases de iniciacin y elaboracin incluyen las actividades de diseo del ciclo de vida del desarrollo; la construccin y la transicin constituyen su produccin. Dentro de cada fase hay varias iteraciones. Una iteracin representa un ciclo de desarrollo completo, desde la captura de requisitos en el anlisis hasta la implementacin y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable. Cada fase e iteracin se centra en disminuir algn riesgo y concluye con un hito bien definido. La revisin de hitos es el momento adecuado para evaluar cmo se estn satisfaciendo los objetivos y si el proyecto necesita ser reestructurado de alguna forma para continuar. Iniciacin. Durante esta fase se establece la planificacin del proyecto y se delimita su alcance. La planificacin del proyecto incluye los criterios de xito, la evaluacin del riesgo, estimaciones de recursos que se necesitarn y un plan de fases que muestre la planificacin de los hitos principales. Durante la iniciacin es frecuente crear un prototipo ejecutable que sirva para probar los conceptos. Al final de la fase de inicio se examinan los objetivos del ciclo de vida del proyecto y se decide si proceder con el desarrollo del sistema. Elaboracin. Los objetivos de esta fase son analizar el dominio del problema, establecer una base arquitectnica slida, desarrollar el plan del proyecto y eliminar los elementos de ms alto riesgo del proyecto. Las decisiones arquitectnicas deben tomarse con una comprensin del sistema global. Esto implica que se deben describir la mayora de los requisitos del sistema. Para verificar la arquitectura, se implementa un sistema que demuestre las distintas posibilidades de la arquitectura y se ejecute los casos de uso significativos. Construccin. Durante la fase de construccin se desarrolla de formas iterativa e incremental un producto completo que est preparado para la transicin hacia los usuarios. Esto implica describir los requisitos restantes y los criterios de aceptacin, refinando el diseo. Completando la implementacin y las pruebas del software. Al final de la fase de construccin se decide si el software, los lugares donde se instalar y los usuarios, estn todos preparados para empezar a funcionar. Transicin.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

13

Durante la fase de transicin, el software se despliega en los usuarios. Una vez que el sistema ha sido puesto en manos de los usuarios finales, a menudo aparecen aspectos que requieren un desarrollo adicional para ajustar el sistema, corregir algunos problemas no detectados o finalizar algunas caractersticas que hayan sido propuestas. Esta fase comienza normalmente con una versin beta del sistema que luego ser reemplazada con el sistema de produccin. Al final de la fase de transicin se decide si se han satisfecho los objetivos del ciclo de vida del proyecto, y se determina si se debera empezar otro ciclo de desarrollo. El proceso Unificado de Racional consta de nueve flujos de trabajo: FLUJO DE TRABAJO Modelado del negocio Requisitos OBJETIVO Describe la estructura y la dinmica de la organizacin Describe el mtodo basado en casos de uso para extraer los requisitos Anlisis y diseo Describe las diferentes vistas arquitectnicas Implementacin Tiene en cuenta el desarrollo del software, la prueba de unidades y la integracin Pruebas Describe los casos de pruebas, los procedimientos y las mtricas para la evaluacin de defectos. Despliegue Cubre la configuracin del sistema entregable Gestin de Controla los cambios y mantiene la integridad de los configuraciones artefactos de un proyecto Gestin del proyecto Describe varias estrategias de trabajo en un proceso iterativo Entorno Cubre la infraestructura necesaria para desarrollar el sistema

2.3.8 MICROSOFT SOLUTIONS FRAMEWOK

Microsoft Solutions Framework (MSF) es una serie de conceptos, modelos, disciplinas y prcticas de uso que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas. MSF contiene mltiples componentes que pueden ser utilizados individualmente o adoptados como un conjunto integrado. La figura No. 2.4 representa un resumen de estos componentes. Modelos MSF: Es la descripcin esquemtica de procesos del proyecto: la organizacin de equipos y

Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizar el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el modelo de equipo

INGENIERA DE SOFTWARE I Gloria Arcos Medina

14

Figura No. 2.4. Modelos y Disciplinas de MSF

Disciplinas MSF: MSF reconoce varias reas no tecnolgicas que son competencias importantes de todos los roles en el Modelo de Equipo de MSF. Son reas que utilizan un conjunto especfico de mtodos, trminos y propuestas, creadas para manejar a las personas, procesos y elementos tecnolgicos que se encuentran en la mayora de los proyectos. Disciplina de Administracin del Riesgo. Define un proceso para identificar y valorar los riesgos en un proyecto, priorizacin de estos riesgos e implementacin de estrategias para combatirlos a lo largo de todo el ciclo de vida de los proyectos. Disciplina de Administracin del Proyecto. Es un rea del conocimiento, habilidades, herramientas y tcnicas usadas para conseguir los objetivos de acuerdo a los parmetros de calidad, costos, planificacin y limitaciones. Disciplina de Administracin de Efectividad. Define a la efectividad como una medida del estado actual versus el estado deseado del conocimiento y habilidades de los miembros de una organizacin. Esta medida es la es la posibilidad real o percibida en algn punto durante el proceso de planeacin, construccin y gestin de la solucin. MODELO DE PROCESO MSF El modelo de procesos de MSF combina los mejores principios de los modelos en cascada y espiral ya que considera la planeacin basada en puntos de revisin o hitos del modelo en cascada y los beneficios de la retroalimientacin y creatividad del modelo en espiral Las cinco fases del modelo de procesos MSF se representa en la Figura No. 2.5 Fase 1: Visin. En esta fase el equipo y el cliente definen los requerimientos del negocio y los objetivos generales del proyecto. La fase culmina con el hito Visin y Alcance aprobados.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

15

Fase 2: Planeacin. Durante la fase de planeacin el equipo crea un borrador del plan maestro del proyecto, adems de un cronograma del proyecto, escenarios de uso, la especificacin funcional del proyecto y diseo. Esta fase culmina con el hito Plan del proyecto aprobado. Fase 3: Desarrollo. Esta fase involucra una serie de versiones internas del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus mdulos o partes estn sincronizados y pueden integrarse., adems del desarrollo del cdigo, el equipo implementa la solucin La fase culmina con el hito Alcance completo
Implantacin completa
E D SE IN FA IS V IM F PL AS A E N D TA E C I N

Release Readiness aprobado

Visin y alcance aprobados

Fase 4: Estabilizacin. Esta fase se centra en probar el producto. El proceso de prueba hace nfasis en el uso y el funcionamiento del producto en las condiciones del ambiente real. El equipo se enfoca en la identificacin, priorizacin y resolucin de los problemas para que el producto est listo para el lanzamiento. La fase culmina con el hito Release Readiness aprobado. Fase 5: Implantacin: En esta fase el equipo implanta la tecnologa y los componentes utilizados por la solucin, estabiliza la implantacin, apoya el funcionamiento y la transicin del proyecto, y obtiene la aprobacin final del cliente. La fase termina con el hito Implantacin completa.

INGENIERA DE SOFTWARE I Gloria Arcos Medina

DE IN SE AC FA ILIZ B TA ES

Alcance completo FASE DE DESARROLLO

Plan del proyecto aprobado

Figura No. 2.5: Fases y puntos de revisin de MSF

FAS PLA E DE N EA CIN

16

INGENIERA DE SOFTWARE I Gloria Arcos Medina

17