C2 306

INSTITUTO POLITCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA

DE INGENIERA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

CONSTRUCCIN DEL SOFTWARE.

TESIS

QUE PARA OPTAR POR EL TTULO DE:

LICENCIADO EN CIENCIAS DE LA INFORMTICA

P R E S E N T A:

DAVID ARMANDO LEN MAYA

Mxico, D.F. 2010.

INDICE
RESUMEN .......................................................................................................... I
INTRODUCCIN .............................................................................................. IV

CAPTULO I
FUNDAMENTOS DE CONSTRUCCIN DE SOFTWARE

1.1 ESCENARIO PARA LA CONSTRUCCIN 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 TCNICAS 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 METODOLOGA PARA LA PREVENCIN DE CAMBIOS. ................................ 15
1.3.4.1 Especificacin de Lneas Base. .............................................. 16
1.3.4.2 Identificacin de Objetos. ........................................................ 17
1.3.4.3 Control de Versiones. .............................................................. 18
1.3.4.4 Control Estricto de Cambios. .................................................. 20

1.4 CONSTRUCCIN PARA LA VERIFICACIN. ........................................................ 22
1.4.1 MODEL CHECKING (COMPROBACIN DE MODELOS). ................................ 23
1.4.2 INTERPRETACIN ABSTRACTA. ............................................................... 25
1.4.2.1 Testing estructural................................................................... 27

1.5 ESTNDARES EN LA CONSTRUCCIN. ............................................................. 28

CAPTULO II
ADMINISTRACIN DE LA CONSTRUCCIN DEL SOFTWARE

2.1 MODELOS DE CONSTRUCCIN 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 METODOLOGAS DE CONSTRUCCIN EN LA ACTUALIDAD. ................................ 40
2.2.1 METODOLOGA RUP (RATIONAL UNIFIED PROCESS- PROCESO UNIFICADO
RACIONAL). ........................................................................................................ 41
2.2.2 METODOLOGA 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 Implementacin. ................................................ 45
2.2.3 METODOLOGA CASE (COMPUTER AIDED SYSTEMS ENGINEERING). ........ 47
2.2.4 METODOLOGA XP (EXTREME PROGRAMING). ......................................... 49
2.2.5 METODOLOGA MSF (MICROSOFT SOLUTION FRAMEWORK). .................... 51
2.2.6 SELECCIONANDO MODELOS DE CONSTRUCCIN. .................................... 53

2.3 PLANIFICACIN DE LA CONSTRUCCIN. .......................................................... 55
2.3.1 OBJETIVOS DE LA PLANIFICACIN. .......................................................... 57
2.3.2 ASPECTOS ASOCIADOS AL PROYECTO. ................................................... 57
2.3.3 MODELOS DE ESTIMACIN. .................................................................... 61

2.4 MEDICIN DE LA CONSTRUCCIN. .................................................................. 62
2.4.1 ARQUITECTURA DE UN PROCESO DE MEDIDA DE SOFTWARE. .................... 65
2.4.2 MODELO DE PROCESO PARA LA DEFINICIN DE MEDIDAS DE SOFTWARE. .. 67

CAPTULO III
CONSIDERACIONES PRCTICAS

3.1 DISEO DE LA CONSTRUCCIN. ..................................................................... 71
3.1.1 TCNICAS DE DISEO. .......................................................................... 71
3.1.2 DISEO DE INTERACCIONES CON LA BASE DE DATOS. .............................. 72
3.1.3 DISEO DE ARCHIVOS. .......................................................................... 73
3.1.4 DISEO DE LA SALIDA. .......................................................................... 73

3.2 LENGUAJES DE CONSTRUCCIN. .................................................................... 74
3.2.1 CARACTERSTICAS. ............................................................................... 74
3.2.2 PARADIGMAS. ....................................................................................... 75
3.2.2.1 Clasificacin de Paradigmas. .................................................. 76
3.2.3 FACTORES EN LA ELECCIN DE UN LENGUAJE DE CONSTRUCCIN. ........... 77
3.2.4 CLASIFICACIN DE LOS LENGUAJES DE CONSTRUCCIN. .......................... 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 CODIFICACIN. ............................................................................................. 83
3.3.1 ESTNDARES DE CODIFICACIN. ............................................................ 84
3.3.2 TCNICAS DE CODIFICACIN. ................................................................. 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 CONSTRUCCIN. ......................................................................... 90
3.4.1 MDULOS INDEPENDIENTES. .................................................................. 92
3.4.2 PRUEBAS DE CARGA Y RENDIMIENTO. ..................................................... 92
3.4.3 SUBCONTRATACIN 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 Clasificacin de Clases. ........................................................ 103
3.5.4.4 Patrones de Diseo............................................................... 104
3.5.4.5 Arquitecturas. ........................................................................ 106

3.6 CALIDAD EN LA CONSTRUCCIN................................................................... 108
3.6.1 PRINCIPIOS BSICOS DE CALIDAD. ....................................................... 109
3.6.2 CONTROL DE CALIDAD. ....................................................................... 110
3.6.2.1 Gestin de Calidad................................................................ 111
3.6.2.2 Niveles de Calidad. ............................................................... 113

3.7 LA INTEGRACIN. ....................................................................................... 116
3.7.1 CARACTERSTICAS. ............................................................................. 118
CONCLUSIONES .......................................................................................... 119
BIBLIOGRAFA ............................................................................................. 121

I
RESUMEN
CAPTULO I
FUNDAMENTOS DE CONSTRUCCIN DEL SOFTWARE

En este captulo 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 variacin 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 tambin se tienen que considerar en el desarrollo de software,
sentencias y algoritmos sencillos, que permitan la modificacin y optimizacin
de la aplicacin sin complicar el funcionamiento.

Un aspecto fundamental en la prevencin del cambio es el control de
versiones. El control de versiones combina procedimientos y herramientas para
gestionar las versiones de los objetos de configuracin creadas durante el
proceso de ingeniera del software.

Por ltimo se presentarn los estndares de construccin 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 parmetros de
factibilidad y costo de dichas modificaciones.

II
CAPTULO II

La Administracin en la construccin del Software se basa primordialmente en
la consecucin de un objetivo mediante una secuencia de pasos, los modelos
de construccin proporcionan una gua para los ingenieros y desarrolladores de
software con el fin de ordenar las diversas actividades tcnicas 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 slidas que permitan un mejor proceso de Ingeniera.

En la actualidad hay que mencionar que se han creado metodologas que
proporcionan una visin ms 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 Planeacin de la Construccin, la
cual depende de la anticipacin a los problemas que puedan surgir y
preparando con soluciones tentativas a ellos.

El objetivo de la Planificacin del proyecto de Software es proporcionar un
marco de trabajo que permita al administrador hacer estimaciones razonables
de recursos costos y planificacin temporal.

Las medidas y las mtricas son herramientas muy tiles para el control de los
procesos. Un proceso de medidas que acompae al proceso software y se
integre con l, ayuda en la interpretacin, control y mejora de cada una de las
actividades que se llevan a cabo dentro del mismo

III
CAPITULO III

Aqu se detallarn las tcnicas y principios que permiten la realizacin fsica de
un sistema o aplicacin. Las cuales se basan en una serie de etapas de
anlisis y transformacin de la informacin en una arquitectura de programa.

El diseo 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 histricos, o informacin de referencia.

La seleccin de un lenguaje de programacin adecuado facilita la tarea de
programacin, ya que tiene que disponer de formas adecuadas que permitan
ser ledas 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 prctica habitual de todo proceso productivo, que bsicamente
consiste en comprobar que un producto tiene las caractersticas deseadas.

Para controlar la calidad del software es necesario, ante todo, definir los
parmetros, indicadores o criterios de medicin.

IV
INTRODUCCIN

En la actualidad, con el avance de la tecnologa 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 propsito dar a conocer
los diversos escenarios que se presentan al momento de construir aplicaciones
de software, desde la Ingeniera de Requerimientos, la planeacin, el desarrollo
la fase de validacin y la implementacin en ambientes productivos.

Pero adems del desarrollo e implementacin es importante recalcar un
aspecto fundamental en la construccin del software, el mantenimiento del
mismo, ya que durante la explotacin 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.

Tambin resulta fundamental recalcar que debemos de recurrir a herramientas
adecuadas y modelos especficos que nos permitan llevar a cabo un desarrollo
funcional y adecuado para satisfacer los requerimientos, es decir, hacer
anlisis previos y definir con el cliente cual es el objetivo primordial del software
a construir, todo esto con el objetivo de reducir al mnimo la complejidad de
dichas herramientas.

Por ello se debe tener conocimiento de la tecnologa que existe actualmente en
el mercado, no podemos estancarnos en lo que ya existe, parte de la evolucin
siempre ser el buscar el surgimiento de nuevas aplicaciones y estar
capacitado para implementarlas en los ambientes de desarrollo y produccin.

V
No se puede dejar fuera el factor calidad, ya que, adems 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 detallarn las tcnicas adecuadas para integrar en un solo
proyecto de construccin de software todo el anlisis, funcionamiento, calidad y
mantenimiento, ya que adems de adems de la separacin 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
CAPTULO I

FUNDAMENTOS DE CONSTRUCCIN DE SOFTWARE

Para abordar el tema de una manera clara y precisa, se necesita entender el
significado del trmino Construccin del Software, este se define como:

La creacin detallada de software significativo en operacin, a travs de
una combinacin de actividades de prevencin de defectos, codificacin,
verificacin y certificacin de calidad.
1

En la construccin intervienen prcticamente todas las disciplinas de la
ingeniera de software y de la ciencia de la computacin, particularmente el
conocimiento de algoritmos.

Desde luego, de las disciplinas de ingeniera, con las que ms estrechamente
se relaciona la construccin es con el Diseo y la etapa de Evaluacin
(pruebas). Suena redundante, pero aunque el Diseo Detallado se hace antes
de Construir, mucho del diseo se realiza dentro de la actividad misma de la
Construccin.

La construccin produce la mayor parte de los elementos de configuracin que
necesitan administrarse en un proyecto de software, por ello est tambin
estrechamente vinculada a la administracin de la configuracin de software.

Puesto que la construccin de software se apoya fuertemente en herramientas
y mtodos, es la ms intensiva en el uso de herramientas, est conectada a la
Ingeniera de Software, Herramientas y diversas reas del Conocimiento.

Es indispensable tener en cuenta que la calidad es lo ms importante en todas
las actividades del ciclo de vida, y es por ello que donde ms ha de cuidarse
esta es en el cdigo, el cual es la columna vertebral en un proyecto de
software.

1
Pressman, R.S. Ingeniera del Software. Un enfoque prctico . Mc Graw Hill, Espaa 6 ed. 2006. p. 15.

2
1.1 Escenario Para la Construccin del Software.
Todos los proyectos de software comienzan con una peticin del cliente, la cual
nosotros interpretamos como una solicitud de requerimientos. Esta solicitud
puede consistir en solucionar problemas del tipo:

Desarrollar una aplicacin para llevar la administracin de un negocio en
particular.
Elaborar informes que definan un conjunto de objetivos comerciales.
Una especificacin que tiene que asignar una funcin o comportamiento
al software ya existente.

Si existe una peticin para una aplicacin de una de las formas dichas
anteriormente, en la construccin del software se aplican los siguientes pasos:

Paso 1.- Evaluar el requerimiento y determinar si la aplicacin a desarrollar es
una buena herramienta para solucionar el problema en cuestin. A esto es a lo
que comnmente 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 evaluacin 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 representacin abreviada de los requerimientos.

Antes de que pueda comenzar la construccin de un software, debemos
representar de manera genrica las funciones principales y de informacin de
la aplicacin, esto conllevar a desarrollar un mtodo razonable de divisin de
procedimientos (Modulacin).

3
Paso 3.- Despus de que se haya revisado la representacin de los
requerimientos, se crea un conjunto de especificaciones de diseo generales
para el software a desarrollar.

El Diseo debe ocurrir antes de que comience la construccin del software.
Aunque hay que sealar que el diseo se enfoca hacia la arquitectura a nivel
superior, en vez de hacia el diseo de procedimientos detallado.

Paso 4.- El software se desarrolla, se valida y se corrige. Idealmente, los
mdulos de construccin 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 ms fcil 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 representacin implementada de
los requerimientos de la aplicacin, sugerir modificaciones que harn al
producto cumplir mejor las necesidades reales.

Paso 6.- Los pasos 4 y 5 entran en un ciclo repetitivo hasta que todos los
requerimientos estn plasmados en la nueva aplicacin o hasta que el software
haya evolucionado hacia un sistema definitivo.

La construccin del software puede ser conducida con dos objetivos en mente:

1) Requerimientos traducidos en la produccin del programa mediante el uso
de mtodos y tcnicas de programacin.
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 Construccin del Software.
3

Los fundamentos de la Construccin del Software Incluyen:
Minimizar la Complejidad.
Prever el Cambio.
Construccin para la Verificacin.
Estndares en la Construccin.
4

A continuacin se explicar la aplicacin 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 Mquina radica en tener estructuras e
informacin complejas, sobre todo cuando la construccin se realiza durante
los perodos largos de tiempo.

3
2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio Fuenlabrada Velzquez.
4
2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio Fuenlabrada velsquez.
Construccin del
Software
Fundamentos en la
Construccin de Software
Consideraciones
Prcticas
Administracin de la
Construccin
Minimizar la
Complejidad

Prever el Cambio

Construccin para
la Verificacin

Estndares en la
Construccin

Modelos de
construccin
Planificacin de
construccin
Medicin de
construccin
Diseo de
construccin
Lenguajes de
construccin
Codificacin
Prueba de
construccin
Reusabilidad
Calidad de
construccin
La integracin

5
Estrictamente, la Complejidad se define como:

Una propiedad intrnseca de los objetos sin tomar en cuenta la
percepcin de un observador externo.
5

Muchos peligros nuevos son relacionados a la complejidad en los sistemas. Ya
que sta dificulta la identificacin de las causas de los errores.

Una paradoja es que la gente quiere gastar mucho ms dinero en la
complejidad pero no en la sencillez. Las computadoras frecuentemente
permiten construir dispositivos ms interactivos, ms acoplados, y ms
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 ms sencillos hasta los de misin crtica.

Las aplicaciones de software son complejas porque modelan la complejidad del
mundo real. En estos das, las aplicaciones tpicas son muy grandes y
complejas para que un individuo las entienda y, por ello, lleva gran tiempo
implementar software.

Es conveniente hacer un anlisis de la complejidad, sus propiedades, los tipos
de esta que pueden surgir y como resolverlos, a continuacin se detallarn
estos puntos:

1.2.1 Propiedades de la Complejidad.

1) No Negativa.- Siempre existe como parte de un diseo 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 ms 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 mdulos.
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 ms importantes en la
construccin de software: reduccin al mnimo de la complejidad.

La complejidad en la construccin del software se divide en 4 tipos:

Complejidad en el Dominio del Problema.
Complejidad en la Administracin del Proyecto.
Complejidad de Flexibilidad.
Complejidad del Comportamiento.

A continuacin se dar una breve descripcin de cada uno de estos tipos:

Complejidad en el Dominio del Problema.- Existe confusin o falta de
entendimiento entre usuarios y desarrolladores. No hablan el mismo idioma.

6
E. J. Weyuker, "Evaluacin de la Complejiadad del Software" Mc Graw Hill, 6 ed 2001. pp. 1357-1365.

7
Complejidad en la Administracin 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 mdulos del proyecto sin necesidad de ayuda de otros profesionales.

Complejidad del Comportamiento.- Cualquier cambio externo puede afectar el
estado interno de modo ms brusco.
7

1.2.2 Consecuencias de la Complejidad Ilimitada.

Mayor Riesgo.- Entre ms complejo es el sistema, es ms riesgoso
aplicar cambios ya que se puede afectar completamente su
funcionamiento.
Gran Inversin de Tiempo y Recursos Humanos.- Lo cual provoca a su
vez mayor inversin costo-capital y menor productividad ya que
provocara retraso de otros posibles proyectos.
Mayor Planeacin.- Mayor anlisis y diseo de un modelado ms amplio
para minimizar el efecto del mantenimiento y la evolucin.
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 diseamos y controlamos, de forma
intencionada, para resolver algn problema.

