MUESTREO

1. SISTEMA INFORMÁTICO

1.1. CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN

Las aplicaciones informáticas tienen un ciclo de vida, desde su nacimiento hasta el momento de sustitución. Estos ciclos de vida se componen de una serie de etapas y fases sucesivas. Existen distintas formas de organizar el orden concreto en el que se acometerán las distintas etapas del ciclo de vida de un sistema deinformación. A continuación se describen algunas de las alternativas que deberían tenerse en cuenta:

1.1.1. CICLO DE VIDA CLÁSICO

El modelo de ciclo de vida clásico, también denominado "modelo en cascada", se basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas deverificación y validación propias de la etapa. Si resulta necesario, únicamente se da marcha atrás hasta la fase anterior.

Este modelo tradicional de ciclo de vida exige una aproximación secuencial al proceso de desarrollo del software. Esta aproximación presenta una serie de graves inconvenientes se puede destacar:

Los proyectos reales raramente siguen el flujo secuencial de actividades que proponeeste modelo.
Normalmente, es difícil para el cliente establecer explícitamente todos los requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no vea evolucionar el proyecto no tendrá una idea clara de qué es lo que realmente quiere).
No habrá disponible una versión operativa del sistema hasta llegar a las etapas finales del proyecto, por lo que la rectificación cualquierdecisión tomada erróneamente en las etapas iniciales del proyecto supondrá un coste adicional significativo, tanto económico como temporal (y eso sin tener en cuenta la mala impresión causada por un retraso en la fecha de entrega).

1.1.2. El ciclo de vida clásico: Modelo "en cascada"
Desde el punto de vista de una empresa de desarrollo de software, formalizar la firma de un contrato al final de laetapa de análisis, por ejemplo, puede ayudar a reducir el riesgo que supone elaborar un presupuesto cuando aún no se dispone de toda la información necesaria para que la estimación del esfuerzo requerido por el proyecto sea lo suficientemente precisa.
Para limar las asperezas que pueden surgir en la relación cliente-proveedor y mejorar el rendimiento del equipo del proyecto, hoy en día se suelerecurrir a modelos iterativos como los que se describirán a continuación.

Desarrollo de prototipos
Normalmente, el cliente es capaz de definir un conjunto general de objetivos para el sistema que hemos de construir, pero no identifica los requisitos detallados. En otros casos, puede que nosotros no estemos seguros de la eficiencia de un algoritmo, de la capacidad de nuestro diseño para soportarlos requerimientos del sistema o de la forma en que debe diseñarse la interfaz de usuario. En cualquiera de estas situaciones, resulta adecuado construir un prototipo.

















Prototipado

El desarrollo de prototipos reduce el riesgo de que nuestro proyecto fracase y facilita la especificación de requerimientos de productos que desconocemos. Sin embargo, también tienesus inconvenientes:
el cliente puede pensar que el prototipo es el sistema definitivo, ignorando que un prototipo no es un sistema acabado aunque tenga el mismo aspecto externo.

Esto puede conducir a la consolidación de aspectos de baja calidad de un prototipo en el sistema final que se entrega si el prototipo no se desecha a tiempo.

A veces, los prototipos desechables no se llegan adesechar. Pero los prototipos no siempre son desechables. En tal caso, estaremos utilizando un modelo iterativo de refinamiento de prototipos en el que, tras varias iteraciones, seremos capaces de construir un sistema que se adapte mejor a las necesidades de nuestro cliente.

Modelos iterativos
En 1994, el Departamento de Defensa de Estados Unidos (el mayor contratista mundial de proyectos de...