Unidad Ii Relevamiento de Datos: Lic. Viviane Oliveira - Introducción Al Análisis de Sistemas - Unidad 2

UNIDAD II
Relevamiento de Datos
Lic. Viviane Oliveira – Introducción al Análisis de Sistemas – Unidad 2

UNIDAD II: RELEVAMIENTO DE DATOS
Relevamiento de datos: definición y caracterización.
OBJETIVO DE APRENDIZAJE
 Definir Proyectos de Sistemas
 Distinguir las diferentes metodologías para el relevamiento de datos
 Determinar los procesos de Planificación y control de actividades de un
proyecto
 Establecer la Viabilidad de un proyecto
 Identificar El ciclo de vida de un proyecto de sistemas
 Reconocer algunas consideraciones para el desarrollo de sistemas.
INTRODUCCIÓN DE UNIDAD DE APRENDIZAJE

En esta unidad se verá la definición, planificación y control de las actividades de
un proyecto, métodos para el relevamiento de datos, la planificación y control de
actividades, la selección de un sistema viable, el ciclo de vida de un sistema en
sus diversas modalidades, así como las consideraciones generales para el desa-
rrollo de sistemas.
CONTENIDO TEMÁTICO
 Introducción a la definición de Proyectos de Sistemas
 Relevamiento de datos
 Planificación y control de actividades
 El ciclo de vida
 Consideraciones para el desarrollo de sistemas
RECURSOS DE APRENDIZAJE
En relación a los temas de la unidad, puede consultar al material base Introduc-
ción a Análisis de Sistemas Módulo 2 de la Prof. Cynthia Rivas Aquino, así
como los videos indicados y las referencias bibliográficas citadas.
UNIDAD 2
I. Inicio de un Proyecto
Iniciar un proyecto, determinar su factibilidad, calendarización, y administración
de las actividades y de los miembros del equipo para lograr productividad, son
Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 1

capacidades muy importantes que debe dominar el analista de sistemas.
1. Comprender como se inicia y selecciona un proyecto
Un proyecto de sistemas empieza con problemas y oportunidades de mejora
dentro de una empresa, conforme la misma se adapte a los cambios que requie-
ren solución de sistemas, que se dan en los ámbitos legales, industriales, etc.
Los proyectos de sistemas inician por muchas causas y razones diferentes. Se
sugieren proyectos por 2 razones:
 Experimentar en problemas que lleven por sí mismos a soluciones de sis-
temas.
 Reconocer oportunidades y hacer mejoras mediante la actualización, alte-
ración o instalación de nuevos sistemas.
Ambas situaciones pueden darse cuando la organización se adapta y enfrenta a
cambios naturales y evolucionados.
2. Definición de objetivos
Antes de planear un proyecto se deben establecer los objetivos y el ámbito del
producto, considerar soluciones alternativas, e identificar restricciones técnicas
y de gestión. De otro modo, es imposible definir estimaciones razonables y pre-
cisas del costo, valoración efectiva del riesgo, división realista de las tareas del
proyecto, calendario de proyecto manejable que ofrezca una indicación fiable del
progreso. Analista y cliente deben reunirse para definir objetivos y ámbito del
producto.
Los objetivos identifican metas globales del producto desde el punto de vista del
cliente, sin considerar cómo se lograrán. El ámbito identifica datos primarios, fun-
ciones y comportamientos que caracterizan al producto y (más importante) los
intentos por enlazar tales características en una forma cuantitativa. Entendidos
los objetivos y el ámbito del producto, se consideran soluciones alternativas, que
posibilitan la selección de un “mejor” enfoque, que cumplan las restricciones que
imponen las fechas límites de entrega, las restricciones presupuestarias, la dis-
ponibilidad del personal, las interfaces técnicas y muchos de factores más.
Hay varios objetivos aceptables para los proyectos de sistemas que éstos inclu-
yen, pero no están limitados a:
 Reducir errores y mejorar la precisión de la entrada de datos
 Reducir costo de la salida del sistema mediante la agilización y eliminación
de reportes duplicados o innecesarios
 Integrar los subsistemas del negocio
 Mejorar servicios al cliente para ganar una posición competitiva
 Acelerar la entrada
 Acortar tiempo de procesamiento de datos
 Automatizar procedimientos manuales para mejorarlos (reducir errores, au-
mentar velocidad o precisión, disminuir tiempo requerido por empleado,
etc.)
Los objetivos del proyecto necesitan ser puestos en claro formalmente.

 Cuál es el problema que ellos creen que resolverá el proyecto de sistema,
o cual situación se mejorará y
 Cuáles son las expectativas acerca del sistema propuesto.
3. Obtención de soluciones alternativas
Los proyectos vienen de muchas fuentes diferentes y por muchas razones. No
todos deben ser seleccionados. Se debe tener en claro las razones para reco-
mendar un estudio de sistema sobre un proyecto que parece resolver un pro-
blema o proporcionar una mejora. Hay que considerar la motivación que impulsa
la propuesta del proyecto.
Es necesario examinar los proyectos prospectivos desde una perspectiva de sis-
tema para considerar el impacto sobre toda la organización. No olvidemos que
todos los sistemas de la organización están interrelacionados y son interdepen-
dientes, por lo que un cambio a un subsistema puede afectar a todos los demás.
Incluso aunque los tomadores de decisiones directamente involucrados ponen
fronteras para el proyecto de sistema, un proyecto no puede ser contemplado o
seleccionado aisladamente del resto de la organización.
Más allá de las consideraciones generales, están los 5 criterios específicos para
la selección de proyectos.
1º (más importante) respaldo de la administración; no se puede lograr absolu-
tamente nada sin la aprobación de las personas que pagarán la cuenta.
2º temporización adecuada; para el analista y todos los recursos.
3º mejora del logro de los objetivos de la organización; poner a la organización
hacia su destino y no desalentarla de sus objetivos finales.
4º proyecto posible de llevar a la práctica, con recursos y capacidades propios
del negocio; reconocer cuando algún proyecto no cae dentro del campo de
la experiencia propia.
5º lograr un acuerdo básico con la organización sobre el valor de un proyecto
ante cualquier otro proyecto posible en consideración.
Cuando un negocio se compromete a un proyecto, compromete sus recursos,
que pasan a no estar disponibles para otros proyectos. Es útil ver todos los pro-
yectos posibles en competencia por los recursos de tiempo, dinero y gente del
negocio.
4. Determinación de la factibilidad de un proyecto propuesto
Una vez elegidos los proyectos acordes con los criterios trazados, es necesario
determinar si son factibles. La factibilidad se valora en 3 modos principales para
merecer un desarrollo posterior: operacional, técnica y económica.
El estudio de factibilidad permite recopilar datos burdos para la administración,
que permita tomar una decisión sobre la continuidad del estudio de sistema, re-
colectados por diferentes métodos, ejemplo entrevistas. El responsable no debe
emplear mucho tiempo en estudios de factibilidad y el mismo debe estar alta-
mente comprimido en el tiempo, comprendiendo varias actividades en un corto
lapso.
a. Factibilidad técnica.