En la construccin del software, la reduccin de la complejidad se alcanza
haciendo nfasis en la creacin del cdigo simple y legible en lugar de
inteligente.

7
www.gruposeti.com/complejidad_sw.htm (20/04/2008).

8
La minimizacin de la complejidad se logra con hacer uso estndares y con
tcnicas especficas. A continuacin se explicarn algunas de esas tcnicas.

1.2.3 Tcnicas para Minimizar la Complejidad.

1) El diseo Modular.- Desarrollo paralelo de las diferentes partes de un
sistema; vamos que es ideal para el proceso de codificacin abierta donde
trabajan varias personas en un proyecto.

El Diseo Modular debe de estar basado en el principio de ocultamiento de la
informacin, el cual sugiere que:

Los mdulos se han de caracterizar por decisiones de diseo que los
oculten unos a otros; es decir, deben especificarse y disearse de forma
que la informacin dentro de un mdulo sea inaccesible a otros mdulos
que no necesitan tal informacin.
8

Algunos aspectos importantes de la modulacin son:

Reglas
Correspondencia directa.
Pocas interfaces.
Interfaces pequeas.
Interfaces explicitas.
Ocultacin de la informacin.

Criterios
Descomposicin modular.
Composicin modular.
Comprensibilidad modular.
Continuidad modular.
Proteccin modular.

8
Klir, G.J., Complejidad del Software Aspectos Generales, Prentice Hall, 3 ed. Mxico 2003, p. 132-133.

9
Principios
Unidades modulares lingsticas.
Auto-documentacin.
Acceso uniforme.
Principio de abierto-cerrado.
Eleccin nica.
9

2) La independencia Funcional de los Mdulos.- La cual nace directamente de
la modularidad, de la abstraccin y ocultamiento de la informacin, esto se
puede afirmar que se adquiere desarrollando mdulos con una clara funcin
y que no tengan excesiva interaccin con otros mdulos.

Se trata pues de disear software de forma que cada mdulo se centre en una
funcin especfica 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 fcil de desarrollar porque su
funcin puede ser divida y se simplifican las interfases (con las implicaciones
que conlleva cuando el desarrollo es realizado por un equipo).

Los mdulos independientes son fciles de mantener y de probar ya que limitan
los efectos secundarios, reduce la propagacin de errores y fomenta la
reusabilidad de cdigo.

3) Cohesin.- Se puede definir como una medida de funcionalidad de un
mdulo; es una extensin del concepto de ocultamiento de informacin.

Un mdulo slo debe tener una funcin especfica, en esto consiste la
cohesin, bsicamente se trata de evitar que los mdulos sean solo una
agrupacin de lneas de cdigo y debe de tender a que los procedimientos de
dicho mdulo se concentren en la funcin especfica en el rea de una
estructura de datos para la que fue diseado.

9
Pleeger. Ingeniera del Software: Teora y prctica. Pearson Education.Mxico 2003 pp.55.

10
Un principio para establecer el grado de cohesin nos dice:

Escribir una frase que describa el propsito del mdulo y examinarlo; si
la frase no contiene un objeto especfico sencillo a continuacin del verbo
lo ms normal es que estemos en la banda baja de cohesin.
10

4) Acoplamiento.- Es un grado de interdependencia relativa entre mdulos,
depende de la complejidad de las relaciones entre los mismos, del punto en
el que se hace una llamada al mdulo y de los datos que pasan a travs del
enlace o llamada. El objetivo es lograr una interrelacin sencilla, es decir,
acoplamiento bajo, ms fcil de comprender y menos propenso a una
cadena de errores a lo largo del sistema.

Como conclusin en este sentido minimizar la complejidad significa tener una
cohesin alta y un acoplamiento bajo.

1.3 Prever el Cambio.

La mayora de las aplicaciones cambia en un cierto plazo, y la anticipacin al
cambio maneja muchos aspectos de la construccin 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 ingeniera. Se
basa en el la propiedad de flexibilidad del software. La habilidad del software
para evolucionar requiere de un esfuerzo adicional que implica anticipar cundo
y dnde se pueden requerir los cambios.

El principio de prevencin del cambio se usa para alcanzar las cualidades de
evolucin y reusabilidad. As como el principio de anticipo al cambio tambin se
puede aplicar al proceso de Construccin.

10
Ibid.

11
Aspectos que se deben tomar en cuenta en la prevencin del cambio:

Considerar alteraciones en el personal (Renuencia al cambio).
Considerar los recursos necesarios para mantenimiento (Capacitacin).

Una definicin del cambio en sentido estricto es:

Una alteracin del estado de una entidad (alguien o algo), siendo esta
alteracin generada por un proceso el cual ha sido disparado por el
entorno en el cual se encuentra inmersa la entidad.
11

A continuacin se dar una breve descripcin 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:

Separacin marcada entre un cambio y otro.
No hay nada entre los cambios.
Catastrfico por lo impredecible.

Figura No. 2.- Representacin Grfica 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 separacin entre cambios.
Surgen requerimientos entre los cambios.
Es predecible.

Figura No. 3.- Representacin Grfica del Cambio Continuo.

3) Cambio Discontinuo:

Depende de la escala de observacin.
Se percibe de forma discreta y continua (discontinuo).

Figura No. 4.- Representacin Grfica 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 continuacin:

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

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 Operacin 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
observacin.

Principio de Ocurrencia del Cambio.- Un cambio ocurre en un momento
especfico. 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 Percepcin 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 Alteracin 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 sntomas que presenta la entidad objeto cuando una
entidad sujeto provoca el cambio.
2.- Determinar si la organizacin 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 algn tipo de problema, sobre todo cuando no se
tiene una buena documentacin de las aplicaciones desarrolladas, ya que no
se conoce el funcionamiento total ni la dependencia que puedan tener los
mdulos, 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 diseo del
software, aqu influyen dos aspectos:

1) Requisitos Cambiantes:

Esta causa del deterioro es muy comn. Los requerimientos cambian de forma
por dems significativa de manera que no estaba previsto en el diseo inicial.

A menudo los cambios necesitan hacerse rpidamente y tienen que hacerse
por programadores que no estn familiarizados con el diseo original.
Entonces, aunque los cambios funcionan, violan el diseo original. Poco a poco
los cambios continan y las violaciones se acumulan hasta que el diseo se
rompe.

Pensamiento Sistemtico + Datos + Informacin + Conocimiento

15
An 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 diseo que soporte modificaciones sin
que este pierda su consistencia.

2) Control de Dependencias:

Qu tipos de cambios hacen que un diseo 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 degradacin de las dependencias del diseo de la
arquitectura, deben ser controladas estas mismas por mdulos de una
aplicacin. Este control consiste en la creacin de "cortafuegos" de
dependencias. A travs de estos cortafuegos las dependencias no se
propagan.

El diseo orientado a objetos est repleto de principios y tcnicas que nos
permiten construir estos cortafuegos y controlar estas dependencias.
14

Otros aspectos poco comunes pero que tambin generan cambios pueden ser:

Reorganizacin y/o reduccin del volumen comercial que provoca
cambios en las prioridades del proyecto o en la estructura del equipo de
ingeniera del software.
Restricciones presupuestarias o de planificaciones que provocan una
redefinicin del sistema o del producto.
15

1.3.4 Metodologa Para la Prevencin de Cambios.

Durante el proceso de construccin de un software, los cambios son
inevitables. Los cambios provocan confusin e incertidumbre, sobre todo
cuando no se han analizado o pronosticado correctamente.

14
Effy Oz, Administracin de sistemas de informacin, 2da ed. Thomson Learning 2001.
15
www.als-es.com/home.php/ingenieria-software_prevencion_cambio (30/05/2008).

16
Las actividades de esta metodologa sirven para:

Identificar el cambio del software.
Controlar ese cambio.
Garantizar que el cambio quede bien implantado.
Informar el cambio.

La Metodologa de Prevencin de cambios comprende 4 pasos:

Especificacin de Lneas Base.
Identificacin de Objetos.
Control de Versiones.
Control de Cambios.

A continuacin se detallar cada uno de estos pasos:
1.3.4.1 Especificacin de Lneas Base.

Una lnea base es un concepto de gestin de configuracin del software que
nos ayuda a controlar los cambios sin impedir seriamente los cambios
justificados.

La IEEE define una lnea base como:

Una especificacin 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
travs de procedimientos formales de control de cambios.
16

En el contexto de la ingeniera del software se define una lnea base como un
punto de referencia en el desarrollo del software y que queda marcado por el
envo de uno o ms elementos de configuracin del software y la aprobacin de
esta mediante una revisin tcnica formal.

16
A. Toval. Ingeniera del Software. Gestin de Requisitos, ed. DM, Espaa, 1999.

17
Por ejemplo, los elementos de una especificacin de diseo 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 especificacin de
diseo se convierte en lnea base. Solo se pueden realizar cambios futuros en
la arquitectura del software, tras haber sido evaluados y aprobados. Las lneas
base ms comunes son las que se muestran en la Figura No. 5.

Figura No. 5.- Lneas base.
17

1.3.4.2 Identificacin de Objetos.

Se pueden identificar dos tipos de objetos, los objetos bsicos y los objetos
compuestos. Un objeto bsico es una unidad de texto creada durante el
anlisis, diseo, codificacin o prueba. Un objeto compuesto es una coleccin
de objetos bsicos u objetos compuestos. Cada objeto tiene un conjunto de
caractersticas que los identifican como nicos. El nombre del objeto es una
cadena de caracteres que identifica al objeto sin ambigedad. El esquema de
identificacin de los objetos de software debe tener en cuenta que los objetos
evolucionan a lo largo del proceso de ingeniera, por lo que se puede crear un
grafo de evolucin como se muestra en la Figura No. 6.

17
www.itil.osiatis.es/gestion_de_cambios/proceso_gestion_de_cambios.php (11/06/2008).

Ingeniera del Sistema
Anlisis de Requerimientos
Diseo del Sistema
Codificacin
Pruebas
Sistema en Funcionamiento

18

Figura No. 6.- Grafo de Evolucin.
18

En el grafo de evolucin se describe la historia del objeto y sus cambios, las
grandes modificaciones hacen que un objeto cambie, por lo que cambia el
nmero de versin principal.

1.3.4.3 Control de Versiones.

El control de versiones combina procedimientos y herramientas para gestionar
las versiones de los objetos de configuracin creadas durante el proceso de
ingeniera del software. Esto permite al usuario especificar configuraciones
alternativas de un sistema mediante la seleccin de las versiones adecuadas.
Esto se puede lograr asociando atributos a cada versin del software y
permitiendo luego especificar y construir una configuracin describiendo el
conjunto de atributos deseado.

Estos atributos pueden ser tan sencillos como un nmero especfico de versin
asociado a cada objeto o tan complejos como una cadena de variables lgicas
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 relacin entre componentes,
variantes y versiones es representarlas como un fondo de objetos.

Figura No. 8.- Representacin 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 especficas de un sistema y en la
mecnica del proceso de construccin.

1.3.4.4 Control Estricto de Cambios.
En un gran proyecto de desarrollo de software, el cambio incontrolado lleva
rpidamente al caos. El control de cambios combina los procedimientos
humanos y las herramientas automticas 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 ingeniera
(OCI).La OCI describe el cambio a realizar, las restricciones que se deben
respetar y los criterios de revisin y de auditora.
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 versin del software.

Los procedimientos de altas y bajas implementan dos elementos importantes
del control de cambios: control de acceso y sincrona. El control de acceso
provee los derechos de los ingenieros de software a acceder y modificar
objetos. El control de sincrona asegura que los cambios en paralelo, realizados
por personas diferentes, no se sobrescriben mutuamente.

Figura No. 10.- Control de Acceso y de Sincrona.

20
Stair M Ralphm. Principios de sistemas de informacin,. Thomson Learning 4 Ed 2002.

22
Antes de que un elemento de configuracin se convierta en una lnea base,
slo es necesario aplicar un control de cambios informal. El que haya
desarrollado el elemento en cuestin podr hacer cualquier cambio justificado
por el proyecto y por los requisitos tcnicos.

Una vez que el objeto ha pasado la revisin tcnica formal y ha sido aprobada,
se crea la lnea base.

Una vez que el elemento se convierte en una lnea base, aparece el control de
cambios a nivel de proyecto.
21

Para hacer un cambio, el encargado del desarrollo debe recibir la aprobacin
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) desempea un papel activo en el
segundo y tercer nivel de control. El papel de la ACC es el de tener una visin
general, o sea, evaluar el impacto del cambio fuera del elemento en cuestin.
Todo esto se traduce en los siguientes cuestionamientos:

Cmo impactar el cambio en el hardware? .
Cmo impactar en el rendimiento?.
Cmo alterar el cambio la percepcin del cliente sobre el producto?.
22

1.4 Construccin para la Verificacin.

La construccin para la verificacin significa disear el software de tal modo
que las fallas puedan ser detectadas fcilmente por los ingenieros y
desarrolladores de software, esto se realiza mediante pruebas unitarias y
simulacin de las actividades operativas del cliente.

21
Ibid.
22
Ibid.

23
Las tcnicas especficas que apoyan la construccin para la verificacin
incluyen estndares en la redaccin del cdigo para apoyar sus respectivas
revisiones, pruebas de unidad, pruebas automatizadas, y el empleo restringido
de estructuras complejas o lenguaje difcil de entender entre otros.

La construccin para verificacin tiene dos tareas:
Validacin.- Comprobar que el modelo se construy segn la hiptesis
planteada.
Verificacin.-Comprobar la consistencia de dicho modelo.

La validacin nos permite comprobar que se cumplen las especificaciones del
usuario y la verificacin nos asegura la correccin del sistema.

En pocas palabras, la validacin nos permite hacer pruebas si el modelo que se
ha construido de acuerdo a los estndares establecidos, pero no se comprueba
el funcionamiento, es por ello que se dice que la validacin es emprica.

La verificacin toma los resultados de la validacin para realizar las pruebas
necesarias para concluir si la construccin del software cumple con las
necesidades del cliente y realiza las funciones que debe ejecutar, es por ello
que la verificacin es deductiva.

1.4.1 Model Checking (Comprobacin de Modelos).
La comprobacin de modelos (model checking) se define como:

Una aproximacin especfica para la verificacin eficiente de
propiedades de sistemas concurrentes y reactivos que tiene especial
aplicacin en el rea de los sistemas de estados finitos. Este tipo de
tcnicas 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. Ao 2000. pp. 464.

24
La verificacin de la correccin de un sistema de software puede verse
oportunamente acompaada por el intento de corregir cualquier posible
anomala detectada.

Las tcnicas de depuracin 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 tcnicas de aprendizaje inductivo de programas).

Puesto que tanto la verificacin como la depuracin de programas necesitan
considerar algn tipo de representacin de lenguaje mquina de la semntica
de los sistemas considerados, la interpretacin abstracta, que permite disear,
aproximar y comparar semnticas de programas que expresan varios tipos de
propiedades observables resulta ser un recurso fundamental que se puede
aadir a las tcnicas de verificacin y depuracin.

En la interpretacin abstracta pueden inferirse propiedades que pueden usarse
para implantar condiciones de seguridad, adems del uso tradicional que se
hace en los compiladores para optimizar el cdigo generado estticamente. Por
supuesto, existen muchas similitudes entre todas estas tcnicas en cuanto a
sus objetivos y dominios de aplicacin.

Con la creciente necesidad de mtodos formales giles para el desarrollo
correcto de software cada vez ms complejo (sistemas abiertos, con un nmero
infinito de estados y/o funciones), cobran especial relevancia los mtodos
hbridos que combinan las distintas tcnicas.

Aqu se describir el desarrollo del Model Checking como tcnicas de
verificacin y depuracin que combinan la mejora algortmica, la sntesis de
programas, el anlisis esttico basado en la interpretacin abstracta.

El Model Checking permite comprobar si un modelo dado satisface una
determinada propiedad. Esta tcnica se puede aplicar tanto a sistemas
reactivos como a sistemas hbridos. Existen paradigmas declarativos muy
adecuados para la especificacin de estas dos clases de sistemas.

