Ciclo de vida del desarrollo de sistemas.

El desarrollo de sistemas es un proceso que consiste en dos etapas

principales de anlisis y diseo de sistemas; comienza cuando la gerencia, o en
algunas ocasiones el personal de desarrollo de sistemas, se da cuenta de que
cierto sistema del negocio necesita mejorarse. El ciclo de vida del desarrollo de
sistemas es el conjunto de actividades de los analistas, diseadores y usuarios,
que necesitan llevarse a cabo para desarrollar y poner en marcha un sistema de
informacin.
Es esencial definir previamente los requisitos de todos los elementos del
sistema, as como un modelo de vida para cada uno de los proyectos de
programacin, puesto que permite clasificar y controlar las diferentes actividades
necesarias para el desarrollo y mantenimiento del producto.
Etapas del ciclo de vida de un sistema.
El ciclo de vida del producto de programacin se divide en una serie de
actividades sucesivas; cada fase requiere informacin de entrada, procesos y
resultados, bien definidos. El ciclo de vida del desarrollo de sistemas consiste en
las siguientes actividades:
1. Definicin y Planificacin del Proyecto.
2. Anlisis del Sistema (Determinacin de requerimientos).
3. Diseo del sistema.
4. Codificacin, Programacin, Implementacin o Desarrollo del
software.
5. Prueba o Testeo del Sistema.
6. Implantacin.
7. Mantencin.

