[Php-objetos] Lecturas para el fin de semana

Dom Mar 29 22:44:00 ART 2009

Hola Gerardo!

El dom, 29-03-2009 a las 13:16 -0300, Gerardo Valiani escribió:
> Me parece bastante interesante. Y veo que las epecificaciones estan
> armadas diferentes. Empiezan primero con el sistema desde el punto de
> vista del usuario. Con ejemplos de uso y pantallas de la vista. Desde
> mi punto de vista me resulta mucho mas comodo ver de que trata el
> sistema que una lista de "El sistema debe". No digo que esta lista no
> sirva. Sino que no deben estar al principio. Primero explicame en
> criollo que queres que haga el sistema. 

	El artículo es motivador de por qué hay que escribir especificaciones.
	Las especificaciones tienen muchos destinatarios: el cliente, los de
marketing, los gerentes, los de contabilidad, los programadores, los de
testeo, etc.
	Sin embargo, si bien una especificación con casos de uso (que son las
cosas desde el punto de vista del usuario) es más rica, los diseñadores
se quedan solo con la parte técnica y los programadores con los "el
sistema debe".
	Estoy absolutamente convencido que que las especificaciones de
FoogCreek son mucho más formales.
	También pasa que ellos fabrican soft enlatado, con lo que no tienen a
un cliente que les diga el grueso del qué hacer, sino que tienen que
inventarlo ellos: pero esto necesitan la riqueza expresiva de los casos
de uso y estereotipan al usuario.

> Y despues vemos como lo armamos.

	Esto es diseño.
	Si no tenés los "el sistema debe" es imposible diseñar.
	Confundir lo que el usuario hace con el sistema con lo que el sistema
debe hacer te hace ir a parar los caños. No hay vuelta.

> Creo que eso fue lo que demoro detectar que mi tesis no tenia
> comportamiento. Nunca explique realmente que quiero hacer por abocar
> mis pensamientos en "El sistema debe".

	Pero Gerardo! Fijate que para lo que querías hacer de D&D podés
plantear todo lo que Joel dice, pero solo cuando lo vayas a expresar en
términos de "el sistema debe" es cuando te das cuenta de que no hay
comportamiento!

> Los articulos me aclararon un poco el panorama!

	Me alegra!
	Esa es la idea!

	Sin embargo, por favor, no saques las moralejas equivocadas.
	Viste la fábula de la cigarra y la hormiga? Bueno, uno podría sacar
también que la moraleja es "la cigarra necesitaba un mejor
representante".
	Las moralejas de estos entretenidos y útiles artículos son: escribir
requerimientos es importantísimo, y los requerimientos son un documento
que está "vivo" mientras se construye el software.

	Para ponerse formales, hay un estándar de Especificación de
Requerimientos del Software (SRS), que es el IEEE 830.
	Las empresas trabajan con este estándar, y si el desarrollo es interno
(sin cliente externo) a veces lo hacen más informal o más entretenido.
	Una SRS según IEEE 830 tiene que ser:
* Correcto
* No ambiguo
* Completo
* Consistente
* Ordenado con base en importancia y/o estabilidad
* Verificable
* Modificable
* Rastreable

	Después, de todas las partes que tiene una SRS, solo les estoy pidiendo
y no rigurosamente los requerimientos funcionales, que son los que el
sistema debe implementar directamente y lo que el diseño no puede no
tener.

	Pensar en Miss Peggy me ayuda a entender el sistema, pero me perjudica
a la hora de diseñarlo. Son dos etapas distintas.
	Cómo acá el "cliente" son Uds mismos, creo que podemos dar por sentado
que entienden la naturaleza del problema que van a resolver. Si damos
por sentado esto, Miss Peggy deja mayormente de hacernos falta.

	Ahora que con estos articulitos ilustré por qué escribir requerimientos
es muy bueno, acá les dejo una breve guía de cómo escribirlos siguiendo
la única norma que hay
http://iteso.mx/~juanjo/IEEE_Std1233_1998_esp_desarrollo_de_especificacion_de_reque.pdf

	Cómo siempre, después de aprenderse bien las reglas y tener experiencia
jugando el juego, son bienvenidos a hacer trampas!!!

> Saludos!

	=mente!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key