Hola a todos. Aprovecho para recordar por si alguien tiene la duda, de que hasta mañana 31 de enero de 2013, todavía se puede comprar Windows 8 original y directamente desde la web de Microsoft, por menos de 30 euros. Ya hablé recientemente en una entrada anterior, así que no le daremos más vueltas.
Tú decides.
miércoles, 30 de enero de 2013
viernes, 25 de enero de 2013
ISO 20.000 - Introducción
Recientemente me han preguntado por la ISO 20.000, y me he visto obligado a revisarla y explorar sus posibilidades. Hoy voy a presentar una introducción, que espero ampliar en próximos posts.
La ISO 20.000 es una norma muy vinculada al estándar ITIL. Ambas tratan sobre la administración de servicios de TI en una organización, independientemente de su tamaño o rama de la industria.
En el caso de aplicarla a las áreas de Tecnología de Información y Sistemas (TI), está orientada a:
Tomando como referencia ITIL, el Instituto Británico de Estándares (BSI) definió la norma BS 15000, a partir de la cual, posteriormente se definió la ISO/IEC 20000:2005.
Al igual que otros estándares ISO, consta de dos partes:
La ISO 20.000 es una norma muy vinculada al estándar ITIL. Ambas tratan sobre la administración de servicios de TI en una organización, independientemente de su tamaño o rama de la industria.
En el caso de aplicarla a las áreas de Tecnología de Información y Sistemas (TI), está orientada a:
- Definición y operación de servicios
- Formalización de ANS (Acuerdos de Nivel de Servicio) con clientes
- Definición de modelos de costes
Tomando como referencia ITIL, el Instituto Británico de Estándares (BSI) definió la norma BS 15000, a partir de la cual, posteriormente se definió la ISO/IEC 20000:2005.
Al igual que otros estándares ISO, consta de dos partes:
- la primera, que es obligatoria y certificable (se puede evaluar el cumplimiento con el estándar)
- la segunda, que es un conjunto de sugerencias sobre la primera parte.
- Orientación a alinear los servicios de TI con los requisitos de negocio.
- Establece procesos de mejora continua de la calidad en la gestión de los servicios de TI tanto a clientes internos como externos de la compañía.
- Identificación de los niveles de servicio (ANS) solicitados a TI.
- Posibilidad de comparar los costes de TI (benchmarking) con estándares.
- Posibilidad de certificar a la empresa, además de a los empleados (al contrario que con ITIL, que sólo certifica a personas).
- Permite aprovechar los esfuerzos ya realizados en la certificáción de otra norma ISO, ya que el marco de administración del estándar se aprovecha al 100%.
- Los proveedores de servicios de TI responden mejor a los servicios regidos por aspectos comerciales que a los impulsados por la tecnología.
- Los proveedores de servicios externos pueden utilizar la certificación como elemento diferencial y ampliar el negocio, ya que ésta se está convirtiendo cada vez más en un requisito contractual.
- Ofrece la posibilidad de seleccionar y gestionar a los proveedores de servicios externos con mayor eficacia.
- Requisitos para la gestión de un sistema.
- Implantación y planificación de Gestión de Servicios.
- Planificación e implantación de servicios nuevos o modificados.
- Procesos del servicio de entrega.
- Procesos relacionales.
- Procesos de control.
- Procesos de emisión.
jueves, 24 de enero de 2013
Toma de Requisitos - Paso 9: Requisitos no funcionales
Toma de Requisitos - Paso 9: Requisitos no funcionales
Las tareas realizadas en los Pasos 1 a 8 nos han permitido solventar proyectos basados principalmente en interfaz, proyectos más bien pequeños.
Sin embargo, siempre tendremos funcionalidades necesarias pero difíciles de plasmar en un prototipo o en un manual de usuario: los requisitos no funcionales. Aquí podemos encontrar entre otros:
¿Hay que hacer un documento con todo esto? Pues no del todo. Lo que hay que hacer es recopilar esta información para que no se pierda, y esto puede hacerse en varios sitios (seamos ágiles):
Como ya creo haber comentado en algún otro post anterior, estaría relacionado con la metodología UIDD (o User Interface Driven Development), donde lo primero que se hace es la interfaz, y se va propagando el desarrollo a otras capas o partes del sistema. Ojo, no significa esto que la interfaz esté cerrada. Recordad que la realidad siempre estará en contra nuestra, y lo más probable que cambie...sea lo más estable y asentado que tengamos. Gracias Sr. Murphy por tu ley.
Hoy vamos a finalizar esta serie de artículos sobre la toma de requisitos (algunos suspiraréis de alivio), explicando el último paso: la documentación de requisitos no funcionales.
Esta entrada forma parte de una serie cuyo índice es el siguiente:
- Identificación de usuarios finales clave.
- Entrevista a dichos usuarios finales.
- Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
- Presentación del prototipo a los usuarios finales, solicitando feedback.
- Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
- Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
- Utilizar el prototipo como la primera línea de base de los requisitos.
- Escribir una documentación de usuario detallada, basada en el prototipo anterior.
- Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Las tareas realizadas en los Pasos 1 a 8 nos han permitido solventar proyectos basados principalmente en interfaz, proyectos más bien pequeños.
Sin embargo, siempre tendremos funcionalidades necesarias pero difíciles de plasmar en un prototipo o en un manual de usuario: los requisitos no funcionales. Aquí podemos encontrar entre otros:
- Velocidad de acceso a la aplicación, o tiempos de respuesta.
- Uso de memoria.
- Interfaz con el sistema operativo o con otros sistemas (tanto hardware como software).
- Algoritmos detallados con reglas internas de comportamiento (reglas de negocio).
¿Hay que hacer un documento con todo esto? Pues no del todo. Lo que hay que hacer es recopilar esta información para que no se pierda, y esto puede hacerse en varios sitios (seamos ágiles):
- Como un anexo del manual de usuario
- Como notas en una pizarra o post-its en la pared (que alguien se acuerde de hacerle una foto, antes de que se los lleve el viento!!)
- Etc.
- Revisar: siempre viene bien, 4 ojos ven más que 2. Si programar entre pares produce buen código...¿porqué no revisar más de una persona los documentos?
- Línea base: hay que dejar claro un punto de partida. Difícilmente sabremos llegar a ningún sitio si no tenemos claro cuál era nuestro punto de origen.
- Control de cambios. No pongáis la cara que suelen poner la gente en mis proyectos cuando les cuento esto. Control de cambios podría ser hacer una foto nueva a la pizarra cada vez que cambiamos los post-it, o guardar el documento en subversion y guardar una nueva versión cada vez que lo modificamos.
Como ya creo haber comentado en algún otro post anterior, estaría relacionado con la metodología UIDD (o User Interface Driven Development), donde lo primero que se hace es la interfaz, y se va propagando el desarrollo a otras capas o partes del sistema. Ojo, no significa esto que la interfaz esté cerrada. Recordad que la realidad siempre estará en contra nuestra, y lo más probable que cambie...sea lo más estable y asentado que tengamos. Gracias Sr. Murphy por tu ley.
martes, 22 de enero de 2013
Toma de Requisitos - Paso 8: Escribir documentacion de usuario
Toma de Requisitos - Paso 8: Escribir documentación de usuario
Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 8: escribiendo una documentación de usuario detallada, basada en el prototipo que completamos enel paso 6 y que establecimos en el paso 7 como línea base de los requisitos.
Esta entrada forma parte de una serie:
Una vez tenemos cerrado el prototipo, es importante cerrar también, lo antes posible, una documentación de usuario (requisitos, manual de usuario, etc).
Muchos pensaréis: "venga ya. ¿ahora vamos a documentar? ¿No basta con el código?". De esto ya hemos hablado en otros posts: "Nos gusta programar pero no documentar". Hay varios motivos para hacerlo:
Bueno. Sigamos. Aunque normalmente se documenta al final, en nuestra aproximación, lo haremos al principio. ¿Porqué? Pues porque estamos haciendo una toma de requisitos, y la mejor forma de hacerlo es dejando los documentos por adelantado.
Es más fácil para el equipo de desarrollo consultar el manual a la hora de hacer unas pruebas, o de avanzar el desarrollo, que cualquier otra cosa. Quizá el usuario no se lea el manual, pero al menos los programadores y los testers sí deberían estar hartos de leerlo. Probablemente el usuario no se lo lee porque los manuales que solemos hacer son siempre "fuera de hora": los hacemos en ese tiempo que hay al final del proyecto, y porque nos obligan, y siempre es en horas muertas, o cuando ya estamos reventados de intentar sacar adelante una funcionalidad que ya va retrasada. Por cierto, esa funcionalidad tal vez no estaría retrasada si no hubiéramos tenido que rehacer 20 veces el producto...y eso ocurría (tal vez), si nos hubiéramos molestado en hacer un manual de usuario al principio (como aquí planteo).
Otra ventaja de hacer la documentación y manuales al principio, evita tener que hacer una especificación técnica detallada. Ya se indica cómo debe funcionar todo, ya están los requisitos...¡pues a programar!
El cliente y usuarios finales entenderán mucho mejor un manual, y seguro que si es el mismo que usan (y revisan y corrigen) los programadores en el día a día, será un manual útil, y no el típico ladrillo que se suele hacer y que nadie lee.
El tener una documentación completa tan temprano, pule aún más posibles inconsistencias y puntos "oscuros" que pudieran haber quedado en nuestro prototipo. Se evitan muchas veces el tener documentos demasiado técnicos. En su lugar, se está haciendo una documentación basada en el uso, en la funcionalidad, no en la tecnología.
Este tipo de documentación, se va a mantener y a actualizar, mucho mejor que cualquier otro tipo de documento. Puesto que es algo que todo el mundo usa y necesita tenerlo al día: los usuarios finales, los programadores, los analistas, los testers...es como el anillo de la película del señor de los anillos: "un documento para unirlos a todos...".
Este tipo de documento es práctico, sin rollos que pretendan artificialmente hacerlo ameno, o inteligente, o complejo. Dice lo que el usuario necesita que el software haga. Y punto.
En este documento, como hemos dicho, se especifica (como si fuera un documento funcional), el QUE, pero no el COMO.
Pero además, este tipo de documentación da a los programadores libertad y creatividad para resolver técnicamente las cosas como mejor les parezca. Y de esta forma, es mucho más fácil que acabe creando software que cumpla lo QUE necesita el usuario.
Un saludo.
Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 8: escribiendo una documentación de usuario detallada, basada en el prototipo que completamos enel paso 6 y que establecimos en el paso 7 como línea base de los requisitos.
Esta entrada forma parte de una serie:
- Identificación de usuarios finales clave.
- Entrevista a dichos usuarios finales.
- Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
- Presentación del prototipo a los usuarios finales, solicitando feedback.
- Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
- Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
- Utilizar el prototipo como la primera línea de base de los requisitos.
- Escribir una documentación de usuario detallada, basada en el prototipo anterior.
- Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Una vez tenemos cerrado el prototipo, es importante cerrar también, lo antes posible, una documentación de usuario (requisitos, manual de usuario, etc).
Muchos pensaréis: "venga ya. ¿ahora vamos a documentar? ¿No basta con el código?". De esto ya hemos hablado en otros posts: "Nos gusta programar pero no documentar". Hay varios motivos para hacerlo:
- Porque lo pide el cliente (sí, en multitud de pliegos, concursos públicos, etc., se exige documentación).
- Porque lo necesita el cliente (sí, de nuevo, los manuales se necesitan, como se necesita una rueda de repuesto. Y eso es así, aunque la rueda de repuesto, al igual que el manual, quizá no se lleguen a usar).
- Porque el cliente no se va a leer tu código cuando tenga que hacer algo y no sepa cómo, o cuando algo no funcione como el usuario cree que debe hacerlo.
- Porque cada vez que el cliente quiere negociar o revisar el avance del proyecto, no se va a leer tu código para ver cómo va a funcionar todo cuando esté: lo que se revisa son los requisitos o un manual provisional.
Bueno. Sigamos. Aunque normalmente se documenta al final, en nuestra aproximación, lo haremos al principio. ¿Porqué? Pues porque estamos haciendo una toma de requisitos, y la mejor forma de hacerlo es dejando los documentos por adelantado.
Es más fácil para el equipo de desarrollo consultar el manual a la hora de hacer unas pruebas, o de avanzar el desarrollo, que cualquier otra cosa. Quizá el usuario no se lea el manual, pero al menos los programadores y los testers sí deberían estar hartos de leerlo. Probablemente el usuario no se lo lee porque los manuales que solemos hacer son siempre "fuera de hora": los hacemos en ese tiempo que hay al final del proyecto, y porque nos obligan, y siempre es en horas muertas, o cuando ya estamos reventados de intentar sacar adelante una funcionalidad que ya va retrasada. Por cierto, esa funcionalidad tal vez no estaría retrasada si no hubiéramos tenido que rehacer 20 veces el producto...y eso ocurría (tal vez), si nos hubiéramos molestado en hacer un manual de usuario al principio (como aquí planteo).
Otra ventaja de hacer la documentación y manuales al principio, evita tener que hacer una especificación técnica detallada. Ya se indica cómo debe funcionar todo, ya están los requisitos...¡pues a programar!
El cliente y usuarios finales entenderán mucho mejor un manual, y seguro que si es el mismo que usan (y revisan y corrigen) los programadores en el día a día, será un manual útil, y no el típico ladrillo que se suele hacer y que nadie lee.
El tener una documentación completa tan temprano, pule aún más posibles inconsistencias y puntos "oscuros" que pudieran haber quedado en nuestro prototipo. Se evitan muchas veces el tener documentos demasiado técnicos. En su lugar, se está haciendo una documentación basada en el uso, en la funcionalidad, no en la tecnología.
Este tipo de documentación, se va a mantener y a actualizar, mucho mejor que cualquier otro tipo de documento. Puesto que es algo que todo el mundo usa y necesita tenerlo al día: los usuarios finales, los programadores, los analistas, los testers...es como el anillo de la película del señor de los anillos: "un documento para unirlos a todos...".
Este tipo de documento es práctico, sin rollos que pretendan artificialmente hacerlo ameno, o inteligente, o complejo. Dice lo que el usuario necesita que el software haga. Y punto.
En este documento, como hemos dicho, se especifica (como si fuera un documento funcional), el QUE, pero no el COMO.
Pero además, este tipo de documentación da a los programadores libertad y creatividad para resolver técnicamente las cosas como mejor les parezca. Y de esta forma, es mucho más fácil que acabe creando software que cumpla lo QUE necesita el usuario.
Un saludo.
jueves, 10 de enero de 2013
Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0
Toma de Requisitos - Paso 7: Prototipo como Requisitos 1.0
Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 7: establecer el prototipo como la primera versión de los requisitos.
Para ello, el prototipo debe cumplir una serie de características:
El control de cambios no significa "ya está", "ya lo tenemos y no hay que tocarlo". Pero sí significa que tenemos que estar atentos a cada cambio, y realizar el adecuado seguimiento antes de aceptarlo, rechazarlo, o ponerlo "en espera". Ya dedicaremos un día algún artículo más detallado al control de cambios, y algunos trucos al respecto que espero os sean útiles.
Por desgracia, la manera más común de tratar los cambios es aceptar todo sí o sí, desbaratando cualquier plan existente, y evitando realizar nuevos planes, que al final, pudieran habernos llevado al éxito. Por desgracia, es así en demasiadas ocasiones. Y es que nos ciega el éxito, nos da miedo involucrar al cliente y realmente llevar un buen control de cambios. En fin.
Una vez tenemos la primera línea base del prototipo, la primera versión por tanto de los requisitos, tendremos una serie de logros adicionales:
Un saludo.
Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 7: establecer el prototipo como la primera versión de los requisitos.
Esta entrada forma parte de una serie cuyo índice es el siguiente:
- Identificación de usuarios finales clave.
- Entrevista a dichos usuarios finales.
- Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
- Presentación del prototipo a los usuarios finales, solicitando feedback.
- Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
- Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
- Utilizar el prototipo como la primera línea de base de los requisitos.
- Escribir una documentación de usuario detallada, basada en el prototipo anterior.
- Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Para ello, el prototipo debe cumplir una serie de características:
- Debe ser estable.
- Debe haber un compromiso por parte del equipo de desarrollo de hacer el software realmente a imagen y semejanza del prototipo.
- El cliente, o al menos los usuarios clave, han de validarlo.
- Debe ponerse al prototipo bajo control de cambios. No podemos modificarlo a la ligera. Un cambio en el estilo, en el flujo, en la funcionalidad...nos puede provocar una tormenta imparable de cambios.
- Las estimaciones.
- Los planes.
- La estructura y organización del equipo.
- Los diseños.
- EL desglose del trabajo que permita construirlo.
El control de cambios no significa "ya está", "ya lo tenemos y no hay que tocarlo". Pero sí significa que tenemos que estar atentos a cada cambio, y realizar el adecuado seguimiento antes de aceptarlo, rechazarlo, o ponerlo "en espera". Ya dedicaremos un día algún artículo más detallado al control de cambios, y algunos trucos al respecto que espero os sean útiles.
Por desgracia, la manera más común de tratar los cambios es aceptar todo sí o sí, desbaratando cualquier plan existente, y evitando realizar nuevos planes, que al final, pudieran habernos llevado al éxito. Por desgracia, es así en demasiadas ocasiones. Y es que nos ciega el éxito, nos da miedo involucrar al cliente y realmente llevar un buen control de cambios. En fin.
Una vez tenemos la primera línea base del prototipo, la primera versión por tanto de los requisitos, tendremos una serie de logros adicionales:
- Posibilidad de empezar con la documentación de usuario (manuales, etc).
- Preparar los planes de pruebas, con todo detalle.
- En paralelo, también pueden comenzar la arquitectura, diseño y algunas tareas de implementación.
Un saludo.
viernes, 4 de enero de 2013
Más Singletonitis
Recientemente, he escrito una entrada sobre la Singletonitis, y hoy me he encontrado con una entrada en un interesante blog, que habla también del tema, abordando incluso aspectos que había pasado por alto.
Al final, el abuso de los patrones está encontrando la horma de su zapato: lo que hoy nos parece una buena idea, mañana resulta contraproducente. El antiguo patrón singleton, tan sencillo, resulta ser un dardo envenenado a prácticas tan aceptadas como indispensables hoy en día como el uso de pruebas unitarias.
Sin embargo, la alternativa es difícil. El autor de este blog propone el uso de otro patrón de diseño, que si bien es similar funcionalmente (el llamado patrón monostate) , resuelve los problemas del Singleton (aunque a costa de una implementación compleja).
Fuentes: enlace.
Un saludo.
Al final, el abuso de los patrones está encontrando la horma de su zapato: lo que hoy nos parece una buena idea, mañana resulta contraproducente. El antiguo patrón singleton, tan sencillo, resulta ser un dardo envenenado a prácticas tan aceptadas como indispensables hoy en día como el uso de pruebas unitarias.
Sin embargo, la alternativa es difícil. El autor de este blog propone el uso de otro patrón de diseño, que si bien es similar funcionalmente (el llamado patrón monostate) , resuelve los problemas del Singleton (aunque a costa de una implementación compleja).
Fuentes: enlace.
Un saludo.
martes, 1 de enero de 2013
Feliz 2013
Os deseo para este año 2013 que entra hoy, paz y prosperidad para todos, salud, y todas estas cosas.
Ha sido un año bastante intenso, a pesar de que supuestamente, mi carga de trabajo debía ser menor. El próximo 2013, y sobre todo el 2014, van a ser la vuelta a todas las tareas anteriores, más nuevos proyectos profesionales que afrontaremos con la debida disciplina y rigor.
Espero traeros por aquí muchas más entradas, y que este blog siga manteniendo el interés, al menos para mí. Ya son algo más de 33.000 visitas. Y no es que sean muchas o pocas. Tampoco es que tuviera planificado un número específico. Hay quien dice que si no te planificas, no consigues las cosas. Y es correcto. Pero planificar lo que no necesitas...bueno, es algo estúpido, además de una pérdida de recursos.
Un cordial saludo
Ha sido un año bastante intenso, a pesar de que supuestamente, mi carga de trabajo debía ser menor. El próximo 2013, y sobre todo el 2014, van a ser la vuelta a todas las tareas anteriores, más nuevos proyectos profesionales que afrontaremos con la debida disciplina y rigor.
Espero traeros por aquí muchas más entradas, y que este blog siga manteniendo el interés, al menos para mí. Ya son algo más de 33.000 visitas. Y no es que sean muchas o pocas. Tampoco es que tuviera planificado un número específico. Hay quien dice que si no te planificas, no consigues las cosas. Y es correcto. Pero planificar lo que no necesitas...bueno, es algo estúpido, además de una pérdida de recursos.
Un cordial saludo
Suscribirse a:
Entradas (Atom)