Ciclo de vida para desarrollar un programa de computadoras “program development live cicle” (pdlc)

2. “Si no sabe qué necesita
hacer, mucho menos sabrá
cómo hacerlo”…

3. Desarrollo de un programa de computadoras
El desarrollo de un
programa de computadoras
(program development)
consiste en una serie de
pasos que los
programadores debemos
utilizar para poder
desarrollar o construir
programas de
computadoras.
Primer paso
Segundo paso
Tercer paso

4. Ciclo de vida para desarrollar un programa de
computadoras “Program Development Live
Cicle” (PDLC)
El “Program Development Live Cicle”
(PDLC), quía al programador a través
de las etapas que conlleva el
desarrollo de un programa de
computadoras. El mismo consiste en
siete pasos fundamentales.

5. 1. Analizar
Requerimientos
2. Diseñar
Solución
3.Validar el
Diseño
4. Implementar
el Diseño
5. Probar la
Solución
6. Documentar
Solución
7.
Mantenimiento
Ciclo de vida para
desarrollar un
programa de
computadoras
“Program
Development Live
Cicle” (PDLC)

6. 1. El análisis de requerimientos se
resume entres (3) pasos:
1. Repasar el problema y establecer requerimientos.
 Estudiar y analizar informes, pedidos, reportes, gráficas,
tablas o cualquier documento que evidencie las actividades
generales y especificas del cliente.
2. Reunirse con el analista de sistemas y usuarios.
 Tener la perspectiva del analista del sistema como la de los
usuarios finales ayuda, al programador a tener mejor
entendimiento del propósito del programa, lo cuál lo lleva a
construir un certero diseño de las especificaciones.
3. Identificar las posibles: Entradas, Procesos y Salidas (INPUT /
PROCESS/ OUTPUT) y otros componentes relacionados a la
data que realizará el programa. Trabajar con una Tabla IPO.

7. Ejemplo de una Tabla o Gráfica IPO
(IPO Chart)
Input Processing Output
Horas Trabajadas
Regulares
Leer y registrar las horas
trabajadas por los
trabajadores o
empleados, calcular el
pago de acuerdo al
salario por hora.
Pago Neto (después de
las deducciones).
Horas Trabajadas en
exceso a 40 (overtime
hours)
Si el empleado trabajó
tiempo extra, calcular el
pago por horas extras.
Pago Salario por Hora Calcular e imprimir el
sueldo bruto.

8. 2. Diseñar la solución
El segundo paso es diseñar la solución que cumplirá con
los requisitos de los usuarios y resolverá el problema en
general. Para construir el diseño de la solución, el
programador desarrollará y creará un algoritmo que
establezca los pasos a seguir para la solución del
problema.
Algoritmo = serie de pasos o procedimientos (gráficos o escritos) que se
establecen para la solución de un problema.
Determinar el comportamiento lógico de un programa
es mayormente el principal reto de los programadores.

9. A continuación veremos algunos
de los principales modelos
utilizados por lo programadores
para desarrollar el diseño de
soluciones.
2. Diseñar la solución

10. Diseño Estructurado (Structured Design)
El diseño estructurado le permite al programador comenzar con
un diseño general y luego moverse a un diseño más detallado
(moverse de lo general a lo especifico). Primero se identifica el
funcionalidad o rutina principal del programa (main module).
Luego el programador descompone o rompe dicha rutina principal
en pequeñas secciones conocidas como sub-rutinas o módulos.
Se analiza cada sub-rutina o módulo para determinar si puede ser
descompuesta en otra sub-rutina o módulo más pequeño. Para
hacer este tipo de diseño el programador utiliza una Gráfica
Jerárquica (Hierarchy Chart).
Una gráfica jerárquica contiene rectángulos y líneas donde cada rectángulo representa
un módulo y las líneas su conexión jerárquica.

11. Gráfica Jerárquica (Hierarchy Chart)
Imagen tomada de: Página 688, Discovering Computers 2012: Chapter 13, Figure 13‐25.
A pesar de su simpleza para diseñar soluciones, muchos programadores coinciden en
que es un sistema de diseño poco eficiente por que es propenso a la duplicidad de
procedimientos y códigos.

