Documentaciones de software

A veces creamos un montón de programas pero nunca dejamos rastros de lo que hicimos , salvo que comentemos
dentro de nuestro programa.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de Sr. Negativo

Documentación de software

No todo lo que escribimos es Software. Por ejemplo clásico "Hola mundo" no es un software, es un simple programa. Un script tampoco es un software. Son unas líneas de código más simples que un programa.

No necesariamente debemos documentarlo todo (a veces basta con unas simples líneas para entender que hace).

El software es más complejo y a veces no basta un solo programador para desarrollarlo. Una de las alternativas para documentarlo es UML aunque creo causa más problemas.

Algunas consultorías manejan una especie de bitácoras en las que se describen los problemas y las soluciones de los proyectos que han desarrollado (y lo manejan como "documentación del software"). A veces ni eso tienen.

Pues mal hecho. Pero de ser

Pues mal hecho. Pero de ser así asegurate que el software sea fácil de usar/mantener/entender/modificar.

Un software que funciona muy bien, no necesita mucha documentación ( pero si necesita que conste ).

Algo peor que no tener un software documentado, es tener un mal software no documentado y que sea difícil de usar/mantener/entender/modificar.

( see algo the agile manifiesto http://agilemanifesto.org/ )

:)

Imagen de neko069

UML malo?

Porqué UML causa más problemas?

Imagen de bferro

UML no causa problema alguno

Ningún lenguaje de modelación causa problemas, si ese lenguaje se sabe usar.

Imagen de javamx

Documentacion del Software

