CICLO DE VIDA DEL SISTEMA

Identificacin de los 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 objetivos.
Esta etapa es imprescindible para el xito del resto del proyecto.
En la primera fase el analista debe analizar con honestidad lo que est
ocurriendo en la empresa. Despus, junto con otros miembros de la organizacin, debe
comenzar a sealar los problemas. Las oportunidades residen en las situaciones que el
analista cree poder mejorar mediante el uso de sistemas de informacin computarizados.
Al aprovechar estas oportunidades, la empresa puede obtener una ventaja competitiva o
establecer un estndar en la industria.
La identificacin de los objetivos tambin es un componente importante de la
primera fase. El analista debe descubrir primero qu trata de hacer la empresa; despus
debe ser capaz de determinar si alguno de los aspectos de las aplicaciones de los
sistemas de informacin puede ayudar a que la empresa logre sus objetivos al enfrentar
problemas u oportunidades especficos.
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 administracin de los usuarios, sintetizar
el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados.
El resultado de esta fase es un informe de viabilidad, el cual contiene la
definicin de un problema y sintetiza los objetivos. Despus, la administracin de la
empresa debe tomar una decisin 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 estn relacionados, o si los problemas no requieren un
sistema computacional, tal vez se pueda recomendar una solucin distinta y el proyecto
de sistemas no contine.
Determinacin de los requerimientos de informacin del factor humano
La siguiente fase a la que entra el analista es determinar las necesidades de los
usuarios involucrados, mediante el uso de varias herramientas, para comprender la
forma en que interactan en el contexto laboral con sus sistemas de informacin
actuales. El analista utilizar mtodos interactivos como entrevistas, muestreos e
investigacin de datos duros, adems de los cuestionarios y los mtodos discretos, como
observar el comportamiento de los encargados al tomar las decisiones y sus entornos de
oficina, y los mtodos integrales como la creacin de prototipos.

El analista utilizar estos mtodos para plantear y responder muchas preguntas

relacionadas con la interaccin humano-computadora (HCI), incluyendo preguntas tales
como: Cules son las fortalezas y limitaciones fsicas de los usuarios?, o dicho en
otras palabras, qu hay que hacer para que el sistema sea perceptible, legible y
seguro?, cmo puede disearse el nuevo sistema para que sea fcil de usar, aprender
y recordar?, cmo puede el sistema ser agradable o incluso divertido de usar?,
cmo puede el sistema apoyar las tareas laborales individuales de un usuario y buscar
nuevas formas de hacerlas ms productivas?.
En la fase de requerimientos del SDLC, el analista se esfuerza por comprender
qu informacin requieren los usuarios para realizar sus trabajos. En este punto el
analista examina cmo hacer que el sistema sea til para las personas involucradas.
Cmo puede el sistema ofrecer un mejor apoyo para las tareas individuales que se
deben llevar a cabo? Qu nuevas tareas habilita el nuevo sistema que los usuarios no
podan realizar sin l? Cmo se puede crear el sistema de manera que extienda las
capacidades de un usuario ms all de lo provisto por el sistema anterior? Cmo puede
el analista crear un sistema gratificante para los trabajadores?
Las personas involucradas en esta fase son los analistas y los usuarios, por lo
general los gerentes y los trabajadores de operaciones. El analista de sistema debe
conocer los detalles sobre las funciones del sistema actual: el quin (las personas
involucradas), el qu (la actividad de la empresa), el dnde (el entorno en el que se lleva
a cabo el trabajo), el cundo (la coordinacin) y el cmo (de qu manera particular se
realizan los procedimientos actuales) de la empresa a la que est estudiando. Despus, el
analista debe preguntar por qu la empresa utiliza el sistema actual. Puede haber buenas
razones por las cuales la empresa trabaje con los mtodos actuales, razn por la que se
deben tener en cuenta al disear un nuevo sistema.
El desarrollo gil es una metodologa orientada a objetos (OOA) para el
desarrollo de sistemas, en la cual se incluye un mtodo de desarrollo (junto con la
generacin de los requerimientos de informacin) as como herramientas de software.
Al terminar esta fase, el analista deber comprender la forma en que los usuarios
realizan su trabajo al interactuar con una computadora y deber empezar a comprender
cmo mejorar la utilidad y capacidad de uso del nuevo sistema. Tambin deber saber
cmo funciona la empresa y tener informacin completa sobre personas, objetivos,
datos y procedimientos involucrados.

Anlisis de las necesidades del sistema

Aqu tambin hay herramientas y tcnicas especiales que ayudan al analista 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
secuencia de los eventos, sirven para ilustrar a los sistemas de una manera estructurada
y grfica. 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 especificaciones.
Durante esta fase, el analista de sistemas tambin analiza las decisiones
estructuradas llevadas a cabo. Las decisiones estructuradas son aquellas para las que se
pueden determinar condiciones, alternativas de condicin, acciones y reglas de accin.
Hay tres mtodos principales para el anlisis de las decisiones estructuradas:
ingls/espaol estructurado, tablas de decisin y rboles de decisin.
En este punto del SDLC, el analista de sistemas prepara una propuesta de
sistemas en la que sintetiza todo lo que ha averiguado sobre los usuarios, la capacidad
de uso y la utilidad de los sistemas actuales; incluye un anlisis de costo-beneficio de
las alternativas y, si se requiere, hace recomendaciones. Si la administracin acepta una
de las recomendaciones, el anlisis contina por esa va. Cada problema de sistemas es
nico, por lo que nunca hay slo una solucin correcta. La manera en que se formule
una recomendacin o solucin depende de las cualidades individuales y la capacitacin
profesional de cada analista, y de su interaccin con los usuarios en el contexto de su
entorno laboral.

