Comentario:
Microsoft Solutions Framework en sus dos versiones (3.0 y 4.0) combinan dos modelos existentes, beneficiándose de la planificación basada en hitos del modelo cascada y del proceso creativo iterativo del modelo espiral. Al momento del desarrollo del proyecto, todos en el equipo tienen igual grado de participación y son responsables del mismo. Además permite tratar el riesgo antes de que se presente como problema, ahora como inconvenientes con este modelo podría citar que en una empresa pequeña habría mucha planificación lo cual alargaría la duración del proyecto; este modelo fue hecho con base al empleo de las herramientas de Microsoft por lo que adaptarlo al uso de otras herramientas resultaría un poco más complejo.
Links:
http://www.malagadnug.org/ficheros/MSFMartinLuisReq.pdf
En este link (pdf) nos muestra una descripcion de MSF, hay informacion que se expuso en clases.
Comentario:
El Modelo RUP Se caracteriza por ser iterativo e incremental, además está guiado por los casos de uso y se centra en la arquitectura. En este modelo están contenidos los artefactos y los roles. Los artefactos son los productos tangibles del proceso como por ejemplo, el código fuente, etc., y el rol es el papel que desempeña una persona en un determinado momento, esta persona puede desempeñar distintos roles a lo largo del proceso en el desarrollo del software.
Ahora hablando sobre el modelo Open Up (Proceso Unificado Abierto), este modelo es muy parecido al modelo RUP, con la diferencia que al contrario del RUP que es un modelo bastante lento para el desarrollo de software, el Open Up es un modelo ágil, pero al igual que el RUP para emplearlo hay que hacerlo con mucha disciplina si queremos un software de buena calidad.
Links:
http://www.histaintl.com/servicios/consulting/rup.php
En esta página nos describe algunos escenarios del RUP.
Comentario:
El RUP es un proceso de desarrollo de software que pretende ser un modelo completo en todos los aspectos, teniendo 4 fases: Inicio; Elaboración, Construcción y Transición. Apreciándose en cada una de ellas distinto número de iteraciones, por lo tanto, sigue un modelo iterativo que trata de reducir los riesgos del proyecto. Si se sigue adecuadamente este modelo me parece que se conseguiría un software con muy buena calidad. Para esto, en el transcurso del desarrollo del software deberíamos ser muy disciplinados, no descuidarnos de cada punto involucrado en el desarrollo del proyecto, pues de lo contrario el esfuerzo que se emplee no dará el resultado que uno espera. Como inconveniente en este modelo creo podría ser que por el intento en haber desarrollado este modelo y hacerlo tan completo, si no se es cuidadoso y responsable al utilizar este modelo no podremos cubrir las expectativas del software final.
Links:
http://user.it.uu.se/~paupet/gu/projdv03/slides/04-rup.pdf
Este es un pdf en el cual nos explica lo que es el RUP. (Lo mismo visto en clase pero en versión en inglés).
http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/c9.html
En esta página nos muestra un tutorial de lo que es UML.
http://www.osmosislatina.com/lenguajes/uml/
En esta página muestra una descripción de lo que es UML.
Comentario:
Los modelos iterativo e incremental al igual que el anterior modelo tienen varias ventajas bajo mi consideración, como son: los clientes no tienen que esperar hasta tener el producto final en sus manos, pues se lo desarrolla por partes, incrementándolas y juntándolas después, siendo este un ciclo iterativo, de esta manera el cliente se involucra, teniendo la oportunidad de probar y dar su opinión en el avance del proyecto. El progreso se puede medir en periodos cortos de tiempo. Las pruebas del software y la integración son constantes.
Además si existiera errores producidos en un incremento se pueden solucionar en el próximo incremento.
Al final de cada ciclo se entrega una versión completa del software mejorada respecto a la anterior, estos ciclos se repiten hasta obtener un producto satisfactorio tanto para el desarrollador así como para el cliente.
Los inconvenientes que podrían existir son: lo difícil de evaluar el coste final, cierta dificultad al ajustar los requisitos a los incrementos, y quizás también al introducir cambios el software quedaría muy “parchado”.
Links:
http://www.highproductivity.org/r6047.pdf
En este link en inglés (documento pdf) nos da una breve historia del desarrollo iterativo e incremental.
Comentario:
El Desarrollo de Software Basado en Componentes en mi criterio tiene muchas ventajas, una de las principales se basa en la reutilización de componentes, de esta manera, los componentes se los diseña con el objetivo de poder ser reutilizados en otros proyectos, favoreciendo a la necesidad de realizar software complejo en cortos periodos de tiempo y a la vez con un menor esfuerzo en la realización del mismo, los costos son mucho menores que desarrollar un software desde cero, la reutilización de código previamente realizado y probado nos facilita el trabajo, mejorando la fiabilidad del producto final.
Estos componentes de software ya desarrollados, son combinados adecuadamente para obtener un producto final de buena calidad, pues dado que un componente puede ser construido y luego mejorado continuamente, la calidad de un software basado en componentes mejorará con el tiempo, para esto hay que realizar una precisa búsqueda y selección de componentes apropiados que se emplearán en el desarrollo del software. Con esto hay que tener especial cuidado pues si al ensamblar los distintos componentes uno de ellos no es confiable, el software en cuestión tendría fallas.
En resumen el Desarrollo de Software Basado en Componentes, como ventajas podría decir que nos ahorra tiempo por la reutilización de componentes, esfuerzo, dinero, y además obtenemos un software de buena calidad..
-> Links:
http://www.sei.cmu.edu/str/descriptions/cbsd.html
En esta página en inglés nos dan algunos conceptos y criterios sobre el Desarrollo de Software Basado en Componentes, sobre el propósito y origen, detalles técnicos, componentes de adaptación (Formas de reutilización), COTS, y muchos temas más al respecto.
http://download.microsoft.com/download/c/2/c/c2ce8a3a-b4df-4a12-ba18-7e050aef3364/070717-Real_World_SOA.pdf
Este es un documento pdf de Microsoft, muy completo en el cual nos habla sobre la aplicación de la Arquitectura Orientada a Servicios (SOA), nos explica de qué se trata el SOA, sus beneficios, y demás temas de interés relacionados con el SOA.
Comentario:
En este modelo representado por una espiral, en que cada giro representa una fase en el proceso, no hay fases fijas, pues se gira en la espiral dependiendo de lo que se requiere, los riesgos son explícitamente identificados y resueltos durante el proceso, ésta es una de las ventajas del Modelo Espiral, se incluye en este modelo el llamado “Análisis de riesgo”, en donde se prevé los posibles fallos que se pudieran dar en el desarrollo del software, pero la desventaja es que por el sin número de vueltas que se daría en el avance del proyecto, el factor tiempo no nos resultaría conveniente, pues podríamos estancarnos en un ciclo y tardarnos mucho tiempo hasta pasar al siguiente ciclo, sin embargo, al culminar con el proyecto, éste en cada ciclo se ha ido perfeccionando, por lo que obtendríamos un software de mejor calidad.
La manera de operar de este modelo es conveniente utilizarlo en proyectos complejos, más no en proyectos sencillos, que no tienen mayor complejidad, pues perderíamos mucho tiempo en realizar ese software.
En el modelo espiral con ganancia hay una mejora en cuanto a que se toma en cuenta los puntos de vista de todas las partes, es decir, usuario - cliente - desarrollador, para conseguir conformidad en todos y así desarrollar un software con mayor aceptación para el cliente y el usuario en conjunto. Aunque aún con esta mejora las debilidades de este modelo no se apartan.
Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que representa el sistema que sería implementado (McCracken y Jackson, 1982). Dicha aplicación, llamada prototipo, está compuesta por los componentes que se desean evaluar (i.e. las funciones principales). Las etapas del modelo son:
- Investigación preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rápido:
- Análisis y especificación del prototipo.
- Diseño y construcción del prototipo.
- Evaluación del prototipo por el cliente.
- Renacimiento del prototipo.
- Diseño técnico.
- Programación y test.
- - Operación y mantenimiento.
Para construir un prototipo del software se aplican los siguientes pasos:
PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo.
Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que: 1) el cliente participe en la evaluación y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo.
PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos.
Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.
PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo.
El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.
PASO 4. El software del prototipo se crea, prueba y refina
Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen.
Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-maquina usando una serie de hojas de historia.
PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.
PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.
El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propósito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación, o 2) el propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y ambos crean problemas.
Comentario:
El empleo de prototipos para el desarrollo de software son útiles para comunicar, discutir y definir las ideas entre los diseñadores y las partes responsables (clientes).
Es frecuente que los clientes no sepan lo que quieren, pero cuando ven algo y lo utilizan, pronto saben lo que no quieren. Es por esto que un prototipo nos es de gran ayuda.
Los prototipos responden a preguntas y apoyan el trabajo de los diseñadores probando ideas, clarificando requisitos o definiendo alternativas.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.
