CICLOS DE VIDA DEL SOFTWARE

CICLOS DE VIDA  DEL SOFTWARE

Definición de Proceso:

Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por:

·                     Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador.

·                     Su estado de ejecución en un momento dado, esto es, los valores de los registros de la CPU para dicho programa.

·                     Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos.

·                     Otra información que permite al sistema operativo su planificación.

Esta definición varía ligeramente en el caso de sistemas operativos multihilo, donde un proceso consta de uno o más hilos, la memoria de trabajo (compartida por todos los hilos) y la información de planificación. Cada hilo consta de instrucciones y estado de ejecución.
Los procesos son creados y destruidos por el sistema operativo, así como también este se debe hacer cargo de la comunicación entre procesos, pero lo hace a petición de otros procesos. El mecanismo por el cual un proceso crea otro proceso se denomina bifurcación (fork). Los nuevos procesos son independientes y no comparten memoria (es decir, información) con el proceso que los ha creado.
En los sistemas operativos multihilo es posible crear tanto hilos como procesos. La diferencia estriba en que un proceso solamente puede crear hilos para sí mismo y en que dichos hilos comparten toda la memoria reservada para el proceso.
Ciclo de vida de un proyecto de Software:
Se entiende por ciclo de vida de un proyecto software a todas las etapas por las que pasa un proyecto, desde la concepción de la idea que hace surgir la necesidad de diseñar un sistema software, pasando por el análisis, desarrollo, implantación y mantenimiento del mismo y hasta que finalmente muere por ser sustituido por otro sistema.
Aunque UML es bastante independiente del proceso, para obtener el máximo rendimiento de UML se debería considerar un proceso que fuese:
Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto básico para establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.
Centrado en la arquitectura de modo que sea el artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema.
Un proceso iterativo, que es aquel que involucra la gestión del flujo de ejecutables del sistema, e incremental, que es aquel donde cada nueva versión corrige defectos de la anterior e incorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por el riesgo, lo que significa que cada nueva versión se ataca y reducen los riesgos más significativos para el éxito del proyecto.
Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental pude descomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos importantes del proceso, cuando se cumplen los objetivos bien definidos, se completan los artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciación, que es cuando la idea inicial está lo suficientemente fundada para poder garantizar la entrada en la fase de elaboración, esta fase es cuando se produce la definición de la arquitectura y la visión del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre el mismo.
Posteriormente se pasa a la fase de construcción, que es cuando se pasa de la base arquitectónica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La transición, cuarta fase del proceso, que es cuando el software se pone en mano de los usuarios. Raramente el proceso del software termina en la etapa de transición, incluso durante esta fase el proyecto es continuamente reexaminado y mejorado erradicando errores y añadiendo nuevas funcionalidades no contempladas.
Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteración, que es un conjunto bien definido de actividades, con un plan y unos criterios de evaluación, que acaban en una versión del producto, bien interna o externa.
Ciclo de Vida:
Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases empleadas se le denomina “ciclo de vida”.
Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologías empleadas.
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí sean lo más simples posibles.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).
De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.
 
Elementos de un Ciclo de Vida:
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).
Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.
A continuación presentamos los distintos elementos que integran un ciclo de vida:

·                     Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).

Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases.
 

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.

·                     Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.
 

Tipos de Modelos de un Ciclo de Vida:
Las principales diferencias entre distintos modelos de ciclo de vida están en:

o        El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.

o        Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avión que un puente), o de la organización (interés de reflejar en la división en fases aspectos de la división interna o externa del trabajo).

o        La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral. Veámoslo con más detalle:

Ciclo de Vida Lineal:
Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para decisiones de planificación), requiere también que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
Ciclo de vida con Prototipado:
A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado.
Ciclo de Vida en Espiral:
El ciclo de vida en espiral puede considerarse como una generalización del anterior para los casos en que no basta con una sola evaluación de un prototipo para asegurar la desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede así considerarse como una sucesión de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente.
A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
Modelos de Procesos de Software:
Al día de hoy, ha aumentado la complejidad con la que se desarrollan sistemas de información para la industria, por lo que resulta difícil generar productos que cumplan cabalmente con las expectativas del cliente.
Para responder a esta situación, han surgido una serie de herramientas, técnicas y modelos que facilitan a las organizaciones, encargadas de las tecnologías de la información, generar productos que cumplan las expectativas del cliente e incluso las rebasen, herramientas que prometen ser la solución a los problemas de calidad, costo y tiempos de desarrollo; de éstas podemos mencionar a los “modelos de calidad” como la norma ISO 9000-2000, la ISO/IEC TR 15504 y el modelo CMM (Capability Maturity Model del Software Engineerig Institute SEI).
Aunque en el pasado se reconocía la necesidad de crear software de calidad, no se había hecho un esfuerzo serio para que nuestra industria generara productos que nos dieran la oportunidad de competir en el mercado internacional, con calidad equiparable o superior a la de países como la India o Irlanda. Afortunadamente, dicha situación ha cambiado; nuestro gobierno en conjunto con la industria, ha iniciado un esfuerzo serio para impulsar la industria del software a través del Programa para el Desarrollo de la Industria del Software (PROSOFT).
PROSOFT reconoce el estado incipiente de la industria mexicana de software, así como la necesidad de invertir cantidades crecientes de recursos en capital de tecnologías de información con objeto de contribuir de manera sostenible al crecimiento de la economía y la generación de empleos bien remunerados.
Con el programa, se pretende establecer una industria de software competitiva internacionalmente y asegurar su crecimiento a largo plazo, lo que situaría a México como líder de esta industria en Latinoamérica en 2012, además de convertirlo en líder desarrollador de soluciones de tecnologías de información de alta calidad y uso de software en Latinoamérica.

