Calidad de Software

139  Descargar (0)

Texto completo

(1)

Calidad de

Software

(2)
(3)

Í

NDICE

Página

Presentación 7

Red de contenidos 8

Unidad de aprendizaje 1

1.1 Tema 1 : Calidad de Software 10

1.1.1. : Definición de Calidad 10

1.1.2. : Política de Calidad 11

1.1.3. : Terminología según ISO 8402 11

1.1.4. : Definición de Calidad de Software 13

1.2 Tema 2 : Aseguramiento y Control de Calidad 20

1.2.1. : SQA (Software Quality Assurance) no es lo mismo que SQC (Software Quality Control)

21

1.2.2. : Funciones Generales del SQA 22

1.3 Tema 3 : Modelo de Procesos 25

1.3.1. : El Proceso de Desarrollo de Software 27

1.3.2. : Normas Relacionados con el Proceso de Desarrollo de Software

30

1.3.3. : Los Procesos ISO 12207:2008 34

1.4 Tema 4 : Modelo de Ciclo de Vida de Software 35

1.4.1. : Codificar y Corregir (Code-and-Fix) 35

1.4.2. : Modelo en Cascada 35

1.4.3. : Desarrollo Evolutivo 37

1.4.4. : Desarrollo Formal de Sistemas 38

1.4.5. : Desarrollo Basado en Reutilización 39

1.4.6. : Procesos Iterativos 40

1.4.7. : ¿Cuál es el modelo de procesos más adecuado? 42

(4)

1.5 Tema 5 : Verificación y Validación 44

1.5.1. : Verificación 44

1.5.2. : Validación 44

1.5.3. : Ventajas de las Revisiones de Software 45

1.5.4. : Desventajas de las Revisiones de Software 45

1.5.5. : Revisiones Informales y Formales 45

Unidad de aprendizaje 2

2.1 Tema 6 : Modelos de Calidad de Software 85

2.1.1. : Introducción 86

2.1.2. : Perspectivas de Calidad 86

2.1.3. : Calidad desde el Punto de Vista del Proceso 87

2.1.4. : Calidad desde el Punto de Vista del Producto 88

2.1.5. : Calidad desde el Punto de Vista de las Personas 89

2.2 Tema 7 : Métricas de Calidad de Producto Software 90

2.2.1. : ISO/IEC 9126-1 – Modelo de Calidad 91

2.2.2. : ISO/IEC 9126-2 – Métricas Externas 93

2.2.3. : ISO/IEC 9126-3 – Métricas Internas 93

2.2.4. : Relación entre las Métricas Internas y Externas 94

2.2.5. : ISO/IEC 9126-4 – Métricas para Calidad en Uso 95

2.2.6. : ISO/IEC 25000:2005 – SquaRE 96

2.3 Tema 8 : Evaluación de Métricas 98

2.3.1. : Definiciones 98

2.3.2. : Proceso de Evaluación 98

Unidad de aprendizaje 3

3.1 Tema 9 : Pruebas de Software 105

3.1.1. : Principios Generales de las Pruebas 106

3.2 Tema 10 : Ciclo de Vida de las Pruebas 108

3.2.1 Planeación y Control de Pruebas 108

(5)

3.2.3 Implementación y Ejecución de Pruebas 109

3.2.4 Evaluación de Criterios de Salida y Reportes 109

3.2.5 Cierre de Pruebas 109

3.3 Tema 11 : Estrategia de Pruebas 111

3.3.1 Casos de Prueba 111

3.3.2 Diseño de Casos de Prueba 113

3.3.3 Realizar Casos de Prueba 116

3.3.4 Informe y Seguimiento de Pruebas 118

(6)
(7)

P

RESENTACIÓN

Calidad de Software pertenece a la línea formativa y se dicta en la carrera de Computación e Informática y de Administración y Sistemas. Brinda los conceptos fundamentales de calidad que deben ser considerados en los proyectos de desarrollo de sistemas de software.

El manual para el curso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema tratado, el cual será ampliamente desarrollado; y los contenidos, que debe desarrollar, es decir, los subtemas. Por último, encontrará las actividades que deberá desarrollar en cada sesión, que le permitirán reforzar lo aprendido en la clase.

El curso tiene un formato teórico práctico. Los conceptos desarrollados son aplicados en el proyecto Integrado de Quinto Ciclo, desarrollado en el curso de Desarrollo de Aplicaciones Web 1, y se complementa con los temas del curso de Gestión de Proyectos de TI. Los conceptos y las técnicas de control de calidad se implementan también en el curso de Análisis y Diseño de Sistemas III de la carrera de Administración y Sistemas, con verificaciones de entregables previamente establecidos.

(8)

R

ED DE CONTENIDOS

UNIDAD DE APRENDIZAJE

1

Calidad de Software Aseguramie nto de la Calidad de Software Métricas de Software Pruebas de Software Calidad de Software Aseguramiento y Control de Calidad Modelo de Procesos Modelos de Ciclo de Vida de Software Modelos de Calidad de Software Métricas de Calidad de Productos de Sofware Evaluación de Métricas Pruebas de Software

Ciclo de Vida de las Pruebas

Estrategia de Pruebas

Verificación y Validación

(9)

C

ALIDAD DE

S

OFTWARE

