V.

IMPLEMENTACION

V.1 LENGUAJES DE ANALISIS Y DISEO.

5.1.1 CARACTERISTICAS.
Los lenguajes de programacin son un vehculo entre los humanos y las computadoras. Las
caractersticas de ingeniera de un lenguaje tienen un impacto importante sobre el xito de un proyecto de
desarrollo de software. Las caracterstics tcnicas pueden influenciar la calidad del diseo. A continuacin se
manifiestan algunas de ellas:
Uniformidad: indica el grado en que un lenguaje usa una notacin consistente, aplica restricciones
aparentemente arbitrarias incluye excepciones a reglas sintcticas semnticas. Ejemplo: uso de parntesis y
corchetes.
Ambigedad: de un lenguaje es percibida por el programador. Un compilador siempre interpreta una
sentencia de una nica forma, pero el lector humano puede interpretar la sentencia de formas diferentes ( sobre
todo aritmticas ).
Compacto: es un indicativo de la cantidad de informacin orientada al cdigo que se debe retener en
la memoria humana. Entre los atributos del lenguaje que miden lo compacto que es, se encuentran: el grado en
que soporta construcciones estructuradas, los tipos de palabras clave y abreviaturas utilizadas, la variedad de
tipos de datos y caractersticas implcitas, el nmero de operadores aritmticos y lgicos, el nmero de
funciones incorporadas.
La memoria y reconociiento humano se pueden dividir en campos sinesttico y secuencial. La
memoria sinesttica nos permite recordar y reconocer las cosas como un todo (cara). La memoria secuencial
proporciona una forma de reconocer el siguiente elemento de una secuencia (cancin).
Localizacin: es caracterstica sinesttica de un lenguaje, se potencia cuando las sentencias se pueden
combinar en bloques, cuando las construcciones estructuradas se pueden implementar directamente y cuando el
diseo y el cdigo resultante son altamente modulares y cohesivos. Una caracterstica que viola la localizacin
es aquella que aporta o induce al manejo de excepciones.
Linealidad: se asocia con el concepto de mantenimiento de un
mbito funcional. Da facilidad al encontrarse secuencias lineales de operadores lgicos.
Tradicin: afecta la capacidad de aprender un nuevo lenguaje, asi como al grado de innovacin
durante el diseo de un lenguaje de programacin.

5.1.2 FUNDAMENTOS.
Un planteamiento de ingeniera del software sobre las caractersticas de los lenguajes de programacin
se centra en las necesidades que puede tener un proyecto especfico de desarrollo de software. Se puede
establecer el siguiente conjunto:
(1) facilidad de traduccin del diseo al cdigo: proporciona una indicacin de como se aproxima un lenguaje a
la representacin del diseo.
(2) eficiencia del compilador.
(3) portabilidad del cdigo fuente: considera si el cdigo fuente puede ser transportado de un procesador a otro
y un compilador a otro, sin ninguna o pocas modificaciones; si el cdigo fuente permanece inalterado cuando
cambia su entorno de funcionamiento (nuevo sistema operativo); si el cdigo fuente puede ser integrado en
diferentes paquetes de software sin requerir modificacin.
(4) disponibilidad de herramientas de desarrollo: puede acortar el tiempo requerido para la generacin del
cdigo fuente y puede mejorar la calidad del cdigo.
(5) facilidad de mantenimiento.

Entre los criterios para la eleccin de un lenguaje de programacin para un proyecto especfico se
tienen:
(1) Area de aplicacin general.
(2) Complejidad algortmica y computacional.
(3) Entorno en el que se ejecutar el software.
(4) Consideraciones de rendimiento.
(5) Complejidad de las estructuras de datos.
(6) Conocimiento de la plantilla de desarrollo de software.
 (7) Disponibilidad de un buen compilador.
La calidad de un diseo de software viene dada por su independencia de las caractersticas de los lenguajes de
programacin. Sin embargo, los atributos del lenguaje juegan su papel en la calidad de un diseo acabado y
afectan a la forma de especificar el diseo.

5.1.3 EFICIENCIA.