El analista debe determinar si los recursos técnicos actuales pueden mejorarse
o añadirse para que satisfagan la petición en consideración. A veces, “adiciones”
a los sistemas existentes son costosos y no valen la pena pues satisfacen las
necesidades de manera ineficiente. Resulta benéfica la experiencia del analista
para responder a la pregunta de la factibilidad técnica. Si la respuesta sobre si
una tecnología determinada está disponible y es capaz de satisfacer las peticio-
nes del usuario es “si”, se convierte en económica.
b. Factibilidad económica. FACTIBILIDAD significa que el proyecto pro-
puesto:
Los recursos básicos a conside-
Ayuda a que la organización logre sus objetivos ge-
rar son:
nerales, con recursos actuales de la organización en
 Tiempo las sgtes. 3 áreas:
 costo de hacer un estudio  Factibilidad técnica

 Adición al sistema actual
 costo del tiempo de los em-
pleados del negocio,  Tecnología disponible para satisfacer necesida-
des del usuario
 costo estimado de recursos  Factibilidad económica
El negocio debe hacer valer el  Tiempo del analista de sistemas
costo de la inversión en su
 Costo del estudio de sistemas, tiempo usado
ponderación antes de com- para el estudio, hardware, software (pa-
prometerse a un estudio de quete/desarrollo)
sistemas completo. Si los cos-
 Factibilidad operacional
tos a corto plazo no son so-
brepasados por las ganancias  Si el sistema trabajará cuando sea usado; si el
sistema será usado.
a largo plazo, el sistema no es
factible económicamente y el proyecto no continuará.
c. Factibilidad operacional.
Depende de los recursos humanos disponibles para el proyecto. Involucra pro-
yectar si el sistema operará y se usará una vez instalado.
Mucho del arte de determinar la factibilidad operacional se encuentra en la inter-
faz de usuario elegida. Esta determinación requiere imaginación creativa, poder
de persuasión que permita que los usuarios sepan cuáles interfaces son posibles
y satisfarán sus necesidades, escuchar cuidadosamente lo que en realidad quie-
ren los usuarios y lo que parece que usarán. Con mucha frecuencia hay que
practicar el arte de adivinar.
La evaluación de factibilidad de proyectos de sistemas nunca es una tarea fácil
o bien definida; es una decisión a ser tomada por la administración, no por el
analista, pero basadas en datos de factibilidad, recolectados en forma experta y
profesional, y presentados por el analista. Se debe asegurar que las 3 áreas de
factibilidad sean vistas en el estudio preliminar. El estudio de un proyecto debe
ser logrado rápidamente para que los recursos que se le dediquen sean mínimos,
la información resultante sea sólida y todo interés en el proyecto se mantenga
alto.
Un estudio preliminar que precede al estudio del sistema debe ser ejecutado en
forma rápida y competente. Los proyectos que satisfagan tanto los criterios de
selección como los de factibilidad, debe ser elegidos para un estudio detallado.
El proceso de valoración de factibilidad es efectivo para el filtrado de proyectos
inconsistentes con los objetivos del negocio, técnicamente imposibles o econó-
micamente no rentables. Aunque laborioso, el estudio de factibilidad vale la pena
y, a la larga, ahorra gran cantidad de tiempo y dinero.
5. Determinación de recursos
La determinación de recursos sigue un patrón amplio, que será revisado y vuelto
a evaluar cuando se recomiende el estudio del sistema formal.
II. Relevamiento de Datos
El relevamiento de datos consiste en la utilización de métodos específicos (téc-
nicas para encontrar hechos) con el objeto de reunir datos relacionados con los
requerimientos del sistema. Entre éstos se incluyen: entrevistas, cuestionarios,
revisión de los registros (en el sitio donde se encuentran), observación del toma-
dor de decisiones y su ambiente de oficina. En general, se usa más de una de
estas técnicas para asegurar que se realiza una investigación amplia y exacta.
1. Método de trabajo para recopilación de información
La recopilación de información es un sistema grande y complejo que puede re-
sultar una tarea costosa. La información se debe reunir siguiendo un camino or-
ganizado 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á identifi-
cado. La búsqueda se debe hacer, de tal forma que se eviten los trabajos repe-
titivos y que un mismo usuario no sea interrogado varias veces pidiéndole la
misma información.
2. Estrategia de búsqueda
Es fácil equivocarse cuando la colecta de información se realiza con base en un
gran sistema con muchas fuentes de información. Para evitar problemas, es ne-
cesario desarrollar una estrategia para recoger la información a fin de asegurar
que se cumplen todos los criterios.
Estrategia de búsqueda es un conjunto de procedimientos y operaciones que se
realiza con el fin de obtener la información necesaria para conocer sobre una
situación determinada.
Una estrategia de búsqueda se establece mediante dos importantes elecciones:
 Primero, se identifican todas las fuentes de donde se obtendrá información,
así como los métodos para obtener la información de cada una de ellas.
 Luego, se establece un procedimiento de búsqueda para obtener la infor-
mación, procedimiento que define donde empezar la búsqueda y como con-
tinuarla. También identifica la secuencia en que se examinaran las fuentes
y que información se obtendrá en cada paso.
En resumen, se deben definir: la fuente de información, los métodos de bús-
queda y los procedimientos de búsqueda.
La estrategia de búsqueda ayuda al analista a establecer el sentido de la infor-
mación obtenida en las fuentes. Estos métodos se utilizan para construir mode-
los del sistema que ayuden a controlar lo que se hace cada día y lo que se ne-
cesita hacer para completar el trabajo.
3. Fuente de información
Se conoce como fuente de información a diversos tipos de documentos que con-
tienen datos útiles para satisfacer una demanda de información o conocimiento
o las personas que manejan dichas fuentes.
Existe una gran variedad de fuente de información para un sistema. Normal-
mente, cada fuente proporciona 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: son normalmente la primera fuente de infor-
mación a investigar. De ellos es posible extraer información de las
actividades del sistema existente y determinar los objetivos de los
mismos y sus necesidades. Aquí, los métodos usuales son las en-
trevistas (unos de los principales métodos de recopilación de infor-
mación) y, a veces, complementados con cuestionarios.
 Formularios y documentos: son fuentes de información utilizadas para los
diagramas de flujos de datos y transacciones. Este método de búsqueda co-
mienza con la obtención de una lista de documentos de usuario del sistema
para, a través de ellos, encontrar los datos elementales y sus estructuras de
datos.
 Programas: se pueden utilizar para determinar los detalles de las estructu-
ras de datos o de los procesos. Son métodos de búsqueda 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: por lo general, especifican o describen lo
que hace el personal de una organización. Se los puede utilizar para deter-
minar en detalle las actividades del usuario. Esta información adquiere rele-
vancia en el diseño detallado. Los métodos de búsqueda se centran en el
estudio de tales documentos.
 Informes: Esta fuente indica las 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 se necesita. Si forma 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.
4. Procedimiento de búsqueda
El procedimiento de búsqueda propone el orden para buscar las fuentes de in-
formación y que métodos utilizar en la búsqueda.
El procedimiento de búsqueda consiste en 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 para tener la seguridad de que se recoge toda la infor-
mación sobre el sistema.

