Control de proyectos en áreas de desarrollo de software

Sistema informático para la administración de proyectos generales

Aspectos generales del sofware y beneficios

El sistema a utilizar para el seguimiento y control de los proyectos deberá cumplir con los fines enumerados en la Sección anterior para la etapa de Control, y además, deberá asegurar que la información que se procese sea exacta, confiable y actualizada, proveyendo mecanismos para su utilización de manera oportuna.

Por otra parte, el hecho de disponer de una herramienta específica para el Control no significa que no puedan realizarse reuniones de trabajo o de evaluación, o que se utilicen otros métodos de control, si no que, al contrario, un sistema informático los facilitaría.

Un sistema informático de Control de Proyectos debería diseñarse para que su procesamiento se realice utilizando redes de comunicaciones Wan - Lan, en modalidad “on-line”, con bases de datos centralizadas. Su arquitectura debería construirse para operar bajo la tecnología WEB, con un esquema cliente-servidor y, finalmente, a pesar de implicar mas trabajo, sería deseable que sea totalmente parametrizable, lo cual permitiría, entre otros aspectos, la rápida incorporación de nuevas áreas, inclusive aquellas que no son de desarrollo.

Con respecto al diseño del sistema, se podría programar de tal manera que la navegación de las páginas, en primera vista, se muestre información en forma amplia y resumida y, luego, ante acciones de selección por parte del operador, se pueda ir descendiendo a niveles mas bajos, con un despliegue de los datos a mayor detalle.

Además, y volviendo a la enumeración de algunos de los beneficios funcionales, la sistematización de dicho control propenderá a estandarizar las tareas realizadas por todos y pondrá orden en la ejecución del proyecto y clarificará la relación entre las personas.

También, podría ayudar considerablemente a la elaboración de la documentación relacionada con el proyecto, en el sentido que puede obligar a confeccionarla a medida que se avance en el mismo.

Asimismo, si dicha documentación se guarda electrónicamente, todas las instancias involucradas podrían tener acceso a la misma.

Por otro lado, el sistema informático debería facilitar el proceso de delegación y el trabajo en equipo, asignando la responsabilidad y autoridad funcional de cada proyecto a un líder quien a su vez asigna tareas a cada uno de los integrantes del grupo. También, en el sistema debe existir un responsable superior de todos los líderes de proyectos y ese debe asumirse que es el jefe del área de desarrollo.

Esta sistematización permitirá, también, que el jefe del área cuente con mas tiempo para participar en la definición y planeamiento de nuevos proyectos, así como en el control de los que están en desarrollo, es decir enfocar su actividad en la Gestión.

También, en base a la información obtenida del sistema, debería ser mas fácil ayudar el desarrollo de la gente, potenciando las capacidades de cada uno de ellos, y, además, favorecer su reconocimiento, motivación y elevar su autoestima.

Además, el hecho de contar con información sistémica de los proyectos realizados permitiría que la evaluación del desempeño del personal se realice bajo un marco de objetividad, dado que, dicho desempeño, se puede medir y cuantificar.

El sistema debería permitir que las instancias de autoridad superior al área de desarrollo, puedan observar es estado de los proyectos en curso y terminados, como asimismo, obtener reportes de actividad y progreso detallados y resumidos.

Finalmente, los datos procesados por el sistema deberían poder servir de base para alimentar otros sistemas, como ser los de Planeamiento y de Control de Gestión para los niveles superiores o institucionales.

Funcionalidad

---

Crear y modificar proyectos

Para la creación de un nuevo proyecto sería necesario cargar los siguientes datos:

·Descripción: Debería escribirse, en forma relativamente extensa, sobre los objetivos y alcances del proyecto.

·Descripción corta: Se trata de un nombre abreviado o nemotécnico del proyecto a los efectos de su utilización y reconocimiento en el lenguaje diario.

