Ingeniera de software Tarea 1 Conceptos Mgr Indira

Ingeniería de software Tarea 1 Conceptos Mgr. Indira Camacho del Castillo UMSS: Cochabamba - Bolivia

Conceptos Ingeniería de sistemas: Es un modo de enfoque interdisciplinario que permite estudiar y comprender a los sistemas, con el propósito de implementar u optimizar sistemas complejos. Ingeniería de requerimientos: Enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema. Ingeniería de producto: Es el software acabado, esta orientado a hacer sistemas para mercados grandes, se concentra en las características que tiene que tener el producto para ser vendido, comercializado. Ingeniería de procesos negocios: Se hace software para una empresa, se observa como trabaja o funciona una empresa, modifica la estructura organizacional de una institución(tareas que ocupaban funcionarios ahora los procesa el software). Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 2

Conceptos Ingeniería de software: Es el proceso de desarrollo de software, mediante métodos y técnicas para resolver problemas reales de la sociedad. Ingeniería de requisitos: Facilita el mecanismo apropiado, para comprender lo que quiere el cliente. Es parte de la ingeniería de requerimientos. Ingeniería de pruebas: Un producto no probado no sale al mercado, constantemente buscan errores e identifican, ellos van probando y se aseguran de que el producto sea de calidad. Sistemas de información: Es un conjunto de partes que interactúan entre si para lograr un objetivo. El sistema de información es considerado como un conjunto de componentes interrelacionados que recuperan, procesan, almacenan y distribuyen información para soportar la toma de decisiones, la coordinación y el control de una organización. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 3

Relaciones Bajo el concepto de ingeniería de sistemas se entiende una ciencia que estudia como mejorar los sistemas organizacionales, de producción, ventas, comercialización y otros. Para ello normalmente se apoya en sistemas computacionales Cuando la ingeniería de software se orienta a una organización se denomina ingeniería de proceso de negocios. Cuando se orienta a un producto se denomina ingeniería de producto. Para que ingeniería de software nos ayude a construir sistemas complejos o simples debemos hacer uso de la ingeniería de requerimientos o requisitos, ingeniería de pruebas y otros procedimientos. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 4

Relaciones Ing. Sistemas de información automatizados Ing. producto Ing. de requerimientos Ing. de requisitos Ing. Software Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Ing. Proceso = Ing. de pruebas negocios Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 5

Repaso Tarea 1: Contrastar/relacionar/definir: Mejor si muestran mediante un diagrama las relaciones/diferencias entre los siguientes conceptos: Ing. Sistemas Ing. Software Ing. Requerimientos Sistemas de información Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Ing. Producto Ing. Requisitos Ing. Proceso Negocios Ing. Pruebas Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 6

Tema III: Fase de Definición Actividades de: Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia • Análisis • Planificación Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software

Análisis de Sistemas

Análisis de sistemas Objetivo Producto El Documento de Especificación de requerimientos sirve para realizar el contrato entre el cliente y el desarrollador Existen dos paradigmas a través de los cuales se enfrenta la actividad análisis de sistemas: Paradigma Estructurado Paradigma Orientado a Objetos Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 9

Actividades del Análisis 1. Estudio de Factibilidad 2. Obtención y análisis de requerimientos Comprensión del dominio Prototipado (opcional) Recolección de requerimientos Clasificación de información Resolución de conflictos 1. Reconocimiento del problema 2. Evolución y síntesis: (Modelamiento /prototipeo) 3. Especificación 4. Revisión Final Priorización Verificación de requerimientos 3. Especificación de requerimientos 4. Validar requerimientos Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 10

Repaso Tarea 1: Análisis de Sistemas 2. Identificar los paradigmas que se utilizan para el análisis de sistemas. Explicar los 2 más usados y por cada uno de ellos señalar las herramientas y notaciones a usar. 3. Describir el proceso de análisis: pasos a seguir y sus entregables/productos. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 11