FORMULACIN Y ANLISIS DEL PROBLEMA

Consiste en entender de qu se trata el problema planteado y esbozar su posible

solucin, concluyendo con una clara definicin de tres aspectos: Qu es lo que nos
piden, definicin del resultado o solucin deseada (para qu). Cmo obtener lo que nos
piden (qu hacer). Qu necesitamos para obtener los resultados pedidos (con qu).
1.1.- Especificacin Funcional: Consiste en determinar las funciones que se
van a realizar (qu hacer) y sus respectivas entradas (con qu) y salidas (para qu):
ENTRADA: Son los argumentos (variables o constantes) que se requieren para resolver
un problema
PROCESO: es el procedimiento(s) u operacin(es) que deben efectuarse sobre las
entradas para obtener las salidas deseadas.
SALIDA: Son los resultados (argumentos) que se desean obtener una vez resuelto el
problema.
1.3.- Establecimiento de Restricciones y Atributos: Consiste en determinar bajo qu
restricciones se ha de operar y cuales son las medidas de rendimiento y calidad que debe
tener el sistema (programa).

Tipos de restricciones :
Econmica: de que cantidad de dinero se dispone para mantener el sistema.
Tcnicas: que equipo debe o puede utilizarse.
De personal: de que personal se dispone para mantener y operar el sistema.
Legales: que polticas, reglamentos, normas, leyes, etc, tanto internas como externas
deben acatarse.
Medidas de rendimiento y calidad:
Confiabilidad.
Grado de prueba.
Movilidad
Adaptabilidad
Mantenimiento requerido.
Seguridad y privacidad.
Eficiencia y rendimiento.
Documentacin.

Diseo del sistema recomendado

En la fase de diseo del SDLC, el analista de sistemas utiliza la informacin
recolectada antes para realizar el diseo lgico del sistema de informacin. El analista
disea los procedimientos para ayudar a que los usuarios introduzcan los datos con
precisin, de manera que los datos que entren al sistema de informacin sean los
correctos. Adems, el analista debe ayudar a que los usuarios completen la entrada de
datos efectiva al sistema de informacin mediante el uso de las tcnicas del buen diseo
de formularios y pginas Web o pantallas.
Parte del diseo lgico del sistema de informacin es idear la HCI. La interfaz
conecta al usuario con el sistema, por lo que es extremadamente importante. La interfaz
del usuario se disea 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 fsicas son el teclado (para escribir las preguntas y respuestas), los
mens en pantalla (para obtener los comandos de los usuarios) y varios tipos de
interfaces grficas de usuario (GUI) basadas en un ratn o una pantalla tctil.
La fase de diseo tambin incluye el diseo de bases de datos que almacenarn
gran parte de los datos necesarios para los encargados de tomar las decisiones en la
organizacin. Los usuarios se benefician de una base de datos bien organizada que sea
lgica para ellos y se corresponda con la forma en que ven su trabajo. En esta fase,
el analista tambin trabaja con los usuarios para disear una salida (ya sea en pantalla o
impresa) que cumpla con sus necesidades de informacin.

Por ltimo, el analista debe disear controles y procedimientos de respaldo para

proteger el sistema y los datos, y para producir paquetes de especificacin de programas
para los programadores. Cada paquete debe contener los diseos de las entradas y las
salidas, las especificaciones de los archivos y los detalles sobre el procesamiento;
tambin puede incluir rboles o tablas de decisin, UML o diagramas de flujo de datos,
junto con los nombres y las funciones de cualquier cdigo previamente escrito dentro de
la empresa o que utilice cdigo u otras bibliotecas de clases.

GUIA

Herramientas para disear algoritmos:

a) Diagramas de Flujo: representacin grfica de un algoritmo.
b) Pseudocdigo: lenguaje de especificacin de algoritmos (el algoritmo se
representa mediante palabras similares al ingls o al espaol, para facilitar tanto la
lectura como la escritura de programas.

ARQUITECTURA DE UNA BASE DE DATOS.

La arquitectura se divide en tres niveles generales: interno, conceptual y externo
Nivel Interno
Es el ms cercano al almacenamiento fsico, es decir, el que concierne a la manera
como los datos se almacenan en realidad. El esquema interno utiliza un modelo fsico de
data y describe los detalles completos de almacenamiento de data y el acceso a los
caminos de la BD
Nivel Externo
Es el ms cercano a los usuarios, es decir, el que atae a la manera cmo cada
usuario ve los datos. O nivel de vista incluye un nmero de esquemas externos o vistas
de usuario.
Nivel Conceptual
Es un nivel de mediacin entre los otros dos. Es una descripcin global de la BD que
oculta los detalles de las estructuras de almacenamiento fsico y se concentra en
describir las entidades, los tipos de data, las relaciones y constantes
MODELOS DE BASE DE DATOS.
Bases de datos jerrquicas: almacenan su informacin en una estructura
jerrquica. En este modelo los datos se organizan en una forma similar a un rbol (visto
al revs), en donde un nodo padre de informacin puede tener varios hijos. El nodo que
no tiene padres es llamado raz, y a los nodos que no tienen hijos se los conoce como
hojas. Las bases de datos jerrquicas son especialmente tiles en el caso de aplicaciones
que manejan un gran volumen de informacin y datos muy compartidos permitiendo
crear estructuras estables y de gran rendimiento.

Bases de datos de red: Este fue creado para representar relaciones de datos
complejas mas eficientes de lo que el modelo anterior permita , para mejorar el
desempeo de las bases de datos y para imponer un estndar. Este modelo es similar al
jerrquico en muchos aspectos, sin embargo la diferencia radica, en que el modelo red,
permite que un registro tenga mas de un padre, por consiguiente, las relaciones pueden
manejarse fcilmente por este modelo.
Base de datos relacional: Este es un modelo simple potente y formal para
representar la realidad, tambin ofrece una base firme para enfocar y analizar
formalmente muchos problemas relacionados con la gestin de bases de datos, como el
diseo, la redundancia, la distribucin etc. El formalismo y una base matemtica, son
las piedras angulares del modelo relacional , el elemento bsico del modelo es la
relacin y un esquema de bases de datos relacional es una coleccin de definiciones de
relaciones. En este modelo, el lugar y la forma en que se almacenen los datos no tienen
relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la
considerable ventaja de que es ms fcil de entender y de utilizar para un usuario
espordico de la base de datos. La informacin puede ser recuperada o almacenada
mediante consultas que ofrecen una amplia flexibilidad y poder para administrar la
informacin.
Base de datos multidimensionales:
Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como
creacin de Cubos OLAP. Bsicamente no se diferencian demasiado de las bases de
datos relacionales (una tabla en una base de datos relacional podra serlo tambin en una
base de datos multidimensional), la diferencia est ms bien a nivel conceptual; en las
bases de datos multidimensionales los campos o atributos de una tabla pueden ser de
dos tipos, o bien representan dimensiones de la tabla, o bien representan mtricas que se
desean estudiar.
Base de datos orientada a objetos: Este es un modelo reciente, trata de almacenar en
la base de datos los objetos completos (estado y comportamiento). Esta base de datos
debe contener todos los conceptos importantes de este paradigma de programacin:
Encapsulacin - Propiedad que permite ocultar la informacin al resto de los objetos,
impidiendo as accesos incorrectos o conflictos.
Herencia - Propiedad a travs de la cual los objetos heredan comportamiento dentro de
una jerarqua de clases.
Polimorfismo - Propiedad de una operacin mediante la cual puede ser aplicada a
distintos tipos de objetos
Base de datos distribuidas: Los datos en un sistema de la base de datos distribuida se
almacenan a travs de varios sitios, y cada sitio es manejado tpicamente por un DBMS
que pueda funcionar independiente de los otros sitios. La vista clsica de un sistema de
la base de datos distribuida debe mostrar los datos distribuidos de forma transparente,
dar la impresin de que los datos son locales.

ESTRUCTURA LGICA Y FISICA DE LA BASE DE DATOS.

Estructura fsica (hardware) Se refiere a la forma en que los datos se almacenan en el
soporte fsico, y est directamente relacionada con el tipo de soporte utilizado.
Estructura lgica (software) Es la visin de los datos que tienen el programador o el
usuario.
SISTEMAS GESTORES DE BASES DE DATOS.
Entre los diferentes tipos de base de datos, tenemos:
MySql: es una base de datos con licencia GPL basada en un servidor. Se caracteriza por
su rapidez. No es recomendable usar para grandes volmenes de datos.
PostgreSql y Oracle: Son sistemas de base de datos poderosos. Administra muy bien
grandes cantidades de datos, y suelen ser utilizadas en intranets y sistemas de gran
calibre.
Access: Es un programa Sistema de gestin de base de datos relacional creado y
modificado por Microsoft para uso personal de pequeas organizaciones. La base de
datos, es un archivo .mdb.
Microsoft SQL Server: es una base de datos ms potente que access desarrollada por
Microsoft. Se utiliza para manejar grandes volmenes de informaciones.
Un SGBD debe permitir:
Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
Construir la base de datos: guardar los datos en algn medio controlado por el mismo
SGBD
Manipular la base de datos: realizar consultas, actualizarla, generar informes.
Las caractersticas de un Sistema Gestor de Base de Datos SGBD son:
Abstraccin de la informacin. Los SGBD ahorran a los usuarios detalles acerca del
almacenamiento fsico de los datos.
Independencia. La independencia de los datos consiste en la capacidad de modificar
el esquema (fsico o lgico) de una base de datos sin tener que realizar cambios en las
aplicaciones que se sirven de ella.
Redundancia mnima. Un buen diseo de una base de datos lograr evitar la
aparicin de informacin repetida o redundante. En algunos casos la complejidad de los
clculos hace necesaria la aparicin de redundancias.
Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula,
ser necesario vigilar que aquella informacin que aparece repetida se actualice de
forma coherente, es decir, que todos los datos repetidos se actualicen de forma
simultnea.

 Seguridad. La informacin almacenada en una base de datos puede llegar a tener un

gran valor. Los SGBD deben garantizar que esta informacin se encuentra resguardada
frente a usuarios malintencionados, que intenten leer informacin privilegiada; frente a
ataques que deseen manipular o destruir la informacin; o simplemente ante las torpezas
de algn usuario autorizado pero despistado.
Control de la concurrencia. En la mayora de entornos (excepto quizs el domstico),
lo ms habitual es que sean muchas las personas que acceden a una base de datos, bien
para recuperar informacin, bien para almacenarla. Y es tambin frecuente que dichos
accesos se realicen de forma simultnea. As pues, un SGBD debe controlar este acceso
concurrente a la informacin, que podra derivar en inconsistencias.
Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los
datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos
introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de
corromper la informacin almacenada.
Respaldo y recuperacin. Los SGBD deben proporcionar una forma eficiente de
realizar copias de respaldo de la informacin almacenada en ellos, y de restaurar a partir
de estas copias los datos que se hayan podido perder.
Desarrollo y documentacin del software
En la quinta fase del SDLC, el analista trabaja con los programadores para
desarrollar el software original requerido. Durante ella, el analista desarrolla junto con
los usuarios una documentacin efectiva para el software, incluyendo manuales de
procedimientos, ayuda en lnea, sitios Web con preguntas frecuentes (FAQ) y archivos
Lame (Read Me) para incluir con el nuevo software.
Los programadores desempean un rol clave en esta fase, ya que disean,
codifican y eliminan los errores sintcticos de los programas de computadora. Para
asegurar la calidad, un programador puede llevar a cabo un recorrido por el diseo o por
el cdigo para explicar las porciones complejas del programa a un equipo formado por
otros programadores.
CODIFICACIN.
Es la escritura en un lenguaje de programacin de la representacin del
algoritmo desarrollado en la etapa de diseo. El resultado de la codificacin es un
programa fuente.
Como los usuarios estn involucrados desde el principio, la fase de
documentacin debe lidiar con las preguntas que hicieron y resolvieron junto con el

analista. La documentacin indica a los usuarios cmo deben usar el software y qu

deben hacer en caso de que ocurran problemas.
Tipos de Documentacin.
Existen varios tipos de documentacin.
Interna: Es aquella que se crea en el mismo cdigo, ya puede ser en forma de
comentarios o de archivos de informacin dentro de la aplicacin.
Externa: Es aquella que se escribe en manuales. Dentro de esta categora tambin se
encuentra la ayuda electrnica. Los tipos de Documentacin Externa son :
Documentacin de Programas
Explica la lgica del programa e incluye descripciones, diagramas de flujo, listados de
programas y otros documentos.
Documentacin para usuarios
Explica el sistema en forma general, su naturaleza y capacidades y cmo usarlo.
Si la documentacin del sistema es incompleta el diseador continuamente estar
involucrado y no podr moverse a otra asignacin. La documentacin de sistemas:
Constituye el respaldo formal de la informacin.
Facilita el conocimiento, interpretacin, comprensin y divulgacin del sistema.
Elimina los riesgos de dependencia con respecto a determinados individuos que
conocen el sistema.
Es un elemento fundamental para la adecuada capacitacin de los usuarios del
sistema y facilita la comunicacin con los mismos.
Estandarizacin Significa que los smbolos convencionales se usan en todos los
diagramas de flujo para prescribir el sistema y que en la documentacin se usen formas
estandarizadas. An cuando las normas de documentacin varan de una instalacin a
otra, es esencial que dentro de una organizacin, se utilice un solo mtodo. El uso de
procedimientos y documentacin estandarizada proporciona la base de una
comunicacin clara y rpida, adiestramiento menos costoso del personal de sistemas,
reduccin de costos de almacenamiento, y otros.
Estndares Bsicos De Documentacin
Toda documentacin que se relacione con un sistema, ya sea manual o por
computadora, sencillo o complejo debe reunir los siguientes requisitos bsicos:
Debe ser rotulada con claridad y bien organizada, con secciones claramente indicadas,
almacenarlas en carpetas e ndice.
Los diagramas debern ser claros, no aglomerados y la escritura manuscrita deber ser
legible.
La documentacin deber ser completa.
Se incluir una leyenda o explicacin de los trminos utilizados.
La documentacin siempre se conserva actualizada.
Tipos de manuales.
Manual del Usuario
Manual del Analista
Manual de Operacin

Manual de Programacin
Manual del Diseo
El Manual de Usuarios.
Expone los procesos que el usuario puede realizar con el sistema implantado. Rene la
informacin, normas y documentacin necesaria para que el usuario conozca y utilice
adecuadamente la aplicacin desarrollada. Para lograr esto, es necesario que se detallen
todas y cada una de las caractersticas que tienen los programas y la forma de acceder e
introducir informacin.
Elementos que debe incluir el Manual del Usuario
1. Diagrama general del sistema.
2. Diagrama particular detallado.
3. Explicacin genrica de las Fases del Sistema.
4. Instalacin del Sistema.
5. Iniciacin al uso del Sistema.
6. Manual de Referencia.
El Manual del Analista.
El manual del analista, tambin conocido como Manual Tcnico juega un papel
importante dentro del sistema debido a que luego de instalar el sistema y ponerlo en
produccin, se tiene la ardua tarea de darle mantenimiento para que el sistema contine
siendo operacional.
Es necesario contar con una herramienta o el manual tcnico que permita
aprender fcilmente como est integrado el sistema desde el punto de vista tcnico,
presentando claramente cada uno de los procesos del sistemas y su interrelacin para
formar el sistema completo.
Adems de indicar cada uno de los datos o informacin que se almacena en la
base de datos del sistema, sus relaciones y las transformaciones que sufren los datos
para convertirse en informacin.
Elementos que debe incluir el Manual del Analista
El diagrama funcional de todo el sistema.
La descripcin de procesos detallando E-P-S (Entrada Proceso salida).
Diagramas de flujo de procesos y algoritmos del sistema.
El diagrama Entidad-Relacin.
Estructura de datos y caractersticas fsicas y lgicas de los archivos usados.
Detalle de las condiciones especiales de ejecucin tales como banderas, palabras
claves, prerrequisitos, usos especficos de recursos.
Descripcin de interfaces con otros sistemas o aplicaciones.
Bitcora de cambios dentro de los mismos cdigos fuentes que incluya el responsable
del cambio, la fecha y la descripcin del cambio.
El manual del Analista debe ser actualizado constantemente inmediatamente
despus de hacer cualquier modificacin (mantenimiento) al sistema

El Manual de Operacin.
El Manual de Instrucciones al Operador proveer instrucciones de cmo correr
el sistema. El analista deber trabajar en conjunto con las especificaciones funcionales,
diseo del sistema y documentacin de programas para escribir el Manual de
Instrucciones al Operador. Este Manual deber estar estructurado de manera tal que
sirva de ayuda al adiestramiento del personal. El Manual de Instrucciones al Operador
deber incluir lo siguiente:
Descripcin del Programa: Incluir descripcin narrativa del programa y qu debe
hacer el Operador antes y mientras ejecuta los programas del sistema.
Flujogramas Generales del Programa: Deber incluir copia del Flujograma General del
Programa, tal como aparece en el Manual de Diseo del Sistema. Este flujograma
reflejar la interrelacin de programa a programa con los archivos correspondientes.
Adems, se indicar la frecuencia de cada programa, disposicin de cada archivo,
etiquetas de archivos de salida en cinta magntica, destino de cada copia de los informes
y algn comentario especfico de cada uno de los programas.
Parmetros: Se deber incluir una lista de todos los parmetros para ejecutar cada
programa.
Mensajes al Operador: Indicar una lista detallada de todos los mensajes, tal como
aparecen en pantalla, las posibles contestaciones y el por qu de dichas respuestas.
Planes de Resguardo (backups): Deber incluir instrucciones especficas de los
procedimientos a seguir para el mantenimiento de un resguardo
Command Procedures:
Instrucciones Especiales: En esta seccin se deber incluir un itinerario de fechas para
ejecutar cada programa (frecuencia), fecha de cierre, flujo de documentos, control de
cintas (ciclo de retencin), formas especiales de impresora y algn otro comentario que
se crea pertinente.
El Manual del Programador.
El objetivo de los manuales de programacin es familiarizar a analistas y
programadores con lo que hace cada programa en particular.
Estos manuales deben ser tcnicos, detallados y no necesitan estar escritos en
una manera entendible al usuario.
La documentacin detallada de cada programa deber incluir los siguientes
elementos que apliquen:
Nombre del Programa (cdigo)
Descripcin
Frecuencia de Procesamiento
Fecha de Efectividad
Archivos de Data
Lista de Archivos de Salida

 Lista de Informes
Datos de Prueba
Mensajes al Operador
- Pantallas (en caso que aplique)
Datos de Control para ejecutar el programa (parmetros)
Transacciones
Nombre del Programador
Fecha
El Manual de Diseo.
El objetivo primordial del manual de diseo del sistema es el de proveer a los
programadores suficiente informacin para escribir los programas de aplicaciones en
lenguaje de computador. Este manual forma parte de las especificaciones funcionales,
ya que convierte la definicin orientada al usuario en una definicin orientada a
sistemas computadorizados.
Elementos del manual de Diseo
Introduccin: Se incluir una descripcin breve de la situacin que motiv la creacin
del sistema. Se acompaar, si aplica, la base legal que justifique dicho sistema.
Descripcin General del Sistema: Deber presentar descripcin narrativa del sistema y
sus funciones. Adems, se incluirn todos los programas que componen el sistema y su
respectiva documentacin.
Flujograma: Se incluir flujograma general del sistema, en el cual se identificarn los
programas para usos, archivos e informes que componen el mismo.
Formato de Archivos, Bases de Datos y/o Bloques de Datos Formato de Archivos,
Bases de Datos a ser utilizados por el sistema, debern ser definidos y debe incluirse
una breve descripcin de cada uno de ellos. Se deber incluir el nombre del archivo y
extensin, as como la siguiente informacin para cada uno:
Copia de la librera
Definicin de DBD
Definicin de los campos de aquellos archivos que no estn configurados en libreras o
que no estn definidos en DBB (Data Base Definition)
Formato de Pantallas: Si el sistema es en lnea, deber incluir formato de las pantallas
que sern utilizadas por el sistema.

Especificaciones de Programas: Sern establecidos en la solicitud de cambio/desarrollo

de programacin. Para cada programa se debe incluir lo siguiente:
a. Identificacin del Programa (cdigo)

Descripcin, Tipo de Programa (Batch , en lnea, etc.), Nombre de Archivos de

Entrada, Nombre de Archivos de Salida, Base de Datos (cuando aplique), Nombre de
Informes
b. Descripcin del Programa: Narrativa de las funciones del programa. Se incluir la
definicin de lo que hace el programa. Deber ser lo ms clara, organizada y precisa
posible, adems de estar bien presentada.
c. Formato de Pantallas: Si el sistema es en lnea, deber incluir formato de las
pantallas utilizadas por el programa.
d. Formato de Archivos de Entrada y/o Salida (librera, DBD o definicin) y
Definicin de la Base de Datos (cuando aplique).
e. Formato de Informes: Se incluirn formatos de los informes que producir el
programa.

Prueba y mantenimiento del sistema

Antes de utilizar el sistema de informacin, 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 completa una serie de pruebas
para sealar los problemas con datos de muestra y despus 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.

Principios de la Prueba.
Hacer un seguimiento de las pruebas hasta los requisitos. Los errores ms graves
son aquellos que impiden que el software cumpla con los requisitos del cliente.
Planificar las pruebas desde antes que comiencen.

Aplicar el principio de Pareto. El 20% de las instrucciones provocan el 80% de

los errores.
Comenzar las pruebas por lo pequeo (mdulos individuales) y terminar en lo
grande (todo el sistema).
No hacer pruebas exhaustivas.

Las pruebas deben ser conducidas por un grupo independiente.

Proceso de Pruebas.
El proceso de prueba tiene dos entradas:
Configuracin del software: Incluye la especificacin de requisitos del
software, la especificacin del diseo y el cdigo fuente.
Configuracin de prueba: Incluye un plan y un procedimiento de prueba.
Diseo de Pruebas.
Pruebas de Caja Blanca. (Enfoque Estructural)
Examinan los detalles procedimentales.
Comprueban los caminos lgicos.

Examinan el estado del programa en varios puntos.

Se centra en la estructura interna del programa (analiza los caminos de ejecucin).
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes de cada mdulo.
Se utilizan las decisiones en su parte verdadera y en su parte falsa.
Se ejecuten todos los bucles en sus lmites.
Se utilizan todas las estructuras de datos internas.
Pruebas de Caja Negra. (Enfoque Funcional)
No toma en cuenta la estructura lgica.
Examinan si las entradas se aceptan de forma adecuada y si se produce un resultado
correcto.
Revisa la integridad de la informacin externa (archivos).
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,
obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
Las funciones del software son operativas
La entrada se acepta de forma correcta
Se produce una salida correcta
La integridad de la informacin externa se mantiene
Son complementarias a las de caja blanca. Pero en la prctica se hace
normalmente solo la prueba de caja negra. Errores habituales que se encuentran con
pruebas de caja negra:
*Funciones inexistentes o incorrectas.
*Errores de interfaz.
*Errores de iniciacin, comienzo o finalizacin.
*Errores en estructuras de datos o acceso a bases de datos externas.
* Errores de rendimiento.

Prueba de la interface grfica de usuario (GUI)

Hacer casos de prueba para revisar:
Ventanas.
Accesibilidad de los componentes dentro de la ventana.
Funciones operativas de la ventana (cerrar, mover, ajuste del tamao).
Nombre de cada ventana.
Colores de la ventana de acuerdo a la especificacin.

Mens.
Contexto adecuado de los mens.
Nombres claros de las opciones.
Chequear cada opcin.
Fuente y tamao de texto adecuada.
Ayuda sensible al contexto.
Entradas de datos.
Validacin de los datos de entrada.
Mensajes de error adecuados.

Pruebas de Unidad
Tambin llamadas pruebas unitarias, consisten en probar o testear piezas de
software pequeas. Dichas pruebas se utilizan para asegurar el correcto funcionamiento
de secciones de cdigo, mucho ms reducidas que el conjunto, y que tienen funciones
concretas con cierto grado de independencia.
Pruebas de Integracin.
La prueba de integracin se realiza posteriormente a las pruebas de unidad y su foco de
atencin es el diseo y la construccin de la arquitectura del software. Despus de la
integracin viene la validacin y por ltimo la prueba del sistema, sta ltima consiste
en probar el software junto con los otros elementos de la empresa o entidad, como la
gente, departamentos, la base de datos, etc.
Pruebas de Validacin.
La validacin se logra cuando el software funciona de acuerdo a las expectativas del
cliente. La validacin se consigue mediante una serie de pruebas de la caja negra que
demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que
negociar con el cliente un mtodo para resolverlas.

a) La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el

