Documentando Software – parte II

Documentación de Sistemas

Bien continuamos con la documentación de sistemas, ahora si pensamos que importante es la documentación, también deberíamos pensar en que importante es mantener un estándar.

Si vamos a generar manuales, procedimientos o procesos mantengamos siempre un estándar, si usamos una forma de documentar usemos siempre la misma.

Java tiene su documentación (java doc) además introduce el CamelCase para poder comprender mejor aún el código de programación.

Ahora de Parte del programador, debería escribir la definición de su programa, fecha, versión, es un buen comienzo para comenzar a tener documentado el código.

Esto también es ahorro. Ahorro de tiempo y de dinero.

Los que dicen que no se documenta tanto en #agiles, no es tan “así” porque depende de la Naturaleza de la empresa, las empresas que hacen ventas en línea o que bien hacen ventas de consumo no tienen los mismos niveles de compromiso que las empresas financieras.

Todo va a depender de la entidad controladora que tipo de documentación requiere para su auditoria.

Y es ahí la diferencia, las metodologías ágiles si bien uno de sus puntos es la documentación básica, y como escribí un poco más arriba no es tan así dependiendo de los factores Gubernamentales, Leyes de Gobiernos.

Anuncios

2 pensamientos en “Documentando Software – parte II

  1. alefq

    Interesante artículo Andy, para continuar te recomiendo que pienses en estos escenarios:
    1) El software certifica para CMMI nivel 3, pasa todas las auditorías y tiene “todo” el sistema documentado para la foto, pero nadie lo usa.
    2) El sistema se construye en base a historia de usuarios, con metodologías ágiles escuchando y haciendo participar al usuario y al sponsor, y todos lo usan y hablan bien de él.
    Hay una diferencia entre el sponsor y el usuario. El primero firma los cheques, y el segundo es quién usa el sistema.
    El estado paraguayo está plagado de sistemas que no se usan, algunos cuyas licitaciones exigían empresas certificadas CMMI. Es sencillamente una locura intentar hacer un proyecto CMMI para un equipo de menos de 10 personas. Lo que documentes, al mes de desarrollo quedó obsoleto.
    Yo opino que no tiene sentido documentar demasiado un sistema, mientras se está construyendo. Para eso podrás contratar después gente que se dedique exclusivamente a eso, pero no antes de que el sistema entre en una fase de mantenimiento.
    La pregunta clave que tenés que hacerte es ¿Construís sistemas para que se usen o para satisfacer al sponsor?
    “No tengas miedo de inventar tu propio ciclo de vida del software que se adecue a tu realidad. El ciclo de vida _perfecto_, es un modelo, tu vive en el mundo real.” (Gracias @johannarothman).

    Me gusta

    Responder
    1. Andy Autor de la entrada

      Justamente queria hablar sobre escenarios, es un tema complejo no sencillo, pero ademas lo que decis en entorno a la documentacion es algo que es cierto , todo es para el paquete de auditoria y depues chau !!! asi mismo
      pero justamente es muy importante ver en terminos de mejora de proceso ademas del manteniento de documentación)
      Gracias por el feedback un abrazo.

      Me gusta

      Responder

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s