Introduccion Al Analisis de Sistemas Modulo II PDF

Fuente: http://www.masingenieros.com/wp-content/uploads/2013/10/19338503_xl.
jpg
COMIENZO DE UN PROYECTO
Fuente:http://2.bp.blogspot.com/-PYpiFSS39_U/TtTIOLHbrLI/AAAAAAAAAWc/9OYUiTt4CkQ/s400/PlanificacionProyectoInformatico.png
1. INICIO DE UN PROYECTO
i. Comprender como se inician y seleccionan los proyectos
Los problemas salen a la superficie de muchas formas. Una manera de conceptualizar
qué son los problemas y cómo surgen es considerarlos como situaciones en las que
nunca se cumplieron los objetivos o dejaron de cumplirse en algún punto.
Lo primero que debemos hacer es identificar las deficiencias del sistema existente. El
objetivo del proyecto es subsanar esas deficiencias, que se encuentran normalmente
mediante entrevistas o al examinar documentos sobre el funcionamiento del sistema.
Además, durante el análisis inicial, los entrevistadores deberán buscar deficiencias
como:
Funciones que faltan; funcionamiento insatisfactorio o excesivo costo de la
operación.
Comprobar la salida, observar el comportamiento de los empleados y escuchar la
retroalimentación son todas formas de ayudar al analista a destacar los problemas y
oportunidades de sistemas.
Definir los problemas y objetivos del sistema, forman la base para determinar qué debe
lograr el sistema.
Prof. Cynthia Rivas Aquino

Por lo general, la definición de un problema contiene cierta clase de declaración del
mismo, sintetizada en uno o dos párrafos. A ésta le siguen una serie de cuestiones o
piezas independientes importantes del problema.
Los objetivos pueden ser muy específicos o se pueden redactar mediante una
declaración general.
3
Sobra decir que el analista de sistemas debe comprender la forma en que funciona la
empresa.
La última parte de la definición del problema contiene los requerimientos, las cosas que
se deben lograr, junto con las posibles soluciones y las restricciones que limitan el
desarrollo del sistema. A menudo las restricciones incluyen la palabra no para indicar
una limitación, y pueden contener restricciones en el presupuesto o límites de tiempo.
La definición del problema se produce después de terminar con las entrevistas, las
observaciones y el análisis de los documentos con los usuarios. El resultado de recopilar
esta información es una enorme cantidad de hechos y opiniones importantes que debe
sintetizarse.
ii. Definición de objetivos

Los objetivos del proyecto tienen dos aspectos importantes para los analistas de
sistemas: como se ven y como se especifican. Ya que los proyectos son variados, hay
muchas formas de definir los objetivos. Por ellos no es posible dar unas reglas exactas
para hacerlo. En el mejor de los casos se puede dar alguna indicación general. Se
comenzará como establecer los objetivos y después describir como son. Una regla
importante para establecer un objetivo es recordar que los objetivos no pueden ser ideas

irrealizables, que luego se ignoren. Se debe desarrollar con los expertos de la
organización. Una vía para asegurar, que tales expertos se pueden encontrar es elaborar
los objetivos con subobjetivos más detallados que consideren las restricciones de la
organización. Estos subobjetivos se utilizaran en etapas posteriores para guiar el análisis
y diseño detallados.
4
A veces, el analista debe realizar una entrevista de seguimiento para obtener
información más precisa sobre los objetivos. Si no hay suficientes fondos para
desarrollar el sistema completo, primero es necesario completar los objetivos más
críticos. Los usuarios son quienes pueden identificar mejor los objetivos más críticos
(con la ayuda de los analistas), ya que son expertos de dominio en su área de negocios y
saben cómo trabajar mejor con las tecnologías en la organización.
iii. Obtención de soluciones alternativas

El análisis de viabilidad comienza una vez que se han definido y aceptado los objetivos.
Empieza obteniendo las posibles soluciones que se utilizan para indicar lo que será el
nuevo sistema. En este caso no es necesario entrar en las operaciones detalladas del
sistema. La solución debe suministrar suficiente información para hacer estimaciones
razonables sobre el costo del proyecto y dar una indicación a los usuarios de cómo se
adaptará el nuevo sistema a la organización. Es importante no dedicar demasiado
esfuerzo en esta etapa, pues se puede decidir que el proyecto no seguirá adelante o que
se necesita cambiar sustancialmente el objetivo original.
Hay que tener presente dos cosas cuando se propone una solución general: debe dar una
idea de lo que será el nuevo sistema y convencer a las personas de que funcionará. La
solución general debe incluir partes principales del sistema propuesto. Una solución
general debe incluir todo equipamiento adicional que se adquirirá en el proyecto para
estimar el costo directo del mismo.
Se debe especificar que se hará automáticamente y que manualmente.
iv. Determinar la viabilidad de un proyecto propuesto

En este punto debemos determinar si los proyectos seleccionados son viables. Nuestra
definición de viabilidad va mucho más allá del uso común del término, ya que existen
tres formas principales para evaluar la viabilidad de los proyectos de sistemas: en base a

su operación, a su capacidad técnica y a su economía. El estudio de viabilidad no es un
estudio detallado de sistemas, sino que se utiliza para recopilar datos más generales para
los miembros de la administración, lo cual a su vez les permite tomar una decisión en
cuanto a si deben continuar o no con un estudio de sistemas.
Los datos para el estudio de viabilidad se pueden recuperar a través de entrevistas. Por
5
lo general, el Analista de sistemas entrevistas a las personas que piden ayuda y a las que
están relacionadas en forma directa con el proceso de toma de decisiones, que
generalmente son los administradores.
El estudio de viabilidad debe tardar el menor tiempo posible, procurando abarcar varias
actividades en un periodo de tiempo corto.
Por lo general, el proceso de evaluación de la viabilidad es efectivo para descartar
proyectos inconsistentes con los objetivos de la empresa, que requieran una capacidad
técnica imposible o que no tengan ningún mérito económico.
Aunque es meticuloso, el estudio de la viabilidad es algo que vale la pena ya que ahorra
tiempo y dinero a las empresas y a los analistas de sistemas. Para que el analista pueda
recomendar que se continúe con el desarrollo de un proyecto, éste debe mostrar que es
viable en las tres siguientes formas: técnica, económica y operacional. Como se muestra
en la figura.

v. Determinación de recursos.
Viabilidad técnica: El analista debe averiguar si es posible desarrollar el nuevo sistema
teniendo en cuenta los recursos técnicos actuales. De no ser así, ¿se puede actualizar o
complementar el sistema de tal forma que pueda cumplir con lo que se requiere? Si no
es posible complementar o actualizar los sistemas existentes, la siguiente pregunta es si
6
¿Está disponible la tecnología necesaria para desarrollar la propuesta? ¿Cumple con las
especificaciones?¿Se puede utilizar en la organización?
Otra de las preguntas es si hay o no paquetes de software disponibles que puedan lograr
sus objetivos, o si hay que personalizar el software para la organización. Para evaluar la
viabilidad técnica hay que evaluar la habilidad del hardware y software computacional
para manejar las cargas de trabajo en forma adecuada. En primer lugar, hay que realizar
un inventario de todo el hardware computacional con el que cuente la organización para
descubrir qué hay disponible y qué se puede utilizar.
El analista de sistemas necesita trabajar con los usuarios para determinar qué hardware
se necesitará.
Viabilidad económica: La viabilidad económica es la segunda parte de la

determinación de recursos. Los recursos básicos a considerar son el tiempo de usted
como analista y el tiempo de su equipo de análisis de sistemas, el costo de realizar un
estudio de sistemas completo (incluyendo el tiempo de los empleados con los que usted
va a trabajar), el costo estimado del hardware y el costo estimado del software o del
desarrollo de software.
La empresa afectada debe ser capaz de ver el valor de la inversión que está
considerando antes de comprometerse con un estudio de sistemas completo. Si los
costos a corto plazo no se ven eclipsados por las ganancias a largo plazo o no producen
una reducción inmediata en los costos de operación, entonces el sistema no es
económicamente viable y el proyecto no debe continuar.
Preguntas como estas se realizan: ¿Es realista para proseguir el proyecto? O, ¿Se
recuperara la cantidad de dinero necesaria para la implementación?

Viabilidad operacional: La viabilidad operacional depende de los recursos humanos
disponibles para el proyecto e implica la acción de pronosticar si el sistema funcionará y
se utilizará una vez instalado.
Si los usuarios están prácticamente casados con el sistema actual, no ven problemas con
él y por lo general no están involucrados en el proceso de solicitar un nuevo sistema,
7
habrá mucha resistencia a la implementación del nuevo. Las probabilidades de que se
vuelva funcional en algún momento dado serán bajas. Por otro lado, si los mismos
usuarios han expresado la necesidad de un sistema que sea funcional por más tiempo, de
una forma más eficiente y accesible, hay más probabilidades de que el sistema
solicitado se llegue a utilizar en un momento dado. Gran parte del arte de determinar la
viabilidad operacional recae en las interfaces de usuario elegidas.
Algunas de las preguntas realizadas son:
¿Puede el sistema propuesto convivir con las operaciones ya existentes? ¿Suministra la
información necesaria para el personal de la organización? ¿Llega esa información a
tiempo en el lugar correcto?
2. RELEVAMIENTO DE DATOS
i. Método de trabajo para la recopilación de información
La recopilación de información, es un sistema grande y complejo, puede ser una tarea
costosa. La información se debe reunir siguiendo un camino organizado para asegurar
que no haya redundancias y que se recogen todos los detalles del sistema. Se debe
consultar a todos los usuarios para asegurarse de que todo problema del sistema,
necesidad del usuario y objetivo está identificado. La búsqueda se debe hacer, de tal
forma que se eviten los trabajos repetitivos y que un mismo usuario no sea interrogado
varias veces pidiéndole la misma información.
ii. Estrategias de búsqueda

Es fácil equivocarse cuando la recogida de información se realiza sobre un gran sistema
que tiene muchas fuentes de información para evitar problemas, es necesario desarrollar
una estrategia para la recogida de información a fin de asegurar que se cumplen todos
los criterios.
Una estrategia de búsqueda se establece por dos importantes elecciones:

 Primero, se identifican todas las fuentes de las que se obtendrá información,
