Sistemas de información. Unidad III. Univ. Gastón Dachary

1. SISTEMAS DE
INFORMACIÓN
Unidad III : Ciclo de vida de Sistemas de Información – Parte 1.

2. PRINCIPIOS ESENCIALES PARA
EL DESARROLLO DE S.I.
Implicar al usuario
Aplicar un método de
resolución de problemas
Definir fases y actividades
Establecer normas para un
desarrollo y una
documentación
consistentes
Justificar los sistemas
como inversión de capital
No tener miedo de revisar
o cancelar el proyecto
Divide y vencerás
Diseñar sistemas que
puedan crecer y cambiar

3. ESTRUCTURA P.I.E.C.E.S.
• Cuando los usuarios o analistas inician un proyecto suele decirse
que lo hacen como reacción a ciertas situaciones. El impulso de la
mayoría de los proyectos proviene de combinar problemas,
oportunidades y normas.
• Los problemas son situaciones no deseables que impiden a la
organización alcanzar plenamente sus propósitos, metas y
objetivos.
• Una oportunidad es toda posibilidad de mejorar la organización
incluso en ausencia de problemas específicos.
• Una norma es todo nuevo requisito impuesto por la dirección, las
instituciones gubernamentales o cualquier otra influencia externa.

4. ESTRUCTURA P.I.E.C.E.S.
• La estructura PIECES ha sido desarrollada por James Wetherbe
para la clasificación de lo problemas, las oportunidades y las
normas.
• Atribuyó a esta estructura el nombre PIECES formado por las
iniciales de cada una de las seis categorías.
P Necesidad de mejorar las prestaciones
I Necesidad de mejorar la información
E Necesidad de mejorar el control económico y de costos
C Necesidad de mejorar el control y la seguridad
E Necesidad de mejorar la eficacia de personas y maquinas
S Necesidad de mejorar el servicio a clientes, colaboradores,
empleados, etc

5. CICLO DE VIDA
• Cada vez son más las organizaciones grandes y pequeñas que están adoptando un ciclo de vida
uniforme y único para sus proyectos. Esto muchas veces se conoce como el plan del proyecto o
metodología del desarrollo del sistema.
• El manual del ciclo de vida del proyecto suele ser un libro tan voluminoso como el compendio de
normas. Este manual ofrece un procedimiento común a seguir para desarrollar un sistema que puede
orientar a cualquier miembro de la organización de desarrollo de sistemas.
• El enfoque puede ser casero, metodológico o también la organización puede comprar un paquete de
administración de proyectos y ajustarlo a las necesidades de la compañía. Además de dar empleo a
personas que crean manuales de ciclo de vida de proyectos, es conveniente la metodología del
proyecto.
• ¿De qué sirve entonces tener un ciclo de vida de un proyecto? Existen tres objetivos principales:
• Definir las actividades a llevarse a cabo en un proyecto de desarrollo de sistemas.
• Lograr congruencia entre la multitud de proyectos de desarrollo de sistemas en una misma
organización.
• Proporcionar puntos de control y revisión administrativos de las decisiones sobre continuar o no
con un proyecto.
• La ayuda que proporciona el ciclo de vida del proyecto es que puede organizar las actividades del
administrador, aumentando la probabilidad de que se traten los problemas pertinentes en el momento
adecuado.

6. CICLO DE VIDA
El ciclo de vida consta de cinco funciones de alto nivel:
Planificación Analisis
Diseño Implantación
Soporte

7. CICLO DE VIDA CLÁSICO
Cada proyecto atraviesa por algún tipo de análisis,
diseño e implantación. El ciclo de vida de proyecto
utilizado puede diferir del que muestra la ilustración en
una, varias o todas las siguientes maneras:
• Las fases de exploración y análisis pueden juntarse
en una sola (sobre todo sí se considera factible
desde el inicio cualquier cosa que quiera el usuario).
• Puede o no haber fase de estudio de hardware si se
cree que cualquier sistema nuevo puede instalarse
con las computadoras existentes.
• Las fases de diseño preliminar y de diseño de
detalles podrían juntarse en una sola llamada
simplemente diseño.
• Diversas fases de pruebas podrían juntarse en una
sola de hecho podrían incluirse con la codificación

