ANALISIS DE SISTEMAS, DISEÑOS Y METODOS
1. CONTEXTO DE METODOS DE ANÁLISIS Y DISEÑO DE SISTEMAS
TIPOS DE SISTEMAS DE INFORMACION
Sistemas de procesamiento de
transacciones
Sistemas de información
administrativa
Sistemas de soporte a las decisiones
Sistemas de información
ejecutiva
Sistemas expertos
Sistemas de comunicación
y colaboración
Sistemas de automatización
de oficina
INVOLUCRADOS EN EL SISTEMA
Propietario del sistema
Financiadores del sistema, generalmente administradores. Su papel es involucrarse en el valor y costo del sistema.
Usuarios
Internos
Empleados del sistema
Externos
Entes externos que hacen
uso del sistema de información
Diseñadores
Traducen requerimientos de los usuarios en soluciones técnicas
Administrador de bases de datos
Arquitecto de redes
Artista Gráfico
Experto en seguridad
Especialistas en tecnología
Constructores
Especialistas técnicos que traducen las soluciones técnicas de los diseñadores en el sistema
Programador de aplicaciones
Programador de sistemas
Programador de bases de datos
Administrador de red
Administrador de seguridad
Proveedores
de servicios
Consultores o asesores que pueden o no estar contratados para brindar asesoramiento para la creación del sistema
Administradores
de proyecto
Supervisa los integrantes del proyecto y se asegura que se cumplan los objetivos del sistema
Analista de sistemas
Analistas
Crea puentes para cortar la brecha de comunicación entre las partes del proyecto
Entendimiento en cómputo y negocios
DIEZ MANDAMIENTOS DE LA ÉTICA DE COMPUTO
No utilizará una computadora para dañar a otras personas.
No interferirá con el trabajo de cómputo de otras personas.
No se entrometerá en los archivos de cómputo de otras personas.
No utilizará una computadora para robar.
No utilizará una computadora para dar falso testimonio.
No copiará o utilizará software registrado por el que no haya pagado.
No utilizará los recursos de cómputo de otras personas sin autorización o compensación adecuada.
No se apropiara de la producción intelectual de otra persona.
Deberá pensar en las consecuencias sociales del programa que usted escribe o el sistema que usted diseña.
Siempre deberá usar una computadora en formas que aseguren consideración y respeto para el resto de la humanidad.
2. COMPONENTES DE LOS SISTEMAS DE INFORMACION
EL PRODUCTO
Está formado por S.I front-office y back-office, alimentan de datos a los S.I administrativos y de soporte de decisiones. Se pueden conectar con clientes y proveedores haciendo uso de la intranet.
MARCO DE ARQUITECTURA
Proporciona la base para enlazar los componentes de cualquier sistema de información a desarrollar.
1. Propietarios y usuarios del sistema
Meta de mejorar el conocimiento del negocio.
Meta de mejorar procesos de negocios y servicios.
Meta de mejorar las comunicaciones del negocio y la colaboración de las personas
2. Diseñadores y Constructores del sistema
Tecnologías
Bases de datos
Software
Interfaz
CONOCIMIENTO
Permite cumplir con la misión y visión del proyecto, captura y almacena datos a través de bases de datos y requiere varios involucrados en la perspectiva del S.I
Puntos de vista
Propietario
Define alcance y visión del proyecto
Diseñadores
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.
Constructores
Administran las bases de datos, en ocasiones directamente trabajan dentro del lenguaje de programación.
Usuarios
Identifican entidades y reglas de los datos y especifican atributos de los datos, además de las reglas para mantener de forma precisa
PROCESOS
Permiten la entrega de una funcionalidad deseada en un S.I
Puntos de vista
Propietario
Relacionan el alcance funcional con la visión para visualizar el proceso
Usuarios
Especifican el proceso del negocio en términos de requerimientos que suelen definirse como políticas y procedimientos.
Diseñadores
Determinan qué procesos automatizar, se manejan mockups para documentar y comunicar cómo son o cómo serán los procesos.
Constructores
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.
COMUNICACIONES
Se enfoca en la mejora y el trabajo colaborativo en equipo, proporciona interfaces de comunicación eficaces y eficientes para los usuarios y tienen una interfaz eficaz y eficiente con otros S.I.
Puntos de vista
Propietario
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.
Usuarios
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.
Diseñadores
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.
Constructores
Construyen, instalan, prueban e implementan tanto soluciones de interfaz de usuario como de sistema a sistema.
3. DESARROLLO DE LOS SISTEMAS DE INFORMACION
ES UN CONJUNTO DE ACTIVIDADES, METODOS, PRACTICAS Y HERRAMIENTAS AUTOMATIZADAS PARA EL CONTINUO DESARROLLO Y MEJORA DE LOS S.I Y SOFTWARE
CMM (MARCO DE REFERENCIA)
PRINCIPIOS
Hacer participar a los usuarios del sistema.
Utilizar un método de solución de problemas.
Establecer fases y actividades
Documentar a través del desarrollo.
Establecer estándares.
Administrar el proceso y los proyectos.
Justificar sistemas de información como inversiones de capital.
No tema cancelar o revisar el alcance.
Divida y vencerá.
Diseñar sistemas para crecimiento y cambio.
PROCESO DE DESARROLLO
P.I.E.C.E.S
Tiene como propósito la producción eficaz y eficiente de un producto de software que satisfaga los requerimientos del usuario
RUTAS Y ESTRATEGIAS ALTERNATIVAS
Metodologías
Construir soluciones o adquirirlas
Estrictas o adaptables
Por modelo o producto
Orientada a objetos
Estrategias
Desarrollo basado en modelos
Facilitan una comunicación mejorada entre los usuarios de sistemas, analistas de sistemas, diseñadores de sistemas y constructores de sistemas.
Ventajas
- Diseños fáciles de validar con imágenes
- Especificaciones mejor documentadas
- El diseño es profundo, adaptable y flexible.
Desventajas
- Consume mucho tiempo.
- Las imágenes no son software siendo que la mayoría de usuarios quiere un software en funcionamiento.
Desarrollo rápido de aplicaciones
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
Ventajas
- Alienta la participación.
- Detección temprana de errores
- Útil para cuando los requerimientos del usuario son inciertos o imprecisos.
Desventajas
- 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.
Implantación de paquetes de aplicación comercial
Algunas veces tiene más sentido comprar una solución de sistema de información que construir uno internamente.
Ventajas
- 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.
Desventajas
- 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.
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
Herramientas y tecnología automatizada
Beneficios
La productividad mejorada
Calidad mejorada
Mejor documentación
Elaboración de modelos de sistemas asistidos por computadora.
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)
Ambientes de desarrollo de aplicación
Los ADE hacen que la programación sea más simple y más eficaz.
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.
4. ANALISIS DE SISTEMAS
ES EL ESTUDIO DE UN SISTEMA Y SUS COMPONENTES. ES UN REQUERIMIENTO PREVIO PARA EL DISEÑO DE SISTEMAS, LA ESPECIFICACIÓN DE UN SISTEMA NUEVO Y MEJORADO QUE DESCRIBE UNA SERIE DE FASES.
Propietario
Usuarios
Analistas
ENFOQUES
Basados en modelos
Utiliza imágenes para comunicar problemas de negocios, requerimientos y soluciones
Diagramas de flujo
Organigrama
Cuadros de estructura
Jerarquías
Herramientas CASE
Análisis de sistemas acelerados
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.
Énfasis en el componente de COMUNICACIONES
Métodos RAD
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”
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
Para identificación de requerimientos
Técnicas de identificación de hechos
El muestreo de la documentación existente, informes, formatos, archivos, bases de
datos y memorandos.
Investigación de bibliografía relevante, sondeo en el mercado de otras soluciones y
visitas a sitios
Observación del sistema actual en acción y el ambiente de trabajo
Cuestionarios y encuestas de la administración y la comunidad de usuarios.
Entrevistas de administradores, usuarios y personal técnico apropiado.
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
Rediseño de procesos de negocios (BPR)
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
ESTRATEGIA DE ANALISIS DE SISTEMAS FAST
Integra todos los métodos populares presentados en los párrafos anteriores en una colección de métodos
acelerados.
COMPONENTES
Conocimiento
Proceso
Comunicaciones
FASES
Definición de alcance
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.1 Identificar problemas y oportunidades
básicos
Solicitud de servicio de sistema
Declaración de la problematica a tratar o directiva
Declaración de la posible solución a la anterior problematica
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.
1.2 Negociar alcance base
Definición del problema
1.3 Considerar el valor del proyecto base
¿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
Propietarios del sistem
Patrocinador ejecutivo
Gerentes del negocio
Encargados del sistema
operativo
Analista de
sistemas experto
administrador
de proyecto
En esta tarea se decide si se aprueba o no y si aumenta o disminuye el alcance del proyecto
1.4 Desarrollar un programa y presupuesto
iniciales.
Si el proyecto se ha considerado como valioso para continuar se extiende
Plan Maestro
Plan y programa del
proyecto base
La definición del trabajo
El programa del proyecto
Asignación de recursos
Un plan y programa detallado
Acuerdo consensuado acerca del alcance, los problemas, las oportunidades, las directrices y el valor del
proyecto.
1.5 Comunicar el plan de proyecto
Presentación y defensa frente a un comité de dirección para su aprobación
Análisis del problema
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
Tareas
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
Conocimiento
Lista las “cosas” acerca de las cuales el sistema en la actualidad almacena datos
Procesos
Define cada suceso de negocios para el cual una respuesta de negocios (proceso) es implementada en la actualidad
Comunicaciones
Define todas las ubicaciones que el sistema actual atiende y todos los usuarios en cada una de esas locaciones
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
Análisis de causa de efecto
Problema u oportunidad
Causas y efectos
Objetivos de mejora del sistema
Objetivos del sistema
Restricción del sistema
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
El volumen de flujo de datos a través de los procesos
Los tiempos de respuesta de cada proceso
Cualquier retraso o cuello de botella que ocurre en el sistema
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.5 Actualizar o refinar el plan del proyecto
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
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
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
Autorizar que el proyecto continúe, tal como está, a la fase de análisis de requerimientos
Ajustar el alcance, costo o programa para el proyecto y luego continuar con la fase de análisis de requerimientos
Cancelar el proyecto
Falta de recursos para continuar el desarrollo del sistema
Darse cuenta de que los problemas y oportunidades simplemente no eran tan importantes como se había anticipado
Comprensión de que no es probable que los beneficios del nuevo sistema excedan los costos
Análisis de requerimientos
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
Tareas
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
Requerimientos Funcionales
Entradas, salidas, procesos, datos almacenados necesarios para completar los objetivos de mejora del sistema
Requerimientos No Funcionales
Desempeño, facilidad de aprendizaje, presupuestos, costos y ahorros, cronogramas y vencimientos, documentación, controles de auditoria internas, externas.
Formatos
División entre lista original de objetivos de mejora: Sub lista de entradas, procesos, salidas y datos almacenados
Casos de uso
Técnicas
JRP (Joint Requeriments Plannin)
Entrevistas y Encuestas
3.2 Priorizar los requerimientos del sistema
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.
Requerimiento Obligatorio
Es aquél que debe ser satisfecho por la mínima versión del sistema (versión 1.0.)
Requerimiento Deseable
Es aquél que no es absolutamente esencial a la versión mínima del sistema (versión 1.0)
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
Miembros
Propietarios del sistema
Administrador del proyecto
Equipo de proyecto completo
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.
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
Análisis de decisión
Propósito
Identificar las soluciones alternativas,
analizarlas y recomendar un sistema objetivo que será diseñado, construido e
implementado
Tareas
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
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 técnica
Factibilidad operativa
Factibilidad económica
Factibilidad de programa
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.
Analista de sistemas
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á
Analistas
Propietarios
Diseñadores
Constructores
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
Diseño físico e integración
Construcción y pruebas
Instalación y entrega
TAREAS
1.1 Identificar problemas y oportunidades básicos.
1.2 Negociar alcance base.
1.3 Considerar el valor del proyecto base.
1.4 Desarrollar un programa y presupuesto iniciales.
1.5 Comunicar el plan de proyecto.
2.1 Entender el dominio del problema
2.2 Analizar problemas y oportunidades.
2.3 Analizar procesos de negocios.
2.4 Establecer objetivos de mejora del sistema.
2.5 Actualizar o refinar el plan del proyecto.
2.6 Comunicar resultados y recomendaciones.
3.1 Identificar y expresar los requerimientos del sistema.
3.2 Priorizar los requerimientos de sistema
3.3 Actualizar o refinar el plan de proyecto.
3.4 Comunicar la definición de requerimientos.
4.1a Requerimientos funcionales de estructura
4.1b Requerimientos funcionales del prototipo
4.2 Validar requerimientos funcionales
4.3 Definir casos de prueba de aceptación
5.1 Identificar soluciones alternativas
5.2 Analizar soluciones alternativas
5.3 Comparar soluciones alternativas
5.4 Actualizar el plan del proyecto
5.5 Recomendar una solución del sistema
Técnicas de exploración
Proceso de identificación de requerimientos
Identificación del problema y análisis
Casos de usos
Modelo de datos
Modelo de procesos
Modelo de objetos
Identificación de los requerimientos
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
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
Documentación y análisis
Documento formal que comunica los requerimientos del sistema propuesto a involucrados clave y sirve como un contrato del proyecto de sistemas
Requerimientos
Restricciones
Información
Administración de los requerimientos
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
Diagrama de Ishikawa
herramienta gráfica usada para identificar, explorar e ilustrar problemas, así como las causas y efectos de esos problemas
Técnicas para explorar hechos
Muestreo de la documentación, las formas y las bases de datos existentes
Investigación y visitas al sitio
Observación del ambiente de trabajo
Ventajas
El analista de sistemas puede ver exactamente lo que se está haciendo. Algunas veces es difícil explicar claramente con palabras las tareas compleja
La observación es relativamente barata en
comparación con otras técnicas de exploración
Desventajas
El trabajo que se esté observando tal vez no incluya el nivel de dificultad o de volumen normalmente experimentado durante ese tiempo.
Algunas tareas no siempre serán desempeñadas en la manera en que las observa el analista de sistemas
Cuestionarios y Entrevistas
Ventajas
Las entrevistas permiten que el analista de
sistemas adapte o parafrasee las preguntas para cada persona
Los cuestionarios son un medio relativamente barato de recopilar datos provenientes de un gran número de
personas.
Desventajas
Una entrevista puede ser impráctica debido
a la ubicación del entrevistado
No es posible que el analista de sistemas observe y analice el lenguaje corporal del encuestado.
Propuestas de prototipos
Planeación conjunta de requerimientos
Modelado del requerimiento de sistema con los casos de uso
Conceptos de sistemas en la modelación de casos de uso
Diagrama de casos de uso
Identificar y describir funciones del sistema
Capturan la esencia de los problemas de negocio
Funcionalidad del problema (moldearlo)
Análisis del sistema con mayor detalle
Actores
Relaciones
Proceso de modelación de casos de uso
Producir y analizar suficiente información de los requerimientos para preparar un modelo que comunique lo que se necesita desde la parte del usuario
1. Identificar los actores de negocios
2. Identificar los casos de uso para los requerimientos de negocios
3. Construir el diagrama del modelo de casos de uso
4. Narraciones de los casos de uso para los requerimientos de documentos para los negocios
Los casos de uso y la administración de proyectos
Jerarquización y Evaluación
Identificación de las dependencias de casos de uso