PAGINA DE BASE DE DATOS Y ARCHIVOS:
http://ict.udlap.mx/people/carlos/is341/bases01.html
lunes, 24 de agosto de 2009
1. Introducción
1.1 Aplicación de bases de datos
1.1.1 Antecedentes
La información ha llegado a ser el eje que mueve a la mayoría de las organizaciones hoy día
La cantidad de información que se maneja actualmente es en extremo enorme.
Se tiene la necesidad de tenerla perfectamente organizada de manera que pueda ser accesada fácilmente y por otro lado se debe tener disponible todo el tiempo (sistemas 24x7)
La solución: las personas de computación han desarrollado conceptos, técnicas y sistemas bajo un tópico conocido como "bases de datos" (databases)
1.1.2 Definición
Surgen entonces los primeros conceptos:
Dato: es la representación física de un aspecto de la realidad
Base de datos: conjunto de datos, que pueden estar organizados y/o interrelacionados de alguna manera con un propósito particular
DBMS*: Sistema Manejador de Bases de Datos (DataBase Manager/Management System) es una colección e datos interrelacionados y un conjunto de programas para accesarlos. En otras palabras un sistema para crear, manipular y aprovechar bases de datos.*Algunos lo llaman SGBD (Sistema Gestionador de Bases de Datos)
1.1.3 Escenarios de bases de datos
Podemos afirmar que las bases de datos están en todas partes, cualquier problema que podamos pensar podemos asociar una base de datos
Bancos: cuentas, transacciones, fondos de ahorro, SAR
Aerolíneas: reservaciones, pasajes, suministros, personal de vuelos
Escuelas: cursos, calificaciones, horarios
Negocios: compras, proveedores, ventas, clientes, devoluciones
Fábricas: flujo de procesos, almacenes, envíos
Recursos Humanos: empleados, puestos, salarios, impuestos, prestaciones
Curiosamente el uso de las bases de datos puede llegar a ser tan transparente que para algunos pareciera que no existen como en las transacciones de web o el cajero del banco (ATM).
1.2 Sistemas de bases de datos vs sistemas de archivos(Databases vs File Systems)
El camino hacia las bases de datos ha sido largo y en el trayecto se han desarrollado un gran número de técnicas que forman los cimientos de las bd y de otras tecnologías.
Dentro de estas técnicas tenemos:
Archivos, Sistemas de Archivos, Acceso y manipulación de archivos, Indices
Pero...
por qué no es suficiente utilizar las herramientas anteriores y es necesario emplear un DBMS ?no es lo mismo ?cuál es la diferencia ?
No es lo mismo, un sistemas de archivos aún cuando pensemos que contiene lógicamente archivos y que se cuenta con índices para accesar los registros en ellos, carece de mucha funcionalidad que se emplea en la mayoría de las aplicaciones, aunque como se mencionó anteriormente, un DBMS emplea sistemas de archivos e índices para la manipulación de datos.
La funcionalidad adicional que provee un DBMS surge en base de algunos inconvenientes al emplear sistemas de archivos únicamente:
Redundancia de datos e inconsistencias (Redundancy and Inconsistency): formatos, duplicidad de información (alto costo de almacenamiento y acceso) e incongruencia entre datos o copias de datos a lo largo del sistema.
Dificultad de acceso (Access): en un sistema de archivos no se pueden obtener aquellos datos que no estén implantados en un programa, se carece de niveles de abstracción.
Aislamiento de datos (Isolation): debido al factor tiempo y los requerimientos que van surgiendo se puede llegar a tener un problema al intentar separar un conjunto de datos porque ya se tiene un enredo en los archivos y se podría dar el caso en que dos usuarios estén manipulando la misma información pero de distinta manera.
Integridad (Integrity): si queremos asociar dos datos, por ejemplo un alumno con una materia que esté cursando, debemos asegurarnos que ambas entidades existan, de lo contrario el alumno parecerá cursando un curso fantasma y viceversa. Para ello se emplean "restricciones de consistencia" (consistency constraints)
Atomicidad (Atomicity): el problema clásico de transacciones bancarias, u ocurre toda la transacción o no ocurre nada pero no puede quedarse a medias.
Acceso concurrente (Concurrent-access): garantizar un buen tiempo de respuesta, que todos los usuarios puedan accesar y/o modificar la información; esto no es fácil porque también hay que considerar que aunque los datos son los mismos, las aplicaciones no necesariamente lo son.
Seguridad (Security): no toda la información debe estar disponible a todos los usuarios, algunos usuarios solo tendrán permisos de lectura, esto es relativamente sencillo de resolver aplicando "roles" pero el problema aumenta cuando en luegar de pensar en terminos de usuarios pensamos en terminos de aplicaciones ya que el número de roles y sus combinaciones aumenta y mantener las restricciones de seguridad se torna complicado.
Podemos entonces extender la definición de DBMS como un sistema robusto que es capaz de emplear algoritmos de almacenamiento y recuperación de información para poder implementar un modelo de datos de manera física garantizando que todas las transacciones que se realizan con respecto a dichos datos sean "ácidas" (Atomicity, Consistency, Isolation, Durability).
1.3 Vistas de datos
Una de las ventajas de emplear una base de datos es que los datos se pueden ver a distintos niveles de abstracción, separando por ejemplo detalles de almacenamiento y mantenimiento.
Niveles de abstracción:
Nivel Físico: el más bajo y define cómo los datos son almacenados
Nivel Lógico: define qué datos hay almacenados y cómo se relacionan
Nivel de visión: más alto nivel, define vistas de "partes" de la base de datos, esto para restringir el acceso a determinados datos o bien para simplificar la interacción
1.4 Modelos de datos
1.4.1 Definición
Un modelo de datos es una colección de herramientas conceptuales para describir datos, sus relaciones, semántica y restricciones de consistencia
Exiten 3 niveles de modelado:
Conceptual
Modelo Entidad-Relación
Lógico
Modelo Relacional
Físico
Implementación en el DBMS
1.1 Aplicación de bases de datos
1.1.1 Antecedentes
La información ha llegado a ser el eje que mueve a la mayoría de las organizaciones hoy día
La cantidad de información que se maneja actualmente es en extremo enorme.
Se tiene la necesidad de tenerla perfectamente organizada de manera que pueda ser accesada fácilmente y por otro lado se debe tener disponible todo el tiempo (sistemas 24x7)
La solución: las personas de computación han desarrollado conceptos, técnicas y sistemas bajo un tópico conocido como "bases de datos" (databases)
1.1.2 Definición
Surgen entonces los primeros conceptos:
Dato: es la representación física de un aspecto de la realidad
Base de datos: conjunto de datos, que pueden estar organizados y/o interrelacionados de alguna manera con un propósito particular
DBMS*: Sistema Manejador de Bases de Datos (DataBase Manager/Management System) es una colección e datos interrelacionados y un conjunto de programas para accesarlos. En otras palabras un sistema para crear, manipular y aprovechar bases de datos.*Algunos lo llaman SGBD (Sistema Gestionador de Bases de Datos)
1.1.3 Escenarios de bases de datos
Podemos afirmar que las bases de datos están en todas partes, cualquier problema que podamos pensar podemos asociar una base de datos
Bancos: cuentas, transacciones, fondos de ahorro, SAR
Aerolíneas: reservaciones, pasajes, suministros, personal de vuelos
Escuelas: cursos, calificaciones, horarios
Negocios: compras, proveedores, ventas, clientes, devoluciones
Fábricas: flujo de procesos, almacenes, envíos
Recursos Humanos: empleados, puestos, salarios, impuestos, prestaciones
Curiosamente el uso de las bases de datos puede llegar a ser tan transparente que para algunos pareciera que no existen como en las transacciones de web o el cajero del banco (ATM).
1.2 Sistemas de bases de datos vs sistemas de archivos(Databases vs File Systems)
El camino hacia las bases de datos ha sido largo y en el trayecto se han desarrollado un gran número de técnicas que forman los cimientos de las bd y de otras tecnologías.
Dentro de estas técnicas tenemos:
Archivos, Sistemas de Archivos, Acceso y manipulación de archivos, Indices
Pero...
por qué no es suficiente utilizar las herramientas anteriores y es necesario emplear un DBMS ?no es lo mismo ?cuál es la diferencia ?
No es lo mismo, un sistemas de archivos aún cuando pensemos que contiene lógicamente archivos y que se cuenta con índices para accesar los registros en ellos, carece de mucha funcionalidad que se emplea en la mayoría de las aplicaciones, aunque como se mencionó anteriormente, un DBMS emplea sistemas de archivos e índices para la manipulación de datos.
La funcionalidad adicional que provee un DBMS surge en base de algunos inconvenientes al emplear sistemas de archivos únicamente:
Redundancia de datos e inconsistencias (Redundancy and Inconsistency): formatos, duplicidad de información (alto costo de almacenamiento y acceso) e incongruencia entre datos o copias de datos a lo largo del sistema.
Dificultad de acceso (Access): en un sistema de archivos no se pueden obtener aquellos datos que no estén implantados en un programa, se carece de niveles de abstracción.
Aislamiento de datos (Isolation): debido al factor tiempo y los requerimientos que van surgiendo se puede llegar a tener un problema al intentar separar un conjunto de datos porque ya se tiene un enredo en los archivos y se podría dar el caso en que dos usuarios estén manipulando la misma información pero de distinta manera.
Integridad (Integrity): si queremos asociar dos datos, por ejemplo un alumno con una materia que esté cursando, debemos asegurarnos que ambas entidades existan, de lo contrario el alumno parecerá cursando un curso fantasma y viceversa. Para ello se emplean "restricciones de consistencia" (consistency constraints)
Atomicidad (Atomicity): el problema clásico de transacciones bancarias, u ocurre toda la transacción o no ocurre nada pero no puede quedarse a medias.
Acceso concurrente (Concurrent-access): garantizar un buen tiempo de respuesta, que todos los usuarios puedan accesar y/o modificar la información; esto no es fácil porque también hay que considerar que aunque los datos son los mismos, las aplicaciones no necesariamente lo son.
Seguridad (Security): no toda la información debe estar disponible a todos los usuarios, algunos usuarios solo tendrán permisos de lectura, esto es relativamente sencillo de resolver aplicando "roles" pero el problema aumenta cuando en luegar de pensar en terminos de usuarios pensamos en terminos de aplicaciones ya que el número de roles y sus combinaciones aumenta y mantener las restricciones de seguridad se torna complicado.
Podemos entonces extender la definición de DBMS como un sistema robusto que es capaz de emplear algoritmos de almacenamiento y recuperación de información para poder implementar un modelo de datos de manera física garantizando que todas las transacciones que se realizan con respecto a dichos datos sean "ácidas" (Atomicity, Consistency, Isolation, Durability).
1.3 Vistas de datos
Una de las ventajas de emplear una base de datos es que los datos se pueden ver a distintos niveles de abstracción, separando por ejemplo detalles de almacenamiento y mantenimiento.
Niveles de abstracción:
Nivel Físico: el más bajo y define cómo los datos son almacenados
Nivel Lógico: define qué datos hay almacenados y cómo se relacionan
Nivel de visión: más alto nivel, define vistas de "partes" de la base de datos, esto para restringir el acceso a determinados datos o bien para simplificar la interacción
1.4 Modelos de datos
1.4.1 Definición
Un modelo de datos es una colección de herramientas conceptuales para describir datos, sus relaciones, semántica y restricciones de consistencia
Exiten 3 niveles de modelado:
Conceptual
Modelo Entidad-Relación
Lógico
Modelo Relacional
Físico
Implementación en el DBMS
LAS FASES DEL PROCESO DE PROGRAMACIÓN
A fin de poder asegurar que un sistema cumpla con el sistema requerido 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 el la comunicación 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. Codifica las instrucciones implementando algoritmos en el lenguaje de programación adecuado. Verifica la lógica del programa preparando rutinas de prueba. Revisa, depura y corrige los programas. Evalúa y modifica los programas existentes para tomar en cuenta los cambios producidos en los requerimientos del sistema. Finalmente prepara el documento base de la ayuda de usuarios.
Nótese que un programador debe comprender y expresarse a través de un lenguaje de alta programación. Este conocimiento puede ser por oficio práctico, intuición o por estudio formales . 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 Bool, 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.
Cualquier consideración del proceso de programación mismo debe comenzar aislando cada una de sus fases componentes. Se identifica las siguientes cinco fases:
1. Análisis del problema2. Desarrollo de la solución3. Construcción de la solución en forma de programa4. Prueba5. 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.
La segunda etapa, el desarrollo de la solución, es eminentemente creativa. 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, script, 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.
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 programado 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 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, puede reducirse el número de ellos, 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; 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 en las compañías profesionales de programación, los encargados suelen 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 datos de prueba desarrollados, independientemente, 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.
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, 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 que deben hacerse a los defectos del diseño, lo cual puede incluir el desarrollo de funciones adicionales para reunir nuevas necesidades. El tiempo de los desarrolladores para producir nuevos programas se ve siempre afectado por el tiempo que deben dedicar al mantenimiento de los programas viejos. La inevitabilidad del mantenimiento debe reconocerse y, en consecuencia, deben realizarse las acciones que sean necesarias para reducir el tiempo que ello implica.
A fin de poder asegurar que un sistema cumpla con el sistema requerido 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 el la comunicación 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. Codifica las instrucciones implementando algoritmos en el lenguaje de programación adecuado. Verifica la lógica del programa preparando rutinas de prueba. Revisa, depura y corrige los programas. Evalúa y modifica los programas existentes para tomar en cuenta los cambios producidos en los requerimientos del sistema. Finalmente prepara el documento base de la ayuda de usuarios.
Nótese que un programador debe comprender y expresarse a través de un lenguaje de alta programación. Este conocimiento puede ser por oficio práctico, intuición o por estudio formales . 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 Bool, 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.
Cualquier consideración del proceso de programación mismo debe comenzar aislando cada una de sus fases componentes. Se identifica las siguientes cinco fases:
1. Análisis del problema2. Desarrollo de la solución3. Construcción de la solución en forma de programa4. Prueba5. 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.
La segunda etapa, el desarrollo de la solución, es eminentemente creativa. 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, script, 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.
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 programado 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 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, puede reducirse el número de ellos, 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; 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 en las compañías profesionales de programación, los encargados suelen 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 datos de prueba desarrollados, independientemente, 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.
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, 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 que deben hacerse a los defectos del diseño, lo cual puede incluir el desarrollo de funciones adicionales para reunir nuevas necesidades. El tiempo de los desarrolladores para producir nuevos programas se ve siempre afectado por el tiempo que deben dedicar al mantenimiento de los programas viejos. La inevitabilidad del mantenimiento debe reconocerse y, en consecuencia, deben realizarse las acciones que sean necesarias para reducir el tiempo que ello implica.
Suscribirse a:
Entradas (Atom)