junto con los métodos para obtener la información de cada una de ellas.
 Luego se establece un procedimiento de búsqueda para conseguir la
información. El procedimiento de búsqueda define donde empezar la búsqueda
y como continuarla. También identifica la secuencia en que se examinaran las
8
fuentes y que información se obtendrá en cada paso.
En resumen debemos definir la: fuente de información, Métodos de búsqueda,
procedimientos de búsqueda.
La estrategia de búsqueda ayuda al analista a establecer el sentido de la información
obtenida en las fuentes. Estos métodos los utiliza el analista para construir modelos del
sistema que ayuden a controlar lo que hace cada día y lo que necesita hacer para
completar su trabajo.
iii. Fuente de información

Hay una gran variedad de fuente de información para un sistema. Normalmente, cada
fuente da información distinta y requiere un método de búsqueda diferente para
conseguirla. Algunas de las fuentes más comunes se exponen seguidamente.
Usuarios del sistema: Los usuarios del sistema son normalmente la primera
fuente de información a investigar por el analista. De los usuarios es posible extraer
información de las actividades del sistema existente y determinar los objetivos de
usuarios y sus necesidades. Aquí, los métodos usuales son las entrevistas y, a veces
cuestionarios. Las entrevistas son uno de los principales métodos usados para recoger
información.
Formularios y documentos: Los formularios y documentos son fuentes de
información utilizadas para los diagramas de flujos de datos y transacciones.
El método de búsqueda comienza con la obtención por parte del analista de una lista de
tales documentos de usuario del sistema para, a través de ellos encontrar los datos
elementales y sus estructuras de datos.
Programas: Los programas se pueden utilizar para determinar los detalles de las
estructuras de datos o de los procesos. Los métodos de búsqueda son generalmente
laboriosos suponen la lectura del programa o su documentación y, a veces, su ejecución

con datos de muestra para ver lo que hace o si algo está en desacuerdo con la interfaz
actual del usuario.
Manuales de procedimientos: Los manuales de procedimientos especifican lo
que hace el personal de una organización. Los puede utilizar el analista para determinar
en detalle las actividades del usuario.
9
Esta información adquiere relevancia en el diseño detallado. Los métodos de búsqueda
se centran en el estudio de tales documentos.
Informes: Esta fuente indica las clases de salidas necesarias para el usuario. Se
pueden utilizar como base para entrevistas con el usuario y así determinar cualquier
nuevo requerimiento de salida que pueda tener.
Es muy improbable que una de estas fuentes pueda, por si sola suministrar toda la
información que necesita un analista. Si es parte de un sistema existente, con toda
certeza se podrá obtener información sobre la organización de la mayoría de las fuentes,
si no de todas.
iv. Procedimiento de búsqueda

El procedimiento de búsqueda propone el orden para buscar las fuentes de información
y que métodos utilizar en la búsqueda. Así, el procedimiento de búsqueda viene a ser un
plan para fijar que información se obtendrá de cada fuente y que secuencia se seguirá
para investigar en ellas.
El procedimiento de búsqueda tiene unos requerimientos generales. Primero, debe ser
de naturaleza top-down. Debe garantizar que se examinan todas las fuentes de
información y así tener la seguridad de que se recoge toda la información sobre el
sistema.
Procedimiento Top-down: Se necesita la aproximación top-down para construir
progresivamente el modelo del sistema.
Siempre es mejor empezar por el nivel superior y seguir hasta el nivel inferior para
obtener información detallada. Esta aproximación comienza normalmente con una serie
de entrevistas con los directores, para determinar las funciones principales del sistema y
sus actividades.

Entonces, el analista busca más información para describir esas funciones y actividades.
Los procedimientos de búsqueda varían dependiendo de si se investiga un sistema
existente o si se diseña uno totalmente nuevo.
 Sistemas nuevos: 10
Los procedimientos para nuevos sistemas son más simples, porque hay pocas fuentes de
información.
No hay informes, programas, ni manuales que examinar. El procedimiento completo se
centra en las entrevistas, pero la forma de atacar éstas es distinta. Las entrevistas no
deben buscar cómo trabaja el sistema, sino determinar lo que los usuarios esperan del
nuevo sistema. Cuando se propone la totalidad del nuevo sistema, generalmente el
analista busca información en fuentes externas. Los analistas pueden examinar estos
sistemas externos para ver si alguna de sus características se ajusta el nuevo sistema
propuesto.
 Sistemas existentes
Estos deben incluir las numerosas fuentes de información de los sistemas para
establecer una secuencia de búsqueda en esas fuentes.
1 - Empieza con una serie de entrevistas iniciales para saber de qué se trata el sistema.
Estas entrevistas identifican funciones y a veces establecen los límites del problema. En
este punto generalmente los analistas estudian algunos de los informes y documentos
más importantes.
2 - Entonces diseñan un modelo de nivel superior
3- Lo verifican durante el siguiente conjunto de entrevistas.
4 - Una vez establecido un modelo de nivel superior satisfactorio, el analista comienza
operaciones más detalladas. La búsqueda de esa información más detallada empieza
normalmente con entrevistas al personal de operación. Estas entrevistas establecen las
fuentes detalladas de información, incluyendo programas, informes y Manuales.
5 - La clase de datos solicitados en el nivel inferior depende del sistema. Si se
perfecciona un sistema, el analista debe examinar los sistemas y programas existentes.
Si se van a mejorar procedimientos manuales, el analista realizara un examen detallado

de los procedimientos actuales. En la mayoría de los casos se debe examinar tanto el
sistema como el procedimiento de usuario.
El analista utiliza esta nueva información detallada para expandir el modelo de nivel
superior que será verificado con el usuario.
6 - Este procedimiento puede repetirse varias veces mientras se busca información cada
11
vez más detallada. Esta secuencia de entrevistas y búsquedas se hará más crítica según
el analista vaya aprendiendo cosas sobre el sistema.
7 - El analista comienza la identificación de los problemas del sistema y junto con el
usuario establece los objetivos del nuevo sistema. La iteración continuara hasta que el
analista este conforme con el modelo.
Este pasa entonces por una serie de revisiones, comenzando con una revisión técnica
para establecer formalmente la exactitud del modelo.
8- Finalmente pasa a revisión por la dirección para que dé la conformidad a los
objetivos del sistema y obtener los recursos para el desarrollo del nuevo sistema.
A continuación se muestra un listado de las tareas principales realizadas. (Favor si

pueden realizar un recuadro donde figuren estas tareas, es la resumida de la anterior).
1- Empiezan las entrevistas de nivel superior para determinar las principales

actividades del sistema y examinar las principales entradas y salidas.
2- Desarrolla un modelo de nivel superior del sistema.
3- Verifica el modelo de nivel superior.
4- Entrevistas con el personal de operaciones. Examen detallado de

documentos, procedimientos, programas e informes.
5- Expande el modelo de nivel superior en sus componentes detallados.
6- Verifica el modelo detallado.
7- Revisión técnica formal del modelo.
8- Revisión de dirección.

v. Métodos de búsqueda
 La entrevista
Es el método más simple para recoger información del usuario, es un proceso continuo
utilizado por el analista para construir gradualmente un modelo de sistema y para
obtener conocimientos sobre los problemas del sistema. 12
Esta debe efectuarse de forma organizada y amistosa. El entrevistador siempre será

cortes y respetará la posición y necesidades del usuario. Es importante no imponer
soluciones a los usuarios, sino realizar el papel de asesor. No se debe utilizar términos
informáticos para impresionar al usuario, los entrevistadores deben explicar las
limitaciones del ordenador en términos cotidianos y describir al usuario como le puede
ayudar en su trabajo. Este debe realizar preguntas precisas y concretas, quienes
responden pueden ser los gerentes o empleados, los cuales son, las personas que utilizan
el sistema actualmente y potenciales usuarios del sistema propuesto.
 Cuestionarios
Los cuestionarios son una técnica de recopilación de información que permite a los
analistas de sistemas estudiar las actitudes, creencias, comportamiento y características
de muchas personas importantes en la organización que podrían resultar afectadas por
los sistemas actuales y los propuestos. La redacción que utilice el analista de sistemas
influye en las respuestas a preguntas sobre actitudes y creencias. Al usar cuestionarios,
el analista podría estar buscando cuantificar lo que se haya descubierto en las
entrevistas. Además, éstos podrían usarse para determinar qué tan extendido o limitado
es en realidad un sentimiento expresado en una entrevista. Por otra parte, los
cuestionarios se pueden usar para encuestar a una muestra considerable de usuarios de
sistemas con el fin de detectar problemas o poner de manifiesto cuestiones importantes
antes de que se realicen las entrevistas.
 Encuestas
La encuesta es un instrumento para la investigación, consiste en obtener información de
las personas encuestadas mediante el uso de cuestionarios diseñados en forma previa
para la obtención de información específica. Es una herramienta no muy útil en los

relevamientos de datos ya que no ayuda a obtener información detallada que defina
cuestiones necesarias para realizar un desarrollo.
 Plan de entrevista.
Hay dos factores clave en la realización de entrevistas 13
1 – Elegir a la persona a entrevistar. Es importante, así que el analista debe asegurarse

de que se considera a todas las personas clave dentro del entorno del estudio.
2 – El siguiente factor es encontrar el camino correcto para dirigir una entrevista
individual. Aquí deben considerar las relaciones humanas. El entrevistador debe
establecer algunos contactos con el entrevistado a fin de asegurar la cooperación
necesaria para obtener todos los factores relevantes.
El plan de entrevista para cada usuario

