UNIDAD 4 AUDITORIA AL DESARROLLO, ADQUISICIN Y

MANTENIMIENTO DE SISTEMAS DE INFORMACIN

INTRODUCCIN

http://www.horcan.com.ar/cont_hmsi.asp#g

DESCRIPCION
Las empresas a menudo realizan una gran inversin monetaria y asignan
numerosos recursos humanos para el desarrollo, adquisicin y mantenimiento de
los sistemas. Por lo tanto, los mismos se convierten en bienes que deben
ser protegidos y controlados.
ABORDAJE METODOLOGICO
Seguimiento en todas las fases de SDLC (Software Development Life Cicle).
Incorporacin de la funcin de Control de Calidad en las distintas fases.
Verificacin de separacin real de ambientes de procesamiento (Produccin y
Prueba).
RESULTADOS QUE SE OBTIENEN
Integridad en los sistemas aplicativos.
Aseguramiento de la calidad de los sistemas.
Mejora de los procedimientos de puesta en produccin de aplicaciones
informticas.
Transparencia en las decisiones de compra de soluciones de sistemas de
informacin

4.1 PAPEL DEL AUDITOR EN LA ADMINISTRACIN DEL PROYECTO

ORGANIZACIN Y ADMINISTRACION

Deber garantizarse la mejor infraestructura del rea de sistemas con el fin de que sus servicios se
presten con calidad y efectividad, teniendo presente la ubicacin y estructura organizacional que le
permita brindar el apoyo necesario a todas las unidades de la entidad, el aseguramiento de la
calidad, la conformacin de comits de apoyo, definicin de polticas, funciones y
responsabilidades; as como la asignacin de personal competente y su debida capacitacin.

Para lograr lo anterior, se requiere de planeamiento de la oficina de servicios de informacin;

polticas, estndares y procedimientos; responsabilidades organizacionales y administracin de
personal; aseguramiento de calidad de los servicios de informacin; la funcin de auditora interna
y requerimientos externos.

A fin de asegurar su contribucin en la consecucin de los objetivos organizacionales, la oficina de

servicios de informacin debe tener planes a largo y corto plazo. Estos planes deben ser
consistentes con los objetivos organizacionales. Las polticas, estndares y procedimientos sirven
de base para el planeamiento de la administracin, control y evaluacin de sus actividades.

La calidad de los servicios brindados por la oficina de servicios de informacin debe asegurarse
estableciendo una funcin separada dentro de la misma, dedicada a mantener los estndares
establecidos de calidad. Como complemento a otros elementos de control, la funcin de auditora
interna se debe establecer con la suficiente competencia tcnica, independencia y autoridad para
conducir revisiones objetivas a los controles en sistemas de informacin, as como para preparar y
emitir reportes de sus hallazgos y recomendaciones para elevar los servicios de los sistemas de
informacin.

AUDITANDO LA ORGANIZACIN Y LA ADMINISTRACIN:

1. Verificar las funciones del rea

a) Documentos que contengan la especificacin de las funciones

b) Que esos documentos estn aprobados y que se lleven a cabo

2. Verificar que exista el organigrama del rea, la descripcin de puestos y el personal que ah
labora

a) Manual de la organizacin

*Relaciones entre los puestos, el organigrama y el personal

b) Procedimientos de promocin

3. Existe un plan estratgico del rea?

a) Debe ser claro, preciso, real y prctico

b) Debe ser revisado y actualizado regularmente

c) Debe ser difundido

4. Plan de sistemas

a) Propuestas y aprobacin de proyectos

b)Desarrollo de sistemas

c) Calendarizacin

d) Asignacin de presupuestos y tiempos

e) Documentacin

5. Presupuestos-> asignados-> se cumple}

6. Procedimientos de contratacin, formacin, abandono de puestos, rotacin, ideas/sugerencias

7. Biblioteca

8. Utilizacin de herramientas segn el plan de sistemas

9. Creacin y utilizacin de estndares para actividades principales y diseo de sistemas