En los sistemas catalogados como buenos bajo el punto de vista de ingeniera, existe una tendencia
natural a usar los recursos crticos de forma eficiente. Los ciclos del procesador y las posiciones de memoria, a
menudo, se tratan como recursos crticos y el paso de codificacin se considera el ltimo punto donde se le
pueden arrancar segundos o bits al software.
Aunque la eficiencia es un fin recomendable, se deben establecer tres mximas. En primer lugar, la
eficiencia es un requisito de rendimiento y, como tal, se debe establecer durante el anlisis de requerimientos.
El software debe ser tan eficiente como se requiera, no tan eficiente como sea humanamente posible.
En segundo lugar, la eficiencia se incrementa con un buen diseo. En tercer lugar, la eficiencia del
cdigo y la simplicidad del mismo van de la mano. En general, no sacrificar la claridad, legibilidad o correccin
en pos de una mejor eficiencia no esencial.

EFICIENCIA EN CODIGO:

Esta directamente unida a la eficiencia de los algoritmos definidos durante el diseo detallado. Algunas
directrices a seguir son:
* Simplificar las expresiones aritmticas y lgicas antes de convertirlas en cdigo.
* Evaluar cuidadosamente los bucles anidados para determinar si se pueden sacar fuera de ellos algunas
sentencias o expresiones.
* Cuando sea posible, evitar el uso de arreglos multidimensionales.
* Cuando sea posible, evitar el uso de apuntadores y listas complejas.
* Usar "rpidas" operaciones aritmticas.
* No mezclar tipos de datos, aunque el lenguaje lo permita.
* Usar, cuando sea posible, aritmtica entera y expresiones lgicas.

EFICIENCIA EN MEMORIA:

La clave para la eficiencia en memoria es "mantenerlo simple". No significa el utilizar menor

memoria posible, sino la eficiencia depende de la "paginacin" del sistema, es decir la localizacin del cdigo
en un campo funcional mediante construcciones estructuradas reduce la paginacin y aumenta la eficiencia.

EFICIENCIA EN LA ENTRADA/SALIDA:

La entrada suministrada por un usuario y salida producida para un usuario son eficientes cuando la
informacin se puede suministrar o se puede comprender con el mnimo esfuerzo intelectual.
La eficiencia de E/S dirigida a otros dispositivos es un tema complejo, mas hay que tomar en cuenta
los siguientes puntos: debe minimizarse el nmero de peticiones de E/S ; toda E/S debe tratarse con buffer para
reducir embotellamiento en la comunicacin; para memorias secundarias debe seleccionarse y usar el mtodo
de acceso ms simple dentro de los aceptables; E/S a memoria secundaria debe hacerse por bloques; E/S a
impresoras debe tener en cuenta las posibilidades del dispositivo que puedan afectar la calidad o a la velocidad.
5.2 TECNICAS DE PRUEBAS DE SOFTWARE.

5.2.1 PRUEBAS DEL SOFTWARE.

Una vez generado el cdigo el software debe ser probado para descubrir el mximo de errores
posibles antes de su entrega al cliente. El ingeniero crea una serie de casos de prueba que intentan
"demoler" el software que ha sido construido. Tiene como objetivos:
(1) La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error.
(2) Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.
(3) Una prueba tiene xito si descubre un error no detectado hasta entonces.

Por lo tanto hay que disear pruebas que saque a la luz diferentes clases de errores, hacindolo con la
menor cantidad de tiempo y esfuerzo. Inclusive tiene como ventaja ver hasta qu punto las funciones parecen
funcionar de acuerdo con las especificaciones y cumplir as los requisitos de rendimiento. Las tcnicas se
fundamentas en los siguientes principios:
(1) A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente
(2) Las pruebas deberan planificarse mucho antes de que empiecen
(3) Las pruebas deberan empezar por lo "pequeo" y progresar hacia "lo grande" ( mdulos )
(4) No son posibles las pruebas exhaustivas ( imposible ejecutar todas las combinaciones de
caminos )
(5) Pasa ser mas eficaces, las pruebas deberian ser realizadas por un equipo independiente

