martes, 12 de mayo de 2015

ANALISIS Y DISEÑO DE SISTEMAS

 Etapa de Investigación Preliminar


El propósito de la investigación preliminar es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación preliminar debe cumplir con los siguientes cinco objetivos:

·         Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “Requerimientos de Sistema” no es el problema real, sino un síntoma.

·         Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, o sea, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer. La limitación puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.

·         Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “Requerimientos de Sistema”. Estos beneficios, junto a los estimados de costo, serán usados por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero.

·         Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – y los costos continuos – costos pagados periódicamente.

·         Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “Requerimientos de Sistema”, estimado de tiempo y costo-beneficios y las recomendaciones.


Etapa de Análisis de la situación actual
 



En esta etapa de los sistemas de información se hace el análisis del sistema actual o de lo que se quiere implementar. Antes de comenzar a diseñar un nuevo sistema de información, el analista debe de conocer y comprender la situación actual de la organización y del sistema de información. De esta manera, el analista puede estudiar con mayor conocimiento la causa de los problemas que surgen en la organización, y las auténticas necesidades que finalmente va a tener el negocio. 

Para estudiar la situación actual el analista debe recopilar la suficiente información para comprender en profundidad el momento actual. Para empezar, el estudio de la organización como un sistema permite averiguar cuáles son los objetivos y las metas de la organización. También permite estudiar cómo se organiza y se estructura la organización y cómo interactúan sus partes para alcanzar los objetivos.

Posteriormente, se analisa se analiza el sistema de informacion actual. Este estudio aporta informacion de como se raliza el trabajo, asi como de las necesidaes baicas de la informacion y comunicación de la organización despues de saber como funciona la organización y el sistema de informacion actual, el anilisata del sistema debe estudiar que problemas y oportunidades existen en la organización. En todos los casos es necesario estudiar la situacion actual en profundidad para poder analizar los autenticos problemas de la organización y de sus sistema de informacion, y no solamente problemas superficiales que suelen ser los identificados por el usuario.

Por ultimo, el analista de forma inequivoca cuales son los objetivos especificos del nuevo sistema de informacion según el funcionamiento actual de la organización, como se trabaja actualmente con el sistema de informacion y según los problemas y oportunidades que se han encontrado a lo largo de esta fase

Etapa de Definición de Requerimientos


En ingeniería del software y en el desarrollo de sistemas de información un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio considerando las especificidades de los clientes.