25
Tanto los sistemas reactivos como los sistemas hbridos estn muy
relacionados con la nocin 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 Interpretacin Abstracta.

La teora de la Interpretacin Abstracta puede ser utilizada para mejorar y
optimizar la tcnica de Model Checking. Usando esta tcnica 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. Ingeniera de Software. Mc Graw Hill. 2006. pp 692.

26
El Model checking se considera un mtodo automtico de verificacin de un
sistema formal, en la mayora de las ocasiones derivado del hardware o del
software de un sistema informtico.

El sistema es descrito mediante un modelo, que debe satisfacer una
especificacin formal descrita mediante una frmula, a menudo escrita en
alguna variedad de lgica temporal. Este modelo suele estar expresado como
un sistema de cambios, es decir, un grafo dirigido, que consta de un conjunto
de vrtices 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 bsicas
que se satisfacen en cada punto de la ejecucin.

Existen herramientas automticas para realizar el Model checking, basadas en
tcnicas combinatorias, explorando el espacio de estados posibles; lo que
conduce al problema de explosin de estados.

Para evitarlo, diversos investigadores han desarrollado tcnicas basadas en
algoritmos simblicos, abstraccin, reduccin de orden parcial y model
checking al vuelo. Inicialmente, las herramientas se disearon para trabajar con
sistemas discretos, pero han sido extendidas a sistemas de tiempo real, o
sistemas hbridos.

Existen 2 tcnicas que podran ayudar a comprobar el funcionamiento del
software:

Tcnicas Estticas.- Usadas para comprobar la correspondencia entre el
software desarrollado y las especificaciones.
Verificacin de Modelos.- Tcnica automtica para verificar sistemas
modelados y especificados con frmulas de una lgica temporal.
27

27
Ibid

27

Figura No. 12.- Diagrama de Verificacin.

1.4.2.1 Testing estructural.

Aqu se utiliza la informacin sobre la estructura interna del programa basada
en la interpretacin abstracta. Se prueba lo que el programa hace, indicando de
forma genrica un subconjunto de caminos a recorrer. Puede automatizarse en
gran medida, pero requiere que haya finalizado la fase de codificacin para que
pueda empezarse a probar. Si se cambia la estructura del cdigo deben
recalcularse los casos.

Figura No. 13.- El ciclo del Testing.
28

28
www.dc.exa.unrc.edu.ar/nuevodc/materias/verificacin (25/05/2008).
Ingeniera
de
Requerimientos
Plan
De
Validacin
Plan de
Verificacin e
Integracin
Plan de
Verificacin de
Componentes

Validacin
Verificacin
e
Integracin
Verificacin
de
Componentes

Arquitectura
Especificacin
de
Mdulos

Diseo
Detallado
Comprobacin Especificacin
Casos de Prueba
a nivel de
Especificacin
Resultados a
nivel de
Especificacin
Resultados a
nivel de
Implementacin
Casos de Prueba
a nivel de
Implementacin
Implementacin
Refinamiento
Extraccin
Sustitucin
Abstraccin
Ejecucin
Ejecucin

28
1.5 Estndares en la Construccin.

1) Uso - Contexto del producto:

ISO/IEC 9126-1: Ingeniera de Software - Modelos de calidad.
ISO/IEC TR 9126-4: Ingeniera de software - Calidad en mtricas de uso.
ISO 9241-11: Guas en Usabilidad.
ISO 20282: Usabilidad en productos de cada da.

2) Interfaz:

ISO/IEC TR 9126-2: Ingeniera de software-Mtricas externas.
ISO 9241: Requerimientos para trabajo en oficinas.
ISO/IEC TR 9126-3: Ingeniera de software-Mtricas internas.
ISO/IEC 10741-1: Interaccin de Dilogo - Control en edicin de textos.
ISO/IEC 11581: Iconos, smbolos y funciones.
ISO 11064: Diseo ergonmico para centros de control.
ISO 13406: Requisitos ergonmicos de trabajo de paneles planos.
ISO 14915: Ergonoma de software para interfaz multimedia.
ISO/IEC 14754: Interfaz de escritura manual.

3) Interaccin:

IEC TR 61997: Guas de interfaz de usuario en equipos de uso general.
ISO/IEC 18021: Interfaz de usuario para dispositivos mviles.
ISO 18789: Requerimientos y sistemas mtricos para pantallas.

4) Documentacin:

ISO/IEC 18019: Guas para diseo y preparacin de documentacin.
ISO/IEC 15910: Documentacin de procesos de software de usuario.

29
5) Proceso de desarrollo:

ISO 13407: Diseo de procesos interactivos.
ISO/IEC 14598: Evaluacin de software.
ISO TR 16982: Mtodos de soporte de diseos centrados en usuarios.

6) Capacitacin de la empresa:

ISO TR 18529: Procesos descriptivos de vida de producto (lifecycle) .

7) Otros ISO:

ISO 9241-1: Introduccin general.
ISO 9241-2: Gua en requisitos de acciones.
ISO 10075-1: Principios de carga mental, trminos y definiciones.
ISO DTS 16071: Gua de accesibilidad en interfaz de usuario.
29

29
www.es.wikipedia.org/wiki/Categora:Formatos_y_estndares_de_software (19/08/2008).

30
CAPTULO II


La Administracin de la construccin comienza con la eleccin de un modelo
de ciclo de vida, el cual define el estado de las fases a travs de las cuales se
mueve un proyecto de desarrollo de software. La Administracin en la
construccin del Software se basa primordialmente en la consecucin de un
objetivo mediante una secuencia de pasos, esta secuencia es proporcionada
por un esquema ya definido y estandarizado, este esquema es comnmente
llamado Modelo de Construccin (Ciclo de Vida) del software.

Resea Histrica.

A fines de los 70s 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 haban seguido esta
metodologa.

Sin embargo, ya desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a
numerosas crticas, debido a que es restrictivo y rgido, lo cual dificulta el
desarrollo de proyectos de software moderno. Es por ello que actualmente,
existe una gama muy basta de Modelos de Construccin 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 transicin asociadas entre estas etapas.
30

30
Lawrence, S..Ingeniera del software. Ed. Prentice-Hall, Mxico. 2002.

31
Caractersticas:

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 definicin de un detallado proceso
de desarrollo de software.

De esta manera, los modelos de construccin proporcionan una gua para los
ingenieros y desarrolladores de software con el fin de ordenar las diversas
actividades tcnicas en el proyecto, en este sentido suministran un marco para
la administracin 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 Construccin Tradicionales.

2.1.1 Modelo Cascada.
El modelo Cascada es el que ha servido como base en la construccin de los
modelos recientes, y sirve como bloque de construccin para los dems
modelos de construccin. La visin del modelo cascada del desarrollo de
software es muy simple; dice que el desarrollo de software puede ser a travs
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 satisfaccin de los
objetivos trazados de dicha fase.

La Figura No. 14 muestra grficamente el flujo de cada una de las fases del
modelo en cascada. Las flechas muestran el flujo de informacin entre las
fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs
representan la retroalimentacin.

32

Figura No. 14.- Modelo de Cascada.
31

El modelo de ciclo de vida cascada, proporciona algunos principios bsicos:

Planear un proyecto antes de establecer un compromiso con el mismo.
Definir el comportamiento externo deseado del sistema antes de disear
su arquitectura interna.
Documentar los resultados de cada actividad.
Disear un sistema antes de codificarlo.
Evaluar un sistema despus de construirlo.

2.1.2 Modelo De Desarrollo Incremental.
El desarrollo incremental es el proceso de construccin que consiste en
incrementar nuevas especificaciones de requerimientos al diseo del sistema
original.

Tpicamente, 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 especfica de observar el
desarrollo de algn otro incremento.

El modelo de desarrollo incremental provee algunos beneficios significativos
para los proyectos de desarrollo de software:

Construir sistemas pequeos.
Si un error importante es detectado, slo el ltimo cambio realizado
necesita ser descartado, es decir, la versin anterior a los ltimos
cambios es la que puede ser utilizada.
Reduccin del tiempo de desarrollo, lo cual evita la redefinicin del
requerimiento.
Los errores de desarrollo cometidos en un incremento o cambio, pueden
ser arreglados antes del comienzo del prximo 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
slo aquellos que son bien comprendidos son seleccionados para el primer
incremento. Los desarrolladores construyen una implementacin parcial del
software que recibe slo estos requerimientos.

El software es entonces desarrollado, se realizan pruebas con la ayuda de los
usuarios para proveer retroalimentacin a los desarrolladores. De esta manera
la especificacin de requerimientos es actualizada, y una segunda versin del
producto es desarrollada. El proceso se repite tantas veces como se necesite
cambiar las reglas o procesos del sistema.

Todo lo que los lderes 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
manipulacin 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 creacin de una implementacin parcial
de un sistema, para el propsito explcito de aprender sobre los requerimientos
del sistema definidos por los usuarios. Un prototipo es construido de una
manera rpida 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 retroalimentacin sobre lo que a ellos les
gust y no les gust acerca del prototipo proporcionado, es entonces cuando
se captura en la documentacin actual de la especificacin de requerimientos
la nueva informacin entregada por los usuarios para el desarrollo ideal del
software.

Muchos usuarios y clientes encuentran que es mucho ms fcil proveer
retroalimentacin convenientemente basada en la manipulacin, desde un
prototipo, en vez de leer una especificacin de requerimientos potencialmente
ambigua y extensa.

A diferencia del modelo evolutivo donde los requerimientos mejor entendidos
estn incorporados, un prototipo generalmente se construye con los
requerimientos entendidos ms 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 podra
responder con "s, as es", y nada podra 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 tambin es
funcional con el Modelo de Desarrollo Evolutivo, de hecho, en combinacin 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 situacin y se
determina que los mayores riesgos son la interfaz con el usuario. Despus de
un cuidadoso anlisis de las formas alternativas de solucionar el problema,
dichas alternativas pueden ser:

Construir un sistema y esperar lo mejor.
Escribir una especificacin de requerimientos.
Construir un prototipo.

35
Ibid.

38
Se lleva a cabo dicha alternativa. Luego se muestra el prototipo al cliente quien
provee con retroalimentacin 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 conclusin de que la mejor es
construir un incremento u opcin alterna del sistema que satisfaga slo los
requerimientos mejor entendidos. Nuevamente se lleva a cabo dicha
alternativa.

Despus del despliegue, el cliente proveer nuevamente de retroalimentacin
que dir si los requerimientos son correctos. El tercer viaje alrededor de la
espiral comienza.

En la Figura No. 19 se observa grficamente 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 contribucin del modelo concurrente es su capacidad de describir las
mltiples actividades del software ocurriendo simultneamente. Los
requerimientos son usualmente "lneas base", cuando la mayora de estos
comienzan a ser bien entendidos, se dedica un esfuerzo considerable en el
tema de diseo. Una vez que comienza el diseo, cambios a los requerimientos
son comunes y frecuentes.

Pero no se debe detener el diseo cuando los requerimientos cambian; existe
una necesidad de modificar y rehacer las especificaciones de los
requerimientos mientras progresa el diseo. Dependiendo del impacto de los
cambios de los requerimientos el diseo puede no ser afectado, medianamente
afectado o se requerir comenzar todo de nuevo.

Durante el diseo 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 diseo detallado en esos
componentes estables. En esta etapa, puede ser posible empezar la
codificacin y quizs establecer una evaluacin de integridad de manera
genrica antes de llevar a cabo el diseo 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 codificacin al componente 3, mientras se realiza diseo
sobre una etapa 4, y especificacin de requisitos sobre un componente 5.

40
En todos estos casos, diversas actividades estn ocurriendo simultneamente.
Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se
posibilita el conocimiento del estado verdadero en el que se encuentra el
proyecto.
37

2.2 Metodologas de Construccin en la Actualidad.

En la actualidad existen nuevas metodologas que permiten hacer un anlisis y
diseo estructurado muy eficiente, entre las ms importantes estn las
siguientes:

Metodologa RUP.
Metodologa ASML.
Metodologa CASE.
Metodologa XP.
Metodologa 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
metodologas de desarrollo, y empezamos a buscar cual sera la ms
apropiada para nuestro caso.

Lo cierto es que muchas veces no encontramos la ms adecuada y terminamos
por hacer o disear nuestra propia metodologa, algo que por supuesto no esta
mal, siempre y cuando cumpla con el objetivo.

Al realizar el diseo del software de manera rgida, cuando el cliente en la
etapa final solicita un cambio, resulta muy difcil realizarlo, pues se alteran
muchas cosas que no habamos 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
modificacin no perjudique al desarrollo del mismo.

A continuacin se explicar el uso de estas nuevas metodologas para dar a
conocer las diferencias entre ellas y as tener una informacin adecuada en
caso de que necesitemos de una de ellas en el desarrollo de un proyecto, de
esta manera podremos elegir la que ms se adapte a nuestras necesidades.

2.2.1 Metodologa RUP (Rational Unified Process- Proceso Unificado
Racional).
La Metodologa RUP, llamada as por sus siglas en ingls Rational Unified
Process, divide en 4 fases el desarrollo del software:

Inicio.- El Objetivo en esta etapa es determinar la visin del proyecto.
Elaboracin.- El objetivo es determinar la arquitectura ptima.
Construccin.- Desarrollar la capacidad operacional inicial.
Transicin.- 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 iteracin se establecen en funcin de la evaluacin de las
iteraciones precedentes.

La Metodologa RUP aplica 2 Disciplinas:

1) Disciplina de Desarrollo.- Contiene las siguientes caractersticas:
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Formalizar las necesidades del negocio.
Diseo: Traslado de los requerimientos a una arquitectura de software.
Implementacin: Creando software que se ajuste a la arquitectura.
Pruebas: Asegurndose que el comportamiento requerido es el correcto.

42
2) Disciplina de Soporte.- Contiene las siguientes caractersticas:

Administracin del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribucin: Hacer todo lo necesario para la salida del proyecto.

La Figura No. 20 nos proporciona una panormica de la Metodologa RUP:

Figura No. 20.- Fases e Iteraciones de la Metodologa RUP.

Cada una de estas iteraciones se debe clasificar y ordenar segn 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 iteracin.
Trabajadores.- Personas o entes involucrados en cada proceso.
Artefactos.- Documento, un modelo, o un elemento de modelo.

43
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se
hace exigente el uso de artefactos, siendo por este motivo, una de las
metodologas ms importantes para alcanzar un grado de certificacin en el
desarrollo del software.

La Metodologa RUP es ms adaptable para proyectos de largo plazo.
38

2.2.2 Metodologa ASML (A System Modelling Language-Sistema de
Lenguaje Modelado).

ASML es una metodologa que integra todas las ideas involucradas en el
anlisis y diseo estructurado. Involucra las tcnicas y herramientas de
modelado usadas en el Anlisis y Diseo Estructurado Moderno.

Los objetivos fundamentales que busca la Metodologa ASML son:

Obtener una buena comprensin del problema.
Disear una solucin de buena calidad.

La Metodologa ASML separa el diseo de un sistema en una jerarqua de
modelos necesarios para comprender diferentes propiedades del mismo.

38
www.manycomics.com/ingenieria_software/modelos_actuales (11/10/2008).

44
Dicha jerarqua de modelos se presenta en la siguiente figura:

Figura No. 21.- Jerarqua de la Metodologa ASML.
39

Como podemos observar, el Modelo del Sistema est dividido en dos modelos
generales:
El Modelo Esencial.
El Modelo de Implementacin.

2.2.2.1 El Modelo Esencial.
Representa la etapa de Anlisis Estructurado. Construccin de un modelo libre
de detalles tecnolgicos. Es la aplicacin de la metodologa de Anlisis
Estructurado Moderno de Yourdon.

39
www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html (11/10/2008).

Modelo
Esencial
Modelo del
Sistema
Modelo de
Implementacin
Modelo del
Usuario
Modelo de
Distribucin
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
Tecnologa Perfecta en la cual no hay restricciones de cantidad de memoria,
tamao del disco o velocidad del procesador.

Dos Componentes conforman el Modelo Esencial:

Ambiente: Declaracin de los objetivos. Creacin de un Diagrama de
Contexto y de una Lista de Eventos, describe las pruebas hechas a un
sistema y los resultados obtenidos. Definicin del Diccionario de Datos
inicial.
Comportamiento: Creacin de un DFD (Diagrama de Flujo de Datos), y
un DER (Diseo Entidad-Relacin) 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 Implementacin.

Representa la etapa de Diseo Estructurado. Instanciacin de un Modelo
Esencial con una Tecnologa dada. A partir de esta etapa, el modelo esencial
es instanciado en una tecnologa dada.

Se debe considerar ahora, las imperfecciones de la tecnologa y determinar los
siguientes aspectos:

La cantidad de procesadores necesarios.
Las cualidades de estos procesadores.
El tamao de disco necesario de acuerdo al volumen de la informacin.

Luego se disea la solucin sobre la base de esas restricciones tecnolgicas.

46
La creacin del Modelo de Implementacin se fundamenta en la creacin de 3
Componentes, uno de ellos en forma independiente (El Usuario o de la interfaz
hombre-mquina) y los otros 2 en forma encadenada en un proceso
incremental de refinamiento e incorporacin de detalles:

Usuario: La interfaz hombre-mquina es modelada en todos sus
detalles, estilo, especificacin y formato de pantallas, formato de
informes y listados, diseo de pantallas para el ingreso de datos y
presentacin de resultados, estilo de mensajes de error, secuencia, etc.
Distribucin: Describe todas las decisiones relativas a la arquitectura de
hardware y a la estructuracin general de la arquitectura de software. Se
incorporan, en los modelos creados hasta este punto algunas
estrategias destinadas a optimizar el uso de esa tecnologa.

Tres Modelos se derivan de la Distribucin:

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 creacin 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 diseada mediante la aplicacin
de las tcnicas y estrategias descriptas por el Diseo
Estructurado.
40

40
www.monografias.com/cicdevida/asml (11/10/2008).

47
2.2.3 Metodologa CASE (Computer Aided Systems Engineering).

CASE plantea una secuencia de etapas ms detallada, y adems proporciona
para cada etapa su descripcin, definicin de objetivos y metas, productos de
la etapa, factores crticos de xito, y la lista de tareas que conviene realizar.
Adems es posible auxiliarse de herramientas CASE que facilitan grandemente
la puesta en prctica del mtodo.

CASE se basa en un anlisis 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 Metodologa CASE.

1) Estrategia.-
Tiene por objetivo lograr un entendimiento claro de las necesidades de la
organizacin y del ambiente en que operar el sistema o sistemas a implantar.

Con el fin de tener una visin de negocio, se analizan las diferentes funciones
que realiza la organizacin y sus necesidades de informacin a todos niveles,
por ello se realizan entrevistas con la direccin y gerentes de departamento.

48
As a partir de esta informacin se realiza as un primer modelado de los
requerimientos del sistema de informacin adecuado a las necesidades de la
organizacin.

2) Anlisis.-
La etapa de anlisis toma y verifica los descubrimientos de la etapa de
estrategia y expande estos en suficiente detalle para asegurar la precisin de
los modelos de la empresa, posibilitando un fundamento slido para el diseo,
dentro del alcance de la organizacin y tomando en cuenta sistemas
existentes.

3) Diseo.-
La etapa de diseo toma los requerimientos y el modelado de la etapa de
anlisis y determina la mejor manera de satisfacerlos, logrando niveles de
servicios acordados, dados el ambiente tcnico y las decisiones previas en los
niveles requeridos de automatizacin. Es decir que del diseo conceptual se
pasa al diseo final que ser utilizado para la implantacin.

Construccin.- A partir del diseo final generado en la anterior etapa, en
esta de construccin, se codificarn y probarn los nuevos programas,
usando herramientas apropiadas.
Documentacin.- Los manuales, resultados de esta etapa, se elaboran a
partir de las especificaciones de diseo, de los programas realizados y
del anlisis 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) Transicin.-
En esta etapa se realizan todas las tareas necesarias para la implementacin y
proporciona un periodo inicial de soporte al sistema. La transicin debe llevarse
a cabo con una interrupcin mnima de la organizacin, 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) Produccin.-
Aqu se asegura que el sistema funcione correctamente en la mayora de los
casos, y con intervencin mnima de los administradores del sistema. Para esto
se realizan nuevas pruebas, se evalan los resultados y se hacen
refinamientos del sistema, los cambios necesarios debern ser introducidos sin
afectar a los usuarios, y deber conseguirse la mxima confianza de los
usuarios. El resultado de esta etapa un sistema listo para su operacin.
41

2.2.4 Metodologa XP (Extreme Programing).
Es una de las metodologas de Construccin de desarrollo de software ms
exitosas en la actualidad utilizados para proyectos de corto plazo, corto equipo
y cuyo plazo de entrega era ayer.

Consiste en una programacin rpida 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 Metodologa XP.

41
www.monografias.com/cicdevida/case (11/10/2008).

50
Caractersticas de XP:

Pruebas Unitarias: se basa en las pruebas realizadas a los principales
procesos, de tal manera que adelantndonos en algo hacia el futuro,
podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si
nos adelantramos a obtener los posibles errores.
Refabricacin: se basa en la reusabilidad de cdigo, para lo cual se
crean patrones o modelos estndares, siendo ms flexible al cambio.
Programacin en pares: una particularidad de esta metodologa es que
propone la programacin en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estacin de
trabajo.

Cada miembro lleva a cabo la accin 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 pequeo y aade funcionalidad con retroalimentacin
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.
Aadir, cambiar o quitar requerimientos en cualquier momento.
Obtener lo mximo de cada semana de trabajo.
Obtener un sistema funcionando cada 3 o 4 meses.

51
Derechos del Desarrollador
Decidir cmo 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 metodologa es:
La comunicacin, entre los usuarios y los desarrolladores .
La simplicidad, al desarrollar y codificar los mdulos del sistema.
La retroalimentacin, concreta y frecuente del equipo de desarrollo,
el cliente y los usuarios finales.

La metodologa XP se recomienda para proyectos de corto plazo.
42

2.2.5 Metodologa MSF (Microsoft Solution Framework).
Metodologa flexible relacionada con una serie de conceptos y prcticas de
uso, que controlan la planificacin, el desarrollo y la gestin de proyectos
tecnolgicos. Se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnolgicas.

Figura No. 24.- Etapas de la Metodologa MSF

42
www.monografias.com/cicdevida/xp (11/10/2008).

52
MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier parte como un
mapa, del cual su uso es limitado a un especfico lugar.
Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas,
as como tambin, proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para desarrollar
soluciones basadas sobre cualquier tecnologa.

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 travs 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, liberacin de versiones y
explicando su relacin con el Modelo de equipo.
Modelo de Gestin del Riesgo.- Proporciona un entorno estructurado
para la toma de decisiones y acciones valorando los riesgos provocados.
Modelo de Diseo del Proceso.- Proporciona un modelo centrado en el
usuario para obtener diseo eficiente y flexible a travs de iteraciones.
Modelo de Aplicacin.- Proporciona un modelo para disear y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son
escalables, y pueden ser usados en una varias computadoras.

La metodologa MSF se adapta a proyectos de cualquier dimensin y de
cualquier tecnologa.
43

43
www.monografias.com/cicdevida/msf (11/10/2008)

53
2.2.6 Seleccionando Modelos de Construccin.

Los modelos presentados, proporcionan una gua con el fin de ordenar las
diversas actividades tcnicas en el proyecto de desarrollo de software e
intentan suministrar un marco para la administracin en el desarrollo y el
mantenimiento. Aunque todos ellos son compatibles unos con otros, un
proyecto puede decidir cules enfoques son ms tiles en situaciones
especiales.

Existe un estudio acerca de los factores que influyen en dicha eleccin; si bien
es cierto este mtodo ofrece gran potencial, necesitara ser ajustado o
actualizado al conocimiento de hoy, principalmente sobre las caractersticas de
los proyectos actualmente en desarrollo.

Este estudio consiste en la proposicin de criterios para proyectos y
aplicaciones especficas, y la creacin de plantillas que describen el perfil ideal
de proyectos convenientes para cada modelo del ciclo de vida. Despus de
crear un perfil para un proyecto en cuestin, el jefe del proyecto necesita slo
encontrar el perfil ideal que ms se acerca.

Entre los criterios incluidos en dicho estudio se encuentran:
Madurez de la aplicacin (relacionado a la probabilidad que muchos
requerimientos comenzarn a conocerse slo despus del uso del
sistema).
Complejidad del problema y de la solucin.
Utilidad de la funcionalidad rpida (parcial).
Frecuencias y magnitudes esperadas de los cambios de requerimientos.
Financiamiento disponible, y su perfil como una funcin del tiempo.
Acceso de los desarrolladores a los usuarios.
Certeza de requerimientos conocidos.

Otros que pueden incluirse:
Tolerancia al riesgo.
Planes y presupuestos crticos.
Grado de lentitud de construccin dentro de los planes y presupuestos.

54
Considerando la importancia de la planificacin 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 planificacin 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 ms influyen en el proceso de desarrollo de software y
que prcticamente acompaa a toda aplicacin es el hecho de que en su
mayora, no hay forma de tener todos los requerimientos corregidos antes del

Muchas veces los requerimientos emergen a medida que la aplicacin o partes
de ella estn disponibles para experimentacin prctica. En todos los casos, el
trabajo comienza con la determinacin de objetivos, alternativas y restricciones,
paso que a veces se llama recoleccin preliminar de requisitos.

El prototipado es ampliamente recomendado para realizar la especificacin de
requerimientos, se debe notar que la idea del prototipado es capturar por
retroalimentacin los objetivos, necesidades y expectativas del cliente por lo
cual no se debe caer en una utilizacin 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 da 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 evolucin 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 decisin 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 creacin de
prototipos y algunos elementos del ciclo de vida clsico, en un enfoque
evolutivo para la ingeniera de software. No hay necesidad por tanto de ser
dogmtico en la eleccin de los paradigmas para la ingeniera de software: la
naturaleza de la aplicacin debe dictar el mtodo a elegir.
44

2.3 Planificacin de la Construccin.

La planeacin efectiva de un proyecto de software depende de la planeacin
detallada de su avance, anticipado problemas que puedan surgir y preparando
con anticipacin soluciones tentativas a ellos.

Se supone que el administrador del proyecto es responsable de la planeacin
desde la definicin de requerimientos hasta la entrega del sistema terminado.
Planificacin del Software se puede definir como:
Es el Proceso de Administracin para la creacin de un Sistema o
software, la cual encierra un conjunto de actividades, una de las cuales es
la estimacin, estimar es echar un vistazo al futuro y aceptamos
resignados cierto grado de incertidumbre. Aunque la estimacin, 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 tcnicas tiles para la estimacin de tiempo. Y dado que la estimacin
es la base de todas las dems actividades de planificacin del proyecto y sirve
como gua para una buena Ingeniera Sistemas y Software.
Al estimar se debe tomar en cuenta no solo del procedimiento tcnico a utilizar
en el proyecto, sino los recursos, costos y planificacin. El Tamao del
proyecto es otro factor importante que puede afectar la precisin de las
estimaciones. A medida que el tamao aumenta, crece rpidamente la
interdependencia entre varios elementos del Software.
Los puntos que se analizarn a continuacin, generalmente son requeridos por
grandes sistemas de programacin, sin embargo estos puntos son validos
tambin para sistemas pequeos.

Panorama.- Descripcin general del proyecto detalle de la organizacin
del plan y resume el resto del documento.
Plan de fases.- Anlisis de requisitos, fase de diseo de alto nivel, fase
de diseo de bajo nivel, etc. Asociada con cada fase debe de haber una
fecha que especifique cuando se deben terminar estas fases..
Plan de Organizacin.- Se definen las responsabilidades especficas 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 Documentacin.- Su funcin es definir y controlar la
documentacin asociada con el proyecto.
Plan de Capacitacin.- Se describe la preparacin de los programadores
que participan en el proyecto y las instrucciones a los usuarios para la
utilizacin del sistema que se les entregue.
Plan de Revisin 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 Instalacin y Operacin.- Se describe el procedimiento para
instalar el sistema en la localidad del usuario.
Plan de Recursos y Entregas.- Se resume los detalles crticos del
proyecto como fechas programadas, marcas de logros y todos los
artculos 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 Planificacin.
El objetivo de la Planificacin del proyecto de Software es proporcionar un
marco de trabajo que permita al administrador hacer estimaciones razonables
de recursos costos y planificacin temporal.
Estas estimaciones se hacen dentro de un marco de tiempo limitado al
comienzo de un proyecto de software, y deberan actualizarse regularmente
medida que progresa el proyecto. Adems las estimaciones deberan definir los
escenarios del mejor caso, y peor caso, de modo que los resultados del
proyecto pueden limitarse.
El Objetivo de la planificacin se logra mediante un proceso de descubrimiento
de la informacin 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 planificacin del proyecto
de Software.
En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al
Software durante la Ingeniera de Sistemas para establecer un mbito de
proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos.

46
www.cognos.com/es/software-de-planificacion.html (25/09/2008).

58
Describe la funcin, el rendimiento, las restricciones, las interfaces y la
fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan
para dar ms detalles antes del comienzo de la estimacin.
Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta
y procesamiento, identifican los lmites 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 estimacin y existen algunos
elementos que se debe tomar en cuenta como es:
La Obtencin de la Informacin necesaria para el software. Para esto el
analista y el cliente se renen sobre las expectativas del proyecto y se ponen
de acuerdo en los puntos de inters para su desarrollo.
2) Recursos.-
La Segunda tarea de la planificacin del desarrollo de Software es la
estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo
de Software, esto simula a una pirmide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de
desarrollo, en segundo nivel de la pirmide se encuentran los Componentes
reutilizables.
Y en la parte ms alta de la pirmide se encuentra el recurso primario, las
personas (el recurso humano).
Cada recurso queda especificado mediante cuatro caractersticas:
Descripcin del Recurso.
Informes de disponibilidad.
Fecha cronolgica en la que se requiere el recurso.
Tiempo durante el que ser aplicado el recurso.

59
Existen diferentes tipos de recursos en la planificacin entre ellos estn:
Recursos Humanos.-
La Cantidad de personas requeridas para el desarrollo de un proyecto de
software solo puede ser determinado despus de hacer una estimacin del
esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y
seleccionar la posicin dentro de la organizacin y la especialidad que
desempeara cada profesional.
Componentes de Software Reutilizables.-
Cualquier estudio sobre recursos de software estara incompleto sin estudiar la
reusabilidad, esto es la creacin y la reusabilidad de bloques de construccin
de Software.
Tales bloques se deben establecer en catlogos para una consulta ms fcil,
estandarizarse para una fcil aplicacin y validarse para la tambin fcil
integracin.
Recursos de Entorno.-
El entorno es donde se apoya el proyecto de Software, llamado a menudo
entorno de Ingeniera 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
prctica de la Ingeniera del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y
verificar que estos recursos estn disponibles.
Muchas veces el desarrollo de las pruebas de validacin de un proyecto de
software para la composicin automatizada puede necesitar un compositor de
fotografas en algn punto durante el desarrollo.
Cada elemento de hardware debe ser especificado por el planificador del
Proyecto de Software.