8. CICLO DE VIDA CLÁSICO
Implantación ascendente: El uso de la implantación ascendente es una de las grandes
debilidades de los ciclos de vida de los proyectos clásicos.
Desventajas:
• Nada está hecho hasta que todo está terminado. Por ejemplo, si el proyecto se atrasa y la
fecha límite cae en medio del proceso de prueba, no habrá nada que mostrar.
• Las fallas más triviales se encuentran al comienzo del período de prueba y las más graves
al final. Por ejemplo errores de interfaz pueden obligar a la recodificación de un gran
número de módulos y afectar gravemente el calendario.
• La localización y eliminación de las fallas es muy difícil durante las últimas fases de prueba
del sistema.
• Las necesidades de prueba del sistema requieren demasiadas horas frente a la
computadora y normalmente retrasan el proyecto.
Progresión secuencial: La segunda debilidad del ciclo de vida de un proyecto clásico es su
insistencia en que sus fases se sucedan secuencialmente. Esto es una tendencia natural, el
problema que trae consigo este progreso ordenado es que no permite el tratamiento de
fenómenos reales como los relacionados con el personal, la política de la economía o los
cambios de requerimientos.

9. CICLO DE VIDA
SEMIESTRUCTURADO
• Desde fines de los 70 crece la tendencia a reconocer el diseño
estructurado, la programación estructurada y la implantación
descendente como parte del ciclo de vida del proyecto.
• Se muestran dos detalles no presentes en el enfoque clásico:
o La secuencia ascendente de codificación, la prueba de módulos y
del sistema se reemplazan por una implantación de arriba hacia
abajo, que es un enfoque en el cual los módulos de alto nivel se
codifican y prueban primero, seguidos por los de bajo nivel más
detallados.
o El diseño clásico se reemplaza por el diseño estructurado, que es
un es un enfoque de diseño formal de sistemas.
• La implantación descendente ofrece retroalimentación entre el proceso
de implementación y el de análisis.
• Gran parte del trabajo que se realiza bajo el nombre de “diseño
estructurado” es un esfuerzo manual para enmendar especificaciones
erróneas.
• Para quienes realizan el diseño estructurado la primer tarea es
transformar la especificación en un paquete de diagramas de flujo de
datos, diccionario de datos, diagramas de entidad - relación y las
especificaciones del proceso.

10. CICLO DE VIDA
ESTRUCTURADO
• Examinaremos aquí las nueve actividades y
los tres terminadores de este ciclo de
proyecto.
• Los terminadores (usuarios, adminis-tradores
y personal de operaciones) representan a
individuos o grupos que proporcionan las
entradas al equipo de trabajo y son los
beneficiarios finales del sistema, ellos
interactúan con las nueve actividades.
• Nada indica que la actividad N debe concluir
antes que comience la N+1, pueden llevarse
acabo diversas actividades en forma paralela,
con la suficiente cordura de paralelismo (Ej.
No realizar encuesta y codificación al mismo
tiempo).
• Prácticamente todas las actividades pueden y
suelen producir información que pueden
llevar a modificaciones adecuadas de una o
más actividades precedentes.

11. CICLO DE VIDA ESTRUCTURADO
- ACTIVIDADES
Actividad 1- La encuesta: Comienza cuando el usuario solicita que una o más partes de su sistema se
automaticen, o se modifiquen. Los principales objetivos son:
• Identificar a los usuarios responsables y crear un 'campo de actividad' inicial del sistema. Esto
puede comprender una serie de entrevistas para determinar usuarios involucrados en el proyecto.
• Identificar deficiencias actuales en el ambiente del usuario. Como que el hardware del sistema
actual no es confiable; el software no se puede mantener, o no es conveniente.
• Preparar el esquema que se usará para guiar el proyecto.
Actividad 2 – El análisis de sistemas: El propósito de esta actividad es transformar sus entradas principales,
políticas del usuario y esquema del proyecto en una especificación estructurada. Esto implica modelar el
ambiente del usuario con diagramas de flujo de datos, diagrama de entidad - relación, diagramas de
transición de estados y otras herramientas.
Actividad 3 – El diseño: Esta actividad se dedica a la creación de una jerarquía apropiada de módulos de
programas y de interfaces entre ellos para implantar la especificación creada en la actividad de análisis.
Además transforma el modelo de datos de entidad - relación en un diseño de base de datos.

12. CICLO DE VIDA ESTRUCTURADO
- ACTIVIDADES
Actividad 4 - Implantación: Incluye la codificación y la integración de módulos en un
esqueleto progresivamente más completo del sistema final. Incluye tanto programación
como implantación descendente.
Actividad 5 – Generación de pruebas de aceptación: Una vez generada la especificación,
puede comenzar la actividad de producir un conjunto de casos de pruebas de aceptación
desde la especificación estructurada.
Actividad 6 – Garantía de calidad: También llamada prueba final o prueba de aceptación.
Requiere como entrada los datos de prueba de aceptación generada en la actividad 5 y el
sistema integrado producido en la actividad 4.
Se necesita una actividad que verifique que el sistema tenga un nivel apropiado de calidad.
Nótese que es importante llevar a cabo actividades de control de calidad en cada una de las
actividades anteriores para asegurar que se hayan realizado con el nivel adecuado.
Actividad 7 – Descripción del procedimiento: Una de las actividades importantes es la
generación de una descripción formal de las partes del sistema que se harán en forma
manual, lo mismo que la descripción de cómo interactúan los usuarios con la parte
automatizada del nuevo sistema. El resultado de esta actividad es un manual para el
usuario.3

13. CICLO DE VIDA ESTRUCTURADO
- ACTIVIDADES
Actividad 8 – Conversión de la base de datos: En algunos proyectos la conversión de la base
de datos involucra más trabajo y más planeación estratégica que el desarrollo de programas
del nuevo sistema.
En otros casos puede no existir una base de datos que convertir. En general esta actividad
requiere como entrada la base de datos actual del usuario, al igual que la actividad de
diseño producida por la actividad 3.
Actividad 9 – Instalación: Esta es la actividad final, sus entradas son el manual del usuario
producido en la actividad 7, la base de datos convertida que se creó con la actividad 8 y el
sistema aceptado producido por la actividad 6.
En algunos casos la instalación podrá ser total; pero también puede ser un proceso gradual,
en el que un grupo tras otro de usuarios van recibiendo manuales y entrenamiento y
comenzando a usar el nuevo sistema.

14. CICLO DE VIDA DE
PROTOTIPOS
Es una versión operativa preliminar (un modelo piloto) del
Sistema de Información que se emplea con fines de
demostración y evaluación. Tiene las características esenciales
pero no todos los detalles necesarios en la interfaz con el
usuario ni tampoco un desempeño eficiente.
Etapas:
Identificar los
requerimientos
básicos del
usuario
Desarrollo de
un prototipo
inicial
Uso y prueba
del prototipo
Revisión y
mejora del
prototipo

15. CICLO DE VIDA DE
PROTOTIPOS
Cuando ya no se requieren iteraciones, el Prototipo aprobado se transforma en un Prototipo
operativo que proporciona las especificaciones finales para la aplicación y se opta por una
de las siguientes opciones:
• El Prototipo se convierte en la versión definitiva del sistema deseado. Algo no deseado ya
que generalmente el Prototipo no puede trabajar eficientemente con grandes volúmenes
de transacciones, y porque carece de detalles operacionales tales como recuperación de
errores, auditorias, documentación para el Usuario, etc.
• Además si no queda registrada la información de los requerimientos se dificulta el
posterior Mantenimiento.
• Se utiliza la información obtenida con el Prototipo operativo para comenzar el desarrollo
detallado de un nuevo sistema (es como si reemplazara el Análisis Estructurado).
• Se emprende el desarrollo de un nuevo Prototipo.
• Se toma la decisión de abandonar el sistema en su totalidad.

16. BIBLIOGRAFÍA
• “Análisis Estructurado Moderno”. Yourdon, Edward. Prentice Hall.
1993.
• “Análisis y diseño de Sistemas de Información”. Whitten, Bentley,
Barlow. McGraw-Hill. 1996.