af JULIAN MATEO MOGOLLON CRUZ 3 år siden
171
ANALISIS DE SISTEMAS, DISEÑOS Y METODOS
af JULIAN MATEO MOGOLLON CRUZ 3 år siden
171
Mere som dette
4. Narraciones de los casos de uso para los requerimientos de documentos para los negocios
3. Construir el diagrama del modelo de casos de uso
2. Identificar los casos de uso para los requerimientos de negocios
1. Identificar los actores de negocios
Relaciones
Actores
Análisis del sistema con mayor detalle
Funcionalidad del problema (moldearlo)
Capturan la esencia de los problemas de negocio
Identificar y describir funciones del sistema
No es posible que el analista de sistemas observe y analice el lenguaje corporal del encuestado.
Una entrevista puede ser impráctica debido a la ubicación del entrevistado
Los cuestionarios son un medio relativamente barato de recopilar datos provenientes de un gran número de personas.
Las entrevistas permiten que el analista de sistemas adapte o parafrasee las preguntas para cada persona
Algunas tareas no siempre serán desempeñadas en la manera en que las observa el analista de sistemas
El trabajo que se esté observando tal vez no incluya el nivel de dificultad o de volumen normalmente experimentado durante ese tiempo.
La observación es relativamente barata en comparación con otras técnicas de exploración
El analista de sistemas puede ver exactamente lo que se está haciendo. Algunas veces es difícil explicar claramente con palabras las tareas compleja
Se especifica cómo debe presentarse una solicitud de cambio, cómo se analiza en cuanto el impacto sobre el alcance, el calendario, y el costo, cómo se aprueba o se rechaza, y cómo se implementa el cambio si se aprueba
Documento formal que comunica los requerimientos del sistema propuesto a involucrados clave y sirve como un contrato del proyecto de sistemas
Información
Restricciones
Requerimientos
El objetivo de la actividad del análisis de requerimientos es identificar y resolver los problemas con los requerimientos y alcanzar un consenso que satisfaga a los involucrados
Los documentos dan la dirección de las técnicas de modelación que el analista de sistemas va a usar para analizar los requerimientos y determinar los requerimientos correctos del proyecto.
Borrador de requerimientos
Modelo de objetos
Modelo de procesos
Modelo de datos
Casos de usos
4.5 Recomendar una solución del sistema
la fase de análisis de decisión concluye con una tarea de comunicación. Debemos recomendar una solución de sistema para la comunidad del negocio
4.4 Actualizar el plan del proyecto
El plan actualizado debe ahora incluir un plan detallado para la fase de diseño de sistemas que seguirá
Propietarios
4.3 Comparar soluciones alternativas
Se recomienda la solución más completa con la combinación de factibilidad técnica, operativa, económica y de cronograma.
4.2 Analizar soluciones alternativas
Se debe analizar la factibilidad de cada sistema alternativo de solución. Esto puede suceder después de que se haya identificado una posible solución o después de que se hayan identificado todas las soluciones posibles
Factibilidad de programa
Factibilidad económica
Factibilidad operativa
Factibilidad técnica
4.1 Identificar soluciones alternativas
Primero se deben identificar soluciones alternativas, ideas y aportes de diseño de los propietarios y usuarios sugerirán algunas soluciones alternativas.
Su propósito es definir soluciones alternativas que se pueden considerar
Propósito
Identificar las soluciones alternativas, analizarlas y recomendar un sistema objetivo que será diseñado, construido e implementado
Es una fase que no se puede pasar por alto, define los requerimientos de negocios para un sistema nuevo. Los nuevos sistemas siempre serán evaluados, primero y sobre todo, acerca de si cumplen o no con los objetivos y requerimientos del negocio
Manejo permanente de requerimientos
El manejo de los requerimientos define un proceso para los propietarios, usuarios, analistas, diseñadores y constructores del sistema para enviar los cambios propuestos a los requerimientos de un sistema
3.4: Comunicar la definición de requerimientos
La comunicación es el proceso a través del cual se deben mediar las diferencias de opinión. El administrador del proyecto y el patrocinador ejecutivo conjuntamente deben facilitar esta tarea.
3.3 Actualizar o refinar el plan del proyecto
Pueden tener que reducir el alcance para cumplir con un vencimiento o incrementar el presupuesto para que el trabajo se realice
Equipo de proyecto completo
Administrador del proyecto
Propietarios del sistema
3.2 Priorizar los requerimientos del sistema
Requerimiento Deseable
Es aquél que no es absolutamente esencial a la versión mínima del sistema (versión 1.0)
Requerimiento Obligatorio
Es aquél que debe ser satisfecho por la mínima versión del sistema (versión 1.0.)
Timeboxing
Divide requerimientos en “partes” que puedan ser implementadas dentro de un periodo que no acabe con la paciencia del usuario y de la comunidad administrativa. El timeboxing obliga a que las prioridades sean definidas claramente.
3.1 Identificar y expresar los requerimientos del sistema
La función que tiene la tarea 3.1 es traer los objetivos de la fase de analisis de problema y llevarlos en un esquema de requerimentos funcionales y no funcionales
Técnicas
Entrevistas y Encuestas
JRP (Joint Requeriments Plannin)
Formatos
Casos de uso
División entre lista original de objetivos de mejora: Sub lista de entradas, procesos, salidas y datos almacenados
Requerimientos No Funcionales
Desempeño, facilidad de aprendizaje, presupuestos, costos y ahorros, cronogramas y vencimientos, documentación, controles de auditoria internas, externas.
Requerimientos Funcionales
Entradas, salidas, procesos, datos almacenados necesarios para completar los objetivos de mejora del sistema
La fase de análisis del problema responde a las preguntas, “¿vale la pena resolver estos problemas?” y “¿vale la pena construir un nuevo sistema?”. Su objetivo es estudiar y comprender el dominio del problema lo bastante bien para analizar a fondo sus problemas, oportunidades y restricciones
2.6 Comunicar resultados y recomendaciones
Esta tarea se dispara por la terminación del plan del proyecto actualizado, se debe comunicar resultados y propuestas a la comunidad del negocio. Otra reunión en la que los participantes deben incluir al equipo del proyecto completo
Cancelar el proyecto
Comprensión de que no es probable que los beneficios del nuevo sistema excedan los costos
Darse cuenta de que los problemas y oportunidades simplemente no eran tan importantes como se había anticipado
Falta de recursos para continuar el desarrollo del sistema
Ajustar el alcance, costo o programa para el proyecto y luego continuar con la fase de análisis de requerimientos
Autorizar que el proyecto continúe, tal como está, a la fase de análisis de requerimientos
2.5 Actualizar o refinar el plan del proyecto
el propietario del sistema clasificará los objetivos en orden de importancia. Luego, si el alcance debe ser reducido, los objetivos de mayor prioridad le dirán al analista qué es lo más importante
Con base en nuestro programa y presupuesto base de la fase de definición de alcance, el alcance puede haber crecido o disminuido en tamaño y complejidad
2.4 Establecer objetivos de mejora del sistema
El propósito de esta tarea es establecer el criterio en contra del cual cualquier mejora al sistema será medida y para identificar cualquier restricción que pueda limitar la flexibilidad en lograr esas mejoras
2.3 Analizar los procesos del negocio
Esta tarea es apropiada sólo para proyectos de rediseño de procesos de negocios (BRP) o proyectos de desarrollo de sistemas que se construyen sobre un significativo rediseño del proceso de negocios o que requieren de él
Cualquier retraso o cuello de botella que ocurre en el sistema
Los tiempos de respuesta de cada proceso
El volumen de flujo de datos a través de los procesos
2.2 Analizar problemas y oportunidades
Analizan cada problema percibido para sus causas y efectos. Ese problema también debe ser analizado para encontrar sus causas y efectos y así sucesivamente hasta que llegue el momento en que las causas y los efectos no arrojen síntomas de otros problemas
Objetivos de mejora del sistema
Restricción del sistema
Objetivos del sistema
Análisis de causa de efecto
Causas y efectos
Problema u oportunidad
2.1 Entender el dominio del problema
Cada PROPIETARIO, USUARIO y ANALISTA DE SISTEMAS aporta un nivel diferente de comprensión al sistema —detalle, vocabulario, percepciones y opiniones diferentes
Define todas las ubicaciones que el sistema actual atiende y todos los usuarios en cada una de esas locaciones
Procesos
Define cada suceso de negocios para el cual una respuesta de negocios (proceso) es implementada en la actualidad
Lista las “cosas” acerca de las cuales el sistema en la actualidad almacena datos
el producto final de la fase de investigación preliminar es el cumplimiento de una carta de definición del proyecto. Define el alcance de proyecto, el plan, la metodología, los estándares y demás.
Tareas
1.5 Comunicar el plan de proyecto
Presentación y defensa frente a un comité de dirección para su aprobación
1.4 Desarrollar un programa y presupuesto iniciales.
Si el proyecto se ha considerado como valioso para continuar se extiende
Un plan y programa detallado
Acuerdo consensuado acerca del alcance, los problemas, las oportunidades, las directrices y el valor del proyecto.
Plan Maestro
Asignación de recursos
El programa del proyecto
La definición del trabajo
Plan y programa del proyecto base
1.3 Considerar el valor del proyecto base
En esta tarea se decide si se aprueba o no y si aumenta o disminuye el alcance del proyecto
¿Solucionar los problemas, explotar las oportunidades o satisfacer las directrices devolverá el valor suficiente para superar los costos en los que incurriremos para desarrollar este sistema?
Miembros
administrador de proyecto
Analista de sistemas experto
Encargados del sistema operativo
Gerentes del negocio
Patrocinador ejecutivo
Propietarios del sistem
1.2 Negociar alcance base
Definición del problema
1.1 Identificar problemas y oportunidades básicos
Alcances y limites a atender
Cada problema, oportunidad y directriz se está evaluado con relación a la urgencia, visibilidad, beneficios, prioridad y soluciones posibles.
Declaración de la posible solución a la anterior problematica
Declaración de la problematica a tratar o directiva
Solicitud de servicio de sistema
Se enfoca en todos los procesos de negocios, sin importar su automatización. Cada proceso de negocios se estudia y analiza con profundidad en busca de cuellos de botella, valor de retorno y oportunidades de eliminación o agilización.
Aplicación
Dentro del contexto de los proyectos de desarrollo de información. Es muy común que los proyectos de S.I incluyan un estudio de los procesos de negocios existentes para identificar problemas, burocracia e ineficiencias
Planeación conjunta de requerimientos (JRP)
Proporciona un ambiente de trabajo en el cual se aceleran todas las tareas y los productos del análisis de sistemas. Promueve una participación mejorada del propietario y del usuario en el análisis del sistema
Técnicas de identificación de hechos
Entrevistas de administradores, usuarios y personal técnico apropiado.
Cuestionarios y encuestas de la administración y la comunidad de usuarios.
Observación del sistema actual en acción y el ambiente de trabajo
Investigación de bibliografía relevante, sondeo en el mercado de otras soluciones y visitas a sitios
El muestreo de la documentación existente, informes, formatos, archivos, bases de datos y memorandos.
Análisis rápido de arquitectura
Construye modelos de sistemas. El análisis rápido de arquitectura se hace posible mediante la tecnología de ingeniería inversa que se incluye en muchas herramientas automatizadas como CASE y lenguajes de programación
Elaboración de prototipos de identificación
Utiliza tecnología de desarrollo rápido para ayudar a los usuarios a identificar sus requerimientos de negocios. Se trata de desalentar a los usuarios de preocuparse por la “visión y sensación”
La mayoría de dichos métodos en este enfoque se derivan de alguna variación en la construcción de prototipos, muestras funcionales pero incompletas de un sistema deseado. A veces, los prototipos pueden evolucionar para convertirse en los sistemas finales, es decir, las aplicaciones completas.
Métodos RAD
Énfasis en el componente de COMUNICACIONES
Herramientas CASE
Utiliza imágenes para comunicar problemas de negocios, requerimientos y soluciones
Jerarquías
Cuadros de estructura
Organigrama
Diagramas de flujo
Herramientas y tecnología automatizada
Administradores de proceso y proyecto
Nos ayuda a manejar la metodología y los proyectos de desarrollo de sistemas que utilizan esta metodología, fueron hechas para soportar las actividades transversales del ciclo de vida.
Ambientes de desarrollo de aplicación
Los ADE hacen que la programación sea más simple y más eficaz.
Ingeniería de sistemas asistida por computadora
Es utilizado para diseñar e implantar otro software. Esto es muy similar a la tecnología de diseño asistida por computadora (CAD)
Beneficios
Elaboración de modelos de sistemas asistidos por computadora.
Mejor documentación
Calidad mejorada
La productividad mejorada
Estrategias híbridas
La ruta que se utilizará siempre es seleccionada durante la fase de definición de alcance y es negociada como parte de la declaración de trabajo, se suelen utilizar más de 2 rutas
Implantación de paquetes de aplicación comercial
- Un sistema adquirido rara vez refleja la solución ideal que el negocio podría lograr con un sistema desarrollado internamente. - Si el proveedor queda fuera del negocio, usted pierde su soporte técnico y mejoras futuras.
- Muchas empresas no pueden permitirse el personal y la experiencia requerida para desarrollar soluciones internas. - El proveedor de aplicación asume la responsabilidad por mejoras de sistema significativas y correcciones de errores.
Algunas veces tiene más sentido comprar una solución de sistema de información que construir uno internamente.
Desarrollo rápido de aplicaciones
- Puede fácilmente resolver los problemas equivocados ya que el análisis del problema se abrevia o se ignora. - Incrementa los costos requeridos para operar, soportar y mantener el sistema.
- Alienta la participación. - Detección temprana de errores - Útil para cuando los requerimientos del usuario son inciertos o imprecisos.
Es una ruta popular para acelerar el desarrollo de sistemas, incluye a los usuarios en actividades de análisis, diseño y construcción de forma interactiva
Desarrollo basado en modelos
Desventajas
- Consume mucho tiempo. - Las imágenes no son software siendo que la mayoría de usuarios quiere un software en funcionamiento.
Ventajas
- Diseños fáciles de validar con imágenes - Especificaciones mejor documentadas - El diseño es profundo, adaptable y flexible.
Facilitan una comunicación mejorada entre los usuarios de sistemas, analistas de sistemas, diseñadores de sistemas y constructores de sistemas.
Orientada a objetos
Por modelo o producto
Estrictas o adaptables
Construir soluciones o adquirirlas
Tiene como propósito la producción eficaz y eficiente de un producto de software que satisfaga los requerimientos del usuario
Construyen, instalan, prueban e implementan tanto soluciones de interfaz de usuario como de sistema a sistema.
Se preocupan por el diseño técnico del usuario y de las interfaces de comunicación de sistema a sistema, consistencia, compatibilidad, integridad y diálogos de usuario.
Está dado más en términos de entradas y salidas del sistema, pueden especificar los detalles de esas entradas y salidas según la comodidad con la que sientan la interfaz.
Incluye el alcance y la visión de comunicación, y podría ser expresado como una simple lista de ubicaciones de negocios o sistemas con los que el sistema de información debe tener una interfaz.
Representan los procesos con lenguajes de programación de cómputo precisos o ambientes de desarrollo de aplicaciones que describen entradas, salidas, lógica y control.
Determinan qué procesos automatizar, se manejan mockups para documentar y comunicar cómo son o cómo serán los procesos.
Especifican el proceso del negocio en términos de requerimientos que suelen definirse como políticas y procedimientos.
Relacionan el alcance funcional con la visión para visualizar el proceso
Puntos de vista
Identifican entidades y reglas de los datos y especifican atributos de los datos, además de las reglas para mantener de forma precisa
Administran las bases de datos, en ocasiones directamente trabajan dentro del lenguaje de programación.
Punto de vista restringido. Su punto de vista consiste en estructuras de datos, esquemas, etc. Diseñan y documentan sus puntos de vista de forma técnica en datos.
Propietario
Define alcance y visión del proyecto
2. Diseñadores y Constructores del sistema
Tecnologías
Interfaz
Software
Bases de datos
1. Propietarios y usuarios del sistema
Meta de mejorar las comunicaciones del negocio y la colaboración de las personas
Meta de mejorar procesos de negocios y servicios.
Meta de mejorar el conocimiento del negocio.
Entendimiento en cómputo y negocios
Crea puentes para cortar la brecha de comunicación entre las partes del proyecto
Supervisa los integrantes del proyecto y se asegura que se cumplan los objetivos del sistema
Analista de sistemas
Consultores o asesores que pueden o no estar contratados para brindar asesoramiento para la creación del sistema
Especialistas técnicos que traducen las soluciones técnicas de los diseñadores en el sistema
Administrador de seguridad
Administrador de red
Programador de bases de datos
Programador de sistemas
Programador de aplicaciones
Traducen requerimientos de los usuarios en soluciones técnicas
Especialistas en tecnología
Experto en seguridad
Artista Gráfico
Arquitecto de redes
Administrador de bases de datos
Externos
Entes externos que hacen uso del sistema de información
Internos
Empleados del sistema
Financiadores del sistema, generalmente administradores. Su papel es involucrarse en el valor y costo del sistema.