Procedimiento Top-down: propone empezar por el nivel superior y seguir hasta
el nivel inferior para obtener información detallada e ir construyendo progresiva-
mente el modelo de sistema. Esta aproximación comienza normalmente con una
serie de entrevistas con los directores, para determinar las funciones principales
del sistema y sus actividades. Entonces, se busca la información que describa
esas funciones y actividades.
Los procedimientos de búsqueda varían dependiendo de si se investiga un sis-
tema existente o si se diseña uno totalmente nuevo.
Sistemas existentes
Deben incluir las numerosas fuentes de información de los sistemas para esta-
blecer una secuencia de búsqueda en esas fuentes.
1. Se 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 se estudian algunos de los
informes y documentos más importantes.
2. Se diseña un modelo de nivel superior que se verifica durante el siguiente
conjunto de entrevistas.
3. Una vez establecido un modelo de nivel superior satisfactorio, se comienza
con operaciones más detalladas. La búsqueda de esa información más de-
tallada empieza normalmente con entrevistas al personal operativo, para es-
tablecer las fuentes detalladas de información, incluyendo programas, infor-
mes y manuales.
4. La clase de datos solicitados en el nivel inferior depende del sistema. Si se
busca perfeccionar un sistema, se deben examinar los sistemas y programas
existentes.
5. Si se van a mejorar procedimientos manuales, se realizará un examen deta-
llado de los procedimientos actuales. En la mayoría de los casos se debe
examinar tanto el sistema como el procedimiento de usuario.
6. Se utiliza esta nueva información detallada para expandir el modelo de nivel
superior que será verificado con el usuario.
7. Este procedimiento puede repetirse varias veces mientras se busca infor-
mación cada vez más detallada. Esta secuencia de entrevistas y búsque-
das se hará más crítica según el analista vaya aprendiendo cosas sobre el
sistema.
8. 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 conti-
nuara hasta que el analista este conforme con el modelo.
9. Este pasa por una serie de revisiones, comenzando con una revisión téc-
nica para establecer formalmente la exactitud del modelo.
10. 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 sis-
tema.
Sistemas nuevos:

Los procedimientos para nuevos sistemas son más simples, porque hay pocas
fuentes de información. No hay informes, programas, ni manuales que exami-
nar. 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 sis-
tema, sino determinar lo que los usuarios esperan del nuevo sistema. Cuando
se propone la totalidad del nuevo sistema, generalmente el analista busca infor-
mación en fuentes externas. Los analistas pueden examinar estos sistemas ex-
ternos para ver si alguna de sus características se ajusta el nuevo sistema pro-
puesto.
5. Métodos de búsqueda
a. Entrevistas
Antes de entrevistar a alguien, empiece por entrevistarse a sí mismo. Conocer
sus prejuicios y cómo afectará esto a sus percepciones. Su educación, intelecto,
contexto cultural, formación, emociones y marco ético, son filtros poderosos de
lo que oirá en las entrevistas.
Necesita pensar detalladamente en las entrevistas antes de ir a ellas. Analizar
qué lo motiva o porqué lo va a hacer, qué preguntará y qué es lo que hará satis-
factoria la entrevista. También, cómo hará satisfactoria la entrevista para la per-
sona a quien entrevistará.
Tipos de información buscada
Una entrevista recaba información es una conversación dirigida con un propósito
específico mediante un formato de preguntas y respuestas. Con ella, se busca
obtener la opinión del entrevistado y sus sentimientos sobre el estado actual del
sistema, los objetivos de la organización y personales, y los procedimientos in-
formales.
Las opiniones de las personas entrevistadas pueden ser más importantes y re-
veladoras que los hechos. Viendo opiniones en vez de hechos, se descubren
problemas que necesitan resolverse.
Tratar de captar los sentimientos del entrevistado para puede comprender de
manera más completa la cultura de la organización, determinar el grado de opti-
mismo existente.
Los objetivos son una información importante que pueden obtenerse de las en-
trevistas. Los hechos obtenidos de datos relevantes pueden explicar el desem-
peño pasado; los objetivos proyectan el futuro de la organización. Trate de en-
contrar tantos objetivos como sea posible a partir de las entrevistas (quizás no
sea posible determinar los objetivos por ningún otro método de recopilación de
datos).
En la entrevista, establece relación con alguien que, probablemente, es un ex-
traño, por lo cual necesita dar confianza y comprensión rápidamente, pero sin
perder el control de la entrevista, vender el sistema proporcionando información
necesaria al entrevistado. Planifique la entrevista antes de ir a ella, para condu-
cirla de modo natural. Afortunadamente, puede aprender a hacer entrevistas
efectivas; verá que mejora conforme va practicando.
Planeación de la entrevista

Cinco pasos en la preparación de la entrevista, que incluyen un rango de activi-
dades, desde la recolección del material básico de fondo hasta tomar la decisión
de a quién entrevistar, pasando por el establecimiento de los objetivos de la en-
trevista, definir la estructura de la entrevista y preparar al entrevistado.
b. Cuestionarios
Técnica de recopilación de información que permite que los analistas de siste-
mas estudien actitudes, creencias, comportamiento y características de varias
personas en la organización, que pueden ser afectadas por los sistemas actual
y propuesto.
Tipos de información buscada
Actitud es lo que la gente de la organización dice que quiere (en un nuevo sis-
tema, por ej.); creencia es lo que la gente piensa que es de hecho cierto; com-
portamiento es lo que hacen los miembros de la organización y características
son propiedades de las personas o cosas.
Las preguntas sobre actitudes y creencias son notablemente sensibles a la re-
dacción escogida por el analista de sistemas.
Con el uso de cuestionarios, el analista puede estar buscando cuantificar lo que
ha encontrado en las entrevistas. Se pueden determinar qué tan amplio o limi-
tado es en realidad un sentimiento expresado en una entrevista. Las respuestas
obtenidas de cuestionarios usando preguntas cerradas pueden ser cuantifica-
das; preguntas abiertas son analizadas e interpretadas de otras formas.
Los cuestionarios se pueden usar para investigar una gran muestra de usuarios
de sistemas tratando de encontrar problemas o recoger cosas importantes antes
de que se realicen las entrevistas.
Hay muchas similitudes entre cuestionarios y entrevistas; podría ser ideal usarlas
en conjunción averiguando respuestas no claras de los cuestionarios con una
entrevista, diseñando cuestionarios según lo descubierto en las entrevistas.
Cada técnica tiene sus propias funciones específicas y no siempre es necesario
o deseable usar ambos.
Planear el uso de cuestionarios
Los cuestionarios pueden parecer una forma rápida de recolección de enormes
cantidades de datos sobre cómo los usuarios valoran el sistema actual, qué pro-
blemas están teniendo con su trabajo y lo que esperan de un sistema nuevo o
modificado.
Si bien es cierto que se puede recolectar gran cantidad de información por medio
de cuestionarios sin gastar tiempo en entrevistas personales, desarrollar un
cuestionario útil lleva gran tiempo de planeamiento.
Se debe decidir qué se está tratando de obtener mediante el cuestionario. Por
ej., si se quiere saber qué % de usuarios prefieren un centro de información como
un medio de aprender sobre nuevos paquetes de software, un cuestionario
puede ser la técnica adecuada.
Si se desea hacer un análisis a fondo sobre el proceso de toma de decisiones
de un gerente, la entrevista es mejor alternativa
Lineamientos para decidir si es adecuado usar cuestionarios.
1. Las personas a quienes necesita preguntar están ampliamente dispersas (di-
ferentes sucursales).
2. En el proyecto está involucrada gran cantidad de personas y tiene sentido
saber qué proporción de un grupo dado (administración, por ej.) aprueba o
no una característica particular del sistema propuesto.
3. Se está haciendo un estudio exploratorio y se desea medir la opinión general
antes de dar al proyecto una dirección fija.
4. Se desea asegurar de que cualquier problema con el sistema actual esté
identificado y tratado en las entrevistas de averiguación.
III. Planificación y control de actividades
El análisis y diseño de sistemas involucra muchos tipos de actividades diferentes
que juntos forman un proyecto.
El analista debe administrar el proyecto cuidadosamente para que llegue a ser
un proyecto exitoso. La administración incluye
 Actividades y tareas requeridas
 Asignar los miembros del equipo a los proyectos adecuados (personal invo-
lucrado)
 Estimar el tiempo requerido para completar cada tarea (cuando empezará y
terminará)
 Calendarizar el proyecto para que las tareas sean terminadas ordenada-