LOGRO DE LA UNIDAD DE APRENDIZAJE

• Al término de la unidad de aprendizaje, el alumno diseña la lista de verificación del Reporte de Especificación de Software y el Plan de Desarrollo considerando los requerimientos previamente definidos por el Líder Usuario para el proyecto integrado de quinto ciclo.

TEMARIO

1.1. Tema 1: Calidad de Software 1.1.1. Definición de Calidad 1.1.2. Política de Calidad

1.1.3. Terminología según ISO 8402

1.1.4. Definición de Calidad de Software 1.1.4.1. Control de Calidad

1.1.4.2. Aseguramiento de Calidad 1.2. Tema 2: Aseguramiento y Control de Calidad

1.2.1. SQA (Software Quality Assurance) no es lo mismo que SQC (Software Quality Control)

1.2.2. Funciones Generales del SQA

1.3. Tema 3: Modelo de Procesos

1.3.1. El Proceso de Desarrollo de Software

1.3.2. Normas Relacionadas con el Proceso de Desarrollo de Software

1.3.2.1. Conceptos Clave

1.3.2.2. Ciclos de Vida, Procesos, Productos

1.3.3. Los Procesos ISO 12207:2008

1.4. Tema 4: Modelo de Ciclo de Vida de Software 1.4.1. Codificar y Corregir (Code-and-Fix)

1.4.2. Modelo en Cascada

1.4.3. Desarrollo Evolutivo

1.4.4. Desarrollo Formal de Sistemas

1.4.5. Desarrollo Basado en Reutilización 1.4.6. Procesos Iterativos

1.4.6.1. Desarrollo Incremental 1.4.6.2. Desarrollo en Espiral

1.4.7. ¿Cuál es el modelo de procesos más adecuado?

1.5. Tema 5: Verificación y Validación de Software 1.5.1. Verificación

1.5.2. Validación

1.5.3. Ventajas de las Revisiones de Software

1.5.4. Desventajas de las Revisiones de Software

(10)

1.1. CALIDAD DE SOFTWARE

Los conceptos relacionados con la calidad de software tienen relación directa con la aplicación de la calidad a un producto desarrollado a través de procesos de ingeniería de software. En tal sentido empezaremos dando algunas definiciones de calidad y luego ampliaremos el concepto hacia calidad de software.

(11)

Existen muchas definiciones de calidad y muchos términos que se utilizan en la gestión de la misma.

Para la ISO 8402 (International Standard Organization), complemento de normas de las series de normas ISO 9000, define La Calidad como: "El conjunto de características de una entidad que le confieren la aptitud para satisfacer las necesidades establecidas e implícitas”.

También podría decirse que es la “conformidad con los requisitos” y el “grado de excelencia”. En un servicio la calidad se define como la diferencia entre la percepción del servicio y la expectativa que el cliente tenía del mismo. Calidad también es la satisfacción del cliente.

La calidad la definen los clientes, por lo que la oferta deberá estar de acuerdo los lo que ellos definen (sus exigencias) y entonces deberá producirse exactamente lo que dichos clientes desean, en el plazo convenido y al mínimo costo e incluso anticiparse a sus necesidades satisfaciendo sus expectativas, lo que dará una ventaja competitiva frente a la competencia.

La calidad no solo hace referencia a que un producto o servicio se ajuste a las exigencias. La percepción que los clientes tienen sobre su empresa está basada en el producto o servicio que les suministra, pero también en el contacto diario que mantienen con los directivos. El concepto de calidad abarca no sólo como se atienden las exigencias de sus clientes sino también la forma en que se hace, cómo se atiende el teléfono, la rapidez con que se satisfacen consultas, tener nuevos servicios cuando se los requiere, asegurarse que la factura que sale de la empresa es la correcta. Cada contacto, llamados momentos de la verdad con el cliente, muestra un reflejo de la compañía a los ojos de ese cliente.

El recepcionista que atiende las llamadas, los agentes de seguridad que controlan los accesos, los ascensoristas que transportan a la gente y la orientan, los administrativos que envían las facturas, los dictámenes de los abogados, todos deben involucrarse en el concepto de calidad, en satisfacer las exigencias del cliente, en crear una compañía con clase reconocida. La calidad es un concepto objetivo que cada empleado puede comprender y evaluar, y sobre el cual puede asumir responsabilidades. La única forma de alcanzar el objetivo de calidad es:

1. Comprender las exigencias de los clientes externos.

2. Conocer a fondo los procesos internos que le permitan satisfacer esas exigencias.

3. Desarrollar un sistema y cultura empresarial que le aseguren que los errores son evitados o eliminados

1.1.2. Política de Calidad

ISO 8402 la define como: "Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la Dirección General". Es una de las vías para hacer operativa la estrategia. Al desplegar verticalmente la política a través de los niveles jerárquicos de la organización:

(12)

• Se proporciona orientación precisa para que ejecutivos y mandos elaboren planes concretos de acción.

• Se cohesiona la organización para el cumplimiento de los objetivos de calidad.

• Se refuerza el compromiso del personal.

La política de calidad debe ser:

• Adecuada a la empresa.

• Coherente con las necesidades y expectativas de sus clientes.

• Muy simple y fácilmente comprensible para que sea comunicable y entendida sin dificultad.

En cuanto a su contenido, debería hacer referencia a:

• Los grandes objetivos de la empresa.

• Los colectivos que en ella conviven: personal, accionistas, clientes, proveedores.

• La disponibilidad de los recursos necesarios; por ejemplo, formación.

• La vía a utilizar (ISO, Mejora Continua, etc.).

Es la totalidad de aspectos y características de un producto o servicio que se refieren a su capacidad para satisfacer necesidades dadas en la adecuación de sus objetivos'”.

El Instituto de Ingeniería de Software (SEI) en su modelo CMM define la calidad como:

• El grado en el cual un sistema, componente o proceso cumple con los requisitos especificados.

• El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario.

1.1.3. Terminología según ISO 8402

1. Calidad: “Conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explicitas o implícitas”.

2. Control de Calidad: “Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio”.

3. Garantía de Calidad: “Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio cumplirá los requerimientos dados sobre calidad”.

4. Gestión de Calidad: “Aspecto de la función de gestión que determina y aplica la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad”. 5. Sistema de Gestión de Calidad: “Conjunto de la estructura de la

organización, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad”.

(13)

• El QS debe tener el volumen y alcance suficiente para conseguir los objetivos de calidad.

• El QS de una organización está fundamentalmente previsto para satisfacer las necesidades internas de la organización. Es más amplio que los requerimientos de un cliente concreto que únicamente valore el QS que le interesa (directamente).

• Para finalidades contractuales o vinculantes en la valoración de la calidad, se puede exigir que se ponga de manifiesto la realización de ciertos elementos del QS.

6. Aseguramiento de la Calidad: “Es un conjunto de actividades preestablecidas y sistematizadas, aplicadas al sistema de calidad, que ha sido demostrado que son necesarias para dar confianza adecuada de que un producto o servicio satisfará los requisitos para la calidad”. 7. Acción Correctiva: “Acción tomada para eliminar las causas de una no

conformidad, defecto o cualquier situación indeseable existente, para evitar su repetición”.

8. Acción Preventiva: “Acción tomada para eliminar las causas de una no conformidad, defecto o cualquier situación indeseable potencial, con el fin de evitar que se produzca”.

9. Conformidad: “Cumplimiento de requisitos especificados”.

10. Costos de la no Calidad: “Costos asociados con la provisión de productos o servicios de baja calidad”.

11. Defectos: “No cumplimiento de un requisito o de una expectativa razonable, ligada a un uso previsto, incluyendo los relativos a la seguridad”.

12. Inspección: “Actividades como medir, examinar, ensayar o comparar una o más características de un producto o servicio, y comparar los resultados con los requisitos especificados, con el fin de determinar la conformidad con respecto a cada una de esas características”.

13. No Conformidad: “No satisfacción de un requisito especificado”. 14. Trazabilidad: “Aptitud de reconstruir la historia, la utilización o la

localización de un producto por medio de identificaciones registradas”. 15. Validación: “Confirmación por examen y aporte de evidencias objetivas de que los requisitos particulares para un uso específico previsto han sido satisfechos”.

16. Verificación: “Confirmación por examen y aporte de evidencias objetivas que los requisitos especificados han sido satisfechos”.

(14)

Figura 1.1 - Sistema de Gestión de Calidad 1.1.4. Definición de Calidad de Software

La Calidad del Software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia.

Según R. Pressman: “La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares y procesos de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición definitiva de la calidad del software. Para los propósitos de este enfoque, la anterior definición sirve para hacer hincapié en tres puntos importantes: 1. Los requisitos del software son la base de las medidas de la calidad.

La falta de concordancia con los requisitos es una falta de calidad. 2. Los estándares especificados definen un conjunto de criterios de

desarrollo que guían la forma en que se aplica la ingeniería del software o del conocimiento. En caso de no seguirse esos criterios, casi siempre habrá falta de calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software se debilita.

Queda claro a partir de la definición de calidad del software, que ésta es siempre relativa a los requisitos o necesidades que se desea satisfacer. Por eso la evaluación de la calidad del software siempre va a implicar la comparación entre los requisitos y el producto generado.

SISTEMA DE GESTIÓN DE LA

CALIDAD

MEJORA CONTINUA

Responsabilidad de la Dirección Medición, análisis y mejoramiento Gestión de recursos Realización Producto o Servicio Entrada Salida Producto o Servicio

C

L

I

E

N

T

E

S

R E Q U I S I T O S S A T I S F A C C I O N

(15)

La Calidad del Software es medible y varía de un sistema a otro o de un programa a otro. Por ejemplo: un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más) necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.

La Calidad del Software puede medirse después de elaborado el producto. Pero esto puede resultar muy costoso si se detectan problemas derivados de imperfecciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas del ciclo de vida del software.

Existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la complejidad del producto, las tecnologías y las personas, así como algunas condiciones de entorno que también tienen su impacto, estas pueden ser condiciones de gestión (plazo de entrega, restricciones dentro de la organización), entornos de desarrollo y características del cliente, sin embargo en el centro de todas ellas se encuentra el proceso. El proceso es el único factor de los controlables al mejorar la calidad del software y su rendimiento en la organización. Analizando y mejorando el proceso se puede obtener mejores productos.

Figura 1.2 - Determinantes de la calidad del software y de la efectividad de la organización

Los ejes de desarrollo de software se relacionan con la calidad de la siguiente forma:

1. Persona: PSP, TSP

2. Producto: McCall, Boehm, ISO/IEC 9126-1 3. Proceso: CMM, ISO/IEC 15504

4. Mejora continua del proceso: IDEAL, ISO/IEC 15504, SPI Por lo tanto:

(16)

Figura 1.3 - Dependencia entre Calidad de Producto y Calidad de Proceso 1.1.4.1. Control de Calidad:

Para controlar la Calidad del Software es necesario, definir los parámetros, indicadores o criterios de medición.

El software posee determinados índices medibles que son las bases para la calidad, el control y el perfeccionamiento de la productividad.

Una vez seleccionados los índices de calidad, debe establecerse el proceso de control, que requiere los siguientes pasos:

1. Definir el software que va a ser controlado: clasificación por tipo, ámbito de aplicación, complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.

2. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.

3. Crear o determinar los métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios parciales y herramientas automatizadas para medir los criterios de cálculo.

Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y, lo que es más importante, que se cumplan. La Calidad del Software debe implementarse a lo largo de todo el ciclo de vida, debe correr paralela desde la planificación del producto hasta la fase de producción del mismo.

(17)

Para ello se cuenta con una serie de ayudas, a través de distintas actividades para la implantación del control de calidad en el desarrollo que son:

• Aplicación de metodología y técnicas de desarrollo

• Reutilización de procesos de revisión formales

• Prueba del software

• Ajustes a los estándares de desarrollo

• Control de cambios, mediciones y recopilación de información

• Gestión de informes sobre el control de calidad

Para la fase de Planificación, se pueden utilizar elementos y herramientas propias de la Gestión de proyectos, como la:

• Estimación de la duración, costo y esfuerzo para la construcción del producto. En lo referido a la estimación habrá que tener presentes las Métricas de software

• Planificación de tareas que hay que realizar, asignación de personas, tiempo, costo y otros parámetros para construcción del producto

Para los procesos de Análisis y Diseño deberemos contar con:

• Sistemas de obtención de requisitos

• Métricas de software

• Herramientas de Generación de Datos

• Casos de Prueba

En los procesos de Construcción y pruebas deberíamos usar:

• Herramientas de Gestión de la Configuración

• Herramientas de Simulación

• Casos de Pruebas

Y, finalmente, para el proceso de Producción, básicamente debemos utilizar:

• Herramientas de monitoreo de resultados

• Pruebas de producción

Definir las regulaciones organizativas para realizar el control: quienes participan en el control de calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

El Instituto de Ingeniería de Software (SEI) en su modelo CMM define la calidad como:

• El grado en el cual un sistema, componente o proceso cumple con los requisitos especificados.

• El grado en el cual el sistema, componente o proceso cumple con las expectativas del cliente o usuario.

(18)

1.1.4.2. Aseguramiento de Calidad:

Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza adecuada en que el producto (software) satisfacerá los requisitos dados de calidad. El aseguramiento pretende dar confianza en que el producto tiene calidad.

Aseguramiento de calidad se enfoca en identificar y evaluar los defectos que puedan afectar al software. Si los errores se pueden identificar de forma temprana en el proceso de software, las características del diseño de software se pueden especificar de modo que eliminarán o controlarán los peligros potenciales, al corregir los errores mucho antes en cada etapa es decir durante el proceso, ahorrando esfuerzos, tiempo y recursos.

Sridharan (Sridharan, 2000) indica que mientras el software que se está desarrollando reúne los requerimientos y su desempeño sea el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software.

Hay tres aspectos muy importantes con relación al aseguramiento de la calidad del software: (Wiegers, 1990) i) La calidad no se puede probar, se construye.

ii) El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del ciclo de vida de desarrollo.

iii) Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo. El aseguramiento de la calidad de software comprende una gran variedad de tareas:

i) Participar en descripción del proyecto de software.

ii) Auditar el producto de software para verificar el cumplimiento del proceso de software definido.

iii) Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos.

iv) Almacenar cualquier inconformidad y reportarla a la gerencia media.

v) Revisiones del software que se aplican durante cada paso del desarrollo del mismo. Las revisiones del software se aplican en varios momentos del desarrollo, tanto en el análisis como en el diseño y la codificación, de manera que puedan ser eliminados cuanto antes.

(19)

vi) Gestión de configuraciones de software (control de la documentación del software y de los cambios realizados). El proceso de control de cambios contribuye directamente a la calidad del software.

Figura 1.4 - Componentes del Aseguramiento de Calidad de Calidad (SQA) El grupo de aseguramiento de calidad participa en la revisión de los productos seleccionados para determinar si se conforman o no a los procedimientos, normas o criterios especificados, siendo totalmente independiente del equipo de desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad vienen gobernadas por el plan. Sus funciones están dirigidas a:

i) Identificar las posibles desviaciones en los estándares aplicados, así como en los requisitos y procedimientos especificados.

ii) Comprobar que se han llevado a cabo las medidas preventivas o correctivas necesarias.

iii) Las revisiones son una de las actividades más importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo más pronto posible, cuando son menos costosos de corregir.

