Software Engineering

Software Engineering • Lec01. Introducción • Un poco de historia • Originalmente la mayor parte de los esfuerzos estaban concentrados en el desarrollo del hardware • Segunda generación de computadoras: • primeros sistemas operativos • primeros lenguajes de alto nivel • Se comenzaron a separar las aplicaciones de las máquinas en • donde se implementan. • Desarrollo de sistemas de multiprogramación: • aumento en la complejidad de los programas • aumento en la complejidad de los programas • Definición de software • Un programa • Simple • Sin documentación • Los errores no importan mucho • Usado por su creador Notas J. Navarro/2004

Software Engineering Definición de software La IEEE define software como la colección de programas, procedimientos, reglas y la documentación y data asociada. Por lo tanto, un software no es solamente un conjunto de programas. Costo del software Notas J. Navarro/2004

Software Engineering Un desarrollador de software genera un promedio de 300 a 1000 líneas de código por mes. Las compañías cobran alrededor de $100,000 por desarrollador/año lo que es alrededor de $8000 por desarrollador/mes o $50 por desarrollador/hora o entre $8 a $25 por línea de código. Problemas con el desarrollo del software Según estudios que se han realizado en las empresas en los Estados Unidos, más del 35% reportaron tener proyectos de software que se encontraban fuera de control en términos de calendario y de presupuesto. Muchos de estos proyectos terminan muy tarde y en ocasiones terminan costando más de 10 veces el estimado inicial. Muchos nunca se terminan. En un reporte del departamento de defensa se informó que más del 70% de las fallas fueron causadas por problemas en el software. Costos de la modificación del software Mantenimiento correctivo: en el que se realizan cambios en el software para corregir errores descubiertos Notas J. Navarro/2004

Software Engineering • Mantenimiento adaptativo: se realizan cambios en el software para atemperarlo a las nuevas condiciones y requisitos del ambiente en que se utiliza. • Pruebas de regresión: las que se realizan cuando se hacen cambios en un software para verificar que no se introducen efectos secundarios no deseados • Las fallas en los equipos pueden deberse al desgaste pero las del software están en el sistema desde el principio. • Algunos estudiosos del área indican que la razón de costos entre el mantenimiento y el desarrollo del software va desde 60:40 hasta 80:20. • Resulta difícil estableces los requisitos • Los cambios que se realizan en el desarrollo, debido a los cambios en las especificaciones consumen entre el 30 y el 40% de los recursos. Notas J. Navarro/2004

Software Engineering • Lec02 Consideraciones en el Desarrollo del Software • En muchas ocasiones el desarrollo se hace por métodos ad hoc en lugar de formales y lo que funciona para aplicaciones pequeñas no pude ser extendido para aplicaciones grandes. • Algunas definiciones de Ingeniería de Software • Ingeniería de software es enfoque sistemático para el desarrollo, operación, mantenimiento y retiro del software • Ingeniería de software es la aplicación de las ciencias y las matemáticas por las cuales las capacidades de un equipo de computadora se vuelven útiles al hombre vía los programas de computadoras, procedimientos y la documentación asociada. • Estas definiciones implican que • la ingeniería de programación tiene que apartarse de ser un arte • y convertirse en un método científico • el producto tiene que poder ser utilizable por el hombre Notas J. Navarro/2004

Cantidad de líneas Tamaño el proyecto 2000 Pequeño 8000 Intermedio 32000 Mediano 128000 Grande Software Engineering Implicaciones del tamaño del proyecto en el enfoque para resolverlo Lo que aplica para sistemas pequeños no necesariamente aplica para problemas grandes Figura 1.2 Problema de expansión en el desarrollo de software Tabla 2.1 Tamaño del proyecto según el número de líneas de código que requiere Notas J. Navarro/2004