a)Anlisis

b) Diseo

c) Programacin ( triggers...)

d) Manuales

e) Modificaciones

10. Existencia de un mtodo para estimar los tiempos de las fases del proyecto ( correcto,
practicable y ajustable)

11. Registro de problemas que se producen en los proyectos

12. Existencia de protocolos de contratacin de outsourcing

13. Verificar las relaciones externas del rea (proveedores, ajustadores, tcnicos, corporativos,
departamentos, etc.)

4.1.1 FASES DE SDLC/ADQUISICIN/MANTENIMIENTO

DESCRIPCION
Las empresas a menudo realizan una gran inversin monetaria y asignan
numerosos recursos humanos para el desarrollo, adquisicin y mantenimiento de
los sistemas. Por lo tanto, los mismos se convierten en bienes que deben
ser protegidos y controlados.
ABORDAJE METODOLOGICO
Seguimiento en todas las fases de SDLC (Software Development Life Cicle).
Incorporacin de la funcin de Control de Calidad en las distintas fases.
Verificacin de separacin real de ambientes de procesamiento (Produccin y
Prueba).
RESULTADOS QUE SE OBTIENEN
Integridad en los sistemas aplicativos.
Aseguramiento de la calidad de los sistemas.
Mejora de los procedimientos de puesta en produccin de aplicaciones
informticas.
Transparencia en las decisiones de compra de soluciones de sistemas de
informacin

[HORCAN]
4.2 PRCTICAS DE ADQUISICIN Y DESARROLLO DE SI

Se dividen en tres etapas:

APROBACIN...

1. Documentacin de aprobacin (objetivos, alcance y reas)

2. Estudio de factibilidad

3. Responsable o Director del Proyecto

4. El proyecto debe ser catalogado

5. Determinacin del ciclo de vida

6. Eleccin del equipo tcnico

PLANIFICACION...

1. Elaborar el plan del proyecto

2. Elaborar mecanismos de resolucin de problemas

3. Mecanismos de control de cambios y reajustes

4. Mecanismos de seguimientos de los tiempos por tarea, fase o proyecto

5. Seguimiento de las etapas del ciclo de vida

6. Mecanismos de finalizacin para liberar documentacin y recursos y hacer la evaluacin del

proyecto

4.2.1 DEFINICIN DE REQUERIMIENTOS

Para el desarrollo efectivo de los sistemas de informacin automatizada debern cumplirse

procedimientos establecidos con relacin a la metodologa del ciclo de vida del desarrollo de
sistemas; las etapas a considerar deben ser: iniciacin de proyectos, estudio de factibilidad,
anlisis, diseo, desarrollo e implementacin, operacin, mantenimiento, y plan de revisin
posterior a la implantacin por parte del nivel gerencial competente.

Para el desarrollo de sistemas se debe contar con el involucramiento del departamento usuario en
la identificacin de la naturaleza general y el enfoque del proyecto de desarrollo de sistemas. Los
requerimientos de informacin a ser satisfechos por los sistemas nuevos o modificados, deben ser
definidos cuidadosamente en forma escrita y el desarrollo de la solucin propuesta debe ser
aprobado antes de que el proceso inicie.

En los proyectos propuestos debe prepararse un estudio de factibilidad, en el cual se formulen

diferentes alternativas para alcanzar los objetivos del proyecto, en trminos de anlisis costo-
beneficio por cada una de las alternativas propuestas. Entre ellas, debe considerarse la posibilidad
de una alternativa nula. Cuando se haya tomado la decisin de proceder con la ejecucin del
proyecto propuesto, deber realizarse por escrito un plan maestro del proyecto.

Una vez que el sistema de informacin sea implementado, debe ser revisado, para asegurarse de
tener un sistema que cumpla con los objetivos y necesidades del usuario, que advierta los
beneficios anticipados y que se apega a los requerimientos de la metodologa.

Anlisis de requerimientos del sistema:

* Verificar la participacin de todas las reas y personas relacionadas con el sistema