software de manera natural, con el encargado de desarrollo "mirando por encima
del hombro del usuario" y registrando errores y problemas de uso. Las pruebas
alfa se llevan a cabo en un entorno controlado.
b) La prueba beta
Se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del
software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no
est presente. La prueba beta es una aplicacin "en vivo" del software en un entorno que
no puede ser controlado por el equipo de desarrollo. El cliente registra todos los
problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares.

Como resultado, el equipo de desarrollo lleva a cabo modificaciones y as prepara una

versin del producto para toda la base de clientes.

El mantenimiento del sistema y la documentacin de este mantenimiento

empieza en esta fase y se lleva a cabo de manera rutinaria durante toda la vida del
sistema de informacin. Gran parte del trabajo rutinario del programador consiste en el
mantenimiento, por lo cual las empresas invierten una gran cantidad de dinero en este
proceso.
Ciertos procedimientos de mantenimiento, como las actualizaciones de los
programas, se pueden llevar a cabo a travs del sitio Web del distribuidor. Muchos de
los procedimientos sistemticos que emplea el analista durante el SDLC pueden ayudar
a asegurar que el mantenimiento siempre se mantenga en el nivel mnimo necesario.

TIPOS DE ERRORES:
a) Errores de compilacin: suelen ser errores de sintaxis.
b) Errores de ejecucin: suelen ser instrucciones que la computadora comprende pero
que no puede ejecutar. Ejemplo: divisiones por cero, races negativas, etc.
c) Errores de lgica: se producen en la lgica del programa, en el diseo del algoritmo.
Se detectan porque los resultados son incorrectos.
Implementacin y evaluacin del sistema
En esta ltima fase del desarrollo de sistemas, el analista ayuda a implementar el
sistema de informacin. En esta fase hay que capacitar a los usuarios para operar el
sistema. Los distribuidores se encargan de una parte de la capacitacin, pero la
supervisin de la capacitacin es responsabilidad del analista de sistemas. Adems, el
analista necesita planear una conversin 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
produccin.
La evaluacin se incluye como parte de esta fase final del SDLC principalmente
por cuestiones informativas.
En realidad, la evaluacin se realiza durante cada fase. El criterio clave que
debemos satisfacer es si los usuarios previstos estn utilizando el sistema.
Hay que tener en cuenta que a menudo el trabajo relacionado con los sistemas es
cclico. Cuando un analista termina una fase del desarrollo de sistemas y contina 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.

