Ingeniería del Software

Introducción

Software e Ingeniería del Software

El Software

Se puede definir el software como:

1. conjunto de instrucciones que cuando se ejecutan proporcionan la función y el comportamiento deseado,
2. estructuras de datos que facilitan a los programas manipular adecuadamente la información, y
3. documentos que describen la operación y el uso de los programas.

El software es lógico, en lugar de físico. Por tanto, el software tiene
unas características distintas a las del hardware:

1. El software se desarrolla, no se fabrica.
   Tanto al desarrollar software como al construir hardware la buena calidad se obtiene mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que prácticamente no existen en el software. Los costes de software se encuentran en la ingeniería.

2. El software no se estropea.
   En las siguientes figuras se muestran las curvas de fallos de hardware y software. El hardware exhibe muchos fallos al principio de su vida (por defectos de diseño o de fabricación); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel estacionario donde permanece un período de tiempo. Sin embargo, los fallos vuelven a presentarse a medida que los componentes del hardware se van estropeando.

Curva de fallos del hardware

Curva de fallos del software (idealizada)

Curva de fallos del software (real)

Actividades de la Ingeniería del Software

La ingeniería de software incluye:

• Personas
  Quién lo hace.
• Proceso
  La manera en que se hace.
• Proyecto
  La realización.
• Producto
  La aplicación de artefactos.

Proceso

Las actividades para crear un proyecto de ingeniería del software son:

1. Entender la naturaleza del proyecto.
2. Los proyectos requieren documentación desde el principio. Debe indentificarse un medio para mantener el control de los cambios tanto en los documentos como en el código (gestión de la configuración).
3. Desarrollo del plan global para el proyecto.
4. Reunir los requisitos para la aplicación.
5. Diseño e implementación del producto.
6. Pruebas exhaustivas del producto inicial y el final.
7. Mantenimiento del producto entregado.

Proceso Unificado de Desarrollo de Software (USDP)

El USDP (Unified Software Development Process) es un proceso
iterativo con una clasificación en cuatro grupos:

• Iteraciones de concepción. Iteración preliminar con los interesados.
• Iteraciones de elaboración. Finalización de qué se desea y necesita. Establecer la base de la arquitectura.
• Iteraciones de construcción. Dan como resultado la capacidad operativa.
• Iteraciones de transición. Terminar la liberación del producto.

Al clasificar las iteraciones de esta forma, el USDP se puede describir en términos de una matriz:

	Concepción	Elaboración	Construcción	Transición
Requisitos	$\times\times\times\times$	$\times\times\times\times$	$\times$
Análisis	$\times\times\times$	$\times\times\times$	$\times$
Diseño	$\times$	$\times\times$	$\times\times\times\times$	$\times$
Implementación	$\times$	$\times\times$	$\times\times\times\times$	$\times\times\times$
Prueba		$\times$	$\times\times$	$\times\times\times$

La mayoría de las iteraciones involucran casi todas las etapas de la cascada, pero en diferentes grados. Las iteraciones de concepción incluyen casi en totalidad análisis de requisitos, parte del análisis y pueden involucrar suficiente diseño e implementación para producir un prototipo preliminar. Las iteraciones de elaboración comprenden principalmente análisis de requisitos, pero incluyen algo de diseño e implementación. Las iteraciones de construcción abarcan sobre todo diseño e implementación y las de transición incluyen implementación y pruebas.

El proceso unificado produce los seis modelos siguientes:

• Modelo de casos de uso. Describe las maneras en que debe usarse la aplicación.
• Modelo de análisis. Describe las clases básicas de la aplicación.
• Modelo de diseño. Detalla la relación de las clases con los objetos seleccionados.
• Modelo de despliegue. Puntualiza cómo debe organizarse el código.
• Modelo de implementación.
• Modelo de pruebas. Consiste en las componentes, procedimientos y casos para las pruebas.

Calidad