·Tipo de proyecto: Identifica la naturaleza del proyecto respecto a las tareas que se realizarán, por ejemplo, si se trata de un nuevo sistema, una mejora a uno existente, etc. Mas abajo se dan, en una lista, los posibles tipos a utilizar.

·Prioridad: Debería señalarse el grado de urgencia que tiene el proyecto.

·Sistema: Debería colocarse la identificación del sistema sobre el cual el proyecto impactará.

·Versión (opcional): Debería informarse la versión del sistema donde se incluirán los desarrollos correspondientes al proyecto. Sirve para ordenar los proyectos para igual sistema, con un orden de procedencia.

Al crearse un proyecto, el mismo debería nacer con un estado de ingresado pero no iniciado, sin responsable asignado, sin la duración (horas y fecha de fin) estimada, sin hitos, sin identificar otros proyectos encadenados o relacionados con este y sin los documentos que originan el proyecto.

Estos datos se colocarán, luego, en módulos separados, justamente para poder ingresar los proyectos planificados y aún no definidos, de tal forma que estén registrados en el sistema.

En el proceso de modificación se deberían poder cambiar todos los datos antedichos, incluyendo los relacionados con el responsable, duración del proyecto, estado, etc. y, además, se deberían poder agregar la identificación y/o contenido digital de nuevos documentos vinculados al proyecto.

Crear y modificar las tareas de un proyecto

Para un proyecto determinado se deberán ingresar todas las tareas a desarrollar para poder implementarlo

Los datos iniciales para crear una nueva tarea serían:

·Descripción: Será la definición resumida (si se agrega documento electrónico) o amplia lo que hay que realizar.

·Tipo de tarea: Indica la índole del trabajo a hacer. En la sección “Valores y explicación de los parámetros” se da una lista de los tipos posibles.

·Especificaciones (opcional): Se debería poder agregar un documento electrónico con las definiciones para la tarea.

Al igual que para un proyecto, la tarea se crearía con estado de ingresado (implica no iniciado), sin responsable asignado, sin la duración estimada (horas y fecha de fin), sin identificar otras tareas que condicionan su realización (precedencia) y sin colocarles los entregables que deberá preparar el responsable de la tarea a su término. Estos datos se deberían colocar en instancias independientes.

Por último, la modificación de una tarea, debería ser similar a lo que se dice para proyectos. Es imperativo mantener la relación entre las tareas, por lo tanto un cambio en la misma podría: cambiar su alcance lo que como consecuenia incrementaría el tiempo, con ello obligaría a modificar las fechas de inicio de las actividades dependientes de la actividad modificada.

Informar/subir documentación relacionada con el proyecto

Tanto al inicio del proyecto como durante la vigencia activa del mismo debería poder registrarse los datos relacionados con la documentación vinculada al proyecto (requerimiento formal para realizar el proyecto, definiciones funcionales, definiciones técnicas, minutas de reunión, e-mail cursados, normas legales y reglamentarias, etc.), inclusive, previendo subida del documento electrónico respectivo, si se cuenta con él.

Los datos a ingresar podrían ser el tipo de documento, su número o identificación, fecha de emisión y persona que firma.

Asignar responsable a los proyectos y tareas

Simplemente deberá ingresarse, para un proyecto o tarea determinada, la identificación de la persona designada responsable del mismo.

Esta asignación debería comunicarse automáticamente y por sistema, mediante un e-mail al responsable a los efectos de que el mismo lo asuma. Además, en las vistas del sistema correspondientes la persona designada debería aparecer el proyecto o la tarea ordenada.

El cambio de responsable se hará de la misma manera y, en todos los casos, debería archivarse en la base de datos, dicha modificación, conformando de esta manera, la historia de los todos los responsables que tuvo el proyecto o la tarea, es decir, guardando el nombre, fecha de inicio y fecha de fin, como mínimo, que se mostraría en un pantalla específica.

Ingresar la duración y la fecha de finalización estimada a proyecto y tareas