Software Engineering Parámetros que afectan la ingeniería de software Costos costo del equipo aplicaciones mano de obra (más costoso) programación de tiempo (scheduling) ventanas de tiempo desarrollo rápido de aplicaciones (RAD Calidad Operación del Producto corrección confiabilidad eficiencia usabilidad Transición del Producto portabilidad interoperabilidad Revisión del producto facilidad para mantenimiento facilidad para realizar pruebas Consistencia predicciones desarrollo de un software estabilidad y aceptación de la compañía La confiabilidad es el factor más importante Se mide en defectos por líneas de código Notas J. Navarro/2004

Software Engineering Lección 03: Fases de la ingeniería de software Objetivo de la ingeniería de programación El objetivo de la ingeniería de programación es: Desarrollar métodos y procedimientos para el desarrollo de software que se puedan expandir para sistemas grandes y que se puedan utilizar para producir consistentemente software de lata calidad a bajo costo y con un ciclo de tiempo corto. Análisis de requisitos Producto final de esta fase es un documento de especificaciones de requisitos para el software (SRS) Diseño del software Establece cómo se solucionará el problema documento de diseño diseño del sistema diseño detallado Notas J. Navarro/2004

Software Engineering Codificación El objetivo del código debe ser reducir los costos de las pruebas de verificación y validación y del mantenimiento ya que estos son muchos más costosos que la codificación. Fase de pruebas El objetivo de esta fase es detectar los errores que se cometieron en todas las fases anteriores Tipos de pruebas pruebas de módulos individuales (parte de esto se realiza durante la codificación) pruebas de integración e interacción de módulos pruebas del sistema pruebas de aceptación (con el cliente) Documentos documento de especificaciones de pruebas reporte de pruebas reporte de errores Notas J. Navarro/2004

Software Engineering • Gerencia del proyecto • Es necesario conocer si el proyecto está corriendo en el tiempo esperado, conocer si se está dentro del presupuesto, determinar la necesidad de recursos y determinar que ajustes se necesitan, entre otros. • Medidas de software • medidas del producto • para cuantificar las características del producto • medidas del sistema • para cuantificar las características del proceso de desarrollo del software. Notas J. Navarro/2004

Software Engineering • Procesos de Software • El proceso de software se refiere al método para desarrollar software . • actividades de desarrollo • actividades de gerencia • Tres entidades importantes de ingeniería de software • procesos de software • proyectos de software • productos de software • relación entre ellos Notas J. Navarro/2004

Software Engineering Procesos de Software de Componentes El proceso de desarrollo del producto (software) tiene como meta desarrollar un producto que satisfaga al cliente Para los proyectos muy complejos, la gerencia es más importante que los métodos técnicos Componentes principales en el proceso de software Proceso de desarrollo Proceso de gerencia del proyecto Notas J. Navarro/2004

Software Engineering Gerencia de configuración Otro proceso necesario en del desarrollo del producto es del de gerencia de configuración del software. Objetivo: manejar los cambios que ocurren durante el desarrollo del producto de forma que los costos y la calidad se mantengan dentro de los límites aceptables sin alterar la integridad del producto. Características de un proceso de software Predecibilidad Facilitar la realización de pruebas Facilitar el mantenimiento Distribución del esfuerzo en el desarrollo de un software Requerimientos 10% Diseño 20% Codificación 20% Pruebas 50% Notas J. Navarro/2004

Software Engineering Distribución del tiempo de los programadores Escribir programas 13% Leer programas y manuales 16% Comunicación relacionada con el trabajo 32% Otras actividades, incluyendo las personales 39% Distribución de la ocurrencia de errores Análisis de requisitos 20% Diseño 30% Codificación 50% Notas J. Navarro/2004

Software Engineering Implicaciones Es necesario detectar y corregir los errores temprano Es necesario prevenir la ocurrencia de erroes Notas J. Navarro/2004

Software Engineering • Proceso de desarrollo de software • Se encarga, principalmente, del diseño, codificación y pruebas. • Cada paso debe acercar más al proceso al objetivo final del proyecto • El producto final de cada paso debe ser la entrada del próximo • Al final de cada fase se necesitan mecanismos de verificación y • validación • En la verificación se coteja que el producto de la fase esté en • acorde con las entradas de la fase • En la validación se verifica que se cumplan con los requisitos • del usuario del producto • Los productos de las fases del desarrollo del software tienen que ser • formales y cuantificables • Los pasos no dan detalles de cómo se debe realizar las actividades • sino cuáles deben ser sus entradas y salidas Notas J. Navarro/2004

Fase Producto Estudio de viabilidad Reporte de viabilidad Análisis de requisitos Doc. de especificaciones de requisitos Planif. del proyecto Plan del proyecto Diseño del sistema Documento de diseño del sistema Diseño detallado Documento del diseño detallado Codif. y prueba de la unidad Código del programa Integración del sistema Docs. de proceso y pruebas de integración Pruebas Plan y resultados de las pruebas y manuales Instalación Reporte de la instalación Oper. y mantenimiento Software Engineering • Modelos • Con el objetivo de realizar el proceso de desarrollo de software se han desarrollado varios modelos • Modelo de cascada • -El más simple y utilizado • Sigue una estructura lineal estricta Notas J. Navarro/2004

Software Engineering • Justificación del modelo de cascada • - De una u otra forma todas las fases se tienen que realizar • - La organización de las fases es óptima • Limitaciones del modelo de cascada • - Asume requisitos estáticos . • - Implica seleccionar el hardware desde el comienzo. • Los requisitos tienen que estar establecidos completamente antes de • proseguir el resto del proceso. • Requiere mucha documentación • El modelo de cascada es, a pesar de sus limitaciones, el más utilizado, sobretodo en el desarrollo de aplicaciones cuyas especificaciones se conocen bastante bien. Modelo de prototipo En este modelo se desarrolla un prototipo desechable del sistema con el objeto de comprender mejor sus requisitos. Análisis de requisitos Diseño Codificación Pruebas Pruebas Codificación Diseño Notas J. Navarro/2004

Software Engineering • Características del modelo de prototipo • Adecuado para sistemas complejos y en donde no se tienen sistemas • previos • Sólo aquellos componentes que provean un resultado costo-efectivos • son implementados • Aquellas partes que se conozcan bien o que resulten triviales no se • implementan • El proceso se termina cuando se considera que seguir desarrollando • prototipos resultará más costoso que seguir adelante con el proceso sin • desarrollarlos. • Ventajas del modelo de prototipo • Los conocimientos que se adquieren durante el desarrollo del • prototipo pueden reducir el costo del desarrollo del software más • adelante • Se ajusta mejor que el modelo de cascada a situaciones en donde los • requisitos sufren muchos cambios. • Se logra congelar los requisitos más tarde en el proceso, cuando es de • esperar que sean más estables. • Como tanto los desarrolladores como el cliente trabajan en el • desarrollo de los prototipos es más probable que las especificaciones • de los mismos se acerquen más a la realidad Notas J. Navarro/2004

Software Engineering • Modelo de mejoramiento iterativo • Se desarrolla el software de forma incremental. • En primer lugar se desarrolla el núcleo del sistema, dándole prioridad a • las especificaciones que se conocen bien • El proceso contiene una lista de las tareas que se desean realizar (lista • de control del proyecto) las cuáles se van eliminando en orden con cada • iteración • El propósito de cada iteración es eliminar la próxima entrada en la lista - Luego de cada iteración se pueden realizar modificaciones, las cuáles se • utilizarán en el desarrollo de la próxima iteración • Al final de cada etapa se realizan las pruebas de integración del sistema. - Cuando todas las tareas se remueven de la lista de control el sistema • está terminado. • Útil cuando los desarrolladores tienen bastante control sobre los requisitos del sistema ya que pueden establecer la lista de control ellos mismos. El modelo iterativo básicamente lo que hace es aplicar el modelo de prototipos de forma iterativa. Análisis de requisitos Diseño Codificación Pruebas Pruebas Codificación Diseño Notas J. Navarro/2004

Software Engineering • Modelo de espiral • En este modelo se trazan diferentes objetivos y se hace pasar cada uno por diferentes fases: • - determinar los objetivos, alternativas y restricciones • - evaluar las alternativas, identificar y resolver los riesgos • - desarrollar y verificar el producto de ese nivel del espiral • - planear la siguiente fase • Las actividades se organizan en secuencia como en un espiral en donde la dimensión angular representa el progreso alcanzado y la dimensión radial representa el costo incurrido hasta el momento. Notas J. Navarro/2004

Software Engineering Notas J. Navarro/2004

Software Engineering Proceso de Gerencia del Proyecto Objetivo: presentar, de forma detallada, las tareas que se tienen que realizar para que el desarrollo del software cumpla con los estándares de calidad y costos establecidos. Sus actividades se pueden organizar en tres grupos: Planificación: Desarrolla un plan mediante el cual se pueda implantar el proceso de desarrollo de software de forma que se pueda cumplir con los objetivos del proyecto de forma exitosa y eficiente. Monitoreo y control: La mayor parte de esta actividad (que es la más larga de las tres) gira alrededor de los factores de costo, programación de tiempo y calidad ya que estos son los más importantes del proceso. Esta actividad puede detectar la necesidad de tomar acciones correctivas con respecto al proceso. Estas actividades pueden incluir el reducir el alcance del proyecto, renegociar los costos, renegociar la programación del tiempo, añadir mano de obra y utilizar otros tipos de herramientas. Análisis de la finalización del proyecto: Esta actividad se realiza luego de la terminación del proyecto. La importancia de esta actividad estriba en que puede proveer valiosa información que nos permita determinar que ocurrió durante el proyecto. Esta información podrá ayudar a planificar mejor futuros proyectos. Notas J. Navarro/2004

Software Engineering • Proceso de Gerencia de Configuración del Software • IEEE :: ‘es el proceso de identificar y definir las entidades de un sistema, controlar los cambios en esas entidades durante su ciclo de vida, grabar y reportar el estado de las entidades y peticiones de cambio y verificar que estén completos y correctos” • La ocurrencia de cambios durante el proceso de software es inevitable • Los modelos de desarrollo de software no proveen métodos efectivos • para manejar los cambios • Es necesario tener una entidad externa que maneje los cambios • - La gerencia de configuración de software es quien aprueba que • cambios se deben realizar, determina su impacto, decide que acciones • se deben tomar para poder realizar los cambios, etc. • Los cambios los implementarán los desarrolladores del software • El uso de la gerencia de configuración de software es beneficiosa en • términos costos y calidad. Notas J. Navarro/2004

Software Engineering Especificaciones de los Requisitos del Sistema • Actividades Básicas • Análisis del Dominio del Problema • Especificaciones de los Requisitos Notas J. Navarro/2004

Software Engineering • Análisis del Problema • Comienza con la recolección de información • aplicar ingeniería del conocimiento con los clientes y usuarios • documentar el modo actual de realizar el proceso (si existe) • tratar de llegar a un consenso en los conflictos que surjan • definir el dominio de interés • Continuar estructurando la información que se obtiene • Ejemplo de una problema The Puerto Rico department of transportation has requested a proposal for the development of a computer controlled system to control traffic at the entrance of Plaza Ferrán in Aguadilla. The hardware includes a set of sensors, the traffic lights and a controller. The software reads the state of the sensors, determines the state of traffic in the intersection, and signals the lights to change state. The system has a test mode and a default state in which all lights flash red. The sensors detect the presence of vehicles and pedestrians. All the sensors are interrupt-driven and a bit is set when the sensor is tripped. The reset function is under software control. Traffic lights are of the 3 color type and turn signals and pedestrian signals will also be used. The controller contains the light relays, a data store for the sensors, a power supply and a microprocessor. Someta su Propuesta Notas J. Navarro/2004

Software Engineering • Estructuración de la Información de los Procesos • Descomposición del problema • Abstracción del problema • Proyección del problema • Utilizar Diagramas de Flujo de Data para representar los resultados del • análisis • Ejemplo de un Diagrama de Flujo de Data para el proceso de pago de nómina de un empleado Notas J. Navarro/2004

Software Engineering Diccionario de Data weekly timesheet = Employee_name + Employee_ID [Regular_hours + Overtime_hours]* Pay_rate = [hourly | daily | weekly] Dollar_amount Employee_name = Last + First + Middle_initial Employee_Id = digit + digit + digit + digit Notas J. Navarro/2004

Software Engineering El Paradigma de Movernos hacia la Programación Orientada a Objetos • Procedural Structuring: • Descomposición “Top- • Down” de la solución • propuesta • La arquitectura es fijada • junto con la solución • algorítmica • El proceso es dividido en • fases con interfaces • establecidas por los • diagramas de flujo de data • La implementación es una • serie de llamadas a funciones • La data es separada de los • procesos • Object-oriented Structuring • Se repasa el espacio total del problema • La arquitectura se basa en las relaciones del dominio del problema • El proceso es una iteración incremental de elaboración • La implementación se descompone en objetos conteniendo la data y métodos (algoritmos) Notas J. Navarro/2004

Software Engineering Ejemplo de un Diagrama de Objetos para el Ejemplo de la Nómina Notas J. Navarro/2004

Software Engineering • Características de las especificaciones de los requisitos • Entendibles • No ambiguas • Completas • Verificables • Consistentes • Modificables • Rastreables • Componentes Principales del Documento de Especificaciones de los Requisitos del Software (SRS) • Requisitos Funcionales • relaciones entre entradas y salidas • casos de excepciones • Requisitos de Rendimiento o Eficiencia • Capacidad • Tiempos de respuesta específicos y generación de resultados • Restricciones en el diseño • Para cumplir con estándares • Limitaciones de hardware • Tolerancia de recuperación de fallas • Particiones de seguridad, autentificación y criptología • Requisitos para la interfaz externa • Interfaz con el usuario • Otras interfaces del sistema Notas J. Navarro/2004

Software Engineering • Validación del Documento de Especificaciones de Requisitos • Lectura • Construcción de escenarios • Revisiones o repasos de los requisitos • Utilización de técnicas automatizadas • Utilización de prototipos • Métricas de los Requisitos • * No se puede manejar lo que no se puede medir • Las herramientas para obtener métricas de los procesos de software han • ganado gran aceptación en los últimos años • Las métricas se utilizan para obtener estimados y medidas de los • recursos y la calidad • Las métricas son más importantes y menos utilizadas durante la fase de • la especificación de los requisitos Notas J. Navarro/2004

Software Engineering • Algunas Técnicas para Aplicar Métricas al Desarrollo de Software • Calibración histórica de errores • número de requisitos funcionales obviados • número de clarificaciones y ambigüedades • número de requisitos inverificables • número de requisitos incorrectos Errores en el SRS para El Tigre Corp. Notas J. Navarro/2004

Software Engineering Frecuencia de las Requisiciones para Cambios • Análisis de Puntos de Funciones • Inventado en 1979 por A. J. Albretch de IBM, esta técnica • revolucionó la ingeniería de software • Provee una técnica para medir la complejidad del software en • términos económicos • Reemplaza las Líneas de Código como medida de la productividad • de software • Puede aplicarse durante la fase de especificación de requisitos • Ha evolucionado sustancialmente desde 1979 • En 1986 la ‘International Function Point User Group’ (IFPUG) se • formó para unir las 500 mayores corporaciones que utilizaban el • análisis de puntos de funciones • La taza de crecimiento del análisis de puntos de función se ha • duplicado cada año Notas J. Navarro/2004

Software Engineering Técnica Original de Puntos de Funciones de Albrecht Number of inputs X 4 = ____ Number of outputs X 5 = ____ Number of inquiries X 4 = ____ Number of data files X 10 = ____ Number of interfaces X 7 = ____ Total = ____ Complexity Adjustment +/- 25% 5120 2560 1280 640 320 160 Tamaño de la Aplicación en Puntos de Función 80 40 1 2 4 8 16 32 64 128 Duración del Proyecto en Meses Tiempo de Entrega Promedio de El Tigre Corp. Notas J. Navarro/2004

Software Engineering • Monitoreo y Control • Se necesita evitar el problema del “objetivo que se mueve” causado • por requisitos cambiantes • Los clientes tienen que “comprar” las consecuencias de los cambios • en la funcionalidad del sistema • La renegociación de los requisitos es crítica • Los requisitos deben ser fáciles de modificar y de rastrear • Un proceso de control de cambios formal es escencial Notas J. Navarro/2004

Software Engineering Estructura del documento para la especificación de los requisitos del software (RSD) Abstract: Explica de forma breve (un párrafo) el documento que se desarrollará incluyendo de forma general las entradas, salidas y restricciones. 1. Introducción 1.1. Propósito: Indica en forma breve el propósito del documento (no del software) 1.2. Ámbito: Indica el enfoque y alcance del documento. 1.3. Definiciones, Acrónimos, Abreviaciones: Incluye toda la nomenclatura del dominio del problema que requiere definirse. 1.4. Referencias: Incluye las fuentes a las que se hace referencia o de donde se obtuvo parte de la información (especificaciones) contenida en el documento 1.5. Resumen de las Responsabilidades del Desarrollador: Indica, de forma general los compromisos del desarrollador. 2. Descripción General 2.1. Resumen de las Funciones del Producto: Explica de forma detallada, pero sin entrar al nivel técnico, la situación con la que se desea resolver, las restricciones y la forma de operación del software que se desarrollará. Notas J. Navarro/2004

Software Engineering 2.2. Características de Usuario: Explica quiénes, de forma general, utilizarán o interactuarán con el sistema y las características que se asume tendrán. 2.3. Restricciones Generales: Indica las restricciones dentro de las cuáles operará el sistema. 2.4. Presunciones Generales: Indica las premisas que se consideran como ciertas para el ambiente en el que se usará el sistema. 3. Requisitos Específicos 3.1. Entradas y Salidas: Se especifican todas las entradas y salidas (manuales, de archivo, comunicación electrónica, etc.) que tendrá el sistema y el formato de la información en cada una de ellas. 3.2. Requisitos Funcionales: Especifica todas las tareas que realizará el sistema. Las tareas deben estar organizadas de forma tal que tanto el cliente como el desarrollador puedan comprender lo que dice y sus implicaciones. 3.3. Requisitos para la Interfaz Externa: Explica los requisitos para la interacción del sistema con los usuarios humaos y no humanos. Notas J. Navarro/2004

Software Engineering 3.4. Requisitos de Desempeño: Indica, entre otros, los requisitos de memoria, tiempo de respuesta, tamaño de los archivos y respuesta del sistema. 3.5. Restricciones al Diseño: Especifica las restricciones que las condiciones externas impondrán al sistema. Incluye equipo en donde se implementará, plataforma, espacio, compatibilidad y otras restricciones de software, hardware e interacción. 3.6. Criterios de Aceptación: Indica las condiciones que se tendrán que dar para que el cliente acepte el producto y cómo el desarrollador demostrará que éstas condiciones se cumplen. Notas J. Navarro/2004

Software Engineering • Planificación de un Proyecto de Software • Estimado de Costos • Programación del Tiempo • Planificación del Personal • Estructuración del Equipo (personal) • Verificación y Control de Calidad • Gerencia de Configuración • Monitoreo del Proyecto • Manejo de Riesgos Especificaciones de los Requisitos del software Planificación del Proyecto Plan para el Proyecto Notas J. Navarro/2004

4x x x/4 Software Engineering • Estimados de Costos • Los estimados se necesitan antes de que comience el desarrollo • Se utiliza para competir en las subastas • Se utiliza para el control del proyecto • La exactitud del estimado aumenta con las fases del proyecto Viabilidad Análisis Diseño Codificación Pruebas Acepatación Notas J. Navarro/2004

Software Engineering • Modelo de Costo de una Sola Variable • Sólo se basa en el tamaño del proyecto • Las constantes a y b se basan en un análisis de regresión aplicado a la • data histórica • Ejemplo: en 1977 IBM estudió 60 proyectos basándose en las líneas • de código entregadas y determinó • a = 5.2 • b = 0.91 Notas J. Navarro/2004

a b 3.2 1.05 organic =>proyecto sencillo 3.0 1.12 semidetached => complejidad mediana 2.8 1.20 embedded =>ambicioso y difícil Software Engineering • Modelo de costo variable multi-variables • COnstructive COst MOdel (COCOMO) • Técnica de estimación desarrollada por Boehm en 1981 • Provee estimados del esfuerzo total del staff técnico basado en un • proceso de tres pasos • Determinar 15 factores de multiplicación basados en los atributos del proyecto • Ajustar el esfuerzo multiplicando el estimado inicial por el producto de los factores de multiplicación • Obtener un estimado inicial de un modelo de una sola variable basado en el tipo de proyecto y las líneas de código • El estimado inicial se determina con la fórmula • Ei = a*(KDL)b • a & b dependen del tipo de proyecto y KDL = miles de líneas entregadas. • Los valores de a & b se determinan de la siguiente tabla: Notas J. Navarro/2004

Software Engineering COCOMO (Atributos) • Product Attributes • Required software reliability (RELY) • Data base size (DATA) • Product complexity (CPLX) • Computer Attributes • Execution time constraint (TIME) • Main storage constraint (STOR) • Virtual machine volatility (VIRT) • Computer turnaround time (TURN) Notas J. Navarro/2004

Software Engineering