MODELOS DELA INGENIERIA DEL SOFTWARE

ÍNDICE

Introducción……………………………………………………4

2.1 MODELO DE CAPACIDAD DE MADUREZ………….5

2.2 MARCO DE TRABAJO PARA EL PROCESO……..…6

2.3. MODELOS DE LA INGENIERÍA DEL SOFTWARE: MODELO DE CASCADA, MODELO DE PROTOTIPOS, MODELO DE ESPIRAL, MODELO DE PROCESO UNIFICADO RACIONAL (RUP)………………………………7

2.4. TENDENCIAS MODERNAS DE MODELOS DE LA INGENIERÍA DEL SOFTWARE………………….14

INTRODUCCIÓN

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes [1]:

• Los sistemas no responden a las expectativas de los usuarios.

• Los programas “fallan” con cierta frecuencia.

• Los costes del software son difíciles de prever y normalmente superan las estimaciones.

• La modificación del software es una tarea difícil y costosa.

• El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.

• Normalmente, es difícil cambiar de entorno hardware usando el mismo software.

• El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

2.1 MODELO DE CAPACIDAD DE MADUREZ

Éste corresponde a uno de los modelos más conocidos creado por el SEI (Software Engineering Institute) de la Carnegie Mellon University. El CMM pretende conseguir mejorar la calidad del software mejorando la calidad de los procesos utilizados en su desarrollo. "Las herramientas y las plataformas cambian de forma continua. Pero siempre podemos usar el mismo proceso si éste está bien definido y se sabe utilizar de forma adecuada."

 Niveles de madurez:

1. El primer nivel (Caos) se produce cuando en la empresa no existe ningún modelo y que todo se hace sobre la marcha es decir no se emplea ningún proceso definido.

2. En el segundo nivel (Repetible) se encuentran las empresas en las que existe planificación y seguimiento de proyectos y está implementada la gestión de los mismos.

3. El tercer nivel (Definido) documenta y normaliza los procesos a nivel organizativo. Las claves de este nivel son la gestión de los requisitos, planificación de proyectos y su seguimiento a través de toda la organización

El (Medible) pone énfasis en la calidad del proceso y del producto. Lo tienen las empresas capaces de medir el estado de un proyecto y utilizar esta información para que los jefes introduzcan los cambios y correcciones necesarias. Una vez adquirido este nivel en la gestión de los proyectos se pueden establecer objetivos.

El quinto nivel (Mejora continua) se conoce como proceso continuo de mejora. Las áreas clave del proceso incluyen prevención de defectos, administración de cambios tecnológicos y gestión de cambios en los procesos

Métodos de evaluación:

Para conseguir la certificación CMM, es necesario contactar con algún evaluador acreditado por el SEI. Éstos utilizan distintos métodos para determinar en las organizaciones el nivel de madurez en el que se encuentra el proceso utilizado en el desarrollo de software.

Entre estos métodos destaca el SCE consiste en una auditoría y el CBA-IPI utiliza entrevistas y otros procedimientos encaminados a ayudar a la mejora de los procesos seguidos en la organización.

2.2 MARCO DE TRABAJO PARA EL PROCESO:

Base para el proceso de software completo.

•Es como un libro de recetas de cocina.

•La adaptación es especial

•Aplicable a lo largo del proceso de software.

• garantizar la calidad del software.

Actividades del marco de trabajo:

(Aplicable a todos los proyectos)

•Comunicación

•Planeación

•Modelado

•Construcción

•Despliegue

Conjunto de tareas:

Actividades que hacen que el marco de trabajo se adapte a las caracteristicas particulares de cada proyecto. Define el trabajo real a cumplirse:

 Tareas

 Puntos SQA

2.3. MODELOS DE LA INGENIERÍA DEL SOFTWARE: MODELO DE CASCADA, MODELO DE PROTOTIPOS, MODELO DE ESPIRAL, MODELO DE PROCESO UNIFICADO RACIONAL (RUP).

MODELO CASCADA

•Es un modelo sencillo para explicar al cliente.

•También llamado ciclo de vida clasico sugiere un enfoque sistemático. Secuencial en el desarrollo del software.

•Requiere que los requerimientos estén bien definidos y estables en forma razonable.

•Es el paradigma más antiguo para la Ingeniería del Software.

FASES:

•Ingeniería y Análisis del Sistema: Debido a que el software siempre es parte de un sistema mayor el trabajo comienza estableciendo los requerimientos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

•Análisis de los requerimientos del software: El proceso de recopilación de los requerimientos se centra e intensifica especialmente en el software. El ingeniero del software debe comprender el ámbito de la información del software así como la función del rendimiento y las interfaces requeridas.

•Diseño: Se enfoca en cuatro atributos distintos del programa la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz.

•Codificación: Debe traducirse en una forma legible para la maquina.

•Prueba: Se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requiere.

•Mantenimiento: El software sufriría cambios después de que se entrega al cliente ocurren debido a que hayan encontrado errores que el software deba adaptarse a cambios del entorno externo o que el cliente requiera aplicaciones funcionales o del rendimiento.

Características:

Es el más utilizado.

Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios.

Para que el proyecto tenga éxito deben desarrollarse todas las fases.

Las fases continúan hasta que los objetivos se han cumplido.

Si se cambia el orden de las fases, el producto final será de inferior calidad.

Ventajas:

La planificación es sencilla.

La calidad del producto resultante es alta.

Permite trabajar con personal poco calificado.

Desventajas:

No refleja realmente el proceso de desarrollo del software.

Se tarda mucho tiempo en pasar por todo el ciclo.

El mantenimiento se realiza en el código fuente.

Las revisiones de proyectos de gran complejidad son muy difíciles.

MODELO DE PROTOTIPOS:

•Es una visión preliminar del modelo futuro.

•Es un modelo operable.

•Fácilmente ampliable y modificable.

•Tiene todas las características propuestas pero realmente es un modelo basico que tiene que ser mejorado

Ventajas:

•La posibilidad de cambiar el modelo.

•La oportunidad para suspender el modelo del desarrollo del modelo sino es funcional.

•La oportunidad de crear un nuevo modelo que se ajuste a mejor a las necesidades y expectativas de los usuarios.

Relaciones de usuario:

Las sugerencias obtenidas de los usuarios lleven al analista hacia adecuaciones o cambios que se ajustan mejor a las necesidades de los usuarios y que no habían sido pensadas antes de la interacción del usuario con el prototipo. Debe ser construido en poco tiempo, no debe de utilizarse mucho dinero, cuando este sea aprobado podemos iniciar el verdadero desarrollo del software. Prodra ser construido si con el software es posible experimentar.

Desventajas:

Debido a que el usuario ve que funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.

Debe ir acompañado de otro modelo para su desarrollo.

Tipo de modelo de prototipo:

•Desechable.: Nos sirve para eliminar dudas sobre las que realmente quiere al cliente además para desarrollar la interfaz que más le convenga al cliente.

•Evolucionario.: Es parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad.

A favor:

 Útiles cuando los requerimientos son cambiantes.

 Cuando no se conoce bien la aplicación.

 Cuando el usuario no se quiere comprometer con los requerimientos.

 Cuando se quiere probar una arquitectura o tecnología. Cuando se requiere rapidez en el desarrollo.

 En contra:

 No se conoce cuando se tendrá un producto aceptable.

 No se sabe cuántas

...