Una función de calidad consiste en un código que:

• Satisface los requisitos establecidos con claridad.
• Verifica sus entradas; reacciona de manera predecible a entradas ilegales.
• Se ha inspeccionado de manera íntegra por ingenieros que no son el autor.
• Se ha probado de modo exhaustivo en varias formas independientes.
• Está bien documentado.
• Tiene una tasa de defectos confiable conocida, si los tiene.

Un diseño de alta calidad:

• Se extiende (es fácil mejorarlo par proporcionar funcionalidad adicional).
• Evoluciona (se puede adaptar con facilidad a requisitos diferentes).
• Se mueve (se aplica a varios entornos).
• Es general (se aplica a varias situaciones diferentes).

Inspección

Una inspección es una técnica de caja blanca para asegurar la calidad. Consiste en examinar las partes del proyecto (requisitos, diseños, código, etc.) para encontrar defectos. Las inspecciones se realizan por colegas del autor, que le señalan los defectos del trabajo antes de que haga entrega del proyecto.

La inspección sigue cuatro reglas:

• Sólo detección de defectos. Las inspecciones excluyen la reparación de defectos. El proceso de reparación se deja al autor.

• Proceso de colegas.

• Roles especificados. Cada participante desempeña uno de los siguientes papeles:

  • Moderador. Responsable de que se lleve a cabo la inspección apropiadamente.
  • Autor. Responsable del trabajo y de la reparación de defectos (fuera del proceso de inspección).
  • Lector. Responsable de conducir al equipo en forma adecuada.
  • Secretario. Responsable de escribir las descripciones de los defectos y clasificarlos.

  Además, todos actúan como inspectores.

• Preparación completa. Los inspectores deben trabajar al mismo nivel de detalle que el autor.

Las inspecciones deben aplicarse lo más pronto posible en el proceso de desarrollo, inspeccionándose requisitos, planes de administración y configuración del proyecto.

Una inspección tiene los siguientes pasos:

1. Planificación. Incluye decidir las métricas de inspección que se recolectarán e identificar las herramientas que se usarán para registrar y analizar estos datos.
2. Según avanza el proyecto, las personas responsables deben determinar qué personas inspeccionan qué fragmentos de código.
3. Si es necesario, debe organizarse una reunión de visión general.
4. Preparación. Los inspectores revisan el trabajo con todo detalle.
5. Reunión de inspección. Los participantes toman sus roles asignados.
6. Etapa de retrabajo. El autor repara todos los defectos.
7. Reunión de seguimiento final.

Administración de la documentación

La administración de la documentación requiere que un documento esté completo, sea consistente y tenga configuración.

Evaluación de capacidades

El Software Engineering Institute (SEI) ha desarrollado:

Personal Software Process (PSP). Tiene como propósito desarrollar hábitos de programación. Se divide en las siguientes etapas:

0. Proceso base.
1. Proceso de planificación personal.
2. Proceso de administración de la calidad personal.
3. Proceso personal cíclico.

Team Software Process (TSP). Tiene los siguientes objetivos:

• Formar equipos autodirigidos.
• Enseñar a los jefes a administrar equipos.
• Acelerar la mejora del CMM.
• Proporcionar guías de mejora.
• Facilitar la enseñanza a equipos.

Capability Maturity Model (CMM). Clasifica a las organizaciones en los siguientes cinco niveles:

1. Nivel 1: Inicial. Expresa el estado más primitivo para las organizaciones de software. Sólo reconoce que la organización es capaz de producir productos de software. No tiene un proceso reconocido para la producción de software y la calidad de los productos y proyectos depende por completo de los individuos que realizan el diseño y la implementación. Cuando termina un proyecto no se registran costo, tiempos ni calidad.
2. Nivel 2: Repetible. Se aplica a las organizaciones capaces de rastrear sus proyectos hasta cierto grado. Mantienen registros de los costos y tiempos del proyecto. También describen la funcionalidad de cada producto por escrito. Es posible predecir el costo y los tiempos de proyectos muy similares que realiza el mismo equipo.
3. Nivel 3: Definido. Se aplica a las organizaciones que reducen la dependencia excesiva en individuos específicos mediante la documentación del proceso e imponen un estándar. Algunas organizaciones adoptan estándares existentes (como los de IEEE), y otras definen unos propios. Aunque las organizaciones de nivel 3 son capaces de producir aplicaciones con calidad consistentes, todavía les falta la capacidad de predecir. Pueden hacer pronósticos sólo para proyectos muy similares a los realizados en el pasado.
4. Nivel 4: Administrado. Se aplica a las organizaciones que pueden predecir el costo y la programación de tareas.
5. Nivel 5: Optimizado. Se aplica a las organizaciones que incluyen una manera sistemática de evaluar el proceso mismo de la organización.

En la tabla se relacionan PSP, TSP y CMM.

Nivel CMM	Enfoque	Área de proceso clave	PSP	TSP
2	Gestión	Administración de requisitos		✓
2	Gestión	Planificación del proyecto de software	✓	✓
2	Gestión	Rastreo del proyecto de software	✓	✓
2	Gestión	Aseguramiento de la calidad del software		✓
2	Gestión	Administración de subcontratistas de software		✓
3	Definición	Enfoque en el proceso organizacional	✓	✓
3	Definición	Definición del proceso organizacional	✓	✓
3	Definición	Programas de capacitación		✓
3	Definición	Administración de software integrada	✓	✓
3	Definición	Ingeniería del producto de software	✓	✓
3	Definición	Coordinación entre grupos		✓
3	Definición	Revisiones de colegas	✓	✓
4	Medición	Administración cuantitativa de procesos	✓	✓
4	Medición	Administración de la calidad del software	✓	✓
5	Optimización	Prevención de defectos	✓	✓
5	Optimización	Administración del cambio tecnológico	✓	✓
5	Optimización	Administración del cambio de proceso	✓	✓

Administración de proyectos

La administración de proyectos consiste en gestionar la producción de un producto dentro del tiempo dado y los límites de fondos. La administración de proyectos comprende:

• Estructura. Elementos organizacionales involucrados.
• Proceso administrativo. Responsabilidades y supervisión de los participantes.
• Proceso de desarrollo. Métodos, herramientas, lenguajes, documentación y apoyo.
• Programa. Tiempos en los que deben realizarse las porciones del trabajo.

El administrador del proyecto puede controlar las siguientes variables:

• Coste total del proyecto.
• Capacidades del producto.
• Calidad del producto.
• Duración del proyecto.

El grado en el que estos cuatro factores pueden controlarse depende del proyecto.

Una secuencia común para la preparación de un proyecto es la siguiente:

1. Comprender el contenido, alcance y marco de tiempo del proyecto.
2. Identificar el proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo).
3. Determinar la estructura organizacional (elementos de la organización involucrados).
4. Identificar el proceso administrativo (responsabilidades de los participantes).
5. Desarrollar una programación (tiempos en que deben realizarse las porciones de trabajo).
6. Desarrollar el plan de personal.
7. Iniciar la administración del riesgo.

Gestión de riesgos

La gestión de riesgos consta de las siguientes actividades:

1. Identificar.
2. Planificar la eliminación.
3. Dar prioridades.
4. Eliminar o atenuar.

Identificación de riesgos

Los factores de riesgo más comunes en los proyectos son los siguientes:

1. Falta de compromiso de la alta administración.
2. Falta de compromiso por parte del usuario.
3. Error al entender los requisitos.
4. Participación inadecuada del usuario.
5. Incumplimiento de las expectativas del usuario final.
6. Cambio de alcance y/o objetivos.
7. Falta de conocimientos o aptitudes requeridas del personal.

Eliminación de riesgos