12. Diseño Orientado a Objetos (Object-Oriented Design)
Los objetos son elementos que puede contener datos y procedimientos que
leen y manipulan la data. Un objeto es como una caja donde no se puede ver
el contenido de su interior desde afuera.
A diferencia de el Diseño
Estructurado, con el Diseño
Orientado a Objetos el
programador puede
empaquetar data y
procedimiento en una unidad u
objeto y cuando la estructura
de un objeto cambia, cualquier
programa que accede al objeto
automáticamente accede al
cambio también.
Imagen tomada de: Página 635 Discovering Computers
2012: Chapter 12, Figure 12‐14

13. Diseño Orientado a Objetos (Object-Oriented Design)
El concepto de empaquetado (packaging) data y procedimiento es también conocido
como encapsulación.
 Un diagrama de clases
muestra gráficamente
clases y subclases en un
sistema.
 Cada clase puede tener
una o más subclases.
 Las subclases utilizan
herencia para heredar
métodos y atributos de
niveles más altos. Imagen tomada de: Página 635 Discovering Computers
2012: Chapter 12, Figure 12‐14
Un atributo describe las características de un objeto.

14. 2. Diseñar solución (Estructuras de Control)
Independientemente el programador utilice
para diseñar su solución el método de Diseño
Estructurado o Diseño Orientado a Objetos,
necesita trabajar con una estructura de control
para describir las tareas que el programa tiene
que desempeñar.
Una estructura de control presenta el orden
lógico de las instrucciones o procedimientos
de un programa.

15. Las tres (3) estructuras básicas de control
utilizadas en programación son:
Estructura de Control Secuencial
Estructura de Control de Selección
Estructura de Control de repetición

16. Estructura de Control Secuencial
La estructura de control secuencial
muestra las acciones que seguirá
un programa de manera lineal,
(una o más acciones seguida de la
acción anterior). Las acciones
pueden ser “input”, “processes”
and “outputs”.
Todas las acciones deben ser
ejecutadas y ninguna puede obviarse.
Imagen tomada de: Página 689 Discovering Computers 2012: Chapter 13, Figure 13‐27.

17. Estructura de Control de Selección
La estructura de control de
selección le indica al
programa que acción tomar
dependiendo de la
condición que se presente.
Dos tipos comunes de
estructuras de selección son
el “if-then-else” y la de
“case”.
En algunas situaciones el programa
puede ejecutar una acción sólo si la
condición es cierta..
Imagen tomada de: Página, Discovering
Computers 2012: Chapter 13, Figure 13‐28.

18. Control de Selección “if-then-else”
La estructura de control “if-then-else” dirige al programa a través del curso de
acción que debe seguir, basado en la evaluación de la condición.

19. Control de Selección “case control”
Con la estructura de
selección “case control”
una condición puede
producir una de tres o
más posibilidades. La
acción a tomar por el
programa va a depender
de la condición
seleccionada.
La estructura de selección “case control” permite más de dos
alternativas después de evaluar la condición.

20. Control de Selección “repetition”
La estructura de control de repetición
permite al programa desempeñar una o más
acciones repetitivamente hasta que cierta
condición se cumpla o no se cumpla. Muchos
programadores le llaman a esta estructura de
control “loop”.
Dos maneras de trabajar con este tipo de
estructura de control de repetición son:
“Do-while” and “Do-until”.

21. Control de selección de repetición “Do-while”
La estructura de control de
repetición “do-while” repite un
procedimiento una o más veces
hasta que cierta condición sea
cierta (que se cumpla). Este tipo
de estructura de control prueba
o valida una condición al
principio del “loop”, a este
proceso se le conoce como
“pretest”.
Con “Do-while” si el resultado de la condición es cierto, el programa ejecuta la acción o
acciones contenidas en el “loop” continuamente, hasta que la condición sea falsa.
Imagen tomada de: Página 690 Discovering Computers 2012: Chapter 13, Figure 13‐30.

22. Control de selección de repetición “Do-until”
La estructura de control de repetición
“do-until” es similar a la de “do-while”
pero tiene dos marcadas diferencias:
Cuando la condición es evaluada o
probada y cuando se detiene el proceso
del “loop”. Primero que nada el “do-
until” espera hasta que se detenga el
“loop” para validar y probar la
condición (posttest). Continua
repetitivamente hasta que cierta
condición se cumpla.
Con “do-until” a diferencia de “do-while”, la acción siempre se ejecuta por lo menos
una vez, hasta que el resultado de la condición sea cierto y luego se detiene
Imagen tomada de: Página 690 Discovering Computers 2012: Chapter 13, Figure 13‐31.

