Técnicas de
Programación
UNIDAD 1
ING. ALVARO ENRIQUE RUANO
Contenido
● Estilo y Codificación
● Documentación
o Manual de usuario
o Manual de mantenimiento
o Manual de operador
● Depuración
● Pruebas
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.).
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.
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.
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.
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
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”.
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.
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
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.
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
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.
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)
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).
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
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
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
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.
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)
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
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?
Pruebas
Pruebas
● Probar un software conlleva todo un proceso.
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.
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.
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.
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
Pruebas
Gracias por su atención

Técnicas de programación

  • 1.
  • 2.
    Contenido ● Estilo yCodificación ● Documentación o Manual de usuario o Manual de mantenimiento o Manual de operador ● Depuración ● Pruebas
  • 3.
    Estilo y Codificación Sebusca 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 Lasreglas 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 Lascaracterí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 decomputadora 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 gruposde 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 contextoactual, 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 Esuna 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 Esteproceso 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 Elmanual 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 Dependiendode 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 conocidaLey 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 tiposde 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 tiempode 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 Elprograma 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 quepueden 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 deruptura (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 elcontenido 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 llamadascomprobació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.
  • 24.
    Pruebas ● Probar unsoftware conlleva todo un proceso.
  • 25.
    Pruebas ● Datos deprueba: 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.
  • 30.
    Gracias por suatención