Una vez codificado el sistema, finalizado las pruebas y con la aceptacin del usuario
final, se lleva a cabo la fase de puesta en marcha, que a su vez se divide en seis etapas
cuyo orden y mbito depender del proyecto en cuestin:
Instalacin del hardware: En esta etapa se realiza la instalacin y verificacin de buen
funcionamiento del hardware involucrado en el uso de la aplicacin desarrollada. Se
instala el servidor y/o los equipos que requieren para el uso de la aplicacin
Instalacin del software:
Instalacin de la aplicacin.
Migracin desde el servidor de pruebas al servidor definitivo.
Migracin de datos.
En caso necesario, se migrar la informacin desde el antiguo gestor de base de
datos de la organizacin al nuevo servidor. En esta etapa ocurre el proceso de cambiar el
sistema anterior al nuevo. Existen 4 mtodos para llevar a cabo esta conversin.
Sistemas paralelos: es el mtodo ms seguro, el cual consiste en poner a trabajar los
dos sistemas en paralelo, de esta manera los usuarios siguen utilizando el sistema
anterior de manera acostumbrada aunque van teniendo mas contacto con el otro.
La data va a ser poco a poco migrada de un sistema a otro y sin que el usuario se
de cuenta vamos obligndolo a usar poco a poco mas el nuevo sistema. Una de las
desventajas es que al estar operando los dos sistemas los costos se duplicaran debido a
que pudiera ser que se tenga que contratar personal para que opere los dos sistemas,
puede que tambin el nuevo sistema sea rechazado por los usuarios y se vuelva al
sistema anterior.
Conversin directa: este tipo de conversin se hace de manera radical debido que se
hace de un da a otro obligando tanto fsico como psicolgicamente al usuario que no
existe otro sistema y debe usar ese.
Esto tiene una desventaja ya que al eliminar por completo el sistema antiguo se
quedan sin respaldo, y si el sistema nuevo llegase a tener problemas quedar parada la
empresa hasta que se solucione, tambin la empresa se retrasa varias semanas debido
que toda la captura de datos debe empezarse de nuevo y los departamentos deben
ponerse a trabajar con eso. una vez que empiece este proceso debe seguirse a pesar de
las frustraciones que pueden haber por cuestin de tiempo perdido. Este mtodo
necesita una buena planificacin, para que as no exista perdida de ningn tipo.

