2. MODELOS DE PROCESO PRESCRIPTIVO
Un proceso primero que todo define quien hace que, cuando y como lo hace, para alcanzar objetivos. El éxito de las empresas u organizaciones depende en gran medida de la definición y seguimiento adecuado de sus procesos. Por ejemplo, si definimos realmente que es un proceso podemos decir que una empresa dedicada al desarrollo de software abarca procesos especializados muy complejos que es la creación y administración del sistema de software. Un modelo de proceso debe considerar una variedad de aspectos, como el conjunto de personas, estructuras organizacionales, reglas, políticas, actividades, componentes de software, metodologías y herramientas utilizadas. Hay muchos aspectos que definen un proceso, desde su arquitectura, actividades, ac tividades, métodos y metodologías, estrategias y herramientas para la administración de software. Cada aspecto para no alargar cada definición lleva al equipo de desarrollo a manejar varios tipos de estos aspectos para el desarrollo de software. desde su estructura que es el inició para la creación del software hasta las herramientas utilizadas fundamental para el ciclo de desarrollo. Ahora bien, ya tenemos un concepto de proceso, lo que nos lleva a profundizar que hace o que es un MODELO PRESCRIPTIVO, estos modelos fueron propuestos originalmente para poner orden en el desarrollo de un sistema o software. Lo que nos indica que antiguamente an tiguamente un equipo desarrollador presentaba mucho caos a la hora de definir su proceso de desarrollo. El modelo prescriptivo logra que su proceso vaya bien, pero no por eso mismo sus resultados se cuidaran de sí mismos, el proceso prescriptivo hay que alimentarlo, porque, aunque este modelo logra orden en sus desarrollos por algún motivo o circunstancias el producto que generan siguen al borde del d el caos, su estructura de ingeniería que es útil para el equipo desarrollador y que da resultados eficaces, no deja de ser perfecto. Todos los modelos del proceso del software pueden incluir las actividades estructurales generales, pero cada una pone distinto estudio en ellas y define en forma diferente acciones y tareas de ingeniería de software.
1. MODELO DE CASCADA:
Se le conoce como ciclo básico del software, se usan cuando los problemas que le plantean son fáciles de entender por lo cual son fácil de solucionar. Describe el orden de las actividades del modelo, es una secuencia de actividades, en sus inicios este modelo se orientaba a este proceso que se encaminaba por seguir el progreso de desarrollo de software hacia puntos de definición bien definidos, a esto se le conoce como checkpoint.
Este modelo original se caracterizaba por no continuar su proceso sin antes terminar cada actividad en su punto partidario. El modelo se especificaba en terminar la actividad que empezaba. Algunas de las creencias del modelo de cascada son que las metas se logran mejor cuando se tienen puntos de revisión bien preestablecidos y documentados (dividiendo el desarrollo del software en actividades secuenciales bien definidas), los documentos técnicos son comprensibles para usuarios y administradores no técnicos, cada detalle de los requisitos se conoce de antemano antes de desarrollar el software (Dichos detalles son estables durante el desarrollo) y las pruebas y evaluaciones se realizan de manera eficiente al final del desarrollo. El modelo de cascada fue inicialmente bien recibido, dado que las actividades de las etapas eran razonables y lógicas. Lamentablemente, el modelo no explicaba cómo modificar un resultado, en especial considerando lo difícil que es definir todos los requisitos de un sistema desde el inicio y que éstos se mantengan estables y sin cambios durante el desarrollo. Además, toma demasiado tiempo en obtener resultados, retrasando la detección de errores hasta el final. Esa clase de modelo se utiliza más que todo para mantenimiento, y para desarrollo nuevo que son fácil de comprender. Cuando los requerimientos se comprenden bien este tipo de modelo enfoca el trabajo desde la comunicación hasta el despliegue en forma lineal. El modelo de cascada también conocido como Ciclo de vida Clásico, sugiere un enfoque sistemático que es el conjunto ordenado de normas y procedimientos y secuencial Orden de una serie de elementos que se suceden unos a otros. Este método de cascada se representa en 5 etapas.
1.1.
Comunicación:
Se hace un listado con el cliente de las necesidades que debe suplir el software de lo que el cliente necesita, se reúnen, se recoge los requerimientos con el cliente. 1.2.
Planeación:
Define y estima como objetivo principal la programación y constante seguimiento del software a plantear. Se define en tres etapas:
1.2.1. La estimación: Habla del recurso humano a nivel tecnológico y costos a definir para la planeación del software. 1.2.2. La programación: Es realizar el debido cronograma del desarrollo en cuanto a la programación. 1.2.3. Los seguimientos: Son los ajustes que uno debe hacerle a la aplicación, un cronograma se hace para tener un indicativo que varía en el transcurso del desarrollo donde se hace más notable realizar estas modificaciones.
1.3.
Modelado:
Se realiza el Análisis con los parámetros establecidos y el diseño incremental del software. 1.4.
La construcción:
En este nivel se realiza la entrada de códigos por parte del desarrollador y se realizan pruebas pilotos de lo que se está realizando o simplemente se aplican las pruebas técnicas requeridas, hay 28 clases de pruebas, dependiendo del software se escoge las clases de pruebas. 1.5.
Despliegue:
Lleva 3 cosas: 1.5.1. La entrega: Es el software o la aplicación que le mandaron a hacer. 1.5.2. Asistencia: Es el tiempo de apoyo limitado (La póliza-cumplimiento). 1.5.3. Retroalimentación: Es el mantenimiento que uno debe hacerle a la aplicación. Desventajas Modelo Cascada
Este modelo tiene unas desventajas, una de ellas es que lleva muchas restricciones y es sujeta a cambios relevantes, ejemplo: El cambio de la actualización, toca hacerle camb ios al software. Por x cosas el IVA sube del 16 al 19 hay que cambiar muchas situaciones. Otra desventaja es que el cliente no dice que es lo que quiere, no queda bien enunciado el problema y para el equipo desarrollador le es complicado conocer realmente como es el software requerido. Una desventaja grande cuando en el equipo hay participantes que no aportan, el software no se va a cumplir, el analista o gerente debe escoger bien su equipo de trabajo.
Modelo en V:
Una variante de la representación del modelo de la cascada se denomina modelo en V. Donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. Con este modelo como variante del modelo clásico de cascada ayuda a que los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución. Ventaja se asegura la calidad, este modelo es bueno, cuando se hace la lista de
requerimientos, se analiza de una vez se hacen pruebas, si hace falta algo, se actúa hasta solucionar sino no continúa con la siguiente fase. La generación de código, se hacen pruebas unitarias por último es software ejecutable, entregable como tal.
2. Modelo de proceso incremental:
Consiste de un desarrollo inicial de la arquitectura completa del sistema, seguida de incrementos y versiones parciales de éste. Cada incremento tiene su propio ciclo de vida, típicamente siguiendo el modelo de cascada. Los incrementos pueden construirse de manera serial o paralela dependiendo de la naturaleza de la dependencia entre versiones y recursos. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema. Conforme se completa cada etapa, se verifica e integra la última versión con las demás versiones ya completadas del sistema. Durante cada incremento, el sistema se evalúa con respecto al desarrollo de versiones futuras. Las actividades se dividen en procesos y subprocesos, dando lugar al término fábrica de software (en inglés, software factory). Para que la secuencia de desarrollo sea exitosa, es esencial definir etapas que no requieran cambiar los resultados anteriores al agregar nuevas. Por lo tanto, es importante comprender al inicio los requisitos completos del sistema, algo que normalmente es muy difícil de lograr. El desarrollo incremental evita la teoría del “big bang” para el desarrollo de
software, donde una gran explosión de desarrollo se transforma repentinamente en el sistema final. Ventaja: El modelo incremental aplica secuencias lineales en forma escalonada a medida
que avanza el calendario de actividades se van haciendo entregas funcionales por pedazos, al cliente o al usuario que lo va a manejar, esas pruebas funcionales no son 100% optimas, se hacen entregas posteriores.
3.
Modelos de proceso evolutivo
Se extiende al modelo incremental en la que los incrementos se hacen de manera secuencial o sea por partes, en lugar de en paralelo. Desde el punto de vista del cliente, el sistema evoluciona según vayan siendo entregados los incrementos. Desde el punto de vista del desarrollador, los requerimientos que son claros al principio del proyecto dictan el incremento inicial, mientras que los incrementos para cada uno de los siguientes ciclos de desarrollo se clarifican a través de la experiencia de los incrementos anteriores. Este modelo se define en dos modelos internos que son: 3.1. Prototipos:
El modelo evolutivo es también conocido como desarrollo rápido de aplicaciones, que se basa tradicionalmente en el uso de prototipos, Un prototipo de software se considera como un medio para especificar los requisitos y un enlace de comunicación entre el usuario final y el diseñador, ayudando a reducir el riesgo de carecer de requerimientos iniciales completos y estables.
DESVENTAJA: El software s e
hace caprichosamente por el desarrollador, cada ser humano piensa diferente, a raíz de eso se hace caprichosamente, cada uno desarrolla a su manera. En las reglas de juego hay que entregar un prototipo, al entregarlo no se mira que h ardware tiene, cosas que si no hay requerimientos claros el desarrollador hace un prototipo a su beneficencia.
3.2. Modelo Espiral: Se hacen versiones rápidas, el modelo espiral se basa en una estrategia para reducir el riesgo del proyecto en áreas de incertidumbre, como tener requerimientos iniciales incompletos e inestables. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identificación de los objetivos, soluciones alternas y restricciones asociadas con cada alternativa, y finalmente se procede a su evaluación. Cuando se encuentra que existe cierta incertidumbre, se utilizan diversas técnicas para reducir el riesgo de las distintas alternativas. Cada ciclo del modelo espiral termina con una revisión que discute los logros actuales y los planes para el siguiente ciclo VENTAJAS:
Una de las grandes ventajas que tiene contra otros modelos es que acá se mira el riesgo, y el riesgo se mira a nivel de fracaso. Se plantea la modulación, el despliegue, comunicación, mismas etapas trabajan ahí. Otra ventaja grande es que incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Este modelo considera que el desarrollo de sistemas es un proceso de cambios progresivos mediante cambios de especificación de requerimientos
4. Modelo Concurrente. Este modelo se ajusta al ciclo de vida del proceso, donde apoya las diferentes actividades, donde Involucra varios equipos de trabajo para el desarrollo de un software y se le conoce como modelo de tipo de red donde las personas actúan simultáneamente y se utiliza para desarrollos cliente – servidor. “el cliente realiza peticiones de programas y el servidor da respuesta a estos requerimientos” CARACTERISTICAS:
Se puede expresar de manera esquematizada Las actividades llevan procesos simultáneos. Es aplicable a todo tipo de desarrollo de software
Es un modelo aplicable para cliente – servidor Está dirigido por las necesidades del usuario.
VENTAJAS:
Excelentes para proyectos en los que se conforman grupos de trabajo independiente. Proporciona la imagen exacta del estado actual de un producto. Si no se dan las condiciones adecuadas o señaladas no es aplicable. Si no existen grupos de trabajo no se puede trabajar en este método.
5. Modelo de proceso Especializado Este modelo cobija todas las características de los modelos básicos de la programación, reúne mismas funcionalidades de los modelos anteriores, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniería de software especializado o definido muy específicamente 5.1. Desarrollo Basado en Componentes:
Los componentes comerciales de software general desarrollados por vendedores que los ofrecen como productos, brindan una funcionalidad que se persigue con interfaces bien definidas que permiten que el componente se integre en el software que se va a construir. VENTAJAS
Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados. 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. 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.
El modelo de desarrollo basado en componentes incorpora las etapas siguientes:
Se investigan y evalúan, para el tipo de aplicación de que se trate, productos disponibles basados en componentes. Se consideran los aspectos de integración de los componentes.
Se diseña una arquitectura del software para que reciba los componentes. Se integran los componentes en la arquitectura. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.
6. Modelo de métodos formales Este modelo se relaciona con las representaciones matemáticas de computo, como su nombre lo indica este modelo denominado métodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemáticas del software, incluyendo la especificación formal de sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la verificación de programas. Todas estas actividades dependen de una especificación formal del software. El modelo de métodos formales agrupa actividades que llevan a la especificación matemática formal del software de cómputo. Los métodos formales permiten especificar, desarrollar y verificar un sistema basado en computadora por medio del empleo de una notación matemática rigurosa. VENTAJAS
La comunicación con el cliente mejora ya que se dispone de una descripción clara y concisa de los requisitos del usuario. El sistema se asegura matemáticamente que es correcto según las especificaciones. Mayor calidad software respecto al cumplimiento de las especificaciones. Mayor productividad
7. Desarrollo a software orientado a objetos Define un mecanismo que ayuda a resolver problemas complementarios de código disperso o scattered y código enmarañado o tangled, estos dos códigos los podemos definir como servicios invocados desde el programa y servicios de acceso desde la operación del programa. Provee una unidad modular llamada aspecto y un mecanismo de composición que permite entremezclar unidades modulares de comportamiento común con otras unidades modulares básicas del sistema. Diseñar un sistema basado en aspectos requiere entender qué se debe incluir en el lenguaje base, qué se debe incluir dentro de los lenguajes de aspectos y qué debe compartirse entre ambos lenguajes. El lenguaje componente debe proveer la forma de implementar la funcionalidad básica y asegurar que los programas escritos en ese lenguaje componente no interfieran con los aspectos.
BIBLIOGRAFIA.
Pressman, R. 2010. Ingeniería del Software un enfoque Práctico, 7ma. ed. México:Mc Graw. Serna, E. 2010. Métodos formales e Ingeniería de Software. “Revista Virtual Universidad Católica del Norte”. No. 30. Yépez, S. 2010. Modelo de Orientación a Aspectos. En Linea. Formato PDF.
Conclusiones Los modelos hacen una mejor funcionalidad de integración del software. Además podemos decir que esto se inclina más a que la arquitectura del software se acople más a los componentes.
Que es el modelo, que etapas tiene, donde se implementa, complementar con otros autores. Un trabajo con normas para entregar, hacer un folleto Plegable hacer un Folleto “Que es: ventajas y las fases que tiene.
En la clase de hoy a las 7:00pm, explicaré sobre modelos, 1. Elaborar un trabajo con investigación más profunda sobre cada modelo, del libro de Roger Pressman, numeral 2.3 y 2.4 con NORMAS ICONTEC (en físico) 2. Se debe diseñar una PLEGABLE explicando qué es, fases que tiene y ventajas solamente de cada modelo (en físico) 3. ENTREGA MÄXIMA: viernes Marzo 02 de 2018 hora de inicio de la clase 4. Se realizará ese mismo día, un QUIZ sobre los modelos