5.2.2 FACILIDAD DE PRUEBA

La facilidad de prueba es la facilidad con que se puede probar un programa de computadora. Las
caractersticas que llevan a un software fcil de probar son:
(a) Operatividad: cuanto mejor funcione, mas eficentemente se puede probar, el sistema tiene pocos
errores, ningun error bloquea la ejecucin de pruebas
(b) Observabilidad: lo que ves es lo que pruebas, se genera una salida distinta para cada entrada, los
estados y variables estan visibles y se pueden consultar durante la ejecucion, un resultado incorrecto se
identifica fcilmente, se informa de los errores internos, el codigo fuente es accesible
(c) Controlabilidad: cuanto mejor podamos controlar el software, mas se puede automatizar y optimizar,
todos los resultados posibles se generan con alguna combinacion de entrada, los formatos de entrada y
resultados son consistentes y estructurados, las pruebas se pueden automatizas
(d) Capacidad de descomposicin : controlando el ambito de las pruebas podemos aislas los problemas y
llevar a cabo mejores pruebas, modularidad, se pueden probar independientemente
(e) Simplicidad : cuanto menos haya que probar, mas rapidamente podremos probarlo, minimo de
caracteristicas para cumplir con los requisitos, ( funcional, estructural y codigo )
(f) Estabilidad: cuanto menos cambios, menos interrupciones a las pruebas, los cambios son
infrecuentes, controlados y no invalidan las pruebas existentes, el software se recupera bien de los
fallos
(g) Facilidad de comprensin : cuanta mas informacion tengamos, mas inteligentes seran las pruebas,
entendible el diseo, las dependencias, la documentacin, si es especifica, detallada y exacta

5.2.3 CASOS DE PRUEBA

Cualquier producto puede probarse de una de estas dos formas : conociendo la funcin especfica
para la que fue diseado el producto llevando a cabo pruebas que demuestren que cada funcin es operativa y
conociendo el funcionamiento del producto llevando a cabo pruebas que aseguren que todas las piezas encajen.
El software debe probarse desde dos perspectivas diferentes:

(1) la lgica interna del programa utilizando tcnicas de diseo de casos de prueba de "caja blanca"
(2) los requisitos del software utilizando tcnicas de diseo de casos de prueba de "caja negra"
5.2.3.1 PRUEBA DE LA CAJA BLANCA.
 Se basa en el minucioso examen de los detalles procedimentales, de los caminos lgicos. Utiliza la
estructura de control del diseo procedural para derivar los casos de prueba. Este mtodo obtiene
casos de prueba que:
* garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada mdulo.
* ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa.
* ejecuten todos los bucles en sus lmites y con sus lmites operacionales.
* y ejerciten las estructuras internas de datos para asegurar su validez.

5.2.3.2 PRUEBA DE LA CAJA NEGRA.

Se refiere a las pruebas que se llevan a cabo sobre la interfaz del sofware. Se centra en los
requisitos funcionales del software. Es decir, permite obtener conjuntos de condiciones de entrada que
ejerciten completamente todos los requisitos funcionales de un programa. No es una alternativa a la
caja blanca, ms bien es un complemento que intenta descubrir diferentes errores que la otra prueba
realizada. Intenta encontrar errores tales como: funciones incorrectas ausentes, errores de
interface, errores en estructuras de datos en accesos a bases de datos externas, errores de rendimiento
y errores de inicializacin y de terminacin.

Prueba del camino basico Prueba basadas en grafos

Prueba de complejidad ciclomtica Prueba de particin equivalente
Prueba de condicin Prueba de comparacin
Prueba de dominio Prueba de tabla ortogonal
Prueba BRO Prueba de Interfaces grficas
Prueba de flujo de datos Prueba de arquitectura cliente/servidor
Prueba de bucles Prueba de documentacin
Prueba de sistemas de tiempo-real

Configuracin del Software