Los requerimientos son declaraciones que identifican atributos, características, capacidades, cualidades que necesita cumplir un sistema de información (o un software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para el desarrollo de un proyecto.




Etapas de la fase de requerimientos

1. Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés considerando las técnicas existentes para la recolección de la información.

2. Análisis: comprobación de la consistencia y completitud de los requerimientos para un análisis real y apropiado a las necesidades de los clientes.

3. Verificación: Validar requerimientos especificados por los clientes son correctos para el buen desempeño de los analistas del sistema actual o el nuevo a desarrollar.


Clasificación de los requerimientos

1. Requerimientos funcionales: qué debe hacer el sistema de información.

2. Requerimientos no funcionales: cómo debe funcionar el sistema de información.

3. Requerimientos externos: Características de compatibilidad, legales y de adecuación del nuevo sistema de información con respecto al entorno geográfico, empresarial y lógico del nuevo sistema de información.


Características que deberían cumplir los requerimientos



1. Actual: el requerimiento debe ser real, preciso optimo y adaptable a las condiciones del tiempo modo y lugar.

2. Cohesión: el requerimiento debe ser aplicado de forma específica a una situación real..

3. Completo: el requerimiento debe abarcar la totalidad de una situación problema obteniendo todos los recursos necesarios para lograr una solución óptima recopilando toda la información necesaria.

4. Consistente: el requerimiento debe ser coherente con los demás requerimientos sin entrar en conflicto entre requerimientos del mismo sistema o contradicciones.

5. Correcto/necesario: el requerimiento debe cumplir con las especificaciones técnicas de los clientes para el nuevo sistema de información.

6. Factible/viable: el requerimiento permite su implementación real.

7. No ambiguo: el requerimiento debe ser preciso, objetivo y fácil de interpretar 

8. Obligatorio: el requerimiento debe representar una característica definida por el cliente.

9. Observable externamente: el requerimiento debe especificar una o varias características medibles, observables por el cliente del nuevo sistema de información.

10. Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.

   Etapa de Estudios de factibilidad 

El estudio de factibilidad de un proyecto consiste en averiguar si es posible que el sistema de información sea desarrollado e implantado exitosamente en la empresa. La evaluación de la factibilidad de un proyecto es la información que requieren los altos ejecutivos para decidir realizar el proyecto, posponerlo o cancelarlo. La factibilidad debe ser revisada desde tres perspectivas:


a.     Factibilidad operativa.

 Se refiere a la posibilidad de éxito que tendrá el sistema al momento de ser implantado y operado por el personal de la empresa. Para estudiar esta el analista debe investigar lo siguiente:

          ¿Los usuarios están de acuerdo con el nuevo sistema?
La gente se resiste a los cambios en su forma de trabajo cuando esta no presenta inconvenientes y se sienten cómoda. Pero si no es así entonces los usuarios aceptaran con gusto cualquier cambio que permita tener un sistema más útil y fácil de usar.

¿Trabajaran con el sistema cuando se haya terminado o instalado?

¿Los usuarios han participado en la planeación y desarrollo del sistema?
Si los usuarios se involucran con el proyecto desde el principio serán parte del cambio y las posibilidades de éxito, desde la perspectiva operativa aumentan.

¿El sistema incrementara la productividad de los empleados?
El proyecto debe aumentar la productividad de los empleados para que sea atractivo para la empresa.

¿Mejorara la integración con otras áreas?
Nunca un proyecto de sistemas debe obstruir o disminuir la integración de las funciones de una empresa ni en el corto ni en el largo plazo.

b.    Factibilidad técnica. 

 Se debe realizar una investigación durante el estudio de factibilidad y debe incluir:
     ¿Existe o se puede adquirir la tecnología necesaria para cubrir las demandas del nuevo proyecto?
     Si se desarrolla el sistema, puede crecer con facilidad
     ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de datos?
El proveedor del equipo también dará los soportes técnicos y de capacitación necesarios antes, durante y después del desarrollo del proyecto
      Cualquier aspecto técnico no considerado puede ocasionar pérdidas importantes a la empresa.

c.     Factibilidad financiera o económica. 

Un sistema que puede desarrollarse desde el punto de vista técnico y además se utilice, si se llega a instalar debe ser una buena inversión para la organización. Los beneficios financieros deben igualar o superar a los costos.
Las cuestiones económicas y financieras formuladas por los analistas durante la investigación preliminar, tienen el propósito de estimar lo siguiente:

    §  El costo de llevar a cabo la investigación completa del sistema
    §  El costo del hw y sw para la aplicación que se está considerando
    §  Beneficios en la forma de reducción de costos o de menos errores costosos
    §  El costo si nada sucede, es decir, si el proyecto no se lleva a cabo

d.    Proyectos no factibles. Para que la propuesta sea factible debe de pasar todas las pruebas. Las propuestas que no pasen las pruebas de factibilidad pueden desecharse o redefinirse para presentarse posteriormente. La solución a los problemas de la empresa no es precisamente  mediante el desarrollo de un S.I.

e.    Selección de un proyecto. No todas las solicitudes de proyecto pueden elegirse para estudiar su factibilidad. Las solicitudes de proyectos deben examinarse desde una perspectiva de sistemas, de tal forma que se considere el impacto del proyecto propuesto sobre toda la organización. Existen 5 criterios básicos para seleccionar el proyecto a desarrollar:

   Contar con el respaldo de la directiva: nada puede lograrse en el respaldo de la gente que eventualmente recibirá la cuenta.

    Programar el tiempo que se requiere para el proyecto: tanto el de los analistas como el de los programadores y usuarios que participaran.

    Mejorar el logro de metas de la organización: dentro de los objetivos del proyecto debe estar contemplada la organización y no desviarla de sus fines primarios.

   Debe ser viable en función de los recursos y capacidades: tanto del analista como de la organización, tal vez haya proyectos para los cuales no existan los recursos ni la capacidad para llevarlos a la práctica.

    Debe dar ventajas sobre cualquier otra opción de inversión: cuando un negocio autoriza un proyecto está comprometiendo los recursos que excluirá de otros proyectos.

Basándose en estos criterios se puede reducir considerablemente el número de proyectos a los que se dedicara tiempo.

      Etapa de Diseño


El diseño de un sistema de información produce los elementos que establecen cómo el sistema cumplirá los requerimientos identificados durante el análisis del sistema. A esta etapa se le conoce también con el nombre de Diseño Lógico.
El primer paso en el diseño de sistemas es identificar los informes y las salidas que el sistema producirá; a continuación los datos específicos de cada uno de éstos se señalan, incluyendo su localización exacta sobre el papel, la pantalla de despliegue o cualquier otro medio.
El diseño también describe los datos calculados o almacenados que se introducirán. Los datos y los procedimientos de cálculo se describen con detalle. Se seleccionan las estructuras de los archivos y los dispositivos de almacenamiento, como son discos o cintas magnéticas o papel. Los procedimientos deben de mostrar cómo se van a procesar los datos y cuáles van a ser la salida.
Los documentos que contienen las especificaciones del diseño se pueden representar por medio de los diagramas, tablas y símbolos especiales.
El último paso del diseño detallado es pasar la información al grupo de programación que se inicie el desarrollo del software.
El diseño de sistemas es un proceso altamente creativo que en gran medida puede ser facilitado por lo siguiente:

1. Definición sólida del problema. 

2. Descripción del sistema existente. 

3. Conjunto de requerimientos del nuevo sistema. 

Por definición, diseño significa hacer un mapa, planear o arreglar las partes en un todo que satisfaga los objetivos involucrados.  El diseño de sistemas requiere principalmente la coordinación de actividades, los procedimientos de trabajo y la utilización de equipo para alcanzar los objetivos organizacionales.
El patrón de diseño de sistemas sigue una técnica iterativa.  El diseño de sistemas es un proceso creativo en el que el analista repite a través de varias actividades o procedimientos de trabajo, uno a la vez, investigando mentalmente a través del proceso completo. el analista debe tener en cuenta dos puntos importantes: 

1. Resuelva un problema a la vez.  No se confunda al querer resolver muchos problemas a la vez. 

2. Su nuevo sistema debe concordar con los objetivos y metas                  generales  del área bajo estudio y la empresa en sí.
  

Otra consideración en la fase de diseño es el control que se debe ejercer desde el sistema. Algunos controles se determinarán por medio de diferentes parámetros de sistemas tales como las aplicaciones y las entradas.  Probablemente se necesite diseñar ciertos controles de calidad.  Por ejemplo, todas las entradas deben preparase en forma consistente para mantener la confianza del sistema y evitar posibles errores en los procedimientos.
Las especificaciones de diseño describen las características del sistema, sus componentes o elementos y la forma en que estos aparecerán ante los usuarios. Para muchos usuarios, el éxito de un sistema está relacionado con la creencia que tengan sobre sí el sistema tiene las características adecuadas.  Los componentes de un sistema de información descritos durante el análisis de requerimientos, son el punto principal del diseño.  Los analistas deben diseñar los siguientes elementos:
 
1.   Flujos de datos: Movimientos de datos hacía, alrededor y desde el sistema.

2.   Almacenes de datos: Conjuntos temporales o permanentes de datos.

3.   Procesos: Actividades para aceptar, manejar y suministrar datos e información.  Pueden ser anuales o basadas en computadora.

4.   Procedimientos: Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados.

5.   Controles: Estándares y lineamientos para determinar si las actividades están ocurriendo en la forma anticipada o aceptada, es decir, si se encuentran bajo control.  Asimismo especificar las acciones que deben emprenderse cuando ocurren problemas o presentan circunstancias inesperadas.  Puede incluirse un reporte sobre las excepciones o procedimientos para la corrección de los problemas.

6.   Funciones del personal: Las responsabilidades de todas las personas que tienen que ver con el nuevo sistema incluyendo los usuarios, operadores de computadora y personal de apoyo.  Abarca todo el espectro de componentes del sistema, incluso desde la entrada de datos hasta la distribución de salidas o resultados.  A menudo, las funciones del personal se establecen en forma de procedimiento.

    Etapa de Desarrollo

En esta etapa del ciclo de vida, el desarrollo de los sistemas, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación del sofware se tiene: el método HIPO los diagramas de flujo, nassi-schneiderman, los diagramas Warnier-Orr y el pseudocodigo. Aquí es donde, el analista de sistemas transmite al programador los requerimientos de programación durante esta fase, el analista también colabora con los usuarios para desarrollar la documentación indispensable del software, incluyendo los manuales de procedimiento.




     Etapa de Depuración 

El sistema de información debe probarse antes de utilizarlo. El costo es menor si se detectan los problemas antes de entrega del sistema. El programador realiza algunas pruebas por cuenta, otras se llevan a cabo en colaboración con el analista de sistemas. En un principio se hace una serie de pruebas, con datos de tipo, para identificar las posibles fallas del sistema; más adelante, se utiliza los datos del sistema real. El mantenimiento del sistema y su documentación empiezan justamente en esta etapa y después esta función se realizara de forma rutinaria a lo largo de toda la vida del sistema.



     Etapa de Capacitación 

En esta etapa del desarrollo del sistema, el analista ayuda a implementar el sistema de información. Esto incluye el adiestramiento que el usuario requerirá. Si bien parte de esta capacitación la dan la casa comercial la supervisión del adiestramiento es una responsabilidad de analista de sistema. Más aun el analista necesita planear la suave transición que trae consigo un cambio de sistema



   Etapa de Puesta en marcha

Durante la puesta en marcha, TI distribuye el nuevo sistema a todos los usuarios finales, para que puedan empezar a usarlo. Además, los especialistas de TI proporcionan la documentación del sistema a los usuarios finales, que detallan cómo usar el sistema. La formación también es una parte importante de la fase de puesta en marcha. Las sesiones de formación deberían ser planteadas para cada grupo de usuarios, para que los usuarios se puedan beneficiar del sistema más adelante.


DOCUMENTACION

Tipos de Diagramas  en UML

La importancia de UML radica en que se utilizan diagramas internacionales que son estándares utilizados y entendidos en todo el mundo.

Existen diversos diagramas entre ellos:
Casos de uso.
Clases.
Estados.
Secuencias.
Colaboración.
Actividades.
Marco de Responsabilidad

EJEMPLO DE DIAGRAMA DE CASOS DE USO.

 

EJEMPLO DE DIAGRAMA DE CASOS DE USO.





















EJEMPLO DE DIAGRAMA DE CLASES.

























EJEMPLO DIAGRAMA DE ESTADOS.
























EJEMPLO DIAGRAMA DE SECUENCIAS.



















EJEMPLO DIAGRAMA DE COLABORACIÓN.






















EJEMPLO DIAGRAMA DE ACTIVIDADES.




















EJEMPLO DIAGRAMA DE MARCO DE RESPONSABILIDAD.