Instituto Mixteco De La Educación Integral

Introducción a la programación

“Realizar un análisis sobre las consideraciones del desarrollo

de un programa considerando
1. Análisis del problema
2. Seudocódigo
3. Programación”

Prof. Antonio Cervantes Hernández

Alumno: Fidel Hernández Méndez

A fin de poder asegurar que un sistema cumpla con la solución requerida por el cliente, no basta
simplemente con un levantamiento y diseño funcional, especificación de los casos de uso y
descripción de procesos. Es imprescindible la comunicación y registro de evidencias con el
Equipo de Desarrollo. Es decir, con la participación del programador.

Para DocIRS, un programador debe participar del análisis de los problemas delineados por el
ingeniero de procesos en términos de los requerimientos detallados. Desde ahí va diseñando la
estrategia a seguir en la estructura del programa, con las siguientes actividades:

 Codifica las instrucciones implementando algoritmos en el lenguaje de programación

adecuado.

 Verifica la lógica del programa preparando rutinas de prueba.

 Revisa, depura y corrige los programas.

 Evalúa y modifica los programas existentes para producir cambios requeridos por la
evolución del negocio.

 Finalmente prepara el documento base de la ayuda de usuarios.

Los lenguajes de programación utilizan formalización matemática, tanto en su estructura

como en su simbología. Sus convenciones y usos se realizan especialmente utilizando leyes
algebraicas, tales como la Lógica de Boole, particularmente Algebra de Proposiciones, Teoría
de Conjuntos, Funciones (algebra y sus propiedades), Series Numéricas, Recursividad, etc. y
por tanto un programador trabaja fundamentado en conceptos matemáticos. Cualquier
consideración del proceso de programación mismo debe comenzar aislando cada una de sus
fases componentes (Ver el Lenguaje de Modelado Unificado UML). Se identifica las siguientes
cinco fases:

1. Análisis del problema

2. Desarrollo de la solución
3. Construcción de la solución en forma de programa
4. Prueba
5. Mantenimiento
El análisis del problema se refiere a la etapa del proceso en la que el programador toma
conocimiento del problema antes de proceder a desarrollar una solución. Es un proceso de
“introducción”, de naturaleza cognoscitiva y muy difícil de describir.

Son demasiados los programadores que recorren esta etapa muy rápidamente, lo que hace
que entiendan mal o malinterpreten las especificaciones.

Algunos programadores prefieren devolver las especificaciones del problema al diseñador,

para reducir la posibilidad de malentendido. Los errores que se cometen en esta etapa son
con mucha frecuencia difíciles de detectar y consumen mucho tiempo cuando se les trata de
remediar en las etapas posteriores.

La segunda etapa, el desarrollo de la solución, es eminentemente creativa.

Aquí se debe hacer hincapié en la formulación del algoritmo antes que en su codificación
en un lenguaje de programación en particular. Aunque algunos podrían argumentar que la
habilidad para resolver problemas es algo innato y que es difícil educar o mejorar la
creatividad, existe suficiente evidencia en el sentido de que algunos enfoques sistemáticos
tienen mucho valor.

También es una alternativa recurrir a desarrollos anteriores hechos para otras soluciones (la
librería propia) y desde allí comenzar el proceso de creación.

Siempre y cuando el problema central haya sido resuelto realmente, puesto que si no es así
esta situación acarreará problemas en las fases posteriores.

Otro punto de suma importancia en esta etapa, es el definir la arquitectura del modelo de
datos, las relaciones lógicas básicas y las pautas a seguir en las transacciones con la base(s)
de datos que tendrá la aplicación. (Asumimos que, en esta etapa, ya debe estar delineado el
conjunto de clases de funciones que tendrá el sistema, y que posteriormente se
transformarán en las entidades u objetos).

La tercera etapa identificada es la construcción de la solución, desarrollada en forma de un

programa real (o código). Considerando que la solución ha sido bien definida, este proceso
es casi directo, pues es un proceso mental inmediato de las fases anteriores. Mediante
rutinas, funciones, scripts, procedimientos y reglas del lenguaje de programación, se va
ensamblando la aplicación de acuerdo con los estándares de estilo y de estructura. Una
buena práctica con respecto la legibilidad del programa es muy importante, recuerde que,
si el programa es fácil de leer, mejor será su revisión. Recomendamos tener presente que
todo programa requiere de un Insumo, de un Proceso y de una Salida, por tanto, se debe
tener especial cuidado en la captura, validación y almacenamiento de datos. (GiGo: Garbage
in, Garbage out).
La cuarta fase se refiere a la revisión y corrección del programa sea en de Ambiente de
Desarrollo o Prueba. Es inevitable realizar pruebas mientras va construyendo las
componentes de la aplicación.

