Está en la página 1de 8
26 DE AGOSTO DE 2014 PROCESOS PRESCRIPTIVOS INGENIERÍA DE SOFTWARE DOCENTE: PALOMA GONGORA SABIDO GRADO

26 DE AGOSTO DE 2014

PROCESOS PRESCRIPTIVOS

INGENIERÍA DE SOFTWARE

DOCENTE: PALOMA GONGORA SABIDO

GRADO Y GRUPO: 5B

INTEGRANTES: DARWIN U. CRUZ QUIÑONES WALTER A. HERNANDEZ POOT

INGENIERIA EN SISTEMAS COMPUTACIONALES. INSTITUTO TENOLOGICO SUPERIOR DE FELIPE C. PUERTO.

INDICE

INTRODUCCION……………………………………………………………………………………………………. 2 CONTENIDO………………………………………………………………………………………………………… TABLA COMPARATIVA………………………………………………………………………………………… REDACCION DE ARGUMENTOS…………………………………………………………………………… BIBLIOGRAFIA………………………………………………………………………………………………………

7

6

3

3

26 de agosto de 2014 1

26 de agosto de 2014

26 de agosto de 2014 1

1

INTRODUCCION

Cualquier organización de ingeniería de software debe describir un conjunto de actividades dentro del marco de trabajo para el o los procesos que adopte para sus distintos proyectos.

Los procesos deben llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería. Y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo y los productos de trabajo, que deben lograrse para alcanzar las metas de desarrollo.

Después la organización debe adoptar el modelo de procesos resultante y ajustarlo a la naturaleza específica de cada proyecto, personas y ambiente en donde se ejecutará el trabajo.

Estos modelos son los modelos prescriptivos de proceso, los cuales definen un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para desarrollar software de alta calidad. Estos modelos de proceso no son perfectos, pero proporcionan una guía útil para el trabajo de la ingeniería del software.

El uso de modelos prescriptivos es de suma importancia ya que estos proporcionan estabilidad, control y organización a una actividad que si no se controla puede volverse caótica.

En el siguiente trabajo analizaremos las características, ventajas y desventajas que poseen dos distintos modelos prescriptivos, los cuales nos permitirán observar las diferencias que posee cada modelo frente al otro en los distintos procesos establecidos para alcanzar las metas de desarrollo de software.

26 de agosto de 2014 2

26 de agosto de 2014

26 de agosto de 2014 2

2

CONTENIDO

TABLA COMPARATIVA

PROCESO

CARACTERISTICAS

Y

VENTAJAS

DESVENTAJAS

PARTICULARIDADES

MODELO EN

1.

Modelo de proceso de

1.

No requiere una

1.

La espiral puede ser un

ESPIRAL

software evolutivo, que conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada.

definición completa, de los requerimientos del software

problema, si la administración exige que el desarrollo tenga un presupuesto fijo, cada vez que se completa un circuito se considera y revisa el costo del

a desarrollar para comenzar su funcionalidad.

2.

Es muy factible aprobar

proyecto.

los requisitos, en la terminación de un producto,

2.

Existe complicación,

2.

Enfoque cíclico, para el

desde el final de la primera iteración.

cuando se evalúa los riesgos.

crecimiento incremental del grado de definición e implementación de un sistema, mientras disminuye su grado de

riesgo.

 

3.

Requiere experiencia en la

3. Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a

identificación de riesgos.

4.

Se requiere la participación

continua por parte del cliente.

3.

Se adapta y aplica en el

tiempo.

5.

Se pierde tiempo, al volver

ciclo de vida completo de una aplicación, desde el desarrollo del concepto hasta el mantenimiento de la misma.

4.

cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Es posible tener en

producir inicialmente una

especificación completa de los requerimientos cuando se modifica o mejora el software.

6.

Genera mucho tiempo en

4.

La diferencia principal,

 

el desarrollo del sistema

entre el modelo espiral y los demás es que contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. El riesgo es todo lo que pueda salir mal en un proyecto de desarrollo de software.

7.

Modelo costoso.

5.

Conjunto de puntos de

 

fijación, para asegurar el

 
26 de agosto de 2014 3

26 de agosto de 2014

26 de agosto de 2014 3

3

 

compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

   

6. Este modelo es el indicado, para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC ́s.

DESARROLL

1.-Componentes

1.-Simplifica las pruebas. Permite que las

1.- Confiabilidad de los componentes. Los componentes son cajas

O BASADO

independientes, que son completamente especificados por sus interfaces. Debería haber una clara separación entre la interfaz de los componentes y su implementación para que una implementación de un componente pueda reemplazarse por otro sin cambiar el sistema,