mente (cuánto tiempo y esfuerzo requerirá y el riesgo involucrado)
1. Gráfica de Gantt para programación de proyectos
Forma fácil de calendarizar actividades y tareas de un proyecto. En ella, barras
horizontales representan cada tarea o actividad; la longitud horizontal de cada
barra indica la duración
relativa de la tarea. La di-
mensión vertical des-
cribe las actividades.
Ventajas: simplicidad
(fácil de usar); adecuada
para una comunicación
satisfactoria con los
usuarios finales; las ba-
rras de actividades o ta-
reas se trazan a escala
(longitud de la barra in-
dica duración relativa
(tiempo) de la tarea).
2. Uso de Diagrama de Pert
Un programa o proyecto se representa como una red de nodos y flechas, para
determinar actividades críticas, mejorar la calendarización (si es necesario) y re-
visar el avance, una vez que el proyecto se realiza. Útil para indicar cuando las
actividades deben realizarse en paralelo o secuencialmente. Cada actividad se
representa como flecha (la longitud no tiene relación directa con la duración de
la actividad). Los círculos representan eventos (pueden identificarse con núme-
ros, letras u otra forma arbitraria). La precedencia de la actividad es importante
para determinar la longitud del proyecto. Un proyecto tiene un inicio, parte media
y final. Para encontrar la duración del proyecto se identifica cada ruta de inicio a
fin y se calcula la duración de cada una. La ruta más larga se llama ruta crítica o
camino crítico; la que podría causar que el proyecto completo se atrase. La liber-
tad para retrasarse en algún punto de las rutas no críticas se denomina tiempo
de holgura. Se debe vigilar cuidadosamente las actividades de la ruta crítica para
que todo el proyecto esté a tiempo o incluso se acorte su duración, de ser posi-
ble.
A,3 20
B,4
10
D,8
C,4
30 50
E,5
F,3
40
IV. Ciclo de vida de un Sistema

1. Definición
El ciclo de vida del sistema es un enfoque, por fases, del análisis y diseño, que
sostiene que los sistemas se desarrollan mejor con el uso de un ciclo específico
de actividades del analista y del usuario. No son fases exactas, varias activida-
des pueden suceder simultáneamente y pueden ser repetidas. Es más útil pen-
sar en fases (con actividades traslapándose y luego disminuyendo) y no en pa-
sos separados. Ayuda a organizar las actividades, aumentando la probabilidad
de que se aborden los problemas pertinentes en el momento adecuado.
Cada vez más las organizaciones grandes y pequeñas que están adoptando un
ciclo de vida uniforme y único para sus proyectos. Esto a veces se conoce
como el plan del proyecto, la metodología del desarrollo del sistema o, simple-
mente, “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.
Existen 3 objetivos principales para este método de trabajo:
 Definir las actividades a realizar en un proyecto de desarrollo de sistemas,
y la secuencia en que se deben tratar esas actividades.
 Ayudar a los analistas y diseñadores a resolver problemas que vayan sur-
giendo 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.
 Producir informes del estado del proyecto para ayudar a los directores y
posibilitar 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.

Cabe subrayar que el ciclo de vida del proyecto definitivamente no está a cargo
del proyecto; no evitara al administrador del mismo la difícil labor de tomar deci-
siones. La única ayuda que puede proporcionar es a poder organizar las activi-
dades del administrador, aumentando la probabilidad de que se aborden los pro-
blemas pertinentes en el momento adecuado.
2. 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 organi-
zado.
Para Kendall & Kendall, el desarrollo de sistemas son simples enfoques para
analizar y diseñar un nuevo sistema, rigiéndose de un ciclo específico de activi-
dades para empezar y terminar de la manera más segura un sistema. Su meto-
dología abarca un ciclo de vida que consta de 7 fases o funciones, que van desde
identificar los problemas, requisitos, análisis hasta concluir con la implementa-
ción y la evaluación del mismo, que pueden trabajarse en momentos solapados
o simultáneos en algunos casos y hasta pueden repetirse.
A continuación, explicaremos cada una de estas funciones o fases:

1. Identificación de problemas, oportunidades y objetivos:
En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se
encarga de identificar correctamente los problemas, las oportunidades y los ob-
jetivos. Esta etapa es imprescindible para el éxito del resto del proyecto, ya que
a nadie le gusta desperdiciar el tiempo resolviendo un problema mal caracteri-
zado.
El analista debe analizar con honestidad lo que está ocurriendo en la empresa.
Luego, junto con otros miembros de la organización, debe señalar los proble-
mas. A menudo, otras personas habrían planteado también estos problemas,
razón por la cual se llamó en un principio al analista. Las oportunidades residen
en las situaciones que el analista cree poder mejorar mediante el uso de siste-

mas de información computarizados. Al aprovechar estas oportunidades, la em-
presa puede obtener una ventaja competitiva o establecer un estándar en la
industria.
La identificación de los objetivos también es un componente importante de la
primera fase. El analista debe descubrir primero qué trata de hacer la empresa;
después debe ser capaz de determinar si alguno de los aspectos de las aplica-
ciones de los sistemas de información puede ayudar a que la empresa logre
sus objetivos al enfrentar problemas u oportunidades específicos.
Las personas involucradas en la primera fase son los usuarios, los analistas y
los administradores de sistemas que coordinan el proyecto. En esta fase las
actividades consisten en entrevistar a los encargados de la administración de
los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del pro-
yecto y documentar los resultados. El resultado de esta fase es un informe de
viabilidad, el cual contiene la definición de un problema y sintetiza los objetivos.
Después, la administración de la empresa debe tomar una decisión en cuanto
a proceder o no con el proyecto propuesto. Si el grupo de usuarios no tiene
suficientes fondos en su presupuesto o desea hacer frente a problemas que no
están relacionados, o si los problemas no requieren un sistema computacional,
tal vez se pueda recomendar una solución distinta y el proyecto de sistemas no
continúe.
2. Determinación de los requerimientos de información:
En esta fase se determinan las necesidades de los usuarios involucrados, me-
diante el uso de varias herramientas, para comprender la forma en que interac-
túan en el contexto laboral con sus sistemas de información actuales. El ana-
lista utilizará métodos interactivos como entrevistas, muestreos e investigación
de datos duros, además de los cuestionarios y los métodos discretos, como
observar el comportamiento de los encargados al tomar las decisiones y sus
entornos de oficina, y los métodos integrales como la creación de prototipos.
El analista utilizará estos métodos para plantear y responder muchas preguntas
relacionadas con la interacción humano-computadora (HCI), incluyendo pre-
guntas tales como: “¿Cuáles son las fortalezas y limitaciones físicas de los
usuarios?”, o, dicho en otras palabras, “¿qué hay que hacer para que el sistema
sea perceptible, legible y seguro?”, “¿cómo puede diseñarse el nuevo sistema
para que sea fácil de usar, aprender y recordar?”, “¿cómo puede el sistema ser
agradable o incluso divertido de usar?”, “¿cómo puede el sistema apoyar las
tareas laborales individuales de un usuario y buscar nuevas formas de hacerlas
más productivas?”.
En esta fase de requerimientos, el analista se esfuerza por comprender qué
información requieren los usuarios para realizar sus trabajos. En este punto el
analista examina cómo hacer que el sistema sea útil para las personas involu-
cradas. ¿Cómo puede el sistema ofrecer un mejor apoyo para las tareas indivi-
duales que se deben llevar a cabo? ¿Qué nuevas tareas habilita el nuevo sis-
tema que los usuarios no podían realizar sin él? ¿Cómo se puede crear el sis-
tema de manera que extienda las capacidades de un usuario más allá de lo
provisto por el sistema anterior? ¿Cómo puede el analista crear un sistema gra-
tificante para los trabajadores?