Normalmente, es deseable comenzar las entrevistas por el nivel más alto de la
organización para obtener el soporte y la cooperación de la dirección antes de comenzar
a examinar actividades organizativas particulares o sugerir nuevas soluciones.
Tanto en las entrevistas iniciales como en las posteriores, el analista siempre intentará
encontrar la forma de conseguir más información. Así, pues, la preparación de las
entrevistas es esencial. Se debe tener unan idea de lo que se pretende conseguir con la
entrevista y formular preguntas directas para obtener esa información.
De esta manera, el proceso de la entrevista sigue un camino totalmente estructurado. Se
consigue de la dirección una visión general de la operación del sistema, pasando
después a las operaciones detalladas mediante entrevistas con usuarios de distintos
niveles de operación del sistema.
No se debe esperar obtener toda la información necesaria de un usuario en el curso de
una entrevista.
Normalmente, hay una serie de dos, tres o más entrevistas con un usuario.
Dentro de una organización, la entrevista es la técnica más significativa y productiva
que dispone el analista para recabar datos, sirve para obtener información acerca de las
necesidades y la manera de satisfacerlas. Una vez culminada la entrevista esta debe ser
escrita (Documentada), analizada, estudiada y por ultimo archivarla para referencia.

3. PLANEACIÓN Y CONTROL DE ACTIVIDADES
i. Uso de graficas de Gantt para la programación de proyectos
Se conoce también como itinerario de tareas. Observe el ejemplo (grafico más abajo)
que cada actividad se muestra con una indicación de cuando comienza y cuando
termina; el área sombreada indica tiempo de ocio posible, mientras que las actividades 14
encerradas en rectángulos blancos pertenecen al camino crítico.

Como puede verse, el diagrama de Gantt presenta en gran medida el mismo tiempo de
información que el diagrama de PERT; su principal diferencia es el hecho de que
muestra la duración de cada actividad, mientras que el diagrama de PERT no lo hace.
Dado que es una representación un tanto más tabular de proyecto, a menudo puede
usarse para presentar una gran cantidad de información en una forma relativamente
compacta.

ii. Uso de diagramas de PERT
PERT es un acrónimo dado por las siglas en ingles de Técnica de Revisión de la
Evaluación de Programas. Originalmente se desarrolló en los años 60 como una
herramienta de administración para proyecto de submarinos Polaris de la fuerza naval
de los Estados Unidos; suele darse el crédito a Booz Allen (la empresa consultora), a
15
Lockheed Aircraft y a la Marina por haber desarrollado el concepto. Los diagramas
PERT se han utilizado ampliamente en proyectos de la industria y el gobierno desde
entonces; también se le conoce como diagrama de actividades.
Ejemplo de un diagrama PERT típico para un proyecto hipotético.
Cada rectángulo representa una actividad o tarea (es decir, un fragmento reconocible de
trabajo que debe hacerse). Los cuadros con esquinas redondeadas se conocen como
señalamientos y tienen un significado obvio dentro del contexto de un proyecto típico.
Las líneas que conectan muestran dependencias; es decir, muestran que actividades
deben terminarse antes de comenzar otra. Las líneas más gruesas y oscuras que forman
un camino contiguo del principio al final del proyecto representan camino crítico, es
decir, aquellas actividades cuyo retraso obligaría al retraso del proyecto global (las
actividades que no están en el camino critico tienen “tiempo de ocio” disponible;

pueden comenzarse hasta después de un tiempo igual a este luego de la fecha
programada, si así se desea, sin afectar al proyecto en conjunto).
Observe que el administrador del proyecto es quien determina cuales tareas dependen de
otras. En muchos casos, la dependencia se relaciona con los datos; la actividad N+1
requiere como entrada algo que se produce como salida de la actividad N. En otros, la
16
dependencia representa un punto de revisión del proyecto (por ejemplo, el señalamiento
N pudiera ser una junta de revisión administrativa en la que se debe aprobar la labor
realizada hasta ese momento, antes de comenzar la actividad N+1).
Observe que el ejemplo es realmente trivial: contiene solo diez actividades y termina
cuando concluye las actividades de análisis de sistema. Desde luego, un proyecto típico
continúa aun después de terminarse la labor de análisis, e invierte una considerable
cantidad de tiempo en el área de diseño, codificación, prueba, etc. De hecho, es
probable que un proyecto típico tenga varios cientos de actividades que se mostrarían en
un diagrama PERT.
Se enfoca a las actividades y sus interdependencias, pero dice poco o nada acerca de
otros aspectos del proyecto que son de interés para un administrador. Por ejemplo: que
persona o grupo lleva a cabo las diversas actividades; tampoco dice nada explícitamente
acerca de la cantidad de tiempo (o número de días-persona) que cada actividad requiere.
Y tampoco muestra que productos o salidas se obtienen por cada actividad.
Lo que claramente demuestra el diagrama PERT es que muchas actividades pueden
llevarse a cabo paralelamente en un proyecto real. Esto es muy importante porque
muchos de los otros modelos implican fuertemente que las actividades deben hacerse
secuencialmente. Los administradores generalmente quieren aprovechar lo más posible
el “paralelismo” pues puede ayudar a reducir el tiempo necesario para el proyecto.
4. TIPOS DE CICLO DE VIDA

a. Definición de Ciclos de Vida.
Para ser un buen analista de sistema se requiere más que simples herramientas de
modelado; se necesita métodos. En la profesión de desarrollo de sistemas, los términos
“método”, “metodología”, “ciclo de vida del proyecto” y “ciclo de vida del desarrollo
de un sistema” se usan de manera casi indistinta.

Las organizaciones pequeñas de proceso de datos tienden a ser relativamente
informales: los proyectos de desarrollo de sistemas nacen de conversaciones entre el
usuario y el administrador del proyecto (puede ser el analista, programador, etc.), y el
proyecto procede desde el análisis hasta el diseño e implementación sin mayor alboroto.
Sin embargo en las organizaciones más grandes, las cosas se llevan a cabo de manera
17
mucho más formal. La comunicación entre los usuarios, la administración y el equipo
del proyecto suele ser por escrito, y todo el mundo entiende que el proyecto pasara por
diversas fases antes de completarse.
Recientemente, sin embargo, ha empezado a cambiar el enfoque que se le da al
desarrollo de sistemas. Cada vez más las organizaciones grandes y pequeñas que están
adoptando un ciclo de vida uniforme y único para sus proyecto. Esto a veces se conoce
como el plan del proyecto, la metodología del desarrollo del sistema o, simplemente, “la
forma en la que hacemos las cosas”. El manual del ciclo de vida del proyecto ofrece un
procedimiento común a seguir para desarrollar un sistema computacional.
El ciclo de vida tiene tres objetivos principales:
1- Definir las actividades a llevarse a cabo en un proyecto de desarrollo de
sistemas, definir la secuencia en que se deben tratar esas actividades.
2- Ayuda a los analistas y diseñadores a resolver problemas que surgen durante el
desarrollo del sistema, marcando la dirección del proyecto y proporcionando una
guía sobre lo que se debería obtener como resultado del mismo.
3. Ayuda a los directores produciendo informes del estado del proyecto y
manteniendo un seguimiento de las necesidades de recursos. Proporcionar
puntos de control y revisión administrativa de las decisiones sobre continuar o
no con un proyecto.
Dicho esto, no queda más que subrayar que el ciclo de vida del proyecto
definitivamente no está a cargo del proyecto; no le evitara al administrador del proyecto
la difícil labor de tomar decisiones. La única ayuda que puede proporcionar el ciclo de
vida del proyecto es que puede organizar las actividades del administrador, aumentando
la probabilidad de que se aborden los problemas pertinentes en el momento adecuado.

b. Actividades del ciclo de vida.
Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo de vida
del desarrollo de sistemas, pero en general alaban su enfoque organizado. Aquí hemos
dividido el ciclo en siete fases, como se aprecia. A pesar de que cada fase se explica por
separado, nunca se realiza como un paso aislado. Más bien, es posible que varias
18
actividades ocurran de manera simultánea, y algunas de ellas podrían repetirse.
1. IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS: En
esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de
identificar problemas, oportunidades y objetivos. Esta etapa es crítica para el éxito
del resto del proyecto, pues a nadie le agrada desperdiciar tiempo trabajando en un
problema que no era el que se debía resolver. La primera fase requiere que el analista
observe objetivamente lo que sucede en un negocio. A continuación, en conjunto con
otros miembros de la organización, el analista determina con precisión cuáles son los
problemas. Con frecuencia los problemas son detectados por alguien más, y ésta es la
razón de la llamada inicial al analista. Las oportunidades son situaciones que el
analista considera susceptibles de mejorar utilizando sistemas de información
computarizados. El aprovechamiento de las oportunidades podría permitir a la
empresa obtener una ventaja competitiva o establecer un estándar para la industria.
La identificación de objetivos también es una parte importante de la primera fase. En
primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A
continuación, podrá determinar si algunas funciones de las aplicaciones de los
sistemas de información pueden contribuir a que el negocio alcance sus objetivos
aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y
los administradores de sistemas que coordinan el proyecto son los involucrados en la
primera fase. Las actividades de esta fase consisten en entrevistar a los encargados de
coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del
proyecto y documentar los resultados. El resultado de esta fase es un informe de
viabilidad que incluye una definición del problema y un resumen de los objetivos. A
continuación, la administración debe decidir si se sigue adelante con el proyecto
propuesto. Si el grupo de usuarios no cuenta con fondos suficientes, si desea atacar
problemas distintos, o si la solución a estos problemas no amerita un sistema de
cómputo, se podría sugerir una so-lución diferente y el proyecto de sistemas se
cancelaría.

2. DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN: La
siguiente fase que enfrenta el analista es la determinación de los requerimientos de
información de los usuarios. Entre las herramientas que se utilizan para determinar
los requerimientos de información de un negocio se encuentran métodos interactivos
como las entrevistas, los muestreos, la investigación de datos impresos y la
19
aplicación de cuestionarios; métodos que no interfieren con el usuario como la
observación del comportamiento delos encargados de tomar las decisiones y sus
entornos de oficina, al igual que métodos de amplio alcance como la elaboración de
prototipos. El desarrollo rápido de aplicaciones es un enfoque orientado a objetos
para el desarrollo de sistemas que incluye un método de desarrollo (que abarca la
generación de requerimientos de información) y herramientas de software. En la fase
de determinación de los requerimientos de información, el analista se esfuerza por
comprender la información que necesitan los usuarios para llevar a cabo sus
actividades. Como puede ver, varios de los métodos para determinar los
requerimientos de información implican interactuar directamente con los usuarios.
Esta fase es útil para que el analista confirme la idea que tiene de la organización y
sus objetivos. En ocasiones sólo realizan las dos primeras fases del ciclo de vida del
desarrollo de sistemas. Esta clase de estudio podría tener un propósito distinto y por
lo general la lleva a la práctica un especialista conocido como analista de
información. Los implicados en esta fase son el analista y los usuarios, por lo general
trabajadores y gerentes del área de operaciones. El analista de sistemas necesita
conocer los detalles de las funciones del sistema actual: el quién (la gente
involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se
desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera
en que se realizan los procedimientos actuales) del negocio que se estudia. A
continuación el analista debe preguntar la razón por la cual se utiliza el sistema
actual. Podría haber buenas razones para realizar los negocios con los métodos
actuales, y es importante tomarlas en cuenta al diseñar un nuevo sistema. Sin
embargo, si la razón de ser de las operaciones actuales es que "siempre se han hecho
de esta manera", quizá será necesario que el analista mejore los procedimientos. La
reingeniería de procesos de negocios podría ser útil para conceptualizar el negocio de
una manera creativa. Al término de esta fase, el analista debe conocer el
funcionamiento del negocio y poseer información muy completa acerca de la gente,
los objetivos, los datos y los procedimientos implicados.

3. ANÁLISIS DE LAS NECESIDADES DEL SISTEMA: La siguiente fase que
debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema.
De nueva cuenta, herramientas y técnicas especiales auxilian al analista en la
determinación de los requerimientos. Una de estas herramientas es el uso de
diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de
20
las funciones del negocio en una forma gráfica estructurada. A partir de los
diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los
datos utilizados en el sistema, así como sus respectivas especificaciones. Durante
esta fase el analista de sistemas analiza también las decisiones estructuradas que se
hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden
determinar las condiciones, las alternativas de condición, las acciones y las reglas de
acción. En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara
una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de
costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que
se debe hacer. Si la administración de la empresa considera factible alguna de las
recomendaciones, el analista sigue adelante. Cada problema de sistemas es único, y
nunca existe sólo una solución correcta. La manera de formular una recomendación o
solución depende de las cualidades y la preparación profesional de cada analista.
4. DISEÑO DEL SISTEMA RECOMENDADO: En la fase de diseño del ciclo de
vida del desarrollo de sistemas, el analista utiliza la información recopilada en las
primeras fases para realizar el diseño lógico del sistema de información. El analista
diseña procedimientos precisos para la captura de datos que aseguran que los datos
que ingresen al sistema de información sean correctos. Además, el analista facilita la
entrada eficiente de datos al sistema de información mediante técnicas adecuadas de
diseño de formularios y pantallas. La concepción de la interfaz de usuario forma
parte del diseño lógico del sistema de información. La interfaz conecta al usuario con
el sistema y por tanto es sumamente importante. Entre los ejemplos de interfaces de
usuario se encuentran el teclado (para teclear preguntas y respuestas), los menús en
pantalla (para obtener los comandos de usuario) y diversas interfaces gráficas de
usuario que se manejan a través de un ratón o una pantalla sensible al tacto. La fase
de diseño también incluye el diseño de archivos o bases de datos que almacenarán
gran parte de los datos indispensables para los encargados de tomar las decisiones en
la organización. Una base de datos bien organizada es el cimiento de cualquier
sistema de información. En esta fase el analista también interactúa con los usuarios
para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de
información de estos últimos. Finalmente, el analista debe diseñar controles y
procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes
de especificaciones de programa para los programadores. Cada paquete debe
contener esquemas para la entrada y la salida, especificaciones de archivos y detalles
21
del procesamiento; también podría incluir árboles o tablas de decisión, diagramas de
flujo de datos, un diagrama de flujo de sistema, y los nombres y funciones de
cualquier rutina de código previamente escrita.
5. DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE: En la quinta fase
del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera conjunta
con los programadores para desarrollar cualquier software original necesario. Entre
las técnicas estructuradas para diseñar y documentar software se encuentran los
diagramas de estructura y el pseudocódigo. El analista se vale de una o más de estas
herramientas para comunicar al programador lo que se requiere programar. Durante
esta fase el analista también trabaja con los usuarios para desarrollar documentación
efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios
Web que incluyan respuestas a preguntas frecuentes en archivos "Léame" que se
integrarán en el nuevo software. La documentación indica a los usuarios cómo
utilizar el software y lo que deben hacer en caso de que surjan problemas derivados
de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan,
codifican y eliminan errores sintácticos de los programas de cómputo. Si el programa
se ejecutará en un entorno de mainframe, se debe crear un lenguaje de control de
trabajos. Para garantizar la calidad, un programador podría efectuar un repaso
estructurado del diseño o del código con el propósito de explicar las partes complejas
del programa a otro equipo de programadores.
6. PRUEBA Y MANTENIMIENTO DEL SISTEMA: Antes de poner el sistema en
funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los
problemas antes que el sistema se entregue a los usuarios. Una parte delas pruebas
las realizan los programadores solos, y otra la llevan a cabo de manera conjunta con
los analistas de sistemas. Primero se realiza una serie de pruebas con datos de
muestra para determinar con precisión cuáles son los problemas y posteriormente se
realiza otra con datos reales del sistema actual. El mantenimiento del sistema de
información y su documentación empiezan en estafase y se llevan a cabo de manera

rutinaria durante toda su vida útil. Gran parte del trabajo habitual del programador
consiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en
esta actividad. Parte del mantenimiento, como las actualizaciones de programas, se
pueden realizar de manera automática a través de un sitio Web. Muchos de los
procedimientos sistemáticos que el analista emplea durante el ciclo de vida del
22
desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se
mantendrá al mínimo. El mantenimiento es un proceso continuo durante el ciclo de
vida de un sistema de información. Después de instalar el sistema de información,
por lo general el mantenimiento consiste en corregir los errores de programación que
previamente no se detectaron. Una vez corregidos estos errores, el sistema alcanza un
estado estable en el cual ofrece un servicio confiable a sus usuarios. El
mantenimiento podría consistir en eliminar algunos errores previamente no
detectados y en actualizar el sistema con algunos cambios menores. Sin embargo,
conforme pasa el tiempo y los negocios y la tecnología cambian, los esfuerzos de
mantenimiento se incrementan de manera considerable.
7. IMPLEMENTACIÓN Y EVALUACIÓN DEL SISTEMA: Ésta es la última fase del
desarrollo de sistemas, y aquí el analista participa en la implementación del sistema
de información. En esta fase se capacita a los usuarios en el manejo del sistema.
Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es
responsabilidad del analista de sistemas. Además, el analista tiene que planear una
conversión gradual del sistema anterior al actual. Este proceso incluye la conversión
de archivos de formatos anteriores a los nuevos, o la construcción de una base de
datos, la instalación de equipo y la puesta en producción del nuevo sistema. Se
menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas
principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante
cada una de las fases. Un criterio clave que se debe cumplir es si los usuarios a
quienes va dirigido el sistema lo están utilizando realmente. Debe hacerse hincapié
en que, con frecuencia, el trabajo de sistemas es cíclico. Cuando un analista termina
una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un
problema podría obligar al analista a regresar a la fase previa y modificar el trabajo
realizado.

c. Caracterización y clasificación del ciclo de vida
Ciclo de vida de un proyecto clásico. ¿Qué es lo que realmente caracteriza el ciclo de
vida de un proyecto como clásico? Se distinguen dos aspectos: una fuerte tendencia a la
implantación ascendente del sistema y la insistencia en la progresión lineal y secuencial
de una fase a la siguiente.
23
Este modelo refleja un desarrollo marcado por la sucesión escalonada de las etapas que
lo componen: requisitos, diseño, codificación, pruebas e integración. Es necesario
terminar por completo cada etapa para pasar a la siguiente Este modelo, identificado ya
a principios de la década de los 50, resulta muy rígido porque cada fase requiere como
elemento de entrada el resultado completo de la anterior. Al aplicarlo en situaciones
reales su rigidez genera problemas, porque muchas veces resulta difícil poder disponer
de requisitos completos o del diseño pormenorizado del sistema en las fases iniciales,
creando una barrera que impide avanzar. Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas ya veteranos en los que el

desconocimiento de las necesidades de los usuarios, o del entorno de
operación no plantea riesgos.
 Sistemas pequeños, sin previsión de evolución a corto plazo. El

modelo prácticamente idéntico, que evita esta rigidez es el de cascada,
que se expone a continuación.

Ciclo de vida Semiestructurado
Desde fines de los años 70 y principios de los 80, ha crecido la tendencia a reconocer al
diseño estructurado, la programación estructurada y la implantación descendente como
parte del ciclo de vida del proyecto. Este reconocimiento ha llevado al ciclo de vida del
proyecto semiestructurado que se muestra en la figura 5.2. Se muestran dos detalles
24
obvios no presentes en el enfoque clásico:
1. La secuencia ascendente de codificación, la prueba de módulos y prueba 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. También hay fuertes indicios de
que la programación estructurada debe usarse como métodos para codificar el
sistema.
2. El diseño clásico se reemplaza por el diseño estructurado, que es un enfoque de
diseño formal de sistemas.
Aparte de estas diferencias obvias, hay algunos detalles sutiles acerca del ciclo de vida
modificado. Por ejemplo, considere que la implantación descendente significa que se
pondrán en ejecución paralelamente parte de la codificación y de las pruebas. Esto
difiere mucho de las fases secuenciales que vimos en el ciclo de vida clásico. En lo
particular, puede darse una retroalimentación entre la codificación, la prueba y la
eliminación de las fallas.
requerimientos del pedido del

usuario hardware
4
1
ESTUDIO
DEL
ENCUESTA
HARDWARE
necesidades de
rendimiento
documento de
factibilidad
datos de
2 especificación configuración
narrativa y de hardware
ANALISIS funcional del
sistema
presupuesto,
calendario
3
plan de pruebas
DISEÑO
requerimiento del ESTRUCTU-
usuario RADO
diseño por 5
paquetes IMPLANTACION
DESCENDENTE
Sistema
Figura 5.2: El ciclo de vida del proyecto semiestructurado