Enfoque piloto: En este mtodo la instalacin del sistema solo se aplica a un

departamento a manera de prueba para as tambin ir probndolo y mejorndolo- Una
vez capaces de trabajar con el, y saber que el sistema esta trabajando en su plenitud y no
tiene errores y ha minimizado tareas en ese departamento tanto como costos, tiempo etc.
se va a implementar en toda la empresa.
Modelo por etapas: Este mtodo se da debido a la tardanza de la llegada del nuevo
sistema que pasara de das a meses y es por eso que solo algunos tendrn acceso a el.
Ejemplo: Para una empresa de ropa con 15 sucursales, automatizar a las 15 sucursales
es muy costoso y es por eso que se hace la implantacin primero en 5 tiendas y luego en
el resto.
Formacin:
El responsable del proyecto prepara la documentacin necesaria, y se encarga de formar
a los futuros usuarios para el uso de la aplicacin o para la gestin de contenidos en el
caso de proyectos Web.
Por lo general la capacitacin del sistema ser in situ, en los departamentos donde se
implementa el sistema. Para ello, se realizar una presentacin global del sistema,
explicando el porque de su construccin, beneficios, limitaciones y su manejo. Adems
se entregar el manual de usuario.
Soporte.

Tcnica: Es un mtodo que aplica herramientas y reglas especficas para completar una
o ms fases del ciclo de vida del desarrollo de Sistemas. Ellas se aplican a una parte del
ciclo de vida total.
Metodologa es una versin amplia y detallada de un ciclo de vida COMPLETO de
desarrollo de sistemas que incluye:
Reglas, procedimientos, mtodos, herramientas
Funciones individuales y en grupo por cada tarea
Productos resultantes
Normas de Calidad
Herramientas.- Son los ambientes de apoyo necesario para realizar la automatizacin
de un proyecto.
Mtodos.- Son las maneras que se efectan las tareas de Desarrollo de Software o las
actividades del ciclo de vida.
Procedimientos.- Son los mecanismos de gestin que soportan a los mtodos: El
control de los proyectos, el control de la calidad