Es importante señalar que la calidad de un producto software no se puede referir únicamente a obtener un producto sin errores. La especificación de la calidad del software debe ser más detallada y exacta, y el camino para ello es la formalización de la calidad mediante un modelo de calidad. Un modelo de calidad es un conjunto de buenas prácticas para el desarrollo del software, enfocado en los procesos de gestión y desarrollo de proyectos, cuyo objetivo es el desarrollo de productos de calidad de manera consistente y predecible.

(20)

Existen distintos marcos de trabajo que nos ayudan a mejorar los procesos de calidad de software. La finalidad de estos modelos es la de mejorar los procesos de software, brindar pautas para efectuar evaluaciones de la unidad informática, determinar la potencialidad y la efectividad de sus procesos, así como la madurez de la empresa. Se busca mejorar los procesos de software, aumentar la productividad la calidad reduciendo su costo.

(21)

1.2. ASEGURAMIENTO Y CONTROL DE CALIDAD

La Administración de la Calidad, es un área de conocimiento de todo proyecto, que incluye tres fases bien identificadas: la Planificación, el Aseguramiento y el Control.

El proceso de Planificación de la Calidad en todo proyecto, toma como entradas las Políticas de Calidad de la compañía, el informe de Alcance del proyecto, la descripción del sistema (producto/s), normas, regulaciones y estándares que deben aplicarse, para producir como salidas un Plan de Dirección de Calidad, definiciones operativas y check-lists utilizadas por los procesos de Aseguramiento y Control de Calidad.

Para ello se utilizan como herramientas el Análisis de costo-beneficio, diagramas de flujo, los diagramas de causa-efecto (Ishikawa), o el Benchmarking. Esta fase es la más importante en cuanto a calidad se refiere, porque se identifican posibles cuellos de botella, duplicación del trabajo o problemas de seguridad, y se ofrecen soluciones dentro del Plan de Calidad.

El Control de la Calidad comprende el seguimiento de los resultados específicos del proyecto para determinar si cumplen con las normas de calidad, e identificar la forma de eliminar los resultados insatisfactorios.

Por lo tanto SQA o Software Quality Assurance, es el proceso de asegurar la calidad, aplicado al software, que debe realizarse a lo largo de todos los procesos de fabricación: desde el análisis de requerimientos hasta la puesta en producción.

Al igual que ocurrió con la definición de calidad hay varios puntos de vista desde donde se puede definir el aseguramiento de la calidad del software. Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad como:

“Una guía planificada y sistemática de todas las acciones necesarias para proveer la evidencia adecuada de que un producto cumple los requerimientos técnicos establecidos. Un conjunto de actividades diseñadas para evaluar el proceso por el cual un producto es desarrollado o construido.”

Daniel Galin define SQA como:

“Un conjunto, sistemático y planificado, de acciones necesarias para proveer la evidencia adecuada de que el proceso de desarrollo o mantenimiento de un sistema de software cumple los requerimientos técnicos funcionales tan bien como los requerimientos gerenciales para cumplir la planificación y operar dentro del presupuesto confinado”.

Desde el punto de vista de la visibilidad, el SEI define SQA como

“El aseguramiento de la calidad del software provee claro control del proceso que está siendo usado por el proyecto y del producto que se está construyendo.”

(22)

Desde el punto de vista del aseguramiento, Don Reifer define SQA como “El aseguramiento de la calidad del software es el sistema de métodos y procedimientos usados para asegurar que el producto de software alcanza sus requerimientos. El sistema involucra la planificación, estimación y monitoreo de las actividades de desarrollo realizadas por otros.”

Desde el punto de vista de la capacidad de uso Schulmeyer y McManus definen SQA como

“Las actividades sistemáticas que proveen evidencia de la capacidad o disponibilidad de uso del producto de software total.”

1.2.1. SQA (Software Quality Assurance) no es lo mismo que SQC (Software Quality Control)

Generalmente cuando le preguntamos a un profesional de sistemas que es lo que entiende por aseguramiento de la calidad del software, inmediatamente comienza a hablar de testing, algunos de ellos incluyen a la validación y verificación y luego empiezan a hablar de revisiones, las cuales son sólo extensiones del testing. Es decir, a menudo hay una confusión entre SQA y el testing (el cual actualmente forma parte del área de control de calidad del software SQC).

Haciendo sólo testing y revisiones no aseguramos la calidad de los productos, sino aseguramos el cumplimiento de especificaciones tanto funcionales como técnicas. En el desarrollo de software la diferencia entre SQC y SQA no está clara y estos términos a menudo se confunden, SQA se encarga de controlar el cumplimiento del proceso, mientras que SQC son aquellas acciones del aseguramiento de la calidad que proporcionan un medio para controlar y medir las características de un elemento, proceso o facilidad respecto a los requisitos establecidos.

La Tabla 1 muestra las diferencias entre Aseguramiento de la calidad (SQA) y Control de calidad (SQC)

SQA SQC

Asegura la adherencia a los procesos, estándares y planes.

Detecta problemas en los productos de trabajo. Evalúa que los procesos,

planes y estándares utilizados en el proyecto cumplan con los estándares organizacionales

Verifica que los productos de trabajo cumplan con los estándares de calidad especificados en el plan de proyecto.

Revisa procesos Revisa el contenido del

producto Tabla 1 – Diferencia entre SQA y SQC