Ciclo de vida estructurado
Ahora que ya hemos visto los ciclos de vida del proyecto clásico y semiestructurado,
estamos listos para examinar el ciclo de vida estructurado.
Examinaremos brevemente las nueve actividades y los tres terminadores del ciclo de
vida del proyecto, como se muestra en la figura 5.4. Los terminadores son los usuarios, 25
administradores y el personal de operaciones. Se trata de individuos o grupos que

proporcionan las entradas al equipo del proyecto, y son los beneficiados finales del
sistema. Ellos interactúan con las nueve actividades que se muestran en la figura 5.4. En
las siguientes secciones se resume cada una de las actividades.
Actividad 1: La encuesta
Esta actividad también se conoce como el estudio de factibilidad o como el estudio
inicial de negocios. Por lo común, empieza cuando el usuario solicita que una o más
partes de su sistema se automaticen. Los principales objetivos de la encuesta son los
siguientes:
- Identificar a los usuarios responsables y crear un “campo de actividad” inicial

del sistema. Esto puede comprender la conducción de una serie de entrevistas
para determinar qué usuarios estarán comprendidos en (o serán afectados por) el
proyecto propuesto. Pudiera también implicar el desarrollo de un diagrama
inicial de contexto, que es un diagrama de flujo de datos sencillo, en el cual se
representa el sistema completo con un solo proceso.

USUARIOS ADMINISTRACIÓN OPERACIONES
política del
usuario
requerimientos restricciones restricciones bases de datos
del sistema operacionales existentes
1.
documento
ENCUESTA especificación
especificación
2. de
estructurada 3.
8.
ANALISIS
diseño CONVERSIÓN
restricciones DISEÑO
DE BASES DE 26
DATOS
informe
especificación
tentativo especificación de diseño
de costo – estructurada
reporte de
beneficio
costo -
beneficio 7. base de
ADMINISTRACIÓN
DESCRIPCIÓN 4. datos
DE PROCEDI- IMPLANTACIÓN
MIENTOS
convertida
5.
GENERACIÓN
DE PRUEBA DE sistema
ACEPTACIÓN integrado
manual
del usuario
conjunto de sistema 9.
aceptado INSTALACIÓN
pruebas de
control de 6.
calidad CONTROL DE
CALIDAD sistema
instalado
Figura 5.4: El ciclo de vida del proyecto estructurado
- Identificar las deficiencias actuales en el ambiente del usuario. Esto en general

comprenderá la lista de funciones que hacen falta o que se están llevando a cabo
insatisfactoriamente en el sistema actual. Por ejemplo, esto pudiera incluir
declaraciones como las siguientes:
o El tiempo de respuesta del sistema telefónico de pedidos actual es tan
malo que muchos clientes cuelgan frustrados antes de hacer su pedido.
o El sistema actual no es capaz de producir los informes requeridos por la
modificación a los impuestos decretada el año anterior.
o El sistema actual no es capaz de recibir los informes sobre límites de
crédito del departamento de contabilidad, y no puede producir lo
informes de promedio de volumen de pedidos que requiere el
departamento de mercadotecnia.
- Establecer metas y objetivos para un sistema nuevo. Esto puede ser también una
simple lista narrativa que contenga las funciones existentes que deben
reimplantarse, las nuevas que necesitan añadirse y los criterios de desempeño del
nuevo sistema.
- Determinar si es factible automatizar el sistema y de ser así, sugerir escenarios
aceptables. Esto implicará algunas estimaciones bastante rudimentarias y

aproximadas del costo y el tiempo necesarios para construir un sistema nuevo y
los beneficios que se derivarán de ello; también involucrará dos o más
escenarios. Aunque a estas alturas la administración y los usuarios usualmente
querrán una estimación precisa y detallada, el analista tendrá mucha suerte si
logra determinar el tiempo, los recursos y los costos con un error menor del 50%
27
en esta etapa tan temprana del proyecto.
- Preparar el esquema que se usará para guiar el resto del proyecto. Este
esquema incluirá toda la información que se lista anteriormente, además de
identificar al administrador responsable del proyecto. También pudiera describir
los detalles del ciclo de vida que seguirá el resto del proyecto.
En general, la encuesta ocupa sólo del 5 al 10 por ciento del tiempo y los recursos de
todo el proyecto, y para los proyectos pequeños y sencillos pudiera ni siquiera ser una
actividad formal. Sin embargo, aun cuando no consuma mucho del tiempo y de los
recursos del proyecto, es una actividad verdaderamente importante: al final de la
encuesta, la administración pudiera decidir cancelar el proyecto si no parece atractivo
desde el punto de vista de costo – beneficio.
Actividad 2: El análisis de sistemas

El propósito principal de la actividad de análisis es transformar sus dos entradas o
insumos o factores principales, las políticas del usuario y el esquema del proyecto, en
una especificación estructurada. Esto implica modelar el ambiente del usuario con
diagramas de flujo de datos, diagramas de entidad – relación, diagramas de transición de
estado y demás herramientas
El proceso paso a paso del análisis de sistemas implica el desarrollo de un modelo

ambiental y el desarrollo de un modelo de comportamiento. Estos dos modelos se
combinan para formar el modelo esencial que representa una descripción formal de lo
que el nuevo sistema debe hacer, independientemente de la naturaleza de la tecnología
que se use para cubrir los requerimientos.
Además, del modelo del sistema que describe los requerimientos del usuario,
generalmente se prepara un conjunto de presupuestos y cálculos de costos y beneficios
más precisos y detallados al final de la actividad de análisis. Obviamente, como analista
del sistema, en esto pasará la mayor parte de su tiempo.

Actividad 3: el diseño
La actividad de diseño se dedica a asignar porciones de la especificación (también
conocida como modelo esencial) a procesadores adecuados (sean máquinas o humanos)
y a labores apropiadas (o tareas, particiones, etc.) dentro de cada procesador. Dentro de
cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de
28
módulos de programas y de interfaces entre ellos para implantar la especificación creada
en la actividad 2. Además, la actividad de diseño se ocupa de la transformación de
modelos de datos de entidad – relación en un diseño de base de datos.
Parte de esta actividad le interesará como analista: el desarrollo de algo conocido como
el modelo de implantación del usuario. Este modelo describe los asuntos relacionados
con la implantación que le importan al usuario al grado de que no se los quiere confiar a
los diseñadores y programadores. Los asuntos principales que suelen preocupar al
usuario son aquellos relacionados con la especificación de la frontera humano –
máquina y la especificación de la interfaz hombre – máquina. Esa frontera separa las
partes del modelo esencial que llevará a cabo una persona (como actividad manual), de
las partes que se implantarán en una o más computadoras. De manera similar, la interfaz
hombre – máquina es una descripción del formato y de la secuencia de entradas que los
usuarios proporcionan a la computadora (por ejemplo, el diseño de pantallas y el
diálogo en línea entre el usuario y la computadora), además del formato y secuencia de
salidas – o productos – que la computadora proporciona al usuario.
Actividad 4: implantación
Esta actividad incluye la codificación y la integración de módulos en un esqueleto

progresivamente más completo del sistema final. Por eso, la actividad 4 incluye tanto
programación estructurada como implantación descendente.
Como podrá imaginar, el analista típicamente no se verá involucrado en esta actividad,

aunque hay algunos proyectos (y organizaciones) donde el análisis, el diseño y la
implantación de sistemas los hace la misma persona.
Actividad 5: generación de pruebas de aceptación

La especificación estructurada debe contener toda la información necesaria para definir
un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez

generada la especificación, puede comenzar la actividad de producir un conjunto de
casos de prueba de aceptación desde la especificación estructurada.
Dado que el desarrollo de las pruebas de aceptación puede suceder al mismo tiempo que
las actividades de diseño e implantación, pudiera ser que al analista le sea asignada esta
labor al término del desarrollo del modelo esencial en la actividad 2. 29
Actividad 6: garantía de calidad

La garantía de calidad también se conoce como la prueba final o la prueba de
aceptación. Esta actividad requiere como entradas los datos de la prueba de aceptación
generada en la actividad 5 y el sistema integrado producido en la actividad 4.
El analista pudiera estar involucrado con la actividad de garantía de calidad, pero por lo
regular no lo está. Pueden tomar la responsabilidad uno o más miembros de la
organización usuaria, o pudiera llevarla a cabo un grupo independiente de prueba o un
departamento de control de calidad.
Nótese, por cierto, que algunas personas le llaman a esta actividad “control de calidad”
en lugar de “garantía de calidad”. Sin importar la terminología, se necesita una actividad
que verifique que el sistema tenga un nivel apropiado de calidad. Nótese también que es
importante llevar a cabo actividades de garantía de calidad en cada una de las
actividades anteriores para asegurar que se hayan realizado con un nivel apropiado de
calidad. Por eso, se esperaría que esto se haga durante toda la actividad de análisis,
diseño y programación para asegurar que el analista esté desarrollando especificaciones
de alta calidad, que el diseñador esté produciendo diseños de alta calidad y que el
programador este escribiendo códigos de alta calidad. La actividad de garantía de
calidad que se menciona aquí es simplemente la prueba final de la calidad del sistema.
Actividad 7: descripción del procedimiento

Desde un principio nos preocupamos por el desarrollo de un sistema completo: no sólo
de la porción automatizada, sino también de la parte que llevarán a cabo las personas.
Por ello, una de las actividades importantes a realizar 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 interactuarán los usuarios con la parte automatizada del
nuevo sistema. El resultado de la actividad 7 es un manual para el usuario.

Como podrá imaginar, esta también es una actividad en la que pudiera verse
involucrado como analista.
Actividad 8: conversión de bases de datos