Documento de requerimientos Los requisitos establecidos explícitamente se reflejan en el documento de especificación de requisitos del sistema: Requerimiento: Un requerimiento puede ser especificado desde una sentencia en lenguaje natural, hasta en un lenguaje matemático muy formal. La línea entre requerimientos y especificaciones de diseño es delgada. Las especificaciones de requerimientos deberían producirse a diferentes niveles de abstracción tomando en cuenta que una Especificación del Sistema debe ser entendida por los potenciales usuarios, de forma que sirva de base para realizar el contrato entre el ingeniero y los usuarios, quienes prefieren una descripción abstracta y a más alto nivel que la especificación para el contrato. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 12

¿Qué es un requerimiento? DEFINICIÓN: Un servicio que el sistema debe proveer Una característica o restricción que debe cumplir. Ejemplos. . Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia • No es una necesidad • No es un problema Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 13

Tipos de requerimientos Funcionales: funciones a realizar por el software. Son declaraciones de los servicios que proveerá el sistema. Estos requerimientos son el corazón del sistema, puesto que su existencia explican la necesidad del mismo. Algunas veces los requerimientos funcionales también declaran explícitamente lo que el sistema no debe hacer. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Este es el corazón del sistema, si no fuera por los requerimientos funcionales, el sistema no tendría razón de ser. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 14

Ej: requerimientos funcionales Sistema de cajero automático. RF 1: Identificar usuario. RF 2: Emitir estado de cuenta. RF 3: Realizar transacción de retiro de dinero RF 5: Emitir recibo impreso. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 15

Tipos de requerimientos No funcionales: Son restricciones bajo las cuales el sistema debe operar. Aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de este como la fiabilidad, la respuesta en el tiempo, la capacidad de almacenamiento, interfaz, documentación, consideraciones de hardware, características de desempeño, manejo de errores, condiciones extremas, asuntos de calidad, modificaciones al sistema, ambiente físico, cuestiones de seguridad, cuestiones de recursos, políticas de la organización en cuanto al software o hardware Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema Estos deben ser cumplidos, acompañan al sistema en sí para que sea usado. Por ejemplo: Si pedimos que un sistema sea hecho en un administrador de BD determinado y no lo hacemos el usuario no hará uso de él porque la BD de la empresa esta sobre ese administrador Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 16

Más sobre requerimientos Requerimiento de usuario: Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema. Hay que tomar en cuenta que el usuario no posee un conocimiento técnico detallado Especifican el comportamiento externo del sistema. Los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos Debido al lenguaje no formal para la especificación pueden surgir problemas como: falta de claridad o detalle, ambigüedades y otros relacionados con el lenguaje natural. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 17

Más sobre requerimientos Requerimientos del sistema Son descripciones más detalladas y formales que los requerimientos del usuario. Agregan detallan y explican como el sistema debe proporcionar los requerimientos del usuario Sirven como base para definir el contrato de la implementación del sistema y por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema. Simplemente deben describir el comportamiento externo del sistema y sus restricciones operativas Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 18

Diagrama de Relaciones de los Conceptos dados Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Se detallan Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 19

Cualidades Requerimientos Del documento de Esp. de Requerimientos Completo Consistente: Los requerimientos no tienen conflictos entre si Documentado Modificable: Su estructura facilita los cambios. De un requerimiento Correcto Verificable: debe poder definirse si se cumplió o no. sistema. Válido: lo que el usuario realmente quiere No ambiguo: una sola interpretación Documentado Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 20

¿Gestión de Requerimientos? Un Clásico…. . La solicitud de usuario Lo que entendió el líder del proyecto El diseño del analista de sistemas El enfoque del programador La recomendación del consultor externo La documentación del proyecto La implantación en producción El presupuesto del proyecto El soporte operativo Lo que el usuario realmente necesitaba ¿ Necesario hacer gestión de requerimientos ? • Los requerimientos son los cimientos de un sistema • Los requerimientos son el “cuello de botella” de la Ing. de Software

Análisis - Subactividad: Modelado del sistema La construcción del Watercube inició en diciembre de 2003 y se planea que esté completamente terminado a principios de 2007. Cinco piscinas, luz natural, acopio de agua de lluvia, reciclado del agua. Costo mas de 100 millones de dólares Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Nido de pájaros Cubo de Agua Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 22