La primera vez que se ingresen estos datos, sencillamente se ingresarán según corresponda, un proyecto o una tarea.

Sin embargo, cuando sea necesario ajustarlos, debido a demoras o cambio de planes, los nuevos valores deberían ingresarse conjuntamente con un motivo o justificación de dicho cambio. Dichos ajustes, para ser efectivos, deberían ser autorizados por el responsable inmediato superior.

El responsable de autorizar dichos ajustes, debería evaluar dichas solicitudes y registrar, en el sistema, su aprobación o rechazo.

En todos los casos, al igual que el caso del ítem anterior, el sistema debería llevar un registro de lo sucedido y su exhibición cuando se requiera.

Efectuar cambios de estado de proyecto y tarea

Los estados del proyecto y de las tareas deberán ir cambiándose en función de la evolución del mismo.

A los efectos de que dicha modificación se realice, el sistema debería “obligar” esa situación.

Por ejemplo, no podría pasar a estado “en ejecución” si aún no fue asignado a un responsable. Otro caso sería que no pueda darse por terminado un proyecto si hay tareas sin cerrar.

Como siempre, el sistema debería llevar el registro de todos los cambios y reversiones realizados.

Marcar los hitos del proyecto

Para un proyecto determinado podrían marcarse todos sus hitos, dicho de otra manera, colocar señales relacionadas con logros importantes a alcanzar en determinada fecha, lo cual facilita el monitoreo del mismo, en forma más global y sin necesidad de tener que estar familiarizado con el proyecto, como puede ser es el caso de un comité de directores.

Este registro y control se podría realizar mediante la creación de tareas especificas (de tipo “Hito”) las cuales, al cerrarse, daría por cumplido el hito.

Al cumplirse un hito, el sistema, automáticamente, debería disparar un aviso a todos los responsables e interesados que se determine.

Además, deberían existir reportes referidos al cumplimiento de los hitos y atrasos detectados, y conformar para todos los proyectos un tablero de control global.

Administrar los entregables de cada tarea

Para cada tarea deberían indicarse cuales son los entregables exigibles al responsable de la misma.

Esto significa que, por ejemplo, si se solicitó la programación de una funcionalidad para un sistema, además, de la realización de ella, podría pedírsele que elabore la documentación técnica respectiva.

Además, el responsable de la tarea no debería cerrar definitivamente la tarea sino que haría un “cierre provisorio” y sería el líder del proyecto quién, después de las revisiones correspondientes, cerraría la tarea.

La totalidad de la documentación incorporada ya sean requerimientos, otros documentos, especificaciones y entregables, compondrán la documentación del proyecto. Dicha lista debería exhibirse en reportes especiales y, cuando exista la copia electrónica, que pueda abrirse y leerse por pantalla.

Fijar las precedencias de las tareas

Este módulo debería permitir realizar el registro de las relaciones de precedencia de las tareas.

Para poder señalar estas relaciones, podría informarse, en cada tarea, si su inicio esta condicionado a que otra se encuentre iniciada, terminada o que no tenga restricciones para realizarse.

El registro de las precedencias correspondientes deberá generar los alertas necesarios en el momento oportuno, a los efectos de la intervención que corresponda.

Además, debería servir para construir el diagrama de red del proyecto, calcular la duración total e identificar el camino crítico.

Imputar las horas aplicadas y avance a las tareas asignadas

Los responsables de tareas deberán con la periodicidad que se establezca (sería recomendable que sea diario) informar en el sistema la dedicación aplicada a cada una, indicando, además, el porcentaje de avance alcanzado a la fecha.

La pantalla donde se carguen las imputaciones a tareas debería diseñarse de tal manera que facilite el descargo y evite que se deba salir y entrar reiteradas veces para ver datos de la misma y los descargos previos realizados. Además, en esta instancia, debería facilitarse la subida de los entregables exigibles, en el caso de que se este informando la terminación de la misma.

Alertas