60
3) Estimacin del proyecto de Software.-
Un gran error en la estimacin del costo puede ser lo que marque la diferencia
entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software
nunca ser una ciencia exacta, son demasiadas las variables: humanas,
tcnicas, de entorno, polticas, 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 estimacin para ms adelante (obviamente podemos realizar
una estimacin confiable despus de haber terminado el proyecto).
Basar las estimaciones en proyectos similares ya terminados.
Utilizar tcnicas de descomposicin relativamente sencillas para
generar las estimaciones de costos y esfuerzo del proyecto.
Desarrollar un modelo emprico para l clculo de costos y esfuerzos
del Software.
Antes de hacer una estimacin, el planificador del proyecto debe comprender el
mbito del software a construir y generar una estimacin de su tamao.
La estimacin basada en el Proceso es una tcnica basada en el proceso que
se va a utilizar, es decir, el proceso se descompone en un conjunto
relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para
llevar a cabo la estimacin de cada tarea.
La estimacin 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 funcin 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 Estimacin.
Existen diferentes modelos de Estimacin como son:
1) Modelos Empricos.-
Donde los datos que soportan la mayora de los modelos de estimacin
obtienen una muestra limitada de proyectos. Por esta razn, el modelo de
estimacin 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 clsico sobre economa de la Ingeniera del Software,
introduce una jerarqua de modelos de estimacin de Software con el nombre
de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo
constructivo de costos. La jerarqua de modelos de Boehm esta constituida por
los siguientes:
Modelo I.- El Modelo COCOMO bsico calcula el esfuerzo y el costo
del desarrollo de Software en funcin del tamao del programa,
expresado en las lneas estimadas.
Modelo II.- El Modelo COCOMO intermedio calcula el esfuerzo del
desarrollo de software en funcin del tamao del programa y de un
conjunto de conductores de costos que incluyen la evaluacin
subjetiva del producto, del hardware, del personal y de los atributos
del proyecto.
Modelo III.- El modelo COCOMO avanzado incorpora todas las
caractersticas de la versin intermedia y lleva a cabo una evaluacin
del impacto de los conductores de costos en cada caso (anlisis,
diseo, etc.) del proceso de ingeniera de Software.
48

48
MEYER,Construccin del Software Orientado a Objetos. McGraw-Hill, 2001.pp 480.

62
3) Herramientas Automticas de Estimacin.-
Las herramientas automticas de estimacin permiten al planificador estimar
costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con
importantes variables del proyecto, tales como la fecha de entrega o la
seleccin del personal. Aunque existen muchas herramientas automticas de
estimacin, todas exhiben las mismas caractersticas generales y todas
requieren de una o ms clases de datos.
A partir de estos datos, el modelo implementado por la herramienta automtica
de estimacin proporciona estimaciones del esfuerzo requerido para llevar a
cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos
casos la planificacin 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. Adems 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 tcnicas referidas anteriormente. Mediante la
comparacin y la conciliacin de las estimaciones obtenidas con las diferentes
tcnicas, el planificador puede obtener una estimacin ms exacta. La
estimacin del proyecto de software nunca ser una ciencia exacta, pero la
combinacin de buenos datos histricos y tcnicas puede mejorar la precisin
de la estimacin.
49

2.4 Medicin de la Construccin.

La Ingeniera del Software ha sido definida como la disciplinada aplicacin de la
ingeniera, la ciencia y los principios matemticos, mtodos, y herramientas
para la produccin de software de calidad.

49
Fairley, R.: Ingeniera del Software. McGraw-Hill, 2001.pp 165.

63
Aqu se incluyen actividades como planificacin, estimacin, modelado, diseo,
construccin o programacin, pruebas, instalacin, mantenimiento y gestin.

Las medidas y las mtricas son herramientas muy tiles para el control de los
procesos. Un proceso de medidas que acompae al proceso software y se
integre con l, ayuda en la interpretacin, control y mejora de cada una de las
actividades que se llevan a cabo dentro del mismo.

Las medidas y mtricas han de ser diseadas para soportar los objetivos de
Negocio de la organizacin para la que son desarrolladas.

Para entender cules son las mejoras crticas en una organizacin, hemos de
ser conscientes de las diferencias entre organizaciones de software maduras e
inmaduras.

En una organizacin de software inmadura, los procesos de software
generalmente son improvisados durante el curso de un proyecto por quienes
los ejecutan y gestionan. En una organizacin 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 organizacin de software madura, posee habilidad y
capacidad en el conjunto de la organizacin para gestionar procesos de
desarrollo y mantenimiento de software. Los procesos estn 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 travs de pruebas controladas y
anlisis costo / beneficio.

A medida que se avanza en la va de una organizacin madura, el proceso
software est mejor definido e implementado de una manera ms consistente.
Para ello se necesita de una infraestructura y de una cultura organizacional
para soportar los mtodos, prcticas y procedimientos de la organizacin.

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 prcticas usuales de la organizacin, como
en la gestin de los proyectos de la misma. La Figura No. 25 muestra el control
de medicin del proceso de un proyecto de Software.

Figura No. 25.- Medicin de Control y Proceso.
50

Han sido desarrollados muchos modelos de gestin de procesos con el fin de
mejorar la calidad y nivel de realizacin de los mismos. El Modelo de
Capacidad de Madurez del Software (CMM), SPICE, ISO9001 y Bootstrap
estn entre los ms extendidos internacionalmente.
51

El concepto de gestin de proceso est fundamentado en los principios del
control estadstico, los cuales sostienen que manteniendo estables los niveles
de variabilidad, los procesos producirn resultados predecibles. La Prediccin
de resultados no debe ser interpretada como obtencin de resultados idnticos,
ya que estos varan respecto de la prediccin, pero cuando un proceso est
controlado, esa variacin estar dentro de lmites 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
prediccin de resultados. Esto permite la preparacin de planes alcanzables, la
estimacin de costes y el establecimiento de compromisos de plazos y fechas.

Por otro lado, la gestin 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 relacin entre las responsabilidades de la
gestin del proceso y del proyecto, as como la integracin de ambas.

Figura No. 26.- Relacin entre gestin del proceso y gestin del proyecto.
52

2.4.1 Arquitectura de un proceso de Medida de Software.
Una posible arquitectura para el diseo y desarrollo de un proceso de medidas
software se muestra en la siguiente figura. Esta arquitectura es genrica y
puede ser implementada en distintos niveles, desde el nivel proyecto hasta el
nivel organizacin.

52
Ibid.

66

Figura No. 27.- Definicin de un Proceso de Medicin de Software.
53

Alineando el proceso de medidas con el proceso de software global, tanto los
proyectos como las organizaciones son capaces simultneamente de recoger y
analizar datos que ayuden a la toma de decisiones respecto de las metas de
los proyectos, y obtener informacin para mejorar el proceso de medidas en s
mismo y el proceso de software en general.

En base a lo anterior una posible definicin del proceso de medicin de
software puede ser la siguiente:

La parte del proceso software que facilita la identificacin, definicin,
recogida y anlisis 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. Optimizacin prctica 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 estndar de la organizacin y deber incorporar componentes como:

Elementos del proceso estndar de la organizacin, y definidos en
trminos operacionales que permitan fcilmente:
Identificar qu datos han de ser recogidos.
Definir cmo son los datos a ser recogidos.
Definir cmo son los datos a ser usados en la toma de decisiones.
Definir cmo es el proceso para la evolucin y mejora tanto del proceso
de medidas como del proceso software.
Recoger y analizar datos.
Tomar decisiones.
Bases de datos de la organizacin y documentacin asociada de
usuario.
Herramientas para definir medidas (formularios, descripciones, recogida
de datos, anlisis, etc.).
Guas y criterios para una definicin 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 cules 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 Definicin 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 informacin 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 implantacin de las medidas. A continuacin se
detallar este paso.

La preparacin de un plan para la implementacin de las acciones que han sido
identificadas. Este plan debera contener al menos los apartados que se
incluyen en la plantilla de la Figura No. 28.

69

Figura No. 28.- Plan de Implementacin de Medidas de Software.

Hay cuatro caractersticas que hemos de considerar bsicas y deben estar
entre las herramientas de gestin del proceso de desarrollo de software:
Tamao.
Esfuerzo.
Duracin.
Calidad.

Estas medidas cubren importantes caractersticas de los productos y el proceso
de software relevante en la planificacin, control y mejora del proceso.
Podemos ver algunas de las medidas y las caractersticas que cubren.

Figura No. 29.- Medidas Especficas.

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
adems son medidas prcticas que producen informacin til.

Cada medida necesita unos atributos para ser definida. Por ejemplo, los
problemas y defectos usualmente estarn clasificados de acuerdo a atributos
tales como estado, tipo, severidad, prioridad, y dnde se producen; el esfuerzo
ser clasificado por horas de trabajo, tipo de trabajo realizado y perfil
profesional de quien lo realiza; la duracin estar definida en trminos de
fechas y criterios de finalizacin; el tamao puede estar definido de acuerdo a
los lenguajes de programacin, el tipo de instrucciones, los mtodos de
produccin, el nmero de entradas al producto software, y el tipo de interfaz
con el usuario.
55

55
www.ingenierosoftware.com/calidad (12/11/2008).

71
CAPTULO III

3.1 Diseo de la Construccin.

El Diseo de la Construccin del Software se define como:

El proceso de aplicar ciertas tcnicas y principios con el propsito de
definir un dispositivo, un proceso o un Sistema, con suficientes detalles
como para permitir su interpretacin y realizacin fsica.
56

La etapa del Diseo encierra cuatro etapas:

1) El diseo de los datos.- Trasforma el modelo de dominio de la informacin,
creado durante el anlisis, en las estructuras de datos necesarios para
implementar el Software.
2) El Diseo Arquitectnico.- Define la relacin entre cada uno de los
elementos estructurales del programa.
3) El Diseo 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 Diseo de Procedimientos.- Transforma elementos estructurales de la
arquitectura del programa. La importancia del Diseo del Software se puede
definir en una sola palabra: Calidad; dentro del diseo es donde se fomenta la
calidad del Proyecto.
3.1.1 Tcnicas de Diseo.
El Diseo de Construccin es un proceso y un modelado a la vez. El proceso
de Diseo es un conjunto de pasos repetitivos que permiten al diseador
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 diseo se evala la calidad del desarrollo del proyecto con un
conjunto de tcnicas:
Debe implementar todos los requisitos explcitos contenidos en el
modelo de anlisis y debe acumular todos los requisitos implcitos que
desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el
cdigo 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 Implementacin.
Debe presentar una organizacin jerrquica que haga un uso inteligente
del control entre los componentes del software.
Debe ser modular, es decir, se debe hacer una particin lgica del
Software en elementos que realicen funciones especficas.
Debe contener abstracciones de datos y procedimientos. As como
producir mdulos que presenten caractersticas de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los mdulos y el entorno exterior.

Estos criterios no se consiguen por casualidad. El proceso de Diseo de
Construccin exige buena calidad a travs de la aplicacin de principios
fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva.

3.1.2 Diseo de Interacciones con la Base de Datos.
La mayora de los sistemas de informacin ya sean implantado en sistemas de
cmputos grandes o pequeos, utilizan una base de datos que pueden abarcar
varias aplicaciones, por esta razn estos sistemas utilizan u administrador de
base de datos, en este caso el diseador 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 Diseo 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
histricos, o informacin de referencia.

Entre las decisiones que se toman durante el diseo 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 caractersticas de los datos
que contenga.
La secuencia a disposicin de los registros dentro del archivo (La
estructura de almacenamiento que puede ser secuencial, indexada o
relativa).
No todos los sistemas requieren del diseo de todos los archivos, ya que
la mayora 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 Diseo de la Salida.
En este caso salida se refiere a los resultados e informaciones generadas por
el Sistema, Para la mayora de los usuarios la salida es la nica razn para el
desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo
cuando se realiza un sistema, como analistas deben realizar lo siguiente:

Determine que informacin presentar. Decidir si la informacin ser
presentada en forma visual, verbal o impresora y seleccionar el medio
de salida.
Disponga la presentacin de la informacin en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios.
58

57
SOMMERVILL. Ingeniera de Software. Mc Graw Hill, 5 Ed.,2002. pp.560.
58
www.wikipedia.org/wiki/Ingeniera_del_diseo/tecnicas (09/12/2008).

74
3.2 Lenguajes de Construccin.
Definimos Lenguaje de Construccin como:

Un lenguaje que puede ser utilizado para controlar el comportamiento de
una computadora. Consiste en un conjunto de reglas sintcticas y
semnticas que definen su estructura y el significado de sus elementos,
respectivamente.
59

3.2.1 Caractersticas.
Los lenguajes de programacin facilitan la tarea de programacin, ya que
disponen de formas adecuadas que permiten ser ledas y escritas por
personas, a su vez resultan independientes del modelo de computador a
utilizar.

Los lenguajes de programacin representan en forma simblica y en manera
de texto los cdigos que podrn ser ledos por una persona. Los lenguajes de
programacin son independientes de las computadoras a utilizar.

Existen estrategias que permiten ejecutar en una computadora un programa
realizado en un lenguaje de programacin simblico. Los procesadores del
lenguaje son los programas que permiten el tratamiento de la informacin en
forma de texto, representada en los lenguajes de programacin simblicos.

Hay lenguajes de programacin que utilizan compilador. La ejecucin de un
programa con compilador requiere de dos etapas:

Traducir el programa simblico a cdigo mquina.
Ejecucin y procesamiento de los datos.

Otros lenguajes de programacin utilizan un programa intrprete o traductor, el
cual analiza directamente la descripcin simblica del programa fuente y realiza
las instrucciones dadas.

59
www.wikipedia.org/wiki/Lenguaje_de_programacin (20/12/2008).

75
El intrprete en los lenguajes de programacin simula una mquina virtual,
donde el lenguaje de mquina 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 ejecucin es
ms lenta ya que debe analizar e interpretar las instrucciones contenidas en el
programa fuente.

Un lenguaje de programacin permite a un programador especificar de manera
precisa: sobre qu datos una computadora debe operar, cmo deben ser estos
almacenados y transmitidos y qu acciones debe tomar bajo una variada gama
de circunstancias. Todo esto, a travs de un lenguaje que intenta estar
relativamente prximo al lenguaje humano o natural, tal como sucede con el
lenguaje coloquial.

Un programa escrito en un lenguaje de programacin necesita pasar por un
proceso de compilacin, es decir, ser traducido al lenguaje de mquina, o ser
interpretado para que pueda ser ejecutado por el ordenador.
60

3.2.2 Paradigmas.

El Paradigma de programacin representa un enfoque particular o
modelo de construccin del software.
61

Los paradigmas determinan radicalmente la forma de abordar los problemas.
Normalmente uno se inclina por el paradigma al que est ms acostumbrado,
ya que todos los paradigmas prcticos son Turing-Completo, es decir, cualquier
computacin realizable se puede llevar a cabo con cualquiera de ellos.

La eleccin del paradigma adecuado para un problema puede reducir
drsticamente el tiempo, el costo y la facilidad con la que se llega a la solucin,
aunque si no se tiene experiencia con el paradigma en cuestin, puede llegar a
ser contraproducente cambiar del que ms 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 Clasificacin 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
clasificacin 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
programacin top-down ya que permita empezar a reutilizar cdigo y
facilitaba enormemente la comprensin de los programas.
4) Orientado a Objetos.- Los datos y las operaciones que actan sobre ellos se
agrupan en "objetos" Es un siguiente paso en la programacin estructurada,
que permite empezar a desarrollar componentes completos reutilizables de
manera fcil.
5) Declarativo.- es el otro gran paradigma. Se trata de especificar los
programas como una descripcin abstracta (de alto nivel) la solucin a un
problema en lugar de detallar paso por paso cmo llegar hasta ella. Este
paradigma es por lo tanto ms sofisticado que el imperativo, ofrece muchas
ventajas al programador, como la posibilidad de comprobar la correccin
formal de los programas, pero tiene como inconveniente que el rendimiento
suele ser peor.
6) Funcional.- Se intenta imitar el lenguaje de las matemticas, expresando
toda la lgica del programa como funciones y composicin de las mismas.
Tiene algunas ventajas importantes, como la ausencia de efectos
secundarios, suele permitir trabajar con tipos infinitos de forma eficiente y
cmoda y presenta muchas soluciones elegantes a problemas tediosos que
se presentan en la programacin estructurada. Ejemplos: Haskell, Erlang.

77
7) Lgico.- Se definen reglas lgicas y luego un motor de inferencia lgico
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 funcin objetivo a optimizar), y un motor de bsqueda proporciona el
conjunto de soluciones posibles (o la solucin ptima). Ejemplos: GAMS,
SQL.
3.2.3 Factores en la eleccin de un Lenguaje de Construccin.