Modelado del sistema ¿Cuándo se realiza esta actividad dentro del proceso de desarrollo de software que se definió en la parte 1. ? Actividades de Análisis y Diseño. ¿Que modelos existen y cómo se representan? Modelos de contexto: Estructurado (DFD de nivel O), OO (Caso de uso general), Modelos comportamiento: OO ( diagrama de casos de uso, diagrama de secuencia, diagrama de actividad), Estructurado: DFD’s Modelos de datos: OO: Diagrama de clases. Estructurado: E-R Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 23

Modelado del sistema Modelos: ¿para qué sirven ? Para describir el sistema formalmente Cuándo usar ? Los modelos se utilizan en la actividad de análisis y diseño. Los modelos ayudan a comprender el sistema/requerimientos /diseño y se deben usar cuando sea difícil la compresión sin ellos o la especificación pueda dar lugar a ambigüedades. Los modelos ayudan a manejar la complejidad del sistema Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 24

Técnicas de relevamiento (recolección) de información Entrevista. - Se selecciona a un conjunto de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Cuestionarios. - Consiste en el llenado formularios o contratos indicando los requerimientos. En sistemas muy complejos éstos pueden tener centenares de páginas. Y se usan cuando hay muchos usuarios, y es difícil entrevistarlos a todos. Talleres. - Reuniones con varios usuarios para concertar requerimientos. Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Observación Revisión documental Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Carrera de Sistemas&Informática Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 25 25

Técnicas/Herramientas Prototipos. - Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de Uso. - Un caso de uso es una técnica para documentar posibles requerimientos, graficando la relación del sistema con los usuarios u otros sistemas. DFD’s Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 26

Fuentes de información Personas: Usuarios directos e indirectos del sistema Colegas con experiencia Otros sistemas Internet Documentos de la empresa Libros relacionados con el software a construir De todas estas fuentes las personas son la fuente más relevante. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 27

Repaso 2: Análisis (tarea 2) 1. Contrastar/relacionar/definir: Mejor si muestran mediante un diagrama las relaciones/diferencias entre los siguientes conceptos 2. Requerimientos funcionales -Requerimientos no funcionales. Requerimientos Usuario- Requerimientos del Sistema 3. De ejemplos por cada concepto de arriba 4 ejemplos aplicados a un sistema que le gustaría desarrollar 4. Modelado del sistema : Cuando se realiza esta actividad dentro del proceso de desarrollo de software que se definió en la parte 1. ? Que modelos existen ? Para qué sirven ? Cuándo usar ? 28 Carrera de Sistemas&Informática Como se representan? Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software UMSS: Cochabamba-Bolivia

Documento de Especificación de Requerimientos Tarea 3

El documento de especificación de requerimientos 1. Introducción/Contexto 1. -Introducción ir Propósito del documento de requerimientos Alcance del producto 2. Requerimientos funcionales&No funcionales 2. -Descripción general Perspectiva del producto 3. Usuarios/roles: Indirectos/directos Funciones del producto Restricciones generales Características del usuario 4. Alcance 3. -Requerimientos específicos Requerimientos funcionales ir 5. Anexos: Documentación, Requerimientos no funcionales ir procedimientos, información sobre valores usados, validación. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia 4. - Alcance 5. - Apéndice e índice ir Plan Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 30

Introducción La introducción debe introducir al tema que en este caso es el sistema. Se debe hablar de la institución, sus objetivos planes y como el sistema ayudará a lograrlos. Se debe establecer los objetivos de la institución a largo, mediano y corto plazo y dentro de ese contexto establecer el lugar que tendrá el sistema. Es importante ubicar al sistema en el ámbito de la organización. Doc Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 31

