Documentacion - Pequeña presentacion

Documentación de Sistemas
Cuando hablamos de Documentación de Software, estamos hablando de todos los documentos que abarcan la creación y el mantenimiento de un software, no solo de su creación, sino que cada modificación de la misma, deriva también a una modificación en la documentación, llámese nuevas políticas o nuevos procesos, los RFC (Ordenes de Cambios), también exigen una modificación en la parte documental del sistema.
La documentación no solo se basa en la idea o en la necesidad de crear un proceso o comprar un producto para que nos ayude o nos dé una solución a un problema dentro de la empresa.
La Documentación nos da el poder de saber los que hicimos a través del tiempo y estamos dejando una historial para futuros usuarios que manejarían o modificarían dicho software.
Haciendo esto se ganaría tiempo tanto en el desarrollo como en la educación de futuros usuarios ya que tendríamos creados manuales técnicos, manuales de usuario, manuales administrativos de sistema, manuales de contingencia.
Un Ejemplo: Cuando hay un problema en un proceso ,el programa hizo mal un cálculo y el desarrollador está de vacaciones, que hacemos, como sabemos que hizo , entramos al programa y miramos eso puede llevar horas para saber que exactamente hizo. No sería más fácil leer un manual de procesos en donde en un español entendible nos pueda explicar con facilidad que quería hacer ese proceso , así ganamos tiempo en saber que quería hacer y podemos corregir con más facilidad, eso es un ahorro de costo , energía y recurso que no se tiene en cuenta muchas veces.
Entonces debemos comenzar a ver la existencia de documentación, contratos, inicio de proyectos o proyectos finalizados.
Al saber que si existe documentación podemos tener muchas respuestas a las preguntas de los ejecutivos de la empresa, podemos también proyectarnos a futuro con una mejor línea de base.

• Plataforma en que estamos parados
• Procesos que corren diariamente, mensualmente o anualmente.
• Hardware
• Software
• Redes
 
Con esto nosotros sabemos cómo estamos y como estamos parado dentro de la empresa esto incluye (contratos, proyectos, contratos de soporte, además de lo anterior mencionado).

Para dar un ejemplo concreto, vemos un caso (que puede suceder).
Saber es si existe alguna documentación del Sistema en el que estamos trabajando, podemos hacer una consulta SQL que nos dieron para hacer, si buscamos ayuda pueden darnos varias respuestas:
• Que la gente antigua ya tiene en la cabeza el DER
Esto se debe a que el DER esta desactualizado pero existen las tablas con las que tenemos que trabajar.

• Tener un DER actualizado, hay que hacer un proceso de cierre de un producto, la idea es como lo hago, interesante seria si te dan un carpeta en donde están los procesos escritos en un español entendible con diagramas y procesos y mucho mejor aún si el mismo tiene un diccionario de datos, anexando esto un DER actualizado podemos ir preguntando menos así ahorrando tiempo de otros compañeros de trabajo en explicaciones.

• Y cuando no existe nada, salvo que se revise las tablas en el sistema y de ahí comience a trabajar.
Pasa lo mismo con los usuarios que utilizan el software fabricado, pasan días o semanas haciendo sombra a sus compañeros para ir preparándose para ser futuros usuarios, pero cuando están solos comienzan los llamados a centro de servicio (si es que la empresa tiene uno) o directamente al programador para ir preguntándole cosas que sería más útil si hubiese leído un manual antes.
Esto es pérdida de tiempo, para el programador, para el SM (Servicie Managament) ya que podrían estar enfocados en incidentes más importantes, antes de decirle que ese botón sirve para reversar la operación y le da ese mensaje de “Pedir Autorización”, porque en verdad debe pedir autorización, pero la segunda pregunta es “como”, que bueno sería si hubiese un manual de procedimiento o excepciones de los sistemas.
Si vemos desde el punto económico es gasto, gasto telefónico, gasto de tiempo tanto del programador como del usuario o sea un gasto de recurso.
 
Ahora vemos cómo se toma una pequeña aplicación, en que casi la mayoría de los “analistas-programadores” tiene que hacer.
1- Entrevistas con el propietario de datos
2- Tomar los Requerimientos
3- Diseñar un DER
4- Hacer los programas (colocar comentarios del autor , fecha, nombre del programa )
5- Probarlos con el propietario de datos (una ayuda en caso que necesite)
6- Poner en producción
7- Finalización del Proyecto

Cuáles son los primero problemas que tendríamos una vez puesta en marcha el sistema.
• Que el propietario al final no era eso lo que quería
• Si podemos modificar los listados
• Si podemos agregar más cosas a los formularios
• Faltan datos que es útil al propietario y no estaban estipulados desde un inicio.
 
