INFORME

DEFINICIÓN DE MODELOS DE PROCESO DE SOFTWARE

Un modelo de procesos del software es una descripción simplificada de un proceso

del software que presenta una visión de ese proceso. Estos modelos pueden incluir

actividades que son parte de los procesos y productos de software y el papel de las

personas involucradas en la ingeniería del software. Algunos ejemplos de estos tipos de

modelos que se pueden producir son:

1. Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso

junto con sus entradas, salidas y dependencias. Las actividades en este modelo

representan acciones humanas.

2. Un modelo de flujo de datos o de actividad. Representa el proceso como un

conjunto de actividades, cada una de las cuales realiza alguna transformación en los

datos. Muestra cómo la entrada en el proceso, tal como una especificación, se transforma

en una salida, tal como un diseño. Pueden representar transformaciones llevadas a

cabo por las personas o por las computadoras.

3. Un modelo de rol/acción. Representa los roles de las personas involucrada en el

proceso del software y las actividades de las que son responsables.

La mayor parte de los modelos de procesos del software se basan en uno de los tres

modelos generales o paradigmas de desarrollo de software:

1. El enfoque en cascada. Considera las actividades anteriores y las representa como

fases de procesos separados, tales como la especificación de requerimientos, el

diseño del software, la implementación, las pruebas, etcétera. Después de que cada

etapa queda

definida «se firma» y el desarrollo continúa con la siguiente etapa.

define las siguientes etapas que deben cumplirse de forma sucesiva:

1. especificación de requisitos
2. diseño del software
3. construcción o implementan del software
4. integración
5. pruebas o validación
6. despliegue o instalación
7. mantenimiento

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

2. Desarrollo iterativo. Este enfoque entrelaza las actividades de especificación, desarrollo

y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones muy

abstractas. Este se refina basándose en las peticiones del cliente

para producir un sistema que satisfaga las necesidades de dicho cliente. El sistema puede

entonces ser entregado. De forma alternativa, se puede re implementar utilizando un

enfoque más estructurado para producir un sistema más sólido y mantenible.

3. Ingeniería del software basada en componentes (CBSE). Esta técnica supone que

las partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la

integración de estas partes más que desarrollarlas desde el principio.

DESCRIPCIÓN DE AL MENOS 3 MODELOS DEL TIPO SECUENCIAL

Para construir sistemas lógicos secuenciales (SLS) de la forma más mecánica posible hace

Existen diversos métodos. Los más sencillos son el modelo de Moore y el modelo de

Mealy, que describen el comportamiento del sistema por medio de grafos basados en la

noción de estado

MODELO MOORE

El modelo de Moore impone una limitación: La salida depende únicamente del estado y NO

de la entrada.

Por tanto, la ecuación de salida Y se nos reduce y nos quedan las expresiones:

Yt = H(Et) ecuación de salida

Et+1 = G(Xt, Et) ecuación de transición de estados

Vamos a realizar el ejercicio contrario, es decir, partiendo del circuito obtener el grafo

asociado.

En este caso también hay que tener en cuenta la limitación de Moore: las salidas no

pueden depender de las entradas sino del estado en que nos encontremos.

En el caso de encontrar un circuito en el que las salidas dependan de las entradas através de alguna puerta, el modelo de Moore no servirá para su análisis.

MODELO MEALY

Las salidas están en función de dos, el estado presente y las entradas.

DESCRIPCIÓN DE  AL MENOS 3 MODELOS DEL TIPO EVOLUTIVO

Un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.

En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

1.    El modelo en cascada.

 Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

2.    Desarrollo evolutivo

. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

3.    Ingeniería del software basada en componentes.

 Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos componentes en el sistema más que en desarrollarlos desde cero.

Aunque existen muchos tipos de modelos de desarrollo, de forma genérica la mayoría está clasificada en una de estas 3 categorías, y estos a pesar de ser diferentes a veces son usados de manera simultáneamente especialmente en sistemas grandes. 

Desarrollo Evolutivo

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Existen dos tipos de desarrollo evolutivo:

1.    Desarrollo exploratorio,

donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2.    Prototipos desechables

donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:

1.    El proceso no es visible.

 Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema.

2.    A menudo los sistemas tienen una estructura deficiente. 

Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

DESCRIPCIÓN DE AL MENOS 3 MODELOS DE TIPO ÁGIL

1. Crystal Clear

Crystal es una metodología de desarrollo de Software ágil, más que una metodología se la considera una familia de metodologías, debido a que se subdivide en varios tipos de metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Es una metodología que ha sido creada por una persona en particular (Alistair Cockburn ) el cuál llegó la creó en base al análisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cual fusionando ambos aspectos dio lugar a una metodología bastante interesante, la cual se presenta a continuación.

Crystal Clear no es una metodología en sí misma sino una familia de metodologías con un “código genético” común.

El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza).

Por ejemplo.

• Clear es para equipos de hasta 8 personas o menos.
• Amarillo para equipos entre 10 a 20 personas.
• Naranja para equipos entre 20 a 50 persona.
• Roja  para equipos entre 50 a 100 personas.
• Azul para equipos entre 100 a 200 personas.

CC puede ser usado en proyectos pequeños y como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.

En primera instancia se especifican los antecedentes de la metodología, continuando con definiciones que ayudan a estructurar la fundamentación teórica y se termina con las características esenciales de los diferentes tipos de Crystal.

2. Metodología FDD

Metodología FDD (Feature Driven Development). Es una metodología ágil para el desarrollo de sistemas, basado en la calidad del software, que incluye un monitoreo constante del proyecto.

FDD fue desarrollado por Jeff De Luca y Peter Coad a mediados de los años 90. Esta metodología se enfoca en iteraciones cortas que permite entregas tangibles del producto en corto periodo de tiempo que como máximo son de dos semanas.

Contenido:

1 Características

2 Procesos

3 Roles y responabilidades

4 Comparación

5 Fuentes

Características

No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción.

Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado.

Propone tener etapas de cierre cada dos semanas.

Se obtienen resultados periódicos y tangibles.

Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar.

Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.

Procesos

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

Desarrollar un modelo global: Al inicio del desarrollo se construye un modelo teniendo en cuenta la visión, el contesto y los requisitos que debe tener el sistema a construir. Este modelo se divide en áreas que se analizan detalladamente. Se construye un diagrama de clases por cada área.

Construir una lista de los rasgos: Se elabora una lista que resuma las funcionalidades que debe tener el sistema, cuya lista es evaluada por el cliente. Cada funcionalidad de la lista se divide en funcionalidades más pequeñas para un mejor entendimiento del sistema.

Planear por rasgo: Se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes.

Diseñar por rasgo: Se selecciona un conjunto de funcionalidades de la lista. Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo, decidiendo que funcionalidad se van a realizar en cada iteración. Este proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.

3. METODOLOGÍA EXTREME PROGRAMMING (XP)

La programación extrema es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.

Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación.

Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software.

 El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.

CARACTERÍSTICAS FUNDAMENTALES

Las características fundamentales del método son:

• Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
• Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
• Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
• Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
• Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
• Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
• Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

ACTIVIDADES DE XP

• Codificar

Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.

• Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.

• Escuchar

En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?".

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

• Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.