Una Metodologa es un conjunto de procedimientos, tcnicas, herramientas, y un

soporte documental que ayuda a los desarrolladores a realizar software.
Principales Metodologas Oficiales
Metodologa MERISE
Metodologa SSADM
Metodologa MTRICA
En comn estn estructuradas en fases, mdulos, actividades y tareas
FASE 0 : Plan de Sistemas de Informacin
FASE 1 : Anlisis de Sistemas
FASE 2 : Diseo de Sistemas
FASE 3 : Construccin de Sistemas
FASE 4 : Implantacin de Sistemas
Todas las metodologas; MERISE, YOURDON Y SSADM (structured Sydtem Analysis
Design Method ) y tantas otras, consideran el hecho informtico dividido en fases, cuyo
conjunto forma el ciclo de vida de un sistema informtico.
Todas tienen en comn la idea de descomposicin del hecho informtico en cuatro
grandes grupos:

Anlisis
Definicin del problema, estudio de la situacin actual, requisitos a considerar,estudio
de factibilidad
Diseo lgico
Anlisis funcional, definicin de datos y procesos, modelizacin
Diseo fsico
Creacin de archivos y tablas,elaboracin de programas
Implementacin
y control
Formacin del usuario, implantacin del sistema, explotacin del sistema,
Mantenimiento

