Microsoft Solution Framework 3.0 (MSF)
Este modelo se basa principalmente en los modelos espiral y cascada (hitos y fases). Como su nombre lo dice fue desarrollado por Microsoft con el objetivo de crear un modelo estructurado basado en una estructura de trabajo en desarrollo de software.
Tiene como principios fundamentales la comunicación (entre cliente/usuario y entre nosotros), una capacitación de las personas (disciplina de disponibilidad) es decir cumple con el proceso de formación de personal, compartir los roles entre todo el equipo de trabajo. MSF es un proceso versionado y se debe crear versiones para el negocio de cada cliente, debe ser ágil, ya que es menos abultado que RUP. Otro principio es la inversión de calidad (tiempo, trabajo, dinero); hay que tomar en cuenta que cada proyecto es una inversión, más no un gasto.
MSF se compone de 2 modelos y 3 disciplinas. Modelo de Equipo y de Proceso. Disciplina de Administración de Proyecto, Administración de Riesgos y Administración de la Preparación.
Como vimos MSF es un proceso muy largo, pero a la vez es muy solvente para la solución de un problema. Este modelo no utiliza UML.
Para empezar con un proyecto de desarrollo empezaremos con la visión, cuya meta principal es establecer la comunicación y evaluar aquellas limitaciones que podamos tener. Luego analizaremos si existen riesgos para controlarlos a tiempo.
Después de analizar la visión seguimos con la planificación en donde se debe tener en cuenta el cronograma establecido (tiempo, dinero, recursos) y concretar los puntos de control de avance del proyecto. Este cronograma debe hacerse sobre Microsoft Proyect. Debemos enfatizar en que nuestro cronograma puede ser cambiado tan solo si el proyecto así lo pida, pero tomando en cuenta que nuestro objetivo del proceso es agrandar la calidad disminuyendo el tiempo de entrega.
Para seguir con el desarrollo se debe conseguir versiones del producto entregable, las cuales deben ser entregadas mediante fuentes y ejecutables (construcción de los frameworks).
En la estabilización se encuentra y se solucionan posibles errores. Y que no nos pase lo mismo que Windows Vista, el cual salió al mercado sin lograr estabilizar y solucionar todos sus defectos. Hasta que finalmente llegamos a la instalación del software donde éste es aceptado por el cliente. Se entrega al cliente en formatos digitales y documentados ejecutables, directorios, archivos, bases de datos, scripts, instaladores, manuales y licencias. Como en todo proceso de desarrollo de software brindamos el soporte técnico adecuado.
Microsoft Solution Framework 4.0 Agile (MSF)
MSF 4.0 presenta dos principios adicionales: una mayor vinculación estrecha con los clientes y que todos los productos sean entregables. Utiliza frameworks descriptivos similares en muchos aspectos a MSF 3.0, pero la gran diferencia es incluye dos metodologías:
MSF para el desarrollo de Aplicaciones Ágiles y MSF para el proceso de mejora CMM.
Al igual que la versión anterior define un equipo de trabajo, pero la ventaja es que aumenta la agilidad.
Ventajas
La ventaja principal ventaja es que al ser un modelo desarrollado por Microsoft se puede tener mayor soporte y mantenimiento, además la mayoría de los usuarios finales están más acostumbrados con este producto. Además sirve para grandes y pequeños proyectos.
Cabe recalcar que MSF no se parece al RUP en algunas definiciones (principalmente en la cuestión de los cambios).
Pero al haber estudiado todos estos modelos, veo que MSF será el mas conveniente para desarrollar el proyecto que nos habló la ingeniera.
Desventajas
La principal desventaja es que se torna un trabajo bastante largo, ya que para cada fase se debe documentar profundamente todo lo que se haga, pero no deja de ser un modelo que tiene buenos resultados.
LINKS
http://rrivera334.blogspot.es/i2007-05/
Este link es de un compañer@ del semestre pasado en donde habla de las dos versiones de MSF 3.0 y 4.0 y finalmente habla de modelos ágiles y su diferencia con modelos antes estudiados.
http://209.85.165.104/search?q=cache:FQ4TFUVaCXAJ:download.microsoft.com/download/4/4/E/44E1B331-E509-4D10-A9E3-B60640A3A403/20051206-ARC-BA.ppt+Microsoft+Solution+Framework+4.0+Agile+(MSF)&hl=es&ct=clnk&cd=1&gl=ec&client=firefox-a
Este link habla más profundamente de MSF v.4 Agile proporcionado por la Lic. Patricia Scalzone.
http://es.wikipedia.org/wiki/SW-CMM
Este link define lo que es CMM: El Modelo de Madurez de la Capacidad para el desarrollo de Software (Capability Maturity Model for Software, SW-CMM)
Proceso Unificado Rational RUP con Herramientas
Parte 2
Esta clase empezamos con la segunda parte de RUP, analizando Trabajadores, actividades y artefactos.
Los trabajadores ejecutan cierta actividad con el fin de obtener un artefacto. Como vimos el trabajador desempeña ciertos roles, y dicha persona debe tener diferentes funciones, es decir debe usar varias camisetas, por ejemplo el diseñador del proyecto a su vez puede ser autor y diseñador de casos de uso. Pudiendo ocupar cualquiera de estos roles cualquier otra persona que desarrolla el proyecto. Es por eso, que cuando tengamos a cargo una obra, debemos estar listos y dispuestos a tomar parte en cualquier rol que tengamos que desempeñarnos.
Dentro de las actividades encontramos la unidad de trabajo, la cual debe ser realizada por aquella persona cuyo propósito general debe ser el crear un artefacto. Para realizar un proyecto debemos tomar en cuenta el tiempo que la actividad debe ser ejecutada, pero debe demorarse tan solo horas o días.
Los artefactos son aquellos segmentos de información producidos o usadas por un proceso. En este punto enfocaremos la utilización y las formas.
Para la utilización tomamos por entrada a un artefacto, luego realizamos una actividad y finalmente a la salida de este proceso tenemos de nuevo al artefacto terminado.
Para las formas definimos un modelo, vemos cual es su elemento, adjuntamos todos los documentos, nos apoyamos de nuestro código fuente creado, el cual nos sirve solo a nosotros, más no al usuario final y posteriormente entregamos al cliente el ejecutable.
RUP nos ayuda a entregar un ejecutable mucho más pronto, ya que a diferencia de los modelos anteriores afronta primordialmente aquellas tareas riesgosas y las hace más pequeñas. También podemos mejorar la calidad, ya que se pueden estar realizando pruebas continuamente. La principal ventaja por la que yo aplicaría este proceso para un desarrollo, es que permite una mejor comunicación entre un ingeniero de software y de negocios, ya que maneja un lenguaje común.
Como vimos anteriormente en RUP parte 1, tan solo se lo puede aplicar en proyectos grandes más no en los simples o pequeños.
Si queremos desarrollar en RUP primero debemos conocer acerca de UML, lo que representa una desventaja un tanto complicada pero a la vez nos ayuda a instruirnos y prepararnos más como profesionales.
Openup
El siguiente tema tratado en clase es OpenUP, que se aplica en enfoques tanto iterativo como incremental. Este proceso puede ser desarrollado para hacer frente a una extensa diversidad de tipos de proyectos.
Asimismo OpenUP mantiene las mismas características de RUP, que contiene el desarrollo iterativo, casos de uso y escenarios de conducción de desarrollo, gestión de riesgos, y el enfoque centrado en la arquitectura.
Existe una forma más básica y fácil de manejar de OpenUP que es OpenUP / Basic, objetivos más pequeños y con sede equipos interesados en el desarrollo ágil e iterativo. Incluyo un link con esta información más adelante.
En una página web encontre que Open Unified Process (OpenUP) es una parte del Eclipse Process Framework (EPF), un proceso de código abierto desarrollado en el marco Eclipse de fuente abierta organización. Ofrece las mejores prácticas de una variedad de desarrollo de software líderes de pensamiento y de la más amplia comunidad de desarrollo de software que cubren un conjunto diverso de perspectivas y necesidades de desarrollo.
LINKS
http://www.epfwiki.net/wikis/openupsp/openup_basic/customcategories/introduction_to_openup_basic,_BTJ_YMXwEduywMSzPTUUwA.html
este link habla específicamente de OPENUP BASIC en español.
http://www.eclipse.org/epf/
Este link nos lleva a la página principal de Eclipse Process Framework Project (EPF)
Proceso Unificado Rational RUP con Herramientas
Parte 1
El Proceso Unificado Rational es un proceso de desarrollo de software que se ha ido desarrollando con el tiempo, el mismo que se maneja conjuntamente con el Lenguaje Unificado de Modelado UML, y en la actualidad es la más manejada para el análisis, implementación y documentación de sistemas orientados a objetos.
RUP como vimos se desarrolla en unos principios básicos que como vimos se deben cumplir para que nuestro proyecto en desarrollo tenga éxito. Estos principios son: adaptar el proceso, balancear prioridades, demostrar valor iterativamente, elevar el nivel de abstracción y enfocarse en la calidad del producto.
Además se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Analizamos un diagrama con esta característica, el cual se divide en fases y cada una de estas en una serie de iteraciones. Aquellas iteraciones dan como consecuencia un incremento del producto desarrollado dentro del que se aumenta o se perfecciona todas las funcionalidades del sistema que se está desarrollando.
Vimos como en cada modelo de desarrollo se cumple un ciclo de vida también en RUP: Concepción, Elaboración, Construcción, Transición.
RUP es más cómoda para utilizarla en grandes proyectos ya que necesita un grupo de trabajo el cual tiene que ser apto para dirigir un proceso complicado en varias fases. Pero si aplicamos este modelo para pequeños proyectos, seguramente no es posible cubrir los costos para que nuestro equipo de trabajo cubra las expectativas.
En algunas páginas de Internet además encontré que la continua validación de RUP como proceso de desarrollo y sus innegables ventajas con respecto a otras metodologías de desarrollo han tenido como consecuencia de que muchos usuarios/clientes utilicen estos medios para construir sistemas que sean efectivos desde el punto de vista del costo y de trascendente aporte a la generación de valor de una empresa en el largo plazo. Si bien RUP corresponde a una metodología de trabajo intensiva en recursos, su aproximación al problema no sólo garantiza que los proyectos abordados serán ejecutados íntegramente sino que además evita desviaciones importantes respecto de los plazos y también permite una definición acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores.
La próxima clase analizaremos la segunda parte de este interesante modelo.
LINKS:
Ø http://www.willydev.net/descargas/articulos/general/cualxpfddrup.PDF
Este link da vista general de RUP. Además también enfoca y compara RUP, XP y FDD que también tienen pocas similitudes entre si, aunque XP y FDD poseen algunas más al ser ambos más ligeros.
Ø http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Hernandez.pdf
Este link es un trabajo de un doctorado, analiza RUP y su relación con las técnicas y métodos de la ingeniería de uso del software.
MODELOS DE PROCESO ITERATIVOS E INCREMENTALES
La principal característica de estos modelos es que permite crear cada vez versiones más completas de software, para esto construimos versiones sucesivas de un producto. Se crea una primera versión que es utilizada por el usuario donde se provee retroalimentación al desarrollador, y según los requerimientos especificados de éste usuario se crea una segunda versión.
Modelo Incremental.-
Como vimos este era un modelo tipo cascada el cual origina una primera versión con su respectiva funcionalidad, aplicamos de nuevo cascada sobre aquella versión 1 y obtenemos como resultado una versión 2 más una funcionalidad 2. Este proceso aplicamos cada vez que deseamos crear una versión más completa según los requerimientos de nuestro cliente.
El modelo incremental se aplica cuando en un proyecto tenemos un tiempo límite y no disponemos del personal suficiente para que nuestro propósito sea implementado completamente.
Además existen altos riesgos en este modelo pero se los puede reducir si tan solo construimos una parte del sistema y dejamos lo demás para complementarlo en versiones posteriores.
Modelo Iterativo.-
A diferencia del modelo incremental, al modelo iterativo no se le agrega funcionalidad si no que en cada iteración se mejora su funcionalidad.
Ventajas
Las ventajas que ofrece un desarrollo iterativo e incremental son varias y variadas, pero debe quedar claro que es muy difícil obtener todas juntas ya que depende del contexto en el que se implemente el proceso. En general las ventajas son:
- Resolución de problemas de alto riesgo en tiempos tempranos del proyecto.
- Visión de avance en el desarrollo desde las etapas iniciales del desarrollo.
- Obtención del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados.
- Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, según demuestran estudios realizados sobre proyectos que han aplicado esta técnica.
- Permite manejar la complejidad del proyecto, apuntando a la resolución de los problemas por partes, y no caer en la inanición del “súper análisis” del producto.
- El aprendizaje y experiencia del equipo iteración tras iteración, mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.
- El trabajo iterativo deja una experiencia en el equipo que permite ir ajustando y mejorando las planificaciones, logrando menores desvíos en la duración total del proyecto.
- Su adopción, con ciertos recaudos, no presenta grandes inversiones.
DESVENTAJAS
Hasta el momento se podría decir que no existen grandes desventajas, pero sí hay puntos a manejar con sumo cuidado:
- El uso de un desarrollo iterativo e incremental no garantiza por sí solo el éxito de su uso.
- Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento.
LINKS:
Ø http://www.is.ls.fi.upm.es/UDIS/docencia/proyecto/docs/curso/06CursoOO_DisenoEvolutivo.doc - (Este link da un ejemplo de desarrollo incremental e iterativo. Una forma de desarrollo evolutivo es el llamado desarrollo iterativo e incremental.)
Ø http://www.unibe.edu.do/tic/ingenieria.pdf (Este link se refiere al porque de los fracasos del desarrollo de software con un Proceso Dirigido por los Casos de Uso. Proceso Iterativo e Incremental. Proceso Iterativo e Incremental. Proceso Centrado en la Arquitectura)
LINKS
http://www.ati.es/novatica/2004/168/168-4.pdf
En este link encontraremos un lenguaje estándar para el modelado de software.
http://msdn2.microsoft.com/en-us/architecture/aa948857.aspx
Este link muestra una definición básica sobre SOA (Service Oriented Architecture), más algunos artículos publicados.
http://www-306.ibm.com/software/solutions/soa/
Aquí encontraremos una orientación de SOA pero tratado por IBM.
http://www.es-asp.net/tutoriales-asp-net/tutorial-215-217/utilizar-el-protocolo-soap-1-2.aspx
Aquí presento un link acerca de un tutorial de cómo utilizar el protocolo soap
DESARROLLO DE SOFTWARE BASADO EN COMPONENTES
Actualmente el desarrollo de software basado en componentes se ha transformado en el componente más seguro tanto para la construcción de grandiosos sistemas como para aplicaciones de software.
Entonces analizaremos principalmente aquellas propiedades de calidad referentes a los componentes software y a las aplicaciones que con ellos se construyen.
El Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Esta norma cuenta en la actualidad con una utilidad, tanto desde el panorama académico como desde el industrial, en donde su demanda de temas es cada día mayor.
La finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo de software y la importancia de sus componentes y servicios. También evaluar las diferencias entre este modelo y los estudiados anteriormente en el transcurso de desarrollar este tipo de software.
Además deberíamos conocer los fundamentos sobre los que se sienta el modelo y todas las tendencias al momento de armar el software, es decir en su arquitectura.
¿Y por qué el empleo de este modelo de desarrollo en el mundo del software?
Se dice que la progresiva necesidad de efectuar sistemas complejos en poco de tiempo, y con menor esfuerzo tanto del desarrollador como de la parte económica, está beneficiando el avance de lo que se conoce como Desarrollo de Software Basado en Componentes (DSBC).
Este nuevo método se sustenta en componentes software ya desarrollado, que son combinados apropiadamente para satisfacer las exigencias del sistema.
Los primordiales esfuerzos de la gente desarrolladora de software en estos temas se han basado hasta ahora en los aspectos prácticos de los componentes, es decir, en la funcionalidad que brindan. Sin embargo, por lo general se han venido previniendo muchos de los aspectos de calidad que intervienen a la hora de seleccionar componentes y ensamblarlos para construir aplicaciones que satisfagan los requisitos del cliente.
Estos aspectos “extra-funcionales”, cada vez absorbe la curiosidad de los arquitectos e ingenieros del software. Por un lado, los requisitos extra-funcionales pueden afectar a varias partes del sistema, y por ello tendrán prioridad si entran en conflicto con los requisitos funcionales. Asimismo, el cuidadoso análisis de las propiedades de calidad puede mejorar el proceso de diferencia de los componentes candidatos que cumplan el núcleo de requisitos funcionales. Por ejemplo, si dos componentes efectúan la misma funcionalidad, sus atributos extra-funcionales pueden ser el criterio definitivo en el proceso de selección.
COTS
La segunda tarea para este modelo de desarrollo se centraliza en los procesos y herramientas para la evaluación y selección de componentes COTS. Aparte de tener en cuenta las obligaciones funcionales de la aplicación, es necesario meditar otros factores que también se mezclan a la hora de seleccionar componentes. El problema es que este tipo de requisitos, denominados “extra-funcionales” son difíciles de apreciar, aunque todos somos conscientes de la importancia que representan.
Estos factores priman muchas veces incluso más que los funcionales, pues un diseñador hasta es capaz de adaptar la arquitectura de un sistema para poder incluir un componente que se desea que esté, o bien para evitar la presencia de un componente de un fabricante en el cual no se confía.
A pesar de estos problemas, los beneficios que proporciona el DSBC están ampliando su uso en ambientes industriales de desarrollo de software, sobre todo en cuanto a reducción de esfuerzos y costes de desarrollo y mantenimiento, y a la mejora de la calidad final de los productos y sistemas construidos. Esta extensión de su uso está favoreciendo la aparición de numerosas metodologías y herramientas de desarrollo para realizar un efectivo DSBC. Sin embargo, esta disciplina dista aún de ser una verdadera “ingeniería”, pues aún no se dispone ni de métricas adecuadas, ni de procesos precisos, ni de normativa internacional que la regule.
En este sentido, la definición de métricas de calidad para componentes y aplicaciones
Software, especialmente las desarrolladas en base a componentes COTS, aparece como una necesidad imperiosa.
EL MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la construcción de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.
Se caracteriza principalmente por:
Ø Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
Ø Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.
El modelo espiral captura algunos principios básicos:
· Decidir qué problema se quiere resolver antes de viajar a resolverlo.
· Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
· Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
· No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
· Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.
Funcionamiento del modelo Espiral
En cada vuelta tomamos en cuenta:
Ø Los Objetivos: Que necesidad debe envolver el programa.
Ø Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:
- Características: experiencia del personal, exigencias a efectuar.
- Formas de gestión del programa.
- Riesgo tomado con cada alternativa.
Ø Desarrollar y Verificar: Programar y probar el programa .
Ø Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:
- Angular=Avance del proyecto Software, dentro de un ciclo.
- Radial=Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.
Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.
Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.
El modelo en espiral WINWIN
El modelo en espiral WINWIN de Boehm, define un conjunto de acciones de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:
- Identificación del sistema o subsistemas clave de los directivos.
- Determinación de las condiciones de victoria de los directivos.
- Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.
LINKS
A Spiral Model of Software Development and Enhancement - Barry Boehm's original article
http://www.itba.edu.ar/capis/rtis/articulosdeloscuadernosetapaprevia/CORCOS-ESPIRAL.pdf - Similitudes y Diferencias entre el Modelo Espiral y el Prototipado
MODELO DE PROTOTIPOS
Este modelo también denominado modelo de desarrollo evolutivo. Para comprender este modelo, comenzaremos con la definición de los objetivos globales para el software, después identificaremos los requerimientos que conocemos y los sitios del diseño en donde es necesaria más definición. Entonces planteamos con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).
Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software.
El diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteració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.
CONSTRUCCION DE PROTOTIPOS
A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humana – máquina, entonces en este caso cuando utilizamos la construcción de prototipos.
El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final. El diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo evalúa el usuario y con la retroalimentación se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.
VENTAJAS:
Ø No modifica el flujo del ciclo de vida.
Ø Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
Ø Reduce costos y aumenta la probabilidad de éxito.
Ø Exige disponer de las herramientas adecuadas.
Ø No presenta calidad ni robustez.
Ø Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
DESVENTAJAS
A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de prototipos se torna problemática por las siguientes razones:
Ø El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “chicle y cable para embalaje”, y puede decepcionarse al indicarle que el sistema aun no ha sido construido.
Ø El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta los obligaciones de calidad y de mantenimiento que tiene con el cliente.
LINKS:
http://prototipos/Ingenieria%20de%20software%20-%20Monografias_com.htm
http://prototipos/Microsoft%20PowerPoint%20-%20Tema03.htm
MODELOS DE PROCESO PRESCRIPTIVO
Introducción.- Se analizó un informe según Presuman que se basa en un triángulo multicapa, en el que se destaca: la calidad, los procesos, los métodos y técnicas, las herramientas.
El Proceso de Software se basa en las personas, en el producto, en el proyecto y finalmente en el proceso.
Debemos diferenciar entre el concepto de proyecto y proceso, el primero es una secuencia de acciones para llevar a cabo el desarrollo del software, mientras que el otro indica su proceso de desarrollo.
Proceso del Software.- Se observó una visión genérica acerca de dicho proceso, el cual consiste en:
DEFINICIÓN: Ing. Sistema
Planificación
Análisis de Req.
DESARROLLO: Diseño
Generación de Código
Pruebas
MANTENIMIENTO Y SOPORTES
MODELO CASCADA
Llamado también Lineal secuencial. Proporciona una simple visión del desarrollo del Software. A los procesos los representa como fases separadas y secuenciales en tiempo.
Antes de codificar debemos diseñar el software, además probarlo antes de construirlo y ponerlo en operación.
FASES DEL MODELO CASCADA
Ingeniería y Análisis del Sistema |
Análisis de los Requisitos |
· Ingeniería y Análisis del Sistema:
Análisis y de diseño de todos los componentes del sistema computacional.
· Análisis de Requisitos Software:
Se debe conocer que necesita el usuario para saber que necesidades debemos cubrir.
· Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Se dividen en:
- Diseño de Alto Nivel o Arquitectónico
- Diseño Detallado
· Codificación: Es la fase de programación propiamente dicha.
- Pruebas: Las componentes una vez programadas, se ensamblan para formar el sistema y se demuestra que trabaja correctamente antes de ser puesto en práctica por el usuario.
Existen varios tipos de Pruebas:
Ø Pruebas de unidad
Ø Pruebas de integración
Ø Pruebas de sistema.
Ø Pruebas de aceptación
- Mantenimiento: El software necesitará cambios después de la entrega. Los tipos de mantenimiento son:
Ø Mantenimiento Preventivo y Perfectivo
Ø Mantenimiento Correctivo
Ø Mantenimiento Evolutivo
VENTAJAS DEL MODELO CASCADA
1. Modelo y planificación fácil y sencillos.
2. Sus fases son conocidas por los desarrolladores.
3. Los usuarios lo pueden comprender fácilmente.
DESVENTAJAS DEL MODELO CASCADA
1. Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.
2. Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.
Documentos del Modelo de Cascada
http://www.biblioteca.co.cr/pdf/unidad12-4.pdf
MODELO V
Se puede definir un software de mejor calidad ya que es un modelo mas evolucionado que Cascada.
Este Modelo más manejable, pero sigue teniendo con algunas carencias del Modelo Cascada.
Permite combinar los tipos de pruebas con actividades de verificación y validación sobre los documentos de requisitos y diseño que optimizan la capacidad de aceptar el producto resultante.
Ø La verificación se fundamenta en demostrar si el producto se está construyendo correctamente.
Ø La validación certifica que el producto cumple con las exigencias definidas por el cliente.
