Estándares de Calidad en el Diseño de Algoritmos y Construcción de

Programas.

Sin importar cualquiera que sea el tipo de software a ser desarrollado sea de
sistemas (Son programas que sirven a otros programas en el trabajo de
desarrollo como compiladores, editores, ..), tiempo real (Software encargado de
analizar datos del mundo en forma real tales como análisis de datos, control
automatizado, monitoreo de datos), gestión (a esta categoría se incluye el
software comercial a nivel empresarial nominas, inventarios), ingeniería y
científico (es software que posee un amplio manejo numérico usado en
biología, astronomía, CAD, …), empotrado (software que se encuentra
residente en memoria, tales como : controles automáticos en los vehículos,
sistemas de background, partes del sistema operativo, …), computación
personal (software comercial de uso local como procesadores de texto, hojas
electrónicas, navegadores web, calendarios, agendas, recetarios, …),
inteligencia artificial (software de procesamiento especial sistemas expertos,
sistemas basados en el conocimiento, generalmente no usan algoritmos
numéricos). Todos los tipos de software mencionados requieren que los
analistas, diseñadores y desarrolladores apliquen características y elementos
de calidad para que se logren productos a las necesidades del usuario, estas
necesidades se comienzan a encontrar un camino de solución a través de la
aplicación de elementos de calidad, así se presentan dos de los más valiosos
como son la eficiencia y la eficacia.

Calidad en la ingeniería del software. En una versión sucinta la calidad en la

ingeniería del software es un grupo de características que representa la
efectividad y la eficiencia de un sistema de información. Es importante enfatizar
en dos puntos :

• Un software de calidad debe ser eficaz, es decir, que debe realizar las
funciones establecidas, debe ser amigable. Un usuario debe utilizar el software
porque produce resultados confiables, realiza todas las operaciones que se
requieren, ejecuta las operaciones en un tiempo aceptado y es fácilmente
usado por el grupo de usuarios a quien este dirigido.

• Un software de calidad debe ser eficiente, es decir el costo de su

desarrollo tomando todos los recursos y el costo de su operación debe ser tal
que las organizaciones involucradas en su desarrollo y uso obtengan el
máximo beneficio o por lo menos un beneficio aceptable en un período de
tiempo establecido.

• Aspectos básicos de calidad de software.

La descripción que se hace de los factores que influyen en un software de

calidad se basan principalmente en las ideas presentadas por Robert Dunn,
Philip Crosby y Roger S. Pressman. Sin embargo, también se han tomado
algunos aportes de Bertrand Meyer y Mauricio Fernando Alba.

Confiabilidad. Este término es necesario sea separado en varios elementos que

permiten darle al software el matiz de fiable. Sus componente son :

• Completitud

• Consistencia y precisión

• Solidez

• Simplicidad

• Calidad en los procesos de desarrollo

• Seguridad y Verificabilidad, estas dos últimas que se determinan con el

sistema en uso.

Seguridad y auditabilidad. Son importantes, puesto que un usuario no puede

confiar en los datos de un sistema que no le ayude a controlar el acceso de
personas no autorizadas o a detectar errores de operación en los que se
introducen y generan datos erróneos.

Simplicidad. Promueve la utilización de estructuras de fácil manipulación con el

fin de evitar que el programador se aleje del problema que desea resolver.
Además, se reduce la probabilidad de cometer errores. Así que, no es
aconsejable hacer uso de estructuras complejas a menos que se necesite
cumplir con requerimientos de vital importancia tales como tiempos máximos
de proceso u otros similares.

• 1. Realización de Revisiones Técnicas Formales durante cada

etapa.

2. Realización de pruebas y revisiones por personas "externas" al proyecto.

3. Elaboración de la adecuada documentación del software, y de los

cambios.

4. Verificación del cumplimiento de los estándares de desarrollo

5. Medición permanente de la productividad del proceso y de la calidad de

los resultados.

6. Desarrollo y ajustes de modelos estadísticos de calidad y productividad.

7. Control de la desviación de los promedios de calidad y productividad.

Uno de los elementos que permite dar garantía acerca de la calidad del
software es la aplicación de métricas, estas son medidas estadísticas aplicadas
a un software determinado, garantizando calidad así como lo afirma Pressman:
"La garantía de calidad del software, es una "Actividad de protección" que se
aplica a lo largo de todo el proceso de ingeniería del software"

