REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DE EDUCACION SUPERIOR

ALDEA CIUDAD ANGOSTURA
INGENIERIA EN SISTEMAS E INFORMATICA
FIN DE SEMANA

INTRODUCCION A LA
PROGRAMACION

Facilitador: Bachiller C.I

INGRIS MANAURE Jesús Sánchez 15.125.287

Trayecto I Semestre I

Ciudad Bolívar, mayo de 2011

 Introducción

El desarrollo de algoritmos es un tema fundamental en el diseño de

programas por lo cual el alumno debe tener buenas bases que le sirvan para
poder desarrollar de manera fácil y rápida sus programas. A las soluciones
creadas por computadora se les conoce como programas y no son más que
una serie de operaciones que realiza la computadora para llegar a un
resultado, con un grupo de datos específicos. El diseño de soluciones a la
medida de nuestros problemas, requiere como en otras disciplinas una
metodología que nos enseñe de manera gradual, la forma de llegar a estas
soluciones.
 Estándares de calidad en el diseño de algoritmos y construcción de
programación

El uso eficiente y eficaz de la tecnología de los computadores es un objetivo

que aún está distante. Para representar lo anterior, sólo basta señalar los
reportes de fracasos y dificultades de muchos proyectos en los que se pretende
involucrar a la tecnología de los computadores.

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.

Robert Dunn presenta la calidad en el software tomando dos puntos de vista: la

calidad en el proceso de desarrollo y la calidad en el producto final, estos dos
grupos principales los agrupa en los siguiente aspectos de calidad:
confiabilidad, utilizabilidad, mantenibilidad, y adaptabilidad.
Roger Pressman describe similares factores de calidad agrupados en tres
grupos: calidad en operación, calidad en revisión y calidad en transición.
A continuación se presentan los factores de calidad de acuerdo al orden dado
por Dunn.
Confiabilidad. Este término es necesario sea separado en varios elementos que
permiten darle al software el matiz de fiable. Sus componentes 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.
Usabilidad. Si bien es cierto que la confiabilidad es un factor muy importante en
la calidad del software también lo es el hecho de que es necesario considerar
otros factores como los que se mencionan en esta sección puesto que de nada
sirve un software que funcione correcta y confiablemente si el usuario prefiere
no utilizarlo.
• Exactitud de los procesos
• Claridad y exactitud de la documentación
• Completitud
• Eficiencia y verificabilidad del software
• Claridad y amigabilidad de la interfaz
Mantenibilidad. Este aspecto de calidad involucra los elementos que simplifican
la labor de prevención, corrección o ampliación del código del programa.
Retomar un código escrito meses antes es un trabajo dispendioso y agobiante,
en especial cuando las aplicaciones no cuentan con la característica a la cual
aquí se hace referencia. Se pueden considerar como atributos de este aspecto:

• Exactitud y claridad en la documentación

• Modularidad acoplamiento
• Facilidad de lectura
• Simplicidad
Portabilidad. Es la capacidad que posee un sistema de información que le
permite funcionar en diferentes plataformas ya sean hardware o de software.
A continuación se describen cada uno de los aspectos de calidad
mencionados:

Calidad en los procesos de desarrollo. Se resume en la frase "bien planeado y

cuidadosamente ejecutado". Este aspecto asegura la confiabilidad, puesto que
el plan que se realice para desarrollar el sistema, debe incluir pruebas bien
seleccionadas que evalúen la confiabilidad del programa en cualquier situación.
Claridad y amigabilidad de la interfaz. De igual forma la interfaz debe ser clara
y agradable al usuario, las interfaces complejas son causa de la no utilización
de los sistemas de información.
Claridad y exactitud de la documentación. Hay que anotar que toda aplicación
requiere de una documentación suficientemente clara con el fin de que
cualquier persona con conocimientos básicos en computación pueda aprender
la forma de operación sin que requiera la asesoría de los desarrolladores o
conocedores de la herramienta, a menos que se trate de eventualidades donde
realmente sea necesario consultar al proveedor.
Completitud o adecuación. Se refiere a que los resultados de operaciones sean
acordes al comportamiento del mundo real desde todos los estados y
condiciones permitidos por la aplicación, es decir, el programa debe reflejar la
realidad. Un programa es inconsistente si presenta respuestas erróneas en
algunos casos. Una mala especificación de rangos en un dominio sobre los
cuales realizan diferentes operaciones matemáticas puede llevar a que algunos
cálculos se realicen dentro de límites inapropiados, obteniéndose resultados
erróneos. Otro caso de inconsistencia se presenta cuando ocurren eventos que
paran abruptamente la ejecución del programa, sólo un sistema de calidad
podrá conservar datos consistentes después de una falla.
Eficiencia y verificabilidad del software. Otro aspecto que no debe pasar por
alto es el de la verificabilidad, puesto que es imprescindible contar con los
requerimientos, y sobre todo en aquellos sistemas donde se obtengan
resultados que no sean visibles.

