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 humanoLa 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 lasecuencia 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 BDNivel 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 resguardoCommand 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 pruebaspara 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 preliminarAnalisis de la situacin actual. Propuesta de solucin global

2.Estudio detalladoDefinicin funcional de la solucin

3.ImplementacinRealiza los programas que corresponden se divide en: estudio tcnico y produccin de programas.

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 DE DOCUMENTACIN DEL DISEO ESTRUCTURADO

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 documentacinIncluyen 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