Metodología, planeacion de proyecto de software

1. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
MODELO DE CASCADA (WATERFALL)
Denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es
el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada
etapa debe esperar a la finalización de la etapa anterior.1 Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final,
que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de
todos los demás modelos de ciclo de vida.
La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.2
Un ejemplo de una metodología de desarrollo en cascada es:
1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Verificación.
7. Mantenimiento.
De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y
nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más
avanzadas de un proyecto.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

2. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
MODELO DE PROCESO EN ESPIRAL
Es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de software.
Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las
actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Para cada ciclo habrá cuatro actividades:
Determinar o fijar objetivos
 Fijar también los productos definidos a obtener: requisitos, especificación, manual de
usuario.
 Fijar las restricciones.
 Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
 Hay una cosa que solo se hace una vez: planificación inicial.
Desarrollar, verificar y validar (probar)
 Tareas de la actividad propia y de prueba.
 Análisis de alternativas e identificación resolución de riesgos.
 Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros
existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de
desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo
basado en transformaciones formales podría ser el más apropiado.
Análisis del riesgo
 Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas
puedan producir. Se evalúan alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.
En resumen, es para tener en cuenta de los riesgos de cada uno de los ámbitos.

3. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
MODELO DE PROTOTIPO
Pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe
utilizar muchos recursos.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño
conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del
software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al
mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Con las siguientes etapas:
 Plan rápido.
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, entrega y retroalimentación
 Comunicación
 Entrega del desarrollo final
A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave
es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:
 Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
 Que el prototipo se descarte, al menos en parte.
 Que después se desarrolle el software real con un enfoque hacia la calidad.

4. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
MODELO INCREMENTAL
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia
con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:
 Método de las comparaciones limitadas sucesivas.
 Ciencia de salir del paso.
 Método de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se
muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada
secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
 Análisis
 Diseño
 Código
 Prueba
Características:
 Se evitan proyectos largos y se entrega "algo de valor"
a los usuarios con cierta frecuencia.
 El usuario se involucra más.
 Difícil de evaluar el costo total.
 Difícil de aplicar a los sistemas transaccionales que
tienden a ser integrados y a operar como un todo.
 Requiere gestores experimentados.
 Los errores en los requisitos se detectan tarde.
 El resultado puede ser positivo.

5. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
MODELO BASADO EN COMPONENTES
Es una rama de la ingeniería de software que enfatiza la separación de asuntos por lo que se refiere a la funcionalidad de amplio rango disponible
a través de un sistema de software dado. Es un acercamiento basado en la reutilización para definir, implementar, y
componer componentes débilmente acoplados en sistemas. Esta práctica persigue un amplio grado de beneficios tanto en el corto como el largo
plazo, para el software en sí mismo y para las organizaciones que patrocinan tal software.
Los ingenieros de software consideran los componentes como parte de la plataforma inicial para la orientación a servicios. Los componentes
juegan este rol, por ejemplo, en servicios de web y, más recientemente, en las arquitecturas orientadas a servicios(SOA), por el que un componente
es convertido por el servicio web en un servicio y consiguientemente hereda otras características más allá de las de un componente ordinario.
Los componentes pueden producir o consumir eventos y pueden ser usados para las arquitecturas dirigida por eventos (EDA).
Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones
relacionadas (o de datos).
Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada
componente están semánticamente relacionados (justo como con el contenimiento de clases). Debido a este principio, con frecuencia se dice
que los componentes son modulares y cohesivos.
Con respecto a la coordinación a lo largo del sistema, los
componentes se comunican uno con el otro por medio de
interfaces. Cuando un componente ofrece servicios al resto del
sistema, éste adopta una interface proporcionada que especifica
los servicios que otros componentes pueden utilizar, y cómo
pueden hacerlo. Esta interface puede ser vista como una firma del
componente - el cliente no necesita saber sobre los
funcionamientos internos del componente (su implementación)
para hacer uso de ella. Este principio resulta en componentes
referidos como encapsulados. Las ilustraciones UML de este artículo
representan a las interfaces proporcionadas, con un símbolo
lollipop unido al borde externo del componente.

6. METODOLOGIAS
PLANEACION DE PROYECTOS DE SOFTWARE
KARLA CRUZ  4105
METODO FORMAL
En ingeniería de software un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del
desarrollo de sistemas informáticos. Los métodos formales se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a
la hora de encarar la construcción o el análisis de un modelo matemático de un sistema.
En 1967, Robert Floyd propuso utilizar lo que se denominó método de aserciones intermedias como una manera de estudiar las propiedades de los
programas. Destacó la posibilidad de definir la semántica de las operaciones mediante reglas lógicas afirmando que estas aserciones son válidas
después de ejecutarse las operaciones basándose en la información de las aserciones que son válidas antes de ejecutarse dichas operaciones.
Sus ventajas son:
 Se comprende mejor el sistema.
 La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
 El sistema se describe de manera más precisa.
 El sistema se asegura matemáticamente que es correcto según las especificaciones.
 Mayor calidad software respecto al cumplimiento de la realidad hacia el desarrollo de herramientas que apoyen la aplicación de métodos formales es
complicado y los programas resultantes son incómodos para los usuarios.
 Los investigadores por lo general no conocen la realidad industrial.
 Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.
 Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.