Asignatura: Programación II
Curso: 5° Informática
ACERCA DE LAS FASES DEL PROCESO DE PROGRAMACIÓN
Actividades:
1) ¿Cuál es el fin del proceso de programación y cuál es la estructura que debe tener?
2)¿Cuáles son las fases que componen el proceso de programación?
3) Explica las cinco fases del proceso de programación?
| Resumen:
El artículo intenta establecer las fases básicas que componen el proceso de programación. La formulación de estas fases se define desde la experiencia de DocIRS y no como una metodología absoluta. A este fin, primeramente se esboza una definición de un programador actual. Posteriormente se describen y analizan las principales características de 5 fases: Análisis del problema; Desarrollo de la solución; Construcción de la solución en forma de programa; Prueba o Testing, Mantenimiento
|
LAS FASES DEL PROCESO DE PROGRAMACIÓN
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:
|
|
|
|
|
|
|
|
|
|
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. (Ver Fundamentos Teóricos de los Lenguajes Estructurados)
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.
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. (Ver La Estrategia de Diseño Simple)
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. (Ver Nomenclatura para la Programación y Acerca del Estilo en Programació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 proyecto 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
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.