METODOLOGA MERISE
1.Estudio preliminar
Analisis de la situacin actual. Propuesta de solucin global
2.Estudio detallado
Definicin funcional de la solucin
3.Implementacin
Realiza los programas que corresponden
produccin de programas.

se divide en: estudio tcnico y

4. Realizacin y puesta en marcha

Implementacin de medios tcnicos, implementacin de medios organizativos
METODOLOGA SSADM
Caracteristicas:
1 . nfasis en los usuarios (requisitos y participacin)
2 . Definicin del proceso de produccin (qu, hacer, cundo y cmo)
3 . Tres puntos de vista: Datos, eventos y procesos
4. Mxima flexibilidad en herramientas y tcnicas de implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el
anlisis y diseo.
METODOLOGA MTRICA
Est estructurada mediante una sucesin de fases, mdulos, actividades y tareas. Indica
los productos que se obtienen en cada una de las tareas
Se divide en las siguientes fases:
Fase 0 : Plan de sistemas de informacin
Fase 1: Anlisis de Sistemas

Fase 2: Diseo del sistema

Fase 3: Construccin de Sistemas
Fase 4: Implementacin de sistemas
Est metodologa se enfoca directamente en el desarrollo.
HERRAMIENTAS
ESTRUCTURADO

DE

DOCUMENTACIN

DEL

DISEO

Diagramas de Flujo de Datos (DFDs)

Diccionario de Datos (DD)
Diagramas de Entidad-Relacin (ER)
Diagramas de Transicin de Estado (DTEs)
Especificaciones de procesos
Tecnicas de documentacin
Incluyen herramientas grficas y de texto
Herramientas
Flujos de datos
Diagramas Hipo
Diagrama de estructura
Especificaciones de mdulo y D.D.
CICLO DE VIDA ESTRUCTURADO
El mtodo de ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseadores y usuarios realizan para desarrollar e
implantar un sistema de informacin.
Anlisis
Diseo
Desarrollo
Generacin del Test de Aceptacin
Garanta de Calidad
Descripcin de Procedimientos
Conversin de la Base de datos
Instalacin
ETAPAS DEL CILO DE VIDA ESTRUCTURADO
A.-Estudio de Viabilidad o Estudio Inicial

Su principal objetivo es el estudio e identificacin de las deficiencias actuales en

el ambiente del usuario, establecer nuevos objetivos, y proponer "escenarios" viables. Si
es factible comienza el anlisis.
B.-Anlisis
Conforme a las alternativas generadas por el estudio, en esta etapa se "modelan" las
necesidades del usuario a travs de Diagramas Especiales (DFD, ER),dando como
resultado las Especificaciones Estructuradas.
C.-Diseo
En esta etapa se "disea" el sistema, determinando los mdulos componentes del
sistema, de acuerdo a una jerarqua apropiada, a los procesadores y a la funcin.
D.- Desarrollo (Implantacin)
Esta actividad incluye la codificacin e integracin de los mdulos con tcnicas de
programacin estructurada
E.-Generacin del Test de Aceptacin
Consiste en preparar un conjunto de casos para efectuar las pruebas del sistema
F.-Garanta de Calidad.En esta etapa se efecta el TEST final de aceptacin del Sistema
G.-Descripcin de Procedimiento
Consiste en la elaboracin de la descripcin formal" del nuevo sistema : Manuales del
Usuario, del Sistema y de Procedimientos.
H.-Conversin de la Base de Datos
Esta actividad slo se realiza cuando existen sistemas funcionando
I.-Instalacin
Es la actividad final, existen varias estrategias de instalacion: gradual, distribuida,
completa
Un aspecto importante de esta actividad es la capacitacion