En algunos proyectos, la conversión de bases de datos involucraba más trabajo (y más
planeación estratégica) que el desarrollo de programas de computadora para el nuevo 30
sistema. En otros casos, pudiera no haber existido una base de datos que convertir. En el
caso general, esta actividad requiere como entrada la base de datos actual del usuario, al
igual que la especificación del diseño producida por medio de la actividad 3.
Según sea de la naturaleza del proyecto, el analista podría tener que ver con la actividad
de la conversión de la base de datos.
Actividad 9: instalación
La actividad final, desde luego, es la instalación; sus entradas son el manual de usuario
producido en la actividad 7, la base de datos convertida que se creó con actividad 8 y el
sistema aceptado producido por la actividad 6. En algunos casos, sin embargo, la
instalación pudiera significar simplemente un cambio de la noche a la mañana al nuevo
sistema, sin mayor alboroto; en otros casos, la instalación pudiera 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.
Resumen del ciclo de vida del proyecto estructurado

Es importante ver la figura 5.4 como lo que es: un diagrama de flujo de datos. No es un
diagrama de flujo; nada implica que toda la actividad N debe concluir antes de
comenzar la actividad N + 1. Por el contrario, la red de flujos de datos que conectan las
actividades hace ver con claridad que pudieran estarse llevando a cabo diversas
actividades paralelamente. Debido a este aspecto no secuencial, usamos la palabra
actividad en el ciclo de vida del proyecto estructurado en lugar de “fase”, que es más
convencional. El término fase tradicionalmente se refiere a un período particular en un
proyecto en el cual se estaba desarrollando una, y sólo una, actividad.
En resumen, la figura 5.4 sólo señala la o las entradas requeridas por cada actividad, y la
o las salidas o productos que se generan. La secuencia de las actividades sólo puede
suponerse en la medida en que la presencia o ausencia de datos haga posible comenzar
una determinada actividad.

i. Ciclo de vida de prototipos
En general se le conoce como el enfoque de prototipos y lo popularizaron Bernard Boar,
James Martin y otros. Como lo describe Boar [Boar, 1984]:
Una alternativa de enfoque para la definición de los requerimientos

consiste en capturar un conjunto inicial de necesidades e implantarlas 31
rápidamente con la intención declarada de expandirlas y refinarlas

iterativamente al ir aumentando la comprensión que del sistema tienen el
usuario y quien lo desarrolla. La definición del sistema se realiza mediante
el descubrimiento evolutivo y gradual y no a través de la previsión
omnisciente… Este tipo de enfoque se llama “de prototipos”. También se
le conoce como modelado del sistema o desarrollo heurístico. Ofrece una
alternativa atractiva y practicable a los métodos de especificación para
tratar mejor la incertidumbre, la ambigüedad y la volubilidad de los
proyectos reales.
A menudo un cliente define un conjunto de objetivos generales para el software que no

identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el
responsable del desarrollo del software esta inseguro de la eficacia de un algoritmo, de
la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción
humano-maquina. En éstas, y muchas otras situaciones, un paradigma de construcción
de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos se inicia con la comunicación. El ingeniero
de software y el cliente encuentran y definen los objetivos globales para el software,
identificando los requisitos conocidos y las áreas del esquema en donde es necesaria
más definición. Entonces se plantea con rapidez una iteración de construcción de
prototipos y se presenta el modelado (en forma de diseño rápido). El diseño rápido se
centra en una representación de aquellos aspectos del software que serán visibles para el
cliente o el usuario final. El diseño rápido conduce a la construcción de un prototipo.
Después, el prototipo lo evalúa el cliente/usuario y con la retroalimentación se refinan
los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se
ajusta para satisfacer las necesidades del cliente. Eso permite que al mismo tiempo el
desarrollador entienda mejor lo que se debe hacer.

De manera ideal, el prototipo debería servir como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta
emplear los fragmentos del programa existentes o aplica herramientas que permiten
producir programas de trabajo con rapidez.
Hay una pregunta, ¿qué hacer con el prototipo una vez cumplido el propósito descrito?
32
El prototipo puede servir como “primer sistema”, se recomienda desechar. Pero esta tal
vez sea una visión idealizada. Es verdad que a los clientes y desarrolladores les gusta el
paradigma de construcción de prototipos. A los usuarios les gusta el sistema real y a los
desarrolladores les gusta construir algo de inmediato. Sin embargo, la construcción de
prototipos también se torna problemática por las siguientes razones:
1- El cliente ve lo que parece una versión en funcionamiento del
software, sin saber que el prototipo está unido “con chicle y cable
para embalaje” que por la prisa de hacerlo funcionar no se ha
considerado la calidad del software global o la facilidad de
mantenimiento a largo plazo. Cuando se informa que el producto
debe construirse otra vez para mantener los altos niveles de
calidad, el cliente no lo entiende y pide la aplicación de unos
pequeños ajustes para que se pueda elaborar un producto final de
“unos pequeños ajustes” para que se pueda elaborar un producto
final a partir del prototipo.
2- A menudo, el desarrollador establece compromisos de
implementación para lograr que el prototipo funcione con
rapidez. Tal vez se utilice un sistema operativo o un lenguaje de
programación inadecuado solo porque está disponible y
conocido; se puede implementar un algoritmo ineficiente solo
para mostrar capacidad.
A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un
paradigma efectivo para la ingeniería del software. La clave es definir las reglas del
juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo
en que el prototipo se construya y sirva como un mecanismo para la definición de
requisitos, en que se descarte, al menos en parte, y en que después se desarrolle el
software real con un enfoque hacia la calidad.

33
ii. Implantación radical vs implantación descendente conservadora

El ciclo de vida del proyecto estructurado permite que más de una actividad se lleve a
cabo a la vez. Pongámoslo de otra manera: en la situación más extrema, todas las
actividades del ciclo de vida estructurado pudieran estarse realizando simultáneamente.
En el otro extremo, el administrador del proyecto pudiera decidir adoptar el enfoque
secuencial, que implica terminar completamente una actividad antes de emprender la
siguiente.
Es conveniente tener terminología para discutir estos extremos así como los términos
medios entre ellos. El enfoque radical del ciclo de vida del proyecto estructurado es
aquel en el que las actividades 1 a 9 se llevan a cabo paralelamente desde el principio
del proyecto: la codificación se inicia el primer día del proyecto, y la encuesta y el
análisis continúan hasta el último. En cambio, en el enfoque conservador del ciclo de
vida del proyecto estructurado, la actividad N completa se termina antes de comenzar
con la actividad N + 1.
Obviamente, ningún administrador en sus cabales adoptaría cualquiera de estos dos

extremos. La clave para reconocer esto consiste en que los extremos radical y
conservador definidos anteriormente son los puntos extremos de una gama de opciones;
esto se ilustra en la figura 5.5. Existe un infinito número de opciones entre los extremos
radical y conservador. Un administrador de proyecto pudiera decidir terminar el 75% de

la actividad de encuesta, seguido por la terminación del 75% del análisis del sistema, y
luego del 75% del diseño para poder producir un esqueleto razonable de un sistema
cuyos detalles pudieran posteriormente refinarse al pasar por segunda vez por el ciclo de
vida entero del proyecto. O bien, el administrador pudiera decidir terminar todas las
actividades de encuesta y de análisis, seguido por la terminación del 50% del diseño y el
34
50% de la implantación. Las posibilidades son interminables.
ULTRA MODERADAMENTE MODERADAMENTE ULTRA

RADICAL RADICAL CONSERVADOR CONSERVADOR
Figura 5.5: Elecciones de implantación radical y conservadora
En resumen, el enfoque radical es el más adecuado para intentos apenas disfrazados de

investigación y desarrollo, en los que nadie está muy seguro de qué es lo que se supone
que debe hacer el sistema final. Y es bueno para los casos en los que para determinada
fecha algo tiene que estar ya funcionando, y en situaciones en las que la percepción del
usuario respecto a lo que desea que el sistema haga esté sujeta a posibles cambios. El
enfoque conservador, por otro lado, suele usarse en proyectos más grandes, en los que
se invierten cantidades enormes de dinero y para los cuales se requiere un análisis y
diseño muy detallados para evitar desastres subsecuentes. Sin embargo, cada proyecto
es diferente y requiere de su propia combinación de implementación descendente
conservadora y radical. Para tratar la naturaleza individual de cada proyecto, el
administrador debe estar dispuesto a modificar su enfoque en mitad del camino si es
necesario.
Enriquecer conocimiento leyendo el libro Análisis Estructurado Moderno de Edward

Yourdon pagina 105 al 108.
iii. Ciclo de vida en espiral

Este ciclo puede considerarse una variación del modelo con prototipado, fue diseñado
por Boehm en el año 1988. El modelo se basa en una serie de ciclos repetitivos para ir
ganando madurez en el producto final. A medida que el ciclo se cumple (el avance del
espiral), se van obteniendo prototipos sucesivos que van ganando la satisfacción del
cliente o usuario.

A menudo, la fuente de incertidumbres es el propio cliente o usuario, que en la mayoría
de las oportunidades no sabe con perfección todas las funcionalidades que debe tener el
producto.
Boehm describe este modelo de la siguiente manera:
El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el
35
riesgo que se emplea para conducir sistemas intensivos de ingeniería de software
concurrente y con múltiples usuarios. Tiene dos características distintivas principales.
Una de ellas es un enfoque cíclico para el crecimiento incremental del grado de
definición e implementación de un sistema, mientras disminuye su grado de riesgo. La
otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con
soluciones de sistema que sean factibles y mutuamente satisfactorias.
Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas
evolutivas. Durante las primeras iteraciones, la entrega tal vez será un documento del
modelo o un prototipo. Durante las últimas interacciones se producen versiones cada
vez más completas del sistema desarrollado.
Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que
define el equipo de ingeniería de software. Cada una de las actividades representa un
segmento de la ruta en espiral que se presenta en la figura. Cuando empieza este proceso
evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor
del espiral que tiene una dirección en el sentido del mantenimiento de las manecillas del
reloj, y se inicia desde el centro. El riesgo es un factor considerado en cada revolución.
Los puntos de fijación una combinación de productos de trabajo y condiciones incluidas
a lo largo de la ruta de la espiral – se considera para cada paso evolutivo.
El primer circuito alrededor de la espiral quizá genere el desarrollo de una
especificación del producto; los pasos subsecuentes alrededor de la espiral se pueden
aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más
elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes
el plan del proyecto. Los costos y el itinerario se ajustan con base en la
retroalimentación derivada de la relación con el cliente después de la entrega.
Además, el administrador del proyecto ajusta el número de iteraciones planeado que se
requiere para completar el software.