Las personas involucradas en esta fase son los analistas y los usuarios, por lo
general los gerentes y los trabajadores operativos. El analista de sistema debe
conocer los detalles sobre las funciones del sistema actual: quién (las personas
involucradas), qué (la actividad de la empresa), dónde (el entorno en el que se
lleva a cabo el trabajo), cuándo (la coordinación) y cómo (de qué manera parti-
cular se realizan los procedimientos actuales) de la empresa a la que está es-
tudiando. Después, el analista debe preguntar por qué la empresa utiliza el sis-
tema actual. Puede haber buenas razones por las cuales la empresa trabaje
con los métodos actuales, razón por la que se deben tener en cuenta al diseñar
un nuevo sistema.
Al terminar esta fase, el analista deberá comprender la forma en que los usua-
rios realizan su trabajo al interactuar con una computadora y deberá empezar
a comprender cómo mejorar la utilidad y capacidad de uso del nuevo sistema.
También deberá saber cómo funciona la empresa y tener información completa
sobre personas, objetivos, datos y procedimientos involucrados.
3. Análisis de las necesidades.
En esta fase de análisis de las necesidades del sistema, el analista utiliza he-
rramientas y técnicas especiales que ayudan a realizar las determinaciones de
los requerimientos. Las herramientas como los diagramas de flujo de datos
(DFD) para graficar la entrada, los procesos y la salida de las funciones de la
empresa, o los diagramas de actividad o de secuencia para mostrar la secuen-
cia de los eventos, sirven para ilustrar a los sistemas de una manera estructu-
rada y gráfica. A partir de los diagramas de flujo de datos, de secuencia u otros
tipos de diagramas se debe desarrollar un diccionario de datos para enlistar
todos los elementos de datos utilizados en el sistema, así como sus especifica-
ciones.
Durante esta fase, también se analizan las decisiones estructuradas llevadas a
cabo. Las decisiones estructuradas son aquellas para las que se pueden deter-
minar condiciones, alternativas de condición, acciones y reglas de acción. Hay
tres métodos principales para el análisis de las decisiones estructuradas: in-
glés/español estructurado, tablas de decisión y árboles de decisión. En este
punto del ciclo de vida, el analista de sistemas prepara una propuesta de siste-
mas en la que sintetiza todo lo que ha averiguado sobre los usuarios, la capa-
cidad de uso y la utilidad de los sistemas actuales; incluye un análisis de costo-
beneficio de las alternativas y, si se requiere, hace recomendaciones. Si la ad-
ministración acepta una de las recomendaciones, el análisis continúa por esa
vía. Cada problema de sistemas es único, por lo que nunca hay una única so-
lución correcta. La manera en que se formule una recomendación o solución
depende de las cualidades individuales y la capacitación profesional de cada
analista, y de su interacción con los usuarios en el contexto de su entorno la-
boral.
4. Diseño del sistema recomendado.
En esta fase de diseño, el analista de sistemas utiliza la información recolectada
antes para realizar el diseño lógico del sistema de información. El analista di-
seña los procedimientos para ayudar a que los usuarios introduzcan los datos
con precisión, de manera que los datos que entren al sistema de información

sean los correctos. Además, el analista debe ayudar a que los usuarios com-
pleten la entrada de datos efectiva al sistema de información mediante el uso
de las técnicas del buen diseño de formularios y páginas Web o pantallas.
Parte del diseño lógico del sistema de información es idear la HCI. La interfaz
conecta al usuario con el sistema, por lo que es extremadamente importante.
La interfaz del usuario se diseña con ayuda de los usuarios para asegurar que
el sistema sea perceptible, legible y seguro, así como atractivo y divertido de
usar. Ejemplos de interfaces de usuario físicas son el teclado (para escribir las
preguntas y respuestas), los menús en pantalla (para obtener los comandos de
los usuarios) y varios tipos de interfaces gráficas de usuario (GUI) basadas en
un ratón o una pantalla táctil.
La fase de diseño también incluye el diseño de bases de datos que almacena-
rán gran parte de los datos necesarios para los encargados de tomar las deci-
siones en la organización. Los usuarios se benefician de una base de datos
bien organizada que sea lógica para ellos y se corresponda con la forma en que
ven su trabajo. En esta fase, el analista también trabaja con los usuarios para
diseñar una salida (ya sea en pantalla o impresa) que cumpla con sus necesi-
dades de información.
Por último, el analista debe diseñar controles y procedimientos de respaldo para
proteger el sistema y los datos, y para producir paquetes de especificación de
programas para los programadores. Cada paquete debe contener los diseños
de las entradas y las salidas, las especificaciones de los archivos y los detalles
sobre el procesamiento; también puede incluir árboles o tablas de decisión,
UML o diagramas de flujo de datos, junto con los nombres y las funciones de
cualquier código previamente escrito dentro de la empresa o que utilice código
u otras bibliotecas de clases.
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.
5. Desarrollo y documentación del software.
En esta fase, el analista trabaja con los programadores para desarrollar el soft-
ware original requerido, así como con los usuarios para elaborar una documen-
tación efectiva para el software, incluyendo manuales de procedimientos, ayuda
en línea, sitios Web con preguntas frecuentes (FAQ) y archivos Léame (Read
Me) para incluir con el nuevo software. Como los usuarios están involucrados
desde el principio, la fase de documentación debe lidiar con las preguntas que
hicieron y resolvieron junto con el analista. La documentación indica a los usua-
rios cómo deben usar el software y qué deben hacer en caso de que ocurran
problemas. Los programadores desempeñan un rol clave en esta fase, ya que
diseñan, codifican y eliminan los errores sintácticos de los programas de
computadora. Para asegurar la calidad, un programador puede llevar a cabo un
recorrido por el diseño o por el código para explicar las porciones complejas del
programa a un equipo formado por otros programadores.
6. Prueba y mantenimiento del sistema.
Antes de utilizar el sistema de información, se debe probar. Es mucho menos
costoso detectar los problemas antes de entregar el sistema a los usuarios. Una
parte del procedimiento de prueba es llevado a cabo por los programadores
solos; la otra la realizan junto con los analistas de sistemas. Primero se com-
pleta una serie de pruebas para señalar los problemas con datos de muestra y
después se utilizan datos reales del sistema actual. A menudo, los planes de
prueba se crean en las primeras etapas del SDLC y se refinan a medida que el
proyecto progresa.
El mantenimiento del sistema y la documentación de este mantenimiento em-
pieza en esta fase y se lleva a cabo de manera rutinaria durante toda la vida
del sistema de información. Gran parte del trabajo rutinario del programador
consiste en el mantenimiento, por lo cual las empresas invierten una gran can-
tidad de dinero en este proceso.
Ciertos procedimientos de mantenimiento, como las actualizaciones de los pro-
gramas, se pueden llevar a cabo a través del sitio Web del distribuidor. Muchos
de los procedimientos sistemáticos que emplea el analista durante el SDLC
pueden ayudar a asegurar que el mantenimiento siempre se mantenga en el
nivel mínimo necesario.
7. Implementación y evaluación del sistema.
En esta última fase del desarrollo de sistemas, el analista ayuda a implementar
el sistema de información. En esta fase hay que capacitar a los usuarios para
operar el sistema. Los distribuidores se encargan de una parte de la capacita-
ción, pero la supervisión de la capacitación es responsabilidad del analista de
sistemas. Además, el analista necesita planear una conversión sin problemas
del sistema antiguo al nuevo. Este proceso incluye convertir los archivos de los
formatos anteriores a los nuevos, o crear una base de datos, instalar equipo y
llevar el nuevo sistema a producción.
La evaluación se incluye como parte de esta fase final del SDLC principalmente
por cuestiones informativas. En realidad, la evaluación se realiza durante cada
fase. El criterio clave que debemos satisfacer es si los usuarios previstos están
utilizando el sistema. Hay que tener en cuenta que a menudo el trabajo relacio-
nado con los sistemas es cíclico. Cuando un analista termina una fase del desa-
rrollo de sistemas y continúa con la siguiente, al descubrir un problema tal vez
se vea obligado a regresar a la fase anterior y modificar el trabajo que realizó
ahí.
El impacto del mantenimiento