* Verificar que se tom en cuenta a las personas indicadas y se les aplicaron las pruebas correctas
* Debe de existir una documentacin del sistema actual y los problemas asociados con el mismo
* Definir las diferentes alternativas de construccin

4.2.2 ESTUDIO DE FACTIBILIDAD

Es importante elaborar un estudio tecnolgico de viabilidad en el cual se contemplen distintas

alternativas para alcanzar los objetivos del proyecto acompaados de un anlisis costo-beneficio
para cada una de las opciones. Se debe considerar entre estas alternativas la posibilidad de no
llevar a cabo el proyecto (no siempre est justificada la implantacin de un sistema de bases de
datos) as como la disyuntiva entre desarrollar y comprar (en la prctica, a veces nos encontramos
con que se ha desarrollado una aplicacin que ya exista en el mercado cuya compra hubiese
supuesto un riesgo menor, asegurndonos incluso una mayor calidad a un precio inferior).

Desafortunadamente, en bastantes empresas este estudio de viabilidad no se lleva a cabo con el

rigor necesario, con lo que a medida que se van desarrollando, los sistemas demuestran, a veces,
ser poco rentables.

El auditor debe comprobar tambin que la alta direccin revisa los informes de los estudios de
viabilidad y que es la que decide seguir adelante i no con el proyecto. Esto es fundamental porque
los tcnicos han de tener en cuenta que si no existe una decidida voluntad de la organizacin en su
conjunto, impulsada por los directivos, aumenta considerablemente el riesgo de fracasar en la
implantacin del sistema.

Los objetivos de control exigen que para todo sistema que se disee, debe
realizarse un estudio de factibilidad, previa definicin de requerimientos, y para
cada una de las opciones revisadas, sugeridas y evaluadas, que comprenda al
menos tres factibilidades:

Factibilidad Tecnolgica

Que la tecnologa seleccionada funcionar de manera correcta y

adecuada, y sin menoscabo del sistema, una vez puesto en
operacin y por la vida del mismo. Que la aplicacin soportar
cambios sustanciales en la tecnologa sin tener que realizar
modificaciones importantes en l.
 Factibilidad Operacional

Que el sistema una vez puesto en operacin funcionar de acuerdo

con los criterios bajo los cuales se dise y que no ofrecer
problemas de carcter tcnico ni administrativo.

Factibilidad Econmico / Financiera

Que los beneficios (tangibles e intangibles) y ahorros superen a los

costos; que los ndices financieros que se calculen sean aceptables,
de acuerdo con polticas y estndares generales y especficos; que
el proyecto tenga contenido econmico y est contemplado en el
presupuesto respectivo.

Como mnimo deben calcularse las siguientes razones:

o Tasa Interna de Retorno

o Valor Neto Presente
o Perodo de Recuperacin
o Y, el total de los beneficios netos.

Dependiendo de los resultados de este estudio se determinar si se

contina o no con el proyecto.

4.2.3 ADQUISICIN DE SOFTWARE

ANALISIS DE CONTRATOS INFORMATICOS

DESCRIPCION
Antes de adquirir algn tipo de software o servicio informtico es necesario
entender no slo la parte legal del contrato sino tambin los aspectos tcnicos del
mismo.

ABORDAJE METODOLOGICO
Evaluacin especfica de los productos (Software, Hardware, Servicios) a entregar
por el proveedor.
Definicin de fechas y pautas de cumplimiento de los servicios contratados.

RESULTADOS QUE SE OBTIENEN

Mejora en las negociaciones.
Optimizacin de las contraprestaciones de servicios informticos.
Participacin en la redaccin de clusulas

El proceso de adquisicin y mantenimiento de infraestructura tecnolgica provee las plataformas

adecuadas para soportar las aplicaciones del negocio. Permite definir consideraciones especficas
de requerimientos funcionales y operativos y una implantacin por fases con hitos claros.
Se deben considerar: la disponibilidad de la tecnologa, la direccin de su evolucin, las polticas
de seguridad, el ajuste de los procedimientos a la instalacin y la flexibilidad.