23. Herramientas para el diseño de
soluciones algorítmicas lógicas
de programas
Para ayudar a los programadores a desarrollar
soluciones algorítmicas para resolver problemas
computacionales, se utilizan herramientas de
diseño. Las dos principales herramientas de
diseño de programas computacionales son:
diagramas de flujo de programación “program
flowchart” y pseudocódigos “pseudocode”.

24. Diseño de “software” programas:
Diagramas de flujo de programación “program
flowchart”
Un diagrama de flujo o
“flowchart” es una
representación gráfica
que muestra el
algoritmo lógico que
solucionará el problema
computacional (el
comportamiento lógico
del programa a
desarrollar).
El “Flowchart” fue desarrollado en los 1960 por la
“American National Standards Institute” (ANSI) con el
propósito de estandarizar el diseño de software y no
ha perdido vigencia su utilidad.
Imagen tomada de: Página 691 Discovering Computers 2012: Chapter 13, Figure 13‐33.

25. Diseño de “software” programas:
Diagramas de flujo de programación “program
flowchart”
Aun que en la actualidad existe una gran variedad de aplicaciones para diseñar diagramas de flujo
para programación, el “flowchart template” sigue siendo utilizado. Recordemos que podemos
diseñar programas con lápiz y papel.

26. Símbolos ANSI del diagrama de flujo “flowchart”
Process (proceso) – Se utiliza para especificar instrucciones de
programación que generarán cambios en el programa.
Input / Output (entrada y/o slida) - Se utiliza para especificar
entradas o salidas en el programa. (hay que identificar siempre su uso)
Decision (condición) (IF) – Se utiliza para especificar una
condición que determinará el flujo a seguir de acuerdo a si se
cumple o no la misma.
Terminal (límites) – Se utilizan para establecer el inició o el fin de
un procedimiento computacional. (hay que identificar siempre su uso)
Conector - Se utiliza para conectar un módulo o parte de uno con
otra sección del modulo en el flowchart , pero en la misma página.
Conector - Se utiliza para conectar un módulo o parte de uno
con otra sección del modulo en otra página de flowchart.

27. Símbolos ANSI del diagrama de flujo “flowchart”
Display (monitor) – Se utiliza para especificar que el “output”
(salida) sólo será a través del monito.
Manual Operation (proceso manual) – Se utiliza para
especificar que el proceso será llevado a cabo manual o
mecánicamente.
Print Document – Se utiliza para especificar que el “output”
(salida) sólo será a través de la impresora.
Flechas de Flujo – Se utilizan para establecer e ilustrar la
secuencia general de flujo.
Anotation (Documentación) – Se utiliza para crear anotaciones
y comentarios adicionales y especificar secuencias.
Predefined Process (proceso pre-definido) – Se utiliza para
especificar procesos o rutinas de proceso previamente
especificadas.

28. Diseño de “software” programas: “Pseudocode:
El pseudocódigo utiliza una
condensada forma del idioma
ingles para transmitir la lógica
del programa. Algunos
programadores prefieren
explicar la solución lógica de un
programa utilizando un
algoritmo de palabras y
oraciones (pseudocódigo), en
vez de la técnica de
representación gráfica con el
“flowchart”. El pseudocódigo utiliza la técnica de la
indentación. Por ejemplo, como se muestra en la
figura de arriba, el comienzo y el fin del
procedimiento computacional, estan pegados al
margen izquierdo del documento.
Imagen tomada de: Página 692, Discovering
Computers 2012: Chapter 13, Figure 13‐35.

29. 3. Validar el Diseño
Una vez el programador a desarrollado y
diseñado el algoritmo con la solución lógica del
problema, tiene que validarlo y asegurarse que
la solución que propuso es adecuada y resuelve
el problema.

30. Validar el Diseño
Recuerde que un error de lógica es un defecto en el
diseño que causa un resultado inexacto o incorrecto.
Validar el diseño es el
proceso de identificar y
corregir errores de lógica en
la solución algorítmica
propuesta. Se utilizan dos
técnicas para validar diseño:
 “Desck check”
 Inspección