V Errores
Resultados >
PRUEBA >
EVALUACION DEPURACION
^
V
Configuracin de Correcciones
Prueba Datos de Tasa de error
V
MODELO DE
FIABILIDAD Prediccin de
> fiabilidad
Fig. 7.1 Flujo de Informacin en la prueba.

Se proporcionan dos entradas al proceso de prueba: la configuracin del software que incluye la
especificacin de requisitos del software, especificacin del diseo y el cdigo fuente; y la configuracin de
prueba que incluye un plan y procedimiento de prueba, algunas herramientas de prueba y casos de prueba con
resultados esperados.
Se llevan a cabo las pruebas y se evalan los resultados. Al descubrir datos errneos comienza la
depuracin. Si se encuentran con regularidad serios errores requiere modificaciones en el diseo siendo
necesarias posteriores pruebas. Si el funcionamiento parece ser correcto y los errores son fcilmente
corregibles, se puede obtener una de dos conclusiones: la calidad y la fiabilidad del software son aceptables,
las pruebas son inadecuadas para descubrir errores serios. Si no se descubren errores, los defectos sern
eventualmente descubiertos por el usuario y corregidos durante la fase de mantenimiento (60-100% mayor
costo).
5.3 ESTRATEGIAS DE PRUEBAS DE SOFTWARE.
 El proceso de ingeniera del software se puede ver como una espiral. Inicialmente, la ingeniera del
sistema define el papel del software y conduce al anlisis de requisitos, donde se establece el campo de
informacin, la funcin, el comportamiento, el rendimiento, las restricciones y criterios de validacin del
software. Al movernos hacia adentro de la espiral, llegamos al diseo y por ltimo a la codificacin.
Las pruebas del software aplican similar estrategia moviendonos de adentro hacia afuera de la espiral.
la prueba de unidad comienza en el vrtice de la espiral y se centra en cada unidad del software, tal como est
implementada en cdigo fuente. La prueba avanza para llegar a la prueba de integracin, donde el foco de
atencin es el diseo y construccin de la arquitectura del software. Otra vuelta hacia afuera encontramos la
prueba de validacin, donde se validadn los requisitos establecidos como parte del anlisis de requisitos del
software, comparndolos con el sistema que ha sido construido. Finalmente, llegamos a la prueba del sistema
en la que se prueban como un todo el software y otros elementos del sistema.

5.3.1 PRUEBAS DE UNIDAD.

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo: el mdulo.
Usando la descripcin del diseo detallado como gua, se prueban los caminos de control importantes, con el
fin de descubrir errores dentro del mdulo.
Se prueba la interface para asegurar que la informacin fluye de forma adecuada hacia y desde la
unidad del programa que est siendo probada. Se examinan las estructuras de datos locales para asegurar que
los datos que se mantienen temporalmente conservan su integridad durante la ejecucin del algoritmo. Se
prueban las condiciones lmite para asegurar que el mdulo funciona correctamente con los lmites
establecidos. Se ejercitan todos los caminos independientes de la estructura de control para asegurar que todas
las sentencias del mdulo se ejecuten por lo menos una vez. Y finalmente se prueban todos los caminos de
manejo de errores.

5.3.2 PRUEBAS DE INTEGRACIN.

Si todos los modulos funcionan bien por qu dudar de que funcionen bien juntos ?. El problema es
"ponerlos juntos". La prueba de integracin detecta errores de interaccin. El procedimiento adecuado se llama
integracin incremental con el cual se construye y se prueba en pequeos segmentos en los que los errores
son ms fciles de aislar y corregir.

Un plan general de integracin y una descripcin de las pruebas especficas deben quedar
documentados en una especificacin de prueba, es parte esencial del proceso de ingeniera de software y
forma parte de la configuracin del software.

Un perfil de la especificacin de prueba puede ser el siguiente:

I. Alcance de la prueba.
II. Plan de prueba.
A. Fases de prueba.
B. Agenda.
C. Software adicional.
D. Entorno y recursos.
III. Procedimiento de prueba N.
A. Orden de integracin.
1. Propsito.
2. Mdulos a ser probados.
B. Pruebas de unidad para los mdulos de la subfase.
1. Descripcin de pruebas para el mdulo M.
2. Descripcin del software adicional.
3. Resultados esperados.
C. Entorno de prueba.
1. Herramientas o tcnicas especiales.
2. Descripcin del software adicional.
D. Datos de los casos de prueba.
 E. Resultados esperados para la subfase N.