Apéndices (anexos) e Indices Apéndice provee información detallada y precisa relacionada con la aplicación que se desarrolla Todo lo que no se especificó en la parte principal de forma detallada y da lugar a doble interpretación debe ser aclarado y especificado en los anexos. Es aquí que se debe DOCUMENTAR el análisis, es decir: se deben poner copias u originales de documentos como ser formularios de registro de datos, reportes, resúmenes que actualmente utilizan en la empresa (sean estos de origen manual o de del antiguo sistema automatizado que se desea cambiar), definir las características de los datos de los mismos, especificar procedimientos y/o cambios en los mismos. Índice se debe incluir varios índices en el documento uno alfabético, de contenido, diagramas, funciones y otros. Doc Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 32

Repaso Doc. Req. 1. 2. 3. 4. (tarea 3) Especifique el contenido mínimo. Explique mediante un ejemplo en que consiste cada una de sus partes ( a través de un caso de aplicación). Indique fuentes de información son recomendables para su elaboración y en que consiste cada una de ellas. Condiciones que tiene que cumplir o características que debe tener el documento para ser considerado de calidad. Mencione el contenido de los anexos que debería tener este documento. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 33

Antes de hacer un plan y después de un análisis previo Análisis de Factibilidad Análisis de opciones

Análisis de factibilidad Objetivo Resultados Es asegurarnos que el proyecto va traer beneficios y es posible realizarlo con los recursos materiales, tecnológicos y humanos Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia • Seguir adelante con el proyecto • Recomendar retrasar por un tiempo • No continuar con el proyecto • Continuar con el proyecto modificado Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 35

Análisis de factibilidad Consideraciones: Factibilidad económica (administrador de la empresa): Beneficios $ Vs. Costos $ Factibilidad técnica (desarrollador/administrador) Factibilidad operativa (desarrollador) Factibilidad legal (desarrollador) Factibilidad política Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 36

Análisis de opciones Objetivo Es escoger el proyecto que más ventajas tiene. Producto Informe indicando la mejor opción y por qué Se necesita establecer: 1. Objetivos & Prioridades 2. Establecer parámetros de comparación 3. Cuantificar los parámetros elegidos para cada una de las opciones 4. Aplicar algún método para elegir objetivamente una opción. Métodos Matriz pay-off Gráficos de polaridad Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 37

Análisis de opciones: Matriz Pay-off Opción A B Costo Máximo Costo Mínimo ($) 100. 000 70. 000 40. 000 55. 000 Payoff ($) 60. 0000 15. 000 1. Opción conservativa: objetivo minimizar las pérdidas, elegirá la opción con payoff más bajo: 15. 000. 2. Opción optimista: el objetivo de maximizar las ganancias, elegirá la opción con payoff más grande: opción A. Sin embargo ni la opción conservativa, ni la optimista toma las en cuenta las magnitudes relativas de las ganancias o las pérdidas, por lo que se planteó la siguiente: Carrera de Sistemas&Informática Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software UMSS: Cochabamba-Bolivia 38

Análisis de opciones: Matriz Pay-off Opción minimización de riesgos: considera la misma probabilidad para el máximo valor como para el mínimo, por ejemplo: Opción A: Opción B: Costo probable = (0, 5 x 100. 000) + (0, 5 x 40. 000) = 70. 000 Costo probable = (0, 5 x 70. 000) + (0, 5 x 55. 000) = 62. 500 Por lo que de acuerdo a esta tercera opción escogeríamos la de menor riesgo la opción B con 62. 500. Si se conociese la probabilidad para A que se de el mínimo, por ejm. 65%. Y para B la probabilidad de mínimo, por ejm. 45% Opción A: Opción B: Costo probable = (0, 35 x 100. 000) + (0, 65 x 40. 000) = 61. 000 Costo probable = (0, 55 x 70. 000) + (0, 45 x 55. 000) = 63. 250 Por lo que en este caso la opción A sería la escogida puesto que permite minimizar riesgos. Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 39

Análisis de opciones: Gráfico de polaridad Opción Costo Miles Bs. Calendario (meses) Confiabili dad Reuso (%) Portabilidad Eficiencia A B C 12. 0 8. 0 17. 5 33 30 36 5 9 13 40 40 50 90 75 30 0. 35 0. 75 1 Carrera de Sistemas&Informática UMSS: Cochabamba-Bolivia Mgr. Indira Camacho del Castillo Materia: Ingeniería de Software 40