El sistema debe generar alertas a fin de avisar a los usuarios de algunas anormalidades, Desvíos o avisos de intervenciones de instancia superior.

Las mismas deberían estar incorporadas en las pantallas del sistema, como ser las apariciones de semáforos o el resaltado de las líneas a considerar.

Otro tipo de alerta deberá producirse en forma externa al sistema, como ser, por ejemplo, mediante la generación de e-mail destinados a los responsables correspondientes.

Con respecto a esto último, ésta podría ser la mecánica para generar las comunicaciones respecto a los ajustes de la duración de proyectos y tareas, cambios de estado, asignación de responsables, etc.

Reportes programados

El sistema debería considerar tanto la generación de aquellos reportes considerados directos o simples, como ser, listado de los proyectos activos asignados a un responsable como de aquellos que requieran una lógica o elaboración más compleja, tal como aquel que dé, por ejemplo, el tiempo dedicado por cada persona, a tareas de mantenimiento, que fueron terminadas entre determinadas fechas y para un sistema en particular.

Deberían existir reportes con las siguientes características:

·Orientados a los Proyectos y a las Tareas.

.Detalle general y particular.

.Agrupados o resumidos por determinada variable.

.Carga horaria aplicada.

.Ajustes de duración realizados.

.Atrasos detectados.

.Hitos cumplidos y atrasados.

·Orientados a la actividad sobre los Proyectos y Tareas.

.Detalle diario y agrupado por responsable, de las horas dedicadas.

.Carga de horas faltante a Tareas.

.Inactividades producidas.

.Productividad comparativa de responsables.

Indicadores

Los indicadores deberían considerar, fundamentalmente, los informes relacionados con la productividad y el avance y estado de los proyectos activos.

En ese sentido, se sugieren reportes o cuadros relacionados con los desvíos tanto en proyectos como en tareas, activos y terminados, relacionando lo estimado originalmente con lo actual, ya sea en horas y fechas.

Gráficos y bajadas de archivos con información

El sistema debería prever que determinados reportes, cuya información se presente agrupada o resumida, en forma matricial, pueda mostrarse gráficamente como ser circular, barras, histograma, etc.

Estos gráficos podrían ser útiles para poder observar mas claramente la distribución de determinadas variables registradas en el sistema. Por ejemplo, podría analizarse la proporción de tiempo dedicado según la tarea realizada (análisis, programación, testing, etc.), y servir de base para dimensionar los recursos del área de desarrollo.

Otra variante podría sería la de generar el diagrama de GANTT de un proyecto determinado, lo cual podría programarse dentro del sistema o generarse un archivo para descargar en la PC que, luego, se ingresaría en algún de los programas específicos preparados para tal fin.

Respecto de la obtención de archivos, además, debería considerarse la generación de las extensiones PDF y CSV, para determinados listados y reportes obtenidos por sistema.

Búsquedas

Debería existir un módulo de búsquedas rápidas o puntuales de determinados elementos registrados en el sistema, en particular, de aquello vinculado con documentos que tienen que ver con áreas externas o usuarias.

Acceso al sistema

Al ingresar al sistema el usuario operador deberá tener definido un perfil, el cual definirá el alcance de su gestión. Dicho perfil podrá contener lo siguiente:

·Identificación del operador.

·Acciones autorizadas al operador a realizar.

·Áreas de Trabajo autorizadas a ingresar.

Estos datos deberían ser permanentes mientras dure su sesión de trabajo.

El acceso al sistema debería realizarse mediante usuarios con perfiles determinados, autorizados mediante un LDAP de seguridad.

Además, tanto la información a visualizar y como acciones a realizar por el operador debería estar restringida o según sea el perfil asignado y, además, sería recomendable que la pantalla de inicio o ingreso sea la que represente la acción principal del operador. Por ejemplo, para un líder de proyecto podrían aparecer solo la lista de sus proyectos, para un programador la pantalla con sus tareas activas (o la de carga de las imputaciones horarias diaria) y, para el CIO, podría mostrarse una página con la lista de sus áreas dependientes y algunos datos resumiendo de actividad de cada una.

