El documento presenta información sobre técnicas de programación como estilo y codificación, documentación, depuración y pruebas. Explica la importancia de documentar el software a través de manuales de usuario, mantenimiento y operador. También describe el proceso de depuración para eliminar errores y las diferentes pruebas como unitarias, de integración y validación para verificar que el software funciona correctamente.

1. Técnicas de
Programación
UNIDAD 1
ING. ALVARO ENRIQUE RUANO

2. Contenido
● Estilo y Codificación
● Documentación
o Manual de usuario
o Manual de mantenimiento
o Manual de operador
● Depuración
● Pruebas

3. Estilo y Codificación
Se busca que los programas sean legibles y modificables por los
creadores y por otras personas.
La calidad de un programa se relaciona directamente con su
escritura, legibilidad y comprensibilidad.
El objetivo de estandarizar el estilo de los programas es crear
eficiencia a través de una comunidad de desarrolladores
(trabajadores de una empresa, una comunidad de desarrollo
de software libre, estudiantes en un proyecto universitario,
etc.).

4. Estilo y Codificación
Las reglas de estilo para construir programas claros,
legibles y fácilmente modificables dependerá del tipo
de programación y lenguaje elegido.
No existe una fórmula mágica que garantice
programas legibles, pero existen diferentes reglas que
facilitarán la tarea y con las que la mayoría de
personas están de acuerdo.

5. Estilo y Codificación
Las características con que debe cumplir el código:
● Entendible: Debe ser fácil de leer, interpretar y
modificar. Debe incluir documentación apropiada
(documentación interna).
● Correcto: Debe de compilar sin problemas y
ejecutarse tal como está documentado.

6. Estilo y Codificación
● Consistente: El estilo de codificación debe de ser
consistente a través de todo el programa, proyecto o
institución (según alcance definido).
● Moderno: Se deben utilizar las recomendaciones
publicadas más recientemente para los componentes que
utilicemos.
● Seguro: Se debe evitar el uso de “hacks” o malas prácticas
de programación. En ningún momento se debe
comprometer la estabilidad de los equipos donde se
ejecute el programa.

7. Estilo y Codificación
● Reglas para lenguajes estructurados (Luis Joyanes Aguilar)
◦ Capítulo 18 del libro de su libro “Fundamentos de Programación”
● The Chromium Projects Coding Style (Google Chrome)
o http://www.chromium.org/developers/coding-style
● Mozilla Developer Network Coding Style (Firefox)
o https://developer.mozilla.org/en-
US/docs/Mozilla/Developer_guide/Coding_Style
● Apache OpenOffice Cpp Coding Standards (OpenOffice y LibreOffice)
o https://wiki.openoffice.org/wiki/Cpp_Coding_Standards

8. Documentación
Un programa de computadora necesita siempre de
una documentación que permita a sus usuarios
aprender a utilizarlo y mantenerlo.
La documentación es una parte importante de
cualquier paquete de software y su desarrollo es una
pieza clave en la “Ingeniería de Sofware”.

9. Documentación
Existen varios grupos de personas interesadas en conocer la
documentación de un sistema:
● Programadores: Personas que realizan las modificaciones al
programa.
● Operadores: Personas encargada de ejecutar el programa,
introducir datos y extraer resultados.
● Usuarios: Personas que explotan el programa y entienden
las entradas y salida que produce.

10. Documentación
En el contexto actual, los programas son interactivos, por lo que el rol de
usuario también incluye las tareas originalmente asociadas al rol de
operador.
Actualmente se denomina operador del programa a aquel usuario que
realiza acciones que requieren un conocimiento técnico y más especializado,
por ejemplo cierre bancarios, cierres contables o parametrizaciones
importantes.
La documentación que debe incluir un software es:
● Manual de usuario
● Manual de mantenimiento
● Manual de operador

11. Manual de usuario/operador
Es una documentación que presenta una inducción a las
funciones más utilizadas de un software.
El frecuente que se edite en forma de libro, aunque la
tendencia actual es que se presente en forma digital con el
nombre de “manual de ayuda en línea”.
Es un instrumento comercial importante, una buena
documentación hará que el programa sea más accesible para
las personas y atractivo para la compra.

12. Manual de usuario/operador
Este proceso puede ser realizado por los desarrolladores, aunque lo más
común es que las empresas contratan “escritores técnicos” para elaborar
esta parte del proceso de producción.
Las partes que incluye son:
● Instrucciones del proceso de instalación
● Instrucciones del proceso de acceso o carga del programa
● Referencia del detalle de todas las funciones del software
● Nombre de archivos externos a los que accede el programa
● Formato de los mensajes de error y explicaciones asociadas
● Descripción detallada de las salidas o informes que genera el programa

13. Manual de mantenimiento
El manual de mantenimiento (documentación del sistema) es por naturaleza
más técnica que el del usuario, ya que está dirigido a los programadores.
Abarca toda la documentación generada durante el ciclo de vida del
software, y su intención es que permite darle mantenimiento durante el
resto de la vida del programa.
Los documentos son considerados “Documentación Externa”.
Los comentarios incluidos en el código fuente se llaman “Documentación
Interna” y están estrechamente asociados con las normas de estilo
utilizadas.