Una vez instalado el sistema hay que darle mantenimiento, lo cual implica que
tal vez haya que realizar modificaciones en los programas de computadora y
mantenerlos actualizados. En la figura vemos la cantidad promedio de tiempo
que se invierte en el mantenimiento de una instalación de MIS (SIG o Sistema
de Información Gerencial) común. Las estimaciones del tiempo invertido por los
departamentos en el mantenimiento varían desde un 48 % hasta un 60 % del
tiempo total invertido en el desarrollo de los sistemas. Queda muy poco tiempo
libre para el desarrollo de nuevos sistemas. A medida que aumenta el número
de programas escritos, también aumenta la cantidad de mantenimiento que se
requiere.
El mantenimiento se realiza por dos razones. La primera, para corregir los erro-
res de software. Sin importar qué tan minuciosas sean las pruebas en el sis-
tema, se pueden infiltrar errores o ‘bugs’ en los programas computacionales.
Los ‘bugs’ en el software comercial de PC se documentan comúnmente como
“anomalías conocidas” y se corrigen al momento de liberar nuevas versiones,
o liberando una versión provisional. En el software personalizado (también co-
nocido como software hecho a la medida), los ‘bugs’ se deben corregir a medida
que se van detectando. La otra razón, para mejorar las capacidades del soft-
ware en respuesta a las necesidades cambiantes de la organización, que por
lo general implica una de las siguientes tres situaciones:
a. Con frecuencia los usuarios solicitan características adicionales a medida
que se familiarizan con el sistema computacional y sus capacidades.
b. La empresa cambia con el tiempo.
c. El hardware y el software cambian a un ritmo acelerado.

La figura nos muestra la cantidad de recursos (por lo general tiempo y dinero)
que se invierten en el desarrollo y mantenimiento de sistemas. El área bajo la
curva representa la cantidad total invertida en dólares. Podemos ver que, a tra-
vés del tiempo, es probable que el costo total del mantenimiento exceda al costo
del desarrollo de sistemas. En cierto punto es más factible realizar un nuevo
estudio de sistemas, debido a que el costo de continuar con el mantenimiento
es sin duda mayor que el de crear un sistema de información totalmente nuevo.
En resumen, el mantenimiento es un proceso continuo que se realiza a lo largo

del ciclo de vida de un sistema de información. Una vez que se instala el sis-
tema de información, por lo general el mantenimiento implica corregir los erro-
res del programa que no se habían detectado antes. Una vez corregidos, el
sistema se acerca a un estado estable para proveer un servicio confiable a sus
usuarios. Durante este periodo, el mantenimiento puede consistir en eliminar
unos cuantos ‘bugs’ que no se detectaron antes y actualizar el sistema con
mejoras menores. Sin embargo, a medida que pasa el tiempo y evolucionan
tanto la empresa como la tecnología, el esfuerzo de mantenimiento aumenta
en forma considerable.
3. 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 ascen-
dente del sistema y la insistencia en la progresión lineal y secuencial de una fase
a la siguiente.
Ciclo de vida lineal o secuencial

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 im-
pide avanzar. Resulta apropiado para:
 Desarrollar nuevas versiones de sistemas ya antiguos en los que el des-
conocimiento de las necesidades de los usuarios o del entorno de opera-
ció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.
Ciclo de vida semiestructurado
Desde fines de los años 70 y principios de los 80, ha crecido la tendencia a re-
conocer 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 fi-
gura. Se muestran dos detalles 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 prue-
ban 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 en-
foque 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 sig-
nifica 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 co-
dificación, la prueba y la eliminación de las fallas.
Ciclo de vida estructurado