IV. Resultados de prueba obtenidos.
V. Referencias.
VI. Apndices.

El alcance de prueba resume las caractersticas funcionales, de rendimiento y diseo interno

especficas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminacin de cada fase de
prueba y se documentan las limitaciones del plan.
El plan de prueba describe la estrategia general para la integracin. Se divide en fases y subfases. En
todas las fases se siguen los siguientes criterios: Integridad de interface, validez funcional, contenido de la
informacin y rendimiento.
La seccin de procedimiento de prueba describe detalladamente el procedimiento de prueba
requerido para llevar a cabo el plan de prueba, describiendo el orden de integracin y las pruebas de cada fase.
Asimismo se incluye un listado de todos los casos de prueba y resultados esperados.
Se registran los resultados reales de prueba obtenidos, problemas y peculiaridades. Esta informacin
es vital para el mantenimiento del software.

5.3.3 PRUEBAS DE VALIDACIN.

Una vez ensamblado como paquete probamos la validacin, la cual se logra cuando el software
funciona de acuerdo con las expectativas razonables del cliente. Estas espectativas estn definidas en la
especificacin de requisitos que describe los atributos del software visibles al usuario, basado en los criterios de
validacin de dicho documento.

La prueba de validacin se lleva a cabo con pruebas de la caja negra que demuestran la conformidad
con los requisitos. Una vez probado cada caso pueden darse dos condiciones: las caractersticas de
funcionamiento de rendimiento estn de acuerdo con las especificaciones y son aceptables, se descubre una
desviacin de las especificaciones y se crea una lista de deficiencias.
Se pueden realizar pruebas alfa beta, la prueba alfa es conducida por un cliente en el lugar de
desarrollo; la prueba beta en uno ms lugares de clientes y usuarios finales. Como resultado el equipo de
desarrollo de software lleva a cabo modificaciones y as prepara una versin del producto de software para toda
la base de clientes.

5.3.4 PRUEBAS DE SISTEMA.

La prueba del sistema es constituida por una serie de pruebas diferentes cuyo propsito es ejercitar
profundamente el sistema basado en computadora. Entre pruebas de sistema tenemos:
Prueba de recuperacin: forza el fallo del software de muchas formas y verifica que la recuperacin
se lleva a cabo apropiadamente. Se evala la correccin de reinicializacin, mecanismos de recuperacin del
estado del sistema, recuperacin de datos y rearranque.
Prueba de seguridad: intenta verificar que los mecanismos de proteccin del sistema lo protegern
adecuadamente.
Prueba de resistencia: est diseada para enfrentar a los programas con situaciones anormales, es
decir, ejecuta un sistema de forma que demande recursos en cantidad, frecuencia volmenes anormales. Una
variacin de esta prueba es la prueba de sensibilidad, utilizando datos que produzcan inestabilidad
procesamiento incorrecto.
Prueba de rendimiento: prueba el rendimiento del software en tiempo de ejecucin. Se da en todos
los pasos del proceso de prueba.
VI. TOPICOS DE INGENIERIA DE SOFTWARE

6.1 MANTENIMIENTO.

6.1.1 MANTENIMIENTO DE SOFTWARE.

El mantenimiento de software es mucha ms que una correccin de errores. Se describe el

mantenimiento describiendo las actividades despus de distribuir un programa:
La primer actividad es el mantenimiento correctivo: proceso que incluye el diagnstico y correccin
de uno ms errores.
La segunda es el mantenimiento adaptativo: actividad que modifica el software para que
interaccione adecuadamente con su entorno cambiante.
La tercera es el mantenimiento perfectivo: se produce cuando un software tien xito, se proponen
nuevas posibilidades, modificaciones de funciones existentes y mejoras en general.
La cuarta se da cuando se cambia el software para mejorar una futura facilidad de mantenimiento
fiabilidad para proporcionar una base mejor para futuras mejoras. Tambin denominada mantenimiento
perfectivo, pero se caracteriza por utilizar la ingeniera inversa y reingeniera.