Resúmen de la información procesada en el sistema

---

Datos relacionados con un proyecto

·Número del Proyecto

·Descripción corta del Proyecto (Nemotécnico)

·Descripción larga del proyecto.

·Tipo de proyecto.

·Prioridad del Proyecto.

·Sistema

·Área responsable

·Fecha de inicio

·Fecha de Finalización prevista (o real, si esta terminado)

·Duración estimada del Proyecto en Horas.

·Ajustes realizados a la duración estimada y/o fechas de fin, con fechas y motivos.

·Responsable actual

·Responsables anteriores y motivos del reemplazo.

·Estado del proyecto.

·Datos sobre el requerimiento o Inicio del proyecto.

·Hitos del proyecto.

·Documentación electrónica relacionada con el Proyecto.

·Otros Proyectos encadenados al presente.

·Tareas definidas para el proyecto.

Datos relacionados con una tarea

·Número de Tarea.

·Descripción de la Tarea.

·Tipo de Tarea.

.Fase (agrupador de tipos de tarea).

·Prioridad de la Tarea.

·Fecha de Inicio.

·Fecha de Finalización prevista (o real).

·Duración estimada de la Tarea en Horas.

·Ajustes realizados a la duración estimada y/o fechas de fin, con fechas y motivos.

·Realizado hasta la Fecha en Horas.

·Avance en Porcentaje.

·Responsable actual.

·Responsables anteriores y motivos del reemplazo.

·Estado de la Tarea.

·Condicionamiento de Precedencia de la Tarea.

·Documentación electrónica relacionada con las definiciones.

·Documentación electrónica con lo realizado (entregables).

·Detalle de la Carga horaria de lo realizado en la Tarea.

Datos relacionados con las imputaciones horarias a las tareas

·Cantidad de Horas realizadas para una Tarea en una fecha determinada.

·Porcentaje de avance total de la Tarea a una fecha determinada.

Valor y explicación de los parámetros

---

La valores que se explicitan a continuación se orientan a proyectos de desarrollo de software y, los mismos, se deberían considerarse variables, es decir, que deberían residir en la base de datos y programarse rutinas que facilite su mantenimiento, lo cual permitiría tener configuraciones distintas para diversas áreas.

Tipos de proyectos

·MANTENIMIENTO: apunta a modificar el software que se encuentra en entorno de producción Involucra la corrección de errores, entendidos como una desviación de la especificación, tanto en el diseño como la programación.

·MEJORA FUNCIONAL: involucra la adaptación de un sistema, por reemplazo o agregado de funcionalidad.

·MEJORA TECNICA: Involucra la adaptación de un sistema por tareas de optimización técnica o cambios en el entorno tecnológico, manteniendo la misma funcionalidad.

·NUEVO DESARROLLO: se refiere al desarrollo de un nuevo sistema.

·DESARROLLO BREVE: se aplica a nuevos desarrollos de mejoras funcionales de escasa duración (no más de 21 hs. de dedicación total)

·CAPACITACION: incluye asistencia a cursos, tareas de auto capacitación y tutoría técnica para el aprendizaje de otros.

·REVISION DE CALIDAD: engloba las actividades que se realizan para asegurar que el software construido cumpla con los requerimientos funcionales y no funcionales.

Tipos de tarea

·ANÁLISIS DEL REQUERIMIENTO: análisis de los requerimientos en el contexto de desarrollos breves.

·ASISTENCIA A CURSOS: cursos de capacitación, demos, presentaciones, etc.

·AUTOCAPACITACIÓN: lectura de manuales, seguimiento de tutoriales, práctica sobre herramientas técnicas, con el fin del autoaprendizaje.

·ELABORACIÓN DE MANUALES: construcción de manuales de usuario, tutoriales, etc.