ESTUDIO DE LAS ETAPAS DEL DESARROLLO DE SISTEMAS
1.- Definicin y Planificacin del Proyecto (Investigacin Preliminar).
Cuntas veces se est en situaciones en donde se pregunta si no existe una
mejor manera de hacer algo? Una compaa en crecimiento, puede contemplar a
los sistemas de informacin computarizados como una forma de crecer
continuamente, sin tener dificultades en varios procesos, como por ejemplo en el
proceso de pedidos de clientes. Una peticin se puede iniciar por varias razones,
pero la clave es que alguna persona de la empresa, ya sea un gerente, un
empleado o un especialista de sistemas, inicie el requerimiento de un sistema de
informacin.
La siguiente tabla muestra las causas por las cuales las organizaciones
toman la decisin estratgica de bordar proyectos sobre sistemas de informacin
en funcin de los parmetros mejorables de sta.
1. Capacidad.
Mayor velocidad de procesamiento
Incremento en el volumen
Recuperacin ms rpida de la informacin
2. Control.
Mayor exactitud
Mejora de la consistencia
3. Comunicacin.
Mejoras en la comunicacin
Integracin de reas de la empresa
4. Costos.
Monitorizacin de costos
Reduccin de costos
5. Ventajas competitivas.
Atraer clientes
Dejar fuera a la competencia
Mejores acuerdos con los proveedores
Desarrollo de nuevos productos
Por todo ello es importante conocer como se deben iniciar este tipo de
proyectos, as como las distintas formas de adquirir la informacin necesaria para
su posterior realizacin.
La solicitud de proyecto, aunque no existe un formato nico y depende de la
Organizacin, debe contener la informacin mnima, a fin de poder ser estudiada
por el comit. Esta informacin a contener es:
Cul es el problema?
Detalles del problema
Importancia del problema
Cul es la solucin aportada por el usuario?
En qu medida ser de ayuda un sistema de informacin?
Qu otras personas conocen el problema y se puede contactar?
Clarificacin de requerimientos.
El analista debe de observar en forma objetiva lo que ocurre en la empresa,
ya que muchas veces los requerimientos no estn claramente establecidos, por lo
que, el proyecto requerido debe examinarse para determinar precisamente lo que
desea la empresa.
La segunda tarea de la planificacin del desarrollo de Software es la
estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de
Software, esto simula a una pirmide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de
desarrollo, en segundo nivel de la pirmide se encuentran los Componentes
reutilizables. Y en la parte mas alta de la pirmide se encuentra el recurso
primario, las personas (el recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del Recurso
Informes de disponibilidad
Fecha cronolgica en la que se requiere el recurso
Estudio de factibilidad.
Es determinar si el proyecto es factible. Los aspectos para determinar la
factibilidad del proyecto son:
1. Factibilidad Estratgica.
Es consistente con el plan de informtica el cual a su vez esta alineado
con el plan estratgico de la organizacin.
Hay capacidad de convocatoria, se puede motivar y hacer participar a
los usuarios, equipo tcnico y otras unidades relacionadas.
Claridad de objeticos del proyecto.
2. Factibilidad tcnica.
Se debe de investigar si se puede realizar el trabajo para el proyecto con
el equipo actual, el personal y el software disponible, dentro de ellas:
Se puede integrar al sistema o arquitectura actual de la organizacin.
Evaluacin de estrategias alternativas para el desarrollo e implantacin.
Existe tecnologa, conocimiento y experiencia disponible para
desarrollar, implantar y satisfacer los requerimientos del usuario.
3. Factibilidad operativa.
Se debe de investigar si el sistema que se desarrolla se pondr en
marcha, si habr resistencia de los usuarios en cuanto a este, entre ellas:
Si el sistema trabajar adecuadamente cuando sea instalado.
Si el sistema ser efectivamente usado.
Si los procedimientos de administracin sern realizables.
4. Factibilidad Temporal.
Existen plazos razonables para la realizacin del proyecto y holguras para
situaciones de problemas, errores o emergencias.
5. Factibilidad Legal.
Qu normas y/o leyes afectan o se vern afectadas por la creacin del
sistema?
6. Factibilidad econmica.
Qu beneficios tendr la creacin del sistema en cuanto a
costo/beneficios?
Evaluacin de Horas-Hombre para el desarrollo e implantacin del
Sistema de Informacin.
Costo del Anlisis y Diseo del Sistema de Informacin.
Costo del hardware, software bsico y plataforma de comunicaciones.
Costo de las aplicaciones de software y/o del desarrollo del software.
Costo de puesta en marcha y entrenamiento de usuarios.
Costo de operacin y mantencin.

2.- Anlisis del Sistema (Determinacin y Especificacin de
requerimientos).
Los analistas al trabajar con los empleados de la empresa, deben estudiar el
proceso que se efecta actualmente para as poder contestar las preguntas claves
de esta fase.
Qu y cmo se est haciendo?
Qu tan frecuentemente ocurre?
Qu tan grande es la cantidad de transacciones?
Existe algn problema?, si el problema existe Qu tan serio es y cul
es su principal causa?
Para que el analista pueda contestar estas preguntas deber hablar con
diferentes grupos de empleados para as recabar diferente opiniones sobre las
causas por las que se originan las cosas. Los mtodos de recoleccin pueden ser
cuestionarios a grupos de personas o individuales, tambin se requiere estudiar
los manuales y reportes, observar los comportamientos y actividades, recabar
formas y documentos para entender los procesos. Una vez, recopilada la
informacin, los analistas estudian los requerimientos para identificar las
caractersticas del nuevo sistema.
(Determinacin y Especificacin de Requerimientos).
Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de
informacin, tienen que profundizar en un rea de la Organizacin, de la cual
tienen poco conocimiento. Del trabajo del analista se espera que se produzca una
mejora en el sistema. As que el analista debe ser capaz de:
Aprender los detalles y procedimientos del sistema en uso.
Prever necesidades futuras de la Organizacin, en funcin del
crecimiento, cambios futuros en el sector, introduccin de nuevas
tecnologas etc.
Documentar detalles del sistema actual para su comprensin y
discusin por otros profesionales de la organizacin.
Evaluar la efectividad y eficiencia del sistema actual y sus
procedimientos.
Recomendar modificaciones del sistema actual, o proponer un nuevo
sistema completo, justificndolo en cada caso.
Documentar las caractersticas del nuevo sistema con un nivel de
detalle que permita comprender a otros sus componentes.
Fomentar la participacin de gerentes y empleados en todo el proceso.
A todas estas tareas, se les une la de cumplir los plazos establecidos. De
modo que una de las claves del xito ser la de estructurar el proceso para el
desarrollo del nuevo sistema.

Requerimiento.
En la ingeniera de sistemas, un requerimiento es una necesidad
documentada sobre el contenido, forma o funcionalidad de un producto o servicio.
Se usa en un sentido formal en la ingeniera de sistemas o la ingeniera de
software.
En la ingeniera clsica, los requerimientos se utilizan como datos de entrada
en la etapa de diseo del producto. Establecen QU debe hacer el sistema, pero
NO CMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase
de anlisis conceptual del proyecto. Esta fase puede dividirse en recoleccin de
requerimientos de los inversores, anlisis de consistencia e integridad, definicin
en trminos descriptivos para los desarrolladores y un esbozo de especificacin,
previo al diseo completo.
Qu es un Requerimiento?
Condicin o capacidad que un usuario necesita para poder resolver un
problema o lograr un objetivo (IEEE).
Condicin o capacidad que debe exhibir o poseer un sistema para
satisfacer un contrato, estndar, especificacin, u otra documentacin
formalmente impuesta (IEEE).
Una condicin o capacidad que debe ser conformada por el sistema
(RUP).
Algo que el sistema debe hacer o una cualidad que el sistema debe
poseer (Robertson - Robertson).
Tipos de Requerimientos.
En ingeniera de sistemas existen tres tipos de requerimientos.
Un requerimiento funcional puede ser una descripcin de lo que un
sistema debe hacer. Este tipo de requerimiento especifica algo que el
sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.;
especifica algo sobre el propio sistema, y cmo debe realizar sus
funciones. Algunos ejemplos de aspectos solicitables son la
disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma
indirecta al producto. Estas pueden ir desde la compatibilidad con cierto
sistema operativo hasta la adecuacin a leyes o regulaciones aplicables
al producto
Una coleccin de requerimientos describe las caractersticas o atributos del
sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto
debe ser decidido en la etapa de diseo por los diseadores.
En la ingeniera de software se aplica el mismo significado, slo que el
nfasis est puesto en el propio software.
Caractersticas de los Requerimientos.
Los requerimientos bien formulados deben satisfacer varias caractersticas.
Si no lo hacen, deben ser reformulados hasta hacerlo.
Necesario:
Lo que pida un requerimiento debe ser necesario para el producto.
No ambiguo:
El texto debe ser claro, preciso y tener una nica interpretacin posible.
Conciso:
Debe redactarse en un lenguaje comprensible por los inversores en
lugar de uno de tipo tcnico y especializado, aunque an as debe
referenciar los aspectos importantes
Consistente:
Ningn requerimiento debe entrar en conflicto con otro requerimiento
diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre
los distintos requerimientos debe ser consistente tambin.
Completo:
Los requerimientos deben contener en s mismos toda la informacin
necesaria, y no remitir a otras fuentes externas que los expliquen con
ms detalle.
Alcanzable:
Un requerimiento debe ser un objetivo realista, posible de ser alcanzado
con el dinero, el tiempo y los recursos disponibles.
Verificable:
Se debe poder verificar con absoluta certeza, si el requerimiento fue
satisfecho o no. Esta verificacin puede lograrse mediante inspeccin,
anlisis, demostracin o testeo.
Estas caractersticas suelen ser subjetivas, es decir, no pueden ser
calculadas de forma automtica por ningn sistema. Por ello, se tiende a medir
otras mtricas o indicadores que s que pueden ser calculados de forma
automtica y que, de algn modo, pueden sustituir o mapear con esta lista de
caractersticas.
Determinacin de requerimientos
Determinar requerimientos consiste en estudiar un sistema para conocer
como trabaja y donde es necesario efectuar mejoras.
Un requerimiento es una caracterstica que debe incluirse en el nuevo
sistema. Esta puede ser la inclusin de determinada forma para capturar o
procesar datos, producir informacin, controlar una actividad de la empresa o
brindar soporte a los directivos.
Los analistas de sistemas no trabajan como directivos o empleados de los
departamentos de usuarios, no tiene los mismos conocimientos, hechos y detalles
que los usuarios y directivos de estas reas. Por lo tanto el primer paso del
analista es comprender la situacin.
El primer paso del analista es comprender la situacin actual.
Actividades de la Determinacin de Requerimientos
1. Anticipacin de Requerimientos
Prever las caractersticas del sistema con base en la experiencia
previa. Esto puede llevar al analista a investigar reas y aspectos que
de otra forma no seran tomados en cuenta.
La experiencia permite anticipar requerimientos para el nuevo
sistema.
2. Investigacin de Requerimientos
Estudio y documentacin del sistema actual utilizando para ello
tcnicas para hallar hechos, anlisis de flujos de datos y anlisis de
decisin.
Es la actividad ms importante.
3. Especificacin de Requerimientos
Anlisis de los datos que describen el sistema para determinar qu
tan bueno es su rendimiento, qu requerimientos deben satisfacer y las
estrategias para alcanzarlos.
3.- Diseo.
El diseo de un sistema de informacin produce los elementos que
establecen cmo el sistema cumplir los requerimientos identificados durante el
anlisis del sistema. Para efectos de anlisis el diseo se divide en Diseo Lgico
y Fsico.
El diseo del sistema es la estrategia de alto nivel para resolver problemas y
construir una solucin. ste incluye decisiones acerca de la organizacin del
sistema en subsistemas, la asignacin de subsistemas a componentes hardware y
software, y decisiones fundamentales conceptuales y de poltica que son las que
constituyen un marco de trabajo para el diseo detallado.
El primer paso en el diseo de sistemas es identificar los informes y las
salidas que el sistema producir; a continuacin los datos especficos de cada uno
de stos se sealan, incluyendo su localizacin exacta sobre el papel, la pantalla
de despliegue o cualquier otro medio. El diseo tambin describe los datos
calculados o almacenados que se ingresaran. Los datos y los procedimientos de
clculo se describen con detalle. Se seleccionan las estructuras de los archivos y
los dispositivos de almacenamiento, como son discos o cintas magnticas o papel.
Los procedimientos deben de mostrar cmo se van a procesar los datos y cuales
van a ser las salidas. Los documentos que contienen las especificaciones del
diseo se pueden representar por medio de los diagramas, tablas y smbolos
especiales. El ltimo paso del diseo detallado es pasar la informacin al grupo de
programacin que inicie el desarrollo del software.
El objetivo del diseo es producir un modelo o representacin que se va a
construir posteriormente. El proceso de diseo combina la institucin y los criterios
basados en la experiencia en la construccin de las entidades similares; un
conjunto de principios y/o heursticas
1
que guan la evolucin del modelo, un
conjunto de criterios que permiten juzgar la calidad y un proceso de iteracin
(repeticin) que lleva como fin ultimo a una representacin definitiva del diseo.
El Diseo es el ncleo tcnico del proceso de ingeniera de software y se
aplica independientemente del paradigma del desarrollo usado.

1
Heurstica es sinnimo de algoritmo.
Diseo Lgico. (Anlisis Estructurado
2
o Anlisis de Flujos de Datos)
El anlisis estructurado, como todos los dems mtodos de anlisis de
requisitos, es una actividad de construccin de modelos. Mediante una notacin
que es nica de este mtodo, se crean modelos que reflejan el flujo y el contenido
de la informacin (datos y control); se parte el sistema funcionalmente y, segn los
distintos comportamientos, se establece la esencia de lo que se debe construir.
La tarea del anlisis de sistemas, con lleva ms que slo realizar anlisis de
requisitos, pero es en eso donde se focalizar la discusin.
Una de las principales labores del analista es descubrir detalles y
documentar la poltica de un negocio que pudiera existir slo en forma implcita,
"transmitidas de generacin en generacin" por los usuarios, nunca documentadas
formalmente. El analista debe distinguir entre sntomas, problemas del usuario y
causas. Con sus conocimientos de la tecnologa de los computadores, el analista
debe ayudar al usuario a explorar aplicaciones novedosas y ms tiles de stos
as como nuevas formas de hacer negocios. Aunque muchos de los sistemas
antiguos slo se limitaban a perpetuar el negocio original del usuario, pero a
velocidades electrnicas, hoy en da los analistas se enfrentan al desafo de
ayudar al usuario a encontrar productos y mercados radicalmente innovadores,
con la ayuda del computador.
El Anlisis de Sistemas trata bsicamente de determinar los objetivos y
lmites del sistema objeto de anlisis, caracterizar su estructura y funcionamiento,
marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar
sus consecuencias. Dependiendo de los objetivos del anlisis podemos
encontrarnos ante dos problemticas distintas:
1. Anlisis de un sistema ya existente para comprender, mejorar, ajustar
y/o predecir su comportamiento.
2. Anlisis como paso previo al diseo de un nuevo sistema-producto.
Los analistas desean conocer las respuestas a cuatro preguntas:
Qu procesos integran el sistema? (se refiere al subsistema
Qu datos emplea cada proceso?
Qu datos son almacenados? (producto mas resultado)
Qu datos entran y salen del sistema? (que datos se emiten del sistema)
Como vemos el elemento fundamental en una Organizacin (sistema de
informacin), van a ser los datos. Los datos son las guas de las actividades de la
Organizacin, inician eventos, son procesados para dar informacin til al
personal, etc.

2
Fue creado por yourdon creo toda una terminologa y metodologa para crear un sistema, es lo
que ms se ve el mercado junto con UML.

Seguir el flujo de datos por todos los procesos de la organizacin, adems de
ser la finalidad del anlisis de flujo de datos, proporciona a los analistas
informacin de cmo se alcanzan los objetivos en la Organizacin.
El anlisis de flujo de datos estudia el empleo de los datos en cada actividad.
Se basa en los diagramas de flujo de datos que muestra de forma grfica la
relacin entre procesos y datos, y en los diccionarios de datos que describen de
manera formal los datos del sistema y los sitios donde son utilizados.
El anlisis puede pensarse de tal manera que se estudien actividades del
sistema desde el punto de vista de los datos, donde se originan, cmo se utilizan o
cambian, hacia dnde van. Los componentes de la estrategia de flujo de datos
abarcan tanto la determinacin de los requerimientos como el diseo de sistemas.
Una notacin
3
bien establecida facilita la documentacin del sistema actual y su
anlisis por todos los participantes en el proceso de determinacin de
requerimientos.
Los analistas deben trabajar con los usuarios para hacerles comprender el
funcionamiento del sistema actual y el sistema futuro, para ello se hace
aconsejable utilizar un lenguaje comn, sencillo y fiable, estas son las
caractersticas de los diagramas de flujo de datos. Los usuarios pueden hacer
sugerencias para modificar los diagramas con la finalidad de describir las
actividades con mayor exactitud, y permitir evitar los errores desde el inicio
pudiendo prevenir una posible falla del sistema.
Diseo Fsico
El diseo de software es un proceso mediante el que se traducen los
requisitos en una representacin del software. Inicialmente, la representacin
describe una visin holstica del software. Posteriores refinamientos conducen a
una representacin de diseo que se acerca mucho al cdigo fuente.
En el diseo se realizan dos pasos. El diseo preliminar se centra en la
transformacin de los requisitos en los datos y arquitectura del software. El diseo
detallado se ocupa del refinamiento de la representacin arquitectnica que lleva a
una estructura de datos detallada y a las representaciones algortmicas del
software.
Dentro del contexto de los diseos preliminar y detallado, se llevan a cabo
varias actividades de diseo diferentes. Adems del diseo de datos, del diseo
arquitectnico y del diseo procedimental, muchas aplicaciones requieren de un
diseo de la interfaz. El diseo de la interfaz establece la disposicin y los
mecanismos para la interaccin hombre mquina (no cubierto por las herramientas
del diseo estructurado).
El diseo de sistemas se ocupa de desarrollar las directrices propuestas
durante el anlisis en trminos de aquella configuracin que tenga ms
posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista

3
Esquema o paradigma.
funcional
4
como del no funcional
5
(lo que antes hemos denominado
constricciones). El proceso de diseo de un sistema complejo se suele realizar de
forma descendente:
Diseo de alto nivel (o descomposicin del sistema a disear en
subsistemas menos complejos).
Diseo e implementacin de cada uno de los subsistemas:
Especificacin consistente y completa del subsistema de acuerdo con
los objetivos establecidos en el anlisis.
Desarrollo segn la especificacin.
Prueba.
Integracin de todos los subsistemas.
Validacin del diseo.
Dentro del proceso de diseo de sistemas hay que tener en cuenta los
efectos que pueda producir la introduccin del nuevo sistema sobre el entorno en
el que deba funcionar, adecuando los criterios de diseo a las caractersticas del
mismo. En este contexto est adquiriendo una importancia creciente la adaptacin
de todo sistema-producto a las capacidades de las personas que van a utilizarlo,
de forma que su operacin sea sencilla, cmoda, efectiva y eficiente. De estas
cuestiones se ocupa una disciplina, la ergonoma
6
, que tiene por objeto la
optimizacin de los entornos hombre-mquina. Si bien en un principio estaba
centrada en los aspectos antropomtricos de la relacin hombre-mquina, en la
actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos
(anlisis, interpretacin, decisin, comunicacin y representacin del
conocimiento).
As, con respecto al diseo de herramientas software, la ergonoma tiene
mucho que decir en cuestiones relacionadas con la disposicin de informaciones
en pantalla, profundidad de mens, formato de iconos, nombres de comandos,
control de cursores, tiempos de respuesta, manejo de errores, estructuras de
datos, utilizacin de lenguaje natural, etc.
El Diseo de software cambia continuamente medida que evolucionan
nuevos mtodos, mejores anlisis esta en una fase relativamente temprana en el
desarrollo carece de profundidad, flexibilidad y naturaleza cuantitativa de otras
disciplinas de la ingeniera, sin embargo existen mtodos, criterios y notacin para
hacer un diseo exitoso.


4
Habla de procedimientos que involucran el sistema
5
Mantenibilidad del sistema
6
QUE SE ADAPTA AL USUARIO

Relacin entre el modelo de diseo lgico y el modelo de diseo fsico.

Componentes del diseo fsico:
1. Diseo de datos.
Transforma el modelo de dominio de la informacin creado durante el
anlisis en las estructuras de datos necesarias para implementar el
software.
2. Diseo de la Interfaz.
Describe como se comunica el software consigo mismo, con los
sistemas que operan con l y con los operadores que los emplean.
3. Diseo Procedimental.
Transforma elementos estructurales de la arquitectura del programa
en una descripcin procedimental de los componentes del software.
4. Diseo Arquitectnico.
Define la relacin entre los principales elementos estructurales del
programa.
La importancia del diseo del software reside en la calidad. El diseo es la
nica manera de traducir los requisitos del cliente un sistema o producto de
software.
4.- Codificacin, Programacin, Implementacin o Desarrollo del
software.
Los desarrolladores pueden instalar o modificar software que se haya
comprado (software comercial), o pueden escribir nuevos programas diseados a
la medida; la decisin depende del costo de cada una de las opciones dadas, el
tiempo y disponibilidad de los programadores. Los programadores de software son
tambin responsables de la documentacin del programa y de incluir los
comentarios que expliquen cmo y porqu se utiliz cierto procedimiento. La
documentacin es esencial para probar el programa y darle mantenimiento una
vez que se ha puesto en marcha.
Cuando termina la etapa de diseo, normalmente comienza la etapa de
programacin. La fase de programacin o implantacin de un proyecto involucra la
escritura de instrucciones en un lenguaje de programacin para implantar lo que el
analista ha especificado y el diseador ha organizado en mdulos.
Durante esta fase el analista tiene un papel importante. En el caso extremo,
una vez terminada su labor de especificacin del sistema pasa algn tiempo con el
equipo de diseo durante las primeras etapas del diseo, pero luego deber
comenzar con otro proyecto. Sin embargo, existen razones por las cuales el
analista debe permanecer involucrado en el proyecto al comenzar la actividad de
programacin:
Por ser lder del proyecto debe estar involucrado en el mismo hasta la
prueba final, la aceptacin y entrega al usuario final. Adems debe
verificar que el cdigo es de alta calidad y que las pruebas a los
programas se efectuaron de manera adecuada.
El analista forma parte del grupo que escribe casos de prueba que se
usaran para probar los programas. Es probable que se adhieran en esta
actividad uno o ms usuarios por ser los ms aptos para pensar en
casos excepcionales y pocos usuales de prueba. El desarrollo de
pruebas puede empezar tan pronto como se termina la especificacin.
Dado a que por lo pronto solo conoce el contenido lgico de las
entradas y salidas, debe esperar a que el modelo de implantacin del
usuario quede terminado para conocer el formato fsico de los mismos y
poder conocer las restricciones operacionales (tiempo de respuesta,
volmenes, etc.) que se necesitan probar.
El analista, por estar involucrado desde el principio en el proyecto, es el
candidato ideal para estar involucrado en el desarrollo de manuales
para el usuario, preparacin de los usuarios o en la planeacin de la
instalacin del nuevo sistema y conversin de datos desde el otro
sistema. En la mayor parte de los casos, esto puede llevarse a cabo de
manera paralela con la programacin y prueba del nuevo sistema.
En el caso de que la especificacin no se comprenda, pueda estar
incompleta, ser inconsistente o contradictoria es necesario que el
programador consulte peridicamente para revisar y aclarar las
especificaciones. Otra variante puede ser la solicitud de cambio de
especificacin por ser demasiado difcil de implantar.
Puede que los usuarios cambien los requerimientos, incluso cuando los
programadores estn implantando lo que decan querer.
As como el anlisis estructurado involucra una progresin continua de
modelado de alto nivel (el diagrama de flujo de datos de nivel superior) a aspectos
de modelado de bajo nivel (especificaciones de procesos y diccionario de datos) y
el proceso de diseo involucra modelos de diseo que van desde diagramas de
estructura de alto nivel hasta formas de bajo nivel como el seudocdigo y
diagrama de flujo, la programacin debe seguir este mismo patrn. Se escriben
mdulos ejecutivos de alto nivel. Luego se desarrollaran los mdulos de bajo nivel
que llevan a cabo clculos detallados, validan datos de entrada, etc.
Niveles de la organizacin que construye el sistema
La construccin de sistema mediante una organizacin constituida por
niveles es una forma de aprovechar ms eficientemente los recursos humanos
aprovechando sus experiencias y permitiendo una actualizacin constante en las
nuevas tecnologas.
Consiste en dejar que la gente con mayor experiencia
(analistas/diseadores) realice las tareas de mayor nivel y dejar la de menor nivel
a los ms novatos (programadores). Esto permite que la programacin no se
vuelva en una tarea mecnica consistiendo es la simple traduccin de las
especificaciones. De esta manera la gente mayor experimentada har no solo las
tareas de anlisis de alto nivel sino tambin las de diseo de alto nivel e incluso
escribir cdigo de alto nivel. Por otro lado, los novatos estaran involucrados en el
proyecto desde el principio (tan pronto como se terminen las tareas de anlisis de
alto nivel) y participaran en el trabajo de escribir especificaciones de procesos y
mdulos, en desarrollar entradas para el diccionario de datos y escribir cdigo
para los mdulos de nivel inferior.
Esto permite que los novatos hagan tareas creativas y codifiquen sus propias
especificaciones e involucrndolos en el proceso de anlisis desde las etapas
tempranas de su carrera. Simultneamente obligara a los ms maduros estar en
contacto con la tecnologa al hacer tareas de diseo y programacin.

5.- Prueba o Testeo.
En esta etapa el sistemas utilizado en forma experimental para asegurar que
el software no falle, es decir, que trabaje de acuerdo a las especificaciones y de la
manera en la que los usuarios esperan que lo haga. En la prueba del sistema se
examinan los datos de entrada de procesamiento y los resultados para localizar
algunos problemas inesperados. Es preferible detectar cualquier falla o anomala
antes de que la empresa ponga en marcha el nuevo sistema. La prueba debe ser
realizada por personas diferentes a aquellas que desarrollaron el sistema
(programadores), ya que de esta manera se asegura una mayor y ms completa
prueba, ya que es imparcial, lo que origina un software ms confiable y de ms
calidad.
La prueba, como su nombre lo indica, involucra ejercitar el sistema para
asegurar que produzca las salidas apropiadas y exhiba el comportamiento
adecuado para una gama amplia de entradas.
La prueba, como su nombre lo indica, involucra ejercitar el sistema para
asegurar que produzca las salidas apropiadas y exhiba el comportamiento
adecuado para una gama amplia de entradas.
Pruebas son un factor crtico para determinar la calidad del software,
entonces el objetivo de una prueba es descubrir algn error. Un caso de prueba es
bueno cuando su ejecucin conlleva una probabilidad elevada de encontrar un
error. El xito de la prueba se mide en funcin de la capacidad de detectar un error
que estaba oculto.
El diseo de casos de prueba para la verificacin del software puede significar
un esfuerzo considerable (cerca del 40% del tiempo total de desarrollo).
Cuando se construye software a medida para un cliente, se lleva a cabo una
serie de pruebas de aceptacin para permitir que el cliente valide todos los
requisitos. La mayora de los desarrolladores de productos de software llevan a
cabo un proceso denominado pruebas alfa y beta para descubrir errores que
parezca que slo el usuario final puede descubrir.
6.- Implantacin
Cuando el personal de sistemas verifica y pone en uso el equipo nuevo, se
instala la nueva aplicacin, se entrena al personal que manejar el sistema y
construyen los archivos de datos que se necesiten. Cuando estas actividades
terminan, entonces se dice que el sistema est puesto en marcha. Los
desarrolladores del sistema pueden escoger una parte (un rea o departamento)
de la empresa para probar el nuevo sistema con slo una o dos personas; a su
vez este puede estar trabajando en forma paralela con sistema anterior para
comparar resultados (beneficios).
7.- Mantencin.
Esta etapa es la ltima del ciclo de vida del desarrollo de sistemas, pero no
es el fin del sistema. Una vez instalado, la aplicacin se utilizar por muchos aos,
sin embargo, las empresas, el personal y el medio ambiente cambiarn a travs
del tiempo. Por lo tanto, la aplicacin necesitar mantenimiento; es decir, se harn
cambios y modificaciones al software, a los archivos y procedimientos para as
cubrir los nuevos requerimientos de la empresa. La puesta en marcha es un
proceso continuo.
Una analista al crear un sistema debe tener la visin de realizar un diseo
comprensible y duradero que sirva para las necesidades actuales y las
proyectadas durante varios aos. Parte de su experiencia debe encaminarse a
pronosticar cules necesidades llegarn a aparecer e incorporar cierta flexibilidad
y adaptabilidad en el sistema. Cunto mejor sea el diseo del sistema, ms fcil
ser darle mantenimiento y se requerir menos dinero de la empresa para su
mantenimiento.
La reduccin de los costos de mantenimiento es una preocupacin
importante de las empresas, ya que el mantenimiento del software, por s slo,
puede devorar hasta el 50 % del presupuesto total de procesamiento de datos. En
el mantenimiento se reflejarn costos excesivos de manera directa sobre el
diseador del sistema. Aproximadamente el 70% de los errores de software se
han atribuido a un diseo inadecuado. Desde una perspectiva de sistemas, tiene
sentido detectar y corregir los errores de diseo en el software, en su fase inicial,
cuando an es menos costoso dejar que los errores permanezcan sin identificarse
hasta realizar el mantenimiento.
El mantenimiento se realiza para mejorar un software existente, ms que
para responder a una crisis o falla de sistema. Conforme cambian los
requerimientos de los usuarios, el software y la documentacin tambin deberan
cambiar, como parte del trabajo de mantenimiento. Adems los programas podran
volverse a codificar para mejorar su eficiencia sobre el programa original. Ms de
la mitad del mantenimiento se orienta a tales tareas de perfeccionamiento.
El mantenimiento tambin se realiza para actualizar el software en respuesta
a los cambios de la organizacin. El mantenimiento de emergencia y adaptativo
cubre menos de la mitad del mantenimiento total del sistema.
Parte de las tareas del analista es asegurar que existan canales y
procedimientos adecuados para permitir una retroalimentacin acerca de las
necesidades de mantenimiento.
Los usuarios y operadores deben ser capaces de comunicar de manera
sencilla los problemas y sugerencias a quienes les dan mantenimiento al sistema.
Ser de utilidad que el analista establezca un esquema de clasificacin para
jerarquizar la importancia del mantenimiento requerido. Las peticiones clasificadas
permitirn a los programadores del mantenimiento comprender cmo los usuarios
por s mismos, consideran la importancia de sus peticiones. Estas peticiones
pueden tomarse en cuenta junto con otros factores a la hora de programar el
mantenimiento.
Una vez instalado el sistema y puesto en operacin, los analistas dejan el
proyecto. Algunos programadores se quedan para el mantenimiento. Pero la
mayora de los analistas, diseadores y programadores se transfieren a otros
nuevos proyectos.
Pero el trabajo realizado debe mantenerse durante loa 5, 10 o 20 aos de
vida operacional del sistema, tanto los programas como las especificaciones.
A la hora de realizar modificaciones, a menudo resulta ms fcil una
correccin, mejora o cambio rpido y sucio al sistema existente, que empezar a
cambiar el documento de los requerimientos y luego propagar dicho cambio al
documento de diseo y la implantacin del mismo. Esto ocurre sobre todo cuando
se necesita el cambio para arreglar un problema inmediato y urgente. La
documentacin es lo ltimo que se quiere hacer, y muchas veces no se hace.
Los sistemas de informacin tienden a ser complejos desde el principio, y se
vuelven cada vez ms complejos al pasar los aos de mantenimiento.
Sin un buen mantenimiento, cualquier sistema puede convertirse en un
misterio. La nica solucin es mantener documentacin precisa y actualizada por
la duracin del sistema mismo.