P. 1
Estándares de Calidad en el Diseño de Algoritmos y Construcción de Programas

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

|Views: 1.172|Likes:
espero que lo aprovechen
espero que lo aprovechen

More info:

Categories:Types, Research, Science
Published by: Anni Aracelis Abreu Romero on Jun 11, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

03/21/2013

pdf

text

original

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éri co 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 algor itmos 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 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 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 comp onente 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, 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 operación en los que se introducen y generan datos erróneos. Simplicidad. Promueve la utilización de es tructuras 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. etapa. 2. Realización de Revisiones Técnicas Formales durante cada

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. 7. Desarrollo y ajustes de modelos estadísticos de calidad y productividad. 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ísti cas 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íne as, 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 ± documentación significativa. ‡ ‡ Que el archivo ejecutable entregue

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 Leemos b 4 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. 2. 3. al principio de cada clase al principio de cada método ante cada variable de clase

Por conveniencia (una línea): 4. 5. al principio de fragmento de código no evidente a lo largo de los bucles

Y por si acaso (una línea): 6. 7. siempre que hagamos algo raro 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 he rramienta, 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 docum ento 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 p oder 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 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 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 resolver lo. 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 determinad o 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

Anni Abreu

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->