31. Técnica de validar el diseño “Desk check”
El “desk check” es la técnica para validar el diseño y comprobar
si hay errores lógicos utilizando datos de prueba “test data”. El
programador que diseño el algoritmo de solución, por lo general
es el que valida el diseño con el “desk check”.
Crear varios conjuntos de datos de prueba
Determinar el resultado esperado
Pasar los datos a través del algoritmo
Comparar los resultados con el resultado esperado
Repetir los pasos para cada conjunto de datos de
prueba

32. 4. Implementar el Diseño
La implementación del diseño incluye el uso de una
herramienta de desarrollo de programa (un lenguaje de
programación) que le permita al programador:
 Generar o proporcionar la
manera de codificar.
 Escribir el código que
traduce el diseño en un
programa de computadoras.
 Crear la interfaz de usuario
Codificar es el proceso de traducir el algoritmo de la solución, utilizando un lenguaje de
programación. A veces se codifica hasta en una hoja de papel, para luego entrarlo en
la computadora.

33. 4. Implementar el Diseño

34. 4. Implementar el Diseño
En esta etapa se hace revisión del código
contantemente para detectar los errores que
van surgiendo al codificar y se reparan. Se inicia
la depuración del código.
Los programadores aprovechan los errores o “bug” que van detectando y corrigiendo
para hacer documentación de los mismos en el código.

35. 5. Probar la Solución
Una vez esta implementado el programa
(proceso de escribir el código mediante un
lenguaje de programación), hay que probarlo.
El objetivo de probar (correr
la aplicación) el programa es
asegurarse que el programa
se ejecuta correctamente y
está libre de errores.

36. Probar la Solución (Depurar el código)
La depuración del programa consiste
en quitar los errores. Utilizando
datos de prueba “test data” el
programador puede detectar
errores de sintaxis y errores de
lógica mediante la técnica conocida
como “Run time error” (entrar data
de prueba para forzar errores).

37. Depurar el código “debugging”
Durante esta etapa el programador coteja y corrige los errores y fallas que no
contempló en el diseño (depurar el código). La implementación se relaciona
con la instalación del software o programa y con permitir que los usuarios lo
prueben.
Recordemos que depurar es el
proceso de identificar y corregir
errores de programación. Los
principales errores son de lógica o de
sintaxis.
 Error de lógica es un defecto en el
diseño que causa un resultado
inexacto o incorrecto.
 Error de sintaxis es una falla o
violación gramatical en la(s)
línea(s) de código o instrucción .

38. Probar la Solución ( Versiones Beta)
Una versión beta es un programa que tiene la mayoría o la
totalidad de las características y funcionalidades de un
programa ya implementadas y que se libera a los usuarios,
para que lo utilicen y detecten e informen errores.

39. 6. Documentar Solución
La documentación de un programa incluye todas las
gráficas, tablas, soluciones algorítmicas, pruebas,
resultados de datos de pruebas y el código del
programa que a su vez debe estar bien documentado
con comentarios específicos y generales relacionados
al código.

40. 6. Documentar Solución
En la documentación de la solución, el programador
realiza dos actividades:
1. Revisar el código del programa para detectar cualquier
tipo de código muerto (se escribió, pero no se usó) y
eliminarlo.
2. Revisar toda la documentación antes de entregar el
programa.
 Si el programa requiere mejoras o hacerle cambios en el
futuro, es sumamente importante la documentación.
 Esta práctica reduce la cantidad de tiempo que otro
programador gastaría en entender el código del programa.
Nota: siempre que se elimina código muerto, hay que probar (correr el programa) nuevamente.

41. 7. Mantenimiento
El mantenimiento comienza tan pronto se haya
instalado el programa. Las razones pueden ser varias:
Parchos
Corregir errores
menores
(vulnerabilidades) que
no se hayan reparado en
el momento en que el
programa fue
terminado.
Actualizaciones
Añadir funciones nuevas
importantes en
respuesta a las
demandas del mercado
o a las solicitudes de los
usuarios.

43. Bibliografía
• Shelly, G.B. & Vermaat, M.E. (2012). Discovering Computers
Your Interactive Guide to the Digital World. Course
Technology Cengage Learning, Boston, MA. USA. (ISBN-13:
978-1-1115-3032-7)
• Norton, P. (2006). Peter Norton Introduction to Computers.
Mc Graw Hill. (ISBN-10: 970-10-5108-4)
• http://es.wikipedia.org/wiki/Programaci%C3%B3n
• http://puracompu.com/?p=144