Documentacion de Software II

Pequeño resumen de Documentacion de Software , espero que les ayude
----------------------------------------------------------------------------------------------------------
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
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.

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.