Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Transcripción

1 Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software SLC -ERS Relator: Sr. Eduardo Leyton G

2 Ingeniería de Software (IS) Es una disciplina que integra métodos, herramientas y procedimientos para el desarrollo del software de computadoras. La IS surge de la ingeniería del Hardware y del Software y abarca los tres elementos claves: métodos, herramientas y procedimientos. Métodos de IS: Indican como construir técnicamente el software, tales como: Planificación y Estimación de Proyectos, Análisis de los Requisitos del Sistema y del Software, Diseño de Estructuras de Datos, Arquitectura de Programas y algoritmos, Codificación, Prueba y Mantenimiento. Herramientas: Suministran un soporte automático o semiautomático para los métodos, por ejemplo las herramientas CASE.(Ingeniería de Software Asistida por Computador) combina software, hardware y Bd sobre la IS.

3 Procedimientos: Son el nexo que vincula los métodos con las herramientas y facilita el desarrollo racional y oportuno del software por computadora. Los procedimientos definen la secuencia en las que se aplican los métodos, las entregas que se requieren y los controles que ayudan a asegurar la calidad del software. La IS está compuesta por una serie de pasos que abarcan métodos, herramientas y procedimientos que se denominan PARADIGMAS de la IS: El Ciclo de Vida Clásico o Modelo de Cascada; Construcción de Prototipos; Modelo en Espiral; Técnicas de Cuarta Generación T4G. CICLO DE VIDA CLASICO: (Metodología Tradicional) Exige un enfoque sistemático y secuencial del desarrollo del software. Está compuesto por las siguientes etapas: Ingeniería y Análisis del Sistema: El software es parte de un sistema mayor, por lo tanto debe identificarse los requisitos y elementos del sistema.

4 Análisis de los Requisitos del Software: Diseño: Codificación: Contempla los requisitos globales a nivel de sistema con una suficiente cantidad de análisis y de diseño a un nivel superior. El proceso de recopilación de requisitos se centra en el software. Que interfaces, naturaleza de las aplicaciones específicas a construir, el ámbito de la información del software. Diseño del Software contempla 4 pasos: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. Es un proceso que transforma o traduce los requisitos en una representación del software. El diseño debe traducirse en forma legible para el computador (instruccioneslenguaje), esta traducción puede ser mecánica y/o automática (4GL)

5 Prueba: Mantenimiento: Pruebas de lógica y consistencia de los algoritmos codificados, integridad del sistema. Actualización del software ante cambios del entorno; modificaciones por errores, etc. Esta etapa por si misma contempla la ejecución de las anteriores. Desventajas de este Paradigma: 1. Los proyectos no siempre siguen un flujo secuencial según el modelo. 2. El Cliente o usuario no siempre logra establecer claramente sus requerimientos al inicio del proyecto como lo exige esta metodología. 3. Existe un espera hasta la última etapa para ver el producto de software. Un error no detectado hasta que el programa esté funcionando puede ser desastrozo o altamente costoso. Ingeniería del Sistema Análisis Diseño Codificación Prueba Mantenimiento

6 Fases del Ciclo de Vida (SLC: System Life Cycle) (Sistemas de Información Gerencial Raymond McLeod) Es un proceso evolutivo que se sigue para implementar una solución basada en automatización de procesos de negocio. El SLC es una serie de actividades que sigue un patrón ordenado y en forma descendente, también conocido como el Enfoque de Cascada para la creación y mantención (usabilidad) de sistemas. Fases del SLC: - Planificación - Análisis - Diseño - Implementación - Mantención (usabilidad: minimizar la o.t) Administración del SLC: - Alto nivel directivo, - Comité de Ejecutivo, - Comité de Informática (Establece políticas, fiscaliza, resuelve conflictos) - Liderazgo del Proyecto (Jefe/equipo de Py)

7 FASE: PLANIFICACION Diagnóstico Preliminar: Estudio del entorno del problema, levantamiento de información, identificación global de problemas y requisitos. Reconocer el Problema: Internalizar en todos los niveles la existencia de un problema organizacional y necesidad de un solución. Definir el Problema: No es recabar información, sino comprender, entender y abstraer la magnitud y las implicancias e impacto del problema en la gestión y continuidad del negocio. Fijar los Objetivos del Sistema: El equipo del proyecto o responsables de la organización identifican, determinan y listan los Objetivos, en términos generales, que debe satisfacer la nueva solución. Identificar Restricciones del Sistema Realizar el Estudio de Factibilidad (T-E-O-L) Propuesta Detallada para su VB 1. Resumen Ejecutivo 2. Introducción 3. Objetivos y Restricciones del Sistema 4. Posibles soluciones alternativas 5. Proyecto de Estudio de Sistema Recomendado 5.1 Tareas a realizar 5.2 Recursos Humanos requeridos 5.3 Programa de Trabajo 5.4 Costo estimado 6. Impacto Esperado del Sistema 7. Plan de Desarrollo General (fases de análisis, diseño e implementación) 8. Resumen

8 FASE: ANALISIS Anunciar el Estudio de Sistemas en la Organización Comunicar a toda la comunidad la necesidad de una nueva solución, el objetivo, motivación y ventajas. Organizar Formalmente el Equipo de Proyecto Definitivo Area Funcional/Area tecnológica Gerencia del Proyecto Definir las Necesidades de Información (Etapa Crucial) Mediante diversas técnicas (comunicación bidireccional, compromiso, lc, vínculos de confianza) analistas y usuarios interactuan con el fin de reunir información relevante, estratégica y secundaria para conformar un cuerpo de antecedentes para su estudio. (DFD, DD. ME, descripciones narrativos, definición y/o Especificación de Requerimientos de Software-ERS) Definir Criterios de Desempeño del Sistema Una vez definidas las necesidades ya es posible especificar en términos exactos qué es lo que debe lograr el sistema: como medio de salida de la información, oportunidad de ésta, algoritmos de calculo, comparaciones, etc. Preparar la Propuesta de Diseño 1. Resumen Ejecutivo 2. Introducción 3. Definición del Problema 4. Objetivos y Restricciones del Sistema 5. Criterios de Desempeño 6. Posibles soluciones alternativas 7. Proyecto de Diseño Recomendado 7.1 Tareas a realizar 7.2 Recursos Humanos requeridos

9 7.3 Programa de Trabajo 7.4 Costo estimado 8. Impacto Esperado del Sistema 8.1 Impacto sobre la estructura de la organización 8.2 Impacto sobre las operaciones de la organización 8.3 Impacto sobre los recursos de la organización 9. Plan de Desarrollo General (fases diseño e implementación) Resumen FASE: DISEÑO Una vez comprendido el sistema existente (situación actual) y los requisitos que debe cumplir la nueva solución, el equipo de proyecto puede abordar el diseño. Este proceso es la determinación de los procesos y datos que requerirá el nuevo sistema (Adm/Comp). Preparar el Diseño Detallado El equipo funcional y tecnológico, proceden mediante técnicas (Análisis Estructurado, Prototipado), a configurar los flujos de información, procesos, algoritmos de transformación, estructura de datos, formato de pantallas, reportes, informes estructurados y no estructurados; es decir, a delinear y diseñar la nueva solución. Modelado de Datos Modelado de Procesos Modelado de Objetos Diagrama de Entidad y Relaciones Diccionario de Datos Forma de Diseño de Pantalla/Impresora Sistema de Flujo del Programa Diagrama de Flujo del Programa Diagrama de Flujo de Datos Español Estructurado Modelado de relación de Objetos Especificación de Clases Identificar Configuraciones Alternativas del Sistema. Se efectúa un preselección de la plataforma tecnológica (hw, so, sgbdr, conectividad) que sustentará el funcionamiento

10 y/o explotación de la nueva solución (No la marca ni el modelo) bajo el criterio de funcionalidad, disponibilidad y costos de los mismos. Evaluar Configuraciones Alternativas del Sistema De acuerdo a los criterios de desempeño del sistemasolución, las restricciones del mismo se evaluan las distintas alternativas tecnológicas (benchmark). Selección de la mejor alternativa tecnológica. Preparar la Propuesta de Implementación El equipo funcional y tecnológico bosqueja las actividades de la próxima fase. 1. Resumen Ejecutivo 2. Introducción 3. Definición del Problema 4. Objetivos y Restricciones del Sistema 5. Criterios de Desempeño 6. Diseño del Sistema 6.1 Descripción resumida 6.2 Configuración del equipo 7. Proyecto de Implementación Recomendado 7.1 Tareas a realizar 7.2 Recursos Humanos requeridos 7.3 Programa de Trabajo 7.4 Costo estimado 8. Impacto Esperado del Sistema 8.1 Impacto sobre la estructura de la organización 8.2 Impacto sobre las operaciones de la organización 8.3 Impacto sobre los recursos de la organización 9. Plan de Implementación General 10. Resumen