En conclusión, el rol del SQA es auditar que los distintos equipos de la organización, inclusive el de SQC siguen los procedimientos, estándares y procesos establecidos. El equipo de SQA debería

(23)

establecer métricas para medir la efectividad del proceso. Como complemento el rol de SQC es tomar una actitud activa de verificación y validación del resultado o salida del proceso implementado.

1.2.2. Funciones Generales del SQA

Describir los diferentes roles que puede jugar el equipo de SQA en una organización nos dará una visión clara de las funciones que puede llevar a cabo.

“Como policía del proceso”

El trabajo del equipo de SQA es asegurar que el desarrollo sigue el proceso establecido.

Entre sus funciones en este rol se encuentran:

• Auditar los productos del trabajo para identificar deficiencias. • Determinar el cumplimiento del plan de desarrollo del proyecto y

del proceso de desarrollo de software. • Juzgar el proceso y no el producto. “Como abogado del cliente”

El trabajo del equipo de SQA es representar al cliente. Entre sus funciones en este rol se encuentran:

• Identificar la funcionalidad que al cliente le gustaría encontrar. • Ayudar a la organización a sensibilizarse con las necesidades del

cliente.

• Actuar como un cliente de prueba para obtener una alta satisfacción del cliente.

“Como analista”

El trabajo del equipo de SQA es recabar información. Entre sus funciones en este rol se encuentran:

• Juntar muchos datos sobre todos los aspectos del producto y del proceso.

• Con esta información ayudar a mejorar los procesos y los productos.

“Como proveedor de información”

El trabajo del equipo de SQA es revisar qué es lo que esté hecho y decir cuáles objetivos técnicos realmente están cumplidos para que la gerencia pueda tomar mejores decisiones de negocios.

Entre sus funciones en este rol se encuentran:

• Proveer información técnica objetiva para que la gerencia pueda usarla para tomar mejores decisiones.

• Proveer información apropiada de las clases de productos y de los riesgos asociados con estos.

• Concentrarse más en la reducción de los riesgos que en el cumplimiento del proceso.

(24)

“Como responsable de la elaboración del proceso”

El trabajo del equipo de SQA es participar en la definición de los planes, procesos, estándares y procedimientos para asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas de la organización. Para cumplir este rol el aseguramiento de la calidad debería comenzar en las fases tempranas del proyecto.

Para ser efectivo, el equipo que realiza SQA debe ser independiente de la organización de desarrollo. Aunque tener un grupo de auditoría independiente es difícil de aplicar en organizaciones chicas donde hay pequeños ambientes de desarrollos. Pero si la organización es madura y tiene una cultura orientada a la calidad, la función de SQA puede estar embebida en el proceso. Cuando el equipo de SQA esta embebido en el proceso, se deben resolver varios inconvenientes para garantizar la objetividad:

• Todo aquel que realice actividades de aseguramiento de la calidad debería estar entrenado en el aseguramiento de la calidad.

• Las actividades de aseguramiento de la calidad realizadas para un producto deberían ser separadas de aquellas involucradas en el desarrollo y mantenimiento del mismo.

• Debe estar disponible un canal de comunicación independiente en el nivel apropiado de la gerencia para poder escalar las no conformidades cuando sea necesario.

El equipo de SQA provee a la gerencia de información fehaciente, objetiva en el momento adecuado. La clave aquí está en que el grupo de SQA provee a la gerencia de información técnica objetiva. La gerencia necesita ver a la gente de SQA como una fuente de información significativa que puede ayudarla a tomar decisiones difíciles. La Gerencia usa esta información para tomar decisiones de negocio apropiadas.

La objetividad en la evaluación de calidad de los procesos y productos es crítica para el éxito del proyecto. La objetividad se logra con independencia del equipo de SQA y sentido común o criterio. Hay diferentes maneras de realizar evaluaciones objetivas, entre las que se incluyen:

• Auditorías formales realizadas por un área de SQA independiente de la organización.

• Revisiones de a pares que pueden ser realizadas con distintos niveles de formalidad.

• Revisiones rigurosas en el lugar de desarrollo. • Revisiones distribuidas y comentarios del producto.

(25)

La tarea del equipo de SQA es un conjunto planificado de tareas, actividades y acciones ejecutadas independientemente de la organización que desarrolla software, que provee a la gerencia del proyecto información fehaciente en un momento preciso que puede ser usada para tomar decisiones de negocio apropiadas

(26)

1.3. MODELO DE PROCESOS

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes:

i) Los sistemas no responden a las expectativas de los usuarios. ii) Los programas “fallan” con cierta frecuencia.

iii) Los costos del software son difíciles de prever y normalmente superan las estimaciones.

iv) La modificación del software es una tarea difícil y costosa.

v) El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.

vi) Normalmente, es difícil cambiar de entorno hardware usando el mismo software.

vii) El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

Según el Centro Experimental de Ingeniería de Software (CEIS), el estudio de mercado “The Chaos Report” realizado por Standish Group Internactional en 1996, concluyó que sólo un 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollo de software son:

i) Escasa o tardía validación con el cliente. ii) Inadecuada gestión de los requisitos.

iii) No existe medición del proceso ni registro de datos históricos. iv) Estimaciones imprevistas de plazos y costos.

v) Excesiva e irracional presión en los plazos.