A diferencia de otros modelos de proceso que termina cuando se entrega el software, el
modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas
a gran escala. Como el software evoluciona conforme avanza el proceso, el
36
desarrollador y el cliente entienden y reaccionan de mejor manera antes los riesgos en
cada etapa evolutiva. El modelo en espiral emplea la construcción del prototipo como
un mecanismo encaminado a reducir riesgos pero, en forma más importante permite al
desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier
etapa evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere
el ciclo de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de
forma más verídica el mundo real. Este modelo exige una consideración directa de los
riesgos técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe
reducir los riesgos antes de que se vuelvan problemáticos.
En este modelo hay cuatro actividades que envuelven a las etapas.
 Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.
 Análisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos

si continuamos con el desarrollo.
 Implementación: desarrollamos un prototipo basado en los requerimientos.
 Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el

proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por
el cliente en la siguiente iteración.

37
iv. Ciclo de Vida Evolutivo

Este modelo está compuesto por varios ciclos de desarrollo. Cada uno de ellos produce
un sistema completo con el que se operará en el entorno de operación. La información
acumulada en el desarrollo de cada sistema, y durante su fase de operación sirve para
mejorar o ampliar los requisitos y el diseño del siguiente. En realidad es un ciclo de vida

común a todos los sistemas desarrollados que se mejoran a través de versiones
sucesivas.
Las circunstancias en las que este modelo puede resultar apropiado son:
 Desconocimiento inicial de todas las necesidades operativas que serán
precisas, generalmente por tratarse del desarrollo de un sistema que
38
operará en un entorno nuevo sin experiencia previa.
 Necesidad de que el sistema entre en operación en tiempos inferiores a
los que serían necesarios para diseñarlo y elaborarlo de forma exhaustiva.
 Necesidad de desarrollar sistemas en entornos cambiantes (sujetos a
normas legislativas, mejora continua del producto para hacer frente a
desarrollos de la competencia, etc.).
v. Ciclo de vida en cascada con subproyectos
El Modelo de Ciclo de Vida Cascada con Subproyectos divide el proyecto en subetapas

para desarrollar en paralelo las diferentes etapas del modelo de ciclo de vida
en Cascada. Suele usarse mucho cuando se cuenta con un plantel de programadores
numerosos. Es útil por el número de personas trabajando, pero puede detenerse el
proyecto temporalmente por la dependencia entre las subetapas.

39
vi. Ciclo de Vida en V y tipo Sashimi.

El Modelo de Ciclo de Vida en V basado en el de Cascada, le agregó una subetapa de
retroalimentación entre el análisis y el mantenimiento y otra entre el diseño y el
debugging. El ciclo de vida diseñado porAlan Davis facilita la corrección y por tal razón
es muy aconsejable su uso para desarrollo de software simple pero donde se necesita
una confiabilidad muy alta.

vii. Ciclo de vida tipo Sashimi
El Modelo de Ciclo de Vida Sashimi permite un solapamiento entre las fases
disminuyendo la generación de la documentación, pero es mucho más dificil controlar
el proyecto pues los puntos al final de cada fase no son referencia y si no existe una
buena comunicación pueden surgir inconsistencias en el desarrollo.
40
Modelo de Ciclo de Vida Sashimi
viii. Ciclo de vida orientado a objetos

Esta técnica fue presentada en la década de los 90, tal vez como una de las
mejores metodologías a seguir para la creación de productos software.
Puede considerarse como un modelo pleno a seguir, como así también una alternativa
dentro de los modelos anteriores.
Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta
metodología cada funcionalidad, o requerimiento solicitado por el usuario, es
considerado un objeto.
Los ciclos de vida clásicos se centran en el proyecto, el desarrollo orientado a objetos se
basa en el producto, no comprende los procesos como funciones sino que arma módulos
basados en componentes, es decir, cada componente es independiente del otro y se

relacionan entre ellos a través de interfaces, son más modulares y se dividen en
miniproyectos lo cual permiten que el código sea reutilizable.
Es más fácil de mantener porque los cambios están localizados en cada uno de estos
componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho
más fácil agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene.
41
Debido a todo esto se considera que el ciclo de vida orientado a objetos es iterativo e
incremental.
A continuación veremos un tipo de ciclo de vida orientado a objetos más conocidos, que
es además el más representativo, el modelo fuente.
Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida
pensado para la orientación a objetos y posiblemente el más seguido.
Un proyecto se divide en las fases:
1. Planificación del negocio
2. Construcción: Es la más importante y se divide a su vez en otras cinco
actividades
 Planificación
 Investigación
 Especificación
 Implementación
 Revisión
3. Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo

orientado a objetos. Además de las tres fases, existen dos periodos:
 Crecimiento: Es el tiempo durante el cual se construye el sistema
 Madurez: Es el periodo de mantenimiento del producto. Cada mejora se

planifica igual que el periodo anterior, es decir, con las fases de Planificación del
negocio, Construcción y Entrega.

Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar
en una fase diferente en un momento cualquiera. La ventaja es que permite un
desarrollo solapado e iterativo. En la figura se muestra un esquema de este tipo de ciclo
de vida.
42
d. Consideraciones en el desarrollo de sistemas

Como analista de sistemas, formará parte de un equipo de personas cuyo propósito es
desarrollar un sistema de información útil y de alta calidad, que cubrirá las necesidades
del usuario final. Al llevar a cabo su trabajo, usted y sus compañeros miembros del
equipo sin duda se verán influenciados por las siguientes importantes cuestiones:
o Productividad
o Confiabilidad
o Mantenibilidad
Desde luego, todo mundo está a favor de la productividad; es un término utilizado de
igual forma que la maternidad y la lealtad a la patria. Pero hace una generación, cuando
se estaban creando la mayoría de los sistemas operativos, la productividad no era algo a
lo que se hiciera mucho caso. Los analistas y programadores de los años 60 trabajaban
largas horas (aunque no siempre en horarios predecibles), pero nadie estaba seguro
jamás de cuánto trabajo lograrían hacer en una semana, o cuánto les tomaría construir
un sistema completo. El sentir común era que el equipo de desarrollo del proyecto
trabajaría Muy Duro cada día, y un día el sistema quedaría terminado.

Hoy en día, la productividad es un asunto mucho más serio. Asimismo lo es el asunto de
la confiabilidad: una falla del sistema en un sistema grande y complejo probablemente
tendría consecuencias devastadoras. Y la mantenibilidad se ha convertido en un asunto
de importancia también: ahora es claro que muchos de los sistemas construidos hoy
deberán durar por lo menos 20 años o más antes de que puedan volverse a construir, y
43
tendrán que someterse a constantes revisiones y modificaciones durante su existencia.
Cada uno de estos asuntos se explora con más detalle a continuación. Algunos, como el
asunto del mantenimiento, aparentan tener poco o nada que ver con el análisis de
sistemas, pero, como se verá, el analista juega un papel crucial en el logro de la
productividad mejorada, una mayor confiabilidad y mejor mantenibilidad.
PRODUCTIVIDAD: EL RETRASO EN LAS APLICACIONES

Tal vez el problema más visible al que se enfrenta actualmente la profesión de
desarrollo de sistemas sea el de la productividad. La sociedad y los negocios modernos
parecen exigir cada vez más: más sistemas, más complejidad y todo más rápido. Como
analista, verá los dos principales aspectos de este problema: el retraso en los nuevos
sistemas que se necesita desarrollar, y el tiempo que se requiere para construir un
sistema individual nuevo.
En casi cualquier organización donde exista un grupo centralizado responsable del

desarrollo de nuevos sistemas, existe un retraso de varios años de trabajo en espera de
que se le lleve a cabo; de hecho, muchas organizaciones tienen un retraso de cuatro a
siete años o más. El retraso se presenta en tres tipos diferentes:
 Retraso visible. Sistemas nuevos que los usuarios han pedido oficialmente y que han
sido aprobados y financiados por comités apropiados de administración. Sin
embargo, los proyectos no se han iniciado porque no existen los recursos adecuados
(esto es, analistas, programadores, etc.).
 Retraso invisible. Existen sistemas nuevos que los usuarios saben que necesitan,
pero no se han molestado en pedirlos “oficialmente”, porque aún están aguardando a
que se concluyan proyectos del retraso visible.
 Retraso desconocido. Estos son sistemas nuevos que los usuarios ni siquiera saben
que quieren todavía, pero que serán identificados en cuanto se termine alguno de los
sistemas del retraso visible o del invisible.

El problema de la productividad ha existido por muchos años en la profesión de
desarrollo de sistemas, y muchas organizaciones están buscando de manera agresiva la
forma de reducir radicalmente su retraso en las aplicaciones y disminuir el tiempo
requerido para desarrollar un nuevo sistema.
CONFIABILIDAD 44
Otro gran problema al que se enfrentan los que desarrollan sistemas es el de la

confiabilidad. El largo tiempo que se invierte en la prueba y la corrección de errores,
típicamente un 50 por ciento de desarrollo de un sistema, y la muy poca productividad
(que muchos sienten que se relaciona con el tiempo que se invierte en probar) pudieran
ser aceptables si el resultado fuesen sistemas altamente confiables y fácilmente
mantenibles. La evidencia de los últimos 30 años es justo lo contrario: los sistemas
productivos por las organizaciones en todo el mundo están llenos de errores y son casi
imposibles de modificar.
Los errores de software van desde los sublimes hasta los ridículos. Un error trivial
pudiera consistir en salidas (resultados) correctas, pero que no se imprimen o presentan
tan bien como el usuario desearía. Un error moderadamente serio pudiera ser un caso en
el cual el sistema se rehúsa a reconocer ciertos tipos de entradas, pero el usuario final
puede hallar alguna forma de saltar el problema. Los errores serios son aquellos que
ocasionan que todo el programa deje de funcionar, con una pérdida asociada de dinero o
de vidas humanas. Algunos ejemplos serios relacionados con software que se han ido
documentando en el transcurso de los años son los siguientes:
 En 1979, el sistema SAC/NORAD (siglas en inglés de Comando Aéreo Estratégico /

Defensa Aérea Norteamericana) registró 50 falsas alarmas, incluyendo un ataque
simulado, cuyos resultados o salidas comenzaron accidentalmente una “escaramuza”
en vivo.
 Un error en el programa simulador de vuelo del F16 hacía que el avión volara en