Todos los elementos anteriormente enumerados indican herramientas que se

deben tener en cuenta al momento de desarrollar un software, agrupando en
una definición estos elementos se afirma que : Un software debe estar
desarrollado "En concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo
software" , si cumple los aspectos señalados se puede afirmar que se posee un
software de calidad. Teniendo en cuenta esto, se puede afirmar

1. Los requisitos del software son la base de las medidas de la calidad.

2. Los estándares especificados definen un conjunto de criterios de

desarrollo que guían la forma en que se aplica la ingeniería del software, Si no
se distinguen esos criterios no habrá calidad del software.

3. Existe un conjunto de requisitos implícitos que a menudo no se

mencionan, si no se alcanzan estos requerimientos podría la calidad quedar en
entredicho. Los requisitos son llamados por los usuarios finales llaman
elementos obvios, los cuales el diseñador no debe dejar pasar sin explicación.

Para estar seguros de las anteriores afirmaciones se tienen en cuenta factores

que se pueden medir estos son llamados factores de calidad. Los factores de
calidad se agrupan en dos bloque así :

1. Factores que pueden ser medidos directamente (errores, líneas, tiempo,

…)

2. Factores que sólo pueden ser medidos indirectamente (facilidad de uso,

mantenimiento,…)

Otro autor que contribuye con el aspecto de las medidas en el software es

McCall, él y sus colegas proponen tres factores de calidad y sus partes así :

Factor 1. Características operativas, relacionadas con las operaciones del

producto.

• Corrección

• Fiabilidad

• Eficiencia

• Integridad

• Facilidad de uso
Factor 2. Capacidad de soportar cambios, relacionado con la revisión del
producto.

• Facilidad de mantenimiento

• Flexibilidad

• Facilidad de prueba

Factor 3. Adaptabilidad, relacionado con la transición del producto.

• Portabilidad

• Reusabilidad - Reutilizabilidad

• Interoperabilidad

McCall propone para las métricas asociadas al software un nivel de evaluación

entro cero (0) y diez (10) como medidas. Además, aclara que las métricas y la
evaluación son procesos subjetivos. Los elementos que se pueden tener en
cuenta para la evaluación son :

• Autodocumentación – Que el archivo ejecutable entregue

documentación significativa.

• Completitud – Se han implementado las funciones requeridas.

• Concisión – Compacto en líneas de código.

• Consistencia - Uso de métodos de diseño, técnicas de documentación a

través del desarrollo.

• Eficiencia en la ejecución – Medida del tiempo de ejecución.

• Estandarización de los datos – Manejar tipos abstractos de datos (TAD)

a través del programa.

• Exactitud – Preciso en cálculos y control.

• Facilidad de auditoría – Comprobar la conformidad con los estándares.

• Facilidad de expansión- Facilidad de ampliar diseños arquitectónicos, de

datos, o procedimiento.

• Facilidad de operación -

• Facilidad de traza – Realizar ingeniería en reversa. Que tan fácil es

devolverme a los requerimientos.

• Formación – Debe poseer un buen sistema de ayudas para que los

nuevos usuarios apliquen el sistema.
• Generalidad – Amplitud de aplicación potencial de los componentes del
programa. Es decir, los módulos creados pueden ser útiles en otras
aplicaciones del mismo tipo, o aplicaciones que manejen tipos de datos
semejantes.

• Independencia del hardware – Que los diseños sean independientes de

la máquina o máquinas que se tienen destinadas para el software. A calidad.
pero no a implantación

• Independencia del sistema software – Hasta donde el programa es

independiente de la plataforma de desarrollo.

• Instrumentación – En qué grado el programa muestra funcionamiento e

identifica errores.

• Modularidad – División del programa en componentes funcionales.

Acoplamiento, cohesión.

• Normalización de las comunicaciones – Que tanto se usan estándares,

interfaces, protocolos, entre otros elementos que pueden ser de importancia.

• Seguridad –

• Simplicidad – El sistema de información debe ser fácil de entender.

• Tolerancia de errores- Que tanto se pierde al ocurrir un daño grave.

• Metodologías de desarrollo. Una metodología de desarrollo de software

