Please enable JavaScript.

Coggle requires JavaScript to display documents.

SISTEMAS (INVESTIGACION PRELIMINAR (Si un proyecto de sistema parece ser…

- - - - 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 “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
      - 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.
      - 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 “system request”. Estos beneficios, junto a los estimados de costo, serán usado 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. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
      - 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.
      - Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
- - - - Diagramas UML estructurales
        
        Diagrama de clases El diagrama UML más comúnmente usado, y la base principal de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas de clases al crear diagramas de sistemas grandes.
        
        Diagrama de componentes Muestra la relación estructural de los elementos del sistema de software, muy frecuentemente empleados al trabajar con sistemas complejos con componentes múltiples. Los componentes se comunican por medio de interfaces.
        
        Diagrama de estructura compuesta Los diagramas de estructura compuesta se usan para mostrar la estructura interna de una clase.
        
        Diagrama de implementación Ilustra el hardware del sistema y su software. Útil cuando se implementa una solución de software en múltiples máquinas con configuraciones únicas.
        
        Diagrama de objetos Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.
        
        Diagrama de paquetes Hay dos tipos especiales de dependencias que se definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de comunicación entre niveles.
      - Diagramas UML de comportamiento
        
        Diagrama de caso de uso Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores (actores) internos/externos.
        
        Diagrama de temporización Al igual que en los diagramas de secuencia, se representa el comportamiento de los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los objetos se muestran durante ese período de tiempo particular.
        
        Diagrama de máquina de estados Similar a los diagramas de actividades, describen el comportamiento de objetos que se comportan de diversas formas en su estado actual.
        
        Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia. Representan interacciones para un escenario concreto.
        
        Diagrama de panorama de interacciones Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia en la cual actúan.
        
        Diagrama de comunicación Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se pasan entre objetos. La misma información se puede representar usando un diagrama de secuencia y objetos diferentes.
        
        Diagramas de actividades Flujos de trabajo de negocios u operativos representados gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los diagramas de actividades se usan como una alternativa a los diagramas de máquina de estados.
- - - - Métodos que utilizan los analistas para investigar los requerimientos
        
        Cuestionarios
        Esta técnica puede ir dirigida a un público específico o general, lo que permite obtener una información mayor, ya que se tiene la posibilidad de involucrar más personas para el desarrollo de los cuestionarios y que estos tengan diferentes puntos de vista. Lo importante es tener en cuenta que se debe tener un mayor cuidado en la selección de los encuestados y de la forma en que se pregunta para obtener respuestas concretas y confiables.
        
        Lluvia de ideas
        Esta técnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la identificación de ideas de todas las personas que hacen parte del equipo de apoyo para la identificación de los requerimientos. Es utilizada para investigar nuevos servicios o necesidades que no son claramente identificadas.
        
        Entrevista
        Estas técnicas son muy utilizadas para la recolección de opiniones, criterios o descripciones sobre diferentes actividades. Se lleva a cabo mediante conversaciones estructuradas donde es fundamental que la relación con el cliente este basada en la confianza para dar a conocer la información de la manera mas detallada.
        Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips a tener en cuenta, no es obligación realizarlas todas pero si es recomendable estudiar cuales son las que más se aplica para cada organización o cada proyecto
      - A continuación se presenta el proceso para la verificación de los requerimientos.
        
        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.
        
        Observable externamente: el requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.
        
        Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada.
        
        No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder poder ser interpretado de una única manera.
        
        Factible/viable: el requerimiento debe poder ser implementado.
        
        Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.
        
        Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.
        
        Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.
        
        Cohesión: el requerimiento debe dirigirse a solo una única cosa.
        
        Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.
      - Requerimientos funcionales y no funcionales
        
        Los requerimientos no funcionales representan características generales y restricciones de la aplicación o sistema que se esté desarrollando.
        Suelen presentar dificultades en su definición dado que su conformidad o no conformidad podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición con criterios de aceptación que se puedan medir.
        Entre los ejemplos de requerimientos no funcionales presentados, tenemos los referidos a atributos como la eficiencia, seguridad, dependibilidad y usabilidad del sistema.
        También presentamos ejemplos de requerimientos no funcionales organizacionales y externos.
        
        Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean aplicables.
        
        Definición de quien puede ingresar datos en el sistema.
        
        Descripción de los reportes del sistema y otras salidas.
        
        Descripción de los flujos de trabajo realizados por el sistema.
        
        Descripciones de las operaciones a ser realizadas por cada pantalla.
        
        Descripciones de los datos a ser ingresados en el sistema.
        
        Requerimientos funcionales Los requisitos funcionales de un software se suelen registran en la matriz de trazabilidad de requerimientos y en la especificación de requerimientos de software, este último, documenta las operaciones y actividades que el sistema debe poder desempeñar.