Tamao del lenguaje.- Sin duda es una ventaja que un lenguaje sea
sencillo, ya que facilita su aprendizaje, la comprensin del cdigo
escrito.
Ambigedades.- Es una caracterstica deseable en un lenguaje que
todas las construcciones vlidas tengan una nica interpretacin posible.
Documentacin.- El lenguaje ms 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 ningn 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 segn salen del horno, hay
que tener en cuenta que al tiempo de ejecucin deberamos sumarle el
tiempo de compilacin.
Consumo de memoria.- ya que es un recurso que se suele agotar
bastante ms rpido que el tiempo y un programa que use mucha
memoria probablemente tendr penalizaciones de rendimiento por la no-
localidad de los accesos.
Libreras comunes (estndar).- Otro factor realmente importante es la
cantidad de cdigo que nos podemos ahorrar porque ya lo ha escrito
otro para nosotros. Si encima esas libreras vienen siempre con la
distribucin del lenguaje, nos ahorraremos tiempo buscndolas y
espacio en la distribucin 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 cdigo, mostrndonos la documentacin sin tener que ir
a buscarla, avisarnos de los errores antes de que probemos el
programa, hacer cambios globales al programa (refactorizacin),
permitindonos navegar rpidamente por todo nuestro cdigo, con un
entorno de depuracin integrado, con editores visuales para interfaces
grficas, etc.
Tamao de la comunidad de usuarios.- se supone que cuantas ms
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 cdigo, soluciones a problemas
comunes) y que no genere demasiada basura alrededor del lenguaje.
62

3.2.4 Clasificacin de los Lenguajes de Construccin.
Programacin Imperativa.-

C ALGOL ML PL/1 FORTRAN
BASIC ALGOL1W LOGO SNOBOL BCPL
PASCAL ALGOL 68 LUA COBOL MODULA
ADA CLIPPER OCAML
Programacin 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 Programacin 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 Programacin 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 Programacin Visual.-

VISUAL BASIC VISUAL BASIC.NET DELPHI

Lenguajes de Programacin Concurrente.-

PASCALFC ALEPH OCCAM ERLANG
JOULE SR LANGUAGE PICT

80
Lenguajes de Programacin Lgica.-

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

INTERCAL MALBOLGE BRAINFUCK WHENEVER WIERD
PIET SARTRE BEFUNGE FOTRH
63

3.2.5 Visual Studio.Net VS C#.
3.2.5.1 Visual Studio.NET.

Visual Studio .NET es el nico entorno de programacin creado exclusivamente
para servicios Web XML.

Al permitir que las aplicaciones se comuniquen y compartan datos a travs 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 estndares que permite a los programadores ensamblar
aplicaciones a partir de cdigo nuevo o existente, independientemente de la
plataforma, del lenguaje de programacin o del modelo de objetos.

Las caractersticas de Visual Studio en cualquiera de sus versiones son:
Soporte para XML Web Services.
Diseo de interfases mediante Windows Forms .
Diseo web mediante Web Forms o Mobile Web Forms.
Creacin de aplicaciones para Pocket PC-Windows CE .NET .
Integracin con .NET y el Common Language Runtime (CLR) .
Asistente para actualizacin de cdigo de VB 6.0 a VB.NET .
Creacin de aplicaciones para consola.
Class Library templates.
Librerias para controles Windows y controles Web.
Creacin 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 instalacin de otros lenguajes).
Otras caractersticas a destacar son: un entorno integrado de desarrollo,
un completo depurador, Crystal Reports o un asistente para el diseo
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 integracin 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 propsito de que se recoja en un slo 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 tambin pueden ser abstract y final .
Las interfaces tambin existen en C# .
Cuenta tambin con operaciones lgicas 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 compilacin.
Estructuras similares a C++.
Preprocesador.
Existe la sobrecarga de operadores.

Nuevas Caractersticas de C#
Declaraciones en el espacio de nombres.- cuando se crea un programa,
se puede definir una o ms clases dentro de un mismo espacio de
nombres.
Tipos fundamentales de datos: existe una variedad ms 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 pblico, protegido, interno, interno protegido y privado.
Paso de argumentos: se puede declarar a los mtodos para que acepten
un nmero 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.
Mtodos virtuales y redefiniciones: antes de que un mtodo pueda ser
redefinido en una clase base, debe declararse el mismo como virtual. El
mtodo 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 declaracin 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 annima para
dirigirse al miembro de una clase.
Control de versiones: C# permite a los desarrolladores mantener
mltiples versiones de clases en forma binaria, colocndolas en
diferentes espacios de nombres. Esto permite que versiones nuevas y
anteriores de software puedan ejecutarse en forma simultnea.
64

3.3 Codificacin.
El mejor diseo fcilmente puede corromperse por alteraciones casuales o
incluso bien intencionadas producidas durante la codificacin del software. Los
miembros del equipo de desarrollo encargados del diseo y los encargados de
escribir las lneas de cdigo deben estar en estrecha coordinacin.
Los programadores son los que finalmente estructurarn todas las
preconcepciones plasmadas en los diversos prototipos en las interfaces que
realmente utilizarn 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 diseo 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 codificacin, pues los ingenieros software y programadores suelen tener
un entrenamiento especial en la resolucin de las propuestas enfocadas a la
optimizacin del tamao del cdigo y a la optimizacin de la velocidad de
ejecucin descuidando los aspectos relacionados con la usabilidad y la
accesibilidad e incluso con el diseo grfico de la interfaz.

64
Farineti.wordpress.com/popularidad-de-lenguajes-de-programacion (25/01/2008)

84
Ser importante, pues, que los programadores estn completamente
comprometidos con el seguimiento del modelo de proceso y convencidos de los
beneficios del mismo incluso si no lo entienden o no estn de acuerdo en
algunas decisiones del diseo.
Otro aspecto destacado en este punto ser que los programadores y
diseadores que respectivamente escribirn las lneas de cdigo y dibujarn
los elementos de las interfaces respeten las caractersticas establecidas en el
enorme trabajo realizado en las fases precedentes..
3.3.1 Estndares de codificacin.

Los estndares de codificacin son la bendicin de las prcticas para
desarrollar software. La bendicin y a veces la maldicin. Cuando los
estndares de codificacin 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 estndares adoptados.

El error que no se puede cometer es precisamente adoptar estndares de
codificacin complejos.

Se necesita que estos sean prcticos 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 estndares sean discutidos por todo el equipo.

3.3.2 Tcnicas de Codificacin.

En general una tcnica de codificacin no pretende formar un conjunto
inflexible de estndares de codificacin. Ms bien intenta servir de gua en el
desarrollo de un estndar de codificacin para un proyecto especfico de
software.

85
3.3.2.1 Generales.

Para conservar recursos hay que ser muy selectivo en la eleccin del
tipo de dato, asegurarse que el tamao de una variable no sea
excesivamente grande. Por ejemplo en los ciclos for es mejor, en la
mayora 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 conexin a una Base de Datos.
Usar los procedimientos y variables con un solo propsito. Evitar crear
procedimientos multipropsito 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 informacin en variables de sesin ASP ya que el estado de
sesin es almacenado siempre en una sola maquina, considerar mejor
almacenar dicha informacin en una base de datos.
No abrir conexiones a datos usando credenciales especificas de usuario,
ya que estas no podrn 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 aplicacin (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 clusulas Switch
o Select.

Las tcnicas de codificacin estn divididas en tres secciones:
Nombrado.
Documentacin Interna (Comentarios).
Formato.

86
3.3.2.2 Nombrado.

El esquema de nombres es una de las ayudas ms importantes para entender
el flujo lgico de una aplicacin. Un nombre debe ms bien expresar el "qu"
que el "cmo". Si se utiliza un nombre que evite referirse a la implementacin
se estar conservando la abstraccin de la estructura ya que la implementacin
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 cdigo) es que se supone que hace el
mtodo y no como lo hace.
Otra tcnica es utilizar nombres tan largos como para que se entiendan pero a
la vez tan cortos como para que no den informacin irrelevante, por ejemplo es
mejor emplearSeleccionarComida() que SeleccionarlaComidadelMenu().

Desde el punto de vista de la programacin, un nombre nico sirve solamente
para diferenciar un elemento de otro. Los nombres expresivos funcionan como
ayuda para el lector, por eso, es lgico dar nombres que sean fciles de
comprender. No obstante, se debe garantizar que los nombres escogidos sean
compatibles con las reglas de cada lenguaje y con los estndares.

En el caso de Estructuras:

Los nombres deben ser en espaol.
Los namespaces deben empezar por el nombre de la compaa 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 notacin hngara, la cual prefija una abreviatura
referente al tipo de objeto: lblAceptar (label), btnOK(Botn), etc.
Utilizar la tcnica verbo-sustantivo para nombrar procedimientos que
ejecuten alguna operacin 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 mayscula a excepcin de las variable miembro privadas. Las
Variables internas o de bloque deben ir en minscula.
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
slo en unas cuantas lneas de cdigo, emplee un nombre descriptivo.
Utilizar nombres de variables de una sola letra, como i o j slo para
ndices (ciclos for).
No usar nmeros 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 fciles de mantener y
comprender.
Los parmetros siguen el mismo estndar 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 documentacin de software: externa e interna. La
documentacin externa, como por ejemplo las especificaciones, los archivos de
ayuda y los documentos de diseo, se debe mantener fuera del cdigo fuente.

88
La documentacin interna est formada por los comentarios que los
programadores escriben dentro del cdigo fuente durante la fase de desarrollo.

Uno de los problemas de la documentacin de software interna es garantizar
que se mantengan y actualicen los comentarios al mismo tiempo que el cdigo
fuente.

Aunque unos buenos comentarios en el cdigo fuente no tienen ningn valor en
el tiempo de ejecucin, resultan valiossimos para un programador que tenga
que mantener una parte de software particularmente compleja.

Aqu se mencionarn las tcnicas para la documentacin:

Los comentarios deben ser en espaol.
Si se programa en C#, utilizar la funcin de documentacin XML.
Cuando se modifique el cdigo, mantener siempre actualizados los
comentarios circundantes.
Al principio de cada rutina, resulta til hacer comentarios estndar,
repetitivos, que indiquen el propsito de la rutina, las suposiciones y las
limitaciones. Un comentario repetitivo podra consistir en una breve
introduccin que explicara por qu existe y qu puede hacer.
Evitar aadir comentarios al final de una lnea de cdigo, porque lo
hacen ms difcil de leer. Sin embargo, los comentarios de final de lnea
s son apropiados al anotar declaraciones de variables.
Evitar los comentarios recargados, como las lneas enteras de
asteriscos. En su lugar, utilice espacios para separar los comentarios y
el cdigo.
Antes de la implementacin, eliminar todos los comentarios temporales o
innecesarios, para evitar cualquier confusin en la futura fase de
mantenimiento.
Usar frases completas cuando escriba comentarios. Los comentarios
deben aclarar el cdigo, no aadirle ambigedad.
Usar los comentarios para explicar el propsito del cdigo. No usarlos
como si fueran traducciones literales.

89
Realizar los comentarios en un estilo uniforme, respetando una
puntuacin y estructura coherentes a lo largo de toda la aplicacin.
Cada declaracin de variable importante debe incluir un comentario en la
misma lnea que describa el uso de la variable que se declara.
Despus de la secuencia de continuacin de lnea no puede escribirse
un comentario en la misma lnea.
Todos los comentarios deben estar ortogrficamente bien escritos, una
escritura incorrecta demuestra un desarrollo negligente.
Evitar comentarios que expliquen cosas obvias, en la mayora de las
cosas el cdigo debe ser autoexplicativo.
3.3.2.4 Formato.

El formato hace que la organizacin lgica del cdigo sea ms clara. Si nos
tomamos el tiempo de comprobar que el cdigo fuente posee un formato
coherente y lgico, resultar muy sencillo descifrarlo.

A continuacin mencionaremos las pautas para establecer el formato:
Evitar albergar mltiples clases en un solo archivo.
Establecer un tamao estndar de sangra (por ejemplo, cuatro espacios
o una tabulacin).
Usar un nico tipo de letra cuando publique versiones impresas del
cdigo 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 Mtodos.

La secuencia de declaracin 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 lnea mxima para el cdigo.
3) Siempre que sea posible, no colocar ms de una instruccin por lnea, a
excepcin de los bucles.
4) Al escribir en HTML, establecer un formato estndar para las etiquetas y
los atributos; como por ejemplo, las etiquetas siempre en mayscula y
los atributos en minscula.
5) En SQL utilice maysculas para las palabras clave: SELECT, UPDATE,
WHERE, FROM, etc.
6) Colocar las clusulas SQL principales en lneas separadas, de modo
que las instrucciones sean ms fciles de leer y editar:

7) Evitar llamadas a mtodos dentro de sentencias condicionales.
8) Evitar utilizar recursividad, usar mejor ciclos for anidados.
65

3.4 Prueba de Construccin.

En sta etapa intervienen solo los desarrolladores, los cuales actan sobre un
cdigo fuente congelado, por lo que estn restringidos a agregar nuevas
funcionalidades y la imposibilidad de realizar grandes modificaciones a las
interfaces grficas 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 prctica habitual de todo proceso productivo, que bsicamente consiste
en comprobar que un producto tiene las caractersticas 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
Prcticamente 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 vara 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 caractersticas y particularidades. Sin
embargo, y aunque es una realidad que los fallos de software ocasionan graves
prdidas econmicas, el nivel de concienciacin en cuanto a la necesidad de
incorporar mecanismos de calidad es muy pequeo.

A pesar de que las pruebas no pueden asegurar la ausencia de defectos, ya
que slo 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 especificacin del software, las funciones que debe
realizar, las entradas y las salidas esperadas. Se detalla a continuacin:

Las pruebas se hacen principalmente en funcin de los requerimientos
determinados. Tambin pruebas tcnicas 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 Mdulos independientes.

Las pruebas de mdulos independientes se realizan con el objetivo de
encontrar y reparar fallas en el comportamiento de los mdulos independientes:

N^o Nombre Entrada Salida esperada Salida real
1 realizar conexin direccin de HW descriptor de socket Socket
2 mover Mouse direccin (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 especificacin del software, las funciones que
debe realizar, las entradas y las salidas analizando los Valores Lmite (AVL).

Tipo Condicin Rendimiento
Consumo energtico conexin activa 12 horas continuado
Cobertura conexin activa mxima 30 metros
Tasa de ejecucin Peticiones de ejecucin
Percepcin de ejecucin en
tiempo real

93
Prueba de validacin.- El software totalmente ensamblado se prueba como un
todo para comprobar si cumple los requisitos funcionales y de rendimiento,
facilidad de mantenimiento, recuperacin de errores, etc.

Prueba de aceptacin.- El usuario comprueba en su propio entorno de
explotacin 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 ejecucin fluida y de excelente
percepcin para el usuario final.

Figura No. 31.- Diagrama de Errores.

3.4.3 Subcontratacin 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 formacin y experiencia especfica, las
empresas dedicadas al desarrollo de software estn optando, de forma
creciente, por la subcontratacin de esta tarea.

94

Las ventajas que la subcontratacin ofrece a las compaas son amplias:
disponer de personal formado en cualquier momento; poder usar, sin tener que
comprar las herramientas ms avanzadas, un proceso de pruebas sistemtico,
automatizado y repetible; y disponer de informacin actualizada que nos
permita tener control sobre el proyecto.

Est claro que en esta poca de implantacin masiva y generalizada de los
sistemas de gestin de la calidad en todos los sectores de nuestra economa,
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 informticas,
resulte cada vez ms comn y recomendable la subcontratacin 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 algn elemento procedente de un esfuerzo de
desarrollo anterior.
67

3.5.1 Beneficios de la Reusabilidad.
Es la nica aproximacin realista para llegar a los ndices de
productividad y calidad que la industria del Software necesita.
Mejora de la productividad.
Disminucin tiempo de desarrollo.
Mejor adaptacin requisitos cambiantes.
Disminucin 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. Ingeniera del Software Un enfoque prctico. 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 especficamente de aspectos tecnolgicos sino de aquellos
organizativos y de motivacin. No obstante las tecnologas pueden ayudar al
respecto. Se describe como la orientacin a objetos y contribuye en los
diferentes niveles de reusabilidad: bibliotecas de clases, patrones de diseo y
arquitecturas.

En primer lugar hay que separar lo que se entiende por reusabilidad individual y
oportunista de la reusabilidad a nivel empresa o sistemtica.

La reusabilidad a nivel individual o de pequeos grupos de desarrollo no es en
realidad nada nuevo y desde siempre los programadores han realizado corta-
pega de trozos de cdigo para ahorrarse trabajo de programacin.

En otros casos se han utilizado bibliotecas de rutinas, principalmente
matemticas que han dado buenos resultados pero sin lograr el objetivo
principal de la reusabilidad, la disminucin 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 sistemtica.

La reusabilidad sistemtica se basa en un conocimiento y modelado del
dominio de aplicacin de inters para la empresa o sus clientes, sea este el
financiero, control de procesos industriales, gestin de red o avinica.

Para la realizacin del modelado del dominio del problema se utilizan tcnicas
de anlisis de dominio, algunas de ellas se basan en los principios de
adquisicin y representacin del conocimiento desarrollado dentro de la
Inteligencia Artificial, otras utilizan principios parecidos a los del anlisis de
sistemas donde hay mucha experiencia en la industria.

La biblioteconoma, ha sido tambin muy til. La obtencin de la representacin
del dominio en el mbito del problema, lleva a la bsqueda de soluciones de
ste. Se desarrollan entonces arquitecturas de referencia que permiten
desarrollar implementaciones de aplicaciones en el mbito del dominio de la
aplicacin.

Estas arquitecturas de referencia se pueden apoyar en bibliotecas de
programas sean estas rutinas o clases dependiendo de las metodologas de
desarrollo software que se utilicen.
3.5.2 Factores de la Reusabilidad.

Soporte de la direccin.- Las decisiones en la utilizacin de procesos de
desarrollo de software, herramientas, y lenguajes, as como las inversiones en
formacin, construccin de activos reutilizables y adaptacin de la organizacin
son inviables sin un apoyo explcito de la alta direccin.

Cambios en la organizacin.- La reusabilidad sistemtica conlleva la divisin
del personal de desarrollo en dos grupos principales con funciones distintas.

97
El grupo de Ingeniera de Dominio, que construye los activos reutilizables, sean
estos modelos del dominio, bibliotecas, arquitecturas o generadores de
aplicaciones, y el grupo de Ingeniera de Aplicacin, que construye aplicaciones
con los activos reutilizables existentes en la organizacin.

Cambios en el personal.- La formacin y los incentivos son tiles para cambiar
prcticas habituales en el personal y disminuir la desconfianza en la utilizacin
de cdigo desarrollado por otros como parte del suyo propio.

Por consiguiente los mayores beneficios se obtendrn de la unin de factores
organizativos (personal y procesos) y tecnolgicos (orientacin 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 adopcin de reusabilidad en una organizacin ha de seguir una evolucin
incremental donde se parte de soluciones tecnolgicas mas simples como las
bibliotecas de clases a soluciones de mayor complejidad como son las
arquitecturas de referencia.

Las cinco etapas en la evolucin de la reusabilidad son:

Corta-Pega.- En esta primera etapa o fase de la evolucin, la organizacin trata
de disminuir los tiempos de desarrollo mediante la clonacin de trozos de
cdigo. Aunque es una solucin 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 cdigo donde estos aplican. Es un problema tpico de la
gestin de configuracin.

Caja Negra.- En la reusabilidad de caja negra se identifican componentes
software de uso comn en la organizacin. Se garantiza que existe un original
nico de ellas. La utilizacin de bibliotecas y taxonomas de clasificacin puede
ayudar en esta fase de la evolucin de la organizacin.

98
Activos Reutilizables.- En esta fase la organizacin considera otros activos
reutilizables distintos del cdigo. Entre estos destacan principalmente los
procedimientos de prueba, las especificaciones, ficheros de ayuda,
herramientas y otros.

Con esta aproximacin se incrementa la reusabilidad en las diversas fases del
ciclo de vida del software, no solo en la fase de implementacin como ocurra
especialmente en la fase de Caja Negra.

Arquitecturas.- En esta fase se generan componentes reutilizables, que podran
ser los anteriores, y una arquitectura software que los aglutina , permitiendo
desarrollar aplicaciones en un dominio especifico de negocio, sea este
financiero, control de trfico areo , gestin de red u otros. Las guas para la
creacin de arquitecturas de referencia o especificas de dominio de este
proyecto pueden ser utilizadas en dominios de aplicacin diferentes.

Reusabilidad sistemtica. Se basa en la estandarizacin de los activos
reutilizables y los procesos para producirlos, la creacin de una infraestructura
para la produccin de estos activos y los mecanismos organizativos adecuados
para facilitar la reusabilidad de estos.

La separacin del personal en grupo de ingeniera de dominio o responsable de
crear y mantener los activos reutilizables y el grupo de ingeniera de aplicacin,
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 tecnolgicos sino tambin de los organizativos y
otros. No obstante la orientacin 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 seccin se describen tres niveles de reusabilidad desde el punto de
vista arquitectnico que pueden ser llevados a cabo teniendo en cuenta los
principios de la orientacin a objetos. Estos niveles son las bibliotecas de
clases, los patrones de diseo y las arquitecturas. Se plantearan que significan
cada uno de ellos y que aspectos se tendran en cuenta en su construccin.

3.5.4.1 Bibliotecas de Clases.
En trminos generales se define una biblioteca de clases como una coleccin
de componentes reutilizables relativas a un dominio de aplicacin o
independientes de dominio que sirven como elementos constructivos de
aplicaciones.

En principio las bibliotecas de clases ms utilizadas son independientes del
dominio de aplicacin 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 especficas de dominio tambin existen. Existen en
dominios diferentes como los financieros, investigacin operativa, control de
trfico areo o comunicaciones.

Propiedades de una Biblioteca de Clases reutilizable:

Completa.- La biblioteca de clases debe proporcionar familias de clases
que tengan un interfaz comn pero posibilitando diferentes
implementaciones.
Adaptable.- Todos los aspectos especficos de la plataforma deben estar
identificados y aislados.
Eficiente.- Se debe buscar la eficiencia en compilacin, permitiendo el
fcil ensamblaje de los componentes y en ejecucin, haciendo una
optima utilizacin de las caractersticas del lenguaje.

100
Segura respecto a los tipos.- Permitiendo que las suposiciones estticas
respecto al comportamiento de una clase puedan reforzarse por el
sistema de compilacin.
Simple.- La biblioteca debe usar una organizacin clara y consistente
que facilite la identificacin y seleccin de clases concretas.
Extensible.- Se ha de admitir la adicin 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:
Abstraccin.
Encapsulamiento.
Modularidad.
Jerarqua.

Los principios secundarios son:
Tipificacin.
Concurrencia.
Persistencia.

El creador de una biblioteca de clases tiene que tener en cuenta como son
soportados estos principios en el lenguaje de programacin utilizado y en
funcin 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 tcnicas de la orientacin a objetos para permitir la
implementacin de la variabilidad en los componentes. Las tcnicas posibles
son:

Especializacin.- Utilizando los mecanismos de herencia soportados por
el lenguaje.
Extensin.- Utilizando la composicin de componentes.

101
Parametrizacin.- Esta tcnica permite definir un tipo sin especificar
todos los otros tipos que este usa. Los tipos no especificados son
suministrados como parmetros en el punto de uso.

La herencia permite definir la implementacin de una clase en trminos 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 estticamente en tiempo de compilacin y es
relativamente fcil 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 precaucin.

La composicin es una alternativa a la herencia. En la composicin 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 composicin se puede realizar en
tiempo de ejecucin.

Si se favorece la composicin sobre la herencia se pueden tener en la
biblioteca de clases, jerarquas de clases ms pequeas y fciles de manejar.

La delegacin es la forma de permitir que la composicin sea tan poderosa
para la reusabilidad como la herencia. En la delegacin, dos objetos estn
involucrados en manejar una misma peticin. Un objeto receptor y un delegado.

El receptor se pasa a si mismo al delegado para permitir que la operacin del
delegado se refiera al receptor.

La principal ventaja de la delegacin es que permitira cambiar la conducta de
la ventana en tiempo de ejecucin. Por ejemplo una ventana se hara circular
simplemente remplazando el objeto rectngulo por un objeto crculo,
suponiendo que ambos tuvieran el mismo tipo.

102
Los tipos parametrizados, tambin conocidos como genricos (Ada,Eiffel) o
plantillas (C++) , permiten definir un tipo sin especificar todos los tipos que ste
usa. Estos sern suministrados como parmetros en el punto de instanciacin.

Los cambios son realizados por tanto en tiempo de compilacin. 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 segn sean instanciados en tiempo de compilacin.

La figura 33 describe un diseo de una aplicacin para ordenar mensajes de
correo electrnico 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 aplicacin.

Figura No. 33.-Diseo de Aplicacin 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
producirn el mismo tipo de resultados. Se utiliza el polimorfismo cuando se
quiere enviar el mismo mensaje a diferentes objetos sin saber el objeto
especfico al que se le est enviando el mensaje.

Existen 2 formas de polimorfismo:

Ad Hoc.- Es la sobrecarga de operadores, donde una funcin es llamada
basndose en su firma definida como la lista de tipos de argumentos en
su lista de parmetros.
Puro. Una clase es subclase de otra. Las funciones disponibles en la
superclase pueden usarse en la subclase. Se puede tener distinta
implementacin de la funcin en la subclase. La funcin a utilizar se
determina dinmicamente en tiempo de ejecucin. esto se conoce como
ligadura dinmica y se consigue en C++ con el uso de funciones
virtuales.

3.5.4.3 Clasificacin de Clases.
Un aspecto no especfico de la orientacin a objetos pero de inters para la
reusabilidad es la clasificacin de las clases pertenecientes a una biblioteca de
clases. Estas clasificaciones son ms necesarias segn sea el tamao de la
biblioteca de clases, es decir cuando se habla de ms de cien clases no es fcil
localizar la clase que se necesita en un momento determinado.

Los esquemas de clasificacin de componentes software reutilizables que
seran tambin aplicados a las clases son bsicamente dos:

Enumerativos.- Donde se descompone el dominio en clases cada vez ms
especficas y restringiendo a la vez el nmero de ramas de los rboles as
creados.

104
Por Facetas.- Se basa en la sntesis y no en la descomposicin del dominio.
Las facetas, cuyo uso proviene tambin de la biblioteconoma, permiten
clasificar una clase escogiendo el trmino adecuado para cada una de las
facetas que mejor describa la clase en cuestin.

Los esquemas enumerativos se basan en jerarquas de las clases o
componentes relacionadas con niveles de abstraccin, relevancia del dominio,
atributos de la clase o tcnicas de creacin de ejemplares.

Las facetas se pueden considerar como dimensiones, perspectivas o vistas de
un dominio particular. Para desarrollar un sistema de clasificacin por facetas,
se sugiere tener en cuenta dos aspectos: funcionalidad del componente y
entorno en donde realiza su funcin.

Esto lleva a un conjunto de seis facetas para describir un componente:

Funcin.
Objeto.
Medio.
Tipo de Sistema.
rea Funcional.
Tipo de Negocio.

Pueden ocurrir problemas de asignacin de trminos a las facetas o con el
manejo de sinnimos, que llevan a la construccin de tesauros de trminos. Se
utilizan tambin los grafos de distancia conceptual para soportar una medida
objetiva de la similitud conceptual entre los trminos de una faceta.

3.5.4.4 Patrones de Diseo.
La utilizacin de patrones no es una actividad exclusiva del desarrollo software,
precisamente ha sido una prctica habitual en multitud de disciplinas siendo su
utilizacin en el desarrollo software ms bien reciente.

105
En trminos generales se puede definir un patrn como una forma realizada,
original, aceptada o propuesta para su imitacin: algo dispuesto como ejemplo
a ser copiado o utilizado como prototipo.

En el software desarrollado con las metodologas de orientacin a objetos, se
considera un patrn de diseo software a la descripcin de un conjunto de
objetos y clases que se comunican entre si y que pueden ser adaptados para
resolver un problema de diseo general en un contexto particular.

En general, un patrn de diseo tiene cuatro elementos esenciales:

1) Nombre.- Es la identificacin que se puede utilizar para etiquetar un
problema de diseo, su solucin 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
abstraccin.
2) Problema.- Describe cuando se puede aplicar el patrn. Se explica el
problema a resolver y su contexto. Se pueden describir problemas
especficos de diseo tales como la representacin de algoritmos como
objetos.
3) Solucin.- Describe los elementos que conforman el diseo en cuestin,
incluyendo sus relaciones, responsabilidades y colaboraciones. La
solucin no describe un diseo particular y concreto o una
implementacin, dado que un patrn es como una plantilla que puede
ser aplicada en situaciones diversas. Por consiguiente, un patrn
suministra una descripcin abstracta de un problema de diseo y como
una agrupacin de elementos constructivos lo resuelven.
4) Consecuencias.- Estas representan las alternativas y resultados de
aplicar el patrn. Aunque a veces en las descripciones de diseos se
obvian las consecuencias, stas son crticas para evaluar las
alternativas y para determinar los costes y beneficios derivados de
aplicar un patrn.

106
En el desarrollo de sistemas, las consecuencias suelen estar ligadas a
alternativas en tamao o prestaciones. Tambin se tienen en cuenta aspectos
de lenguaje e implementacin. 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
realizacin de aplicaciones informticas especficas.

La construccin de compiladores fue una de los primeros dominios donde se
han realizado arquitecturas. Otros han sido las interfaces grficas. Actualmente
se estn desarrollando arquitecturas en otros dominios como el financiero,
avionica o multimedia.

La arquitectura describe la estructura global de un sistema es decir la particin
de ste en clases y objetos, la asignacin de responsabilidades, la
colaboracin entre los objetos, y el flujo de control.

La arquitectura captura las decisiones de diseo que son comunes al dominio
de la aplicacin. Las arquitecturas enfatizan la reusabilidad a nivel de diseo en
vez de a nivel de cdigo.

Las arquitecturas se diferencian de los patrones en una serie de aspectos:
Los patrones de diseo son ms abstractos que las arquitecturas. Las
arquitecturas estn implementadas en cdigo, lo que solo ocurre con los
ejemplos concretos de los patrones. Los patrones se implementan cada
vez que se utilizan.
Los patrones son ms 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 especfico de aplicacin, 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 caractersticas
necesitadas por los ingenieros de las aplicaciones y suministrar
implementaciones siempre que sea posible.
Ser Flexible.- Las abstracciones podrn ser utilizadas en diversos
contextos.
Ser Extensible.- Los ingenieros de las aplicaciones podrn fcilmente
aumentar o modificar la funcionalidad suministrada. Se suministraran los
mecanismos de adaptacin que permitan modificar la conducta de la
arquitectura por herencia o composicin.
Ser Inteligible.- Las interfaces con otros subsistemas estn claras y la
arquitectura est bien documentada y sigue estndares de diseo y
codificacin.

El dominio de solucin que una arquitectura resuelve puede ser el de funciones
de aplicacin, funciones de dominio o funciones de soporte.

Las arquitecturas de aplicacin conllevan la implementacin de una rebanada
horizontal de la funcionalidad de un sistema. Ejemplos de estas arquitecturas
son aquellas para resolver las interfaces grficas de un sistema.

Las arquitecturas de dominio conllevan la implementacin de la solucin a los
requisitos de un dominio determinado de aplicacin. Conllevan por consiguiente
la implementacin 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 computacin distribuida o
manejadores de dispositivo.
72

Aunque la orientacin a objetos no es ni condicin necesaria ni suficiente para
obtener beneficios de la reusabilidad, puede contribuir a sta. Existen diversos
niveles donde la orientacin a objetos puede contribuir en la adopcin de la
reusabilidad por una organizacin. Estos son las bibliotecas de clases, los
patrones de diseo y las arquitecturas.

No siempre los aspectos ms novedosos o complejos de los lenguajes de
programacin, como puede ser la herencia mltiple o la ligadura dinmica son
los que mejor contribuyen a la reusabilidad.

La conjuncin de los principios bsicos de la ingeniera software con la
implementacin adecuada de las variabilidades de un dominio de aplicacin ha
dado frecuentemente mejores resultados.

3.6 Calidad en la Construccin.
La calidad en la construccin se define como:

El conjunto de cualidades que lo caracterizan y que determinan su
utilidad y existencia. Es sinnimo de eficiencia, flexibilidad, correccin,
confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e
integridad.

