PARADIGMAS DEL SOFTWARE

TRABAJO COLABORATIVO 1

PRESENTADO A:

Ing. JAIRO MARTINEZ BANDA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

INGENIERIA DE SOFTWARE

ING. SISTEMAS

PITALITO, MARZO DE 2010

Actividad 1. (Individual). Para el capítulo 1, el equipo de trabajo dividirá de manera equitativa entre sus integrantes, el estudio de los Mitos del Software y se elaborará de manera individual una tabla con los siguientes campos:

• Mito o Creencia: Explicar en qué consiste el mito,

• Validez: Basado en la teoría o la experiencia, explicar cómo se puede verificar la falsedad o veracidad de ese mito.

MITOS DEL CLIENTE

MITO O CREENCIA

VALIDEZ

- Una declaración general de los objetivos es suficiente para comenzar a escribir los programas.

- Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.

-En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores de software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollador del software.

- Falso. El éxito de un proyecto está amarrado a unas buenas bases, como hacer bien algo que no se conoce? Como definir un tiempo sin conocer el alcance del proyecto? Como estimar ese alcance si no se tienen definidos claramente los requerimientos?

Es necesario pues un buen levantamiento de requerimientos, estructurado, con una definición clara de alcances y limitaciones tanto del proyecto como de sus partes (cliente – proveedor), así como tener previamente establecidos los criterios de aceptación, entre mas claras y escritas se tengan las cosas menos problemas futuros se van a tener.

Actividad 2. (Individual). Para los capítulos 2 y 3, el equipo de trabajo dividirá entre sus integrantes el estudio de los Paradigmas de la Ingeniería del Software (Modelos de Proceso de Software) y elaborará de manera individual una tabla con los siguientes campos: Paradigma, Ventajas, Desventajas y un escenario donde se aplique el modelo o paradigma.

PARADIGMAS DEL SOFTWARE VENTAJAS

DESVENTAJAS

CICLO DE VIDA CLASICO Ingeniería y Análisis del Sistema: El Software es siempre parte de un sistema mayor, por tanto se comienza estableciendo las entidades, roles, funciones, etc de los que antevienen en el sistema, se identifican los requisitos del sistema y luego se asigna un sub conjunto de estos requisitos al software.

• Análisis de Requisitos del Software: Recopilación de los requisitos específicamente del software. El analista debe comprender el ámbito de la información, la función, el rendimiento y las interfaces del software.

• Diseño: Traduce los requisitos en una representación de software que pueda ser codificada.

• Codificación: Traducción del diseño en código fuente escrito en un lenguaje de programación.

• Prueba: Verificación de que las funciones del software producen los resultados que realmente se requieren.

• Mantenimiento: El mantenimiento aplica cada uno de los pasos precedentes para implementar los cambios que con el tiempo indudablemente sufrirá el software. • Si se cumplen eficazmente cada uno de estos puntos casi que nos garantiza una salida en marcha más pronta y eficiente. Cada escala es requisito de su sucesora por tanto saltarse una etapa puede crear inconvenientes en el proyecto.

• Fácil adaptación de métodos (estructurados, orientados a objetos...)

• Constituye la base de los demás paradigmas.

• Es el más ampliamente utilizado.

• Las frecuentes iteraciones crean problemas para su aplicación.

• No es apropiado si los requisitos no están claros al principio.

• Hay que esperar hasta el final para obtener la 1ª versión operativa.

• Se requiere mucha paciencia por parte del cliente.

CONSTRUCCION DE PROTOTIPOS • El cliente define los objetivos generales del software, pero no identifica detallamente todos los requisitos.

• El prototipo puede ser elaborado en papel o programado para que implemente algunas funciones requeridas de manera rudimentaria, sin todos los detalles y acabados del programa final.

• Se empieza con la recolección de requisitos, se produce un diseño “rápido” que se enfoca sobre los aspectos visibles al usuario ( pantallas, informes, etc )

• Se construye el prototipo y se evalúa por parte del cliente y sus observaciones se usan para refinar los requisitos del software a desarrollar.

• Se produce un proceso iterativo en el que el prototipo se “afina” para que satisfaga las necesidades del cliente y al mismo tiempo facilita al desarrollador una mejor comprensión de lo que hay que hacer. • Son reales y tangibles.

• Permite al cliente aclarar lo que quiere que haga el sistema.

• Siente que es oído y tenido en cuenta para el diseño.

• Asegura que el trabajo se está haciendo bien y cumpliendo los requerimientos del cliente.

• El cliente puede creer que el sistema ya está listo y pedir su entrega rápida.

• El

...