vi) Escaso o deficiente control en el progreso del proceso de desarrollo. vii) No se hace gestión de riesgos formalmente.

viii) No se realiza un proceso formal de pruebas.

(27)

El primer reconocimiento público de la existencia de problemas en la producción de software tuvo lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia, así como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer lo que se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el software económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora que funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin embargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de la calidad del software, satisfacción del cliente, mediciones y métricas, etc.

El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) ha desarrollado una definición más completa para ingeniería del software: “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software.

El estudio de enfoques en Pressman caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 3.1.

Figura 3.1 - Capas de la Ingeniería de Software

Dichas capas se describen a continuación:

1. Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software.

2. El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

(28)

3. Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

4. Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering).

Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas.

A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.

1.3.1. El Proceso de Desarrollo de Software

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 3.2. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

1. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).

2. Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

3. Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

(29)

Figura 3.2 - Proceso de Desarrollo de Software

4. El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:

1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.

2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.

3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.

4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.

Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación:

1. Seguimiento y control de proyecto de software. 2. Revisiones técnicas formales.

3. Garantía de calidad del software. 4. Gestión de configuración del software. 5. Preparación y producción de documentos. 6. Gestión de reutilización.

7. Mediciones.

(30)

Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 2.3. Los elementos involucrados se describen a continuación:

1. Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.

2. Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto.

3. Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3.3 - Elementos del Proceso de Software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

(31)

Figura 3.4 - Relación entre los Elementos del Proceso de Software En la Figura 3.4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma:

1. Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos.

2. Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones.

3. Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos.

La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

1.3.2. Normas Relacionadas con el Proceso de Software

La calidad es un concepto que se ha difundido y establecido en diversas actividades del quehacer humano y que se aprecia por su recurrente utilización en distintos ámbitos. En particular, en el campo de las tecnologías de la información, se han desarrollado o se han adaptado, de otros contextos, modelos para favorecer la adopción de buenas prácticas para la realización de los procesos del ciclo de vida del software. Estos modelos en calidad de proceso software han evolucionado, siendo quizás una de las más interesantes el manejo de los conceptos de capacidad de procesos y de madurez organizacional. En especial, en los modelos definidos en las normas ISO/IEC 12207 e ISO/IEC 15504 se presenta un modelo de madurez organizacional.

(32)

En el tema de calidad a nivel de procesos se han desarrollado diversas propuestas para la industria en general como es el caso de los modelos: Malcom Baldrige, EFQM e ISO 9001, entre otros; los mismos que en alguna medida han sido utilizados por las organizaciones que desarrollan software. Un caso particular es la ISO/IEC 90003, que es una guía de aplicación de la ISO 9001:2000 para el sector informático. En el campo de las tecnologías de información, relacionado a procesos de software, se tienen una variedad creciente de propuestas y estándares que han ido evolucionando o mejorando de acuerdo al desarrollo tecnológico.

Existen varios modelos que cubren diversos aspectos y han sido desarrollados con distintos propósitos. Entre los modelos relacionados de manera directa o indirecta con los procesos de software se pueden mencionar: ISO/IEC 12207 (procesos del ciclo de vida de software), CMMI (modelo de madurez y capacidad integrada, antes CMM-Sw), RUP (Rational Unified Processes), ISO/IEC 20000 (gestión de servicios de TI), ITIL (biblioteca de infraestructura de tecnologías de información), ISO/IEC 15504 (modelo para la evaluación de capacidades de procesos y madurez de organizaciones), IDEAL (mejora de procesos recomendado para CMMI), PSP (proceso de software para persona), TSP (proceso de software para equipos de trabajo), SCAMPI (método de evaluación de procesos usado para CMMI), Quick Locus (método ligero brasileño de evaluación de CMMI), PMBOK (Cuerpo de conocimiento de gestión de proyectos de PMI), ISO 10006 (directrices para la calidad en la gestión de proyectos), MoProSoft (modelo de procesos de referencia mexicano), EvalProSoft (método de evaluación basado en 15504 para MoProSoft), SIMEP-Sw (conjunto de modelos ligeros para mejor de procesos, colombiano), MPS.BR (modelos de mejor y evaluación de procesos brasileños), TMMI (modelo de madurez para Pruebas de Software), SPIRE (modelo de mejora de la región Europea), TOPS (mejora de procesos para pymes), PROCESSUS, IMPACT y RAPID entre otros.

El modelo de madurez organizacional es uno de los tipos de modelos que ha recibido más atención en los últimos años. Dentro del campo de la informática se tienen entre otros a CMMI, MoProSoft, el par ISO/IEC12207-ISO/IEC 15504 y TMMI; y fuera del campo de la informática se tiene a OPM3, SOA-MM, BP-MM y GIMM de una lista mayor de propuestas. Todos estos modelos que pueden tener aspectos diferentes influenciados por el dominio donde aplican, están vinculados necesariamente por el concepto que tratan de representar: un modelo de madurez organizacional; sin embargo al no existir algún referente que oriente como definir este tema, es posible que cada cual adopte el suyo propio.

(33)

Figura 3.5 - Normas Relacionadas con el Proceso de Software 1.3.2.1. Conceptos Clave

i) Proceso:

Conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman elementos de entrada en resultados. NTP-ISO/IEC 12207 Procesos del Ciclo de Vida del Software.

