Embed Size (px)
Citation preview
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.1 ESCENARIO PARA LA CONSTRUCCIÓN DEL SOFTWARE. ..................................... 2 1.2 MINIMIZAR LA COMPLEJIDAD. .......................................................................... 4
1.2.1 PROPIEDADES DE LA COMPLEJIDAD. ......................................................... 5 1.2.2 CONSECUENCIAS DE LA COMPLEJIDAD ILIMITADA. ...................................... 7 1.2.3 TÉCNICAS PARA MINIMIZAR LA COMPLEJIDAD. ........................................... 8
1.3 PREVER EL CAMBIO. ..................................................................................... 10
1.3.1 TIPOS DE CAMBIO. ................................................................................ 11 1.3.2 PRINCIPIOS DEL CAMBIO........................................................................ 12 1.3.3 PROBLEMAS DEL CAMBIO. ..................................................................... 14 1.3.4 METODOLOGÍ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.4 CONSTRUCCIÓN PARA LA VERIFICACIÓN. ........................................................ 22
1.4.1 MODEL CHECKING (COMPROBACIÓN DE MODELOS). ................................ 23 1.4.2 INTERPRETACIÓN ABSTRACTA. ............................................................... 25
1.4.2.1 Testing estructural................................................................... 27 1.5 ESTÁNDARES EN LA CONSTRUCCIÓN. ............................................................. 28
CAPÍTULO II
ADMINISTRACIÓN DE LA CONSTRUCCIÓN DEL SOFTWARE
2.1 MODELOS DE CONSTRUCCIÓN TRADICIONALES. .............................................. 31 2.1.1 MODELO CASCADA. .............................................................................. 31 2.1.2 MODELO DE DESARROLLO INCREMENTAL. .............................................. 32 2.1.3 MODELO DE DESARROLLO EVOLUTIVO. .................................................. 34 2.1.4 MODELO DE PROTOTIPADO DE REQUERIMIENTOS. ................................... 35 2.1.5 MODELO ESPIRAL. ................................................................................ 37 2.1.6 MODELO CONCURRENTE. ...................................................................... 39
2.2 METODOLOGÍAS DE CONSTRUCCIÓN EN LA ACTUALIDAD. ................................ 40 2.2.1 METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS- PROCESO UNIFICADO
RACIONAL). ........................................................................................................ 41 2.2.2 METODOLOGÍA ASML (A SYSTEM 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.3 METODOLOGÍA CASE (COMPUTER AIDED SYSTEMS ENGINEERING). ........ 47 2.2.4 METODOLOGÍA XP (EXTREME PROGRAMING). ......................................... 49 2.2.5 METODOLOGÍA MSF (MICROSOFT SOLUTION FRAMEWORK). .................... 51 2.2.6 SELECCIONANDO MODELOS DE CONSTRUCCIÓN. .................................... 53
2.3 PLANIFICACIÓN DE LA CONSTRUCCIÓN. .......................................................... 55
2.3.1 OBJETIVOS DE LA PLANIFICACIÓN. .......................................................... 57 2.3.2 ASPECTOS ASOCIADOS AL PROYECTO. ................................................... 57 2.3.3 MODELOS DE ESTIMACIÓN. .................................................................... 61
2.4 MEDICIÓN DE LA CONSTRUCCIÓN. .................................................................. 62
2.4.1 ARQUITECTURA DE UN PROCESO DE MEDIDA DE SOFTWARE. .................... 65 2.4.2 MODELO DE PROCESO PARA LA DEFINICIÓN DE MEDIDAS DE SOFTWARE. .. 67
CAPÍTULO III
CONSIDERACIONES PRÁCTICAS 3.1 DISEÑO DE LA CONSTRUCCIÓN. ..................................................................... 71
3.1.1 TÉCNICAS DE DISEÑO. .......................................................................... 71 3.1.2 DISEÑO DE INTERACCIONES CON LA BASE DE DATOS. .............................. 72 3.1.3 DISEÑO DE ARCHIVOS. .......................................................................... 73 3.1.4 DISEÑO DE LA SALIDA. .......................................................................... 73
3.2 LENGUAJES DE CONSTRUCCIÓN. .................................................................... 74
3.2.1 CARACTERÍSTICAS. ............................................................................... 74 3.2.2 PARADIGMAS. ....................................................................................... 75
3.2.2.1 Clasificación de Paradigmas. .................................................. 76 3.2.3 FACTORES EN LA ELECCIÓN DE UN LENGUAJE DE CONSTRUCCIÓN. ........... 77 3.2.4 CLASIFICACIÓN DE LOS LENGUAJES DE CONSTRUCCIÓN. .......................... 78 3.2.5 VISUAL STUDIO.NET VS C#. ................................................................. 80
3.2.5.1 Visual Studio.NET. .................................................................. 80 3.2.5.2 Lenguaje C#. ........................................................................... 81
3.3 CODIFICACIÓN. ............................................................................................. 83
3.3.1 ESTÁNDARES DE CODIFICACIÓN. ............................................................ 84 3.3.2 TÉ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.4 PRUEBA DE CONSTRUCCIÓN. ......................................................................... 90 3.4.1 MÓDULOS INDEPENDIENTES. .................................................................. 92 3.4.2 PRUEBAS DE CARGA Y RENDIMIENTO. ..................................................... 92 3.4.3 SUBCONTRATACIÓN DE PRUEBAS. .......................................................... 93
3.5 REUSABILIDAD. ............................................................................................. 94
3.5.1 BENEFICIOS DE LA REUSABILIDAD. ......................................................... 94 3.5.2 FACTORES DE LA REUSABILIDAD. ........................................................... 96 3.5.3 NIVELES DE REUSABILIDAD. ................................................................... 97 3.5.4 REUSABILIDAD ORIENTADA A OBJETOS. .................................................. 98 3.5.4.1 BIBLIOTECAS 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.6 CALIDAD EN LA CONSTRUCCIÓN................................................................... 108
3.6.1 PRINCIPIOS BÁSICOS DE CALIDAD. ....................................................... 109 3.6.2 CONTROL DE CALIDAD. ....................................................................... 110
3.6.2.1 Gestión de Calidad................................................................ 111 3.6.2.2 Niveles de Calidad. ............................................................... 113
3.7 LA INTEGRACIÓN. ....................................................................................... 116
3.7.1 CARACTERÍSTICAS. ............................................................................. 118
CONCLUSIONES .......................................................................................... 119
BIBLIOGRAFÍA ............................................................................................. 121
I
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.
II
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
III
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.
IV
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.
V
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.
1
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.
2
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).
3
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).
4
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
5
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.
6
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.
7
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).
8
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.
9
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.
10
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.
11
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)
12
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”.
12 2006- Tipos de Cambio (Archivo en formato PDF) Profesor: Sergio Fuenlabrada Velázquez.
Cambio
Inicial (T0)
Cambio
Final (T1)
T0 T1 T2 T3 T4 T5
13
� 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.
14
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
15
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).
16
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.
17
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
18
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.
19
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.
20
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.
21
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.
22
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.
23
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.
24
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.
25
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
24 www.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.
26
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
27
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
28
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.
29
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).
30
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.
31
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.
32
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).
33
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).
34
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.
35
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).
36
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).
34 www.es.wikipedia.org/wiki/Modelo_de_prototipado (12/11/2008)
37
Figura No. 18.- Prototipado de Requerimientos Basado en el Modelo de Desarrollo Evolutivo.35
2.1.5 Modelo Espiral.
Es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo
es repetitivo. Tan pronto como uno completa un esfuerzo de desarrollo, otro
comienza.
El Modelo Espiral define los siguientes objetivos:
� Determinar qué es lo que se quiere lograr.
� Determinar las rutas alternativas, analizar los riesgos y resultados finales
de cada una, y seleccionar la mejor.
� Implementar la alternativa seleccionada en el paso 2.
� Establecer qué es lo que se logró y evaluar los resultados obtenidos.
Durante el primer viaje alrededor de la espiral, se analiza la situación y se
determina que los mayores riesgos son la interfaz con el usuario. Después de
un cuidadoso análisis de las formas alternativas de solucionar el problema,
dichas alternativas pueden ser:
� Construir un sistema y esperar lo mejor.
� Escribir una especificación de requerimientos.
� Construir un prototipo.
35 Ibid.
38
Se lleva a cabo dicha alternativa. Luego se muestra el prototipo al cliente quien
provee con retroalimentación útil. Ahora, se comienza el segundo viaje
alrededor de la espiral. Es entonces cuando se comienza nuevamente a
analizar las rutas alternativas, llegando a la conclusión de que la mejor es
construir un incremento u opción alterna del sistema que satisfaga sólo los
requerimientos mejor entendidos. Nuevamente se lleva a cabo dicha
alternativa.
Después del despliegue, el cliente proveerá nuevamente de retroalimentación
que dirá si los requerimientos son correctos. El tercer viaje alrededor de la
espiral comienza.
En la Figura No. 19 se observa gráficamente el Modelo Espiral
Figura No. 19.- Modelo Espiral.36
36 www.es.wikipedia.org/wiki/Modelo_de_Espiral (12/11/2008).
39
2.1.6 Modelo Concurrente.
La contribución del modelo concurrente es su capacidad de describir las
múltiples actividades del software ocurriendo simultáneamente. Los
requerimientos son usualmente "líneas base", cuando la mayoría de estos
comienzan a ser bien entendidos, se dedica un esfuerzo considerable en el
tema de diseño. Una vez que comienza el diseño, cambios a los requerimientos
son comunes y frecuentes.
Pero no se debe detener el diseño cuando los requerimientos cambian; existe
una necesidad de modificar y rehacer las especificaciones de los
requerimientos mientras progresa el diseño. Dependiendo del impacto de los
cambios de los requerimientos el diseño puede no ser afectado, medianamente
afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de la arquitectura, es posible que algunos componentes ya
se hayan definido antes que la arquitectura completa sea estabilizada. Por lo
cual no necesiten reestructurarse dependiendo si se ve afectada la
infraestructura planteada en un inicio.
En tales casos, puede ser posible comenzar el diseño detallado en esos
componentes estables. En esta etapa, puede ser posible empezar la
codificación y quizás establecer una evaluación de integridad de manera
genérica antes de llevar a cabo el diseño detallado de todos los componentes.
En algunos proyectos, las etapas de un producto se pueden desarrollar
concurrentemente. No es inusual dar mantenimiento a la etapa 1 de un
producto, y al mismo tiempo dar mantenimiento a un componente 2, mientras
que se está haciendo codificación al componente 3, mientras se realiza diseño
sobre una etapa 4, y especificación de requisitos sobre un componente 5.
40
En todos estos casos, diversas actividades están ocurriendo simultáneamente.
Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se
posibilita el conocimiento del estado verdadero en el que se encuentra el
proyecto. 37
2.2 Metodologías de Construcción en la Actualidad.
En la actualidad existen nuevas metodologías que permiten hacer un análisis y
diseño estructurado muy eficiente, entre las más importantes están las
siguientes:
� Metodología RUP.
� Metodología ASML.
� Metodología CASE.
� Metodología XP.
� Metodología MSF.
Hablando en este sentido, cuando los proyectos que se van a desarrollar son
de mayor complejidad, ahí si toma sentido el basarnos en una de estas
metodologías de desarrollo, y empezamos a buscar cual sería la más
apropiada para nuestro caso.
Lo cierto es que muchas veces no encontramos la más adecuada y terminamos
por hacer o diseñar nuestra propia metodología, algo que por supuesto no esta
mal, siempre y cuando cumpla con el objetivo.
Al realizar el diseño del software de manera rígida, cuando el cliente en la
etapa final solicita un cambio, resulta muy difícil realizarlo, pues se alteran
muchas cosas que no habíamos previsto, y es justo éste, uno de los factores
que ocasiona un atraso en el proyecto y por tanto la incomodidad del
desarrollador por no cumplir con el cambio solicitado y el malestar por parte del
cliente por no tomar en cuenta su pedido.
37 www.soloarquitectura.com/software (25/11/2008).
41
Obviamente para evitar estos incidentes debemos haber llegado a un acuerdo
formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o
modificación no perjudique al desarrollo del mismo.
A continuación se explicará el uso de estas nuevas metodologías para dar a
conocer las diferencias entre ellas y así tener una información adecuada en
caso de que necesitemos de una de ellas en el desarrollo de un proyecto, de
esta manera podremos elegir la que más se adapte a nuestras necesidades.
2.2.1 Metodología RUP (Rational Unified Process- Proceso Unificado
Racional).
La Metodología RUP, llamada así por sus siglas en inglés Rational Unified
Process, divide en 4 fases el desarrollo del software:
� Inicio.- El Objetivo en esta etapa es determinar la visión del proyecto.
� Elaboración.- El objetivo es determinar la arquitectura óptima.
� Construcción.- Desarrollar la capacidad operacional inicial.
� Transición.- El objetivo es llegar a obtener el release del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la
cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los
Objetivos de una iteración se establecen en función de la evaluación de las
iteraciones precedentes.
La Metodología RUP aplica 2 Disciplinas:
1) Disciplina de Desarrollo.- Contiene las siguientes características:
� Ingeniería de Negocios: Entendiendo las necesidades del negocio.
� Requerimientos: Formalizar las necesidades del negocio.
� Diseño: Traslado de los requerimientos a una arquitectura de software.
� Implementación: Creando software que se ajuste a la arquitectura.
� Pruebas: Asegurándose que el comportamiento requerido es el correcto.
42
2) Disciplina de Soporte.- Contiene las siguientes características:
� Administración del cambio: Guardando todas las versiones del proyecto.
� Administrando el proyecto: Administrando horarios y recursos.
� Ambiente: Administrando el ambiente de desarrollo.
� Distribución: Hacer todo lo necesario para la salida del proyecto.
La Figura No. 20 nos proporciona una panorámica de la Metodología RUP:
Figura No. 20.- Fases e Iteraciones de la Metodología RUP.
Cada una de estas iteraciones se debe clasificar y ordenar según su prioridad,
y que cada una se convierte luego en un entregable al cliente.
Los elementos del RUP son:
� Actividades.- Procesos que se llegan a determinar en cada iteración.
� Trabajadores.- Personas o entes involucrados en cada proceso.
� Artefactos.- Documento, un modelo, o un elemento de modelo.
43
Una particularidad de esta metodología es que, en cada ciclo de iteración, se
hace exigente el uso de artefactos, siendo por este motivo, una de las
metodologías más importantes para alcanzar un grado de certificación en el
desarrollo del software.
La Metodología RUP es más adaptable para proyectos de largo plazo. 38
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado).
ASML es una metodología que integra todas las ideas involucradas en el
análisis y diseño estructurado. Involucra las técnicas y herramientas de
modelado usadas en el Análisis y Diseño Estructurado Moderno.
Los objetivos fundamentales que busca la Metodología ASML son:
� Obtener una buena comprensión del problema.
� Diseñar una solución de buena calidad.
La Metodología ASML separa el diseño de un sistema en una jerarquía de
modelos necesarios para comprender diferentes propiedades del mismo.
38 www.manycomics.com/ingenieria_software/modelos_actuales (11/10/2008).
44
Dicha jerarquía de modelos se presenta en la siguiente figura:
Figura No. 21.- Jerarquía de la Metodología ASML.39
Como podemos observar, el Modelo del Sistema está dividido en dos modelos
generales:
� El Modelo Esencial.
� El Modelo de Implementación.
�
2.2.2.1 El Modelo Esencial.
Representa la etapa de Análisis Estructurado. Construcción de un modelo libre
de detalles tecnológicos. Es la aplicación de la metodología de Análisis
Estructurado Moderno de Yourdon.
39 www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html (11/10/2008).
Modelo Esencial
Modelo del Sistema
Modelo de
Implementación
Modelo del Usuario
Modelo de Distribución
Modelo de Programa
Modelo de Procesadores
Modelo de Tareas
Modelo del Ambiente
Modelo de Comportamiento
Diagrama de Contexto
1.- cliente
vie 1.- client 1.- cliente 1.- cliente
vie 1.- cliente
vie
1.- cliente vie 1.- client 1.- cliente 1.- cliente vie 1.- cliente vie
Diccionario de Datos
Modelo Funcional
Modelo de Datos
Lista de Eventos
DTE
Árboles de Pantalla
Informes, Listados, Lay-out de Pantallas
DFDs y ERDs por Procesador
DFDs por Tarea
DEs por Tarea
45
La idea fundamental con la que el modelo esencial es concebido es la de
Tecnología Perfecta en la cual no hay restricciones de cantidad de memoria,
tamaño del disco o velocidad del procesador.
Dos Componentes conforman el Modelo Esencial:
� Ambiente: Declaración de los objetivos. Creación de un Diagrama de
Contexto y de una Lista de Eventos, describe las pruebas hechas a un
sistema y los resultados obtenidos. Definición del Diccionario de Datos
inicial.
� Comportamiento: Creación de un DFD (Diagrama de Flujo de Datos), y
un DER (Diseño Entidad-Relación) por cada uno de los eventos de la
Lista de Eventos. Los DFDs por eventos se unen en un único DFD (el
Modelo Funcional) y los DERs por eventos se unen en un único DER (el
Modelo de Datos).
2.2.2.2 El Modelo de Implementación.
Representa la etapa de Diseño Estructurado. Instanciación de un Modelo
Esencial con una Tecnología dada. A partir de esta etapa, el modelo esencial
es instanciado en una tecnología dada.
Se debe considerar ahora, las imperfecciones de la tecnología y determinar los
siguientes aspectos:
� La cantidad de procesadores necesarios.
� Las cualidades de estos procesadores.
� El tamaño de disco necesario de acuerdo al volumen de la información.
Luego se diseña la solución sobre la base de esas restricciones tecnológicas.
46
La creación del Modelo de Implementación se fundamenta en la creación de 3
Componentes, uno de ellos en forma independiente (El Usuario o de la interfaz
hombre-máquina) y los otros 2 en forma encadenada en un proceso
incremental de refinamiento e incorporación de detalles:
� Usuario: La interfaz hombre-máquina es modelada en todos sus
detalles, estilo, especificación y formato de pantallas, formato de
informes y listados, diseño de pantallas para el ingreso de datos y
presentación de resultados, estilo de mensajes de error, secuencia, etc.
� Distribución: Describe todas las decisiones relativas a la arquitectura de
hardware y a la estructuración general de la arquitectura de software. Se
incorporan, en los modelos creados hasta este punto algunas
estrategias destinadas a optimizar el uso de esa tecnología.
Tres Modelos se derivan de la Distribución:
� Modelo de Procesadores: El modelo de comportamiento (modelo de
datos, modelo funcional y modelo de comportamiento externo
o de interfaz) es subdividido por procesadores.
� Modelo de Tareas: Los modelos resultantes de la creación del Sub-
Modelo de procesadores son estudiados por separado, para
determinar tareas diferentes.
� Modelo de Programas: La estructura del programa que implementa
cada una de las tareas resultantes de las etapas de modelado
de procesadores y tareas, es diseñada mediante la aplicación
de las técnicas y estrategias descriptas por el Diseño
Estructurado.40
40 www.monografias.com/cicdevida/asml (11/10/2008).
47
2.2.3 Metodología CASE (Computer Aided Systems Engineering).
CASE plantea una secuencia de etapas más detallada, y además proporciona
para cada etapa su descripción, definición de objetivos y metas, productos de
la etapa, factores críticos de éxito, y la lista de tareas que conviene realizar.
Además es posible auxiliarse de herramientas CASE que facilitan grandemente
la puesta en práctica del método.
CASE se basa en un análisis y desarrollo del tipo descendiente en que el ciclo
de vida se compone de las etapas que observamos en la siguiente Figura:
Figura No. 22.- Etapas de la Metodología CASE.
1) Estrategia.-
Tiene por objetivo lograr un entendimiento claro de las necesidades de la
organización y del ambiente en que operará el sistema o sistemas a implantar.
Con el fin de tener una visión de negocio, se analizan las diferentes funciones
que realiza la organización y sus necesidades de información a todos niveles,
por ello se realizan entrevistas con la dirección y gerentes de departamento.
48
Así a partir de esta información se realiza así un primer modelado de los
requerimientos del sistema de información adecuado a las necesidades de la
organización.
2) Análisis.-
La etapa de análisis toma y verifica los descubrimientos de la etapa de
estrategia y expande estos en suficiente detalle para asegurar la precisión de
los modelos de la empresa, posibilitando un fundamento sólido para el diseño,
dentro del alcance de la organización y tomando en cuenta sistemas
existentes.
3) Diseño.-
La etapa de diseño toma los requerimientos y el modelado de la etapa de
análisis y determina la mejor manera de satisfacerlos, logrando niveles de
servicios acordados, dados el ambiente técnico y las decisiones previas en los
niveles requeridos de automatización. Es decir que del diseño conceptual se
pasa al diseño final que será utilizado para la implantación.
� Construcción.- A partir del diseño final generado en la anterior etapa, en
esta de construcción, se codificarán y probarán los nuevos programas,
usando herramientas apropiadas.
� Documentación.- Los manuales, resultados de esta etapa, se elaboran a
partir de las especificaciones de diseño, de los programas realizados y
del análisis del estilo de trabajo y nivel de competencia de los usuarios y
operadores de los sistemas. En la figura 6 se muestra el proceso de esta
etapa.
4) Transición.-
En esta etapa se realizan todas las tareas necesarias para la implementación y
proporciona un periodo inicial de soporte al sistema. La transición debe llevarse
a cabo con una interrupción mínima de la organización, y debe dejar a los
usuarios confiados y listos para explotar el nuevo sistema. El resultado final de
esta etapa es un reporte que muestre que las pruebas fueron satisfactorias.
49
5) Producción.-
Aquí se asegura que el sistema funcione correctamente en la mayoría de los
casos, y con intervención mínima de los administradores del sistema. Para esto
se realizan nuevas pruebas, se evalúan los resultados y se hacen
refinamientos del sistema, los cambios necesarios deberán ser introducidos sin
afectar a los usuarios, y deberá conseguirse la máxima confianza de los
usuarios. El resultado de esta etapa un sistema listo para su operación.41
2.2.4 Metodología XP (Extreme Programing).
Es una de las metodologías de Construcción de desarrollo de software más
exitosas en la actualidad utilizados para proyectos de corto plazo, corto equipo
y cuyo plazo de entrega era ayer.
Consiste en una programación rápida o extrema, cuya particularidad es tener
como parte del equipo, al usuario final, pues es uno de los requisitos para llegar
al éxito del proyecto.
Figura No. 23.- Etapas de la Metodología XP.
41 www.monografias.com/cicdevida/case (11/10/2008).
50
Características de XP:
� Pruebas Unitarias: se basa en las pruebas realizadas a los principales
procesos, de tal manera que adelantándonos en algo hacia el futuro,
podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si
nos adelantáramos a obtener los posibles errores.
� Refabricación: se basa en la reusabilidad de código, para lo cual se
crean patrones o modelos estándares, siendo más flexible al cambio.
� Programación en pares: una particularidad de esta metodología es que
propone la programación en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estación de
trabajo.
Cada miembro lleva a cabo la acción que el otro no está haciendo en ese
momento. Es como el chofer y el copiloto: mientras uno conduce, el otro
consulta el mapa.
¿Qué es lo que propone XP?
� Empieza en pequeño y añade funcionalidad con retroalimentación
continua.
� El manejo del cambio se convierte en parte sustantiva del proceso.
� El costo del cambio no depende de la fase o etapa.
� No introduce funcionalidades antes que sean necesarias.
� El cliente o el usuario se convierte en miembro del equipo.
Derechos del Cliente
� Decidir que se implementa .
� Saber el estado real y el progreso del proyecto.
� Añadir, cambiar o quitar requerimientos en cualquier momento.
� Obtener lo máximo de cada semana de trabajo.
� Obtener un sistema funcionando cada 3 o 4 meses.
51
Derechos del Desarrollador
� Decidir cómo se implementan los procesos.
� Crear el sistema con la mejor calidad posible.
� Pedir al cliente en cualquier momento aclaraciones de los
requerimientos.
� Estimar el esfuerzo para implementar el sistema.
� Cambiar los requerimientos en base a nuevos descubrimientos.
� Lo fundamental en este tipo de metodología es:
� La comunicación, entre los usuarios y los desarrolladores .
� La simplicidad, al desarrollar y codificar los módulos del sistema.
� La retroalimentación, concreta y frecuente del equipo de desarrollo,
el cliente y los usuarios finales.
La metodología XP se recomienda para proyectos de corto plazo.42
2.2.5 Metodología MSF (Microsoft Solution Framework).
Metodología flexible relacionada con una serie de conceptos y prácticas de
uso, que controlan la planificación, el desarrollo y la gestión de proyectos
tecnológicos. Se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnológicas.
Figura No. 24.- Etapas de la Metodología MSF
42 www.monografias.com/cicdevida/xp (11/10/2008).
52
MSF tiene las siguientes características:
� Adaptable: es parecido a un compás, usado en cualquier parte como un
mapa, del cual su uso es limitado a un específico lugar.
� Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas,
así como también, proyectos que requieren 50 personas a más.
� Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
� Tecnología Agnóstica: porque puede ser usada para desarrollar
soluciones basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes
partes implicadas en el desarrollo de un proyecto:
� Modelo de Arquitectura del Proyecto.- Define las pautas para construir
proyectos empresariales a través del lanzamiento de versiones.
� Modelo de Equipo.- Proporciona una estructura flexible para organizar
los equipos de un proyecto.
� Modelo de Proceso.- Proporciona pautas a seguir en el ciclo de vida del
proyecto, describiendo fases, actividades, liberación de versiones y
explicando su relación con el Modelo de equipo.
� Modelo de Gestión del Riesgo.- Proporciona un entorno estructurado
para la toma de decisiones y acciones valorando los riesgos provocados.
� Modelo de Diseño del Proceso.- Proporciona un modelo centrado en el
usuario para obtener diseño eficiente y flexible a través de iteraciones.
� Modelo de Aplicación.- Proporciona un modelo para diseñar y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son
escalables, y pueden ser usados en una varias computadoras.
La metodología MSF se adapta a proyectos de cualquier dimensión y de
cualquier tecnología.43
43 www.monografias.com/cicdevida/msf (11/10/2008)
53
2.2.6 Seleccionando Modelos de Construcción.
Los modelos presentados, proporcionan una guía con el fin de ordenar las
diversas actividades técnicas en el proyecto de desarrollo de software e
intentan suministrar un marco para la administración en el desarrollo y el
mantenimiento. Aunque todos ellos son compatibles unos con otros, un
proyecto puede decidir cuáles enfoques son más útiles en situaciones
especiales.
Existe un estudio acerca de los factores que influyen en dicha elección; si bien
es cierto este método ofrece gran potencial, necesitaría ser ajustado o
actualizado al conocimiento de hoy, principalmente sobre las características de
los proyectos actualmente en desarrollo.
Este estudio consiste en la proposición de criterios para proyectos y
aplicaciones específicas, y la creación de plantillas que describen el perfil ideal
de proyectos convenientes para cada modelo del ciclo de vida. Después de
crear un perfil para un proyecto en cuestión, el jefe del proyecto necesita sólo
encontrar el perfil ideal que más se acerca.
Entre los criterios incluidos en dicho estudio se encuentran:
� Madurez de la aplicación (relacionado a la probabilidad que muchos
requerimientos comenzarán a conocerse sólo después del uso del
sistema).
� Complejidad del problema y de la solución.
� Utilidad de la funcionalidad rápida (parcial).
� Frecuencias y magnitudes esperadas de los cambios de requerimientos.
� Financiamiento disponible, y su perfil como una función del tiempo.
� Acceso de los desarrolladores a los usuarios.
� Certeza de requerimientos conocidos.
Otros que pueden incluirse:
� Tolerancia al riesgo.
� Planes y presupuestos críticos.
� Grado de lentitud de construcción dentro de los planes y presupuestos.
54
Considerando la importancia de la planificación se recomienda realizar el
desarrollo de un proyecto de software bajo el modelo espiral insertando en él,
cualquier otro modelo que se requiera dependiendo de las necesidades que se
presenten. Este modelo permite realizar una planificación del proceso de
desarrollo del software considerando los riesgos asociados en cada etapa.
El identificar los riesgos en proyectos, evaluar su impacto, monitorear y
controlar el avance del desarrollo del proyecto, permite al administrador
aumentar las posibilidades de éxito de un proyecto o, minimizar las
posibilidades de fracaso de éste.
Uno de los factores que más influyen en el proceso de desarrollo de software y
que prácticamente acompaña a toda aplicación es el hecho de que en su
mayoría, no hay forma de tener todos los requerimientos corregidos antes del
desarrollo del software.
Muchas veces los requerimientos emergen a medida que la aplicación o partes
de ella están disponibles para experimentación práctica. En todos los casos, el
trabajo comienza con la determinación de objetivos, alternativas y restricciones,
paso que a veces se llama recolección preliminar de requisitos.
El prototipado es ampliamente recomendado para realizar la especificación de
requerimientos, se debe notar que la idea del prototipado es capturar por
retroalimentación los objetivos, necesidades y expectativas del cliente por lo
cual no se debe caer en una utilización de estos prototipos como partes finales
del sistema, ya que en su desarrollo generalmente no se consideran aspectos
de calidad, ni otros asociados con facilitar la etapa de mantenimiento del
sistema.
El cambio es una propiedad del software. Hoy en día el software debe poseer
un enfoque evolutivo, un sistema debe evolucionar para acomodar la
naturaleza evolutiva de los grandes sistemas.
55
El software cambia constantemente, debido a la necesidad de reparar el
software (eliminando errores no detectados anteriormente) como a la
necesidad de apoyar la evolución de los sistemas a medida que aparecen
nuevos requerimientos o cambian los antiguos. Por lo cual es importante
enfatizar que, no tiene sentido entonces que un proyecto tome estrictamente
una decisión concerniente con cual modelo se adherirá. Los modelos de ciclo
de vida presentados, son complementarios en vez de excluyentes.
En muchos casos, los paradigmas pueden y deben combinarse de forma que
puedan utilizarse las ventajas de cada uno en un único proyecto. El paradigma
del modelo en espiral lo hace directamente, combinando la creación de
prototipos y algunos elementos del ciclo de vida clásico, en un enfoque
evolutivo para la ingeniería de software. No hay necesidad por tanto de ser
dogmático en la elección de los paradigmas para la ingeniería de software: la
naturaleza de la aplicación debe dictar el método a elegir.44
2.3 Planificación de la Construcción.
La planeación efectiva de un proyecto de software depende de la planeación
detallada de su avance, anticipado problemas que puedan surgir y preparando
con anticipación soluciones tentativas a ellos.
Se supone que el administrador del proyecto es responsable de la planeación
desde la definición de requerimientos hasta la entrega del sistema terminado.
Planificación del Software se puede definir como:
“Es el Proceso de Administración para la creación de un Sistema o
software, la cual encierra un conjunto de actividades, una de las cuales es
la estimación, estimar es echar un vistazo al futuro y aceptamos
resignados cierto grado de incertidumbre. Aunque la estimación, es mas
un arte que una Ciencia, es una actividad importante que no debe llevarse
a cabo de forma descuidada”.45
44 www.huma.upm.es/documentacion.html (11/10/2008). 45 -Ivar Jacobson. El proceso unificado de desarrollo de software. Addison-Wesley 2000.
56
Existen técnicas útiles para la estimación de tiempo. Y dado que la estimación
es la base de todas las demás actividades de planificación del proyecto y sirve
como guía para una buena Ingeniería Sistemas y Software.
Al estimar se debe tomar en cuenta no solo del procedimiento técnico a utilizar
en el proyecto, sino los recursos, costos y planificación. El Tamaño del
proyecto es otro factor importante que puede afectar la precisión de las
estimaciones. A medida que el tamaño aumenta, crece rápidamente la
interdependencia entre varios elementos del Software.
Los puntos que se analizarán a continuación, generalmente son requeridos por
grandes sistemas de programación, sin embargo estos puntos son validos
también para sistemas pequeños.
� Panorama.- Descripción general del proyecto detalle de la organización
del plan y resume el resto del documento.
� Plan de fases.- Análisis de requisitos, fase de diseño de alto nivel, fase
de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una
fecha que especifique cuando se deben terminar estas fases..
� Plan de Organización.- Se definen las responsabilidades específicas de
los grupos que intervienen en el proyecto.
� Plan de Pruebas.- Se ejecuta una matriz de las pruebas y de las
herramientas, procedimientos y responsabilidades para realizar las
pruebas del sistema.
� Plan de Control de Modificaciones.- Se establece un mecanismo para
aplicar las modificaciones que se requieran a medida que se desarrolle
el sistema.
� Plan de Documentación.- Su función es definir y controlar la
documentación asociada con el proyecto.
� Plan de Capacitación.- Se describe la preparación de los programadores
que participan en el proyecto y las instrucciones a los usuarios para la
utilización del sistema que se les entregue.
� Plan de Revisión e Informes.- Se analiza como se informa del estado del
proyecto y se definen las revisiones formales asociadas con el avance
de proyecto.
57
� Plan de Instalación y Operación.- Se describe el procedimiento para
instalar el sistema en la localidad del usuario.
� Plan de Recursos y Entregas.- Se resume los detalles críticos del
proyecto como fechas programadas, marcas de logros y todos los
artículos que deben entrar bajo contrato.
� Índice.- Se muestra en donde encontrar las cosas dentro del plan.
� Plan de Mantenimiento.- Se establece un bosquejo de los posibles tipos
de mantenimiento que se tienen que dar para futuras versiones del
sistema.
2.3.1 Objetivos de la Planificación.
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.
Estas estimaciones se hacen dentro de un marco de tiempo limitado al
comienzo de un proyecto de software, y deberían actualizarse regularmente
medida que progresa el proyecto. Además las estimaciones deberían definir los
escenarios del mejor caso, y peor caso, de modo que los resultados del
proyecto pueden limitarse.
El Objetivo de la planificación se logra mediante un proceso de descubrimiento
de la información que lleve a estimaciones razonables.46
2.3.2 Aspectos Asociados al Proyecto.
1) Ámbito del Software.-
Es la primera actividad de llevada a cabo durante la planificación del proyecto
de Software.
En esta etapa se deben evaluar la función y el rendimiento que se asignaron al
Software durante la Ingeniería de Sistemas para establecer un ámbito de
proyecto que no sea ambiguo, e incomprensible para directivos y técnicos.
46 www.cognos.com/es/software-de-planificacion.html (25/09/2008).
58
Describe la función, el rendimiento, las restricciones, las interfaces y la
fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan
para dar más detalles antes del comienzo de la estimación.
Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta
y procesamiento, identifican los límites del software originados por el hardware
externo, por la memoria disponible y por otros sistemas existentes.
El Ámbito se define como un pre-requisito para la estimación y existen algunos
elementos que se debe tomar en cuenta como es:
La Obtención de la Información necesaria para el software. Para esto el
analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen
de acuerdo en los puntos de interés para su desarrollo.
2) Recursos.-
La Segunda tarea de la planificación del desarrollo de Software es la
estimación de los recursos requeridos para acometer el esfuerzo de desarrollo
de Software, esto simula a una pirámide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de
desarrollo, en segundo nivel de la pirámide se encuentran los Componentes
reutilizables.
Y en la parte más alta de la pirámide se encuentra el recurso primario, las
personas (el recurso humano).
Cada recurso queda especificado mediante cuatro características:
� Descripción del Recurso.
� Informes de disponibilidad.
� Fecha cronológica en la que se requiere el recurso.
� Tiempo durante el que será aplicado el recurso.
59
Existen diferentes tipos de recursos en la planificación entre ellos están:
� Recursos Humanos.-
La Cantidad de personas requeridas para el desarrollo de un proyecto de
software solo puede ser determinado después de hacer una estimación del
esfuerzo de desarrollo (por ejemplo personas mes o personas años), y
seleccionar la posición dentro de la organización y la especialidad que
desempeñara cada profesional.
� Componentes de Software Reutilizables.-
Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la
reusabilidad, esto es la creación y la reusabilidad de bloques de construcción
de Software.
Tales bloques se deben establecer en catálogos para una consulta más fácil,
estandarizarse para una fácil aplicación y validarse para la también fácil
integración.
� Recursos de Entorno.-
El entorno es donde se apoya el proyecto de Software, llamado a menudo
entorno de Ingeniería de Software, incorpora Hardware y Software.
El Hardware proporciona una plataforma con las herramientas (Software)
requeridas para producir los productos que son el resultado de la buena
práctica de la Ingeniería del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y
verificar que estos recursos estén disponibles.
Muchas veces el desarrollo de las pruebas de validación de un proyecto de
software para la composición automatizada puede necesitar un compositor de
fotografías en algún punto durante el desarrollo.
Cada elemento de hardware debe ser especificado por el planificador del
Proyecto de Software.
60
3) Estimación del proyecto de Software.-
Un gran error en la estimación del costo puede ser lo que marque la diferencia
entre beneficios y perdidas, la estimación del costo y del esfuerzo del software
nunca será una ciencia exacta, son demasiadas las variables: humanas,
técnicas, de entorno, políticas, que pueden afectar el costo final del software y
el esfuerzo aplicado para desarrollarlo.
Para realizar estimaciones seguras de costos y esfuerzos tienen varias
opciones posibles:
� Dejar la estimación para más adelante (obviamente podemos realizar
una estimación confiable después de haber terminado el proyecto).
� Basar las estimaciones en proyectos similares ya terminados.
� Utilizar técnicas de descomposición relativamente sencillas para
generar las estimaciones de costos y esfuerzo del proyecto.
� Desarrollar un modelo empírico para él cálculo de costos y esfuerzos
del Software.
Antes de hacer una estimación, el planificador del proyecto debe comprender el
ámbito del software a construir y generar una estimación de su tamaño.
La estimación basada en el Proceso es una técnica basada en el proceso que
se va a utilizar, es decir, el proceso se descompone en un conjunto
relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para
llevar a cabo la estimación de cada tarea.
La estimación basada en el proceso comienza en un enlistado de las funciones
del software obtenidas a partir del ámbito del proyecto. Se mezclan las
funciones del problema y las actividades del proceso. Como último paso se
calculan los costos y el esfuerzo de cada función y la actividad del proceso de
software.47
47 www.gmv.es/transporte/software_planificacion.htm (30/10/2008).
61
2.3.3 Modelos de Estimación.
Existen diferentes modelos de Estimación como son:
1) Modelos Empíricos.-
Donde los datos que soportan la mayoría de los modelos de estimación
obtienen una muestra limitada de proyectos. Por esta razón, el modelo de
estimación no es adecuado para todas las clases de software y en todos los
entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos
se deben utilizar con prudencia.
2) Modelo COCOMO.-
Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software,
introduce una jerarquía de modelos de estimación de Software con el nombre
de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo
constructivo de costos. La jerarquía de modelos de Boehm esta constituida por
los siguientes:
� Modelo I.- El Modelo COCOMO básico calcula el esfuerzo y el costo
del desarrollo de Software en función del tamaño del programa,
expresado en las líneas estimadas.
� Modelo II.- El Modelo COCOMO intermedio calcula el esfuerzo del
desarrollo de software en función del tamaño del programa y de un
conjunto de conductores de costos que incluyen la evaluación
subjetiva del producto, del hardware, del personal y de los atributos
del proyecto.
� Modelo III.- El modelo COCOMO avanzado incorpora todas las
características de la versión intermedia y lleva a cabo una evaluación
del impacto de los conductores de costos en cada caso (análisis,
diseño, etc.) del proceso de ingeniería de Software. 48
48 MEYER,“Construcción del Software Orientado a Objetos”. McGraw-Hill, 2001.pp 480.
62
3) Herramientas Automáticas de Estimación.-
Las herramientas automáticas de estimación permiten al planificador estimar
costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con
importantes variables del proyecto, tales como la fecha de entrega o la
selección del personal. Aunque existen muchas herramientas automáticas de
estimación, todas exhiben las mismas características generales y todas
requieren de una o más clases de datos.
A partir de estos datos, el modelo implementado por la herramienta automática
de estimación proporciona estimaciones del esfuerzo requerido para llevar a
cabo el proyecto, los costos, la carga de personal, la duración, y en algunos
casos la planificación temporal de desarrollo y riesgos asociados.
En resumen el planificador del Proyecto de Software tiene que estimar tres
cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo
requerirá y cuanta gente estará implicada. Además el planificador debe
predecir los recursos de hardware y software que va a requerir y el riesgo
implicado.
Para obtener estimaciones exactas para un proyecto, generalmente se utilizan
al menos dos de las tres técnicas referidas anteriormente. Mediante la
comparación y la conciliación de las estimaciones obtenidas con las diferentes
técnicas, el planificador puede obtener una estimación más exacta. La
estimación del proyecto de software nunca será una ciencia exacta, pero la
combinación de buenos datos históricos y técnicas puede mejorar la precisión
de la estimación.49
2.4 Medición de la Construcción.
La Ingeniería del Software ha sido definida como la disciplinada aplicación de la
ingeniería, la ciencia y los principios matemáticos, métodos, y herramientas
para la producción de software de calidad.
49 Fairley, R.: “Ingeniería del Software”. McGraw-Hill, 2001.pp 165.
63
Aquí se incluyen actividades como planificación, estimación, modelado, diseño,
construcción o programación, pruebas, instalación, mantenimiento y gestión.
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.
Las medidas y métricas han de ser diseñadas para soportar los objetivos de
Negocio de la organización para la que son desarrolladas.
Para entender cuáles son las mejoras críticas en una organización, hemos de
ser conscientes de las diferencias entre organizaciones de software maduras e
inmaduras.
En una organización de software inmadura, los procesos de software
generalmente son improvisados durante el curso de un proyecto por quienes
los ejecutan y gestionan. En una organización inmadura no hay base objetiva
para poder enjuiciar la calidad del producto o para resolver problemas del
producto o el proceso.
Por el contrario, una organización de software madura, posee habilidad y
capacidad en el conjunto de la organización para gestionar procesos de
desarrollo y mantenimiento de software. Los procesos están documentados y
son utilizables y consistentes con la forma en la que el trabajo es hecho en
cada momento.
Las definiciones de los procesos son actualizadas cuando es necesario, y las
mejoras a esos procesos son desarrolladas a través de pruebas controladas y
análisis costo / beneficio.
A medida que se avanza en la vía de una organización madura, el proceso
software está mejor definido e implementado de una manera más consistente.
Para ello se necesita de una infraestructura y de una cultura organizacional
para soportar los métodos, prácticas y procedimientos de la organización.
64
La calidad de los productos software está determinada en gran medida por la
calidad del proceso usado para desarrollar y mantener dichos productos, y ello
ha de ser incorporado tanto en las prácticas usuales de la organización, como
en la gestión de los proyectos de la misma. La Figura No. 25 muestra el control
de medición del proceso de un proyecto de Software.
Figura No. 25.- Medición de Control y Proceso.50
Han sido desarrollados muchos modelos de gestión de procesos con el fin de
mejorar la calidad y nivel de realización de los mismos. El Modelo de
Capacidad de Madurez del Software (CMM), SPICE, ISO9001 y Bootstrap
están entre los más extendidos internacionalmente. 51
El concepto de gestión de proceso está fundamentado en los principios del
control estadístico, los cuales sostienen que manteniendo estables los niveles
de variabilidad, los procesos producirán resultados predecibles. La Predicción
de resultados no debe ser interpretada como obtención de resultados idénticos,
ya que estos varían respecto de la predicción, pero cuando un proceso está
controlado, esa variación estará dentro de límites conocidos.
50 JOHNSON, “Flexible Software Design”. McGraw-Hill, 2005.pp 230. 51 www.pchardware.org/software/testeo.php (11/11/2008).
65
Los Procesos controlados son estables, y los procesos estables permiten la
predicción de resultados. Esto permite la preparación de planes alcanzables, la
estimación de costes y el establecimiento de compromisos de plazos y fechas.
Por otro lado, la gestión de proyectos es debe asegurar que un producto
software es desarrollado de acuerdo a un plan y que ese plan es viable.
En la Figura No. 26 se muestra la relación entre las responsabilidades de la
gestión del proceso y del proyecto, así como la integración de ambas.
Figura No. 26.- Relación entre gestión del proceso y gestión del proyecto.52
2.4.1 Arquitectura de un proceso de Medida de Software.
Una posible arquitectura para el diseño y desarrollo de un proceso de medidas
software se muestra en la siguiente figura. Esta arquitectura es genérica y
puede ser implementada en distintos niveles, desde el nivel proyecto hasta el
nivel organización.
52 Ibid.
66
Figura No. 27.- Definición de un Proceso de Medición de Software.53
Alineando el proceso de medidas con el proceso de software global, tanto los
proyectos como las organizaciones son capaces simultáneamente de recoger y
analizar datos que ayuden a la toma de decisiones respecto de las metas de
los proyectos, y obtener información para mejorar el proceso de medidas en sí
mismo y el proceso de software en general.
En base a lo anterior una posible definición del proceso de medición de
software puede ser la siguiente:
“La parte del proceso software que facilita la identificación, definición,
recogida y análisis de medidas que son usadas para entender, evaluar,
controlar o mejorar los productos y-o procesos software”.54
53 www.tracnova.com/softwaredemedicion.htm (01/11/2008). 54 McGarry, J. Optimización práctica del Software. Addison Wesley. 2002. pp 142.
67
Este proceso de medidas debe estar disponible para que sea utilizado en
cualquier proyecto de desarrollo y mantenimiento como parte del proceso
software estándar de la organización y deberá incorporar componentes como:
� Elementos del proceso estándar de la organización, y definidos en
términos operacionales que permitan fácilmente:
� Identificar qué datos han de ser recogidos.
� Definir cómo son los datos a ser recogidos.
� Definir cómo son los datos a ser usados en la toma de decisiones.
� Definir cómo es el proceso para la evolución y mejora tanto del proceso
de medidas como del proceso software.
� Recoger y analizar datos.
� Tomar decisiones.
� Bases de datos de la organización y documentación asociada de
usuario.
� Herramientas para definir medidas (formularios, descripciones, recogida
de datos, análisis, etc.).
� Guías y criterios para una “definición a medida” de cada proyecto de
algunos elementos del proceso de medidas software.
En el desarrollo de un proceso de medidas debe tenerse en cuenta cuáles son
las metas a alcanzar y las medidas que son necesarias para alcanzarlas. Es
decir, los procesos de medidas deben enfocarse a los objetivos que se
pretenden conseguir, no a las medidas en sí mismas.
2.4.2 Modelo de Proceso para la Definición de Medidas de Software.
Aquí explicaremos la primera fase de la arquitectura del Sistema de Medidas.
Se pone énfasis sobre las medidas dirigidas por objetivos y metas para
recoger información que ayude a alcanzarlos.
Con esto se pretende que las medidas tengan referencias claras con cada
meta u objetivo, evitando malgastar esfuerzos que no contribuyan directamente
a alcanzar las metas de los negocios.
68
El proceso de medidas dirigido por metas y objetivos propuesto está basado en
dos preceptos, estos preceptos a su vez se descomponen en cinco grupos y
los grupos se dividen en diez pasos.
Los dos preceptos son:
� Las metas de las medidas deben estar dirigidas por las metas de los
negocios.
� Es preciso transformar las metas y objetivos en estructuras de medida
ejecutables.
Los Cinco Grupos son:
� Identificar Metas y Objetivos, es decir, qué se desea conocer.
� Formalizar las metas de las medidas.
� Definir las medidas a utilizar y sus definiciones operacionales.
� Identificar las acciones a llevar a cabo para implementar las medidas.
� Preparar un plan para la implantación de las medidas. A continuación se
detallará este paso.
La preparación de un plan para la implementación de las acciones que han sido
identificadas. Este plan debería contener al menos los apartados que se
incluyen en la plantilla de la Figura No. 28.
69
Figura No. 28.- Plan de Implementación de Medidas de Software.
Hay cuatro características que hemos de considerar básicas y deben estar
entre las herramientas de gestión del proceso de desarrollo de software:
� Tamaño.
� Esfuerzo.
� Duración.
� Calidad.
Estas medidas cubren importantes características de los productos y el proceso
de software relevante en la planificación, control y mejora del proceso.
Podemos ver algunas de las medidas y las características que cubren.
Figura No. 29.- Medidas Específicas.
70
Las medidas que aparecen en la figura anterior no son las únicas posibles,
pero pueden ser usadas para describir los productos y procesos software, y
además son medidas prácticas que producen información útil.
Cada medida necesita unos atributos para ser definida. Por ejemplo, los
problemas y defectos usualmente estarán clasificados de acuerdo a atributos
tales como estado, tipo, severidad, prioridad, y dónde se producen; el esfuerzo
será clasificado por horas de trabajo, tipo de trabajo realizado y perfil
profesional de quien lo realiza; la duración estará definida en términos de
fechas y criterios de finalización; el tamaño puede estar definido de acuerdo a
los lenguajes de programación, el tipo de instrucciones, los métodos de
producción, el número de entradas al producto software, y el tipo de interfaz
con el usuario.55
55 www.ingenierosoftware.com/calidad (12/11/2008).
71
CAPÍTULO III
CONSIDERACIONES PRÁCTICAS
3.1 Diseño de la Construcción.
El Diseño de la Construcción del Software se define como:
“El proceso de aplicar ciertas técnicas y principios con el propósito de
definir un dispositivo, un proceso o un Sistema, con suficientes detalles
como para permitir su interpretación y realización física”.56
La etapa del Diseño encierra cuatro etapas:
1) El diseño de los datos.- Trasforma el modelo de dominio de la información,
creado durante el análisis, en las estructuras de datos necesarios para
implementar el Software.
2) El Diseño Arquitectónico.- Define la relación entre cada uno de los
elementos estructurales del programa.
3) El Diseño de la Interfaz.- Describe como se comunica el Software consigo
mismo, con los sistemas que operan junto con el y con los operadores y
usuarios que lo emplean.
4) El Diseño de Procedimientos.- Transforma elementos estructurales de la
arquitectura del programa. La importancia del Diseño del Software se puede
definir en una sola palabra: Calidad; dentro del diseño es donde se fomenta la
calidad del Proyecto.
3.1.1 Técnicas de Diseño.
El Diseño de Construcción es un proceso y un modelado a la vez. El proceso
de Diseño es un conjunto de pasos repetitivos que permiten al diseñador
describir todos los aspectos del Sistema a construir.
56 www.monografias.com/diseno_de_construccion/software-uml.shtml (01/12/2008).
72
A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un
conjunto de técnicas:
� Debe implementar todos los requisitos explícitos contenidos en el
modelo de análisis y debe acumular todos los requisitos implícitos que
desea el cliente.
� Debe ser una guía que puedan leer y entender los que construyan el
código y los que prueban y mantienen el Software.
� Debe proporcionar una completa idea de lo que es el Software,
enfocando los dominios de datos, funcional y comportamiento desde el
punto de vista de la Implementación.
� Debe presentar una organización jerárquica que haga un uso inteligente
del control entre los componentes del software.
� Debe ser modular, es decir, se debe hacer una partición lógica del
Software en elementos que realicen funciones específicas.
� Debe contener abstracciones de datos y procedimientos. Así como
producir módulos que presenten características de funcionamiento
independiente.
� Debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y el entorno exterior.
Estos criterios no se consiguen por casualidad. El proceso de Diseño de
Construcción exige buena calidad a través de la aplicación de principios
fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva.
3.1.2 Diseño de Interacciones con la Base de Datos.
La mayoría de los sistemas de información ya sean implantado en sistemas de
cómputos grandes o pequeños, utilizan una base de datos que pueden abarcar
varias aplicaciones, por esta razón estos sistemas utilizan u administrador de
base de datos, en este caso el diseñador no construye la base de datos sino
que consulta a su administrador para ponerse de acuerdo en el uso de esta en
el sistema.
73
3.1.3 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.
Entre las decisiones que se toman durante el diseño de archivos, se
encuentran las siguientes:
� Los datos que deben incluirse en el formato de registros contenidos en
el archivo.
� La longitud de cada registro, con base en las características de los datos
que contenga.
� La secuencia a disposición de los registros dentro del archivo (La
estructura de almacenamiento que puede ser secuencial, indexada o
relativa).
� No todos los sistemas requieren del diseño de todos los archivos, ya que
la mayoría de ellos pueden utilizar los del viejo Sistema y solo tenga que
enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los
registros.57
3.1.4 Diseño de la Salida.
En este caso salida se refiere a los resultados e informaciones generadas por
el Sistema, Para la mayoría de los usuarios la salida es la única razón para el
desarrollo de un Sistema y la base de evaluación de su utilidad. Sin embargo
cuando se realiza un sistema, como analistas deben realizar lo siguiente:
� Determine que información presentar. Decidir si la información será
presentada en forma visual, verbal o impresora y seleccionar el medio
de salida.
� Disponga la presentación de la información en un formato aceptable.
� Decida como distribuir la salida entre los posibles destinatarios. 58
57 SOMMERVILL. Ingeniería de Software. Mc Graw Hill, 5ª Ed.,2002. pp.560. 58 www.wikipedia.org/wiki/Ingeniería_del_diseño/tecnicas (09/12/2008).
74
3.2 Lenguajes de Construcción.
Definimos Lenguaje de Construcción como:
“Un lenguaje que puede ser utilizado para controlar el comportamiento de
una computadora. Consiste en un conjunto de reglas sintácticas y
semánticas que definen su estructura y el significado de sus elementos,
respectivamente”.59
3.2.1 Características.
Los lenguajes de programación facilitan la tarea de programación, ya que
disponen de formas adecuadas que permiten ser leídas y escritas por
personas, a su vez resultan independientes del modelo de computador a
utilizar.
Los lenguajes de programación representan en forma simbólica y en manera
de texto los códigos que podrán ser leídos por una persona. Los lenguajes de
programación son independientes de las computadoras a utilizar.
Existen estrategias que permiten ejecutar en una computadora un programa
realizado en un lenguaje de programación simbólico. Los procesadores del
lenguaje son los programas que permiten el tratamiento de la información en
forma de texto, representada en los lenguajes de programación simbólicos.
Hay lenguajes de programación que utilizan compilador. La ejecución de un
programa con compilador requiere de dos etapas:
� Traducir el programa simbólico a código máquina.
� Ejecución y procesamiento de los datos.
Otros lenguajes de programación utilizan un programa intérprete o traductor, el
cual analiza directamente la descripción simbólica del programa fuente y realiza
las instrucciones dadas.
59 www.wikipedia.org/wiki/Lenguaje_de_programación (20/12/2008).
75
El intérprete en los lenguajes de programación simula una máquina virtual,
donde el lenguaje de máquina es similar al lenguaje fuente.
La ventaja del proceso interprete es que no necesita de dos fases para ejecutar
el programa, sin embargo su inconveniente es que la velocidad de ejecución es
más lenta ya que debe analizar e interpretar las instrucciones contenidas en el
programa fuente.
Un lenguaje de programación permite a un programador especificar de manera
precisa: sobre qué datos una computadora debe operar, cómo deben ser estos
almacenados y transmitidos y qué acciones debe tomar bajo una variada gama
de circunstancias. Todo esto, a través de un lenguaje que intenta estar
relativamente próximo al lenguaje humano o natural, tal como sucede con el
lenguaje coloquial.
Un programa escrito en un lenguaje de programación necesita pasar por un
proceso de compilación, es decir, ser traducido al lenguaje de máquina, o ser
interpretado para que pueda ser ejecutado por el ordenador. 60
3.2.2 Paradigmas.
“El Paradigma de programación representa un enfoque particular o
modelo de construcción del software.”61
Los paradigmas determinan radicalmente la forma de abordar los problemas.
Normalmente uno se inclina por el paradigma al que está más acostumbrado,
ya que todos los paradigmas prácticos son Turing-Completo, es decir, cualquier
computación realizable se puede llevar a cabo con cualquiera de ellos.
La elección del paradigma adecuado para un problema puede reducir
drásticamente el tiempo, el costo y la facilidad con la que se llega a la solución,
aunque si no se tiene experiencia con el paradigma en cuestión, puede llegar a
ser contraproducente cambiar del que más se domina. 60 www.lenguajes-de-programacion.com/caracteristicas.shtml (20/12/2008). 61 www.wikipedia.org/wiki/Paradigma_de_programacion (15/12/2008).
76
3.2.2.1 Clasificación de Paradigmas.
Existen muchas formas de clasificar los paradigmas, ya que muchos se
solapan y depende del nivel de detalle al que se quiera llegar. Entre esta
clasificación tenemos:
1) Imperativos.- Son paradigmas mayores, consisten en una serie de
instrucciones que se ejecutan para modificar el estado del programa.
2) Top-Down.- Consiste en especificar el programa como una serie de
instrucciones que se ejecutan secuencialmente, con la posibilidad de incluir
saltos a otras partes del programa.
3) Estructurado.- El programa se divide en bloques independientes y el flujo se
controla mediante estructuras de control. Fue un gran avance respecto a la
programación top-down ya que permitía empezar a reutilizar código y
facilitaba enormemente la comprensión de los programas.
4) Orientado a Objetos.- Los datos y las operaciones que actúan sobre ellos se
agrupan en "objetos" Es un siguiente paso en la programación estructurada,
que permite empezar a desarrollar componentes completos reutilizables de
manera fácil.
5) Declarativo.- es el otro gran paradigma. Se trata de especificar los
programas como una descripción abstracta (de alto nivel) la solución a un
problema en lugar de detallar paso por paso cómo llegar hasta ella. Este
paradigma es por lo tanto más sofisticado que el imperativo, ofrece muchas
ventajas al programador, como la posibilidad de comprobar la corrección
formal de los programas, pero tiene como inconveniente que el rendimiento
suele ser peor.
6) Funcional.- Se intenta imitar el lenguaje de las matemáticas, expresando
toda la lógica del programa como funciones y composición de las mismas.
Tiene algunas ventajas importantes, como la ausencia de efectos
secundarios, suele permitir trabajar con tipos infinitos de forma eficiente y
cómoda y presenta muchas soluciones elegantes a problemas tediosos que
se presentan en la programación estructurada. Ejemplos: Haskell, Erlang.
77
7) Lógico.- Se definen reglas lógicas y luego un motor de inferencia lógico
permite extraer conclusiones o responder a preguntas planteadas al
sistema. Ejemplos: prolog, parlog.
8) Basado en Restricciones.- Consiste en definir una serie de restricciones (y
una función objetivo a optimizar), y un motor de búsqueda proporciona el
conjunto de soluciones posibles (o la solución óptima). Ejemplos: GAMS,
SQL.
3.2.3 Factores en la elección de un Lenguaje de Construcción.
� Tamaño del lenguaje.- Sin duda es una ventaja que un lenguaje sea
sencillo, ya que facilita su aprendizaje, la comprensión del código
escrito.
� Ambigüedades.- Es una característica deseable en un lenguaje que
todas las construcciones válidas tengan una única interpretación posible.
� Documentación.- El lenguaje más maravilloso del mundo si no está
documentado no sirve para nada.
� Portabilidad.- Es deseable que un programa que se implementa en una
computadora pueda funcionar sin ningún problema si se implementa en
otra.
� Rendimiento.- el rendimiento es algo importante, pero hasta cierto punto.
Si se trata de programas que se van a usar según salen del horno, hay
que tener en cuenta que al tiempo de ejecución deberíamos sumarle el
tiempo de compilación.
� Consumo de memoria.- ya que es un recurso que se suele agotar
bastante más rápido que el tiempo y un programa que use mucha
memoria probablemente tendrá penalizaciones de rendimiento por la no-
localidad de los accesos.
� Librerías comunes (estándar).- Otro factor realmente importante es la
cantidad de código que nos podemos ahorrar porque ya lo ha escrito
otro para nosotros. Si encima esas librerías vienen siempre con la
distribución del lenguaje, nos ahorraremos tiempo buscándolas y
espacio en la distribución del programa.
78
� Entornos de desarrollo.- Un buen entorno de desarrollo puede convertir
la tarea de programar en un placer. Nos puede facilitar la vida
completando el código, mostrándonos la documentación sin tener que ir
a buscarla, avisarnos de los errores antes de que probemos el
programa, hacer cambios globales al programa (refactorización),
permitiéndonos navegar rápidamente por todo nuestro código, con un
entorno de depuración integrado, con editores visuales para interfaces
gráficas, etc.
� Tamaño de la comunidad de usuarios.- se supone que cuantas más
personas haya usando un lenguaje menos probabilidad tendrá de morir.
� Calidad de la comunidad de usuarios.- desde luego que está bien que
haya mucha gente, pero es preferible que haya poca gente pero
dispuesta a ayudarse (compartir código, soluciones a problemas
comunes) y que no genere demasiada basura alrededor del lenguaje. 62
3.2.4 Clasificación de los Lenguajes de Construcción.
Programación Imperativa.-
C ALGOL ML PL/1 FORTRAN
BASIC ALGOL1W LOGO SNOBOL BCPL
PASCAL ALGOL 68 LUA COBOL MODULA
ADA CLIPPER OCAML
Programación Orientada a Objetos.-
C++ C# OBJ-C J2ME J2EE
JAVA SAMLLTALK SIMULA OBERON LEXICO
J2SE EIFFEL SATHER J#
62 www.rincondelvago.com/informatica_lenguajes_de_programacion (20/12/2008).
79
Lenguajes de Programación Funcional.-
CAML J APL HASKELL FP
LISP ISWIN JOY OCAML SCHEME
Lenguajes de Shell y Script.-
PHYTON PERL AWK RUBY TCL
BASH SH JAVASCRIPT VBSCRIPT ACTIONSCRIPT
Lenguajes de Programación Web.-
PHP ASP ASP.NET COLDFUSION
Lenguajes de Etiquetado (marcado).-
HTML CSS XML WAP XHTML
XLS XLS-FO XLST POSTSCRIPT RTF
SMIL SGML SVG DOCBOOK LATEX
MATHML VRML X3D XLINK XPATH
Lenguajes de Programación Visual.-
VISUAL BASIC VISUAL BASIC.NET DELPHI
Lenguajes de Programación Concurrente.-
PASCALFC ALEPH OCCAM ERLANG
JOULE SR LANGUAGE PICT
80
Lenguajes de Programación Lógica.-
PROLOG MERCURY SAIL
Lenguajes para el Manejo de Datos.-
SQL MYSQL DBASE VISUAL FOXPRO
Lenguajes de Ensamblador.-
INTEL
80X86 MOTOROLA POWER PC ARM
STRONG
ARM
Lenguajes Esotéricos.-
INTERCAL MALBOLGE BRAINFUCK WHENEVER WIERD
PIET SARTRE BEFUNGE FOTRH63
3.2.5 Visual Studio.Net VS C#.
3.2.5.1 Visual Studio.NET.
Visual Studio .NET es el único entorno de programación creado exclusivamente
para servicios Web XML.
Al permitir que las aplicaciones se comuniquen y compartan datos a través de
Internet, los servicios Web XML permiten que las empresas transformen
Internet en una verdadera plataforma para integrar y ofrecer sus principales
valores empresariales.
63 Lenguajes-de-programacion.com/clasificacion (25/01/2008).
81
Visual Studio .NET y los servicios Web XML proporcionan un modelo sencillo y
flexible basado en estándares que permite a los programadores ensamblar
aplicaciones a partir de código nuevo o existente, independientemente de la
plataforma, del lenguaje de programación o del modelo de objetos.
Las características de Visual Studio en cualquiera de sus versiones son:
� Soporte para XML Web Services.
� Diseño de interfases mediante Windows Forms .
� Diseño web mediante Web Forms o Mobile Web Forms.
� Creación de aplicaciones para Pocket PC-Windows CE .NET .
� Integración con .NET y el Common Language Runtime (CLR) .
� Asistente para actualización de código de VB 6.0 a VB.NET .
� Creación de aplicaciones para consola.
� Class Library templates.
� Librerias para controles Windows y controles Web.
� Creación de Servicios Windows ejecutables al inicio del sistema.
� Soporte Multilenguaje (Visual Basic .NET, Visual C# .NET, Visual C++
.NET, Visual J# .NET, soporte para la instalación de otros lenguajes).
� Otras características a destacar son: un entorno integrado de desarrollo,
un completo depurador, Crystal Reports o un asistente para el diseño
HTML.
3.2.5.2 Lenguaje C#.
C# debe entenderse como un Java mejorado en todos los sentidos: desde la
eficiencia hasta la facilidad de integración con aplicaciones tan habituales como
Microsoft Office o Corel Draw.
Se trata de un nuevo lenguaje orientado a objetos que Microsoft ha
desarrollado con el propósito de que se recoja en un sólo lenguaje los mejores
aspectos de los principales lenguajes existentes. Aparentemente, tiene mucho
de C++, pero contiene obvias influencias de Java.
82
Similitudes entre C# y Java:
� Las clases en C# se declaran de forma muy similar a como se declaran
en Java, las clases también pueden ser abstract y final .
� Las interfaces también existen en C# .
� Cuenta también con operaciones lógicas booleanas.
� C# cuenta con el manejo de excepciones para errores tal como lo hace
Java.
� Garbage collector.
Similitudes entre C# y C++:
� El proceso de compilación.
� Estructuras similares a C++.
� Preprocesador.
� Existe la sobrecarga de operadores.
Nuevas Características de C#
� Declaraciones en el espacio de nombres.- cuando se crea un programa,
se puede definir una o más clases dentro de un mismo espacio de
nombres.
� Tipos fundamentales de datos: existe una variedad más amplia de tipos
de datos que los que se encuentran en C, C++ o Java.
� Ensamblaje: lo que se entiende como ensamblaje para el lenguaje es un
conjunto de clases compiladas, así como un conjunto de otros posibles
elementos que se combinan en un archivo único para ser ejecutado.
� Atributos: cada miembro de una clase tiene un atributo de acceso del
tipo público, protegido, interno, interno protegido y privado.
� Paso de argumentos: se puede declarar a los métodos para que acepten
un número variable de argumentos. Por defecto el pasaje de argumentos
es por valor, salvo que se utilice la palabra reservada ref, la cual indica
que el pasaje es por referencia.
� Métodos virtuales y redefiniciones: antes de que un método pueda ser
redefinido en una clase base, debe declararse el mismo como virtual. El
método redefinido en la subclase debe ser declarado con la palabra
override.
83
� Propiedades: un objeto COM posee de por sí una serie de propiedades,
y dado que las clases en C# pueden ser utilizadas como objetos COM,
C# permite la declaración de propiedades dentro de cualquier clase.
� Indexador: Un indexador (o indexer) se asemeja a una propiedad, con la
diferencia de que en lugar de un nombre de propiedad, un valor de
índice encerrado en corchetes rectos se utiliza en forma anónima para
dirigirse al miembro de una clase.
� Control de versiones: C# permite a los desarrolladores mantener
múltiples versiones de clases en forma binaria, colocándolas en
diferentes espacios de nombres. Esto permite que versiones nuevas y
anteriores de software puedan ejecutarse en forma simultánea.64
3.3 Codificación.
El mejor diseño fácilmente puede corromperse por alteraciones casuales o
incluso bien intencionadas producidas durante la codificación del software. Los
miembros del equipo de desarrollo encargados del diseño y los encargados de
escribir las líneas de código deben estar en estrecha coordinación.
Los programadores son los que finalmente estructurarán todas las
preconcepciones plasmadas en los diversos prototipos en las interfaces que
realmente utilizarán los usuarios. Éstos, a menudo debido a los plazos de
entrega del producto, suelen ser personas que voluntaria o involuntariamente
aportan sus preconcepciones e ideas propias al diseño de dichas interfaces y
ello puede llevarles a no seguir estrictamente las pautas o conclusiones
determinadas.
Cabe destacar el papel de las disciplinas no directamente relacionadas con la
propia codificación, pues los ingenieros software y programadores suelen tener
un entrenamiento especial en la resolución de las propuestas enfocadas a la
optimización del tamaño del código y a la optimización de la velocidad de
ejecución descuidando los aspectos relacionados con la usabilidad y la
accesibilidad e incluso con el diseño gráfico de la interfaz.
64 Farineti.wordpress.com/popularidad-de-lenguajes-de-programacion (25/01/2008)
84
Será importante, pues, que los programadores estén completamente
comprometidos con el seguimiento del modelo de proceso y convencidos de los
beneficios del mismo incluso si no lo entienden o no están de acuerdo en
algunas decisiones del diseño.
Otro aspecto destacado en este punto será que los programadores y
diseñadores que respectivamente escribirán las líneas de código y dibujarán
los elementos de las interfaces respeten las características establecidas en el
enorme trabajo realizado en las fases precedentes..
3.3.1 Estándares de codificación.
Los estándares de codificación son la bendición de las prácticas para
desarrollar software. La bendición y a veces la maldición. Cuando los
estándares de codificación son muy rigurosos tienden a frenar la velocidad del
desarrollo e inevitablemente cuartan en cierta medida la creatividad de los
programadores para brindar soluciones novedosas que puedan no adaptarse
completamente a los requisitos de los estándares adoptados.
El error que no se puede cometer es precisamente adoptar estándares de
codificación complejos.
Se necesita que estos sean prácticos y que todo el equipo de programadores
se encuentre de acuerdo y se sienta a gusto con los mismos. Esto nos permite
vislumbrar que se deben tomar en cuenta en la agenda aquellas reuniones a
inicios del proyecto donde los estándares sean discutidos por todo el equipo.
3.3.2 Técnicas de Codificación.
En general una técnica de codificación no pretende formar un conjunto
inflexible de estándares de codificación. Más bien intenta servir de guía en el
desarrollo de un estándar de codificación para un proyecto específico de
software.
85
3.3.2.1 Generales.
� Para conservar recursos hay que ser muy selectivo en la elección del
tipo de dato, asegurarse que el tamaño de una variable no sea
excesivamente grande. Por ejemplo en los ciclos for es mejor, en la
mayoría de las veces utilizar un tipo de dato tipo short que int.
� Mantener el tiempo de vida de las variables tan corto como sea posible,
esto es muy importante por ejemplo cuando se utiliza un recurso finito
como una conexión a una Base de Datos.
� Usar los procedimientos y variables con un solo propósito. Evitar crear
procedimientos multipropósito que lleven a cabo una variedad de
funciones no relacionadas.
� Dentro de una clase, evitar el uso de variables publicas, en cambio usar
procedimientos y propiedades que accedan a dichas variables
(privadas), así se brinda la posibilidad de validar valores de cambio
sobre las mismas, antes de manipularlas directamente.
� Cuando se trabaje en un entorno web distribuido, tener cuidado de
almacenar información en variables de sesión ASP ya que el estado de
sesión es almacenado siempre en una sola maquina, considerar mejor
almacenar dicha información en una base de datos.
� No abrir conexiones a datos usando credenciales especificas de usuario,
ya que estas no podrán ser reutilizadas por el pool de conexiones.
� Usar siempre rutinas de manejo de excepciones. Así como evitar el uso
de variables en el ámbito de aplicación (web).
� Usar siempre sentencias Select-Case o Switch en lugar de utilizar
sentencias if-then repetitivas.
� Siempre que sea posible utilizar polimorfismo en vez de cláusulas Switch
o Select.
Las técnicas de codificación están divididas en tres secciones:
� Nombrado.
� Documentación Interna (Comentarios).
� Formato.
86
3.3.2.2 Nombrado.
El esquema de nombres es una de las ayudas más importantes para entender
el flujo lógico de una aplicación. Un nombre debe más bien expresar el "qué"
que el "cómo". Si se utiliza un nombre que evite referirse a la implementación
se estará conservando la abstracción de la estructura ya que la implementación
está sujeta a cambios, de esta manera se describe que hace la estructura y no
como lo hace.
Por ejemplo es mas claro nombrar un procedimiento de acceso a datos
SeleccionarRegistro() que RealizarConsultaSelect(), porque lo que importa
(para que otra persona entienda el código) es que se supone que hace el
método y no como lo hace.
Otra técnica es utilizar nombres tan largos como para que se entiendan pero a
la vez tan cortos como para que no den información irrelevante, por ejemplo es
mejor emplearSeleccionarComida() que SeleccionarlaComidadelMenu().
Desde el punto de vista de la programación, un nombre único sirve solamente
para diferenciar un elemento de otro. Los nombres expresivos funcionan como
ayuda para el lector, por eso, es lógico dar nombres que sean fáciles de
comprender. No obstante, se debe garantizar que los nombres escogidos sean
compatibles con las reglas de cada lenguaje y con los estándares.
En el caso de Estructuras:
� Los nombres deben ser en español.
� Los namespaces deben empezar por el nombre de la compañía seguido
de la unidad de negocio, el producto o proyecto yla funcionalidad:
� El nombre de la clase y el archivo fuente deben ser iguales.
� No se debe usar la notación húngara, la cual prefija una abreviatura
referente al tipo de objeto: lblAceptar (label), btnOK(Botón), etc.
� Utilizar la técnica verbo-sustantivo para nombrar procedimientos que
ejecuten alguna operación en un determinado objeto; ejemplo
CalcularDesperdicio().
87
Para el caso de las Variables:
� Las variables miembro se escriben con la primera letra de cada palabra
en mayúscula a excepción de las variable miembro privadas. Las
Variables internas o de bloque deben ir en minúscula.
� Es recomendado que las variable booleanas contengan una palabra que
describa su estado: puedeEliminarse, esGrande, tieneHijos, etc. Y
siempre se debe referir al estado verdadero: tieneCredito en cambio de
noTieneCredito .
� Incluso para el caso de una variable de poco uso, que deba aparecer
sólo en unas cuantas líneas de código, emplee un nombre descriptivo.
Utilizar nombres de variables de una sola letra, como i o j sólo para
índices (ciclos for).
� No usar números o cadenas literales, como por ejemplo For i = 1 To 7.
En su lugar, emplear constantes con nombre, del tipo For i = 1 To
Enumeracion.length para que resulten fáciles de mantener y
comprender.
� Los parámetros siguen el mismo estándar de las variables.
Tablas:
� Los nombres de tablas deben ser en singular.
� Las columnas de las tablas, no deben llamarse igual que la tabla.
� No incorporar el tipo de datos en el nombre de una columna.
3.3.2.3 Comentarios.
Existen dos tipos de documentación de software: externa e interna. La
documentación externa, como por ejemplo las especificaciones, los archivos de
ayuda y los documentos de diseño, se debe mantener fuera del código fuente.
88
La documentación interna está formada por los comentarios que los
programadores escriben dentro del código fuente durante la fase de desarrollo.
Uno de los problemas de la documentación de software interna es garantizar
que se mantengan y actualicen los comentarios al mismo tiempo que el código
fuente.
Aunque unos buenos comentarios en el código fuente no tienen ningún valor en
el tiempo de ejecución, resultan valiosísimos para un programador que tenga
que mantener una parte de software particularmente compleja.
Aquí se mencionarán las técnicas para la documentación:
� Los comentarios deben ser en español.
� Si se programa en C#, utilizar la función de documentación XML.
Cuando se modifique el código, mantener siempre actualizados los
comentarios circundantes.
� Al principio de cada rutina, resulta útil hacer comentarios estándar,
repetitivos, que indiquen el propósito de la rutina, las suposiciones y las
limitaciones. Un comentario repetitivo podría consistir en una breve
introducción que explicara por qué existe y qué puede hacer.
� Evitar añadir comentarios al final de una línea de código, porque lo
hacen más difícil de leer. Sin embargo, los comentarios de final de línea
sí son apropiados al anotar declaraciones de variables.
� Evitar los comentarios recargados, como las líneas enteras de
asteriscos. En su lugar, utilice espacios para separar los comentarios y
el código.
� Antes de la implementación, eliminar todos los comentarios temporales o
innecesarios, para evitar cualquier confusión en la futura fase de
mantenimiento.
� Usar frases completas cuando escriba comentarios. Los comentarios
deben aclarar el código, no añadirle ambigüedad.
� Usar los comentarios para explicar el propósito del código. No usarlos
como si fueran traducciones literales.
89
� Realizar los comentarios en un estilo uniforme, respetando una
puntuación y estructura coherentes a lo largo de toda la aplicación.
� Cada declaración de variable importante debe incluir un comentario en la
misma línea que describa el uso de la variable que se declara.
� Después de la secuencia de continuación de línea no puede escribirse
un comentario en la misma línea.
� Todos los comentarios deben estar ortográficamente bien escritos, una
escritura incorrecta demuestra un desarrollo negligente.
� Evitar comentarios que expliquen cosas obvias, en la mayoría de las
cosas el código debe ser autoexplicativo.
3.3.2.4 Formato.
El formato hace que la organización lógica del código sea más clara. Si nos
tomamos el tiempo de comprobar que el código fuente posee un formato
coherente y lógico, resultará muy sencillo descifrarlo.
A continuación mencionaremos las pautas para establecer el formato:
� Evitar albergar múltiples clases en un solo archivo.
� Establecer un tamaño estándar de sangría (por ejemplo, cuatro espacios
o una tabulación).
� Usar un único tipo de letra cuando publique versiones impresas del
código fuente.
Una clase debe estar definida en orden descendente de la siguiente manera:
Variables Miembro, Constructores, Enumeraciones, Estructuras o Clases
anidadas, Propiedades y por ultimo los Métodos.
La secuencia de declaración de acuerdo a los modificadores de acceso debe
ser la siguiente:
public protected internal private
90
1) Alinear verticalmente las llaves de apertura y cierre de cualquier bloque:
2) Establecer una longitud de línea máxima para el código.
3) Siempre que sea posible, no colocar más de una instrucción por línea, a
excepción de los bucles.
4) Al escribir en HTML, establecer un formato estándar para las etiquetas y
los atributos; como por ejemplo, las etiquetas siempre en mayúscula y
los atributos en minúscula.
5) En SQL utilice mayúsculas para las palabras clave: SELECT, UPDATE,
WHERE, FROM, etc.
6) Colocar las cláusulas SQL principales en líneas separadas, de modo
que las instrucciones sean más fáciles de leer y editar:
7) Evitar llamadas a métodos dentro de sentencias condicionales.
8) Evitar utilizar recursividad, usar mejor ciclos for anidados.65
3.4 Prueba de Construcción.
En ésta etapa intervienen solo los desarrolladores, los cuales actúan sobre un
código fuente congelado, por lo que están restringidos a agregar nuevas
funcionalidades y la imposibilidad de realizar grandes modificaciones a las
interfaces gráficas de usuario. Los procesos de prueba o testing 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.
65 www.elguille.info/colabora/NET2005/fernandez_EstandarCodificacionNET.htm (21/01/2008) .
Public void Main() { ... }
SELECT Nombre, Apellido FROM Clientes WHERE Fecha= ‘Now.Today’;
91
Prácticamente todos los productos que llegan al mercado son probados: se
"prueban" los materiales que van a forma parte de un producto, se "prueba"
que las partes a ensamblar tienen las dimensiones adecuadas y se "prueba",
por ejemplo, que el producto final tiene la resistencia adecuada.
Es decir, a lo largo del proceso productivo de cualquier producto se hacen
comprobaciones que hacen que el producto final sea el adecuado.
En el caso del software ocurre lo mismo. El proceso de desarrollo de software
consta de una serie de etapas. En cada etapa se van desarrollando y
ensamblando partes que al final van a conformar el producto final.
Al igual que ocurre en un proceso productivo normal, cada una de estas partes
debe ser "probada". Al igual que ocurre en un proceso productivo normal, la
naturaleza y el tipo de pruebas a realizar con el software varía a media que el
desarrollo avanza.
Se puede decir, por lo tanto, que el desarrollo de software es un proceso
productivo como otro cualquiera, con sus características y particularidades. Sin
embargo, y aunque es una realidad que los fallos de software ocasionan graves
pérdidas económicas, el nivel de concienciación en cuanto a la necesidad de
incorporar mecanismos de calidad es muy pequeño.
A pesar de que las pruebas no pueden asegurar la ausencia de defectos, ya
que sólo se puede demostrar que existen defectos en el software, ya que es
hecho por humanos, son parte fundamental antes de entregar el software final.
El esquema general de pruebas finales aplicadas se rige por pruebas de tipo
caja negra que estudia la especificación del software, las funciones que debe
realizar, las entradas y las salidas esperadas. Se detalla a continuación:
Las pruebas se hacen principalmente en función de los requerimientos
determinados. También pruebas técnicas no siempre visibles para el usuario
final, que una vez que son superadas pueden permitir la entrega del software
finalizado.
92
Figura No. 30.- Esquema General de Pruebas.
3.4.1 Módulos independientes.
Las pruebas de módulos independientes se realizan con el objetivo de
encontrar y reparar fallas en el comportamiento de los módulos independientes:
N^o Nombre Entrada Salida esperada Salida real
1 realizar conexión dirección de HW descriptor de socket Socket
2 mover Mouse dirección (v , , ) moverse x,y OK
3 info disponible id disponible info dispositivo info OK
4 guardar registro msg, fecha Registro OK
3.4.2 Pruebas de carga y rendimiento.
Tiene por principal objetivo probar el funcionamiento del software bajo
condiciones extremas. Estudia la especificación del software, las funciones que
debe realizar, las entradas y las salidas analizando los Valores Límite (AVL).
Tipo Condición Rendimiento
Consumo energético conexión activa 12 horas continuado
Cobertura conexión activa máxima 30 metros
Tasa de ejecución Peticiones de ejecución Percepción de ejecución en
tiempo real
93
Prueba de validación.- El software totalmente ensamblado se prueba como un
todo para comprobar si cumple los requisitos funcionales y de rendimiento,
facilidad de mantenimiento, recuperación de errores, etc.
Prueba de aceptación.- El usuario comprueba en su propio entorno de
explotación si acepta el software como está o precisa ser necesario aplicar
nuevas optimizaciones y soluciones de fallas.
Las pruebas de rendimiento, tanto el uso CPU, uso memoria, ping a distancias
y otras variables son aceptables para una ejecución fluida y de excelente
percepción para el usuario final.
Figura No. 31.- Diagrama de Errores.
3.4.3 Subcontratación de pruebas.
Tras haber comprobado las innegables ventajas que un buen proceso de
pruebas ofrece, y siendo conscientes de que gestionar de forma eficaz un
proceso de pruebas requiere de formación y experiencia específica, las
empresas dedicadas al desarrollo de software están optando, de forma
creciente, por la subcontratación de esta tarea.
94
Las ventajas que la subcontratación ofrece a las compañías son amplias:
disponer de personal formado en cualquier momento; poder usar, sin tener que
comprar las herramientas más avanzadas, un proceso de pruebas sistemático,
automatizado y repetible; y disponer de información actualizada que nos
permita tener control sobre el proyecto.
Está claro que en esta época de implantación masiva y generalizada de los
sistemas de gestión de la calidad en todos los sectores de nuestra economía,
el sector de desarrollo de software no puede permanecer ajeno a estas
demandas del mercado. Es por tanto que, siendo el proceso de pruebas un
factor clave en el aseguramiento de la calidad de las aplicaciones informáticas,
resulte cada vez más común y recomendable la subcontratación de los
procesos de prueba.66
3.5 Reusabilidad.
La Reusabilidad se puede definir como:
“Cualquier procedimiento que produce o ayuda a producir un sistema
mediante el nuevo uso de algún elemento procedente de un esfuerzo de
desarrollo anterior.”67
3.5.1 Beneficios de la Reusabilidad.
� Es la única aproximación realista para llegar a los índices de
productividad y calidad que la industria del Software necesita.
� Mejora de la productividad.
� Disminución tiempo de desarrollo.
� Mejor adaptación requisitos cambiantes.
� Disminución de costos.
� Mejora de la calidad del Software.
� Mayor fiabilidad.
� Mayor eficiencia.
66 www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-software.shtml (25/01/2008). 67 RogerS. Pressman. “Ingeniería del Software –Un enfoque práctico”. 4ª Ed.Mc Graw-Hill. P. 460.
95
Figura No. 32.-Modelo de procesos con Reusabilidad.68
Las experiencias de la industria en reusabilidad del software, demuestran que
esta no depende específicamente de aspectos tecnológicos sino de aquellos
organizativos y de motivación. No obstante las tecnologías pueden ayudar al
respecto. Se describe como la orientación a objetos y contribuye en los
diferentes niveles de reusabilidad: bibliotecas de clases, patrones de diseño y
arquitecturas.
En primer lugar hay que separar lo que se entiende por reusabilidad individual y
oportunista de la reusabilidad a nivel empresa o sistemática.
La reusabilidad a nivel individual o de pequeños grupos de desarrollo no es en
realidad nada nuevo y desde siempre los programadores han realizado corta-
pega de trozos de código para ahorrarse trabajo de programación.
En otros casos se han utilizado bibliotecas de rutinas, principalmente
matemáticas que han dado buenos resultados pero sin lograr el objetivo
principal de la reusabilidad, la disminución substancial de los costes de
desarrollo y mantenimiento, y la mejora de los tiempos de desarrollo.
68 Ibid.
96
Para lograr de una manera efectiva los anteriores objetivos es necesario un
planteamiento a nivel de empresa de reusabilidad sistemática.
La reusabilidad sistemática se basa en un conocimiento y modelado del
dominio de aplicación de interés para la empresa o sus clientes, sea este el
financiero, control de procesos industriales, gestión de red o aviónica.
Para la realización del modelado del dominio del problema se utilizan técnicas
de análisis de dominio, algunas de ellas se basan en los principios de
adquisición y representación del conocimiento desarrollado dentro de la
Inteligencia Artificial, otras utilizan principios parecidos a los del análisis de
sistemas donde hay mucha experiencia en la industria.
La biblioteconomía, ha sido también muy útil. La obtención de la representación
del dominio en el ámbito del problema, lleva a la búsqueda de soluciones de
éste. Se desarrollan entonces arquitecturas de referencia que permiten
desarrollar implementaciones de aplicaciones en el ámbito del dominio de la
aplicación.
Estas arquitecturas de referencia se pueden apoyar en bibliotecas de
programas sean estas rutinas o clases dependiendo de las metodologías de
desarrollo software que se utilicen.
3.5.2 Factores de la Reusabilidad.
Soporte de la dirección.- Las decisiones en la utilización de procesos de
desarrollo de software, herramientas, y lenguajes, así como las inversiones en
formación, construcción de activos reutilizables y adaptación de la organización
son inviables sin un apoyo explícito de la alta dirección.
Cambios en la organización.- La reusabilidad sistemática conlleva la división
del personal de desarrollo en dos grupos principales con funciones distintas.
97
El grupo de Ingeniería de Dominio, que construye los activos reutilizables, sean
estos modelos del dominio, bibliotecas, arquitecturas o generadores de
aplicaciones, y el grupo de Ingeniería de Aplicación, que construye aplicaciones
con los activos reutilizables existentes en la organización.
Cambios en el personal.- La formación y los incentivos son útiles para cambiar
prácticas habituales en el personal y disminuir la desconfianza en la utilización
de código desarrollado por otros como parte del suyo propio.
Por consiguiente los mayores beneficios se obtendrán de la unión de factores
organizativos (personal y procesos) y tecnológicos (orientación a objetos). En
esto se puede afirmar que no hay diferencias substanciales con los principios
que rigen la mejora del desarrollo software.
3.5.3 Niveles de Reusabilidad.
La adopción de reusabilidad en una organización ha de seguir una evolución
incremental donde se parte de soluciones tecnológicas mas simples como las
bibliotecas de clases a soluciones de mayor complejidad como son las
arquitecturas de referencia.
Las cinco etapas en la evolución de la reusabilidad son:
Corta-Pega.- En esta primera etapa o fase de la evolución, la organización trata
de disminuir los tiempos de desarrollo mediante la clonación de trozos de
código. Aunque es una solución a primera vista, los problemas aparecen en el
mantenimiento, pues a la hora de realizar cambios hay que ser consciente de
todos los sitios en el código donde estos aplican. Es un problema típico de la
gestión de configuración.
Caja Negra.- En la reusabilidad de caja negra se identifican componentes
software de uso común en la organización. Se garantiza que existe un original
único de ellas. La utilización de bibliotecas y taxonomías de clasificación puede
ayudar en esta fase de la evolución de la organización.
98
Activos Reutilizables.- En esta fase la organización considera otros activos
reutilizables distintos del código. Entre estos destacan principalmente los
procedimientos de prueba, las especificaciones, ficheros de ayuda,
herramientas y otros.
Con esta aproximación se incrementa la reusabilidad en las diversas fases del
ciclo de vida del software, no solo en la fase de implementación como ocurría
especialmente en la fase de Caja Negra.
Arquitecturas.- En esta fase se generan componentes reutilizables, que podrían
ser los anteriores, y una arquitectura software que los aglutina , permitiendo
desarrollar aplicaciones en un dominio especifico de negocio, sea este
financiero, control de tráfico aéreo , gestión de red u otros. Las guías para la
creación de arquitecturas de referencia o especificas de dominio de este
proyecto pueden ser utilizadas en dominios de aplicación diferentes.
Reusabilidad sistemática. Se basa en la estandarización de los activos
reutilizables y los procesos para producirlos, la creación de una infraestructura
para la producción de estos activos y los mecanismos organizativos adecuados
para facilitar la reusabilidad de estos.
La separación del personal en grupo de ingeniería de dominio o responsable de
crear y mantener los activos reutilizables y el grupo de ingeniería de aplicación,
responsable de utilizarlos, es un aspecto fundamental en esta fase. 69
3.5.4 Reusabilidad Orientada a Objetos.
Las anteriores consideraciones indicaban que la reusabilidad no depende
esencialmente de aspectos tecnológicos sino también de los organizativos y
otros. No obstante la orientación a objetos ofrece un conjunto de
particularidades que facilitan el desarrollo de la reusabilidad.
69 www.evolutionperu.com/reuse.html (25/01/2008)
99
En esta sección se describen tres niveles de reusabilidad desde el punto de
vista arquitectónico que pueden ser llevados a cabo teniendo en cuenta los
principios de la orientación a objetos. Estos niveles son las bibliotecas de
clases, los patrones de diseño y las arquitecturas. Se plantearan que significan
cada uno de ellos y que aspectos se tendrían en cuenta en su construcción.
3.5.4.1 Bibliotecas de Clases.
En términos generales se define una biblioteca de clases como una colección
de componentes reutilizables relativas a un dominio de aplicación o
independientes de dominio que sirven como elementos constructivos de
aplicaciones.
En principio las bibliotecas de clases más utilizadas son independientes del
dominio de aplicación y suelen ser suministradas por los fabricantes de
compiladores o por terceros. Ejemplos del último caso son las bibliotecas de
tipos abstractos de datos donde se ofrecen abstracciones estructurales de tipo
pilas, colas, listas, bolsas, anillos, etc.
Bibliotecas de clases específicas de dominio también existen. Existen en
dominios diferentes como los financieros, investigación operativa, control de
tráfico aéreo o comunicaciones.
Propiedades de una Biblioteca de Clases reutilizable:
� Completa.- La biblioteca de clases debe proporcionar familias de clases
que tengan un interfaz común pero posibilitando diferentes
implementaciones.
� Adaptable.- Todos los aspectos específicos de la plataforma deben estar
identificados y aislados.
� Eficiente.- Se debe buscar la eficiencia en compilación, permitiendo el
fácil ensamblaje de los componentes y en ejecución, haciendo una
optima utilización de las características del lenguaje.
100
� Segura respecto a los tipos.- Permitiendo que las suposiciones estáticas
respecto al comportamiento de una clase puedan reforzarse por el
sistema de compilación.
� Simple.- La biblioteca debe usar una organización clara y consistente
que facilite la identificación y selección de clases concretas.
� Extensible.- Se ha de admitir la adición de nuevas clases.
El modelo de objetos se basa en cuatro principios fundamentales y tres
secundarios, estos últimos no son esenciales al modelo de objetos.
Los principios fundamentales son:
� Abstracción.
� Encapsulamiento.
� Modularidad.
� Jerarquía.
Los principios secundarios son:
� Tipificación.
� Concurrencia.
� Persistencia.
El creador de una biblioteca de clases tiene que tener en cuenta como son
soportados estos principios en el lenguaje de programación utilizado y en
función de ello definir una estrategia para implementar los aspectos variables
del dominio en las diferentes clases.
Los puntos de variabilidad de los componentes son aquellos aspectos que
denotan particularidades que distinguen a las aplicaciones dentro del dominio.
Se pueden utilizar diversas técnicas de la orientación a objetos para permitir la
implementación de la variabilidad en los componentes. Las técnicas posibles
son:
� Especialización.- Utilizando los mecanismos de herencia soportados por
el lenguaje.
� Extensión.- Utilizando la composición de componentes.
101
� Parametrización.- Esta técnica permite definir un tipo sin especificar
todos los otros tipos que este usa. Los tipos no especificados son
suministrados como parámetros en el punto de uso.
La herencia permite definir la implementación de una clase en términos de otra.
Esta reusabilidad se le suele denominar de "caja blanca" porque permite que
las interioridades de los ancestros sean conocidas por sus descendientes.
La herencia se define estáticamente en tiempo de compilación y es
relativamente fácil de aplicar. La herencia tiene el inconveniente que en cierta
medida no cumple el principio de encapsulamiento, por lo que ha de ser
utilizada con precaución.
La composición es una alternativa a la herencia. En la composición se obtiene
una nueva funcionalidad ensamblando o componiendo objetos. Esto requiere
que los objetos tengan bien definidas sus interfaces.
Se suele conocer como reusabilidad de "caja negra" porque los objetos no
conocen los detalles internos de los otros. La composición se puede realizar en
tiempo de ejecución.
Si se favorece la composición sobre la herencia se pueden tener en la
biblioteca de clases, jerarquías de clases más pequeñas y fáciles de manejar.
La delegación es la forma de permitir que la composición sea tan poderosa
para la reusabilidad como la herencia. En la delegación, dos objetos están
involucrados en manejar una misma petición. Un objeto receptor y un delegado.
El receptor se pasa a si mismo al delegado para permitir que la operación del
delegado se refiera al receptor.
La principal ventaja de la delegación es que permitiría cambiar la conducta de
la ventana en tiempo de ejecución. Por ejemplo una ventana se haría circular
simplemente remplazando el objeto rectángulo por un objeto círculo,
suponiendo que ambos tuvieran el mismo tipo.
102
Los tipos parametrizados, también conocidos como genéricos (Ada,Eiffel) o
plantillas (C++) , permiten definir un tipo sin especificar todos los tipos que éste
usa. Estos serán suministrados como parámetros en el punto de instanciación.
Los cambios son realizados por tanto en tiempo de compilación. Los tipos
parametrizados se utilizan especialmente para implementar tipos abstractos de
datos: pilas, colas, anillos , bolsas y otros que permiten almacenar distintos
tipos de elementos según sean instanciados en tiempo de compilación.
La figura 33 describe un diseño de una aplicación para ordenar mensajes de
correo electrónico por orden de llegada y prioridad. Para lo cual se utiliza una
biblioteca de clases, plantillas en C++, donde se encuentran los tipos
abstractos cola y cola con prioridades, esta última es un descendiente del
anterior.
Se crea un ejemplar de cola con prioridades para manejar mensajes. Un
descendiente de éste es el componente para gestionar mensajes de correo que
se ha realizado para cubrir los requisitos de la aplicación.
Figura No. 33.-Diseño de Aplicación para Ordenar Mensajes.70
70 www.es.wikipedia.org/wiki/Mantenimiento_de_software (12/12/2008).
103
3.5.4.2 Polimorfismo.
El polimorfismo consiste en dar el mismo nombre a servicios implementados en
diferentes objetos, estos servicios pueden implementarse diferentemente pero
producirán el mismo tipo de resultados. Se utiliza el polimorfismo cuando se
quiere enviar el mismo mensaje a diferentes objetos sin saber el objeto
específico al que se le está enviando el mensaje.
Existen 2 formas de polimorfismo:
� Ad Hoc.- Es la sobrecarga de operadores, donde una función es llamada
basándose en su firma definida como la lista de tipos de argumentos en
su lista de parámetros.
� Puro. Una clase es subclase de otra. Las funciones disponibles en la
superclase pueden usarse en la subclase. Se puede tener distinta
implementación de la función en la subclase. La función a utilizar se
determina dinámicamente en tiempo de ejecución. esto se conoce como
ligadura dinámica y se consigue en C++ con el uso de funciones
virtuales.
3.5.4.3 Clasificación de Clases.
Un aspecto no específico de la orientación a objetos pero de interés para la
reusabilidad es la clasificación de las clases pertenecientes a una biblioteca de
clases. Estas clasificaciones son más necesarias según sea el tamaño de la
biblioteca de clases, es decir cuando se habla de más de cien clases no es fácil
localizar la clase que se necesita en un momento determinado.
Los esquemas de clasificación de componentes software reutilizables que
serían también aplicados a las clases son básicamente dos:
Enumerativos.- Donde se descompone el dominio en clases cada vez más
específicas y restringiendo a la vez el número de ramas de los árboles así
creados.
104
Por Facetas.- Se basa en la síntesis y no en la descomposición del dominio.
Las facetas, cuyo uso proviene también de la biblioteconomía, permiten
clasificar una clase escogiendo el término adecuado para cada una de las
facetas que mejor describa la clase en cuestión.
Los esquemas enumerativos se basan en jerarquías de las clases o
componentes relacionadas con niveles de abstracción, relevancia del dominio,
atributos de la clase o técnicas de creación de ejemplares.
Las facetas se pueden considerar como dimensiones, perspectivas o vistas de
un dominio particular. Para desarrollar un sistema de clasificación por facetas,
se sugiere tener en cuenta dos aspectos: funcionalidad del componente y
entorno en donde realiza su función.
Esto lleva a un conjunto de seis facetas para describir un componente:
� Función.
� Objeto.
� Medio.
� Tipo de Sistema.
� Área Funcional.
� Tipo de Negocio.
Pueden ocurrir problemas de asignación de términos a las facetas o con el
manejo de sinónimos, que llevan a la construcción de tesauros de términos. Se
utilizan también los grafos de distancia conceptual para soportar una medida
objetiva de la similitud conceptual entre los términos de una faceta.
3.5.4.4 Patrones de Diseño.
La utilización de patrones no es una actividad exclusiva del desarrollo software,
precisamente ha sido una práctica habitual en multitud de disciplinas siendo su
utilización en el desarrollo software más bien reciente.
105
En términos generales se puede definir un patrón como una forma realizada,
original, aceptada o propuesta para su imitación: algo dispuesto como ejemplo
a ser copiado o utilizado como prototipo.
En el software desarrollado con las metodologías de orientación a objetos, se
considera un patrón de diseño software a la descripción de un conjunto de
objetos y clases que se comunican entre si y que pueden ser adaptados para
resolver un problema de diseño general en un contexto particular.
En general, un patrón de diseño tiene cuatro elementos esenciales:
1) Nombre.- Es la identificación que se puede utilizar para etiquetar un
problema de diseño, su solución y consecuencias. El nombre de los
patrones, es de gran importancia pues formará parte del vocabulario del
dominio de reusabilidad y nos permitirá trabajar a niveles superiores de
abstracción.
2) Problema.- Describe cuando se puede aplicar el patrón. Se explica el
problema a resolver y su contexto. Se pueden describir problemas
específicos de diseño tales como la representación de algoritmos como
objetos.
3) Solución.- Describe los elementos que conforman el diseño en cuestión,
incluyendo sus relaciones, responsabilidades y colaboraciones. La
solución no describe un diseño particular y concreto o una
implementación, dado que un patrón es como una plantilla que puede
ser aplicada en situaciones diversas. Por consiguiente, un patrón
suministra una descripción abstracta de un problema de diseño y como
una agrupación de elementos constructivos lo resuelven.
4) Consecuencias.- Estas representan las alternativas y resultados de
aplicar el patrón. Aunque a veces en las descripciones de diseños se
obvian las consecuencias, éstas son críticas para evaluar las
alternativas y para determinar los costes y beneficios derivados de
aplicar un patrón.
106
En el desarrollo de sistemas, las consecuencias suelen estar ligadas a
alternativas en tamaño o prestaciones. También se tienen en cuenta aspectos
de lenguaje e implementación. Impacto en la portabilidad, flexibilidad o
escalabilidad del sistema. 71
3.5.4.5 Arquitecturas.
Las arquitecturas o "frameworks" definen un conjunto de elementos
constructivos software que se pueden utilizar, extender o adaptar para la
realización de aplicaciones informáticas específicas.
La construcción de compiladores fue una de los primeros dominios donde se
han realizado arquitecturas. Otros han sido las interfaces gráficas. Actualmente
se están desarrollando arquitecturas en otros dominios como el financiero,
avionica o multimedia.
La arquitectura describe la estructura global de un sistema es decir la partición
de éste en clases y objetos, la asignación de responsabilidades, la
colaboración entre los objetos, y el flujo de control.
La arquitectura captura las decisiones de diseño que son comunes al dominio
de la aplicación. Las arquitecturas enfatizan la reusabilidad a nivel de diseño en
vez de a nivel de código.
Las arquitecturas se diferencian de los patrones en una serie de aspectos:
� Los patrones de diseño son más abstractos que las arquitecturas. Las
arquitecturas están implementadas en código, lo que solo ocurre con los
ejemplos concretos de los patrones. Los patrones se implementan cada
vez que se utilizan.
� Los patrones son más reducidos que las arquitecturas, algunos autores
les denominan microarquitecturas. Una arquitectura puede contener
varios patrones, lo contrario en cambio no es cierto.
71 es.wikipedia.org/wiki/Mantenimiento_de_software/patrones (12/12/2008)
107
� Los patrones son menos especializados que las arquitecturas. Las
arquitecturas tienen siempre un dominio específico de aplicación, en
cambio los patrones pueden ser aplicados en diversos dominios.
Las arquitecturas han de tener una serie de propiedades para favorecer su
reusabilidad:
� Ser Completa.- La arquitectura debe soportar las características
necesitadas por los ingenieros de las aplicaciones y suministrar
implementaciones siempre que sea posible.
� Ser Flexible.- Las abstracciones podrán ser utilizadas en diversos
contextos.
� Ser Extensible.- Los ingenieros de las aplicaciones podrán fácilmente
aumentar o modificar la funcionalidad suministrada. Se suministraran los
mecanismos de adaptación que permitan modificar la conducta de la
arquitectura por herencia o composición.
� Ser Inteligible.- Las interfaces con otros subsistemas están claras y la
arquitectura está bien documentada y sigue estándares de diseño y
codificación.
El dominio de solución que una arquitectura resuelve puede ser el de funciones
de aplicación, funciones de dominio o funciones de soporte.
Las arquitecturas de aplicación conllevan la implementación de una rebanada
horizontal de la funcionalidad de un sistema. Ejemplos de estas arquitecturas
son aquellas para resolver las interfaces gráficas de un sistema.
Las arquitecturas de dominio conllevan la implementación de la solución a los
requisitos de un dominio determinado de aplicación. Conllevan por consiguiente
la implementación de una rebanada vertical de funcionalidad.
108
Las arquitecturas de soporte suministran los servicios a nivel de sistema tales
como aquellos de acceso a ficheros, soporte a computación distribuida o
manejadores de dispositivo.72
Aunque la orientación a objetos no es ni condición necesaria ni suficiente para
obtener beneficios de la reusabilidad, puede contribuir a ésta. Existen diversos
niveles donde la orientación a objetos puede contribuir en la adopción de la
reusabilidad por una organización. Estos son las bibliotecas de clases, los
patrones de diseño y las arquitecturas.
No siempre los aspectos más novedosos o complejos de los lenguajes de
programación, como puede ser la herencia múltiple o la ligadura dinámica son
los que mejor contribuyen a la reusabilidad.
La conjunción de los principios básicos de la ingeniería software con la
implementación adecuada de las variabilidades de un dominio de aplicación ha
dado frecuentemente mejores resultados.
3.6 Calidad en la Construcción.
La calidad en la construcción se define como:
“El conjunto de cualidades que lo caracterizan y que determinan su
utilidad y existencia. Es sinónimo de eficiencia, flexibilidad, corrección,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad.”
La calidad del software es medible y varía de un sistema a otro o de un
programa a otro. 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.
72 www.es.wikipedia.org/wiki/Mantenimiento_de_software/arquitecturas (12/12/2008)
109
La calidad del software puede medirse después de elaborado el producto. Pero
esto puede resultar muy costoso si se detectan problemas deriva dos 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.
La obtención de un software con calidad implica la utilización de metodologías
o procedimientos estándares para el análisis, diseño, programación y prueba
del software que permitan uniformar la filosofía de trabajo, en aras de lograr
una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que
eleven la productividad, tanto para la labor de desarrollo como para el control
de la calidad del software.
3.6.1 Principios Básicos de Calidad.
La política establecida debe estar sustentada sobre tres principios básicos:
tecnológico, administrativo y ergonómico.
El principio tecnológico.- Define las técnicas a utilizar en el proceso de
desarrollo del software.
El principio administrativo.- Contempla las funciones de planificación y control
del desarrollo del software, así como la organización del ambiente o centro de
ingeniería de software.
El principio ergonómico.- Define la interfaz entre el usuario y el ambiente
automatizado. 73
La adopción de una buena política contribuye en gran medida a lograr la
calidad del software, pero no la asegura. Para el aseguramiento de la calidad
es necesario su control o evaluación.
73 www.calidaddelsoftware.com (15/12/2008)
110
3.6.2 Control de Calidad.
Para controlar la calidad del software es necesario, ante todo, definir los
parámetros, indicadores o criterios de medición.
Las cualidades para medir la calidad del software son definidas por
innumerables autores, los cuales las denominan y agrupan de formas
diferentes. Todos los autores coinciden en que 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, se debe establecer el proceso de
control, que requiere los siguientes pasos:
Definir el software que va a ser controlado.- Clasificación por tipo, esfera de
aplicación, complejidad, etc., de acuerdo con los estándares establecidos para
el desarrollo del software.
Seleccionar una medida que pueda ser aplicada al objeto de control.- Para
cada clase de software es necesario definir los indicadores y sus magnitudes.
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 periciales y herramientas automatizadas para medir los criterios de
cálculo.
Definir las regulaciones organizativas para realizar el control.- Quiénes
participan en el control de la calidad, cuándo se realiza, qué documentos deben
ser revisados y elaborados, etc.
El control de calidad del software engloba todo el proceso de desarrollo;
supervisar y mejorar el proceso, asegurar que se siguen los procedimientos
acordados, que se alcanza el nivel de calidad deseado y que se localizan y
resuelven los problemas.
111
Estas son las fases de dicho proceso:
� Análisis.
� Plan general de la prueba.
� Esquema detallado de la prueba.
� Prueba de funcionamiento.
� Prueba de la interfaz de usuario (UI).
� Inspección final del cliente (FCI).
� Herramientas automatizadas.
� Localización y regresión de errores.
� Coordinación de proyectos. 74
3.6.2.1 Gestión de Calidad.
La gestión de la calidad se puede entender como el conjunto de actividades y
medios necesarios para definir e implementar un sistema de la calidad, por una
parte y responsabilizarse de su control, aseguramiento y mejora continua, por
otra.
El control está dirigido al cumplimiento de requisitos, el aseguramiento a
inspirar confianza en que se cumplirá el requisito pertinente y el mejoramiento
al aumento de su eficiencia y eficacia.
La gestión de calidad a nivel de la organización en entidades de software ha
seguido dos líneas que pueden perfectamente complementarse entre sí.
Por una parte, se ha seguido la línea marcada por las entidades internacionales
de estandarización para todos los productos y servicios a través de las normas
ISO 9000 y por otra, el mundo del software ha creado su propia línea de trabajo
en la gestión de la calidad, trabajando sobre los procesos de producción de
software como medio de asegurar la calidad del producto final.
74 es.wikipedia.org/wiki/calidad_de_software (25/01/2008)
112
En los últimos años en que los estándares de calidad internacionales se han
reorientado hacia el aseguramiento de la calidad, han aparecido en la industria
del software dos importantes modelos de referencia que tienen en común la
evaluación de la capacidad de los procesos en niveles de desarrollo o
madurez:
� Modelo CMM (Capability Maturity Model).
� Modelo SPICE (Software Process Improvement and Capability
determination).
Estadísticas del Software Engineering Institute (SEI) reportan que del total de
empresas que aplican CMM el 81 % se encuentra en el nivel 1, el 12 % en el
nivel 2 y el 7 % en el nivel 3. Ninguna ha alcanzado los niveles 4 y 5.
(Tinnirello, 1998). Esto da cuenta de la rigurosidad del modelo y de las pocas
posibilidades que tendría las PYMES de ubicarse en los niveles superiores.
Las grandes empresas ya consolidadas pueden disponer a su voluntad, y de
hecho lo hacen, la implantación de otras metodologías o esquemas propios
para lograr la calidad y la mejora continua de sus procesos productivos.
Sin embargo, para las pequeñas y medianas empresas de software la
implantación de sistemas de la calidad basados en las normas ISO 9000 puede
constituir el mejor camino a seguir pues estas normas definen los requisitos
básicos de la organización y por otro lado la certificación le confiere un prestigio
importante ante sus clientes.
La solución ideal para los que comienzan es integrar ambos enfoques en la
medida de lo posible bajo el principio de especificar en la ISO 9000 todas
aquellas características propias del producto de software que se contemplan en
las otras metodologías. 75
75 Ibid.
113
3.6.2.2 Niveles de Calidad.
Para acometer la gestión de la calidad con resultados intermedios que permitan
a la empresa ir obteniendo madurez en la medida en que avanza la
implantación de las normas, se propone definir 5 niveles, ya no específicos al
proceso de desarrollo del producto como da cuenta el CMM, sino referentes a
la gestión de la calidad a nivel de toda la organización:
� Nivel Inicial.
� Nivel de Proyecto.
� Nivel de Gestión Total de Calidad.
� Nivel de Certificación.
� Nivel de Referencia.
� Nivel Inicial.
Nivel Inicial.-
Toda empresa de software aplica al menos un mínimo control de la calidad de
sus productos y establece algunos parámetros mínimos como requisitos del
producto.
Las empresas que trabajan a este nivel se caracterizan por:
� Definición de políticas elementales de contratación.
� Obtención de las especificaciones de los clientes.
� Formación empírica de equipos de trabajo de acuerdo a la disponibilidad
de personal que se tenga.
� Compromisos de plazos de entrega sin criterios bien fundamentados.
� Uso de herramientas de ingeniaría de software a voluntad de los
desarrolladores.
� Empleo de los lenguajes de programación en que se tiene experiencia,
al no ser que el cliente exija lo contrario.
� Mínima documentación.
� Acta de aceptación del cliente quien generalmente no está en
condiciones de evaluar adecuadamente el producto.
� Deficiente organización del mantenimiento posventa del producto.
114
Nivel de Proyecto .-
En este nivel se incluyen: evaluaciones, revisiones y auditorias, normas,
procedimientos de control y seguimiento de errores, así como el registro de la
información como vía de retroalimentación para la calidad del proyecto.
Algunas acciones importantes que no pueden dejar de realizarse son: asegurar
que los procesos de ingeniería de software sean usados durante todo el ciclo
de vida del proyecto; evaluar mediante métricas, los requerimientos de calidad
de los productos; analizar las pérdidas de calidad para definir acciones para el
mejoramiento continuo del proceso de desarrollo de software.
Nivel de Gestión Total de Calidad.-
Una vez superada la etapa de lograr la calidad en los proyectos, la empresa
estará en condiciones de revisar las normas ISO 9000 de manera detallada y
comenzar a adecuar sus actividades y procesos a los requisitos mínimos que
ellas establecen.
Aquí es importante tener en cuenta:
� Como la norma admite que la documentación puede estar en cualquier
formato o tipo de medio, revisar los diseños de la intranet y de los
sistemas de información digital que minimicen la burocracia del exceso
de documentación con el que generalmente se acompaña la
implantación de estas normas.
� Dentro de la gestión de recursos, prestar la máxima atención a la gestión
del capital humano (gestión del conocimiento a nivel de toda la
organización y control de indicadores de capital intelectual).
� Revisar el proceso de materialización del producto que se definió a nivel
de proyecto a la luz de la norma.
� Conceder especial importancia dentro de la revisión de requisitos
relacionados con el producto a los no explícitos por parte del cliente y a
los de ingeniería de software.
� El control de cambios de diseño y desarrollo mediante los registros
adecuados garantizará la calidad del proceso de mantenimiento del
software.
115
� La propiedad del cliente requiere un respeto riguroso: habrá que precisar
la confidencialidad de la información que se maneja y hasta donde llega
la participación del cliente en el know how no informático del producto.
� La medición, análisis y mejora se da en dos etapas: durante el desarrollo
del software utilizando las métricas que proporcionan los múltiples
modelos existentes y el seguimiento y medición posterior.
� Se requiere implementar adecuados sistemas de satisfacción del cliente
que permita retroalimentarse con el desempeño posterior del producto.
Nivel de Certificación.-
Por la gran variabilidad de los procesos de desarrollo de software, es
importante buscar una estabilidad del nivel anterior antes de pasar a este nivel.
Por otro lado, los procesos de desarrollo de software ocurren en plazos mucho
mayores que los procesos productivos y de servicios convencionales, de ahí
que para demostrar resultados con vistas a la certificación hay que esperar un
tiempo mayor.
Una vez certificada la entidad tendrá que ser capaz en el tiempo de demostrar
su aptitud para mantener la certificación otorgada en las auditorias recurrentes
que establecen las normas.
Nivel de Referencia.-
Existe una tendencia a considerar el proceso de desarrollo de software como
un proceso de I + D lo que no se considera exacto. El verdadero proceso de
investigación y desarrollo se da en el software cuando se trabaja en nuevas
herramientas de ingeniería y en nuevos métodos de trabajo que permitan
obtener resultados superiores.
Las empresas de alto desempeño se convierten en referencia para otras que
comienzan a partir de convertir sus métodos y experiencias en estándares de
trabajo. Por otro lado, el desarrollo de software propicia la producción de
herramientas de ingeniería y de codificación que hacen mas efectivos y
productivos los procesos. 76
76 www.ati.es/gt/calidad-software (25/01/2008)
116
3.7 La Integración.
Un concepto de Integración puede ser:
“Etapa en la cual se utiliza el diseño realizado (código de programación) y
se realiza la unión de las diferentes partes del software. Incluye toda la
documentación necesaria. El resultado de esta etapa es el software en
versión Beta.” 77
La integración de componentes o elementos de software no es un concepto
nuevo.
Lo que ha hecho el software es llevar la integración de software a límites
mucho más extensos. El software libre por su naturaleza ofrece casi todas las
ventajas para construir un negocio basado en integración de software.
Las bases de este tipo de negocio consisten en un potente I+D, capaz de
conocer y analizar la mayoría de las herramientas disponibles basadas en
software libre. De este conocimiento es posible construir aplicaciones a la
medida del cliente mediante la integración de los elementos que más se
adaptan a sus necesidades.
La clave para este tipo de negocios es el desarrollo de software de integración
evitando en la medida de lo posible la modificación de las aplicaciones a
integrar y que permita evolucionar los distintos elementos de la solución final
con el mínimo impacto sobre la solución alcanzada.
Para las soluciones construidas en base a integración de distintas herramientas
es vital la liberación del código desarrollado, sobre todo si la integración ha
requerido la adaptación de alguna de las herramientas utilizadas.
La clave del modelo de negocio es un potente I+D, fundamentalmente
dedicado al análisis de aplicaciones existentes en el mundo del software libre
desde la óptica de la integración, dirigido desde el departamento comercial.
77 www.olea.org/servicios/integracion-software.html (25/01/2008)
117
La solución a las necesidades del cliente se construye generalmente mediante
las siguientes fases:
� Análisis de las necesidades del cliente
� Identificación de los grandes sistemas que integrarán la solución
� Identificación de las necesidades de desarrollo
� Desarrollo de elementos necesarios
� Integración de la solución mediante utilización de estándares LDAP,
SGBD.
La integración se realiza de forma limpia, evitando modificar el código de las
distintas aplicaciones a integrar.
De este modo es posible beneficiarse del proceso de revisión y actualización
de versiones de cada proyecto individual basado en software libre sin realizar
esfuerzos importantes en reintegrar las modificaciones.
En casos en los que es necesario realizar modificaciones a algún proyecto
original, dichas modificaciones deben ser siempre publicadas y enviadas al
proyecto principal, de modo que se garantice la compatibilidad con la solución
global ante futuras revisiones del código.
La integración proporciona una configuración e instalación personalizada de
software (estándar, personalizada o de propiedad) en nuestro entorno de
fábrica. A través de la integración de software empresarial, puede controlar su
servidor para asegurar que el sistema tendrá la misma versión del mismo
software, sin variaciones debido a versiones antiguas de la misma aplicación.
La integración también proporciona una configuración e instalación de software
personalizada, (estándar, personalizada o de propiedad) en nuestro entorno de
fábrica.
118
Los servicios de integración de software incluyen:
� Cargas de imágenes de software del cliente (Windows 2000 / Windows
XP / Windows 9X / NT4 y Linux).
� Cargas de sistema operativo y sistema operativo de red, incluidos
parámetros de sistema operativo personalizados.
� Cargas de aplicaciones de propiedad y de otros proveedores, incluidos
software de copia de seguridad y comunicación de administración de
servidores.
� Configuración de dominio.
� Partición de disco duro.
� Agrupación en clúster personalizada.
� Personalización del sistema, incluida la personalización de parámetros
individuales para que cada uno tenga una dirección IP, un nombre de
ordenador y un identificador de sistema exclusivos.
� Servicios de administración de imagen.
3.7.1 Características.
Las características de esta etapa son las siguientes:
� La integración de los datos y de los sistemas surge como un resultado
directo de la centralización del departamento de sistemas bajo una sola
estructura administrativa.
� Las nuevas tecnologías relacionadas con base de datos, sistemas
administradores de bases de datos y lenguajes de cuarta generación,
hacen posible la integración.
� El costo del equipo y del software disminuye por lo cual está al alcance
de más usuarios.
� En forma paralela a los cambios tecnológicos, cambia el rol del usuario y
del departamento de Sistemas de Información.
� Los usuarios y el departamento de sistema inician el desarrollo de
nuevos sistemas, reemplazando los sistemas antiguos, en beneficio de
la organización. 78
78 www.vsf.es/servicios/integracion.php (25/01/2008)
119
CONCLUSIONES
En la construcción del software se debe tener siempre la idea de que este tiene
que ser lo menos complejo posible, para detectar a tiempo los errores que
puedan presentarse o añadir mejoras a su funcionamiento, para ello es
importante también que exista una documentación de todos los procesos que lo
conforman y que esta sea entendible por todas las personas que intervengan
en el proceso.
Otro aspecto a considerar es el entendimiento del negocio, es decir, que desde
los líderes de proyecto, pasando por los desarrolladores el control de calidad y
la gente que implementa el sistema tenga claros los objetivos del mismo, esto
sin duda beneficiará y hará más fluida la comunicación en cuanto a tiempos,
prioridades y herramientas necesarias.
Existen estándares de construcción aprobados en la Ingeniería de Software
que no se pueden dejar pasar, las aplicaciones que se desarrollen deberán
cumplir con las normas ya establecidas.
También ya se tiene conocimiento que además de los modelos de construcción
tradicionales, existen nuevas técnicas de planeación y desarrollo que se
adaptan a las nuevas tecnologías y que en el caso de las aplicaciones
robustas, son indispensables debido a su flexibilidad y minimización de
complejidad.
En la construcción de software debe existir una arquitectura de medición, es
decir, hasta donde tiene que cumplir su objetivo y hasta donde tiene que estar
limitado, es importante proporcionar herramientas adicionales que quizás no
formen parte de los objetivos principales, pero siempre y cuando estas no
incrementen la complejidad y como consecuencia se entregue un producto
demasiado robusto.
120
La calidad quizás es el factor más importante en la fase de desarrollo, ya que
tiene que servir como filtro antes de la implementación de aplicaciones de
software, las empresas que no cuentan con estándares y procedimientos
eficaces de calidad serán menos productivas y las aplicaciones que desarrollen
serán más susceptibles de caer y por tanto, ser reemplazadas por otras.
Gracias a la integración, se permite la división del trabajo, ya que al principio
cada quien debe de tener sus propias, funciones, los líderes tratan con los
usuarios, la gente de desarrollo se encarga de las construcción, el control de
calidad ejerce sus pruebas de validación, pero al final todos se unen para
formar así un sistema que cumpla con los requerimientos inicialmente
establecidos.
121
BIBLIOGRAFÍA
CAPÍTULO I
Pressman, R.S. Ingeniería del Software. Un enfoque práctico . Mc Graw Hill,
España 6ª ed. 2006. p. 15
2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio
Fuenlabrada Velázquez.
JOHNSON, Bruce. Flexible Software Design. Ed Mc Graw Hill. 2005, pp.440.
E. J. Weyuker, "Evaluación de la Complejidad del Software" Mc Graw Hill, 6ª ed
2001. pp. 1357-1365.
Klir, G.J., Complejidad del Software Aspectos Generales, Prentice Hall, 3ª ed.
México 2003, p. 132-133.
Pleeger. Ingeniería del Software: Teoría y práctica. Pearson Education.México
2003 pp.55.
2006- Tipos de Cambio (Archivo en formato PDF) Profesor: Sergio
Fuenlabrada Velázquez.
Effy Oz, Administración de sistemas de información, 2da ed. Thomson Learning
2001.
A. Toval. Ingeniería del Software. Gestión de Requisitos, ed. DM, España,
1999.
Stair M Ralphm. Principios de sistemas de información,. Thomson Learning 4
Ed 2002.
BOOCH, Grady. Lenguaje Unificado de Modelado. Mc Graw Hill. Año 2000. pp.
464.
SOMMERVILLE, Lan. Ingeniería de Software. Mc Graw Hill. 2008. pp 692.
En Internet:
www.chapters.computer.org/actividades/escenario_const_soft.pdf (25/04/2008).
www.dc.exa.unrc.edu.ar/nuevodc/materias/verificación (25/05/2008).
www.es.wikipedia.org/wiki/Categoría (19/08/2008).
www.fceia.unr.edu.ar/ingsoft/unidad21-4.pdf (19/07/2008).
www.itil.osiatis.es/gestion_de_cambios/proceso_gestion_de_cambios.php
(11/06/2008).
122
www.als-es.com/home.php/ingenieria-software_prevencion_cambio
(30/05/2008).
www.cyberferia.com/elcambio_sw.asp (10/06/2008)
www.gruposeti.com/complejidad_sw.htm (20/04/2008).
CAPÍTULO II
Lawrence, S..Ingeniería del software. Ed. Prentice-Hall, México. 2002.
Ivar Jacobson. El proceso unificado de desarrollo de software. Addison-Wesley
2000.
MEYER,“Construcción del Software Orientado a Objetos”. McGraw-Hill,
2001.pp 480.
Fairley, R.: “Ingeniería del Software”. McGraw-Hill, 2001.pp 165.
JOHNSON, “Flexible Software Design”. McGraw-Hill, 2005.pp 230.
McGarry, J. Optimización práctica del Software. Addison Wesley. 2002. pp 142.
Bernd Bruegge, Allen h. Dutoit. “Ingeniería de Software Orientado a Objetos”.
Prentice Hall. 2002.
Perdita Stevens, Rob Pooley. “Utilización de UML en Ingeniería del Software
con Objetos y Componentes”. Addison Wesley. 2002
Sahri Lawrence Pfleeger. 2002. “Ingeniería de Software. Teoría y Práctica”.
Prentice Hall. Capítulo 7.
En Internet:
www.es.wikipedia.org/wiki/Modelo_de_cascada (11/09/2008).
www.es.wikipedia.org/wiki/Modelo_de_desarrollo_incremental (12/11/2008).
www.es.wikipedia.org/wiki/Modelo_de_desarrollo_evolutivo (12/11/2008).
www.es.wikipedia.org/wiki/Modelo_de_prototipado (12/11/2008)
www.es.wikipedia.org/wiki/Modelo_de_Espiral (12/11/2008).
www.soloarquitectura.com/software (25/11/2008).
www.manycomics.com/ingenieria_software/modelos_actuales (11/10/2008).
www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html (11/10/2008).
www.monografias.com/cicdevida/asml (11/10/2008).
www.monografias.com/cicdevida/case (11/10/2008).
www.monografias.com/cicdevida/xp (11/10/2008).
www.monografias.com/cicdevida/msf (11/10/2008)
www.huma.upm.es/documentacion.html (11/10/2008).
123
www.cognos.com/es/software-de-planificacion.html (25/09/2008).
www.gmv.es/transporte/software_planificacion.htm (30/10/2008).
www.pchardware.org/software/testeo.php (11/11/2008).
www.tracnova.com/softwaredemedicion.htm (01/11/2008).
www.ingenierosoftware.com/calidad (12/11/2008).
CAPÍTULO III
SOMMERVILL. Ingeniería de Software. Mc Graw Hill, 5ª Ed.,2002. pp.560.
RogerS. Pressman. Ingeniería del Software –Un enfoque práctico. 4ª Ed.Mc
Graw-Hill. P. 460.
Pleeger. Ingeniería del Software: Teoría y práctica. Pearson Education..México
2003 pp..55
Effy Oz. Administración de sistemas de información, 2da ed. Thomson Learning
2001 .
Roda, José Luis y Brito, Julio. Introducción a la ingeniería del software.
Gobierno de Canarias, 200.
K. Arnold, J. Gosling, D. Holmes. El lenguaje de programación JAVA. Addison
Wesley, 2001
Beck, K. 2002. Una explicación de la Programación Extrema. Aceptar el
Cambio. Addison Wesley. 2002.
Cabrera, G., Montoya, M. 1999. Análisis y Diseño Detallado de Aplicaciones
Informáticas de Gestión. Ciclo Formativo Grado Superior, McGraw Hill.
En Internet:
www.wikipedia.org/wiki/Lenguaje_de_programación (20/12/2008).
www.lenguajes-de-programacion.com/caracteristicas.shtml (20/12/2008).
www.wikipedia.org/wiki/Paradigma_de_programacion (15/12/2008).
www.rincondelvago.com/informatica_lenguajes_de_programacion (20/12/2008).
Lenguajes-de-programacion.com/clasificacion (25/01/2008).
Farineti.wordpress.com/popularidad-de-lenguajes-de-programacion
(25/01/2008)
www.elguille.info/colabora/NET2005/fernandez_EstandarCodificacionNET.htm
(21/01/2008) .
124
www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-
software.shtml (25/01/2008).
www.evolutionperu.com/reuse.html (25/01/2008)
www.es.wikipedia.org/wiki/Mantenimiento_de_software (12/12/2008).
es.wikipedia.org/wiki/Mantenimiento_de_software/patrones (12/12/2008)
www.es.wikipedia.org/wiki/Mantenimiento_de_software/arquitecturas
(12/12/2008)
www.calidaddelsoftware.com (15/12/2008)
es.wikipedia.org/wiki/calidad_de_software (25/01/2008)
www.ati.es/gt/calidad-software (25/01/2008)
www.olea.org/servicios/integracion-software.html (25/01/2008)
www.vsf.es/servicios/integracion.php (25/01/2008)