6.1.2 PROBLEMAS CARACTERSTICOS.

Entre los problemas clsicos asociados con el manteniiento se encuentran:

* Es difcil imposible seguir la evolucin del software a travs de varias versiones. Los cambios no
estn adecuadamente documentados.
* Es difcil imposible seguir el proceso por el que se construy el software.
* Es excepcionalmente difcil comprender un programa ajeno.
* Si existen menos elementos de configuracin del software (documentos), mayor es la dificultad.
* Esa persona ajena no se encuentra cerca para explicar lo que hizo.
* No existe una documentacin apropiada est mal preparada.
* La mayora del software no ha sido diseado previendo el cambio; a menos que se prevea el cambio
utilizando independencia funcional clases de objetos, las modificaciones sern difciles y propensas
a errores.
* El mantenimiento no se ve como un trabajo atractivo. (por frustrante)

6.1.3 MANTENIBILIDAD.

Se define como la facilidad de comprender, corregir, adaptar y/o mejorar el software: facilidad de
mantenimiento.
Gilb da un nmero de mtricas de facilidad de mantenimiento relacionadas con el esfuerzo gastado durante el
mantenimiento:
1. Tiempo de reconocimiento del problema.
2. Tiempo de retraso administrativo.
3. Tiempo de recoleccin de herramientas de mantenimiento.
4. Tiempo de anlisis del problema.
5. Tiempo de especificacin de los cambios.
6. Tiempo activo de correccin ( modificacin ).
7. Tiempo de prueba local.
8. Tiempo de prueba global.
9. Tiempo de revisin del mantenimiento.
10. Tiempo total de recuperacin.

Adems de stas medidas orientadas al tiempo, se puede medir indirectamente considerando medidas
de la estructura del diseo y mtricas de la complejidad del software.
6.1.4 OPERACIONES DE MANTENIMIENTO.
 Las operaciones tareas asociadas con el mantenimiento comienzan mucho ants de que se haga una
peticin de mantenimiento. Inicialmente se debe establecer una organizacin de mantenimiento; se deben
prescribir procedimientos de evaluacin y de informacin, y se debe definir una secuencia estndar de sucesos
para cada peticin de mantenimiento. Adems debe establecerse un sistema de registro de informacin de las
actividades de mantenimiento y definir criterios de revisin y de evaluacin.

El registro de informacin comprenden los siguientes datos:

1. Identificacin del programa.
2. Nmero de sentencias fuente.
3. Nmero de instrucciones en cdigo mquina.
4. Lenguaje de programacin usado.
5. Fecha de instalacin del programa.
6. Nmero de ejecuciones del programa desde la instalacin.
7. Nmero de fallas de procesamiento asociados con el punto anterior.
8. Nivel e identificacin de cambios sobre el programa.
9. Nmero de sentencias fuente aadida en los cambios del programa.
10. Nmero de sentencias eliminadas en los cambios del programa.
11. Nmero de personas-hora por cambio.
12. Fecha de cambio del programa.
13. Identificacin del ingeniero de software.
14. Identificacin del FPM ( Flujo del Proceso de
Mantenimiento).
15. Tipo de mantenimiento.
16. Fechas de comienzo y final del mantenimiento.
17. Nmero de personas/hora acumuladas para el mantenimiento.
18. Beneficios netos asociados con el mantenimiento realizado.

6.1.5 EFECTOS DEL MANTENIMIENTO.