posición invertida (cabeza abajo), cada vez que cruzaba el ecuador.
 Un proyectil F18 comenzó su propulsión estando todavía unido al avión e hizo que
éste perdiera 6.000 metros de altitud.
 Las puertas del sistema de trenes BART, controlado por computadora en San
Francisco, se abren a veces en tramos largo entre estaciones.

 Una señal de alerta NORAD, del Sistema de Advertencia Rápida de Proyectiles
Balísticos (BMEWS), detectó a la Luna como un proyectil que llegaba.
 El índice de la Bolsa de Vancouver perdió 574 puntos en un período de 22 meses
debido a redondeos (por ejemplo, redondear 3.14159 a 3.1416)
 El 28 de noviembre de 1979, un avión de Air New Zealand se estrelló en una
45
montaña. Las investigaciones posteriores mostraron que se había detectado y
corregido un error en los datos de curso de la computadora, pero que jamás se
informó de esto al piloto.
Desafortunadamente, la lista sigue y sigue. Muchos errores de software jamás se
reportan porque el individuo o la organización “culpables” preferirían no admitirlo
públicamente.
En muchos casos, nadie está muy seguro respecto a cuántos errores tiene un sistema,
pues 1) algunos errores jamás se encuentran antes de que caduque el sistema y, 2) el
proceso de documentación y registro de errores es tan descuidado que la mitad de los
errores encontrados no se reportan, aun dentro de la organización misma de desarrollo
de sistemas. En cualquier caso, el fenómeno típico de descubrimiento de errores, en un
período de varios años de utilidad de un sistema de software, usualmente toma la forma
mostrada en la figura 6.1.
La forma de esta curva recibe influencias de buen número de factores. Por ejemplo,
cuando el sistema se entrega por primera vez a los usuarios finales. A menudo no
pueden ponerlo a trabajar a su máxima capacidad. Lleva tiempo convertir su sistema
anterior (que pudiera haber sido un sistema manual) y capacitar a su personal. Además,
desconfían un poco de la computadora y no la quieren usar demasiado, por lo que se
descubren pocos errores. Al convertir su operación anterior al nuevo sistema, a medida
que su personal operacional ya está mejor preparado y que dejan sentirse intimidados,
empiezan a usar más el software y se encuentran cada vez más errores. Desde luego, si
esto continuara indefinidamente, si se encontraran cada día más errores, los usuarios
finalmente dejarían de usar el software y lo desecharían. En la mayoría de los casos, los
programadores arreglan frenéticamente nuevos errores al irlos descubriendo los
usuarios. En la mayoría de los casos, llega un momento en el cual el sistema empieza a
estabilizarse y los usuarios encuentran cada vez menos errores.

46
Figura 6.1. Errores descubiertos como función del tiempo
Existen tres aspectos deprimentes en la figura 6.1. Primero, la curva jamás regresa a
cero; es decir, casi nunca encontramos una situación donde transcurra el tiempo sin
encontrar nuevos errores. Segundo, el área bajo la curva, que representa el número total
de errores descubiertos en función del tiempo, es atrozmente grande; su promedio es de
tres a cinco errores por cada cien instrucciones del programa. Y, tercero, la curva
finalmente comienza a subir de nuevo, por lo común después de varios años. Por último,
todos los sistemas de software llegan a un estado de parchado tal que cualquier intento
de eliminar un error introduce otros dos nuevos y las modificaciones necesarias para
eliminarlos introducirán cuatro, y así en adelante.
MANTENIBILIDAD
La corrección de errores sobre la marcha es un aspecto del mantenimiento. El
mantenimiento también involucra la modificación de un sistema para reflejar cambios
en el hardware, modificaciones para apresurar ciertos aspectos operacionales o
modificaciones para reflejar cambios en los requerimientos del usuario final del sistema.
El mantenimiento de software es un problema primordial en muchas organizaciones,

entre el 50 y el 80 por ciento del trabajo que se hace en la mayoría de las organizaciones
de desarrollo de sistemas se asocia con la revisión, modificación, conversión,
mejoramiento o corrección de errores en algún programa de computadora que otra
persona escribió hace mucho. Y es caro: a comienzos de los años 70, la Secretaría de la
Defensa de Estados Unidos informó que el costo promedio de desarrollar programas de
computadora en un proyecto era de 75 dólares por instrucción de computadora; el costo
de mantener el sistema llegaba hasta los 4.000 dólares por instrucción.

Si fuera simplemente un caso de que el software fuese malo, se podría considerar
desecharlo o reemplazarlo. Pero muchas organizaciones jamás han capitalizado su
software (los costos se determinan cada año), y sus políticas de administración y de
negocios hacen que se vuelva prohibitivamente caro reemplazar los sistemas antiguos.
Y existe un problema aún más fundamental: en la mayoría de las organizaciones, no
47
existe una descripción coherente de lo que se supone que los sistemas deben hacer. La
documentación existente suele ser obsoleta y confusa. En cualquier caso, proporciona,
cuando más, alguna idea de cómo funciona el software, pero no de cuál es su propósito
fundamental, o qué política de negocios se supone que debe realizar.
Por eso, aunque se pueda argumentar que la mantenibilidad es enteramente función de

la implantación (es decir, algo que preocupa a los programadores), es imposible
mantener un sistema si no existe un modelo preciso y actualizado de sus requerimientos.
Esto, a fin de cuentas, es labor del analista. Las especificaciones funcionales
desarrolladas por los analistas han progresado gradualmente, desde novelas victorianas
absolutamente inmantenibles (miles de hojas de texto narrativo) a modelos gráficos del
sistema hechos a mano, y hasta modelos generados y mantenidos por computadora.

Bibliografía
 YOURDON, E. (1993). ANÁLISIS ESTRUCTURADO MODERNO. 1ra.
Edicion. México. Prentice-Hall Hispanoamericana, S.A..
 Pressman, R. (2005, 2002). Ingenieria del Software – Un enfoque práctico. 48
Sexta edición. México. McGraw-Hill.
 Kendall y Kendall (1997). Análisis y Diseño de Sistemas Tercera edición.

México. Prentice Hall Hispanoamericana,S.A.
 Schach, S. (2006). Análisis y diseño orientado a objetos. Sexta edición. México:
McGraw-Hill
 Hawryszkiewycz, I.T. (1990) “Introducción al análisis y diseño de sistemas con
ejemplos prácticos”, Madrid. Anaya
Links consultados
recuperado de
file:///C:/Users/hp/Downloads/guia_de_ingenieria_del_software.pdf
recuperado de http://es.slideshare.net/GUEOVANNY20/ciclos-de-vida-del-
software-13742188
recuperado de http://maestria-modulo7.blogspot.com/2012/05/ciclo-de-vida-
orientado-objetos-vs.html
recuperado de http://ciclodevidasoft.blogspot.com/2012/07/modelos.html

Introduccion Al Analisis de Sistemas Modulo II PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introduccion Al Analisis de Sistemas Modulo II PDF

Cargado por

Copyright:

Formatos disponibles

Fuente: http://www.masingenieros.com/wp-content/uploads/2013/10/19338503_xl.

Prof. Cynthia Rivas Aquino

ii. Definición de objetivos

Prof. Cynthia Rivas Aquino

iii. Obtención de soluciones alternativas

iv. Determinar la viabilidad de un proyecto propuesto

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

Viabilidad económica: La viabilidad económica es la segunda parte de la

Prof. Cynthia Rivas Aquino

ii. Estrategias de búsqueda

Prof. Cynthia Rivas Aquino

iii. Fuente de información

Prof. Cynthia Rivas Aquino

iv. Procedimiento de búsqueda

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

A continuación se muestra un listado de las tareas principales realizadas. (Favor si

1- Empiezan las entrevistas de nivel superior para determinar las principales

2- Desarrolla un modelo de nivel superior del sistema.

3- Verifica el modelo de nivel superior.

4- Entrevistas con el personal de operaciones. Examen detallado de

5- Expande el modelo de nivel superior en sus componentes detallados.

6- Verifica el modelo detallado.

7- Revisión técnica formal del modelo.

Prof. Cynthia Rivas Aquino

Esta debe efectuarse de forma organizada y amistosa. El entrevistador siempre será

Prof. Cynthia Rivas Aquino

1 – Elegir a la persona a entrevistar. Es importante, así que el analista debe asegurarse

El plan de entrevista para cada usuario

Prof. Cynthia Rivas Aquino

encerradas en rectángulos blancos pertenecen al camino crítico.

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

4. TIPOS DE CICLO DE VIDA

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

Prof. Cynthia Rivas Aquino

 Desarrollar nuevas versiones de sistemas ya veteranos en los que el

 Sistemas pequeños, sin previsión de evolución a corto plazo. El

Prof. Cynthia Rivas Aquino

1. La secuencia ascendente de codificación, la prueba de módulos y prueba del

requerimientos del pedido del

Figura 5.2: El ciclo de vida del proyecto semiestructurado

Prof. Cynthia Rivas Aquino

administradores y el personal de operaciones. Se trata de individuos o grupos que

- Identificar a los usuarios responsables y crear un “campo de actividad” inicial

Prof. Cynthia Rivas Aquino

Figura 5.4: El ciclo de vida del proyecto estructurado

- Identificar las deficiencias actuales en el ambiente del usuario. Esto en general

Prof. Cynthia Rivas Aquino

Actividad 2: El análisis de sistemas

El proceso paso a paso del análisis de sistemas implica el desarrollo de un modelo

Prof. Cynthia Rivas Aquino

Esta actividad incluye la codificación y la integración de módulos en un esqueleto

Como podrá imaginar, el analista típicamente no se verá involucrado en esta actividad,

Actividad 5: generación de pruebas de aceptación

Prof. Cynthia Rivas Aquino

Actividad 6: garantía de calidad