La calidad del software es medible y vara 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 perodo (10 aos o ms),
necesita ser confiable, mantenible y flexible para disminuir los costos de
mantenimiento y perfeccionamiento durante el tiempo de explotacin.

72
www.es.wikipedia.org/wiki/Mantenimiento_de_software/arquitecturas (12/12/2008)

109

La calidad del software puede medirse despus de elaborado el producto. Pero
esto puede resultar muy costoso si se detectan problemas deriva dos de
imperfecciones en el diseo, por lo que es imprescindible tener en cuenta tanto
la obtencin de la calidad como su control durante todas las etapas del ciclo de
vida del software.

La obtencin de un software con calidad implica la utilizacin de metodologas
o procedimientos estndares para el anlisis, diseo, programacin y prueba
del software que permitan uniformar la filosofa 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 Bsicos de Calidad.
La poltica establecida debe estar sustentada sobre tres principios bsicos:
tecnolgico, administrativo y ergonmico.

El principio tecnolgico.- Define las tcnicas a utilizar en el proceso de
El principio administrativo.- Contempla las funciones de planificacin y control
del desarrollo del software, as como la organizacin del ambiente o centro de
ingeniera de software.
El principio ergonmico.- Define la interfaz entre el usuario y el ambiente
automatizado.
73

La adopcin de una buena poltica 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 evaluacin.

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
parmetros, indicadores o criterios de medicin.

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.- Clasificacin por tipo, esfera de
aplicacin, complejidad, etc., de acuerdo con los estndares 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 mtodos de valoracin de los indicadores.- Mtodos
manuales como cuestionarios o encuestas estndares para la medicin de
criterios periciales y herramientas automatizadas para medir los criterios de
clculo.

Definir las regulaciones organizativas para realizar el control.- Quines
participan en el control de la calidad, cundo 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:

Anlisis.
Plan general de la prueba.
Esquema detallado de la prueba.
Prueba de funcionamiento.
Prueba de la interfaz de usuario (UI).
Inspeccin final del cliente (FCI).
Herramientas automatizadas.
Localizacin y regresin de errores.
Coordinacin de proyectos.
74

3.6.2.1 Gestin de Calidad.

La gestin 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 gestin de calidad a nivel de la organizacin en entidades de software ha
seguido dos lneas que pueden perfectamente complementarse entre s.

Por una parte, se ha seguido la lnea marcada por las entidades internacionales
de estandarizacin para todos los productos y servicios a travs de las normas
ISO 9000 y por otra, el mundo del software ha creado su propia lnea de trabajo
en la gestin de la calidad, trabajando sobre los procesos de produccin 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 aos en que los estndares 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 comn la
evaluacin 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).

Estadsticas 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 tendra las PYMES de ubicarse en los niveles superiores.

Las grandes empresas ya consolidadas pueden disponer a su voluntad, y de
hecho lo hacen, la implantacin de otras metodologas o esquemas propios
para lograr la calidad y la mejora continua de sus procesos productivos.

Sin embargo, para las pequeas y medianas empresas de software la
implantacin de sistemas de la calidad basados en las normas ISO 9000 puede
constituir el mejor camino a seguir pues estas normas definen los requisitos
bsicos de la organizacin y por otro lado la certificacin le confiere un prestigio
importante ante sus clientes.

La solucin 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 caractersticas propias del producto de software que se contemplan en
las otras metodologas.
75

75
Ibid.

113
3.6.2.2 Niveles de Calidad.
Para acometer la gestin de la calidad con resultados intermedios que permitan
a la empresa ir obteniendo madurez en la medida en que avanza la
implantacin de las normas, se propone definir 5 niveles, ya no especficos al
proceso de desarrollo del producto como da cuenta el CMM, sino referentes a
la gestin de la calidad a nivel de toda la organizacin:

Nivel Inicial.
Nivel de Proyecto.
Nivel de Gestin Total de Calidad.
Nivel de Certificacin.
Nivel de Referencia.
Nivel Inicial.

Nivel Inicial.-
Toda empresa de software aplica al menos un mnimo control de la calidad de
sus productos y establece algunos parmetros mnimos como requisitos del
producto.

Las empresas que trabajan a este nivel se caracterizan por:
Definicin de polticas elementales de contratacin.
Obtencin de las especificaciones de los clientes.
Formacin emprica 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 ingeniara de software a voluntad de los
desarrolladores.
Empleo de los lenguajes de programacin en que se tiene experiencia,
al no ser que el cliente exija lo contrario.
Mnima documentacin.
Acta de aceptacin del cliente quien generalmente no est en
condiciones de evaluar adecuadamente el producto.
Deficiente organizacin 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
informacin como va de retroalimentacin para la calidad del proyecto.

Algunas acciones importantes que no pueden dejar de realizarse son: asegurar
que los procesos de ingeniera de software sean usados durante todo el ciclo
de vida del proyecto; evaluar mediante mtricas, los requerimientos de calidad
de los productos; analizar las prdidas de calidad para definir acciones para el
mejoramiento continuo del proceso de desarrollo de software.

Nivel de Gestin 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 mnimos que
ellas establecen.

Aqu es importante tener en cuenta:
Como la norma admite que la documentacin puede estar en cualquier
formato o tipo de medio, revisar los diseos de la intranet y de los
sistemas de informacin digital que minimicen la burocracia del exceso
de documentacin con el que generalmente se acompaa la
implantacin de estas normas.
Dentro de la gestin de recursos, prestar la mxima atencin a la gestin
del capital humano (gestin del conocimiento a nivel de toda la
organizacin y control de indicadores de capital intelectual).
Revisar el proceso de materializacin del producto que se defini a nivel
de proyecto a la luz de la norma.
Conceder especial importancia dentro de la revisin de requisitos
relacionados con el producto a los no explcitos por parte del cliente y a
los de ingeniera de software.
El control de cambios de diseo 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 informacin que se maneja y hasta donde llega
la participacin del cliente en el know how no informtico del producto.
La medicin, anlisis y mejora se da en dos etapas: durante el desarrollo
del software utilizando las mtricas que proporcionan los mltiples
modelos existentes y el seguimiento y medicin posterior.
Se requiere implementar adecuados sistemas de satisfaccin del cliente
que permita retroalimentarse con el desempeo posterior del producto.

Nivel de Certificacin.-
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 certificacin 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 certificacin 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
investigacin y desarrollo se da en el software cuando se trabaja en nuevas
herramientas de ingeniera y en nuevos mtodos de trabajo que permitan
obtener resultados superiores.

Las empresas de alto desempeo se convierten en referencia para otras que
comienzan a partir de convertir sus mtodos y experiencias en estndares de
trabajo. Por otro lado, el desarrollo de software propicia la produccin de
herramientas de ingeniera y de codificacin que hacen mas efectivos y
productivos los procesos.
76

76
www.ati.es/gt/calidad-software (25/01/2008)

116
3.7 La Integracin.
Un concepto de Integracin puede ser:

Etapa en la cual se utiliza el diseo realizado (cdigo de programacin) y
se realiza la unin de las diferentes partes del software. Incluye toda la
documentacin necesaria. El resultado de esta etapa es el software en
versin Beta.
77

La integracin de componentes o elementos de software no es un concepto
nuevo.

Lo que ha hecho el software es llevar la integracin de software a lmites
mucho ms extensos. El software libre por su naturaleza ofrece casi todas las
ventajas para construir un negocio basado en integracin de software.

Las bases de este tipo de negocio consisten en un potente I+D, capaz de
conocer y analizar la mayora de las herramientas disponibles basadas en
software libre. De este conocimiento es posible construir aplicaciones a la
medida del cliente mediante la integracin de los elementos que ms se
adaptan a sus necesidades.

La clave para este tipo de negocios es el desarrollo de software de integracin
evitando en la medida de lo posible la modificacin de las aplicaciones a
integrar y que permita evolucionar los distintos elementos de la solucin final
con el mnimo impacto sobre la solucin alcanzada.

Para las soluciones construidas en base a integracin de distintas herramientas
es vital la liberacin del cdigo desarrollado, sobre todo si la integracin ha
requerido la adaptacin de alguna de las herramientas utilizadas.

La clave del modelo de negocio es un potente I+D, fundamentalmente
dedicado al anlisis de aplicaciones existentes en el mundo del software libre
desde la ptica de la integracin, dirigido desde el departamento comercial.

77
www.olea.org/servicios/integracion-software.html (25/01/2008)

117
La solucin a las necesidades del cliente se construye generalmente mediante
las siguientes fases:

Anlisis de las necesidades del cliente
Identificacin de los grandes sistemas que integrarn la solucin
Identificacin de las necesidades de desarrollo
Desarrollo de elementos necesarios
Integracin de la solucin mediante utilizacin de estndares LDAP,
SGBD.

La integracin se realiza de forma limpia, evitando modificar el cdigo de las
distintas aplicaciones a integrar.

De este modo es posible beneficiarse del proceso de revisin y actualizacin
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 algn proyecto
original, dichas modificaciones deben ser siempre publicadas y enviadas al
proyecto principal, de modo que se garantice la compatibilidad con la solucin
global ante futuras revisiones del cdigo.

La integracin proporciona una configuracin e instalacin personalizada de
software (estndar, personalizada o de propiedad) en nuestro entorno de
fbrica. A travs de la integracin de software empresarial, puede controlar su
servidor para asegurar que el sistema tendr la misma versin del mismo
software, sin variaciones debido a versiones antiguas de la misma aplicacin.

La integracin tambin proporciona una configuracin e instalacin de software
personalizada, (estndar, personalizada o de propiedad) en nuestro entorno de
fbrica.

118
Los servicios de integracin de software incluyen:

Cargas de imgenes de software del cliente (Windows 2000 / Windows
XP / Windows 9X / NT4 y Linux).
Cargas de sistema operativo y sistema operativo de red, incluidos
parmetros de sistema operativo personalizados.
Cargas de aplicaciones de propiedad y de otros proveedores, incluidos
software de copia de seguridad y comunicacin de administracin de
servidores.
Configuracin de dominio.
Particin de disco duro.
Agrupacin en clster personalizada.
Personalizacin del sistema, incluida la personalizacin de parmetros
individuales para que cada uno tenga una direccin IP, un nombre de
ordenador y un identificador de sistema exclusivos.
Servicios de administracin de imagen.

3.7.1 Caractersticas.
Las caractersticas de esta etapa son las siguientes:
La integracin de los datos y de los sistemas surge como un resultado
directo de la centralizacin del departamento de sistemas bajo una sola
estructura administrativa.
Las nuevas tecnologas relacionadas con base de datos, sistemas
administradores de bases de datos y lenguajes de cuarta generacin,
hacen posible la integracin.
El costo del equipo y del software disminuye por lo cual est al alcance
de ms usuarios.
En forma paralela a los cambios tecnolgicos, cambia el rol del usuario y
del departamento de Sistemas de Informacin.
Los usuarios y el departamento de sistema inician el desarrollo de
nuevos sistemas, reemplazando los sistemas antiguos, en beneficio de
la organizacin.
78

78
www.vsf.es/servicios/integracion.php (25/01/2008)

119
CONCLUSIONES

En la construccin 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 aadir mejoras a su funcionamiento, para ello es
importante tambin que exista una documentacin 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 lderes 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 ms fluida la comunicacin en cuanto a tiempos,
prioridades y herramientas necesarias.

Existen estndares de construccin aprobados en la Ingeniera de Software
que no se pueden dejar pasar, las aplicaciones que se desarrollen debern
cumplir con las normas ya establecidas.

Tambin ya se tiene conocimiento que adems de los modelos de construccin
tradicionales, existen nuevas tcnicas de planeacin y desarrollo que se
adaptan a las nuevas tecnologas y que en el caso de las aplicaciones
robustas, son indispensables debido a su flexibilidad y minimizacin de
complejidad.

En la construccin de software debe existir una arquitectura de medicin, es
decir, hasta donde tiene que cumplir su objetivo y hasta donde tiene que estar
limitado, es importante proporcionar herramientas adicionales que quizs 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 quizs es el factor ms importante en la fase de desarrollo, ya que
tiene que servir como filtro antes de la implementacin de aplicaciones de
software, las empresas que no cuentan con estndares y procedimientos
eficaces de calidad sern menos productivas y las aplicaciones que desarrollen
sern ms susceptibles de caer y por tanto, ser reemplazadas por otras.

Gracias a la integracin, se permite la divisin del trabajo, ya que al principio
cada quien debe de tener sus propias, funciones, los lderes tratan con los
usuarios, la gente de desarrollo se encarga de las construccin, el control de
calidad ejerce sus pruebas de validacin, pero al final todos se unen para
formar as un sistema que cumpla con los requerimientos inicialmente
establecidos.

121
BIBLIOGRAFA

CAPTULO I
Pressman, R.S. Ingeniera del Software. Un enfoque prctico . Mc Graw Hill,
Espaa 6 ed. 2006. p. 15
2006- Swebok_Guide_2006 (Archivo en formato PDF) Profesor: Sergio
Fuenlabrada Velzquez.
JOHNSON, Bruce. Flexible Software Design. Ed Mc Graw Hill. 2005, pp.440.
E. J. Weyuker, "Evaluacin 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.
Mxico 2003, p. 132-133.
Pleeger. Ingeniera del Software: Teora y prctica. Pearson Education.Mxico
2003 pp.55.
2006- Tipos de Cambio (Archivo en formato PDF) Profesor: Sergio
Fuenlabrada Velzquez.
Effy Oz, Administracin de sistemas de informacin, 2da ed. Thomson Learning
2001.
A. Toval. Ingeniera del Software. Gestin de Requisitos, ed. DM, Espaa,
1999.
Stair M Ralphm. Principios de sistemas de informacin,. Thomson Learning 4
Ed 2002.
BOOCH, Grady. Lenguaje Unificado de Modelado. Mc Graw Hill. Ao 2000. pp.
464.
SOMMERVILLE, Lan. Ingeniera 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/verificacin (25/05/2008).
www.es.wikipedia.org/wiki/Categora (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).

CAPTULO II
Lawrence, S..Ingeniera del software. Ed. Prentice-Hall, Mxico. 2002.
Ivar Jacobson. El proceso unificado de desarrollo de software. Addison-Wesley
2000.
MEYER,Construccin del Software Orientado a Objetos. McGraw-Hill,
2001.pp 480.
Fairley, R.: Ingeniera del Software. McGraw-Hill, 2001.pp 165.
JOHNSON, Flexible Software Design. McGraw-Hill, 2005.pp 230.
McGarry, J. Optimizacin prctica del Software. Addison Wesley. 2002. pp 142.
Bernd Bruegge, Allen h. Dutoit. Ingeniera de Software Orientado a Objetos.
Prentice Hall. 2002.
Perdita Stevens, Rob Pooley. Utilizacin de UML en Ingeniera del Software
con Objetos y Componentes. Addison Wesley. 2002
Sahri Lawrence Pfleeger. 2002. Ingeniera de Software. Teora y Prctica.
Prentice Hall. Captulo 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).

CAPTULO III
SOMMERVILL. Ingeniera de Software. Mc Graw Hill, 5 Ed.,2002. pp.560.
RogerS. Pressman. Ingeniera del Software Un enfoque prctico. 4 Ed.Mc
Graw-Hill. P. 460.
Pleeger. Ingeniera del Software: Teora y prctica. Pearson Education..Mxico
2003 pp..55
Effy Oz. Administracin de sistemas de informacin, 2da ed. Thomson Learning
2001 .
Roda, Jos Luis y Brito, Julio. Introduccin a la ingeniera del software.
Gobierno de Canarias, 200.
K. Arnold, J. Gosling, D. Holmes. El lenguaje de programacin JAVA. Addison
Wesley, 2001
Beck, K. 2002. Una explicacin de la Programacin Extrema. Aceptar el
Cambio. Addison Wesley. 2002.
Cabrera, G., Montoya, M. 1999. Anlisis y Diseo Detallado de Aplicaciones
Informticas de Gestin. Ciclo Formativo Grado Superior, McGraw Hill.

En Internet:

www.wikipedia.org/wiki/Lenguaje_de_programacin (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)

C2 306

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

C2 306

Caricato da

Copyright:

Formati disponibili

INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA

Potrebbero piacerti anche