Software Engineering

Software Engineering

Notas J. Navarro/2004

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



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

0%

20%

40%

60%

80%

100%

120%

1955 1970 1985

SoftwareMaintenance

HardwareMaintenance

SoftwareDevelopment



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



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.



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



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

Cantidad de líneas

Tamañoel proyecto

2000 Pequeño

8000 Intermedio

32000 Mediano

128000 Grande

Tabla 2.1 Tamaño del proyecto según el número de líneas de código que requiere



Parámetros que afectan la ingeniería de software Costos

costo del equipoaplicacionesmano de obra (más costoso)

programación de tiempo (scheduling)ventanas de tiempodesarrollo rápido de aplicaciones (RAD

CalidadOperación del Producto

correcciónconfiabilidadeficienciausabilidad

Transición del Productoportabilidadinteroperabilidad

Revisión del productofacilidad para mantenimientofacilidad para realizar pruebas

Consistenciapredicciones desarrollo de un softwareestabilidad y aceptación de la compañía

La confiabilidad es el factor más importanteSe mide en defectos por líneas de código



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 sistemadiseño detallado



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



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.



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



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 softwareProceso de desarrollo Proceso de gerencia del proyecto



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

PredecibilidadFacilitar 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%



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%



Implicaciones

Es necesario detectar y corregir los errores tempranoEs necesario prevenir la ocurrencia de erroes



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



ModelosCon 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

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



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 derequisitos

Diseño

Codificación

Pruebas

Análisis derequisitos

Diseño

Codificación

Pruebas

DiseñoDiseño CodificaciónCodificación PruebasPruebas



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



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.


Diseño

Codificación

Pruebas


Diseño

Codificación

Pruebas

DiseñoDiseño CodificaciónCodificación PruebasPruebas



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.





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.



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.



Especificaciones de los Requisitos del Sistema

Actividades Básicas

• Análisis del Dominio del Problema• Especificaciones de los Requisitos



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



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



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



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)



Ejemplo de un Diagrama de Objetos para el Ejemplo de la Nómina



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



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



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

0

5

10

15

20

25

mes 1 mes 2 mes 3 mes 4

funcones obviadas

ambiguedades

requisitos inverificables

requisitos incorrectos

Errores en el SRS para El Tigre Corp.



Frecuencia de las Requisiciones para Cambios

0

50

100

mes 1 mes 2 mes 3 mes 4 mes 5 mes 6 mes 7 8 9

Número de cambios

Requisiciones de Cambios para El Tigre Corp.

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



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%

1 2 4 8 16 32 64 128

4080160320640

1280

Tam

año

de la

Apl

icació

n en

Pun

tos

de F

unció

n

Duración del Proyecto en Meses

Tiempo de Entrega Promedio de El Tigre Corp.

25605120



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



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á.



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.



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.



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

Especificacionesde los Requisitosdel software

Planificación delProyecto

Plan parael Proyecto



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

x

4x

x/4

Viabilidad Análisis Diseño Codificación Pruebas Acepatación



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.2b = 0.91

bTamaño*acosto



Modelo de costo variable multi-variablesCOnstructive 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

1. Determinar 15 factores de multiplicación basados en los atributos del proyecto

2. Ajustar el esfuerzo multiplicando el estimado inicial por el producto de los factores de multiplicación

3. 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:

a b 3.2 1.05 organic =>proyecto sencillo3.0 1.12 semidetached => complejidad mediana2.8 1.20 embedded =>ambicioso y difícil



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)

Documents

Software Engineering