Existen dos formas de eliminar un riesgo. Una es hacer cambios en los requisitos del proyecto para evitar el aspecto que causa el riesgo. Otra manera es desarrollar técnicas y diseños que resuelvan el problema.

Estimación de costos

Las estimaciones de costo y duración de un proyecto se realizan de la siguiente forma:

1. Usar comparaciones con trabajos anteriores para estimar el costo y la duración en forma directa o para estimar líneas de código.
2. Usar el método de puntos de función para estimar líneas de código:
3. Calcular puntos de función sin ajuste.
4. Aplicar el proceso de ajuste.
5. Usar líneas de código estimadas para calcular la mano de obra y la duración mediante las fórmulas de COCOMO.

Estimación de líneas de código sin el proceso de puntos de función

Para estimar las líneas de código en la etapa inicial (mucho antes de la etapa de diseño) se utilizan varios métodos de estimación, como el modelo COCOMO (Constructive Cost Model) de Boehm.

Puntos de función y líneas de código

Albrecht elaboró en 1979 el concepto de puntos de función para evaluar el tamaño de un proyecto sin tener que conocer su diseño.

La técnica de los puntos de función es un medio para calibrar las capacidades de una aplicación de manera uniforme, como un solo número. Este número se puede usar para estimar las líneas de código, los costos y la duración.

El cálculo de los puntos de función sigue los siguientes pasos:

1. Identificar las funciones que debe tener la aplicación. En general, una función es el equivalente a procesar una pantalla o formulario.

2. Para cada función se calcula su contribución de puntos de función según el siguiente baremo:

   • Entradas externas. Sólo se cuentan separadas las entradas que afectan la función en forma diferente a las otras.
   • Salidas externas. Deben contarse sólo salidas responsables de algoritmos verdaderos o funcionalidades no triviales.
   • Búsquedas internas. Cada búsqueda independiente cuenta como $1$.
   • Archivos lógicos internos. Cuenta cada grupo lógico único de datos del usuario creados por o mantenidos por la aplicación.
   • Archivos lógicos externos. Cuenta cada grupo único de datos en archivos externos a la aplicación.

3. Cada uno de estos valores de los parámetros se factoriza por un número, según el grado de complejidad del parámetro en la aplicación. Estos números se muestran en la siguiente tabla.

4. Se calculan ponderaciones para las 14 características generales del proyecto, cada una entre 0 y 5. Estas características son las siguientes:

   1. ¿Requiere respaldo/recuperación?
   2. ¿Requiere comunicación de datos?
   3. ¿Tiene distribución de funciones de procesamiento?
   4. ¿El rendimiento es crítico?
   5. ¿Corre en entorno existente con uso pesado?
   6. ¿Requiere entrada de datos en línea?
   7. ¿Tiene ventanas de entrada múltiples?
   8. ¿Campos maestros actualizados en línea?
   9. ¿Son complejas entradas, salidas, búsquedas de archivos?
   10. ¿El procesamiento interno es complejo?
   11. ¿Se diseñó el código para reuso?
   12. ¿Incluye conversión e instalación?
   13. ¿Se hacen instalaciones múltiples en diferentes organizaciones?
   14. ¿Debe simplificarse el cambio y facilidad de uso para el usuario?

5. Por último, los puntos de función ajustados totales se calculan con la siguiente fórmula:

Parámetro		simple	medio	complejo
Entradas externas (EE)	$\times$	$3$	$4$	$6$	$=$	$\square$
Salidas externas (SE)	$\times$	$4$	$5$	$7$	$=$	$\square$
Búsquedas externas (BE)	$\times$	$3$	$4$	$6$	$=$	$\square$
Archivos lógicos internos (ALI)	$\times$	$7$	$10$	$15$	$=$	$\square$
Archivos lógicos externos (ALE)	$\times$	$5$	$7$	$10$	$=$	$\square$
				Total	$=$	$\square$

