Queridos 2 lectores
Aqui regresando a poner un post (por fin!!!), entre influenza, chamba, etc etc. habia abandonado escribir...bien pues entremos en materia.
En estos dias he estado involucrado en unos cursos/talleres de un modelo que usamos en el trabajo llamado MOSASA, el cual combina muchos de los marcos de referencia de la industria tales como, PMBOK, RUP, CMMI-DEV, CMMI-ADQ, ITIL basicamente.
El dia de hoy me toco el track de "Administracion de Requerimientos de Software", en el cual estamos viendo las tareas que involucra este proceso, desde que estas entendiendo "lo que el cliente desea" hasta que se especifican en papel o en alguna herramienta, todos esos requerimientos.
En el transcurso del taller se genero una pregunta "¿porque es importante los requerimientos no funcionales?" en la cual los del equipo de arquitectura empezamos a sacar todos nuestros traumas...
A lo largo de N proyectos que hemos estado trabajando, nos hemos dado cuenta que muchos equipos de desarrollo no toman en cuenta este tipo de requerimientos, lo que ocasiona que se den por obvio que el sistema va a hacer maravillas... problemas que me ha tocado vivir por mencionar algunos son: Sistemas que no soportan los volumnes operacionales, saturacion de red por el uso del sistema, Requerimientos de seguridad no contemplados, Sistemas que no son escalables.. etc etc etc.
Aqui lo interesante es definir un requerimiento NO funcional... podemos consultar multiples fuentes para definirlo, aqui compartire parte de lo que he visto que nos ha ayudado a conocer las espectativas no funcionales del usuario que influyen directamente en la arquitetura del sistema:
- Volumenes: Datos interesantes son cuantos usuarios trabajaran con el sistema, 10, 10,000, 1 millon,...
- Horarios de mayor demanda: Dias picos de operacion, por ejemplo "la recaudacion que debe de recibir el seguro social es cada 17 de cada mes, dia en el cual se reciben 300,000 patrones..." como buen mexicano, lo haremos hasta el mero dia... y este requerimiento influye a la arquitectura para ver como soportar esa carga.
- Manejo de megadatos: procesamientos Batch de 10,000 registros, o de millones. Dependiendo de el dato, la arquitectura cambia.
- Volumenes a transmitir de informacion: esto influye directamente en nuestro ancho de banda, si lo que vamos a transmitir puede llegar a saturar, asi mismo si el sistema sera en nuestra intranet o va a ser trabajado desde Internet.
Para mayor detalle consulten la siguiente liga http://www.ibm.com/developerworks/rational/library/4710.html
Todo lo anterior afecta directamente a la arquitecrtura y solucion de nuestro sistema, desde el hardware hasta el software.
Espero que compartan algunas experiencias que han vivido similares a las que les he platicado..
Bueno los dejo.
"Por una cultura del desarrollo de software"
Chao
Tuzo
Tuesday, May 26, 2009
Subscribe to:
Posts (Atom)