INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA
DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
“CONSTRUCCIÓN DEL SOFTWARE”.
TESIS
QUE PARA OPTAR POR EL TÍTULO DE:
LICENCIADO EN CIENCIAS DE LA INFORMÁTICA
P R E S E N T A:
DAVID ARMANDO LEÓN MAYA
México, D.F. 2010.
INDICE
RESUMEN ... I
INTRODUCCIÓN ... IV
CAPÍTULO I
FUNDAMENTOS DE CONSTRUCCIÓN DE SOFTWARE
1.1ESCENARIO PARA LA CONSTRUCCIÓN DEL SOFTWARE. ... 2
1.2MINIMIZAR LA COMPLEJIDAD. ... 4
1.2.1PROPIEDADES DE LA COMPLEJIDAD. ... 5
1.2.2CONSECUENCIAS DE LA COMPLEJIDAD ILIMITADA. ... 7
1.2.3TÉCNICAS PARA MINIMIZAR LA COMPLEJIDAD. ... 8
1.3PREVER EL CAMBIO. ... 10
1.3.1TIPOS DE CAMBIO. ... 11
1.3.2PRINCIPIOS DEL CAMBIO... 12
1.3.3PROBLEMAS DEL CAMBIO. ... 14
1.3.4METODOLOGÍA PARA LA PREVENCIÓN DE CAMBIOS. ... 15
1.3.4.1 Especificación de Líneas Base. ... 16
1.3.4.2 Identificación de Objetos. ... 17
1.3.4.3 Control de Versiones. ... 18
1.3.4.4 Control Estricto de Cambios. ... 20
1.4CONSTRUCCIÓN PARA LA VERIFICACIÓN. ... 22
1.4.1MODEL CHECKING (COMPROBACIÓN DE MODELOS). ... 23
1.4.2INTERPRETACIÓN ABSTRACTA. ... 25
1.4.2.1 Testing estructural... 27
1.5ESTÁNDARES EN LA CONSTRUCCIÓN. ... 28
CAPÍTULO II ADMINISTRACIÓN DE LA CONSTRUCCIÓN DEL SOFTWARE 2.1MODELOS DE CONSTRUCCIÓN TRADICIONALES. ... 31
2.1.1MODELO CASCADA. ... 31
2.1.2MODELO DE DESARROLLO INCREMENTAL. ... 32
2.1.3MODELO DE DESARROLLO EVOLUTIVO. ... 34
2.1.4MODELO DE PROTOTIPADO DE REQUERIMIENTOS. ... 35
2.1.5MODELO ESPIRAL. ... 37
2.1.6MODELO CONCURRENTE. ... 39
2.2METODOLOGÍAS DE CONSTRUCCIÓN EN LA ACTUALIDAD. ... 40
2.2.1METODOLOGÍA RUP(RATIONAL UNIFIED PROCESS-PROCESO UNIFICADO RACIONAL). ... 41
2.2.2METODOLOGÍA ASML(ASYSTEM MODELLING LANGUAGE-SISTEMA DE LENGUAJE MODELADO). ... 43
2.2.2.1 El Modelo Esencial . ... 44
2.2.2.2 El Modelo de Implementación. ... 45
2.2.3METODOLOGÍA CASE(COMPUTER AIDED SYSTEMS ENGINEERING). ... 47
2.2.4METODOLOGÍA XP(EXTREME PROGRAMING). ... 49
2.2.5METODOLOGÍA MSF(MICROSOFT SOLUTION FRAMEWORK). ... 51
2.2.6SELECCIONANDO MODELOS DE CONSTRUCCIÓN. ... 53
2.3PLANIFICACIÓN DE LA CONSTRUCCIÓN. ... 55
2.3.1OBJETIVOS DE LA PLANIFICACIÓN. ... 57
2.3.2ASPECTOS ASOCIADOS AL PROYECTO. ... 57
2.3.3MODELOS DE ESTIMACIÓN. ... 61
2.4MEDICIÓN DE LA CONSTRUCCIÓN. ... 62
2.4.1ARQUITECTURA DE UN PROCESO DE MEDIDA DE SOFTWARE. ... 65
2.4.2MODELO DE PROCESO PARA LA DEFINICIÓN DE MEDIDAS DE SOFTWARE. .. 67
CAPÍTULO III CONSIDERACIONES PRÁCTICAS 3.1DISEÑO DE LA CONSTRUCCIÓN. ... 71
3.1.1TÉCNICAS DE DISEÑO. ... 71
3.1.2DISEÑO DE INTERACCIONES CON LA BASE DE DATOS. ... 72
3.1.3DISEÑO DE ARCHIVOS. ... 73
3.1.4DISEÑO DE LA SALIDA. ... 73
3.2LENGUAJES DE CONSTRUCCIÓN. ... 74
3.2.1CARACTERÍSTICAS. ... 74
3.2.2PARADIGMAS. ... 75
3.2.2.1 Clasificación de Paradigmas. ... 76
3.2.3FACTORES EN LA ELECCIÓN DE UN LENGUAJE DE CONSTRUCCIÓN. ... 77
3.2.4CLASIFICACIÓN DE LOS LENGUAJES DE CONSTRUCCIÓN. ... 78
3.2.5VISUAL STUDIO.NET VSC#. ... 80
3.2.5.1 Visual Studio.NET. ... 80
3.2.5.2 Lenguaje C#. ... 81
3.3CODIFICACIÓN. ... 83
3.3.1ESTÁNDARES DE CODIFICACIÓN. ... 84
3.3.2TÉCNICAS DE CODIFICACIÓN. ... 84
3.3.2.1 Generales. ... 85
3.3.2.2 Nombrado. ... 86
3.3.2.3 Comentarios. ... 87
3.3.2.4 Formato. ... 89
3.4PRUEBA DE CONSTRUCCIÓN. ... 90
3.4.1MÓDULOS INDEPENDIENTES. ... 92
3.4.2PRUEBAS DE CARGA Y RENDIMIENTO. ... 92
3.4.3SUBCONTRATACIÓN DE PRUEBAS. ... 93
3.5REUSABILIDAD. ... 94
3.5.1BENEFICIOS DE LA REUSABILIDAD. ... 94
3.5.2FACTORES DE LA REUSABILIDAD. ... 96
3.5.3NIVELES DE REUSABILIDAD. ... 97
3.5.4REUSABILIDAD ORIENTADA A OBJETOS. ... 98
3.5.4.1BIBLIOTECAS DE CLASES. ... 99
3.5.4.2 Polimorfismo. ... 103
3.5.4.3 Clasificación de Clases. ... 103
3.5.4.4 Patrones de Diseño... 104
3.5.4.5 Arquitecturas. ... 106
3.6CALIDAD EN LA CONSTRUCCIÓN... 108
3.6.1PRINCIPIOS BÁSICOS DE CALIDAD. ... 109
3.6.2CONTROL DE CALIDAD. ... 110
3.6.2.1 Gestión de Calidad... 111
3.6.2.2 Niveles de Calidad. ... 113
3.7LA INTEGRACIÓN. ... 116
3.7.1CARACTERÍSTICAS. ... 118
CONCLUSIONES ... 119
BIBLIOGRAFÍA ... 121
RESUMEN
CAPÍTULO I
FUNDAMENTOS DE CONSTRUCCIÓN DEL SOFTWARE
En este capítulo se dan a conocer los aspectos generales que se deben considerar previo el desarrollo del software, tales como prever los posibles cambios en las necesidades del negocio, esto es muy importante ya que todo desarrollo debe ser flexible y adaptable a cualquier variación del entorno para el que va a ser útil.
Existen diferentes tipos de cambio, los cuales pueden ser predecibles o impredecibles, y estos dependen de los diversos factores que rodean a las organizaciones.
Por esto mismo también se tienen que considerar en el desarrollo de software, sentencias y algoritmos sencillos, que permitan la modificación y optimización de la aplicación sin complicar el funcionamiento.
Un aspecto fundamental en la prevención del cambio es el control de versiones. El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.
Por último se presentarán los estándares de construcción que se deben seguir para lograr un desarrollo óptimo, que esté preparado para soportar los cambios del ambiente y necesidades del negocio, así como los parámetros de factibilidad y costo de dichas modificaciones.
CAPÍTULO II
ADMINISTRACIÓN DE LA CONSTRUCCIÓN DEL SOFTWARE
La Administración en la construcción del Software se basa primordialmente en la consecución de un objetivo mediante una secuencia de pasos, los modelos de construcción proporcionan una guía para los ingenieros y desarrolladores de software con el fin de ordenar las diversas actividades técnicas en el proyecto.
De manera tradicional, se han creado modelos de ciclo de vida de software, tales como el Modelo Cascada, De Desarrollo Incremental, De Desarrollo Evolutivo, Prototipado y Espiral, todos con sus ventajas y desventajas pero orientados a mejorar la calidad de las aplicaciones y con el objetivo de tener bases sólidas que permitan un mejor proceso de Ingeniería.
En la actualidad hay que mencionar que se han creado metodologías que proporcionan una visión más amplia del entorno en el cual se va a construir software, tales como RUP, ASML, CASE, XP y MSF.
Otro aspecto importante a considerar es la Planeación de la Construcción, la cual depende de la anticipación a los problemas que puedan surgir y preparando con soluciones tentativas a ellos.
El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al administrador hacer estimaciones razonables de recursos costos y planificación temporal.
Las medidas y las métricas son herramientas muy útiles para el control de los procesos. Un proceso de medidas que acompañe al proceso software y se integre con él, ayuda en la interpretación, control y mejora de cada una de las actividades que se llevan a cabo dentro del mismo
CAPITULO III
CONSIDERACIONES PRÁCTICAS
Aquí se detallarán las técnicas y principios que permiten la realización física de un sistema o aplicación. Las cuales se basan en una serie de etapas de análisis y transformación de la información en una arquitectura de programa.
El diseño de archivos Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia.
La selección de un lenguaje de programación adecuado facilita la tarea de programación, ya que tiene que disponer de formas adecuadas que permitan ser leídas y escritas por personas, y que a su vez resulten independientes del modelo de computadora a utilizar.
Por último hay que mencionar los procesos de prueba o testing, los cuales son una herramienta que asegura que un sistema hace lo que tiene que hacer.
Probar es una práctica habitual de todo proceso productivo, que básicamente consiste en comprobar que un producto tiene las características deseadas.
Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición.
INTRODUCCIÓN
En la actualidad, con el avance de la tecnología y los requerimientos cambiantes del negocio, surge la necesidad de tener herramientas automatizadas que sean eficientes y que tengan la capacidad de evolucionar.
Basados en lo anterior, el presente trabajo tiene como propósito dar a conocer los diversos escenarios que se presentan al momento de construir aplicaciones de software, desde la Ingeniería de Requerimientos, la planeación, el desarrollo la fase de validación y la implementación en ambientes productivos.
Pero además del desarrollo e implementación es importante recalcar un aspecto fundamental en la construcción del software, el mantenimiento del mismo, ya que durante la explotación de aplicaciones pudieran presentarse situaciones de mejoras o errores que no se tuvieron contemplados. Es por ello que se tiene que hacer énfasis en la flexibilidad que deben tener las aplicaciones para adaptarse al cambio.
También resulta fundamental recalcar que debemos de recurrir a herramientas adecuadas y modelos específicos que nos permitan llevar a cabo un desarrollo funcional y adecuado para satisfacer los requerimientos, es decir, hacer análisis previos y definir con el cliente cual es el objetivo primordial del software a construir, todo esto con el objetivo de reducir al mínimo la complejidad de dichas herramientas.
Por ello se debe tener conocimiento de la tecnología que existe actualmente en el mercado, no podemos estancarnos en lo que ya existe, parte de la evolución siempre será el buscar el surgimiento de nuevas aplicaciones y estar capacitado para implementarlas en los ambientes de desarrollo y producción.
No se puede dejar fuera el factor calidad, ya que, además de proporcionar prestigio ante los clientes, minimiza el trabajo y aumenta la productividad, se debe tener un control adecuado y personal debidamente capacitado para detectar errores de manera oportuna, todo esto con el objetivo de solucionar y obtener resultados antes de implementar las aplicaciones.
Los errores son menos costosos si se detectan en los ambientes de desarrollo y control de calidad que una vez instalados en los ambientes productivos.
Por último se detallarán las técnicas adecuadas para integrar en un solo proyecto de construcción de software todo el análisis, funcionamiento, calidad y mantenimiento, ya que además de además de la separación de actividades se necesita capacidad para armar cada una de las piezas del rompecabezas y que este llegue al objetivo deseado.
El objetivo principal del software será siempre satisfacer las necesidades del negocio con el menor costo posible.
CAPÍTULO I
FUNDAMENTOS DE CONSTRUCCIÓN DE SOFTWARE
Para abordar el tema de una manera clara y precisa, se necesita entender el significado del término “Construcción del Software”, este se define como:
“La creación detallada de software significativo en operación, a través de una combinación de actividades de prevención de defectos, codificación, verificación y certificación de calidad”.1
En la construcción intervienen prácticamente todas las disciplinas de la ingeniería de software y de la ciencia de la computación, particularmente el conocimiento de algoritmos.
Desde luego, de las disciplinas de ingeniería, con las que más estrechamente se relaciona la construcción es con el Diseño y la etapa de Evaluación (pruebas). Suena redundante, pero aunque el Diseño Detallado se hace antes de Construir, mucho del diseño se realiza dentro de la actividad misma de la Construcción.
La construcción produce la mayor parte de los elementos de configuración que necesitan administrarse en un proyecto de software, por ello está también estrechamente vinculada a la administración de la configuración de software.
Puesto que la construcción de software se apoya fuertemente en herramientas y métodos, es la más intensiva en el uso de herramientas, está conectada a la Ingeniería de Software, Herramientas y diversas Áreas del Conocimiento.
Es indispensable tener en cuenta que la calidad es lo más importante en todas las actividades del ciclo de vida, y es por ello que donde más ha de cuidarse esta es en el código, el cual es la columna vertebral en un proyecto de software.
1 Pressman, R.S. Ingeniería del Software. Un enfoque práctico . Mc Graw Hill, España 6ª ed. 2006. p. 15.
1.1 Escenario Para la Construcción del Software.
Todos los proyectos de software comienzan con una petición del cliente, la cual nosotros interpretamos como una solicitud de requerimientos. Esta solicitud puede consistir en solucionar problemas del tipo:
Desarrollar una aplicación para llevar la administración de un negocio en particular.
Elaborar informes que definan un conjunto de objetivos comerciales.
Una especificación que tiene que asignar una función o comportamiento al software ya existente.
Si existe una petición para una aplicación de una de las formas dichas anteriormente, en la construcción del software se aplican los siguientes pasos:
Paso 1.- Evaluar el requerimiento y determinar si la aplicación a desarrollar es una buena herramienta para solucionar el problema en cuestión. A esto es a lo que comúnmente conocemos como factibilidad.
Debido a que el cliente debe interactuar con el software en los últimos pasos, es esencial que:
El cliente participe en la evaluación y refinamiento del software.
El cliente sea capaz de tomar decisiones del requerimiento solicitado de una forma oportuna.
Paso 2 .- Una vez evaluada la factibilidad del proyecto de software, se tiene que desarrollar una representación abreviada de los requerimientos.
Antes de que pueda comenzar la construcción de un software, debemos representar de manera genérica las funciones principales y de información de la aplicación, esto conllevará a desarrollar un método razonable de división de procedimientos (Modulación).
Paso 3.- Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño generales para el software a desarrollar.
El Diseño debe ocurrir antes de que comience la construcción del software.
Aunque hay que señalar que el diseño se enfoca hacia la arquitectura a nivel superior, en vez de hacia el diseño de procedimientos detallado.
Paso 4.- El software se desarrolla, se valida y se corrige. Idealmente, los módulos de construcción de software existen en el programa final. Esto resulta de gran utilidad en la fase de pruebas, ya que en caso de presentar errores, es mucho más fácil localizar el punto donde se está presentando dicha falla.
Paso 5.- El software evaluado, se presenta al cliente, el cual realiza otra serie de pruebas de acuerdo a lo que el ha solicitado y sugiere modificaciones.
Es aquí donde el cliente puede examinar una representación implementada de los requerimientos de la aplicación, sugerir modificaciones que harán al producto cumplir mejor las necesidades reales.
Paso 6.- Los pasos 4 y 5 entran en un ciclo repetitivo hasta que todos los requerimientos estén plasmados en la nueva aplicación o hasta que el software haya evolucionado hacia un sistema definitivo.
La construcción del software puede ser conducida con dos objetivos en mente:
1) Requerimientos traducidos en la producción del programa mediante el uso de métodos y técnicas de programación.
2) Suministrar un proceso continuo que pueda conducir al desarrollo evolutivo del software. 2
2 www.chapters.computer.org/actividades/escenario_const_soft.pdf (25/04/2008).
Figura No. 1.- Desglose de los Elementos que Intervienen en la Construcción del Software.3
Los fundamentos de la Construcción del Software Incluyen:
Minimizar la Complejidad.
Prever el Cambio.
Construcción para la Verificación.
Estándares en la Construcción. 4
A continuación se explicará la aplicación de estos fundamentos.
1.2 Minimizar la Complejidad.
El problema principal cuando los Ingenieros de Software tratan de codificar los requerimientos del usuario a Lenguaje Máquina radica en tener estructuras e información complejas, sobre todo cuando la construcción se realiza durante los períodos largos de tiempo.
3 2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio Fuenlabrada Velázquez.
4 2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio Fuenlabrada velásquez.
Construcción del Software
Fundamentos en la Construcción de Software
Consideraciones Prácticas Administración de la
Construcción
Minimizar la Complejidad Prever el Cambio Construcción para la Verificación Estándares en la Construcción
Modelos de construcción Planificación de construcción Medición de construcción
Diseño de construcción Lenguajes de construcción Codificación Prueba de construcción Reusabilidad Calidad de construcción La integración
Estrictamente, la Complejidad se define como:
“Una propiedad intrínseca de los objetos sin tomar en cuenta la percepción de un observador externo.”5
Muchos peligros nuevos son relacionados a la complejidad en los sistemas. Ya que ésta dificulta la identificación de las causas de los errores.
Una paradoja es que la gente quiere gastar mucho más dinero en la complejidad pero no en la sencillez. Las computadoras frecuentemente permiten construir dispositivos más interactivos, más acoplados, y más susceptibles a los errores, y pueden introducir complejidad innecesaria y peligrosa.
La complejidad del software se incrementa constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más sencillos hasta los de misión crítica.
Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.
Es conveniente hacer un análisis de la complejidad, sus propiedades, los tipos de esta que pueden surgir y como resolverlos, a continuación se detallarán estos puntos:
1.2.1 Propiedades de la Complejidad.
1) No Negativa.- Siempre existe como parte de un diseño de un sistema.
2) Nula.- No hay relaciones dependientes entre los elementos de un sistema.
5 JOHNSON, Bruce. Flexible Software Design. Ed Mc Graw Hill. 2005, pp.440.
En algunos casos, el agregar relaciones entre componentes puede ayudar a entender más al sistema. Esto es desde luego cierto, pero lo que se mejora es el entendimiento de el sistema y no la complejidad.
La complejidad está basada en los siguientes principios:
Principio No. 1.- “La complejidad de un sistema debe ser igual o mayor que la suma de las complejidades de cualquiera de sus módulos.”
Principio No. 2.- “La complejidad de un sistema nunca disminuirá cuando las relaciones entre sus componentes aumenten.”
3) No Sensitiva.- Es decir, un sistema y las relaciones entre sus componentes no cambian si cambiamos la forma de representarlos. 6
La complejidad determina el entendimiento de el sistema y puede ayudar a pronosticarlo, pero no es el único elemento que se deba de usar para medir el entendimiento del sistema.
Esto nos lleva a tomar en cuenta uno de los factores más importantes en la construcción de software: reducción al mínimo de la complejidad.
La complejidad en la construcción del software se divide en 4 tipos:
Complejidad en el Dominio del Problema.
Complejidad en la Administración del Proyecto.
Complejidad de Flexibilidad.
Complejidad del Comportamiento.
A continuación se dará una breve descripción de cada uno de estos tipos:
Complejidad en el Dominio del Problema.- Existe confusión o falta de entendimiento entre usuarios y desarrolladores. No hablan el mismo idioma.
6 E. J. Weyuker, "Evaluación de la Complejiadad del Software" Mc Graw Hill, 6ª ed 2001. pp. 1357-1365.
Complejidad en la Administración del Proyecto.- La tarea del equipo de desarrollo es proporcionar al usuario un enfoque se simplicidad aunque se trate de un sistema muy complejo.
Complejidad de Flexibilidad.- El equipo de desarrollo se puede ocupar de todos los módulos del proyecto sin necesidad de ayuda de otros profesionales.
Complejidad del Comportamiento.- Cualquier cambio externo puede afectar el estado interno de modo más brusco.7
1.2.2 Consecuencias de la Complejidad Ilimitada.
Mayor Riesgo.- Entre más complejo es el sistema, es más riesgoso aplicar cambios ya que se puede afectar completamente su funcionamiento.
Gran Inversión de Tiempo y Recursos Humanos.- Lo cual provoca a su vez mayor inversión costo-capital y menor productividad ya que provocaría retraso de otros posibles proyectos.
Mayor Planeación.- Mayor análisis y diseño de un modelado más amplio para minimizar el efecto del mantenimiento y la evolución.
Sistemas altamente jerarquizados.- Varios subsistemas relacionados, lo cual ocasiona mayor dependencia de un procedimiento con otro.
La complejidad es como casi todo. Hay complejidad mala y hay complejidad buena. La complejidad mala es la que no controlamos, la que puede con nosotros. La complejidad buena es la que diseñamos y controlamos, de forma intencionada, para resolver algún problema.
En la construcción del software, la reducción de la complejidad se alcanza haciendo énfasis en la creación del código simple y legible en lugar de inteligente.
7 www.gruposeti.com/complejidad_sw.htm (20/04/2008).
La minimización de la complejidad se logra con hacer uso estándares y con técnicas específicas. A continuación se explicarán algunas de esas técnicas.
1.2.3 Técnicas para Minimizar la Complejidad.
1) El diseño Modular.- Desarrollo paralelo de las diferentes partes de un sistema; vamos que es ideal para el proceso de codificación abierta donde trabajan varias personas en un proyecto.
El Diseño Modular debe de estar basado en el principio de ocultamiento de la información, el cual sugiere que:
“Los módulos se han de caracterizar por decisiones de diseño que los oculten unos a otros; es decir, deben especificarse y diseñarse de forma que la información dentro de un módulo sea inaccesible a otros módulos que no necesitan tal información”. 8
Algunos aspectos importantes de la modulación son:
Reglas
Correspondencia directa.
Pocas interfaces.
Interfaces pequeñas.
Interfaces explicitas.
Ocultación de la información.
Criterios
Descomposición modular.
Composición modular.
Comprensibilidad modular.
Continuidad modular.
Protección modular.
8 Klir, G.J., Complejidad del Software Aspectos Generales, Prentice Hall, 3ª ed. México 2003, p. 132-133.
Principios
Unidades modulares lingüísticas.
Auto-documentación.
Acceso uniforme.
Principio de abierto-cerrado.
Elección única.9
2) La independencia Funcional de los Módulos.- La cual nace directamente de la modularidad, de la abstracción y ocultamiento de la información, esto se puede afirmar que se adquiere desarrollando módulos con una clara función y que no tengan excesiva interacción con otros módulos.
Se trata pues de diseñar software de forma que cada módulo se centre en una función específica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras partes de la estructura del software.
El software con independencia funcional es fácil de desarrollar porque su función puede ser divida y se simplifican las interfases (con las implicaciones que conlleva cuando el desarrollo es realizado por un equipo).
Los módulos independientes son fáciles de mantener y de probar ya que limitan los efectos secundarios, reduce la propagación de errores y fomenta la reusabilidad de código.
3) Cohesión.- Se puede definir como una medida de funcionalidad de un módulo; es una extensión del concepto de ocultamiento de información.
Un módulo sólo debe tener una función específica, en esto consiste la cohesión, básicamente se trata de evitar que los módulos sean solo una agrupación de líneas de código y debe de tender a que los procedimientos de dicho módulo se concentren en la función específica en el área de una estructura de datos para la que fue diseñado.
9 Pleeger. Ingeniería del Software: Teoría y práctica. Pearson Education.México 2003 pp.55.
Un principio para establecer el grado de cohesión nos dice:
“Escribir una frase que describa el propósito del módulo y examinarlo; si la frase no contiene un objeto específico sencillo a continuación del verbo lo más normal es que estemos en la banda baja de cohesión.” 10
4) Acoplamiento.- Es un grado de interdependencia relativa entre módulos, depende de la complejidad de las relaciones entre los mismos, del punto en el que se hace una llamada al módulo y de los datos que pasan a través del enlace o llamada. El objetivo es lograr una interrelación sencilla, es decir, acoplamiento bajo, más fácil de comprender y menos propenso a una cadena de errores a lo largo del sistema.
Como conclusión en este sentido minimizar la complejidad significa tener una cohesión alta y un acoplamiento bajo.
1.3 Prever el Cambio.
La mayoría de las aplicaciones cambia en un cierto plazo, y la anticipación al cambio maneja muchos aspectos de la construcción del software.
El software forma parte inevitablemente de los ambientes externos del cambio, y los cambios en esos ambientes externos afectan al software de maneras diversas.
El prever el cambio distingue al software de otros aspectos de la ingeniería. Se basa en el la propiedad de flexibilidad del software. La habilidad del software para evolucionar requiere de un esfuerzo adicional que implica anticipar cuándo y dónde se pueden requerir los cambios.
El principio de prevención del cambio se usa para alcanzar las cualidades de evolución y reusabilidad. Así como el principio de anticipo al cambio también se puede aplicar al proceso de Construcción.
10 Ibid.
Aspectos que se deben tomar en cuenta en la prevención del cambio:
Considerar alteraciones en el personal (Renuencia al cambio).
Considerar los recursos necesarios para mantenimiento (Capacitación).
Una definición del cambio en sentido estricto es:
“Una alteración del estado de una entidad (alguien o algo), siendo esta alteración generada por un proceso el cual ha sido disparado por el entorno en el cual se encuentra inmersa la entidad”.11
A continuación se dará una breve descripción de los tipos de cambio que se presentan en las aplicaciones actuales.
1.3.1 Tipos de Cambio.
Se reconocen Tres tipos de Cambio:
Cambio discreto.
Cambio continuo.
Cambio discontinuo.
1) Cambio Discreto:
Separación marcada entre un cambio y otro.
No hay “nada” entre los cambios.
Catastrófico por lo impredecible.
Figura No. 2.- Representación Gráfica del Cambio Discreto.
11 www.cyberferia.com/elcambio_sw.asp (10/06/2008)
Cambio Inicial (T0)
Cambio
Final (T1)
2) Cambio Continuo:
No hay separación entre cambios.
Surgen requerimientos entre los cambios.
Es predecible.
Figura No. 3.- Representación Gráfica del Cambio Continuo.
3) Cambio Discontinuo:
Depende de la escala de observación.
Se percibe de forma discreta y continua (discontinuo).
Figura No. 4.- Representación Gráfica del Cambio Discontinuo.12
1.3.2 Principios del Cambio.
Una manera de comprender la naturaleza del cambio nos la proporcionan los principios que mencionaremos a continuación:
Principio de Equivalencia entre Cambio y Proceso.- “El cambio define el proceso, y el proceso define el cambio. El cambio está organizado en procesos, siendo algunos de ellos visibles y otros no”.
122006- Tipos de Cambio (Archivo en formato PDF) Profesor: Sergio Fuenlabrada Velázquez.
Cambio Inicial (T0)
Cambio Final (T1)
T0 T1 T2 T3 T4 T5
Principio de Universalidad del Cambio.- “El cambio forma y opera el universo. El cambio puede ser perceptible o no”.
Principio de Escalamiento de la Operación del Cambio.- El cambio siempre opera a todas las posibles escalas existentes en el universo. Si el cambio es perceptible, ¿Qué lo origino?, ¿Cual es el final del cambio?.
Principio de las Fronteras del Cambio.- “En el universo, los procesos, y por lo tanto el cambio, no tienen ni principio ni final. El cambio en el universo carece de fronteras, esta depende de la escala de observación”.
Principio de Ocurrencia del Cambio.- “Un cambio ocurre en un momento específico. Si el estado no cambia con el tiempo, entonces el cambio no representa una ocurrencia”.
Principio de Origen del Cambio.- “Un cambio siempre es provocado por la “entidad sujeto”. Si el evento es generado por si mismo (entidad objeto), el evento no representa un cambio”.
Principio de Control del Cambio.- “La ocurrencia de un cambio está bajo control de la entidad sujeto y no de la entidad objeto”.
Principio de Percepción del Cambio.- “La entidad objeto debe ser capaz de percibir que el cambio ocurrió. Si la entidad objeto no percibe el cambio, entonces no representa un cambio”.
Principio de Alteración del Estado y del Comportamiento.- “Una vez detectado el cambio por la “entidad objeto”, ésta altera su estado original y por lo tanto su comportamiento. Si la entidad objeto percibe el cambio, pero no hace nada, entonces no representa un cambio”.13
13 Ibid.
Basados en los principios descritos anteriormente, se ha generado un modelo prototipo que vale la pena considerar, este consta de los siguientes pasos:
1.- Determinar los síntomas que presenta la “entidad objeto” cuando una
“entidad sujeto” provoca el cambio.
2.- Determinar si la organización y estructura de la “entidad objeto” es lo suficientemente robusta para soportar el cambio.
3. - Determinar las acciones para reducir el impacto.
Este Modelo se traduce en:
1.3.3 Problemas del Cambio.
El cambio siempre provoca algún tipo de problema, sobre todo cuando no se tiene una buena documentación de las aplicaciones desarrolladas, ya que no se conoce el funcionamiento total ni la dependencia que puedan tener los módulos, por lo tanto, el impacto puede ser mayor al esperado como consecuencia de no conocer el alcance de las modificaciones a realizar.
Como consecuencia, el cambio puede provocar un deterioro en el diseño del software, aquí influyen dos aspectos:
1) Requisitos Cambiantes:
Esta causa del deterioro es muy común. Los requerimientos cambian de forma por demás significativa de manera que no estaba previsto en el diseño inicial.
A menudo los cambios necesitan hacerse rápidamente y tienen que hacerse por programadores que no están familiarizados con el diseño original.
Entonces, aunque los cambios funcionan, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe.
Pensamiento Sistemático + Datos + Información + Conocimiento
Aún así no se puede echar la culpa a que los requisitos cambian. Como desarrolladores, se debe de tener conocimiento de que los requisitos van a cambiar. Así que se tiene que realizar un diseño que soporte modificaciones sin que este pierda su consistencia.
2) Control de Dependencias:
¿Qué tipos de cambios hacen que un diseño se degrade? Los cambios que introducen nuevas e imprevistas dependencias, y son estas dependencias de la arquitectura las que se degradan y con ellas el mantenimiento del software.
Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas estas mismas por módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan.
El diseño orientado a objetos está repleto de principios y técnicas que nos permiten construir estos cortafuegos y controlar estas dependencias. 14
Otros aspectos poco comunes pero que también generan cambios pueden ser:
Reorganización y/o reducción del volumen comercial que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software.
Restricciones presupuestarias o de planificaciones que provocan una redefinición del sistema o del producto. 15
1.3.4 Metodología Para la Prevención de Cambios.
Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente.
14 Effy Oz, Administración de sistemas de información, 2da ed. Thomson Learning 2001.
15 www.als-es.com/home.php/ingenieria-software_prevencion_cambio (30/05/2008).
Las actividades de esta metodología sirven para:
Identificar el cambio del software.
Controlar ese cambio.
Garantizar que el cambio quede bien implantado.
Informar el cambio.
La Metodología de Prevención de cambios comprende 4 pasos:
Especificación de Líneas Base.
Identificación de Objetos.
Control de Versiones.
Control de Cambios.
A continuación se detallará cada uno de estos pasos:
1.3.4.1 Especificación de Líneas Base.
Una línea base es un concepto de gestión de configuración del software que nos ayuda a controlar los cambios sin impedir seriamente los cambios justificados.
La IEEE define una línea base como:
“Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios”.16
En el contexto de la ingeniería del software se define una línea base como un punto de referencia en el desarrollo del software y que queda marcado por el envío de uno o más elementos de configuración del software y la aprobación de esta mediante una revisión técnica formal.
16 A. Toval. Ingeniería del Software. Gestión de Requisitos, ed. DM, España, 1999.
Por ejemplo, los elementos de una especificación de diseño se documentan y se revisan. Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se han revisado corregido y aprobado, la especificación de diseño se convierte en línea base. Solo se pueden realizar cambios futuros en la arquitectura del software, tras haber sido evaluados y aprobados. Las líneas base más comunes son las que se muestran en la Figura No. 5.
Figura No. 5.- Líneas base.17 1.3.4.2 Identificación de Objetos.
Se pueden identificar dos tipos de objetos, los objetos básicos y los objetos compuestos. Un objeto básico es una unidad de texto creada durante el análisis, diseño, codificación o prueba. Un objeto compuesto es una colección de objetos básicos u objetos compuestos. Cada objeto tiene un conjunto de características que los identifican como únicos. El nombre del objeto es una cadena de caracteres que identifica al objeto sin ambigüedad. El esquema de identificación de los objetos de software debe tener en cuenta que los objetos evolucionan a lo largo del proceso de ingeniería, por lo que se puede crear un grafo de evolución como se muestra en la Figura No. 6.
17 www.itil.osiatis.es/gestion_de_cambios/proceso_gestion_de_cambios.php (11/06/2008).
Ingeniería del Sistema
Análisis de Requerimientos
Diseño del Sistema
Codificación
Pruebas
Sistema en Funcionamiento
Figura No. 6.- Grafo de Evolución.18
En el grafo de evolución se describe la historia del objeto y sus cambios, las grandes modificaciones hacen que un objeto cambie, por lo que cambia el número de versión principal.
1.3.4.3 Control de Versiones.
El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software. Esto permite al usuario especificar configuraciones alternativas de un sistema mediante la selección de las versiones adecuadas.
Esto se puede lograr asociando atributos a cada versión del software y permitiendo luego especificar y construir una configuración describiendo el conjunto de atributos deseado.
Estos atributos pueden ser tan sencillos como un número específico de versión asociado a cada objeto o tan complejos como una cadena de variables lógicas que especifiquen tipos de cambios funcionales aplicados al sistema.
18 Ibid.
Figura No. 7.-Versiones y Variantes.
Otra forma de establecer los conceptos de la relación entre componentes, variantes y versiones es representarlas como un fondo de objetos.
Figura No. 8.- Representación de objetos, componentes, variantes y versiones.19
19 Ibid.
La principal diferencia entre los distintos está en la mejora de los atributos que se usan para construir versiones y variantes específicas de un sistema y en la mecánica del proceso de construcción.
1.3.4.4 Control Estricto de Cambios.
En un gran proyecto de desarrollo de software, el cambio incontrolado lleva rápidamente al caos. El control de cambios combina los procedimientos humanos y las herramientas automáticas para proporcionar un mecanismo para el control de cambio.
Figura No. 9.- Proceso de Control de Cambios.
Para cada cambio aprobado se genera una orden de cambio de ingeniería (OCI).La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoría. 20
El objeto a cambiar es "dado de baja" de la base de datos del proyecto y se realiza el cambio. Luego, el objeto es "dado de alta" en la base de datos y se usan los mecanismos de de control de versiones apropiadas para crear la siguiente versión del software.
Los procedimientos de altas y bajas implementan dos elementos importantes del control de cambios: control de acceso y sincronía. El control de acceso provee los derechos de los ingenieros de software a acceder y modificar objetos. El control de sincronía asegura que los cambios en paralelo, realizados por personas diferentes, no se sobrescriben mutuamente.
Figura No. 10.- Control de Acceso y de Sincronía.
20 Stair M Ralphm. Principios de sistemas de información,. Thomson Learning 4 Ed 2002.
Antes de que un elemento de configuración se convierta en una línea base, sólo es necesario aplicar un control de cambios informal. El que haya desarrollado el elemento en cuestión podrá hacer cualquier cambio justificado por el proyecto y por los requisitos técnicos.
Una vez que el objeto ha pasado la revisión técnica formal y ha sido aprobada, se crea la línea base.
Una vez que el elemento se convierte en una línea base, aparece el control de cambios a nivel de proyecto. 21
Para hacer un cambio, el encargado del desarrollo debe recibir la aprobación del gestor del proyecto (si el cambio es local), o de la Autoridad de Control de Cambios (ACC) si el cambio impacta en otros elementos.
La autoridad de control de cambios (ACC) desempeña un papel activo en el segundo y tercer nivel de control. El papel de la ACC es el de tener una visión general, o sea, evaluar el impacto del cambio fuera del elemento en cuestión.
Todo esto se traduce en los siguientes cuestionamientos:
¿Cómo impactará el cambio en el hardware? .
¿Cómo impactará en el rendimiento?.
¿Cómo alterará el cambio la percepción del cliente sobre el producto?. 22
1.4 Construcción para la Verificación.
La construcción para la verificación significa diseñar el software de tal modo que las fallas puedan ser detectadas fácilmente por los ingenieros y desarrolladores de software, esto se realiza mediante pruebas unitarias y simulación de las actividades operativas del cliente.
21 Ibid.
22 Ibid.
Las técnicas específicas que apoyan la construcción para la verificación incluyen estándares en la redacción del código para apoyar sus respectivas revisiones, pruebas de unidad, pruebas automatizadas, y el empleo restringido de estructuras complejas o lenguaje difícil de entender entre otros.
La construcción para verificación tiene dos tareas:
Validación.- Comprobar que el modelo se construyó según la hipótesis planteada.
Verificación.-Comprobar la consistencia de dicho modelo.
La validación nos permite comprobar que se cumplen las especificaciones del usuario y la verificación nos asegura la corrección del sistema.
En pocas palabras, la validación nos permite hacer pruebas si el modelo que se ha construido de acuerdo a los estándares establecidos, pero no se comprueba el funcionamiento, es por ello que se dice que la validación es empírica.
La verificación toma los resultados de la validación para realizar las pruebas necesarias para concluir si la construcción del software cumple con las necesidades del cliente y realiza las funciones que debe ejecutar, es por ello que la verificación es deductiva.
1.4.1 Model Checking (Comprobación de Modelos).
La comprobación de modelos (model checking) se define como:
“Una aproximación específica para la verificación eficiente de propiedades de sistemas concurrentes y reactivos que tiene especial aplicación en el área de los sistemas de estados finitos. Este tipo de técnicas son, pues, especialmente adecuadas para abordar los problemas planteados por los sistemas anteriormente mencionados”.23
23 BOOCH, Grady. Lenguaje Unificado de Modelado. Mc Graw Hill. Año 2000. pp. 464.
La verificación de la corrección de un sistema de software puede verse oportunamente acompañada por el intento de corregir cualquier posible anomalía detectada.
Las técnicas de depuración de programas permiten detectar las causas que introducen discrepancias entre el comportamiento real y el comportamiento que se espera de un programa ayudando a corregir, en su caso, las inconsistencias encontradas (mediante técnicas de aprendizaje inductivo de programas).
Puesto que tanto la verificación como la depuración de programas necesitan considerar algún tipo de representación de lenguaje máquina de la semántica de los sistemas considerados, la interpretación abstracta, que permite diseñar, aproximar y comparar semánticas de programas que expresan varios tipos de propiedades observables resulta ser un recurso fundamental que se puede añadir a las técnicas de verificación y depuración.
En la interpretación abstracta pueden inferirse propiedades que pueden usarse para implantar condiciones de seguridad, además del uso tradicional que se hace en los compiladores para optimizar el código generado estáticamente. Por supuesto, existen muchas similitudes entre todas estas técnicas en cuanto a sus objetivos y dominios de aplicación.
Con la creciente necesidad de métodos formales ágiles para el desarrollo correcto de software cada vez más complejo (sistemas abiertos, con un número infinito de estados y/o funciones), cobran especial relevancia los métodos híbridos que combinan las distintas técnicas.
Aquí se describirá el desarrollo del Model Checking como técnicas de verificación y depuración que combinan la mejora algorítmica, la síntesis de programas, el análisis estático basado en la interpretación abstracta.
El Model Checking permite comprobar si un modelo dado satisface una determinada propiedad. Esta técnica se puede aplicar tanto a sistemas reactivos como a sistemas híbridos. Existen paradigmas declarativos muy adecuados para la especificación de estas dos clases de sistemas.
Tanto los sistemas reactivos como los sistemas híbridos están muy relacionados con la noción de concurrencia por lo que resultan muy complicados de verificar a mano. Por este motivo es importante disponer de algoritmos de Model Checking para estos paradigmas. 24
Figura No. 11.- Algoritmo de Model Checking.25
1.4.2 Interpretación Abstracta.
La teoría de la Interpretación Abstracta puede ser utilizada para mejorar y optimizar la técnica de Model Checking. Usando esta técnica es posible verificar sistemas con un gran espacio de estados de una forma eficaz. 26
24www.dc.uba.ar/materias/valsof/view (19/07/2008).
25 www.fceia.unr.edu.ar/ingsoft/unidad21-4.pdf (19/07/2008).
26 SOMMERVILLE, Lan. Ingeniería de Software. Mc Graw Hill. 2006. pp 692.
El Model checking se considera un método automático de verificación de un sistema formal, en la mayoría de las ocasiones derivado del hardware o del software de un sistema informático.
El sistema es descrito mediante un modelo, que debe satisfacer una especificación formal descrita mediante una fórmula, a menudo escrita en alguna variedad de lógica temporal. Este modelo suele estar expresado como un sistema de cambios, es decir, un grafo dirigido, que consta de un conjunto de vértices y arcos.
Así pues, los nodos representan los estados posibles de un sistema, los arcos posibles evoluciones del mismo, mediante ejecuciones permitidas, que alteran el estado, mientras que las proposiciones representan las propiedades básicas que se satisfacen en cada punto de la ejecución.
Existen herramientas automáticas para realizar el Model checking, basadas en técnicas combinatorias, explorando el espacio de estados posibles; lo que conduce al problema de explosión de estados.
Para evitarlo, diversos investigadores han desarrollado técnicas basadas en algoritmos simbólicos, abstracción, reducción de orden parcial y model checking al vuelo. Inicialmente, las herramientas se diseñaron para trabajar con sistemas discretos, pero han sido extendidas a sistemas de tiempo real, o sistemas híbridos.
Existen 2 técnicas que podrían ayudar a comprobar el funcionamiento del software:
Técnicas Estáticas.- Usadas para comprobar la correspondencia entre el software desarrollado y las especificaciones.
Verificación de Modelos.- Técnica automática para verificar sistemas modelados y especificados con fórmulas de una lógica temporal. 27
27 Ibid
Figura No. 12.- Diagrama de Verificación.
1.4.2.1 Testing estructural.
Aquí se utiliza la información sobre la estructura interna del programa basada en la interpretación abstracta. Se prueba lo que el programa hace, indicando de forma genérica un subconjunto de caminos a recorrer. Puede automatizarse en gran medida, pero requiere que haya finalizado la fase de codificación para que pueda empezarse a probar. Si se cambia la estructura del código deben recalcularse los casos.
Figura No. 13.- El ciclo del Testing.28
28 www.dc.exa.unrc.edu.ar/nuevodc/materias/verificación (25/05/2008).
Ingeniería de Requerimientos
Plan De Validación
Plan de Verificación e
Integración
Plan de Verificación de
Componentes
Validación
Verificación e Integración
Verificación de Componentes Arquitectura Especificación
de Módulos
Diseño Detallado
Comprobación Especificación
Casos de Prueba a nivel de Especificación Resultados a
nivel de Especificación
Resultados a nivel de Implementación
Casos de Prueba a nivel de Implementación
Implementación
Refinamiento Extracción Sustitución
Abstracción
Ejecución Ejecución
1.5 Estándares en la Construcción.
1) Uso - Contexto del producto:
ISO/IEC 9126-1: Ingeniería de Software - Modelos de calidad.
ISO/IEC TR 9126-4: Ingeniería de software - Calidad en métricas de uso.
ISO 9241-11: Guías en Usabilidad.
ISO 20282: Usabilidad en productos de cada día.
2) Interfaz:
ISO/IEC TR 9126-2: Ingeniería de software-Métricas externas.
ISO 9241: Requerimientos para trabajo en oficinas.
ISO/IEC TR 9126-3: Ingeniería de software-Métricas internas.
ISO/IEC 10741-1: Interacción de Diálogo - Control en edición de textos.
ISO/IEC 11581: Iconos, símbolos y funciones.
ISO 11064: Diseño ergonómico para centros de control.
ISO 13406: Requisitos ergonómicos de trabajo de paneles planos.
ISO 14915: Ergonomía de software para interfaz multimedia.
ISO/IEC 14754: Interfaz de escritura manual.
3) Interacción:
IEC TR 61997: Guías de interfaz de usuario en equipos de uso general.
ISO/IEC 18021: Interfaz de usuario para dispositivos móviles.
ISO 18789: Requerimientos y sistemas métricos para pantallas.
4) Documentación:
ISO/IEC 18019: Guías para diseño y preparación de documentación.
ISO/IEC 15910: Documentación de procesos de software de usuario.
5) Proceso de desarrollo:
ISO 13407: Diseño de procesos interactivos.
ISO/IEC 14598: Evaluación de software.
ISO TR 16982: Métodos de soporte de diseños centrados en usuarios.
6) Capacitación de la empresa:
ISO TR 18529: Procesos descriptivos de vida de producto (lifecycle) .
7) Otros ISO:
ISO 9241-1: Introducción general.
ISO 9241-2: Guía en requisitos de acciones.
ISO 10075-1: Principios de carga mental, términos y definiciones.
ISO DTS 16071: Guía de accesibilidad en interfaz de usuario.29
29 www.es.wikipedia.org/wiki/Categoría:Formatos_y_estándares_de_software (19/08/2008).
CAPÍTULO II
ADMINISTRACIÓN DE LA CONSTRUCCIÓN DEL SOFTWARE
La Administración de la construcción comienza con la elección de un modelo de ciclo de vida, el cual define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. La Administración en la construcción del Software se basa primordialmente en la consecución de un objetivo mediante una secuencia de pasos, esta secuencia es proporcionada por un esquema ya definido y estandarizado, este esquema es comúnmente llamado Modelo de Construcción (Ciclo de Vida) del software.
Reseña Histórica.
A fines de los 70’s se definió como tal el primer modelo de ciclo de vida de software (modelo de cascada), Winston Royce es el autor de este primer modelo. Desde entonces muchos equipos de desarrollo habían seguido esta metodología.
Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. Es por ello que actualmente, existe una gama muy basta de Modelos de Construcción de software adaptables a las necesidades de cada proyecto.
Un Modelo de Ciclo de Vida de Software se puede definir como:
“Una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.”30
30 Lawrence, S..Ingeniería del software. Ed. Prentice-Hall, México. 2002.
Características:
Describe las fases o etapas principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo.
Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
De esta manera, los modelos de construcción proporcionan una guía para los ingenieros y desarrolladores de software con el fin de ordenar las diversas actividades técnicas en el proyecto, en este sentido suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
2.1 Modelos de Construcción Tradicionales.
2.1.1 Modelo Cascada.
El modelo Cascada es el que ha servido como base en la construcción de los modelos recientes, y sirve como bloque de construcción para los demás modelos de construcción. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases.
Cada fase tiene un conjunto de actividades y objetivos bien definidos, en donde las actividades dentro de cada fase contribuyen a la satisfacción de los objetivos trazados de dicha fase.
La Figura No. 14 muestra gráficamente el flujo de cada una de las fases del modelo en cascada. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.
Figura No. 14.- Modelo de Cascada.31
El modelo de ciclo de vida cascada, proporciona algunos principios básicos:
Planear un proyecto antes de establecer un compromiso con el mismo.
Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
Documentar los resultados de cada actividad.
Diseñar un sistema antes de codificarlo.
Evaluar un sistema después de construirlo.
2.1.2 Modelo De Desarrollo Incremental.
El desarrollo incremental es el proceso de construcción que consiste en incrementar nuevas especificaciones de requerimientos al diseño del sistema original.
Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Sin embargo, este modelo permite agregar nuevas funcionalidades interdependientes a las ya hechas.
31 www.es.wikipedia.org/wiki/Modelo_de_cascada (11/09/2008).
El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos de desarrollo de software:
Construir sistemas pequeños.
Si un error importante es detectado, sólo el último cambio realizado necesita ser descartado, es decir, la versión anterior a los últimos cambios es la que puede ser utilizada.
Reducción del tiempo de desarrollo, lo cual evita la redefinición del requerimiento.
Los errores de desarrollo cometidos en un incremento o cambio, pueden ser arreglados antes del comienzo del próximo incremento.
La Figura No. 15 nos muestra la arquitectura del modelo de Desarrollo Incremental, el cual podemos visualizar como una especie de Modelo Estrella.
Figura No. 15.- Modelo de Desarrollo Incremental.32
32 www.es.wikipedia.org/wiki/Modelo_de_desarrollo_incremental (12/11/2008).
2.1.3 Modelo De Desarrollo Evolutivo.
Al igual que el modelo de desarrollo incremental, el modelo de desarrollo evolutivo construye una serie de grandes versiones sucesivas de un producto.
Sin embargo, mientras que el modelo de desarrollo incremental asume que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo aquellos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del software que recibe sólo estos requerimientos.
El software es entonces desarrollado, se realizan pruebas con la ayuda de los usuarios para proveer retroalimentación a los desarrolladores. De esta manera la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada. El proceso se repite tantas veces como se necesite cambiar las reglas o procesos del sistema.
Todo lo que los líderes de proyecto tienen que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de prueba, etc. desarrollados para distintas versiones del software.
Figura No. 16.- Modelo de Desarrollo Evolutivo.33
2.1.4 Modelo de Prototipado de Requerimientos.
El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema definidos por los usuarios. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo.
Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, es entonces cuando se captura en la documentación actual de la especificación de requerimientos la nueva información entregada por los usuarios para el desarrollo ideal del software.
Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basada en la manipulación, desde un prototipo, en vez de leer una especificación de requerimientos potencialmente ambigua y extensa.
A diferencia del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
33 www.es.wikipedia.org/wiki/Modelo_de_desarrollo_evolutivo (12/11/2008).
En caso de que se desarrollen requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.
El Prototipado de Requerimientos es compatible con el Modelo de Cascada (Figura No.17).
Figura No. 17.- Prototipado de Requerimientos Basado en el Modelo de Cascada.34
Sin Embargo, el Modelo de Prototipado de Requerimientos también es funcional con el Modelo de Desarrollo Evolutivo, de hecho, en combinación con este, alcanza su mayor grado de funcionalidad (Figura 18).
34www.es.wikipedia.org/wiki/Modelo_de_prototipado (12/11/2008)