Cálculo de puntos de función, antes del ajuste.

Una vez obtenidos los puntos de función, se pueden utilizar para convertir en líneas de código y en personas-mes mediante tablas estándar. Por ejemplo, se suelen estimar 53 líneas de código fuente de Java por cada punto función.

Estimación del esfuerzo y la duración a partir de las líneas de código

Boehm estimó el esfuerzo y la duración a partir de las líneas de código según las siguientes fórmulas de COCOMO:

$$
\boxed{\mbox{Esfuerzo} = a \times {\mbox{KLOC}}^b}
$$
$$
\boxed{\mbox{Duración} = c\times {\mbox{Esfuerzo}}^d}
$$

donde el esfuerzo se mide en personas-mes, KLOC es el número de líneas de código (en millares) y los parámetros $a, b, c, d$ se obtienen de la tabla siguiente. En esta tabla, las aplicaciones orgánicas son aplicaciones independientes; las aplicaciones empotradas están integradas a sistemas de software-hardware; y las aplicaciones semiempotradas son intermedias.

La fórmula de la duración de un proyecto se puede expresar directamente en términos de miles de lineas de código de la forma:

$$
\boxed{\mbox{Duración} = c\times a^d \times {\mbox{KLOC}}^{bd}}
$$

Proyecto de software	a	b	c	d
Orgánico	$2.4$	$1.05$	$2.5$	$0.38$
Semiempotrado	$3.0$	$1.12$	$2.5$	$0.35$
Empotrado	$3.6$	$1.20$	$2.5$	$0.32$

Análisis de requisitos

Introducción al análisis de requisitos

Los requisitos expresan qué debe hacer una aplicación, no cómo lograrlo. Un requisito en un nivel con frecuencia se traduce en más de un requisito específico en el siguiente nivel más detallado.

La salida del análisis de requisitos es un documento que se conoce como especificación de requisitos o especificación de requisitos de software (ERS).

El análisis de requisitos se divide en dos niveles. El primer nivel documenta los deseos y necesidades del cliente y se expresa en lenguaje claro para él. Los resultados se denominan requisitos del cliente o requisitos C. La audiencia primaria para los requisitos C es la comunidad del cliente y la secundaria es la comunidad del desarrollador. El segundo nivel documenta los requisitos de manera específica y estructurada. Éstos se denominan requisitos del desarrollador o requisitos D. La audiencia primordial de estos es la comunidad del desarrollador y la secundaria la del cliente.

Cada requisito debe:

• Expresarse de modo adecuado.
• Ser de acceso sencillo.
• Numerarse.
• Acompañarse con pruebas que lo verifiquen.
• Tomarse en cuenta en el diseño.
• Tomarse en cuenta en el código.
• Probarse de forma aislada.
• Probarse junto con otros requisitos.
• Validarse con las pruebas después de construir una aplicación.

El proceso típico de análisis de requisitos es el siguiente:

1. Identificar al cliente.
2. Entrevistar representantes del cliente.
   • Identificar deseos y necesidades.
   • Aprovechar herramientas de expresión.
   • Bosquejar las GUI.
   • Identificar el hardware.
3. Escribir los requisitos C en forma de documento estándar.
4. Inspeccionar los requisitos C.
5. Construir los requisitos D.

La especificación de requisitos de software se organiza según el estándar IEEE 830-1993 de la siguiente forma:

1. Introducción
   1. Propósito
   2. Alcance
   3. Definiciones, acrónimos y abreviaturas
   4. Referencias
   5. Panoramas
2. Descripción general
   1. Perspectiva del producto
      1. Interfaces del sistema
      2. Interfaces de usuario
      3. Interfaces de hardware
      4. Interfaces de software
      5. Interfaces de comunicación
      6. Restricciones de memoria
      7. Operaciones
      8. Requisitos de adaptación del sitio
   2. Funciones de producto
   3. Características del usuario
   4. Restricciones
   5. Suposiciones y dependencias
   6. Distribución de requisitos
