Re: [pyPYME-Giotto] Sgerencias y preguntas v0.1

[Jose <coo...@py...>]

El mi=E9, 06-07-2005 a las 01:31, Cesar Pablo Verdes escribi=F3:
> Cuando decis "para que los dem=E1s pod=E1is participar cuanto antes", =BF=
te
> refieres a codificar?

S=ED.

> Si =E9ste fuera el caso entiendo tu decisi=F3n, aunque suguiero en esta
> etapa trabajar en la documentaci=F3n del an=E1lisis a fin de no caer en
> codificar sin una guia (manteniendo la filosof=EDa de producci=F3n "Agi=
l"
> y como capas de cebolla, aclaro que no me refiero a al "Analisis" de
> RUPS ni nada por el estilo).

La forma de redactar los an=E1lisis ya est=E1 documentada.

Al tratarse de una metodolog=EDa "Agile" otorga mucha libertad en aras de
agilizar su redacci=F3n.

> A lo que me refiero es que por ejemplo, por lo que entiendo Marcelo
> est=E1 produciendo la parte de clientes, pero la documentaci=F3n del
> componente "Charon/Ficheros maestros/Clientes" est=E1 vacia (Marcelo po=
r
> favor no lo tomes a mal este comentario, lo pongo como ejemplo). =BFNo
> ser=EDa mejor documentar el an=E1lisis para que las personas que lo des=
een
> pueda opinar antes de ponerse a codificar componentes espec=EDficos?=20

Por una parte soy yo el que est=E1 desarrollando Charon. Marcelo est=E1
poniendo en pr=E1ctica lo que todos debemos hacer: participar en el
desarollo de los m=F3dulos de los dem=E1s.

En cuanto a lo de documentar el an=E1lisis antes de codificar, eso es lo
ideal y lo que se indica en la metodolog=EDa propuesta, pero en un mensaj=
e
anterior coment=E9 por qu=E9 no lo he cumplido en esta =FAltima parte del
proyecto.

De hecho la idea es:

   1. documentar un an=E1lisis
   2. dar una semana para comentar el an=E1lisis
   3. modificar el an=E1lisis para reflejar las conclusiones del punto 2
   4. codificar

> Estamos elaborando muchas cosas por mail que leemos solo los
> suscriptos a la lista, en vez, un an=E1lisis plasmado en la web lo pued=
e
> ver y opinar cualquiera, y a su vez atraer a mas colaboradores. Aclaro
> que yo en lo personal me vi atraido al proyecto por tu claridad de
> conceptos y organizaci=F3n que lograste trasmitir en el sitio
> /dev.pypyme.org/doc/
>=20
> =BFQue opinan?

La lista de correo no pretende sustituir la documentaci=F3n sino ayudar a
discutir y aclarar conceptos. Se trata de una herramienta para llegar a
un fin, que no es otro sino crear y documentar c=F3digo.

> > Lo que s=ED necesitaremos es idear una forma de correlacionar las
> > historias de usuario con los tests de aceptaci=F3n. Como no hemos mon=
tado
> > (ni nadie se ha asignado dicha tarea) la infraestructura necesaria pa=
ra
> > ejecutar tests de aceptaci=F3n, este tema ha quedado pospuesto.
> >  =20
> Suguiero como algo importante para luego simplificar el montaje de la
> infraestructura de tests de aceptaci=F3n, definir y utilizar una
> codificaci=F3n de las historias de usuario.
> Se me ocurre utilizar un c=F3digo como el siguiente:
>     HU-xxx-yyy-nnnn
>=20
> donde:
> - "HU" es la abreviaci=F3n de "historia de usuario"
> - xxx es una abreviaci=F3n del m=F3dulo... por ejemplo "THA", "CHA",
> "UMB", "POR", "OBE", "THE" y "ELA" (o cualquier otra que Uds.
> sugieran).
> - yyy es una codificaci=F3n del componente... por ejemplo "PYC" para
> PyContainer "adaptado" de Thalassa.
> - nnnn es un n=FAmero correlativo de Historias de usuario.
>=20
> En la documentaci=F3n espec=EDfica del componente bastar=EDa solo con
> numerarlos, pero se deber=EDa utilizar el c=F3digo completo cuando se
> refiere desde otro sitio de la documentaci=F3n.
>=20
> Siguiendo el mismo razonamiento tal vez sea bueno codificar y enumerar
> todo a medida que se va produciendo para facilitar su futura
> identificaci=F3n. Por ejemplo podemos utiliar los siguientes prefijos:
> - "RO": Roles
> - "HE": Historias =E9picas
> - "TA": Tests de acptaci=F3n
>=20
> =BFLes parece conveniente?

La metodolog=EDa basada en historias de usuario no precisa codificaci=F3n
alguna. Tan s=F3lo necesitaremos codificar las historias de usuario para
poderlas relacionar con los tests de aceptaci=F3n correspondientes.

Por otra parte, la codificaci=F3n que propones para las historias de
usuario me parece buena.