·ELABORACIÓN DEFINICIÓN TÉCNICA DETALLADA: transformación de la definición global en una especificación detallada, que posibilite la construcción de software.

·ESQUEMA Y DEFINICIÓN GLOBAL: Definición de funcionalidades a nivel detallado y del diseño global del software, desarrollo formal de la arquitectura a utilizar, la descripción de la estructura modular del sistema y de los modelos conceptuales y de datos.

·EXPLOTACIÓN DE INFORMACIÓN: proceso realizado para la obtención de datos, desde el ambiente de producción, y elaboración para su presentación en algún formato viable para el usuario.

·HOMOLOGACIÓN CON USUARIOS: demostración y pruebas con el área definidora, que culmina con la conformidad del usuario.

.HITO: para aquellas tareas "falsas" que se utilicen para señalar el cumplimiento de una etapa importante.

·INVESTIGACION: tarea de capacitación en el marco de un proceso de desarrollo y destinado exclusivamente al propósito del proyecto en cuestión.

·OPERACIÓN TÉCNICA: engloba una serie de tareas del tipo de generación de backup, instalación de ejecutables en PC, análisis de conectividad, etc.

·PASE A CONTROL DE CALIDAD: armado de la documentación y del software para el área de Control de Calidad.

·PASE A DESARROLLO: armado de documentación y reporte de errores para la vuelta del software revisado, al sector de Desarrollo.

·PLANIFICACIÓN Y SEGUIMIENTO: cubre la planificación global y detallada del proyecto de desarrollo informático y el seguimiento y control del mismo. Es una Tarea que se realiza transversalmente a las etapas de definición, diseño, construcción e implementación y se ejecuta durante las mismas.

·PREPARACIÓN DE AMBIENTES: instalación del software de base, creación / exportación de tablas y todo lo necesario para generar un nuevo ambiente de desarrollo.

·PREPARACIÓN PARA BAJA DEL SISTEMA: acciones para llevar a cabo el retiro del sistema de producción.

·PREPARACIÓN PASE A PRODUCCIÔN: armado de la documentación necesaria y del software para su instalación en el ambiente de producción; incluye la interacción con todas las áreas involucradas.

·PROGRAMACIÓN: creación de objetos de la base y creación y prueba de piezas de software en función de la tecnología elegida.

·PRUEBA FUNCIONAL: planificación de escenarios para la prueba, con casos y resultados esperados.

·PRUEBA TÉCNICA: prueba de los aspectos técnicos de un sistema (tiempos de respuesta, uso de índices, consumo de recursos, etc.).

·PUESTA EN PRODUCCIÓN: engloba las actividades necesarias para la puesta efectiva en producción de un sistema o una mejora al mismo.

·RECEPCIÓN DESDE CONTROL DE CALIDAD: análisis de los resultados de las pruebas realizadas por el sector control de calidad y administración de los eventuales cambios.

·RECEPCIÓN DESDE DESARROLLO: recepción de la documentación y software enviado y administración de recursos para la homologación.

·RELEVAMIENTO Y ANÁLISIS: tarea tendiente a formalizar un proyecto de desarrollo, planificar sus fases y delinear la solución informática.

·REUNIÓN CON USUARIOS: incluye las reuniones con áreas usuarias y definidoras y la elaboración de la minuta correspondiente.

·TUTORÍA TÉCNICA: supervisión del proceso de aprendizaje de otro integrante del área.

Fases de proyectos

·DEFINICIÓN Cubre desde el planteo de una necesidad de solución informática, hasta la formalización de la decisión de iniciar un proceso de desarrollo.

·DISEÑO: Cubre las actividades del relevamiento de las necesidades, especificación de la funcionalidad, análisis y diseño global de la solución.

·CONSTRUCCIÓN: Cubre las actividades de programación y pruebas de calidad del software, culminando con la homologación del software producido.