La documentacin del diseo y una cuidadosa prueba de regresin ayudan a eliminar errores, pero
seguirn apareciendo efectos secundarios del mantenimiento.
Efectos secundarios sobre el cdigo: un subprograma eliminado cambiado, eliminacin
modificacin de una sentencia de etiqueta, eliminacin modificacin de un identificador, cambios para
mejorar el rendimiento en ejecucin, modificacin de operadores lgicos, cambios sobre las pruebas de lmites.
Efectos secundarios sobre los datos: redefinicin de constantes locales globales, redefinicin de
formatos de registros de archivos, aumento disminucin del tamao de arreglos de otras estructuras de
datos de mayor orden, modificacin de datos globales, reinicializacin de indicadores de control de
apuntadores, reorganizacin de argumentos de E/S de subprogramas.
Efectos secundarios sobre la documentacin: siempre que se haga un cambio en el flujo de datos,
arquitectura, procedimientos sistema, debe actualizarse la documentacin tcnica de soporte.

6.1.6 ASPECTOS DEL MANTENIMIENTO.

La ingeniera inversa es un proceso de anlisis de un programa en un esfuerzo por crear una

representacin del programa de mayor nivel de abstaccin que el cdigo fuente. Es un proceso de recuperacin
de diseo. Estas herramientas extraen la informacin del diseo de datos, arquitectnico y procedimental de un
programa.
No slo recupera la informacin, sino que usa esa informacin para alterar reconstruir el sistema
existente, en un esfuerzo de mejorar la calidad general. La mayora de los casos implementa la funcin del
sistema existente, pero tambin aade nuevas funciones y/o mejora el rendimiento general.
6.1.7 CONFIGURACION DEL SOFTWARE.

El resultado del proceso de ingeniera de software es una informacin que se puede dividir en tres
categoras (1) programas de computadora; (2) documentos que describen los programas y (3) estructuras de
datos.
 Los elementos que componen toda la informacin producida como parte del proceso de ingeniera del
software se denominan colectivamente configuracin del software. En forma ms realista un Elemento de
Configuracin del Software (ECS) es un documento, un conjunto completo de casos de prueba un
componente de programa identificado.
Por lo tanto los siguientes ECS son el objeto de las tcnicas de gestin de configuraciones y forman un
conjunto de lneas base:

1. Especificacin del sistema.

2. Plan del proyecto del software.
3. a. Especificacin de requisitos del software.
b. Prototipo ejecutable "en papel".
4. Manual de usuario preliminar.
5. Especificacin del diseo.
5. a. Descripcin del diseo de datos.
b. Descripcin del diseo arquitectnico.
c. Descripciones del diseo de los mdulos.
d. Descripciones del diseo de las interfaces.
e. Descripciones de los objetos.
6. Listados del cdigo fuente.
7. a. Plan y procedimiento de prueba.
b. Casos de prueba y resultados registrados.
8. Manuales de operacin y de instalacin.
9. Programas ejecutables.
a. Mdulos, cdigo ejecutable.
b. Mdulos enlazados.
10. Descripcin de la base de datos.
a. Esquema y estructura de archivos.
b. Contenido inicial.
11. Manual de usuario final.
12. Documentos de mantenimiento.
a. Informes de problemas del software.
b. Peticiones de mantenimiento.
c. Ordenes de cambios de ingeniera.
13. Estndares y procedimientos de ingeniera de software.

Construir diversos diseos de software en base a un Proyecto Propuesto por el alumno durante el
curso, aplicando diferentes tcnicas de diseo y realizando la documentacin adecuada.

6.2 CALIDAD.

6.2.1 CONTROL DE CALIDAD.

Los factores que afectan a la calidad del software se pueden clasificar en dos grandes grupos:

(1) Factores que pueden ser medidos directamente : errores/KLDC/unidad de tiempo.

(2) Factores que slo pueden ser medidos indirectamente: facilidad de uso de mantenimiento.
 Debemos comparar el software con alguna referencia y llegar a una indicacin de la calidad. McCall
propone una clasificacin de los factores de calidad del software centrados en tres aspectos: caractersticas
operativas, capacidad de soportar los cambios y su adaptabilidad a nuevos entornos. Los describe como:

Correctividad: el grado en que un programa satisface sus especificaciones y consigue los objetivos de la
misin encomendada por el cliente.

Fiabilidad: el grado en que se puede esperar que un programa lleva a cabo sus funcionese esperadas con la
precisin requerida.