permite producir organizada y económicamente software de alta calidad,
siguiendo una serie de pasos donde se utilizan un conjunto de técnicas,
notación y normas de documentación preestablecidas.

La traza de un Algoritmo

Se puede definir como la ejecución manual de forma secuencial de las

sentencias que lo componen. Así, la traza del siguiente algoritmo es el valor
que van adoptando las variables a medida que se va ejecutando un programa.

+-Algoritmo Suma

Variable entera a,b

Escribir "Indique el primer sumando"

Leer a

Escribir "Indique el segundo sumando"

Leer b

c=a+b

Escribir "El resultado es: ";c

Final

TRAZA

Comentario Valores

Leemos a 4

Leemos b 5

Calculamos c=a+b 9

Escribimos c 9

Formas y Técnicas de Documentar Algoritmos y programas

Documentar el código de un programa es añadir suficiente información como

para explicar lo que hace, punto por punto, de forma que no sólo los
ordenadores sepan qué hacer, sino que además los humanos entiendan qué
están haciendo y por qué.

Documentar un programa no es sólo un acto de buen hacer del programador

por aquello de dejar la obra rematada. Es además una necesidad que sólo se
aprecia en su debida magnitud cuando hay errores que reparar o hay que
extender el programa con nuevas capacidades o adaptarlo a un nuevo
escenario. Hay dos reglas que no se deben olvidar nunca:

1. todos los programas tienen errores y descubrirlos sólo es cuestión de

tiempo y de que el programa tenga éxito y se utilice frecuentemente

2. todos los programas sufren modificaciones a lo largo de su vida, al

menos todos aquellos que tienen éxito

Por una u otra razón, todo programa que tenga éxito será modificado en el
futuro, bien por el programador original, bien por otro programador que le
sustituya. Pensando en esta revisión de código es por lo que es importante que
el programa se entienda: para poder repararlo y modificarlo.

¿Qué hay que documentar?

Hay que añadir explicaciones a todo lo que no es evidente.

No hay que repetir lo que se hace, sino explicar por qué se hace.
Y eso se traduce en:

• ¿de qué se encarga una clase? ¿un paquete?

• ¿qué hace un método?

• ¿cuál es el uso esperado de un método?

• ¿para qué se usa una variable?

• ¿cuál es el uso esperado de una variable?

• ¿qué algoritmo estamos usando? ¿de dónde lo hemos sacado?

• ¿qué limitaciones tiene el algoritmo? ¿... la implementación?

• ¿qué se debería mejorar ... si hubiera tiempo?

Tipos de comentarios

En Java disponemos de tres notaciones para introducir comentarios:

javadoc

Comienzan con los caracteres "/**", se pueden prolongar a lo largo de varias

líneas (que probablemente comiencen con el carácter "*") y terminan con los
caracteres "*/".

una línea

Comienzan con los caracteres "//" y terminan con la línea

tipo C

Comienzan con los caracteres "/*", se pueden prolongar a lo largo de varias

líneas (que probablemente comiencen con el carácter "*") y terminan con los
caracteres "*/".

Cada tipo de comentario se debe adaptar a un propósito:

javadoc

Para generar documentación externa (ver comentarios javadoc más abajo)

una línea

Para documentar código que no necesitamos que aparezca en la

documentación externa (que genere javadoc)

Este tipo de comentarios se usará incluso cuando el comentario ocupe varias

líneas, cada una de las cuales comenzará con "//"
tipo C

Para eliminar código. Ocurre a menudo que código obsoleto no queremos que
desaparezca, sino mantenerlo "por si acaso". Para que no se ejecute, se
comenta.

(En inglés se suele denominar "comment out")

Javadoc, que veremos posteriormente, impone sus propias reglas prácticas.

¿Cuándo hay que poner un comentario?

Por obligación (javadoc):

1. al principio de cada clase

2. al principio de cada método

3. ante cada variable de clase

Por conveniencia (una línea):

4. al principio de fragmento de código no evidente

5. a lo largo de los bucles

Y por si acaso (una línea):

6. siempre que hagamos algo raro

7. siempre que el código no sea evidente

Es decir, que los comentarios más vale que sobren que falten.

Y una nota de cautela, cuando un programa se modifica, los comentarios

deben modificarse al tiempo, no sea que los comentarios acaben refiriéndose a
un algoritmo que ya no utilizamos.

Javadoc: documentación de APIs

El paquete de desarrollo Java incluye una herramienta, javadoc, para generar

un conjunto de páginas web a partir de los ficheros de código. Esta herramienta
toma en consideración algunos comentarios para generar una documentación
bien presentada de clases y componentes de clases (variables y métodos).

Aunque javadoc no ayuda a la comprensión de los detalles de código, si ayuda

a la comprensión de la arquitectura de la solución, lo que no es poco. Se dice
que javadoc se centra en la interfaz (API - Application Programming Interface)
de las clases y paquetes Java.
Como regla general, hay que destacar que la primera frase (el texto hasta el
primer punto) recibirá un tratamiento destacado, por lo que debe aportar una
explicación concisa y contundente del elemento documentado. Las demás
frases entrarán en detalles.

Introducción a la Elaboración del Manual del Sistema, usuario y programas

Manual de Usuario: Se explicará todas las posibles opciones que puede

realizar el usuario con la aplicaciones de manera detallada, y mediante el uso
de capturas de pantalla. Este documento está dirigido al usuario final.

Partes del manual del usuario:

Portada: Describe de que se trata el documento.

Introducción: Describe el uso del documento, para que sirve y de que habla.

Análisis y requerimientos del sistema: De que se ocupa, para poder instalarlo y

usarlo.

Explicación del funcionamiento: Se describe paso a paso y con pantallas bien

explicadas como funciona el programa.

Glosario: definición de la terminología usada en el manual.

Un Manual debe ser escrito de tal manera, que cualquier persona pueda
entenderlo con la menor dificultad posible. Es recomendable detallar todos
aquellos pasos que se llevan a cabo para usar el programa. Especificar los
alcances y limitaciones que tiene el programa. Un buen punto de partida para
un manual, es hacer de cuenta que las personas que lo van a leer no tienen el
más mínimo conocimiento sobre computadoras.

Técnicas de escritura y pruebas de algoritmos y programas

CONCEPTO DE ALGORITMO:

El algoritmo trata de resolver problemas mediante programas.

Fases:

• Análisis preliminar o evaluación del problema: Estudiar el problema en

general y ver que parte nos interesa.

• Definición o análisis del problema: Ver que es lo que entra y que es lo

que sale, las posibles condiciones o restricciones, ...

• Diseño del algoritmo: Diseñar la solución.

• El programa: Codificación del algoritmo en un lenguaje de programación.

• Ejecución del programa y las pruebas: Ver si el programa hace lo que
queríamos.

¿Qué es un algoritmo?:

Es una formula para resolver un problema. Es un conjunto de acciones o

secuencia de operaciones que ejecutadas en un determinado orden resuelven
el problema. Existen n algoritmos, hay que coger el más efectivo.

Características:

• Tiene que ser preciso.

• Tiene que estar bien definido.

• Tiene que ser finito.

La programación es adaptar el algoritmo al ordenador. El algoritmo es

independiente según donde lo implemente.

1. RESOLUCIÓN DE PROBLEMAS:

La resolución de un problema desde el punto de vista algorítmico tiene 3 fases:

• Análisis del problema: Comprensión.

• Diseño del algoritmo: Resolución algorítmica.

• Resolución en computadora: Implantación del algoritmo en un lenguaje

de programación.

2. ANÁLISIS DEL PROBLEMA:

El objetivo de ésta fase es comprender el problema para lo cual como resultado

tenemos que obtener la especificación de las entradas y salidas del problema.
Tiene que quedar claro que entra y que sale.

3. DISEÑO DEL ALGORITMO:

Una vez comprendido el problema se trata de determinar que pasos o acciones

tenemos que realizar para resolverlo.

Como criterios a seguir a la hora de dar la solución algorítmica hay que tener
en cuenta:

• Si el problema es bastante complicado lo mejor es dividirlo en partes más

pequeñas e intentar dividirlo en partes más pequeñas e intentar resolverlas por
separado. Esta metodología de “divide y vencerás” también se conoce con el
nombre de diseño descendente.
• Las ventajas de aplicar esto son:

• Al dividir el problema en módulos o partes se comprende más

fácilmente.

• Al hacer modificaciones es más fácil sobre un módulo en particular que

en todo el algoritmo.

• En cuanto a los resultados, se probarán mucho mejor comprobando si

cada módulo da el resultado correcto que si intentamos probar de un golpe
todo el programa porque si se produce un error sabemos en que módulo ha
sido.

Una segunda filosofía a la hora de diseñar algoritmos es el refinamiento por

pasos, y es partir de una idea general e ir concretando cada vez más esa
descripción hasta que tengamos algo tan concreto para resolver. Pasamos de
lo más complejo a lo más simple.

La representación de los algoritmos:

Una vez que tenemos la solución hay que implementarla con alguna
representación. Las representaciones más usadas son los flujogramas, los
diagramas NS y el pseudocódigo.

También la solución se puede escribir en algunos casos en lenguaje natural

pero no se hace porque es muy ambiguo, e incluso otras formas de expresión
como fórmulas matemáticas.

Escritura del algoritmo:

Al escribir el algoritmo hay que tener en cuenta:

• Las acciones o pasos a realizar tienen que tener un determinado orden.

• En cada momento solo se puede ejecutar una acción.

• Dentro de las sentencias del algoritmo pueden existir palabras

reservadas (palabras propias del lenguaje de programación que tienen para el
compilador un determinado significado).

• Si estamos utilizando pseudocódigo tenemos también que usar la

identación (aumenta la legibilidad del problema para que se pueda leer mejor).

4. RESOLUCIÓN EN LA COMPUTADORA:

Es hacer entender nuestro algoritmo a la computadora para que lo pueda

hacer.

• Codificamos el algoritmo en un leguaje de programación.

• Ejecutar el programa antes compilado.

• Comprobar los resultados y si no funciona, corregirlo.

5. FLUJOGRAMAS:

Es una notación gráfica para implementar algoritmos. Se basa en la utilización

de unos símbolos gráficos que denominamos cajas, en las que escribimos las
acciones que tiene que realizar el algoritmo.

Las cajas están conectadas entre sí por líneas y eso nos indica el orden en el
que tenemos que ejecutar las acciones.

En todo algoritmo siempre habrá una caja de inicio y otra de fin, para el
principio y final del algoritmo. Son la representación gráfica de la solución
algorítmica de un problema. Para diseñarlos se utilizan determinados símbolos
o figuras que representan una acción dentro del procedimiento. Utilizan unos
símbolos normalizados, con los pasos del algoritmo escritos en el símbolo
adecuado y los símbolos unidos con flechas, denominadas líneas de flujo, que
indican el orden en que los pasos deben ser ejecutados.

Para su elaboración se siguen ciertas reglas:

Se escribe de arriba hacia abajo y de izquierda a derecha

Siempre se usan flechas verticales u horizontales, jamás curvas

Evitar cruce de flujos

En cada paso expresar una acción concreta

Secuencia de flujo normal en una solución de problema

Tiene un inicio

Una lectura o entrada de datos

El proceso de datos

Una salida de información

Un final

Los símbolos:

Líneas de flujo: Una línea con una flecha que sirve para conectar los símbolos
del diagrama y la flecha indica la secuencia en la que se van a ejecutar las
acciones.

Símbolo de proceso: Indica la acción que tiene que realizar la computadora.

Dentro escribimos la acción.
Representa las acciones de entrada y salida. Dentro colocaremos las acciones
de lectura y escritura.

Condición: Dentro se va a colocar una condición. Sirve para representar

estructuras selectivas y repetitivas y lo que se hace al encontrar ese signo es
evaluar la condición que hay dentro tal que según la condición sea verdadera o
falsa iremos por caminos distintos.

Principio y fin: Dentro del símbolo ira la palabra inicio o fin del algoritmo.

Subprograma: Dentro se coloca el nombre del subprograma al que se llama.

Conectores: Nos sirven cuando un flujograma no me cabe en una columna de

la hoja y hay que seguir en otra columna:

• Si es en la misma hoja:

• Si es en hoja distinta:

Los conectores se ponen uno donde termina la columna y otra donde empieza.

Es una aclaración para entender mejor el código, pero no es parte del código,
no se ejecuta.

Otros símbolos:

- Pantalla: Cuando una salida es por pantalla.

- Teclado: Para representar una entrada por teclado.

- Impresora:

- Entrada/Salida por disco