Es importante la integridad, peor han de prevalecer eficacia y eficiencia.

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

La estimacin de costos de un producto de programacin es una de las ms difciles y errticas

tareas, es complicado hacer estimaciones exactas durante la fase de planeacin de un desarrollo
debido a la gran cantidad de factores desconocidos en ese momento. Sin embargo, la prctica
normal en los contratos implica un firme compromiso monetario como parte del estudio de
factibilidad. Lo anterior, aunado a la naturaleza competitiva de este negocio, es un factor que
contribuye a los retrasos de entrega y sobregiro en presupuesto tan comunes en los proyectos dfe
programacin.

Reconociendo este problema, algunas organizaciones utilizan una serie de estimadores de costos;
se prepara un estudio preliminar durante la fase de planeacin y se presenta en la revisin de la
factibilidad del proyecto. La estimacin mejorada se muestra en las revisiones de los requisitos de
programacin y la estimacin final se presenta durante la revisin preliminar del diseo. Cada
estimacin es un refinamiento obtenido como resultado de las actividades de trabajo desarrolladas
adicionalmente; algunas veces, varias opciones del producto, con sus respectivos costos, se
exhiben en las revisiones; lo anterior permite que el cliente escoja una solucin adecuada dentro
de las posibles soluciones.

En ocasiones los clientes financian las fases de anlisis y de diseo preliminar en contratos
separados para poder alcanzar estimaciones exactas en cuanto a costo y tiempo de entrega. Los
contratos para anlisis y diseo preliminar a veces se otorgan a diversas empresas de
programacin por parte del cliente, quien escoge despus la organizacin que ms se ajuste con
base a un concurso del anlisis y diseo preliminar para que se desarrollo el producto.

Factores principales que influyen en el costo de software:

1. Capacidad del programador

2. Complejidad del producto
3. Tamao del programa
4. Tiempo disponible
5. Confiabilidad requerida
6. Nivel Tecnolgico

Para la adquisicin del software se debe:

1. Comprobar que todos los lenguajes, herramientas, compiladores, etc., estn homologados
2. Comprobar que existan mecanismos de control en la adquisicin de software
a) Adquisiciones
*Productividad
* Portabilidad
* Transicin de los productos actuales
* Solvencia del proveedor
* Compatibilidad con el entorno actual
 * Protocolos de comunicacin
* Riesgos al cambio
3. Informar al personal de los nuevos productos
4. Contar con catlogos y manuales de los productos
5. Registro de fallas e informacin importante de los productos
6. Registro de pruebas a nivel tecnolgico
7. Reutilizacin de software
a) libreras
b) clases
c) programas tipo
d) componentes

[MEPI]

4.2.4 DISEO DETALLADO

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

En esta fase se llevarn a cabo los diseos lgico y fsico de la base de datos, por lo que el auditor
tendr que examinar si estos diseos se han realizado correctamente; determinando si la definicin
de los datos contempla adems de su estructura, las asociaciones y las restricciones oportunas,
as como las especificaciones de almacenamiento de datos y las cuestiones relativas a la
seguridad. El auditor tendr que tomar una muestra de ciertos elementos (tablas, vistas, ndices) y
comprobar que su definicin es completa, que ha sido aprobada por el usuario y que el
administrador de la base de datos particip en su establecimiento.

Es importante que la direccin del departamento de informtica, los usuarios e incluso, en algunas
ocasiones, la alta direccin, aprueben el diseo de los datos, al igual que el de las aplicaciones.

Una vez diseada la BD, se proceder a su carga, ya sea migrando datos de un soporte magntico
o introducindolos manualmente.

Las migraciones o conversiones de sistemas, como el paso de un sistema de archivos a uno de