Eficiencia: la cantidad de recursos de computadora y de cdigo requeridos por un programa para llevar a cabo
sus funciones.

Integridad: el grado en que puede controlarse el acceso al software o a los datos, por personal no autorizado.

Facilidad de Uso: el esfuerzo requerido para aprender un programa, trabajar con l, preparar su entrada e
interpretar su salida.

Facilidad de Mantenimiento: el esfuerzo requerido para localizar y arregalar un error en un programa

(Siguiente Captulo).

Flexibilidad: el esfuerzo requerido para modificar un programa operativo.

Facilidad de prueba: el esfuerzo requerido para probar un programa de forma que se asegure que realiza su
funcin requerida.

Portabilidad: El esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistemas
de software a otro.

Reusabilidad: El grado en que un programa se puede reusar en otras aplicaciones.

Facilidad de interoperacin: El esfuerzo requerido para acoplar un sistema a otro.

Es difcil medir los factores anteriores por lo que McCall propone una serie de mtricas: facilidad de
auditora, exactitud, normalizacin de las comunicaciones, completitud, concisin, consistencia,
estandarizacin en los datos, tolerancia de errores, eficiencia en la ejecucin, facilidad de expansin,
generalidad, independencia del hardware, modularidad, facilidad de operacin, seguridad, autodocumentacin,
simplicidad, independencia del sistema de software, facilidad de traza, formacin.

6.2.2 GARANTA DE CALIDAD.

La garanta de calidad de software es un "planificado y sistemtico diseo de acciones" que se

requieren para asegurar la calidad del software. Comprende una gran variedad de tareas, asociadas con siete
actividades principales:

(1) aplicacin de mtodos tcnicos.

(2) realizacin de revisiones tcnicas formales.
(3) prueba del software.
(4) ajuste a los estndares.
(5) control de cambios.
(6) mediciones.
(7) registro y realizacin de informes.
 La actividad central que permite garantizar la calidad es la revisin tcnica formal. Es una reunin de
personal tcnico con el nico propsito de descubrir problemas de calidad. La prueba de software combina
una estrategia de mltiples pasos con una serie de mtodos de diseo de casos de prueba que ayudan a asegurar
una efectiva deteccin de errores.

6.2.3 TECNICAS DE REVISION.

Las revisiones son un "filtro" para el proceso de ingeniera de software. El beneficio de las revisiones
es el descubrimiento rpido de los defectos del software. Los objetivos de la revision tcnica formal (RTF) son:

(1) Descubrir errores en la funcin, la lgica la implementacin de cualquier representacin del

software.
(2) Verificar que el software bajo revisin alcanza sus requisitos.
(3) Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos.
(4) Conseguir un software desarrollado de forma uniforme y
(5) Hacer que los proyectos sean ms manejables.

6.2.4 MEDIDAS DE CALIDAD.

La determinacin de la calidad es factor clave en cualquier suceso. La calidad se juzga por

comparacin bajo idnticas condiciones y conceptos previamente determinados. Las medidas son indirectas, es
decir, no medimos realmente la calidad, sino algunas de sus manifestaciones.
Algunas manifestaciones pueden ser: estructura del programa, independencia de mdulos, tamao y
compartimentalizacin de la base de datos, caractersticas de E/S, longitud total del programa, volmen
potencial de un algoritmo, nivel del programa (complejidad), esfuerzo de desarrollo, tiempo de desarrollo, etc.

6.3 PROCESO DE INSTALACION

Implica el transporte y la instalacin de un sistema de software desde el entorno de desarrollo al

entorno de destino. Incluye la carga , si es necesaria, de la base de datos, las modificaciones necesarias del
software, las comprobaciones en el entorno de destino y la aceptacin del cliente. Si en el proceso de
instalacin surge un problema se debe identificay e informar de inmediato.

El proceso de instalacin verifica que se implemente la configuracin adecuada del software y

culmina con la aceptacin formal del mismo por parte del cliente conforme a lo especificado en el plan de
gestin de lproceso de software y la realizacin con xito de la prueba de aceptacin del usuario.