Viendo de esta forma seria así:
La primera auditoria pasaríamos con éxito seguramente porque tenemos lo básico, inicio de proyecto, especificaciones, manuales y Diagrama de Entidad Relación.
Ahora si algo de esto no se hubiera hecho de entrada tendríamos muchos problemas con auditoria y peor aún si se hace el programa y el programador abandona la empresa por otro trabajo.
No solo hablamos de Auditoria, sino también de certificaciones y una forma de saber si podemos migrar a otra plataforma (esto puede darse por diferentes motivos).
Acá no se trata de tener el sistema funcionando correctamente y que haga lo que deba hacer y con el propietario de datos feliz.
Sino que además de eso tener un sistema totalmente documentado.
Cuando comienzan los pedidos de órdenes de cambios (RFC), porque las necesidades del negocio pueden ser cambiantes, ayer vendíamos autos hoy vendemos camiones, vendemos automotores no pero no es igual un camión que un auto ya que tienen atributos diferentes.
La finalidad es donde quedan representados estos cambios, donde queda explayado, donde está la persona que necesitaba que se cambie ciertos datos o modificaciones de procesos ya que no es compatible con el nuevo negocio.
Así que partamos de lo siguiente las personas cambian de trabajo pero los sistemas se quedan, si esto es así entonces la persona, que se va, tenemos que extraerle de su cerebro todo la mecánica y el funcionamiento del sistema porque no tenemos ni idea de cómo se hizo.
Entonces es ahí donde empieza la documentación:
La documentación empieza desde el inicio de la idea, desde la primera reunión con los interesados para crear una solución o un proceso nuevo dentro de la empresa o bien un producto para ser vendible o entregable.
Una vez que tengamos toda la idea, hablo de todos porque para el inicio del proyecto las reuniones deben hacerse con todos los interesados, para saber todo lo que se quiere.
Después se debe dejarlo por escrito y darle la responsabilidad del proyecto al propietario de datos.
También pude ser una OPM si es que la empresa tiene una. 
Para entrar en detalles sobre los entregables se presentan los siguientes puntos:

Manuales
Los manuales son las guías prácticas para entender que hace el sistema o también podemos decir, lo que tenemos en pantalla.
Se pueden definir diferentes manuales:
• Manuales de Usuario
• Manuales Administrativo
• Manuales Técnicos

Manuales de Usuario:
Como se hace un manual de usuario, es mejor dividir en diferentes faces
1. Presentación del Manual
2. Prólogo
3. Índice
4. Descripción de los Programas
5. Finalización del manual
6. Anexos
7. Políticas
8. Procesos
Esto va a depender del tipo de manual de usuario que va a hacerse, puede ser un manual muy nutrido debido a que el programa que está usando en un programa de cierre o que tiene muchas RFC en el transcurso del tiempo, en el cual están incluidas.
 

Presentación del Manual:
Como presentamos un manual, los manuales deben tener un título una breve descripción del sistema, va a depender si se manejan versiones del software también debe ir incluido en la presentación, en otros casos se encuentra en los anexos.
Prologo:
Breve descripción del software que estamos documentando, para que sirve, que hace, en que influye en los otros sistemas integrados en caso que exista.
Índice:
El índice es indicarle al usuario una guía rápida de la información que está buscando.
Descripción de los Programas:
La descripción de los programas, seria colocar una impresión de la pantalla que el usuario va a utilizar y el mismo una explicación de los datos que van a ser cargados y para qué sirven, esto sería mejor si los mismos se pueden dar una explicación a nivel del diccionario de datos.
Finalización del Manual:
Terminar el manual es darle fin a estos puntos , pero el manual puede seguir creciendo si se agregan nuevos menús o nuevas pantallas.
Anexos:
Pueden ser explicaciones más detalladas de ciertos puntos del sistema, también para agregar nuevas modificaciones dentro del sistema.
Políticas:
Los cambios surgidos por políticas, deben estar incluidos
Procesos:
Si el Sistema tiene procesos, pueden hacerlo escribiendo como se dijo anteriormente en un español legible para que otras personas no informáticas puedan saber, que exactamente hace ese proceso.

Manuales Administrativos:
Los manuales administrativos, son propios del sistema que se está documentando acá debe ir incluido en caso que tenga que ser administrado para dar autorizaciones o modificaciones de parámetros, es más para gente otro rango.
Debe ser igual al manual de usuario pero la explicación debe ser por qué va a cambiar algún dato, dentro de sistema en caso puede ser cambio de parámetro dentro del sistema.

Manuales Técnicos:
Los Manuales técnicos son para las instalaciones de los productos y que otras librerías necesitan para su instalación.
También contiene características de las PC que pueden soportar los programas y en que versiones de sistema operativos funcionan.
Son más complejos cuando esto es en Web ya que se necesita instalar diferentes productos para ir poniendo en producción el sistema.
Generalmente cuando se exporta se hace la instalación con alguna persona enviada por la empresa, pero este manual no debe faltar ya que en caso de que sufran algún problema esa empresa y por falta de recurso no tiene una contingencia adecuada pueden ellos con tranquilidad poder reinstalar el programa o los servicios que eso incluya con la ayuda del manual.