Como todo el mundo sabe, el desarrollo de software conlleva varios procesos, no sólo el desarrollo como ocurre en algunos entornos dominados por los malos modos a la hora de abordar un proyecto.
Los procesos a los que me refiero abarcan desde la recogida de especificaciones hasta la puesta en producción del producto. Hoy en día, las herramientas de desarrollo se están convirtiendo en entornos configurables según el rol del que las utiliza, por tanto habrá tantas vistas como roles tengamos. En principio se podría hablar de cuatro roles fundamentales: jefe de proyecto, arquitecto, analista/desarrollador y testeador.
La función de cada uno la conocemos todos, pues bien, todos trabajarán con la misma herramienta de forma ordenada en función a una perspectiva sobre la misma información. Esta información es toda la referente al proyecto, incluidas las tareas, el código fuente, los documentos que generan los arquitectos para orientar a los anialistas/desarrolladores (GUIDANCE) y por último los que verifican que el software cumple con unos requisitos mínimos de calidad, los testeadores, rol cada vez más importante y en contradicción menos considerado.
Ejemplos de estas herramientas los hemos visto aparecer recientemente, es el caso de IBM Rational y Visual Studio Team System.
De los dos ejemplos, quizás el que mejor conozco es el de Visual Studio Team System y en mi opinión me parece que está bastante bien, y no es por echar flores a nadie, ya que cada uno está implementando la misma idea de la mejor manera posible.
No voy a entrar a detallar qué características tiene esta herramienta, pero sí pensar en la ventaja y el beneficio que pueda tener un jefe de proyecto para controlar un proyecto en .Net siempre y cuando esté bien dividido en hitos y tareas, ya que gracias a esta herramienta, al estar todo integrado y sincronizado en una base de datos sobre la que se basa, como no, SQLServer, se puede saber en todo momento qué porcentaje de cada tarea está cubierto, ya que todo desarrollador, al hacer checkin está proporcionando qué es lo que se libera y qué es lo que está completo. Y esto es sólo un pequeño ejemplo.
Los procesos a los que me refiero abarcan desde la recogida de especificaciones hasta la puesta en producción del producto. Hoy en día, las herramientas de desarrollo se están convirtiendo en entornos configurables según el rol del que las utiliza, por tanto habrá tantas vistas como roles tengamos. En principio se podría hablar de cuatro roles fundamentales: jefe de proyecto, arquitecto, analista/desarrollador y testeador.
La función de cada uno la conocemos todos, pues bien, todos trabajarán con la misma herramienta de forma ordenada en función a una perspectiva sobre la misma información. Esta información es toda la referente al proyecto, incluidas las tareas, el código fuente, los documentos que generan los arquitectos para orientar a los anialistas/desarrolladores (GUIDANCE) y por último los que verifican que el software cumple con unos requisitos mínimos de calidad, los testeadores, rol cada vez más importante y en contradicción menos considerado.
Ejemplos de estas herramientas los hemos visto aparecer recientemente, es el caso de IBM Rational y Visual Studio Team System.
De los dos ejemplos, quizás el que mejor conozco es el de Visual Studio Team System y en mi opinión me parece que está bastante bien, y no es por echar flores a nadie, ya que cada uno está implementando la misma idea de la mejor manera posible.
No voy a entrar a detallar qué características tiene esta herramienta, pero sí pensar en la ventaja y el beneficio que pueda tener un jefe de proyecto para controlar un proyecto en .Net siempre y cuando esté bien dividido en hitos y tareas, ya que gracias a esta herramienta, al estar todo integrado y sincronizado en una base de datos sobre la que se basa, como no, SQLServer, se puede saber en todo momento qué porcentaje de cada tarea está cubierto, ya que todo desarrollador, al hacer checkin está proporcionando qué es lo que se libera y qué es lo que está completo. Y esto es sólo un pequeño ejemplo.