bases de datos, o de un tipo de SGBD (de jerrquico a relacional), entraan un riesgo muy
importante por lo que debern estar claramente planificadas para evitar prdida de informacin y la
transmisin al nuevo sistema de datos errneos. Tambin se debern realizar pruebas en paralelo,
verificando que la decisin real de dar por terminada la prueba en paralelo se atena a los criterios
establecidos por la direccin y que se haya aplicado un control estricto de la correccin de errores
detectados en esta fase.

Por lo que respecta a la entrada manual de datos, hay que establecer un conjunto de controles que
aseguren la integridad de los mismos. A este respecto, cabe destacar que las declaraciones
escritas de procedimientos de la organizacin referentes a la entrega de datos a ser procesados
deben asegurar que los datos se autorizan, recopilan, preparan, transmiten, y se comprueba su
integridad de forma apropiada.

Tambin es aconsejable que los procedimientos y el diseo de los documentos fuentes minimicen
los errores y las omisiones, as como el establecimiento de unos procedimientos de autorizacin de
datos.
El Diseo ...

* El entorno tecnolgico debe estar definido, ser claro y preciso

* Se debe empezar ka descomposicin modular
* Disear la estructura fsica de los datos
* Disear el plan de prueba de los mdulos por separado

4.2.5 PROGRAMACION

Se debe:

Verificar que la construccin de los mdulos se haga de acuerdo a los requerimientos de

los usuarios, a los estndares y al plan del proyecto
Que se utilicen tcnicas de programacin adecuadas
El entorno de desarrollo debe ser el adecuado y de acuerdo a lo especificado en el anlisis
Se debe programar, probar y documentar cada uno de los componentes del sistema
Deben hacerse pruebas de integracin
Se deben especificar los perfiles y capacitacin de los usuarios
Se deben especificar los recursos materiales necesarios para la integracin del sistema y
el usuario

[MEPI]

Los lenguajes de programacin son los vehculos notacionales que se usan para instrumentar
productos de la programacin. Las caractersticas disponibles en el lenguaje de instrumentacin
ejercen una fuerte influencia sobre la estructura arquitectnico y los detalles algortmicos escritos
en ese lenguaje.

[RIFA]

4.2.6 PRUEBAS

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

Los planes de prueba son un importante, peor a menudo pasado por alto, producto del diseo de la
programacin. Un plan de prueba prescribe varias clases de actividades que se efectuarn para
demostrar que el producto de programacin cumple con sus requisitos.

El plan de prueba especifica los objetivos de las pruebas, los criterios de realizacin de pruebas, el
plan de integracin del sistema, mtodos a utilizarse en mdulos particulares, y los casos
particulares de prueba a utilizarse.

Hay cuatro tipos de pruebas que un producto de programacin debe satisfacer: funcionales, de
desempeo, de tensin y estructurales. Las pruebas funcionales y de desempeo se basan en las
especificaciones de requisitos; se disean para demostrar que el sistema satisface sus requisitos.
Por lo tanto, el plan de prueba slo puede ser tan bueno como sean los requisitos, los que a su vez
deben expresarse en trminos cuantificables, verificables.

Los casos de prueba funcionales especifican las condiciones operativas normales, los valores
comunes de entrada, y los resultados normales esperados. Las pruebas funcionales tambin
deben disearse para probar condiciones de frontera justo dentro y justo ms all de los lmites.
Tambin deben probarse valores especiales tales como archivos y arreglos que contengan valores
idnticos, la matriz identidad, la matriz cero, etc. Suponiendo que deben probarse los valores
iniciales y los que proporcione el sistema, y suponiendo que las entradas tienen relaciones de
orden, deben probarse con datos que contengan tanto ordenamientos correctos como incorrectos.

Las pruebas de desempeo deben disearse para verificar el tiempo de respuesta, tiempo de
ejecucin, capacidad de procesamiento, utilizacin de memoria primaria y secundaria, y tasas de
trfico en los canales de datos y ligas de comunicacin. Las pruebas de desempeo a menudo
indicarn los cuellos de botella del procesamiento que deben atenderse durante la prueba y
afinacin del sistema.