11 FASE: IMPLEMENTACION Esta fase es la adquisición e INTEGRACION de los recursos físicos y conceptuales que producen un sistema funcional para migrar funcional y operativamente desde un antiguo sistema a una nueva solución. Planear la Implementación en forma detallada Anunciar la Implementación (comunicar y comprometer) Obtener los Recursos de Hardware-Software El diseño del sistema se presenta (globalmente) a los proveedores de T.I, con las Bases Técnicas y Bases Administrativas para su posterior evaluación. Documentación de la Empresa 1. Carta de Presentación 2. Objetivos del Sistema y Restricciones Aplicables 3. Diseño del Sistema 3.1 Descripción Resumida 3.2 Criterios de Desempeño 3.3 Configuracuión del Equipo 3.4 Documentación Resumida del Sistema 3.5 Volumen de Transacciones Estimado y tiempo de respuesta 3.6 Tamaño estimado de Archivo (multivolumen) 4. Programa de Instalación Propuesta (Tipo) del Proveedor 1. Carta de Presentación 2. Resumen de Recomendaciones 3. Ventajas 4. Configuración de la Plataforma Tecnológica 5. Especificación de la Plataforma 5.1 Datos del Técnicos del Desempeño 5.2 Precios

12 5.3 Fechas de Entrega 5.4 PostVenta 6. Satisfacción de los Criterios de Desempeño 7. Programa de Entrega. Preparar la Base de Datos (DBA) Preparar las Instalaciones Físicas Entrenamiento y Capacitación a los Usuarios Preparar la Propuesta de Corte y Cambio SISTEMA ANTIGUO Sistema Piloto (Estrategia PILOTO) Corte y Cambio Inmediato o Corte y Cambio por Fases o Corte y Cambio PARALELO SISTEMA NUEVO SISTEMA ANTIGUO (Estrategia INMEDIATA) SISTEMA ANTIGUO SISTEMA ANTIGUO SISTEMA NUEVO (Estrategia por FASES) SISTEMA ANTIGUO NUEVO SISTEMA NUEVO SISTEMA (Estrategia PARAELA) Tiempo Aprobar o Rechazar la Propuesta de Corte y Cambio Corte y Cambio al Nuevo Sistema. FASE: MANTENCION (USABILIDAD DEL SISTEMA) Usar el Sistema Someter a Auditorías al Sistema Mantención del Sistema (Minimizar la Obsolescencia del Sistema) Mantención (I/E): Preventivas, Correctivas y de Optimización. Preparar una Propuesta de Reingeniería Cuando el sistema a cumplido un ciclo de operaciones a través del tiempo, puede ser necesario una propuesta de repensar la solución o proponer una

13 repotenciación funcional y/u operativa o hacer un nuevo sistema, reinciar el SLC) Aprobar o Rechazar la Reingeniería del Sistema