> > > > 4) =BFHay alg=FAn componente espec=EDfico encargado de la "docume=
ntaci=F3n del
> > > > usuario"? Tal vez lo pensaron como una funcionalidad de cada
> > > > componente... pero =BFno deber=EDa haber en Charon un componente =
espec=EDfico
> > > > que preste servicios de busqueda, indesaxion, etc?
> > > >      =20
> > > Creo que faltaria ese modulo...
> > > Pense en en un componente separado de charon... digamos "manual" , =
que
> > > imitando a deploy para armar los menus dinamicos... busque en cada
> > > modulo... (charon, portia...) un componente "manual" especifico de
> > > cada uno... y lo agregue como un "grupo" independiente...
> > >=20
> > > Visualmente quedaria una barra de menus...
> > >=20
> > > - charon - portia - manual
> > >                              I
> > >                              I- manual comun
> > >                              L manual charon
> > >                              L manual portia
> > >=20
> > > obviamente... en lugar de charon dira tablas generales, en lugar de
> > > portia  tesoreria... etc...
> > >=20
> > > esto permitiria que deacuerdo a la configuracion de modulos que se
> > > carguen, el manual acompa=F1e a cada uno... dinamicamente...
> > >    =20
> > A pesar de lo que muchos digan yo creo que no podemos documentar el u=
so
> > de una herramienta hasta que no dispongamos de ella. Por ello, y aun
> > valor=E1ndola como un requisito imprescindible, no he prestado mucha
> > atenci=F3n al tema de la documentaci=F3n de usuario.
> >=20
> > Creo que es algo que podemos dejar para m=E1s adelante, para cuando
> > dispongamos de la v1.0.
> >=20
> > Marcelo: no estoy seguro de si C=E9sar se refiere a c=F3mo integrar l=
a
> > documentaci=F3n de usuario o a otra cosa. En cualquier caso queda
> > registrada tu idea 8-).
> >  =20
> Totalmente de acuerdo. No tiene sentido documentar la ayuda ahora, me
> refer=EDa al enfoque de Marcelo... un componente o m=F3dulo que utiliza=
ndo
> servicios de los compontes arme la ayuda para el usuario
> (independientemente de texto de la ayuda, o ayuda sobre que tema).=20
> Por ejemplo, la vista que est=E1 usando el programa tiene campos de
> ingreso de datos, por lo tanto los controladores podr=EDan informar al
> componente "ayuda" un texto descriptivo sobre que espera el sistema
> que el usuario ingrese en cada lugar. A su vez cada vista tiene una
> funci=F3n dentro de una tarea de un flujo de trabajo. La vista tambien
> podria registrar informaci=F3n en el componente "ayuda".
> Es solo para dejar registrada la idea a nivel an=E1lisis de servicios d=
e
> componentes (no de documentaci=F3n espec=EDfica)... tal vez no sea mome=
nto
> para preocuparse por =E9sto.

Es un tema que habr=E1 que tratar. S=F3lo que no creo que sea el momento.

> > > > 5) Desde que trabaj=E9 con SAP me ha obsecionado el dise=F1o de i=
nterfaz de
> > > > usuario de los sistemas y he estudiado bastante sobre el tema. Al=
g=FAn d=EDa
> > > > me gustar=EDa conversar sobre el tema (tal vez sobre la base de e=
scribir
> > > > un documento de sugerencias espec=EDficas).
> > > > Tras leer el apartado de "Interfaz de usuario" de la documentaci=F3=
n me
> > > > surgen muchas ideas/sugerencias. Posiblemente en este momento del
> > > > proyecto sea conveniente dise=F1ar e implementar una interfaz b=E1=
sica como
> > > > la planteada... o tal vez sea conveniente profundizar en su an=E1=
lisis
> > > > inicial. =BFCual es tu opini=F3n?
> > > > Pongo a tu disposici=F3n mi tiempo, si lo consideras conveniente,=
 para
> > > > trabajar en esta =E1rea a fin de realizar un An=E1lisis mas detal=
lado con
> > > > visi=F3n de futuro de la interfaz de usuario de pyPYME.
> > > >      =20
> > Creo que a todos nos gustar=EDa disponer del documento del que hablas=
, con
> > tus propuestas y sugerencias. Lo adjuntar=EDamos a la documentaci=F3n
> > t=E9cnica y as=ED podr=EDamos iniciar una conversaci=F3n acerca de si=
 incluir o
> > no algunas (o todas) tus ideas.
> >  =20
> Ma=F1ana mismo comienzo a trabajar en =E9sto! Si les parece bien
> diariamente ir=E9 presentando los progresos en la documentaci=F3n.
> Tal vez convenga hacerlo por mail para ver si vale la pena incluir las
> ideas o no... de decidir incluirlas, pasar=EDa a trabajar documentar
> sobre la Web (con tu permiso obviamente).

Me parece bien.

> > > > =BFQue te parece m=E1s conveniente para el proyecto?... que dediq=
ue un
> > > > tiempo a realizar un an=E1lisis m=E1s global de la interfaz del u=
suario (el
> > > > menos en lo referente a Historias =E9picas, Composici=F3n, Histor=
ias de
> > > > usuario, Test de aceptaci=F3n, etc) o que comience con el an=E1li=
sis del
> > > > M=F3dulo Contable paralelamente a la lectura y estudio del c=F3di=
go ya
> > > > programado?
> > > >      =20
> > Perdona pero no acabo de entender la relaci=F3n entre el an=E1lisis d=
el
> > interfaz de usuario y la metodolog=EDa de desarrollo. =BFMe puedes de=
tallar
> > un poco m=E1s este p=E1rrafo?
> >  =20
> Mi pregunta era para consultarte como "coordinador" del proyecto sobre
> tu parecer sobre que es m=E1s =FAtil en este momento. Por raz=F3n de
> disponibilidad de tiempo no puedo hacer ambas cosas simultaneamente.
> Si est=E1n de acuerdo y dado el inter=E9s en el tema de interfaz de
> usuarios presentado en el mail de Patricio y el tuyo, me dedicar=E9 a
> plasmar en palabras todos los conceptos y sugerencias sobre interfaz
> de usuarios, dejando para m=E1s tarde el an=E1lisis del m=F3dulo contab=
le.

Ok.

Jose