Ahora que ya hemos visto los ciclos de vida del proyecto clásico y semiestruc-
turado, estamos listos para examinar el ciclo de vida estructurado.
Examinaremos brevemente las nueve actividades y los tres terminadores del ci-
clo de vida del proyecto, como se muestra en la figura 5.4. Los terminadores son
los usuarios, administradores y el personal de operaciones. Se trata de indivi-
duos 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 sgte. (posteriormente iremos resumiendo cada una de

las actividades).
Actividad 1: Encuesta
Esta actividad, conocida también estudio de factibilidad o estudio inicial de ne-
gocios, generalmente empieza cuando el usuario solicita la automatización de
una o más partes de su sistema. 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 entrevis-
tas para determinar qué usuarios estarán comprendidos en (o serán afecta-
dos 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.
 Identificar las deficiencias actuales en el ambiente del usuario. Esto en ge-
neral comprenderá la lista de funciones que hacen falta o que se están lle-
vando a cabo insatisfactoriamente en el sistema actual. Por ejemplo, esto
pudiera incluir declaraciones como las siguientes:
- El tiempo de respuesta del sistema telefónico de pedidos actual es tan
malo que muchos clientes cuelgan frustrados antes de hacer su pedido.
- El sistema actual no es capaz de producir los informes requeridos por
la modificación a los impuestos decretada el año anterior.
- 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 infor-
mes de promedio de volumen de pedidos que requiere el departamento
de mercadotecnia.
 Establecer metas y objetivos para un sistema nuevo. Esto puede ser una
simple lista narrativa de 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 escena-
rios 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% en esta etapa tan temprana del proyecto.
 Preparar el esquema que se usará para guiar el resto del proyecto. Este es-
quema incluirá toda la información que se lista anteriormente, además de
identificar al administrador responsable del proyecto. También pudiera des-
cribir los detalles del ciclo de vida que seguirá el resto del proyecto.
En general, la encuesta ocupa sólo del 5 al 10 % 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 así, es una actividad verdaderamente
importante: al final de la encuesta, la administración podría decidir cancelar el
proyecto si no parece atractivo desde el punto de vista costo – beneficio.
Actividad 2: El análisis del sistema
El propósito principal de esta actividad es transformar sus dos entradas o insu-
mos 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 mo-
delo ambiental y el desarrollo de un modelo de comportamiento. Ambos modelos
se combinan para formar el modelo esencial que representa una descripción for-
mal 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. Obvia-
mente, esto consumirá la mayor parte del tiempo del analista.
Actividad 3: Diseño
Esta actividad dedica a asignar porciones de la especificación (también conocida
como modelo esencial) a procesadores adecuados (máquinas o humanos) y a labores
apropiadas (tareas, particiones, etc.) dentro de cada procesador. Dentro de cada
labor, 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
2. Además, 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 incluirá el desarrollo de algo conocido como modelo de

implantación del usuario, que describe los asuntos relacionados con la implanta-
ción que interesa 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 ma-
nera 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 compu-
tadora), además del formato y secuencia de salidas – o productos – que la
computadora proporciona al usuario.
Actividad 4: Implantación
Incluye la codificación y la integración de módulos en un esqueleto progresiva-
mente más completo del sistema final. Por eso, esta actividad incluye tanto pro-
gramación estructurada como implantación descendente.
En esta actividad, el analista no se verá muy involucrado, aunque hay 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 produ-
cir un conjunto de casos de prueba de aceptación desde la especificación es-
tructurada.
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 el analista
cumpla esta labor al término del desarrollo del modelo esencial en la actividad 2.
Actividad 6: garantía de calidad
Conocida también como prueba final o prueba de aceptación, esta actividad re-
quiere como entradas los datos de la prueba de aceptación generada en la acti-
vidad 5 y el sistema integrado producido en la actividad 4.
El analista puede estar involucrado con esta actividad, 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 depar-
tamento de control de calidad.
Algunas personas le llaman a esta actividad “control de calidad” en vez de “ga-
rantí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 la
importancia de llevar a cabo acciones de garantía de calidad en cada una de las
actividades anteriores para asegurar que se hayan realizado con un nivel apro-
piado de calidad. Por eso, es deseable que esto se haga durante toda la actividad
de análisis, diseño y programación para asegurar que el analista esté desarro-
llando 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 cali-
dad. 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 de procedimientos
Desde un principio hay que preocuparse por el desarrollo de un sistema com-
pleto: no sólo de la parte automatizada, también de la parte que llevarán a cabo
las personas. Por ello, una de las actividades importantes a realizar es la gene-
ració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 sistema. El resultado de la actividad 7 es un manual para
el usuario. Esta es una actividad que podría involucrar al analista.
Actividad 8: conversión de base 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 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 pro-
ducida 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, es decir, la instalación; sus entradas son el manual de usuario
producido en la actividad 7, la base de datos convertida que se creó con la acti-
vidad 8 y el sistema aceptado producido por la actividad 6. En algunos casos, sin
embargo, la instalación pudiera simplemente constituir un cambio de la noche a
la mañana al nuevo sistema, sin mayor inconveniente; en otros casos, la instala-
ción podría resultar un proceso gradual, en el que un grupo tras otro de usuarios
van recibiendo manuales y entrenamiento y comenzando a usar el nuevo sis-
tema.
Resumen del ciclo de vida del proyecto estructurado
Es importante ver la figura 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 an-
tes 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 lle-
vando a cabo diversas actividades paralelamente. Debido a este aspecto no
secuencial, usamos la palabra actividad en el ciclo de vida del proyecto estruc-
turado en lugar de “fase”, que es más convencional y tradicionalmente se re-
fiere a un período particular en un proyecto en el cual se estaba desarrollando
una, y sólo una, actividad.
En resumen, la figura 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.
Ciclo de vida de prototipos
En general se 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 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 defini-
ció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 prototi-
pos”. También conocido 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 proyec-
tos 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 efica-
cia 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 in-
geniero 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 itera-
ción de construcción de prototipos y se presenta el modelado (en forma de di-
seño rápido). El diseño rápido se centra en una representación de aquellos as-
pectos 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 satis-
facer las necesidades del cliente. Eso permite que al mismo tiempo el desarro-
llador 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 desarrolla-
dor intenta emplear los fragmentos del programa existentes o aplica herramien-
tas que permiten producir programas de trabajo con rapidez.
Hay una pregunta, ¿qué hacer con el prototipo una vez cumplido el propósito
descrito?
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 desarrolla-
dores 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 inme-
diato. 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 sis-
tema operativo o un lenguaje de programación inadecuado solo porque
está disponible y cono-
cido; se puede imple-
mentar un algoritmo in-
eficiente solo para mos-
trar capacidad.
A pesar de que tal vez surjan
problemas, la construcción de
prototipos puede ser un para-
digma efectivo para la ingenie-
ría del software. La clave es de-
finir las reglas del juego desde
el principio; es decir, el cliente
y el desarrollador se deben po-
ner de acuerdo en que el proto-
tipo se construya y sirva como
un mecanismo para la defini-
ció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.
Implantación radical vs implantación descendente conservadora
El ciclo de vida del proyecto estructurado permite que más de una actividad
realice simultáneamente. Dicho de otra manera: en la situación más extrema,
todas las actividades del ciclo de vida estructurado se podrían estar realizando
simultáneamente. En el otro extremo, el administrador del proyecto podría adop-
tar el enfoque secuencial, que implica terminar completamente una actividad an-
tes 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 paralela-
mente 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 siguiente. Existe un infinito número de op-
ciones entre los extremos radical y conservador. Un administrador de proyecto
podría decidir terminar el 75% de la actividad de encuesta, seguido por la termi-
nació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 posteriormente

podrían refinarse al pasar por segunda vez por el ciclo de vida entero del pro-
yecto. O bien, el administrador podría decidir terminar todas las actividades de
encuesta y de análisis, seguido por la terminación del 50% del diseño y el 50%
de la implantación. Las posibilidades son interminables.
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 suele usarse en proyectos más grandes, en los que
se invierten cantidades enormes de dinero y para los cuales se requiere
análisis y diseño muy detallados para evitar desastres subsecuentes.
 Sin embargo, cada proyecto es diferente y requiere de su propia combina-