14 Especificación de Requerimientos de Software (E.R.S. Basado en la IEEE /1984b) (Análisis y Diseño Detallado de Aplicaciones Informática de Gestión, Capitulo Nº7 Mario Piattini) Es una documentación que define los requisitos esenciales (funcionales, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces externas. Las ERS representan, en las fases iniciales del SLC, el fundamento y las bases del producto de software. Requisitos de la ERS: Consignar información veraz y coherente con las necesidades reales de las áreas usuarias beneficiadas con el producto de software. Comunicación eficaz, es decir que su comprensión por el equipo del proyecto (tecnológico - funcional) se íntegra y cabal. Debe especificar la descripción de lo que hay que desarrollar, NO el cómo y el cuándo. El nivel de detalle deber ser tal que no sea excesivo y complejo en su redacción, evitando: - requisitos o funciones innecesarias no definidos por las áreas usuarias. - Detalles del diseño del software, de su verificación o de la gestión del proyecto, con excepción de las restricciones propias del diseño tales como las limitaciones del hardware disponible. Características de una buena ERS: No ambigua Es decir, tiene sólo una interpretación, ello implica que cada característica del producto final sea descrita utilizando un término único y en caso de una eventual interpretación adicional, refinar este concepto con un glosario. En algunos casos expresar en lenguaje estructurado o en seudocódigo para construir secuencias lógicas. Alternativa Repetitiva SI condición Bloque SI NO Bloque FIN SI MIENTRAS condición Bloque

15 Secuencia FIN MIENTRAS REPETIR Bloque HASTA condición Está formada por un conjunto de sentencias (bloque) y cada una de ellas puede ser una acción sencilla o una estructura de las anteriores. Completa Una ERS esta completa si: 1. Incluye todos los requisitos significativos tales como: funcionalidad, ejecución, imperativos de diseño, atributos de calidad o a interfaces externas. 2. Define controles de validación de datos, especificación de clases de datos de entrada y salida en todas las posibles situaciones. 3. Está conforme con cualquier estándar de especificación, en caso contrario explicitar y referenciar la excepción. 4. Están etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas, como así también definidos los términos y unidades de medida. Se debe evitar la expresión por definir, salvo en casos excepcionales en las cuales se debe complementar con las condiciones o restricciones que la motivaron. Fácil de Verificar Si y sólo si cualquier requisito al que se haga referencia se puede verificar fácilmente, es decir, si existe un procedimiento finito, efectivo y costo/beneficioso para que en forma manual o automatizada (Sw) compruebe el software satisface dicho requisito. Consistente Si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflictos. Pueden presentarse 3 tipos de conflictos:

16 1. Dos o mas requisitos pueden describir el mismo objeto real pero utilizan distintos términos para designarlo. 2. Las características especificadas de objetos reales pueden estar en conflictos. (luz verde v/s azul) 3. Puede haber un conflicto lógico o temporal entre 2 acciones determinadas. (+*) Fácil de Modificar Si su estructura y estilo permiten que cualquier cambio necesario en los requisitos se pueda realizar fácil, completa y consistentemente. Esto implica : 1. Tener organización, coherencia y manejable, mediante una tabla de contenidos, índice y referencias cruzadas. 2. No ser redundante, es decir que el mismo requisito no aparezca en más de un lugar de la ERS. (La redundancia no es un error en sí, pero puede llevar a ello) Facilidad para Identificar el origen y las consecuencias de cada Requisito. Cuando facilita las referencias con otros productos del SCL, si establece un origen claro para cada uno de los requisitos y si posibilita la referencia de estos requisitos en desarrollo futuros o en incrementos 1. Referencia hacia atrás o previo al desarrollo 2. Referencia hacia adelante o documentos originados de una ERS. (mantenimiento) Facilidad de utilización durante la fase de explotación (operaciónproducción) y de mantenimiento. Para efectos de mantención del software es importante debido a: 1. Profesionales de mantención de sistemas poder recabar información desde la conceptualización del software. 2. Debe señalarse la criticidad de éste., su relación temporal y su origen. 3. Comprensión del origen para desarrollar el mantenimiento.

17 Evolución de las ERS. Durante el proceso evolutivo del software (tanto al inicio de su diseño como durante el funcionamiento en régimen o explotación de éste) y para minimizar la obsolescencia del mismo es relevante mantener lo siguiente: 1. Actualizar o perfeccionar los ERS especificados al inicio cuando en fases posteriores no se ajustan durante el diseño afinado del sistema. 2. En la fase de mantención debe iniciarse un proceso formal de cambios o control de cambios debidamente documentado mediante las ERS. 1. Introducción 1.1 Objetivo 1.2 Ambito 1.3 Definiciones, Siglas y Abreviaturas 1.4 Referencias 1.5 Visión Global 2. Descripción General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Características del Usuario 2.4 Limitaciones Generales 2.5 Supuestos y Dependencias Estructura de una E.R.S. (IEEE Std. 830 IEEE, 1984b-2001) 3. Requisitos Específicos 3.1 Requisitos Funcionales Requisito Funcional Introducción Entradas Procesamiento Salidas Requisitos Funcional Requisito Funcional n 3.2 Requerimiento de Interfaz Externa Interfaces de Usuario

18 3.2.2 Interfaces de Hardware Interfaces de Software Interfaces de Comunicación 3.3 Requisitos de Ejecución 3.4 Restricciones de Diseño Acatamiento de Estándares Limitaciones de Software Atributos de Calidad Seguridad Mantenimiento Otros Requisitos Base de Datos Operaciones (Explotación) Adaptación de Situación (Inducción)... (Otros formatos de ERS son DOD,1988; Dorfman y Thyer, )a