Figura 3.6 - Proceso

Figura 3.7 - ¿El desarrollo de software es realmente un proceso? ii) Modelo:

Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja. DRAE

(34)

Periodo de tiempo que comienza con la decisión de desarrollar el producto software y termina cuando el software es entregado. IEEE Std. 610.12-1990 Software Engineering Terminology

iv) Ciclo de vida de software:

Periodo de tiempo que comienza cuando el producto software es concebido y termina cuando el software no está disponible permanentemente para el usuario (retirada del software) . IEEE Std. 610.12-1990 Software Engineering Terminology.

v) Estados del ciclo de vida del software:

Constituye cada uno de los momentos (“estados”) por las que pasa (evoluciona) el producto software. Ing.

Software. R.Fairley

Figura 3.8 - Ciclo de Vida y Ciclo de Desarrollo del Software 1.3.2.2. Ciclos de Vida, Procesos, Productos

Considerando al ciclo de vida como la evolución del producto de software, se infiere que dentro de cada una de las etapas del ciclo de vida se implementen procesos de desarrollo.

Figura 3.9 - Procesos y Ciclos de Vida Obtener

Requisitos

Necesidades Especificación de

Requisitos Diseño Codigo

Diseñar

Sistema Codificar Probar

Ciclos de vida Proceso

(35)

De la definición de proceso se infiere que cada proceso genera productos, tal como se muestra a continuación:

Figura 3.10 - Procesos y Productos 1.3.3. Los Procesos ISO 12207:2008

El modelo ISO 12207:2008 establece un conjunto de buenas prácticas para guiar a las organizaciones en la mejora de sus procesos de desarrollo y mantenimiento software.

En concreto, define 43 procesos que pueden aplicarse durante la adquisición de un producto o servicio software y durante el suministro, desarrollo, operación, mantenimiento y evolución de productos software.

(36)

Figura 3.11 - Modelo de Procesos ISO 12207:2008

Figura 3.12 - Modelo de Procesos ISO 12207:2008 – Alcance APLICACIÓN:

Nace M uere

Adquirientes, proveedores, usuarios, ...

PROCESOS CORPORATIVOS PROYECTOS PRODUCTOS INVOLUCRADOS (STAKEHOLDERS) : CICLO DE VIDA:: DETALLES: : PROCESOS, DEFINICIO NES Y DESCRIPCIONES

METODO LOG ÍAS, MÉTO DOS Y MÉTRICAS PROCEDIMIENTO S , TÉCNICAS, HERRAM IENTAS Y ENTORNOS PROYECTOS SERVICIOS

(37)

1.4. MODELO DE CICLO DE VIDA DE SOFTWARE

Sommerville define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.”

Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software.

Modelos que se van a discutir a continuación:

• Codificar y corregir

• Modelo en cascada

• Desarrollo evolutivo

• Desarrollo formal de sistemas

• Desarrollo basado en reutilización

• Desarrollo incremental

• Desarrollo en espiral

1.4.1. Codificar y corregir (Code-and-Fix)

Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:

• Escribir código.

• Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento.

Este modelo tiene tres problemas principales:

• Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.

• Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.

• El código es difícil de reparar por su pobre preparación para probar y modificar.

1.4.2. Modelo en Cascada

El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.

(38)

El modelo en cascada consta de las siguientes fases:

1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.

2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.

3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.

4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El

sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.

La interacción entre fases puede observarse en la Figura 4.1. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario.

Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

Figura 4.1 - Modelo de Desarrollo en Cascada

En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:

• Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.

• Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.

(39)

• Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.

• Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.

• Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

1.4.3. Desarrollo Evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en “N” versiones hasta que se desarrolle el sistema adecuado. En la Figura 4.2 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final.

Una ventaja de este modelo es que se obtiene una rápida retroalimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Figura 4.2 - Modelo de Desarrollo Evolutivo

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio:

El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.

(40)

Enfoque utilizando prototipos:

El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo están:

• La especificación puede desarrollarse de forma creciente.

• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:

• Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.

• Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

• Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.

Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

1.4.4. Desarrollo Formal de Sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

(41)

Figura 4.3 - Paradigma de Programación Automática

La Figura 4.3 ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son:

• La especificación es formal y ejecutable constituye el primer prototipo del sistema).

• La especificación es validada mediante prototipado.

• Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema.

• En el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado.

• El mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).

Observaciones sobre el desarrollo formal de sistemas:

• Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.

• Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.

• Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

1.4.5. Desarrollo Basado en Reutilización

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 4.4.

(42)

A continuación se describe cada fase:

1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.

2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).

3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.

4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Las ventajas de este modelo son:

• Disminuye el costo y esfuerzo de desarrollo.

• Reduce el tiempo de entrega.

• Disminuye los riesgos durante el desarrollo.

Figura 4.4 Desarrollo Basado en Reutilización de Componentes

Desventajas de este modelo:

• Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.

• Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

(43)

1.4.6. Procesos Iterativos

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:

• Desarrollo Incremental.

• Desarrollo en Espiral.

1.4.6.1. Desarrollo Incremental

Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 4.5). Es una combinación del Modelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 4.5 - Modelo de Desarrollo Iterativo Incremental

Entre las ventajas del modelo incremental se encuentran:

• Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.

• Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

• Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

• Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

Figure

Actualización...

Referencias

Actualización...