·IMPLANTACIÓN: cubre la planificación y ejecución de las actividades necesarias para la puesta efectiva en producción de un sistema.

·DISCONTINUIDAD DEL SISTEMA: Cubre la planificación y ejecución de las actividades para retirar el sistema del ambiente de producción.

·SIN FASE: Para proyectos de Capacitación y de Mantenimiento.

Estados del proyecto

·INGRESADO . Proyecto aún no iniciado.

·EN EJECUCIÓN. Proyecto activo y en marcha.

·CON CIERRE PROVISORIO. Proyecto terminado pero sin el visto de la Jefatura.

·CERRADO. Proyecto terminado definitivamente, en condición de cumplido.

·ANULADO. Proyecto cerrado sin haber dedicado tiempo al mismo.

·SUSPENDIDO. Proyecto paralizado pero para reanudar mas adelante.

·CANCELADO. Proyecto terminado sin haber cumplido sus objetivos y con tiempos dedicados al mismo.

Estado de la tarea

·INGRESADA. Tarea aún no iniciada y sin asignar.

·EN EJECUCIÓN. Tarea activa y en marcha.

·CON CIERRE PROVISORIO. Tarea terminada pero sin la conformidad del Líder.

·CERRADA. Tarea terminada y cumplida.

·ANULADA. Tarea cerrada sin haberse dedicado tiempos.

·SUSPENDIDA. Tarea paralizada pero para reanudar próximamente.

·CANCELADA. Tarea cerrada sin cumplimentar y con tiempos dedicados.

Tipos de documentos exigibles por tarea (entregables)

·DAP – DOCUMENTO DE PASE A PRODUCCIÓN. Documento para especificar la puesta efectiva en producción del sistema.

·DGS – DISEÑO GLOBAL DEL SOFTWARE. Documento para explicitar la arquitectura a utilizar, describir la estructura modular del sistema, los ambientes y estándares de desarrollo, la interacción con otros sistemas, el modelo conceptual y el modelo de datos.

·DIP – DOCUMENTO DE INICIO. Documento donde se formaliza el proyecto y planifica sus fases y los recursos necesarios. Se describen las características generales del proyecto.

·DOCUMENTO DE CONFORMIDAD DEL USUARIO. Documento donde se especifican las pruebas de homologación efectuadas por los usuarios y su conformidad para proceder a la implementación en ambiente de producción.

·DPP – DOCUMENTO PRELIMINAR. Documento donde se expone el problema o necesidad del negocio y se describe su solución informática.

·ERS – ESPECIFICACIÓN DE REQUERIMIENTO DE SOFTWARE. Documento para especificar detalladamente los requerimientos del área usuaria.

·ESPECIFICACIÓN DETALLADA DEL SOFTWARE. Definición técnica de cada pieza de software a construir.

·IFS – INFORME DE FINALIZACION DE SOFTWARE. Documento para especificar la configuración de la versión del software y las instrucciones para poner en disponibilidad de producción dicha versión del sistema.

·INFORME. Documento que contiene las novedades respecto a un tema particular.

·INFORME TÉCNICO. Documento conteniendo explicaciones técnicas sobre algún aspecto del sistema.

·LISTADO DE LO CONSTRUIDO. Detalle de lo realizado en al tarea.

·MINUTA DE REUNION. Documento resumen de lo tratado en una reunión de trabajo relacionada con la tarea o proyecto.

·PLANIFICACIÓN DE PRUEBA. Elaboración de un plan de trabajo para realizar la prueba del sistema.

·CASOS DE PRUEBA. Listado o planilla con datos para utilizar en el testing del sistema con todos los desenlaces posibles.

·RESULTADO DE PRUEBA. Planillas con los errores detectados en las pruebas.

·DDS – DOCUMENTO DE DISCONTINUIDAD DEL SOFTWARE. Documento donde se planifica la discontinuidad parcial o total de un sistema.

Desarrollo: