OSCAR CRUZ JIMENEZ

6CM2

Modelos de desarrollo del Software

Secuencial Lineal
Cascada (clsico) RAD (Desarrollo Rpido de Aplicacin) Incremental Espiral Basado en reutilizacin

Evolutivo

Basado en transformaciones

Modelo de Desarrollo Rpido de Aplicacin - RAD

RAD: Rapid Application Development Modelo secuencial lineal con tiempos cortos de desarrollo Varios equipos participando en el desarrollo Cada equipo maneja una parte del sistema Uso de herramientas de pruebas automatizadas En cada etapa de liberacin, los productos parciales son integrados, probados y liberados

Desventajas:
Para ciclos de desarrollo extremadamente cortos: Requerimientos bien entendidos y alcance de proyecto restringido Se requiere mltiples desarrolladores Compromiso de desarrolladores y clientes para un tiempo de entrega corto No adecuado para sistemas que no puedan ser mantenidos adecuadamente No se enfoca en detalles minuciosos

Modelo Evolutivo
Entregar algo al usuario Recibir retroalimentacin del usuario Ajustar el diseo y objetivos basado a las realidades observadas Enfoques: Incremental Espiral Basado en reutilizacin

Modelo Incremental
Desarrollo paso a paso donde las partes de algunas etapas se posponen. Cada etapa consiste en expandir incrementos de un producto de software operacional Incrementos pueden ser entregados al cliente

OSCAR CRUZ JIMENEZ

6CM2

Cada incremento es diseado, codificado, probado, integrado y entregado por separado Los incrementos se desarrollan uno despus de otro, basados en retroalimentacin recibida del cliente.

Ventajas:
Existe una disponibilidad limitada de recursos de desarrollo. Cuando es difcil establecer todos los requerimientos por anticipado

Desventajas:
Si los requerimientos crecen, la arquitectura y el diseo puede cambiar drsticamente

Modelo en espiral
Propuesto por Barry Boehm en 1988 Desarrollo en ciclos. En cada ciclo: se define el objetivo, se analizan los riesgos, desarrollo y verificacin de la solucin obtenida, revisin de resultados y planificacin del siguiente ciclo Se centra en algunas mejores prcticas: Manejo de Riesgos Orientacin al Cliente Desarrollo Iterativo

Ventajas:
Resolucin temprana de riesgos. Definicin de arquitectura en sus fases iniciales. Basado en un proceso continuo de verificacin de la calidad. Ideal para productos con un nivel alto de inestabilidad de los requerimientos.

Desventajas:
No aplicable a proyectos bajo contrato. No recomendable en proyectos simples.

Las tcnicas de cuarta generacin

Son un conjunto muy diverso de mtodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas caractersticas del mismo a alto nivel, ms tarde, la herramienta genera automticamente el cdigo fuente a partir de esta especificacin.

OSCAR CRUZ JIMENEZ

6CM2

Los tipos ms comunes de generadores de cdigo cubren uno o varios de los siguientes aspectos: 1.-Acceso a base de datos: utilizando lenguajes de consulta de alto nivel. Generadores de cdigos: a partir de una especificacin de los requisitos se genera automticamente toda la aplicacin 2.-Generacin de pantallas: permitiendo disear la pantalla dibujndola directamente, incluyendo adems el control del cursor y la gestin de los errores de los datos de entrada. 3.-Gestin de entornos grficos. 4.-Generacin de informes: Como otros paradigmas, T4G comienza con el paso de recoleccin de requerimientos. En el mejor de los casos el cliente debera describir los requerimientos y stos traducirse directamente a un prototipo operacional pero en general esto no es as. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificacin de hechos que son conocidos y puede ser incapaz o no desear especificar la informacin en la forma que una herramienta T4G puede construirla, adems las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo sern por algn tiempo. Para aplicaciones pequeas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementacin, sin embargo es necesaria una estrategia del diseo para el sistema. El uso de T4G sin diseo para grandes proyectos causar las mismas dificultades (poca calidad, pobre mantenimiento, mala aceptacin por el cliente) que se encuentran cuando se desarrolla software usando los mtodos convencionales. El ltimo paso de la figura anterior contiene la palabra producto para transformar una implementacin T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentacin con sentido y ejecutar todas las otras actividades de transicin requeridas en los otros paradigmas de la ingeniera de software. En conclusin podemos definir que las tcnicas de cuarta generacin pueden reducir drsticamente el esfuerzo y tiempo de desarrollo en aplicaciones de pequeo y mediano nivel, sin embargo debido a su imperfecto estado actual el desarrollo de grandes aplicaciones con estas esta aun muy lejos de convertirse en una realidad.

Modelo de desarrollo concurrente

Es un modelo de tipo de red donde todas las personas actan simultneamente o al mismo tiempo. Davis Sitaram ha descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniera concurrente, de la siguiente forma:

OSCAR CRUZ JIMENEZ

6CM2

Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clsico] no tiene ideal del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente simples. Tenga en cuenta que aunque un proyecto [grande] este en la fase de codificacin, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultneamente. Por ejemplo,...el personal est escribiendo requisitos diseando, codificando, haciendo pruebas y probando la integracin (todo al mismo tiempo). Los modelos de proceso de ingeniera del software de Humphrey y Kellner han mostrado la concurrencia que existe para actividades que ocurren para cualquier fase. El trabajo ms reciente de Kellner utiliza diagramas de estado para representar la relacin concurrente que existe entre actividades asociadas a un acontecimiento especifico, pero falla en capturar la riqueza de la concurrencia que existe en todas las actividades del desarrollo y de gestin del software en mi proyecto...La mayora de los modelos de procesos de desarrollo del software son dirigido por el tiempo; cuanto ms tarde sea, ms atrs se encontrara en el proceso de desarrollo. (Un modelo de proceso concurrente) est dirigido por las necesidades del usuario, las decisiones de la gestin y los resultados de las revisiones.

Metricas del proceso del Software

La medicin es fundamental para cualquier disciplina de ingeniera, y la ingeniera del Software no es una excepcin. Las mtricas del Software se refieren a un amplio elenco de medidas para el Software de computadora. La medicin se puede aplicar al proceso de Software con el intento de mejorarlo sobre una base continua. Podemos definir las Mtricas de Software o Medidas de Software como: La aplicacin continua de tcnicas basadas en las medidas de los procesos de desarrollo de Software y sus productos, para producir una informacin de gestin significativa y a tiempo. Esta informacin se utilizar para mejorar esos procesos y los productos que se obtienen de ellos. Las Mtricas de Software implican medir: medir involucra nmeros; el uso de nmeros para hacer cosas mejor. Las Mtricas de Software pretenden mejorar los procesos de desarrollo de Software y mejorar, por tanto, todos los aspectos de la gestin de aquellos procesos. Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciacin, cuando debemos estimar los costos, al seguimiento y control de la fiabilidad de los productos finales, y a la forma en que los productos cambian a travs del tiempo debido a la aplicacin de mejoras. Las medidas del Software y los modelos de medida son entonces tiles para estimar y predecir costos y para medir la productividad y la calidad del producto. Un ingeniero del Software recopila medidas y desarrolla mtricas para obtener indicadores.

OSCAR CRUZ JIMENEZ

6CM2

Caractersticas de las Mtricas de Software

La calidad de las medidas deberan facilitar el desarrollo de modelos que sean capaces de predecir el comportamiento de determinados parmetros que afectan al desarrollo de productos o procesos. Una medida ideal debera ser : Objetiva Sencilla, definible con precisin para que puede ser evaluada Fcilmente obtenible ( a costo razonable) Valida, la mtrica debera medir exactamente lo que se quiere medir y no otra cosa. Robusta. Debera de ser relativamente insensible a cambios poco insignificativos en el proceso o en el producto .

Adems, para una mejor utilizacin de estas medidas, a la hora de realizar estudios analticos o anlisis estadsticos deberan de tener unos valores que se ajusten a una cierta escala de medida. Clasificacin de las Mtricas de Software Las Mtricas de Software se pueden clasificar, de una manera general. En Mtricas de producto y Mtricas de proceso. Las Mtricas de Producto son medidas de producto Software durante cualquier fase de su desarrollo desde los requisitos hasta la instalacin. Las Mtricas de Producto pueden medir la complejidad del diseo, el tamao del producto final (fuente u objeto) o el nmero de pginas de documentacin producida. Las Mtricas de Proceso son medidas del proceso de desarrollo del Software tales como tiempo de desarrollo total, esfuerzo en das/ hombre o mes / hombre de desarrollo del producto, tipo de metodologa utilizada o nivel medio de experiencia de los programadores.