Cada prueba funcional y de desempeo debe especificar la configuracin de la mquina, las

suposiciones concernientes al estado del sistema para el caso de prueba, los requisitos que se
estn probando, las entradas de prueba, y los resultados esperados. Es particularmente importante
que los resultados esperados de cada prueba se especifiquen previamente a la instrumentacin del
sistema y las pruebas reales. De otro modo, es fcil racionalizar un resultado incorrecto.

Las pruebas de tensin se disean para sobrecargar a un sistema en varias maneras, tales como
intentar conectar ms del mximo nmero permitido de terminales, procesar ms del nmero
permitido de identificadores de niveles estticos, o desconectar una liga de comunicacin. El
propsito de las pruebas de tensin es determinar las limitaciones del sistema y, cuando el sistema
falla, determinar la manera en que se manifiesta la falla. Las pruebas de tensin pueden
proporcionar un conocimiento valioso relacionado con la fortaleza y la debilidad de un sistema. Las
pruebas de tensin se obtienen de los requisitos, el diseo, y los presentimientos e intuiciones de
los diseadores.

Las pruebas estructurales estn relacionadas con examen de la lgica de procesamiento interno de
un sistema de programacin. Las rutinas particulares que se invocan y los caminos lgicos
recorridos a lo largo de las rutinas son los objetos de inters. El objetivo de la prueba estructural es
recorrer un nmero especificado de caminos a travs de cada rutina en el sistema para establecer
la profundidad de la prueba.

El enfoque recomendado es el realizar las pruebas funcional, de desempeo, y de tensin sobre el

sistema instrumentado, y aumentar estas pruebas con pruebas de estructura adicionales par lograr
el nivel deseado de cobertura de las pruebas. As las pruebas estructurales no pueden disearse
hasta que el sistema ha sido instrumentado y se sujete a un plan de pruebas predefinido.

4.2.7 IMPLANTACIN

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

Comprendera todas las actividades para conseguir el funcionamiento adecuado del elemento en
cuestin:

Planificacin. Procedimiento general del suministrador adaptado a la instalacin concreta.

Documentacin. Inventario de componentes del elemento y normas de actualizacin.
Parametrizacin. Valores de parmetros del sistema en funcin del resto de elementos
planificados
Pruebas. Verificaciones a realizar y sus resultados

Debe partirse de los documentos existentes en la organizacin sobre normativa general: estructura
organizativa ( especialmente informtica), normativas de instalacin (como, por ejemplo,
direcciones IP a utilizar), metodologa general de proyectos y dems informaciones que puedan y
deban condicionar la instalacin.

Especificaciones de funcionamiento:

*Verificar que existan o se elaboren los modelos lgicos de procesos y de datos

* Que sean coherentes y entendible
* Que sigan los estndares de l plan de sistemas
* Diccionario de datos
* Interfaces con los usuarios
* Requisitos de seguridad
* Especificacin de las pruebas y su duracin

Implantacin...

Se deben realizar las pruebas del sistema que se especificaron en el anlisis

El sistema debe ser aceptado completamente por los usuarios antes de ser explotado
Se deben instalar todos los procedimientos de explotacin necesarios
Se coordinar la explotacin del sistema anterior y el nuevo
Debe de existir el documento de implantacin por parte de usuarios
Debe registrarse el trabajo de los usuarios con el sistema
Debern elaborarse y ponerse en marcha los mecanismos de mantenimiento del sistema

4.2.8 REVISIN DE LA POST-IMPLANTACIN

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

Aunque en bastantes organizaciones no se lleva a cabo, por falta de tiempo y recursos, se debera
establecer el desarrollo de un plan para efectuar una revisin post-implantacin de todo sistema
nuevo o modificado con el fin de evaluar si:

Se han conseguido los resultados esperados

Se satisfacen las necesidades de los usuarios
Los costos y beneficios coinciden con los previstos

4.3 PRACTICAS DE MANTENIMIENTO DE SI

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