Exactitud de los procesos. Un programa no será utilizado por un usuario si sus

resultados no son exactos. Tampoco se puede garantizar el uso de un
programa que no presta las utilidades que el usuario requiere, es decir, que sea
incompleto. Además, un programa ineficiente que no cumpla con los
requerimientos de tiempo, memoria o flexibilidad no podrá satisfacer las
expectativas de quienes lo utilizan.

Robustez o solidez. Se refiere a la capacidad del software de defenderse de las

acciones anormales que llevan al sistema a un estado no deseado o por lo
menos no previsto, causando un comportamiento inesperado, indeseado y
posiblemente erróneo. El software de hoy, debe estar en capacidad de analizar
los datos que recibe para hacer cumplir requerimientos o condiciones del
software y enfrentar de la mejor manera los errores cometidos por un usuario al
utilizar la aplicación. Es importante resaltar, que la solidez no siempre es
generada por la digitación inapropiada del usuario, sino también por un mal
procesamiento o un mal encadenamiento de procesos. El resultado de un
proceso, aunque sea correcto, puede estar fuera de los límites permitidos en
los parámetros del módulo que lo recibe y si este módulo no controla los
parámetros que le entran caerá en un estado inesperado.

Seguridad y adaptabilidad. 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.

• Calidad de software. Se define la calidad de software como la ausencia

de errores de funcionamiento, la adecuación a las necesidades del usuario, y el
alcance de un desempeño apropiado (tiempo, volumen, espacio), además del
cumplimiento de los estándares. Los objetivos que la calidad persigue son: La
aceptación (utilización real por parte del usuario) y la Mantenibilidad
(posibilidad y facilidad de corrección, ajuste y modificación durante largo
tiempo). Para alcanzar estos objetivos, es necesaria una actitud y compromiso
de todo el personal que se encuentre en el desarrollo del proyecto, y en todas y
cada una de las etapas (en general, planeación, análisis, diseño, programación,
pruebas, mantenimiento) correspondientes al ciclo de vida que se hubiese
seleccionado para el proyecto. En forma adicional durante el proceso de
aplicación de las metodologías se requiere tener en cuenta:
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 bloques 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.

El análisis y diseño, como elementos esenciales del proceso de desarrollo,

obligan a tener especial atención y por tal motivo se han ido creando
metodologías que sirven de base para tomar las decisiones que afectarán el
producto final. Con el advenimiento de la disciplina de la ingeniería del software
se inicia el proceso de desarrollo de metodologías las primeras de ellas fueron
las estructuradas, y en forma posterior aparecen las metodologías orientadas a
objetos, siendo estas últimas las más difundidas actualmente en el medio.

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

La función principal que posee realizar la traza de un algoritmo es la de

comprobar que éste funciona correctamente o para realizar la etapa de
depuración en la que se intenta corregir errores, simplificar el algoritmo al
máximo e incrementar su eficacia y velocidad.
 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é.
Porque entre lo que tiene que hacer un programa y cómo lo hace hay una
distancia impresionante: todas las horas que el programador ha dedicado a
pergeñar una solución y escribirla en el lenguaje que corresponda para que el
ordenador la ejecute ciegamente.
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.
Javadoc realza algunos comentarios, de los que exige una sintaxis especial.
Deben comenzar por "/**" y terminar por "*/", incluyendo una descripción y
algunas etiquetas especiales:
/**
* Parte descriptiva.
* Que puede consistir de varias frases o párrafos.
*
* @etiqueta texto específico de la etiqueta
*/
Estos comentarios especiales deben aparecer justo antes de la declaración de
una clase, un campo o un método en el mismo código fuente. En las siguientes
secciones se detallan las etiquetas (tags) que javadoc sabe interpretar en cada
uno de los casos.
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.
Documentación de clases e interfaces
Deben usarse al menos las etiquetas:
• @author
• @versión
La tabla muestra todas las etiquetas posibles y su interpretación:
@author nombre del autor
@versión identificación de la versión y fecha
@see referencia a otras clases y métodos
Documentación de constructores y métodos
Deben usarse al menos las etiquetas:
• @param
Una por argumento de entrada
• @return
Si el método no es void
• @Excepción ó @throws
una por tipo de Exception que se puede lanzar
(@exception y @throws se pueden usar indistintamente).
La tabla muestra todas las etiquetas posibles y su interpretación:
@param nombre del parámetro descripción de su significado y uso
@return descripción de lo que se devuelve
@exception nombre de la excepción excepciones que pueden lanzarse
@throws nombre de la excepción excepciones que pueden lanzarse
@exception y @throws se pueden usar indistintamente.
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 las 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 cómo 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.

Formas de trazalizar un 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
identificación (aumenta la legibilidad del problema para que se pueda leer
mejor.
 Conclusión

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.