ciclo de vida para desarrollar un programa de computadoras “program development live cicle”...

43

Upload: romeprofe

Post on 19-Jul-2015

496 views

Category:

Education


0 download

TRANSCRIPT

“Si no sabe qué necesita hacer, mucho menos sabrá

cómo hacerlo”…

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

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.

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)

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.

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.

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.

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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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”.

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.

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.

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”.

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.

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.

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.

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.

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.

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.

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

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

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.

4. Implementar el Diseño

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.

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.

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).

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 .

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.

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.

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.

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.

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