Ultima Unidad / Ultimo Exámen Parcial

V.
IMPLEMENTACION
5.1 LENGUAJES DE ANALISIS Y DISEÑO.
5.1.1 CARACTERISTICAS.
Los lenguajes de programación son un vehículo entre los humanos y las computadoras. Las
características de ingeniería de un lenguaje tienen un impacto importante sobre el éxito de un proyecto de
desarrollo de software. Las característics técnicas pueden influenciar la calidad del diseño. A continuación se
manifiestan algunas de ellas:
Uniformidad: indica el grado en que un lenguaje usa una notación consistente, aplica restricciones
aparentemente arbitrarias ó incluye excepciones a reglas sintácticas ó semánticas. Ejemplo: uso de paréntesis y
corchetes.
Ambigüedad: 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 aritméticas ).
Compacto: es un indicativo de la cantidad de información orientada al código 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 características implícitas, el número de operadores aritméticos y lógicos, el número de
funciones incorporadas.
La memoria y reconociiento humano se pueden dividir en campos sinestético y secuencial. La
memoria sinestética 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 (canción).
Localización: es característica sinestética de un lenguaje, se potencia cuando las sentencias se pueden
combinar en bloques, cuando las construcciones estructuradas se pueden implementar directamente y cuando el
diseño y el código resultante son altamente modulares y cohesivos. Una característica que viola la localización
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 lógicos.
Tradición: afecta la capacidad de aprender un nuevo lenguaje, asi como al grado de innovación
durante el diseño de un lenguaje de programación.
5.1.2 FUNDAMENTOS.
Un planteamiento de ingeniería del software sobre las características de los lenguajes de programación
se centra en las necesidades que puede tener un proyecto específico de desarrollo de software. Se puede
establecer el siguiente conjunto:
(1) facilidad de traducción del diseño al código: proporciona una indicación de como se aproxima un lenguaje a
la representación del diseño.
(2) eficiencia del compilador.
(3) portabilidad del código fuente: considera si el código fuente puede ser transportado de un procesador a otro
y un compilador a otro, sin ninguna o pocas modificaciones; si el código fuente permanece inalterado cuando
cambia su entorno de funcionamiento (nuevo sistema operativo); si el código fuente puede ser integrado en
diferentes paquetes de software sin requerir modificación.
(4) disponibilidad de herramientas de desarrollo: puede acortar el tiempo requerido para la generación del
código fuente y puede mejorar la calidad del código.
(5) facilidad de mantenimiento.
Entre los criterios para la elección de un lenguaje de programación para un proyecto específico se
tienen:
(1) Area de aplicación general.
(2) Complejidad algorítmica 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 diseño de software viene dada por su independencia de las características de los lenguajes de
programación. Sin embargo, los atributos del lenguaje juegan su papel en la calidad de un diseño acabado y
afectan a la forma de especificar el diseño.
5.1.3 EFICIENCIA.
En los sistemas catalogados como buenos bajo el punto de vista de ingeniería, existe una tendencia
natural a usar los recursos críticos de forma eficiente. Los ciclos del procesador y las posiciones de memoria, a
menudo, se tratan como recursos críticos y el paso de codificación 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 máximas. En primer lugar, la
eficiencia es un requisito de rendimiento y, como tal, se debe establecer durante el análisis 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 diseño. En tercer lugar, la eficiencia del
código y la simplicidad del mismo van de la mano. En general, no sacrificar la claridad, legibilidad o corrección
en pos de una mejor eficiencia no esencial.
EFICIENCIA EN CODIGO:
Esta directamente unida a la eficiencia de los algoritmos definidos durante el diseño detallado. Algunas
directrices a seguir son:
* Simplificar las expresiones aritméticas y lógicas antes de convertirlas en código.
* 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 "rápidas" operaciones aritméticas.
* No mezclar tipos de datos, aunque el lenguaje lo permita.
* Usar, cuando sea posible, aritmética entera y expresiones lógicas.
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 "paginación" del sistema, es decir la localización del código
en un campo funcional mediante construcciones estructuradas reduce la paginación 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
información se puede suministrar o se puede comprender con el mínimo 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 número de peticiones de E/S ; toda E/S debe tratarse con buffer para
reducir embotellamiento en la comunicación; para memorias secundarias debe seleccionarse y usar el método
de acceso más 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 código el software debe ser probado para descubrir el máximo 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 ejecución de un programa con la intención 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 diseñar pruebas que saque a la luz diferentes clases de errores, haciéndolo 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 técnicas se
fundamentas en los siguientes principios:
(1) A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente
(2) Las pruebas deberían planificarse mucho antes de que empiecen
(3) Las pruebas deberían empezar por lo "pequeño" y progresar hacia "lo grande" ( módulos )
(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
características que llevan a un software fácil de probar son:
(a) Operatividad: cuanto mejor funcione, mas eficentemente se puede probar, el sistema tiene pocos
errores, ningun error bloquea la ejecución 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 fácilmente, 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 descomposición : 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 comprensión : cuanta mas informacion tengamos, mas inteligentes seran las pruebas,
entendible el diseño, las dependencias, la documentación, si es especifica, detallada y exacta
5.2.3 CASOS DE PRUEBA
Cualquier producto puede probarse de una de estas dos formas : conociendo la función específica
para la que fue diseñado el producto llevando a cabo pruebas que demuestren que cada función 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 lógica interna del programa utilizando técnicas de diseño de casos de prueba de "caja blanca"
(2) los requisitos del software utilizando técnicas de diseño 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 lógicos. Utiliza la
estructura de control del diseño procedural para derivar los casos de prueba. Este método obtiene
casos de prueba que:
* garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada módulo.
* ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
* ejecuten todos los bucles en sus límites y con sus límites 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, más 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 inicialización y de terminación.
Prueba del camino basico
Prueba de complejidad ciclomática
Prueba de condición
Prueba de dominio
Prueba BRO
Prueba de flujo de datos
Prueba de bucles
Prueba de sistemas de tiempo-real
Prueba basadas en grafos
Prueba de partición equivalente
Prueba de comparación
Prueba de tabla ortogonal
Prueba de Interfaces gráficas
Prueba de arquitectura cliente/servidor
Prueba de documentación
Configuración del Software
──────────┐
V
Errores
┌────────┐
Resultados
┌────────>
│ PRUEBA
├─────────> ┌───────┴─┐ ┌─────────┐
└────────┘
│ EVALUACION │ │ DEPURACION │
^
└── ┬──────┘ └────┬────┘
───────────┘
│
V
Configuración de
│
Correcciones
Prueba
Datos de Tasa de error │
V
│ MODELO DE │
│ FIABILIDAD │ Predicción de
└──────> fiabilidad
Fig. 7.1 Flujo de Información en la prueba.
Se proporcionan dos entradas al proceso de prueba: la configuración del software que incluye la
especificación de requisitos del software, especificación del diseño y el código fuente; y la configuración 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 evalúan los resultados. Al descubrir datos erróneos comienza la
depuración. Si se encuentran con regularidad serios errores requiere modificaciones en el diseño siendo
necesarias posteriores pruebas. Si el funcionamiento parece ser correcto y los errores son fácilmente
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 serán
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 ingeniería del software se puede ver como una espiral. Inicialmente, la ingeniería del
sistema define el papel del software y conduce al análisis de requisitos, donde se establece el campo de
información, la función, el comportamiento, el rendimiento, las restricciones y criterios de validación del
software. Al movernos hacia adentro de la espiral, llegamos al diseño y por último a la codificación.
Las pruebas del software aplican similar estrategia moviendonos de adentro hacia afuera de la espiral.
la prueba de unidad comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está
implementada en código fuente. La prueba avanza para llegar a la prueba de integración, donde el foco de
atención es el diseño y construcción de la arquitectura del software. Otra vuelta hacia afuera encontramos la
prueba de validación, donde se validadn los requisitos establecidos como parte del análisis de requisitos del
software, comparándolos 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 verificación en la menor unidad del diseño: el módulo.
Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes, con el
fin de descubrir errores dentro del módulo.
Se prueba la interface para asegurar que la información 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 ejecución del algoritmo. Se
prueban las condiciones límite para asegurar que el módulo funciona correctamente con los límites
establecidos. Se ejercitan todos los caminos independientes de la estructura de control para asegurar que todas
las sentencias del módulo se ejecuten por lo menos una vez. Y finalmente se prueban todos los caminos de
manejo de errores.
5.3.2 PRUEBAS DE INTEGRACIÓN.
Si todos los modulos funcionan bien ¿ por qué dudar de que funcionen bien juntos ?. El problema es
"ponerlos juntos". La prueba de integración detecta errores de interacción. El procedimiento adecuado se llama
integración incremental con el cual se construye y se prueba en pequeños segmentos en los que los errores
son más fáciles de aislar y corregir.
Un plan general de integración y una descripción de las pruebas específicas deben quedar
documentados en una especificación de prueba, es parte esencial del proceso de ingeniería de software y
forma parte de la configuración del software.
Un perfil de la especificación 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 integración.
1. Propósito.
2. Módulos a ser probados.
B. Pruebas de unidad para los módulos de la subfase.
1. Descripción de pruebas para el módulo M.
2. Descripción del software adicional.
3. Resultados esperados.
C. Entorno de prueba.
1. Herramientas o técnicas especiales.
2. Descripción 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. Apéndices.
El alcance de prueba resume las características funcionales, de rendimiento y diseño interno
específicas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminación de cada fase de
prueba y se documentan las limitaciones del plan.
El plan de prueba describe la estrategia general para la integración. Se divide en fases y subfases. En
todas las fases se siguen los siguientes criterios: Integridad de interface, validez funcional, contenido de la
información y rendimiento.
La sección de procedimiento de prueba describe detalladamente el procedimiento de prueba
requerido para llevar a cabo el plan de prueba, describiendo el orden de integración 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 información
es vital para el mantenimiento del software.
5.3.3 PRUEBAS DE VALIDACIÓN.
Una vez ensamblado como paquete probamos la validación, la cual se logra cuando el software
funciona de acuerdo con las expectativas razonables del cliente. Estas espectativas están definidas en la
especificación de requisitos que describe los atributos del software visibles al usuario, basado en los criterios de
validación de dicho documento.
La prueba de validación 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 características de
funcionamiento ó de rendimiento están de acuerdo con las especificaciones y son aceptables, ó se descubre una
desviación 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 ó más lugares de clientes y usuarios finales. Como resultado el equipo de
desarrollo de software lleva a cabo modificaciones y así prepara una versión 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 propósito es ejercitar
profundamente el sistema basado en computadora. Entre pruebas de sistema tenemos:
Prueba de recuperación: forza el fallo del software de muchas formas y verifica que la recuperación
se lleva a cabo apropiadamente. Se evalúa la corrección de reinicialización, mecanismos de recuperación del
estado del sistema, recuperación de datos y rearranque.
Prueba de seguridad: intenta verificar que los mecanismos de protección del sistema lo protegerán
adecuadamente.
Prueba de resistencia: está diseñada para enfrentar a los programas con situaciones anormales, es
decir, ejecuta un sistema de forma que demande recursos en cantidad, frecuencia ó volúmenes anormales. Una
variación 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 ejecución. 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 más que una corrección de errores. Se describe el
mantenimiento describiendo las actividades después de distribuir un programa:
La primer actividad es el mantenimiento correctivo: proceso que incluye el diagnóstico y corrección
de uno ó más 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. También denominada mantenimiento
perfectivo, pero se caracteriza por utilizar la ingeniería inversa y reingeniería.
6.1.2 PROBLEMAS CARACTERÍSTICOS.
Entre los problemas clásicos asociados con el manteniiento se encuentran:
* Es difícil ó imposible seguir la evolución del software a través de varias versiones. Los cambios no
están adecuadamente documentados.
* Es difícil ó imposible seguir el proceso por el que se construyó el software.
* Es excepcionalmente difícil comprender un programa ajeno.
* Si existen menos elementos de configuración del software (documentos), mayor es la dificultad.
* Esa persona ajena no se encuentra cerca para explicar lo que hizo.
* No existe una documentación apropiada ó está mal preparada.
* La mayoría del software no ha sido diseñado previendo el cambio; a menos que se prevea el cambio
utilizando independencia funcional ó clases de objetos, las modificaciones serán difíciles 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 número de métricas 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 recolección de herramientas de mantenimiento.
4. Tiempo de análisis del problema.
5. Tiempo de especificación de los cambios.
6. Tiempo activo de corrección ( ó modificación ).
7. Tiempo de prueba local.
8. Tiempo de prueba global.
9. Tiempo de revisión del mantenimiento.
10. Tiempo total de recuperación.
Además de éstas medidas orientadas al tiempo, se puede medir indirectamente considerando medidas
de la estructura del diseño y métricas 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
petición de mantenimiento. Inicialmente se debe establecer una organización de mantenimiento; se deben
prescribir procedimientos de evaluación y de información, y se debe definir una secuencia estándar de sucesos
para cada petición de mantenimiento. Además debe establecerse un sistema de registro de información de las
actividades de mantenimiento y definir criterios de revisión y de evaluación.
El registro de información comprenden los siguientes datos:
1. Identificación del programa.
2. Número de sentencias fuente.
3. Número de instrucciones en código máquina.
4. Lenguaje de programación usado.
5. Fecha de instalación del programa.
6. Número de ejecuciones del programa desde la instalación.
7. Número de fallas de procesamiento asociados con el punto anterior.
8. Nivel e identificación de cambios sobre el programa.
9. Número de sentencias fuente añadida en los cambios del programa.
10. Número de sentencias eliminadas en los cambios del programa.
11. Número de personas-hora por cambio.
12. Fecha de cambio del programa.
13. Identificación del ingeniero de software.
14. Identificación del FPM ( Flujo del Proceso de
Mantenimiento).
15. Tipo de mantenimiento.
16. Fechas de comienzo y final del mantenimiento.
17. Número de personas/hora acumuladas para el mantenimiento.
18. Beneficios netos asociados con el mantenimiento realizado.
6.1.5 EFECTOS DEL MANTENIMIENTO.
La documentación del diseño y una cuidadosa prueba de regresión ayudan a eliminar errores, pero
seguirán apareciendo efectos secundarios del mantenimiento.
Efectos secundarios sobre el código: un subprograma eliminado ó cambiado, eliminación ó
modificación de una sentencia de etiqueta, eliminación ó modificación de un identificador, cambios para
mejorar el rendimiento en ejecución, modificación de operadores lógicos, cambios sobre las pruebas de límites.
Efectos secundarios sobre los datos: redefinición de constantes locales ó globales, redefinición de
formatos de registros ó de archivos, aumento ó disminución del tamaño de arreglos ó de otras estructuras de
datos de mayor orden, modificación de datos globales, reinicialización de indicadores de control ó de
apuntadores, reorganización de argumentos de E/S ó de subprogramas.
Efectos secundarios sobre la documentación: siempre que se haga un cambio en el flujo de datos,
arquitectura, procedimientos ó sistema, debe actualizarse la documentación técnica de soporte.
6.1.6 ASPECTOS DEL MANTENIMIENTO.
La ingeniería inversa es un proceso de análisis de un programa en un esfuerzo por crear una
representación del programa de mayor nivel de abstacción que el código fuente. Es un proceso de recuperación
de diseño. Estas herramientas extraen la información del diseño de datos, arquitectónico y procedimental de un
programa.
No sólo recupera la información, sino que usa esa información para alterar ó reconstruir el sistema
existente, en un esfuerzo de mejorar la calidad general. La mayoría de los casos implementa la función del
sistema existente, pero también añade nuevas funciones y/o mejora el rendimiento general.
6.1.7 CONFIGURACION DEL SOFTWARE.
El resultado del proceso de ingeniería de software es una información que se puede dividir en tres
categorías (1) programas de computadora; (2) documentos que describen los programas y (3) estructuras de
datos.
Los elementos que componen toda la información producida como parte del proceso de ingeniería del
software se denominan colectivamente configuración del software. En forma más realista un Elemento de
Configuración 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 técnicas de gestión de configuraciones y forman un
conjunto de líneas base:
1. Especificación del sistema.
2. Plan del proyecto del software.
3. a. Especificación de requisitos del software.
b. Prototipo ejecutable ó "en papel".
4. Manual de usuario preliminar.
5. Especificación del diseño.
5. a. Descripción del diseño de datos.
b. Descripción del diseño arquitectónico.
c. Descripciones del diseño de los módulos.
d. Descripciones del diseño de las interfaces.
e. Descripciones de los objetos.
6. Listados del código fuente.
7.
a. Plan y procedimiento de prueba.
b. Casos de prueba y resultados registrados.
8. Manuales de operación y de instalación.
9. Programas ejecutables.
a. Módulos, código ejecutable.
b. Módulos enlazados.
10. Descripción 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 ingeniería.
13. Estándares y procedimientos de ingeniería de software.
Construir diversos diseños de software en base a un Proyecto Propuesto por el alumno durante el
curso, aplicando diferentes técnicas de diseño y realizando la documentación 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 sólo pueden ser medidos indirectamente: facilidad de uso ó de mantenimiento.
Debemos comparar el software con alguna referencia y llegar a una indicación de la calidad. McCall
propone una clasificación de los factores de calidad del software centrados en tres aspectos: características
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
misión encomendada por el cliente.
Fiabilidad: el grado en que se puede esperar que un programa lleva a cabo sus funcionese esperadas con la
precisión requerida.
Eficiencia: la cantidad de recursos de computadora y de código 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 Capítulo).
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
función 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 interoperación: El esfuerzo requerido para acoplar un sistema a otro.
Es difícil medir los factores anteriores por lo que McCall propone una serie de métricas: facilidad de
auditoría, exactitud, normalización de las comunicaciones, completitud, concisión, consistencia,
estandarización en los datos, tolerancia de errores, eficiencia en la ejecución, facilidad de expansión,
generalidad, independencia del hardware, modularidad, facilidad de operación, seguridad, autodocumentación,
simplicidad, independencia del sistema de software, facilidad de traza, formación.
6.2.2 GARANTÍA DE CALIDAD.
La garantía de calidad de software es un "planificado y sistemático diseño de acciones" que se
requieren para asegurar la calidad del software. Comprende una gran variedad de tareas, asociadas con siete
actividades principales:
(1) aplicación de métodos técnicos.
(2) realización de revisiones técnicas formales.
(3) prueba del software.
(4) ajuste a los estándares.
(5) control de cambios.
(6) mediciones.
(7) registro y realización de informes.
La actividad central que permite garantizar la calidad es la revisión técnica formal. Es una reunión de
personal técnico con el único propósito de descubrir problemas de calidad. La prueba de software combina
una estrategia de múltiples pasos con una serie de métodos de diseño de casos de prueba que ayudan a asegurar
una efectiva detección de errores.
6.2.3 TECNICAS DE REVISION.
Las revisiones son un "filtro" para el proceso de ingeniería de software. El beneficio de las revisiones
es el descubrimiento rápido de los defectos del software. Los objetivos de la revision técnica formal (RTF) son:
(1) Descubrir errores en la función, la lógica ó la implementación de cualquier representación del
software.
(2) Verificar que el software bajo revisión alcanza sus requisitos.
(3) Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.
(4) Conseguir un software desarrollado de forma uniforme y
(5) Hacer que los proyectos sean más manejables.
6.2.4 MEDIDAS DE CALIDAD.
La determinación de la calidad es factor clave en cualquier suceso. La calidad se juzga por
comparación bajo idénticas 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 módulos, tamaño y
compartimentalización de la base de datos, características de E/S, longitud total del programa, volúmen
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 instalación 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 aceptación del cliente. Si en el proceso de
instalación surge un problema se debe identificay e informar de inmediato.
El proceso de instalación verifica que se implemente la configuración adecuada del software y
culmina con la aceptación formal del mismo por parte del cliente conforme a lo especificado en el plan de
gestión de lproceso de software y la realización con éxito de la prueba de aceptación del usuario.