2.-Implementación de middleware, esto proporciona soportes software para la integración de componentes. Para conseguir que componentes independientes y distribuidos trabajen juntos, se necesita un soporte middleware que maneje las comunicaciones de los componentes.

EN

COMPONEN

 

TES

pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.

2.-Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.

3.-Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

negras de unidades de programas, y el código de los componentes puede no estar disponible para los usuarios de dichos componentes.

2.-Certificación de componentes. Estrechamente relacionada con la confiabilidad se halla la cuestión de la certificación. Se ha propuesto que asesores independientes deberían certificar los componentes para asegurar a los usuarios que los componentes son confiables. Sin embargo, no está claro cómo se puede hacer esto. ¿Quién pagaría por la certificación?, ¿quién sería responsable si el componente no funciona de acuerdo con la certificación?.

3.-Predicción de propiedades emergentes. Todos los sistemas tienen propiedades emergentes, y el intentar predecir y controlar estas propiedades emergentes es importante en el proceso de desarrollo del sistema. Debido a que los componentes son opacos, predecir sus

3.-Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.

4.-Ciclos de desarrollo más cortos. La adición de una pieza dada de funcionalidad

26 de agosto de 2014 4

26 de agosto de 2014

26 de agosto de 2014 4

4

tomará días en lugar de meses ó años. 5.-Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo.

6.-Funcionalidad

propiedades emergentes es particularmente difícil. Como consecuencia, es posible encontrarse con que, cuando se integran componentes, el sistema resultante tiene propiedades no deseadas que limitan el uso.

4.-Equilibrio de requerimientos. Normalmente se tiene que encontrar un equilibrio entre los requerimientos ideales y los componentes disponibles en el proceso de especificación y diseño del sistema. Por el momento, alcanzar este equilibrio es un proceso intuitivo. Necesitamos un método de análisis de equilibrio sistemático y más estructurado para ayudar a los diseñadores a seleccionar y configurar componentes.

mejorada. Para usar un componente que contenga una pieza de funcionalidad, solo se necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que sería impráctica de implementar en la empresa, se vuelve ahora completamente asequible.

26 de agosto de 2014 5

26 de agosto de 2014

26 de agosto de 2014 5

5

- Método en espiral

ARGUMENTACION

La razón por la cual se escogió el modelo de espiral es debido a que es un modelo de desarrollo de software el cual posee características que comparte con otros modelos como lo que sea de carácter evolutivo y basado en iteraciones al igual que poseer una características únicas como lo es que sea un proceso cíclico y considere el análisis de riesgos, el cual es analizar todo lo que pudiera salir mal en el desarrollo del software.

Creemos que las características que posee este modelo en el desarrollo de software son muy útiles, ya que al ser un proceso cíclico y de iteraciones, nos permite repetir el ciclo del proceso de desarrollo tantas veces como sea necesario hasta cumplir con las expectativas planteadas en un principio, realizando así un software más completo y que haya pasado por varios prototipos de prueba hasta su producto final. Destacamos que este modelo se considera como un enfoque realista para el desarrollo de software y de sistemas a gran escala, esto dado a su robustez y la cantidad de iteraciones que se haga uso en el ciclo.

- Método de desarrollo basado en componentes

La reutilización informal es independiente del proceso de desarrollo con el cual se trabaje. Sin embargo, en los últimos años, ha surgido un enfoque de desarrollo de software CBSE (Ingeniería del software basada en componentes), esta se basa principalmente en la reutilización del código, que últimamente se está usando de forma frecuente.

Elegimos el modelo de desarrollo de software basado en componentes por la considerable reutilización de software que se implementa, siendo esta su característica más importante. Otros aspecto importantes son: la calidad del software al implementar este modelo, la simplicidad al momento de ejecutar el proceso de pruebas, el proceso de mantenimiento, la reducción de gastos al implementar código o componentes ya desarrollados y el tiempo para concluir el proyecto resulta más corto y por ende los gastos disminuyen de forma considerable.

26 de agosto de 2014 6

26 de agosto de 2014

26 de agosto de 2014 6

6

BIBLIOGRAFIA

Roger S. Pressman (2007). Ingeniería del software, un enfoque práctico. (6ª.ed.). México: McGraw- Hill/Interamericana Editores S.A de C.V

Ian Sommerville (2002). Ingeniería de software. (6ª.ed.) México: Editorial Pearson Educación.

Ian Sommerville (2005). Ingeniería de software. (7ª.ed.) México: Editorial Pearson Educación.

26 de agosto de 2014 7

26 de agosto de 2014

26 de agosto de 2014 7

7