Documentar un software bueno es todo un proyecto que es administrado y que ha pasado por un ciclo de desarrollo del mismo, utilizando modelos de desarrollo como (RUP, PROCESO UNIFICIADO, PROTOTIPOS, PROGRAMACION EXTREMA (OTROS LO DENOMINAN AL (A LO TONTO)) , y utilzando UML (lenguaje modelado unificado, te recomiendo que indages sobre eso ) , aparte en si se ve lo que es Calidad del Software (caja negra, blanca, pruebas unitarias (dependiendo de que lenguaje de programacion utilizes varia su forma de utilizacion) y pues tambien se lleva acabo control del tiempo como cronogramas, una EDT(estructura de desglose de trabajo) y aproximaciones de costos del proyecto del software que siempre se utilizan dos que es Puntos de Funcion y COCOMO 2 (basico , intermedio y avanzado) , bueno teniendo en cuenta todo esto y entre muchos aspectos el software lo realiza un equipo de trabajo que en si trabajan colaborativamente, organizativamente, con calidad tambien puedes indagar sobre CMMI que es un modelo que utilizan las empresas para poder desarrollar su software a la medida y tambien Six Sigma.

En si todo esto es documentacion del software entre otras cosas que se me escapan ya que tienes que documentar sea poniendo comentarios en tu programacion, tambien casos de uso, diragrama de clases , modelo entidad relacion en si.... es mucho muchoo personas involucradas o interesadas mejor conocidas como DBA's , programadores , diseñadores , testers, analistas, etc., dependiendo que tipo de proyectos aveces una persona puede hacer dos o mas cosas dependiendo de la capacidad de la empresa y proyecto .... buenoooo todo eso es documentacionn de software.. si

aunque seas novato digo si es que te recomiendo que te hagas de libros y que le heches una leida a este Guía de los
Fundamentos de la Dirección de Proyectos tercera edicion mejor conocido como (Guia el PMBOK)

lo siento si se me barre la ortografia jxD es ke me entere lo de la SOPA

Imagen de ezamudio

six sigma jaj

Críticas de Six Sigma y el legendario comentario en Dilbert:

Six Sigma

Imagen de Andres villamayor

Documentacion

Fantastico lo que me decis, yo queria continuar con esto porque ademas del inicio de proyecto(PMP) ya incluye una documentacion que es el inicio de proyecto ( llamemos proyecto a un nuevo sistema) , la docuementacion de software para mi punto de vista es esencial si es que vemos que las compañias se quedan pero la gente va rotando y en muchas auditorias que tuve en mi vida , esto fue alo que me llevo ver y relevar muchos aconteciemientos del software ...
Si nos ponemos a pensar cuantas RFC no fueron documentadas porque el cambio solo fue el color del fonde del formulario, vemos que las politicas internas de la empresa no estan bien definidas.
Tal vez soy medio poetico en esto y me puden dar con un palo y acepto, pero desde mi punto de vista
tanto la programacion - el servicio - y la documentacion de todo esto debe ir junto , yo escribi algo en blog , lastimosamente no esta voy a colocar de nuevo, porque en verdad yo como programador, analista, jefe de proyecto otras cosas, vi la necesida constante de autorizaciones y documentaciones de procesos. UML es una metodologia , pero tambien escribir en un word en un español entendible de los procesos es tambien una buena practica.
Si vemos del lado ITIL se utiliza mucho ITSM y SM para lograr que tanto los incidentes y las ordenes de cambios sean guardadas para futuras auditorias..
Yo creo que si tenemos un software bien documentado,esto pensando que el software funciona correctamente podemos llegar a los ISO, y llegar a los Standares podemos tener salida a los mercados que piden cada dia mas maduracion de software.
Es mi punto de vista .. Gracias por compartir este pensamiento

Si se necesita, pero hay que hacerlo bien.

Sí es importante la documentación, no solo si hay gente rotando, sino para la existencia del software mismo, especialmente cuando se construye para alguien más, hay que en la mayoría de los casos, sobre todo en el ámbito empresarial el software es solicitado por un área usuaria, con ciertos requerimientos y el seguimiento del proyecto debe de hacerse a través de documentación por la PMO. Sin embargo hay veces que se da demasiado énfasis en la documentación y se toma más tiempo que el desarrollo mismo de la solución. Esto es particularmente cierto cuando quién va a desarrollar no sabe que es lo que tiene que hacer o como va a hacerlo ( consultorías que dicen que saben algo y realmente lo desconocen ) y se pasan el tiempo haciendo manuales, arquitecturas y demás.

La documentación debe de ser concisa y completa. No documentar de más ni dar rodeos solo para llenar los manuales. Si solo hay una hoja eso es lo que debería de conservarse y debe de ser actualizada conforme el sofwate va siendo construido.

La mayoría de las metodologías o .. disciplinas tienen un número tremendo de documentos a llenar, particularmente en consultorías grandes, estos documentos son muy útiles y es importante conocerlos especialmente para proyectos grandes, pero más importante aún es tener un Gerente de Proyecto con experiencia en desarrollo ( creo que aquí es donde muchos proyectos fallan ) y que sepa como adaptar la metodología a las necesidades del proyecto y sabes que de 60 documentos el proyecto solo necesita 10, claro esta es una decisión en la que debe de tener apoyo del Lider de Desarrollo y el Arquitecto de Solución.

Una vez identificados los documentos a entregar y aclarado con el cliente, yo he visto que funciona muy bien hacer una redacción muy sencilla y así todo entienden la documentación, los desarrolladores pueden tener actualizado el producto y en vez de quitarles el tiempo, les permite tener sincronía con el proceso. De nuevo el gerente de proyectos o el líder de desarrollo deben de ser capaces de identificar que documentación es útil y cual otra no aplica para el proyecto.

Lo ideal ( que aún no he visto que suceda ) es que además se utilizarán formatos de texto de marcación ligeros, como MarkDown por ejemplo sería genial, así no hay que batallar con words, imagenes, visio, porwerpoints ni nada de eso.

En resumen, la documetanción si es necesaria, pero debe de ser solo la que el proyecto de software requiera y no irse por todos los documentos que una metodología puede estar sugiriendo pues todas indican claramente que las primeras actividades es adaptar la metodología al proyecto.

De esta forma se obtendrá el máximo beneficio, para el equipo de desarrollo al no invertir tiempo extra y estress por no sabes como llenar un documento, la gerencia del proyecto y el cliente porque obtendrá un estado real del proyecto y el usuario final que podrá usar lo que pidió que es finalmente lo que interesa.

Imagen de bferro

UML NO es una metodología

Por ahí Andres villamayor comenta que UML es una metodología.
UML NO es una metodología; es un lenguaje de modelación que puede ser usado por muchos métodos y técnicas para diseñar y construir software.

Imagen de Andres villamayor

Es cierto !!! bferro

Es cierto perdon, uml en un lenguaje de modelacion.
Yo practicamente uso solo, los casos de uso , no hago ni digramas de colaboracion ni todo eso, Utilizo y Escribio los procesos imprimir pantallas , revisar los DER para poder explicar en manuales tanto de usuarios como en manuales administrativos manteniendome dentro del diccionario de datos para ver los requerimientos y asi para poder darle una ayuda directa al usuario en su manual. Esto a nivel de usuario

A nivel de programacion la documentacion del programador es diferente.
Gracias bferro por la acotacion y aclaracion .. agradecido

Imagen de Andres villamayor

Hola Oscar Ryz no soy

Hola Oscar Ryz no soy colombiano , soy paraguayo pero hize manuales de sistemas para CelCaribe en su momento alla por el año 2000 ..
Saludos

Corregido el post entonces.

Corregido el post entonces.

Imagen de Sr. Negativo

Re:UML malo?

Me refería a que muchas veces no lo sabemos usar (como lo dice el Sr. bferro). Depende también para que lo uses, por ejemplo el diagrama de clases es común utilizarlo primero para tener una descripción más o menos detallada de lo que vas a desarrollar.

:)