Comprendera el conjunto de acciones necesarias para la puesta al da del elemento, as como la

asistencia de terceros para la consecucin de dicha puesta al da y la asistencia a prestar a otros
colectivos (desarrolladores, por ejemplo) para facilitar informacin necesaria sobre el mismo
sistema y sus herramientas para su mejor utilizacin.
 Planificacin. Control del periodo de garanta y comienzo del mantenimiento del elemento
Documentacin. Procedimiento para contactar con el soporte
Parametrizacin. Adaptacin de los parmetros del sistema en funcin de nuevos
requerimientos o como resultado de nuevas versiones o resolucin de incidencias.
Pruebas. Verificaciones de los cambios o adaptaciones realizadas.

4.3.2 DOCUMENTACIN DEL SISTEMA

INGENIERIA DE SOFTWARE
Richard E. Fairley
Mc. Graw Hill

DOCUMENTACIN DE APOYO

Las especificaciones de requisitos, documentacin de diseo, planes de prueba, manuales de

usuario, instrucciones de instalacin y los reportes de mantenimiento son ejemplos de
documentacin de apoyo. Estos documentos son los productos que resultan del desarrollo y
mantenimiento sistemtico de la programacin.
Un enfoque sistemtico al desarrollo de la programacin garantiza que los documentos de apoyo
se desarrollen de una manera ordenada, y que esos documentos se encuentren disponibles
cuando se necesiten. En el enfoque adecuado para el desarrollo de la programacin, la
preparacin de documentos de apoyo normalmente se difiere hasta que se termine la
instrumentacin del sistema.

NOTAS DE UNIDAD DE PROGRAMA

Una unidad de programa es una unidad de cdigo fuente que es desarrollada y/o mantenida por
una persona; esa persona es la responsable de la unidad. En un sistema bien diseado, una
unidad de programa es un subprograma o grupo de subprogramas que cumplen una funcin bien
definida o forman un subsistema bien definido.

Una unidad de programa tambin es lo suficientemente pequea y modular que puede ser probada
totalmente en forma aislada por el programador que la desarrolla o modifica. Un cuaderno de notas
de cada unidad de programa (tambin conocido como carpeta de desarrollo de unidad) consta de
una portada y varias secciones. La portada es la tabla de contenidos y la hoja de avisos de
terminacin de los diversos logros asociados con la unidad del programa. El mantenimiento del
cuaderno de notas es responsabilidad del programador asignado a la unidad de programa. Las
secciones dentro de un cuaderno de notas de la unidad corresponden a las diversas fases del ciclo
de vida de la unidad.

NOMBRE DE LA UNIDAD______________ PROGRAMADOR________________

RUTINAS INCLUIDAS________________________________________________
 SECCION CONTENIDOS FECHA DE FECHA DE REVISOR /
VENCIMIENTO TERMINACIN FECHA
1 REQUISITOS
2 DISEO
ARQUITECTNICO
3 DISEO
DETALLADO
4 PLAN DE PRUEBA
5 CODIGO FUENTE
6 RESULTADOS DE
PRUEBA
7 CAMBIOS DE
SOLICITUDES
8 NOTAS

CONSENTIMIENTO DE LIBERACIN________________________ FECHA_______________

DOCUMENTACIN INTERNA

Consiste en un prlogo estndar para cada unidad de programa y unidad de compilacin, los
aspectos autodocumentados del cdigo fuente, y los comentarios internos intercalados en la
porcin ejecutable del cdigo.

Formato caracterstico de los prlogos de subprogramas y unidades de compilacin

Nombre del autor

Fecha de compilacin
Funcin (es) realizada (s)
Algoritmos empleados
Autor / Fecha / Propsito de las modificaciones
Parmetros y modos
Aseveracin de entrada
Aseveracin de salida
Variables globales
Efectos colaterales
Estructuras de datos principales
Rutinas que invocan
Rutinas invocadas
Restricciones de tiempo
Manejo de excepciones
Suposiciones