1.             Este programa tiene siete estrategias de donde emergen varios proyectos que ayudarán a que se alcancen las metas previstas en éste:

2.             Promover las exportaciones y la atracción de inversiones.

3.             Educar y formar personal competente en el desarrollo de software, en cantidad y calidad convenientes.

4.             Contar con un marco legal promotor de la industria.

5.             Desarrollar el mercado interno.

6.             Fortalecer a la industria local.

7.             Alcanzar niveles internacionales en capacidad de procesos.

8.             Promover acciones conjuntas con los gobiernos estatales y construir infraestructura.

Para el caso de la estrategia 6, la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS), con el auspicio de la Secretaría de Economía propone un modelo concebido, diseñado y desarrollado por mentes mexicanas, adecuado para las necesidades específicas de México y con ventajas respecto de otros. El nuevo modelo, denominado MoProSoft, ofrece características que los otros no tienen de manera independiente; para su concepción, se tomaron las mejores prácticas de los otros modelos y se integraron y mejoraron otras; a continuación, mencionamos a qué se refiere cada modelo y algunas de sus ventajas y desventajas.

Norma ISO 9000-2000

Es una norma internacional destinada a evaluar la capacidad de la organización para cumplir los requisitos del cliente, los reglamentarios y los propios de la organización.

Ventajas

·                     Tiene un mecanismo de certificación bien establecido.

·                     Está disponible y es conocida.

Desventajas

·                     No es específica para la industria de software.

·                     No es fácil de entender.

·                     No está definida como un conjunto de procesos.

·                     No es fácil de aplicar.

Capability Maturity Model (CMM)

Es un marco evolutivo organizado en cinco niveles para lograr la mejora continua de procesos.

Ventajas

·                     Específico para el desarrollo y mantenimiento de software.

·                     Definido como un conjunto de áreas clave de procesos.

·                     Tiene un modelo de evaluación.

·                     Desde 1998 empezó a popularizarse en México.

·                     Existen organizaciones evaluadas.

Desventajas

·                     Es un modelo extranjero, no internacional.

·                     No es fácil de entender (inglés, 18 KPAs, 220 páginas).

·                     No es fácil de aplicar (pensado para organizaciones grandes).

·                     La mejora no está enfocada directamente a los objetivos de negocio.

·                     La evaluación es costosa y no tiene periodo de vigencia.

·                     Se está abandonando a favor de CMM-I (el SEI dejará de dar soporte a partir del 2005).

ISO/IEC TR 15504

Define el modelo de referencia de procesos de software y de capacidades de procesos que constituyen la base para la evaluación de procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son normativas y las demás informativas.

Ventajas

·                     Específico para el desarrollo y mantenimiento de software.

·                     Fácil de entender (24 procesos, 16 páginas).

·                     Definido como un conjunto de procesos.

·                     Orientado a mejorar los procesos para contribuir a los objetivos del negocio.

Desventajas

·                     No es práctico ni fácil de aplicar.

·                     Tiene solamente lineamientos para un mecanismo de evaluación.

·                     Todavía no es norma internacional.

MoProSoft

Es un Modelo de Procesos para la Industria de Software que fomenta la estandarización de su operación, a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad.

Ventajas

·                     Fácil de entender.

·                     Fácil de aplicar.

·                     No es costoso en su adopción.

·                     Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 [1] o CMM.1 V1.1[2].

A decir de sus creadores, el modelo está orientado a pequeñas y medianas empresas, hecho favorable si se considera que aproximadamente el 80% de las empresas desarrolladoras de software del país caen en esta categoría. Su principal fortaleza es que integra varias de las prácticas propuestas por los otros modelos y corrige algunas de sus desventajas, como son el hecho de que no ha sido liberado por completo o al menos falta el modelo de evaluación; además, está en proceso de convertirse en norma compitiendo con el proyecto de norma ISO/IEC TR 15504 y aunque no ha sido probado, se planea realizar pilotos en algunas organizaciones para evaluar qué tan fácil resulta su implantación determinando los recursos necesarios.
Lo interesante para nosotros como academia, es que tenemos la oportunidad de proponer productos concebidos y desarrollados en México, adecuados a nuestros requerimientos y realidad, lo que repercute de manera directa en la gama de soluciones que tiene una organización para resolver sus necesidades.

Modelo de Cascada:

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.
Un ejemplo de una metodología de desarrollo en cascada es:

1.             Análisis de requisitos

2.             Diseño

3.             Codificación

4.             Pruebas

5.             Implantación

6.             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 costes 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.

Fases del modelo

Análisis de requisitos

Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Diseño

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Codificación

Es la fase de programación propiamente dicha. Aquí se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.

Implantación

El software obtenido se pone en producción.

Mantenimiento

Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.

Variantes

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.