ción de implementación descendente conservadora y radical. Para tratar la
naturaleza individual de cada proyecto, el administrador debe estar dis-
puesto a modificar su enfoque en mitad del camino si es necesario.
Ciclo de vida en espiral
Este ciclo puede considerarse una variación del modelo con prototipo, fue dise-
ñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos repe-
titivos para ir ganando madurez en el producto final. A medida que el ciclo se
cumple (el avance de la 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 riesgo que se emplea para conducir sistemas intensivos de inge-
niería de software concurrente y con múltiples usuarios. Tiene dos característi-
cas 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 facti-
bles 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 pro-
ducen versiones cada vez más completas del sistema desarrollado.
Un proceso en espiral se divide en un conjunto de actividades del marco de tra-
bajo 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 de la 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 espe-
cificación del producto; los pasos subsecuentes alrededor de la espiral se pue-
den 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 pla-
neación resulta en ajustes el plan del proyecto. Los costos y el itinerario se ajus-
tan con base en la retroalimentación derivada de la relación con el cliente des-
pué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 soft-
ware, 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 pro-
ceso, el 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 cons-
trucción de prototipos en cualquier etapa evolutiva del producto. Mantiene el en-
foque sistemático de los pasos que sugiere el ciclo de vida clásico, pero lo incor-
pora 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 to-
das 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 ite-
ración.
 Análisis de riesgo: De acuerdo con el relevamiento de requerimientos deci-
dimos 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 solicita-
dos por el cliente en la siguiente iteración.

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 opera-
ció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 si-
guiente. En realidad, es un ciclo de vida común a todos los sistemas desarrolla-
dos 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
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 exhaus-
tiva.
 Necesidad de desarrollar sistemas en entornos cambiantes (sujetos a
normas legislativas, mejora continua del producto para hacer frente a
desarrollos de la competencia, etc.).
Ciclo de vida en cascada con subproyectos

El modelo de ciclo
de vida cascada
con subproyectos
divide el proyecto
en subetapas para
desarrollar en para-
lelo las diferentes
etapas del modelo
de ciclo de vida en
cascada. Suele
usarse mucho
cuando se cuenta
con un plantel de
programadores nu-
merosos. Es útil por
el número de per-
sonas trabajando,
pero puede dete-
nerse el proyecto
temporalmente por la dependencia entre las subetapas.

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 re-
troalimentación
entre el análisis
y el manteni-
miento y otra
entre el diseño y el debugging. El ciclo de vida diseñado por Alan Davis facilita
la corrección lo cual hace muy aconsejable su uso para desarrollo de software
simple pero donde se necesita una confiabilidad muy alta.
Ciclo de vida tipo Sashimi
El Modelo de Ciclo de Vida Sashimi permite
un solapamiento entre las fases disminu-
yendo la generación de la documentación,
pero es mucho más difícil controlar el pro-
yecto 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.
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 me-
todologías a seguir para la creación de pro-
ductos 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 in-
dependiente 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 re-
utilizable.
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.
Debido a todo esto se considera que el ciclo de vida orientado a objetos es ite-
rativo e incremental.
Seguidamente veremos un tipo de ciclo de vida orientado a objetos más conoci-
dos, que es además el más representativo, el modelo fuente.
Ciclo de vida orientado a objetos: modelo fuente
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 activi-
dades
 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 Planifi-
cació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.
4. 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, todos los miembros
del equipo sin duda se verán influenciados por las siguientes importantes cues-
tiones:
 Productividad
 Confiabilidad
 Mantenibilidad
Desde luego, todo mundo está a favor de la productividad. Pero hace una gene-
ració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 pro-
gramadores de los años 60 trabajaban largas horas (aunque no siempre en ho-
rarios 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.
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 pro-
blema: 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 di-
ferentes:
 Retraso visible. Sistemas nuevos que los usuarios han pedido oficial-
mente 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 si-
quiera 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 dis-
minuir el tiempo requerido para desarrollar un nuevo sistema.
CONFIABILIDAD
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 alta-
mente 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 pu-
diera 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.
Muchos errores de software jamás se reportan porque el individuo o la organi-
zació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 descui-
dado 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 si-
guiente.
La forma de esta curva recibe influencias de buen número de factores. Por ejem-
plo, cuando el sistema se entrega por primera vez a los usuarios finales. A me-
nudo no pueden ponerlo a trabajar a su máxima capacidad. Lleva tiempo con-
vertir 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 opera-
ció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 soft-
ware 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.
Existen tres aspectos deprimentes en la figura. 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 repre-
senta el número total de errores descubiertos en función del tiempo, es atroz-
mente 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 opera-
cionales o modificaciones para reflejar cambios en los requerimientos del usuario
final del sistema.
El mantenimiento de software es un problema primordial en muchas organiza-
ciones, 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, modifica-
ción, conversión, mejoramiento o corrección de errores en algún programa de
computadora que otra persona escribió hace mucho. Y es caro.
Si fuera simplemente un caso de que el software fuese malo, se podría conside-
rar desecharlo o reemplazarlo. Pero muchas organizaciones jamás han capitali-
zado su software (los costos se determinan cada año), y sus políticas de admi-
nistració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 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 fun-
ciona 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 especi-
ficaciones funcionales desarrolladas por los analistas han progresado gradual-
mente, desde novelas victorianas absolutamente inmantenibles (miles de hojas
de texto narrativo) a modelos gráficos del sistema hechos a mano, y hasta mo-
delos generados y mantenidos por computadora.

BIBLIOGRAFÍA
Hawryszkiewycz, I.T. (1990) “Introducción al análisis y diseño de sistemas con
ejemplos prácticos”, Madrid. Anaya
Kendall y Kendall (1997). Análisis y Diseño de Sistemas. Sexta edición. México:
Pearson Education
Pressman, Roger S. Ingeniería de Software. Un enfoque práctico. McGraw-Hill.
Rivas Aquino, Cynthia. Material de base de la Asignatura.
Schach, S. (2006). Análisis y diseño orientado a objetos. Sexta edición. México:
McGraw-Hill
Senn, James. Análisis y diseño de sistemas de información. McGraw-Hill
Yourdon, E. (1993). Análisis Estructurado Moderno. México: Prentice-Hall Hispa-
noamericana, S.A.
Introducción a Análisis de Sistemas Módulo 2 - Prof. Cynthia Rivas Aquino
TEMA VIDEO
Unidad 2 Introducción al Análisis https://vimeo.com/109155702
de Sistemas Clase 2 Parte 1
Teórico
Teórico
Práctico
Práctico


Unidad Ii Relevamiento de Datos: Lic. Viviane Oliveira - Introducción Al Análisis de Sistemas - Unidad 2

Cargado por

Copyright:

Formatos disponibles

Unidad Ii Relevamiento de Datos: Lic. Viviane Oliveira - Introducción Al Análisis de Sistemas - Unidad 2

Cargado por

Información del documento

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

Unidad Ii Relevamiento de Datos: Lic. Viviane Oliveira - Introducción Al Análisis de Sistemas - Unidad 2

Cargado por

Copyright:

Formatos disponibles

UNIDAD II

Lic. Viviane Oliveira – Introducción al Análisis de Sistemas – Unidad 2

INTRODUCCIÓN DE UNIDAD DE APRENDIZAJE

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 1

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 2

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 3

 costo de hacer un estudio  Factibilidad técnica

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 6

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 7

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 8

IV. Ciclo de vida de un Sistema

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 11

A continuación, explicaremos cada una de estas funciones o fases:

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 12

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 13

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 14

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 16

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 17

En resumen, el mantenimiento es un proceso continuo que se realiza a lo largo

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 18

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 19

Ciclo de vida estructurado

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 20

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 22

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 24

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 26

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 27

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 28

Ciclo de vida en cascada con subproyectos

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 30

4. Consideraciones en el desarrollo de sistemas

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 32

usuarios. En la mayoría de los casos, llega un momento en el cual el sistema

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 35

Introducción al Análisis de Sistemas Lic. Viviane Oliveira Unidad 2 – Página 36

También podría gustarte