3. Requisitos específicos
   1. Requisitos de interfaz externa
      1. Interfaces de usuario
      2. Interfaces de hardware
      3. Interfaces de software
      4. Interfaces de comunicación
   2. Clases/objetos
   3. Requisitos de rendimiento
   4. Restricciones de diseño
   5. Atributos del sistema de software
   6. Otros requisitos
4. Información de apoyo

Descripción de los requisitos de cliente (C)

Casos de uso

El caso de uso es una forma de expresar una secuencia de interacción entre usuario y aplicación para una utilización típica. Un caso de uso se identifica por su nombre y por el tipo de usuario de la aplicación, llamado actor. Los casos de uso son un medio de comunicación muy útil con los clientes.

Con la notación de UML (Unified Modeling Language), una elipse denota un caso de uso. El USDP (Proceso Unificado de Desarrollo de Software) recomienda usar casos de uso detallados para especificar una fracción grande de requisitos.

Los casos de uso relacionados entre sí deben ser secuenciales u ortogonales. Los casos de uso ortogonales toman puntos de vista u opciones opuestas. Los casos de uso son secuenciales si uno sigue directamente al otro.

Diagramas de flujo de datos

Algunos requisitos se describen de forma natural como el flujo de datos entre los elementos de procesamiento.

Diagramas de transición de estados

El estado de una aplicación es su situación o condiciones. La idea es dividir la aplicación en estados de forma que siempre esté justo en uno de ellos.

Diseño preliminar de interfaces de usuario

Los clientes comprenden una aplicación al visualizar su interfaz gráfica de usuario (GUI), por lo que una manera de ayudar a describir la aplicación es desarrollar el diseño preliminar de la GUI.

Los pasos para producir interfaces de usuario son los siguientes:

1. Conocer al usuario (C¹).
2. Entender la función de negocios en cuestión (C).
3. Aplicar los principios del buen diseño de pantallas (C, D).
4. Seleccionar el tipo adecuado de ventanas (C, D).
5. Desarrollar los menús del sistema (C, D).
6. Seleccionar los controles adecuados basados en los dispositivos (C).
7. Elegir los controles adecuados basados en las pantallas (C).
8. Organizar y distribuir la pantalla (C, D).
9. Elegir los colores adecuados (D).
10. Crear iconos significativos (C, D).
11. Proporcionar mensajes, retroalimentación y guía afectivos (D).

Descripción de los requisitos específicos (D)

Los requisitos D son una lista completa de las propiedades específicas y la funcionalidad que debe tener la aplicación, expresada con todo detalle. Con consistentes con lo requisitos C, siendo un refinamiento de estos.

El proceso típico para reunir y documentar los requisitos D es el siguiente:

1. Seleccionar la organización de requisitos D.
2. Crear diagramas de secuencia a partir de casos de uso.
3. Se realizan en paralelo:
   1. Obtener los requisitos D a partir de requisitos C y del cliente.
   2. Describir planes de prueba.
   3. Inspeccionar.
4. Validar con el cliente.
5. Liberar.

Tipos de requisitos D

1. Requisitos funcionales.
   • Funcionalidad de la aplicación.
2. Requisitos no funcionales.
   1. Rendimiento
      • Velocidad.
      • Capacidad (tasas de circulación).
      • Uso de memoria.
        • En RAM.
        • En disco.
   2. Confiabilidad y disponibilidad.
   3. Manejo de errores.
   4. Requisitos de interfaz.
      • Cómo interactúa la aplicación con el usuario y con otras aplicaciones.
3. Restricciones.
   • Exactitud.
   • Restricciones de herramientas y lenguaje.
   • Restricciones de diseño.
   • Estándares que deben usarse.
   • Plataforma de hardware que se utilizará.
4. Requisitos inversos.
   • Qué no debe hacer la aplicación.