Todo programador experto prueba no sólo mentalmente cada instrucción cuando la está
escribiendo, sino que va ejecutando las rutinas de cualquier módulo o sección de su
programa antes de proceder a pasar a Ambiente de Prueba, donde probarán los que
establecieron el diseño funcional del sistema.

La prueba de las aplicaciones nunca es sencilla; Es natural que las pruebas muestran la
presencia de errores y nunca se puede demostrar la ausencia de ellos. Una prueba con éxito
sólo significa que no se detectaron errores bajo las circunstancias especiales de dicha
prueba; esto no significa nada frente a otras circunstancias. Aunque se sabe, que el
programador repite múltiples veces sus formas de prueba de lo que construye y siempre
dejará espacios que encontrará un tercero.

En teoría, la (única manera en que las pruebas pueden demostrar que un programa es
correcto es que se examinen todos los casos posibles, lo cual se conoce como una prueba
exhaustiva), situación que es imposible técnicamente, incluso para los programas más
simples.

¿Significa esto último que las pruebas son inútiles? Definitivamente, no.

El programador puede hacer mucho por reducir el número de casos a probar a partir del
número requerido por una prueba exhaustiva. Tomando con mucho cuidado y seleccionando
apropiadamente el diseño de los casos de prueba. De este modo puede reducirse el número
de fallas, haciendo posible una prueba razonable con un número relativamente pequeño de
casos.

La prueba de un programa es una tarea tan creativa como su mismo desarrollo, por lo que
debe considerarse con la misma diligencia y entusiasmo. Algunos principios de las pruebas
son claros:

Trátese de iniciar las pruebas de un programa con una mentalidad de saboteador, casi
disfrutando la tarea de buscar un error. Hay que sospechar de todo. Los casos de prueba
deberían diseñarse a partir de las especificaciones originales, en lugar del programa mismo
(o sea a partir del negocio) y sus casos de uso;

Si se efectúan a partir del programa, algunos aspectos del problema que han sido pasados
por alto durante su construcción también lo serán cuando se le pruebe. Para reducir las
posibilidades de que esto ocurra, se debe insistir en que sean personas diferentes a los
programadores originales quienes tengan a su cargo la prueba de los programas. Los usuarios
de los programas disponen, con frecuencia, de sus propios métodos de revisión para usarlos
cuando el programa esté a su disposición.
Téngase en cuenta que la contraparte del cliente evalúa muy mal al equipo de desarrollo o
proveedor cuyas aplicaciones no son capaces de pasar las pruebas de los usuarios. Por eso,
de cualquier forma, que se haga, una prueba completa antes de pasar a la revisión del
cliente es una parte esencial de los proyectos de programación. Los revisores externos,
cuando no tienen experiencia en revisión de programas, no tienen paciencia y se
transforman en críticos negativos, en vez de seguir un Plan de Pruebas y aceptar las fallas.

La quinta etapa del proceso de programación, el mantenimiento del programa. Sin

embargo, su importancia en el trabajo real nunca debe despreciarse.

En general, según nuestra experiencia el costo de mantenimiento de un programa de uso

generalizado es del orden del 40% o más del costo de su desarrollo.

Al contrario de lo que sucede con el mantenimiento de hardware, el mantenimiento de los

programas no se refiere a la reparación o cambio de partes deterioradas, sino a las
modificaciones y que deben hacerse a los defectos del diseño y evolución del mismo, lo cual
puede incluir el desarrollo de funciones adicionales para reunir nuevas necesidades del
negocio.

El tiempo de los desarrolladores para producir nuevos programas se ve siempre afectado por
el tiempo que deben dedicar al mantenimiento de los programas en producción.

El mantenimiento debe reconocerse como no evitable y, en consecuencia, deben realizarse

las acciones que sean necesarias para reducir el tiempo que ello implica.

Existe un tipo de problemas, - donde el programador está involucrado indirectamente-, y

que es necesario tener ciertas precauciones en la evolución y mantención de programas.
Especialmente en lo referente a los requerimientos asociados al levantamiento y diseño
funcional durante los mejoramientos de un sistema.
 En efecto, con los Clientes Dilema, quienes hacen pensar que es un pequeño cambio el que
están solicitando, pero que detrás de la petición existe una enorme cantidad de tareas
relacionadas al requerimiento. (Ver artículo testimonial Clientes Dilema

Otro punto muy importante a tener en cuenta y al menos mencionar, - a pesar que no es el
motivo central del presente artículo-, es el COB ( Continuity Of Business). Es decir, la
continuidad operacional que debe tener todo programa de computación (Ver Acerca de la
Continuidad Operacional DociRS con Elastic Load Balancing (ELB) Cloud Computing con
Amazon Web Services)