14. Manual de mantenimiento
Dependiendo de la metodología y tecnología utilizada, así
variará el contenido del manual, aunque habitualmente
contiene:
● Especificaciones originales del sistema (ERS)
● Especificaciones con las que se verificó el programa
(Implementación)
● Diagramas de flujos de datos (Diseño Estructurado)
● Diagramas entidad-relación (Base de Datos)
● Diccionario de datos (Base de Datos)
● Diagramas de distribución y componentes del sistema
(POO)

15. Depuración
Según la conocida Ley de Murphy: si algo puede salir mal,
saldrá mal.
Un programa raramente funciona correctamente desde la
primera vez.
Un programa funciona correctamente solamente si produce
resultados correctos para “todas las entradas válidas
posibles”.
El proceso de eliminar errores (bugs) se llama depuración
(debugging).

16. Depuración
Existen tres tipos de errores:
● De compilación (syntax error)
o Son detectados por el compilador
o Son errores de sintaxis, instrucción mal escrita
o La computadora nos dice la causa del error para poder
corregirlo, dependiendo del compilador puede ser
fácil o difícil de interpretar
 C# -> Fácil interpretación
 C++ -> Difícil interpretación

17. Depuración
● De tiempo de ejecución (runtime error)
o Son detectados por el computador cuando el
programa está siendo ejecutado
o Dependen de los valores de entrada dados por el
usuario, así como del flujo de ejecución que tome el
programa
o Normalmente está asociado a advertencias (warnings)
en el tiempo de compilación

18. Depuración
● Lógicos
o El programa produce resultados erróneos
o Se permite compilar y ejecutar sin problemas
o Son los más difíciles de resolver
o Corresponden a un entendimiento inadecuado
el problema a resolver o a un diseño
incorrecto del programa

19. Depuración
Existen herramientas que pueden ser utilizadas para la
depuración de programas:
● Sentencias de escritura
o Dependiendo del lenguaje de programación se
pueden utilizar las instrucciones “Print” o
“MessageBox” para mostrar el flujo que está tomando
un programa.
o No es una herramienta desarrollada para este fin,
pero puede aprovecharse.

20. Depuración
● Puntos de ruptura (break-point)
o Permite detener el programa en un punto específico
para realizar un seguimiento a partir de este punto.
o Normalmente se permite un avance instrucción por
instrucción para ver el desenvolvimiento del programa.
o Es más recomendable que la técnica anterior.
o Visual Studio provee esta la funcionalidad (lo verémos
en laboratorio)

21. Depuración
● Examinar el contenido de variables (watches)
o Permite visualizar el contenido de las
variables
o Se utilizan en conjunto con break-points
o Muy útiles para evaluar las variables al inicio
o fin de la iteraciones y antes y después de
las llamadas a métodos o subprogramas.
o Esta funcionalidad también está incluida en
Visual Studio

22. Pruebas
● Comúnmente llamadas comprobación, pruebas o testing.
● Acciones que determinan si un programa funciona correctamente o no.
● Nos permiten verificar y validar la calidad del software que estamos
desarrollando.
o Verificación: Busca comprobar que el sistema implementa
correctamente una función específica. ¿Estamos construyendo el
producto correctamente?
o Validación: Busca comprobar que el sistema hace lo que tiene
que hacer. ¿Estamos construyendo el producto correcto?

23. Pruebas

24. Pruebas
● Probar un software conlleva todo un proceso.

25. Pruebas
● Datos de prueba:
o La ingeniería de software contempla la construcción
sistemática de un conjunto de pruebas.
o Para su correcta construcción se debe considerar:
 Conocer la salida de cada programa por cada dato
de entrada.
 Deben incluir aquellas entradas que
probablemente originarán más errores.

26. Pruebas de Verificación
● Pruebas Unitarias
o Su objetivo es ejecutar cada módulo (unidad mínima
de software) de la aplicación-
o Busca asegurar que el código funciona de acuerdo a
las especificaciones, validando módulos.
o Visual Studio provee formas de realizarlas.
● Pruebas de Integración:
o Identifica errores generados por la combinación de
módulos probados unitariamente.
o Puede utilizarse la técnica top-down o bottom-up
o Prueba de interfaces.

27. Pruebas de Validación
● Determina la aceptación o rechazo del sistema desarrollado
● También llamadas pruebas de aceptación, entre las cuales
encontramos:
● Pruebas Alfa
o El usuario prueba en presencia del desarrollador.
o El desarrollador recopila los resultados de las pruebas.
● Pruebas Beta
o El usuario prueba en su estación de trabajo.
o El desarrollador no está presente.
o El usuario recopila resultados y los envía.

28. Pruebas de Sistema
● Determinan si el software se integrará al sistema
dónde operará o en un ambiente similar.
● Entre los tipos de pruebas de sistema
encontramos:
o Recuperación
o Carga
o Seguridad

29. Pruebas

30. Gracias por su atención