Estndares de Calidad en el Diseo de Algoritmos y Construccin 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 anlisis de datos, control automatizado, monitoreo de datos), gestin (a esta categora se incluye el software comercial a nivel empresarial nominas, inventarios), ingeniera y cientfico (es software que posee un amplio manejo numri co usado en biologa, astronoma, CAD, ), empotrado (software que se encuentra residente en memoria, tales como : controles automticos en los vehculos, sistemas de background, partes del sistema operativo, ), computacin personal (software comercial de uso local como procesadores de texto, hojas electrnicas, navegadores web, calendarios, agendas, recetarios, ), inteligencia artificial (software de procesamiento especial sistemas expertos, sistemas basados en el conocimiento, generalmente no usan algor itmos numricos). Todos los tipos de software mencionados requieren que los analistas, diseadores y desarrolladores apliquen caractersticas y elementos de calidad para que se logren productos a las necesidades del usuario, estas necesidades se comienzan a encontrar un camino de solucin a travs de la aplicacin de elementos de calidad, as se presentan dos de los ms valiosos como son la eficiencia y la eficacia. Calidad en la ingeniera del software. En una versin sucinta la calidad en la ingeniera del software es un grupo de caractersticas que representa la efectividad y la eficiencia de un sistema de informacin. 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 fcilmente usado por el grupo de usuarios a quien este dirigid o. Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando todos los recursos y el costo de su operacin debe ser tal que las organizaciones involucradas en su desarrollo y uso obtengan el mximo beneficio o por lo menos un beneficio aceptable en un perodo de tiempo establecido. Aspectos bsicos de calidad de software.

La descripcin 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, tambin se han tomado algunos aportes de Bertrand Meyer y Mauricio Fernando Alba. Confiabilidad. Este trmino es necesario sea separado en varios elementos que permiten darle al software el matiz de fiable. Sus comp onente son : Completitud Consistencia y precisin 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, pue sto 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 operacin en los que se introducen y generan datos errneos. Simplicidad. Promueve la utilizacin de es tructuras de fcil manipulacin con el fin de evitar que el programador se aleje del problema que desea resolver. Adems, 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 mximos de proceso u otros similares. 1. etapa. 2. Realizacin de Revisiones Tcnicas Formales durante cada

Realizacin de pruebas y revisiones por personas "externas" al proyecto.

3. Elaboracin de la adecuada documentacin del software, y de los cambios. 4. Verificacin del cumplimiento de los estndares de desarrollo

5. Medicin permanente de la productividad del proceso y de la calidad de los resultados. 6. 7. Desarrollo y ajustes de modelos estadsticos de calidad y productividad. Control de la desviacin de los promedios de calidad y productividad.

Uno de los elementos que permite dar garanta acerca de la calidad del software es la aplicacin de mtricas, estas son medidas estadsti cas aplicadas

a un software determinado, garantizando calidad as como lo afirma Pressman: "La garanta de calidad del software, es una "Actividad de proteccin" que se aplica a lo largo de todo el proceso de ingeniera del software" Todos los elementos anteriormente enumerados indican herramientas que se deben tener en cuenta al momento de desarrollar un software, agrupando en una definicin estos elementos se afirma que : Un software debe estar desarrollado "En concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software" , si cumple los aspectos sealados 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 estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software, Si no se distinguen esos criterios no habr calidad del software. 3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan, si no se alcanzan estos requerimientos podra la calidad quedar en entredicho. Los requisitos son llamados por los usuarios finales llaman elementos obvios, los cuales el diseador no debe dejar pasar sin explicacin. 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, lne as, tiempo,) 2. Factores que slo 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. Caractersticas operativas, relacionadas con las operaciones del producto. Correccin Fiabilidad Eficiencia Integridad Facilidad de uso

Factor 2. Capacidad de soportar cambios, relacionado con la revisin del producto. Facilidad de mantenimiento Flexibilidad Facilidad de prueba

Factor 3. Adaptabilidad, relacionado con la transicin del producto. Portabilidad Reusabilidad - Reutilizabilidad Interoperabilidad

McCall propone para las mtricas asociadas al software un nivel de evaluacin entro cero (0) y diez (10) como medidas. Adems, aclara que las mtricas y la evaluacin son procesos subjetivos. Los elementos que se pueden tener en cuenta para la evaluacin son : Autodocumentacin documentacin significativa. Que el archivo ejecutable entregue

Completitud Se han implementado las funciones requeridas. Concisin Compacto en lneas de cdigo.

Consistencia - Uso de mtodos de diseo, tcnicas de documentacin a travs del desarrollo. Eficiencia en la ejecucin Medida del tiempo de ejecucin.

Estandarizacin de los datos Manejar tipos abstractos de datos (TAD) a travs del programa. Exactitud Preciso en clculos y control. Facilidad de auditora Comprobar la conformidad con los estndares.

Facilidad de expansin- Facilidad de ampliar diseos arquitectnicos, de datos, o procedimiento. Facilidad de operacin -

Facilidad de traza Realizar ingeniera en reversa. Que tan fcil es devolverme a los requerimientos. Formacin Debe poseer un buen sistema de ayudas para que los nuevos usuarios apliquen el sistema.

 Generalidad Amplitud de aplicacin potencial de los componentes del programa. Es decir, los mdulos creados pueden ser tiles en otras aplicaciones del mismo tipo, o aplicaciones que manejen tipos de datos semejantes. Independencia del hardware Que los diseos sean independientes de la mquina o mquinas que se tienen destinadas para el software. A calidad. pero no a implantacin Independencia del sistema software Hasta donde el programa es independiente de la plataforma de desarrollo. Instrumentacin En qu grado el programa muestra funcionamiento e identifica errores. Modularidad Divisin del programa en componentes funcionales. Acoplamiento, cohesin. Normalizacin de las comunicaciones Que tanto se usan estndares, interfaces, protocolos, entre otros elementos que pueden ser de importancia. Seguridad Simplicidad El sistema de informacin debe ser fcil de entender. Tolerancia de errores- Que tanto se pierde al ocurrir un dao grave.

Metodologas de desarrollo. Una metodologa de desarrollo de software permite producir organizada y econmicamente software de alta calidad, siguiendo una serie de pasos donde se utilizan un conjunto de tcnicas, notacin y normas de documentacin preestablecidas. La traza de un Algoritmo Se puede definir como la ejecucin 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 Leemos b 4 5

Calculamos c=a+b 9 Escribimos c 9 Formas y Tcnicas de Documentar Algoritmos y programas Documentar el cdigo de un programa es aadir suficiente informacin como para explicar lo que hace, punto por punto, de forma que no slo los ordenadores sepan qu hacer, sino que adems los humanos entiendan qu estn haciendo y por qu. Documentar un programa no es slo un acto de buen hacer del programador por aquello de dejar la obra rematada. Es adems una necesidad que slo 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 slo es cuestin 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 razn, 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 revisin de cdigo es por lo que es importante que el programa se entienda: para poder repararlo y modificarlo. Qu hay que documentar? Hay que aadir 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 mtodo? cul es el uso esperado de un mtodo? para qu se usa una variable? cul es el uso esperado de una variable? qu algoritmo estamos usando? de dnde lo hemos sacado? qu limitaciones tiene el algoritmo? ... la implementacin? qu se debera 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 lneas (que probablemente comiencen con el carcter "*") y terminan con los caracteres "*/". una lnea Comienzan con los caracteres "//" y terminan con la lnea tipo C Comienzan con los caracteres "/*", se pueden prolongar a lo largo de varias lneas (que probablemente comiencen con el carcter "*") y terminan con los caracteres "*/". Cada tipo de comentario se debe adaptar a un propsito: javadoc Para generar documentacin externa (ver comentarios javadoc ms abajo) una lnea Para documentar cdigo que no necesitamos que aparezca en la documentacin externa (que genere javadoc) Este tipo de comentarios se usar incluso cuando el comentario ocupe varias lneas, cada una de las cuales comenzar con "//"

tipo C Para eliminar cdigo. Ocurre a menudo que cdigo obsoleto no queremos que desaparezca, sino mantenerlo "por si acaso". Para que no se ejecute, se comenta. (En ingls se suele denominar "comment out") Javadoc, que veremos posteriormente, impone sus propias reglas prcticas. Cundo hay que poner un comentario? Por obligacin (javadoc): 1. 2. 3. al principio de cada clase al principio de cada mtodo ante cada variable de clase

Por conveniencia (una lnea): 4. 5. al principio de fragmento de cdigo no evidente a lo largo de los bucles

Y por si acaso (una lnea): 6. 7. siempre que hagamos algo raro siempre que el cdigo no sea evidente

Es decir, que los comentarios ms 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 refirindose a un algoritmo que ya no utilizamos. Javadoc: documentacin de APIs El paquete de desarrollo Java incluye una he rramienta, javadoc, para generar un conjunto de pginas web a partir de los ficheros de cdigo. Esta herramienta toma en consideracin algunos comentarios para generar una documentacin bien presentada de clases y componentes de clases (variables y mtodos ). Aunque javadoc no ayuda a la comprensin de los detalles de cdigo, si ayuda a la comprensin de la arquitectura de la solucin, 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 explicacin concisa y contundente del elemento documentado. Las dems frases entrarn en detalles. Introduccin a la Elaboracin 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 docum ento est dirigido al usuario final. Partes del manual del usuario: Portada: Describe de que se trata el documento. Introduccin: Describe el uso del documento, para que sirve y de que habla. Anlisis y requerimientos del sistema: De que se ocupa, para p oder instalarlo y usarlo. Explicacin del funcionamiento: Se describe paso a paso y con pantallas bien explicadas como funciona el programa. Glosario: definicin de la terminologa 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 ms mnimo conocimiento sobre computadoras. Tcnicas de escritura y pruebas de algoritmos y programas CONCEPTO DE ALGORITMO: El algoritmo trata de resolver problemas mediante programas. Fases: Anlisis preliminar o evaluacin del problema: Estudiar el problema en general y ver que parte nos interesa. Definicin o anlisis del problema: Ver que es lo que entra y que es lo que sale, las posibles condiciones o restricciones, ... Diseo del algoritmo: Disear la solucin. El programa: Codificacin del algoritmo en un lenguaje de programacin.

 Ejecucin del programa y las pruebas: Ver si el programa hace lo que queramos. Qu es un algoritmo?: Es una formula para resolver un problema. Es u n conjunto de acciones o secuencia de operaciones que ejecutadas en un determinado orden resuelven el problema. Existen n algoritmos, hay que coger el ms efectivo. Caractersticas: Tiene que ser preciso. Tiene que estar bien definido. Tiene que ser finito.

La programacin es adaptar el algoritmo al ordenador. El algoritmo es independiente segn donde lo implemente.

1. RESOLUCIN DE PROBLEMAS: La resolucin de un problema desde el punto de vista algortmico tiene 3 fases: Anlisis del problema: Comprensin. Diseo del algoritmo: Resolucin algortmica.

Resolucin en computadora: Implantacin del algoritmo en un lenguaje de programacin. 2. ANLISIS DEL PROBLEMA: El objetivo de sta fase es comprender el problema para lo cual como resultado tenemos que obtener la especificacin de las entradas y salidas del problema. Tiene que quedar claro que entra y que sale. 3. DISEO DEL ALGORITMO: Una vez comprendido el problema se trata de determinar que pasos o acciones tenemos que realizar para resolver lo. Como criterios a seguir a la hora de dar la solucin algortmica hay que tener en cuenta: Si el problema es bastante complicado lo mejor es dividirlo en partes ms pequeas e intentar dividirlo en partes ms pequeas e intentar resolverlas por separado. Esta metodologa de divide y vencers tambin se conoce con el nombre de diseo descendente.

 Las ventajas de aplicar esto son: Al dividir el problema en mdulos o partes se comprende ms fcilmente. Al hacer modificaciones es ms fcil sobre un mdulo en particular que en todo el algoritmo. En cuanto a los resultados, se probarn mucho mejor comprobando si cada mdulo da el resultado correcto que si intentamos probar de un golpe todo el programa porque si se produce un error sabemos en que mdulo ha sido. Una segunda filosofa a la hora de disear algoritmos es el refinamiento por pasos, y es partir de una idea general e ir concretando cada vez ms esa descripcin hasta que tengamos algo tan concreto para resolver. Pasamos de lo ms complejo a lo ms simple. La representacin de los algoritmos: Una vez que tenemos la solucin hay que implementarla con alguna representacin. Las representaciones ms usadas son los flujogramas, los diagramas NS y el pseudocdigo. Tambin la solucin se puede escribir en algunos casos en lenguaje natural pero no se hace porque es muy ambiguo, e incluso otras formas de expresin como frmulas matemticas. 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 accin.

Dentro de las sentencias del algoritmo pueden existir palabras reservadas (palabras propias del lenguaje de programacin que tienen para el compilador un determinad o significado). Si estamos utilizando pseudocdigo tenemos tambin que usar la identacin (aumenta la legibilidad del problema para que se pueda leer mejor). 4. RESOLUCIN EN LA COMPUTADORA: Es hacer entender nuestro algoritmo a la computadora para que lo pueda hacer. Codificamos el algoritmo en un leguaje de programacin.

 Ejecutar el programa antes compilado. Comprobar los resultados y si no funciona, corregirlo. 5. FLUJOGRAMAS: Es una notacin grfica para implementar algoritmos. Se basa en la utilizacin de unos smbolos grficos que denominamos cajas, en las que escribimos las acciones que tiene que realizar el algoritmo. Las cajas estn conectadas entre s por lneas 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 representacin grfica de la solucin algortmica de un problema. Para disearlos se utilizan determinados smbolos o figuras que representan una accin dentro del procedimiento. Utilizan unos smbolos normalizados, con los pasos del algoritmo escritos en el smbolo adecuado y los smbolos unidos con flechas, denominadas lneas de flujo, que indican el orden en que los pasos deben ser ejecutados. Para su elaboracin se siguen ciertas reglas: Se escribe de arriba hacia abajo y de izquierda a derecha Siempre se usan flechas verticales u horizontales, jams curvas Evitar cruce de flujos En cada paso expresar una accin concreta Secuencia de flujo normal en una solucin de problema Tiene un inicio Una lectura o entrada de datos El proceso de datos Una salida de informacin Un final Los smbolos: Lneas de flujo: Una lnea con una flecha que sirve para conectar los smbolos del diagrama y la flecha indica la secuencia en la que se van a ejecutar las acciones. Smbolo de proceso: Indica la accin que tiene que realizar la computadora. Dentro escribimos la accin.

Representa las acciones de entrada y salida. Dentro colocaremos las acciones de lectura y escritura. Condicin: Dentro se va a colocar una condicin. Sirve para representar estructuras selectivas y repetitivas y lo que se hace al encontrar ese signo es evaluar la condicin que hay dentro tal que segn la condicin sea verdadera o falsa iremos por caminos distintos. Principio y fin: Dentro del smbolo 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 aclaracin para entender mejor el cdigo, pero no es parte del cdigo, no se ejecuta. Otros smbolos: - Pantalla: Cuando una salida es por pantalla. - Teclado: Para representar una entrada por teclado. - Impresora: - Entrada/Salida por disco

Anni Abreu