Si usted es el profesor, Tenga en cuenta que es extenso por que incluimos las tablas de ROLES EN LOS PROYECTOS, por eso el texto se muestra tan extenso
El rol de las personas en las metodologías de ingeniería del software ha variado sustancialmente durante la. vida de esta disciplina. En un inicio, el desarrollo de software estaba al alcance. de unas pocas personas, altamente capacitadas. Los avances en los campos del hardware y software trajeron como consecuencia obvia y directa mayor potencia computacional y la posibilidad de trabajar con mayores niveles de abstracción, dando lugar a diferentes .metodologías de ingeniería del software.
Las personas al Inicio de la Informática: Protoingeniería del Software
Los "proto-ingenieros de software", eran visionarios altamente calificados, generalmente adelantados a su tiempo. Eran personas únicas: la historia de la informática no podría concebirse sin sus aportaciones. Si en lugar de ellos hubieran sido otros, seguramente la informática no sería la que conocemos actualmente.
Aunque parezca que estamos hablando de hace mucho tiempo, en algunos casos sólo han transcurrido un par de décadas. Para ilustrar esto, proveeremos 2 ejemplos:
Cuando Dijkstra contrajo matrimonio, quiso dejar constancia que su profesión era "programador". Como esta profesión no existía, no le fue permitido y tuvo que registrarse como "físico teórico"
John Von Newmann: fue el precursor de la separación..entre el hardware y el software, por tanto inventor del concepto de programa almacenado. Fue quien propuso al bit como unidad de información y resolvió el problema de la obtención de respuestas fiables con componentes no fiables (bit de paridad).
Alan M. Turing: matemático inglés creador de la Máquina de Turing, el antecedente teórico del ordenador moderno. Demostró que la base esencial de la informática podía modelarse con una máquina teórica muy simple. Creó el primer ordenador teórico en Fue un hombre muy peculiar, que llego a verse a si mismo como un ordenador
Metodologías Estructuradas Clásicas
Las metodologías estructuradas hacen fuerte separación ente los datos y los procesos. Producen una gran cantidad de modelos y documentación y se basan en ciclos de vida en cascada.
El enfoque estructurado tiene un alto grado de especialización en sus perfiles y las relaciones entre ellos tienen fuertes raíces en los principios de la descomposición funcional. Para ilustrar este concepto, podemos citar la fuerte separación que existe entre el programador y el analista. En el Análisis Estructurado Moderno, idealmente el analista no habla directamente con el programador! sino que lo hace a través del diseñador. Adicionalmente, se intenta mecanizar las tareas del programador, teniendo como ideal la generación del código mediante herramientas CASE. El programador es altamente reemplazable.
Metodologías Orientadas a Objetos Clásicas
Ante la necesidad de normalizar el proceso desarrollo se propusieron unas metodologías que priman las fases, actividades y tareas antes que a las personas: lo más importante es el rol que juega la persona dentro del proceso de desarrollo. Esto se ha justificado históricamente argumentando que el desarrollo de software es una actividad compleja que debe estar dirigida por un proceso y debe llevarse a cabo en grupos.
Para cubrir todas las fases se necesitan distintos y diversos perfiles, que no se encuentran en una sola persona. El rol se asigna dependiendo de la experiencia, formación y capacidades de cada individuo.
Una de las ventajas de estos procesos es que el intercambio de un recurso es relativamente fácil: cuanto más identificadas se tengan las tareas que realiza un rol, más fácil es formar a una persona en esas tareas específicas.
En un proyecto de RUP existen los siguientes roles :
Jefe de proyecto Supervisor y responsable del proyecto
Analista del Proceso de Negocio Coordina el modelado de los CU de negocio
Diseñador del Proceso de Negocio Describe el worfl1ow de uno o varios casos de uso de negocio
Revisor del Proceso de Negocio Revisa los artefactos generados del workflow de Modelado de Negocio
Analista de Sistemas Es el responsable de un conjunto de requisitos: Requisitos funcionales,
Requisitos no funcionales
Especificador de Casos de Uso Asumen las responsabilidades de las descripciones detalladas de uno o más casos de uso
Diseñador de Interfaces de Usuario Forma visual de los interfaces de usuario, esquema de pantallas, modelos de interfaz grafica
Arquitecto Describe el modelo de la arquitectura, es responsable de la integridad del
modelo de análisis y de la integridad de los modelos de diseño y despliemle
Revisor de Requisitos Revisa los artefactos generados en el workt1ow de Análisis de Requisitos
lngeniero de Componentes Define y mantiene las responsabilidades, atributos, relaciones y requisitos de una o varias clases de análisis
Ingeniero de Casos de Uso Analiza un Caso de Uso, Captura requisitos. especiales sobre ]a ealización del caso de uso y es responsable de la integridad de una o más realizaciones de casos de uso-diseño
lntegrador de Sistemas Planifica la secuecia de construcciones nece"sarias en cada iteración "
Diseñador de Pruebas Responsable de la integridad del modelo de pruebas y plantear las pruebas
Ingeniero de Pruebas de implantación Verifica los componentes integrados en la construcción que se derivan de los casos de prueba Que especifican una realización de un caso de uso-diseño
Ingeniero de Pruebas de Sistemas Prueba de las pruebas técnicas: rendimiento, estrés, carga,.. de una iteracción completa
Jefe de Control de Cambio Concreta las acciones de cambio obtenidas del plan de cambios
Administrador de Sistemas Configuración y adaptar e] proceso a las necesidades y restricciones
Experto en Herramientas Conocedor de las herramientas deben ajustarse a cada actividad: modelado, gestión de requisitos. entomos de desarrollo, gestión de configuración,
pruebas, planificación. documentación
Escritor Técnico Encargado de documentar los manuales de usuario y explotación
Programador Programador del código fuente
Personal Técnico Encargado de la formación
Las personas en las metodologías ágiles
En los procesos ágiles, las personas vuelven a tomar un valor importante: el éxito de estos procesos es función de la participación, preparación e involucramiento de las personas en el mismo. Generalmente estos procesos deben ser conducidos y llevados a cabo por personas con características muy especiales. El cambio de estas personas afecta fuertemente al proceso. De hecho, estos procesos están también orientados a las personas, buscando un mayor estado de bienestar para las personas que llevan a cabo el proceso de software a cambio de un mayor grado de compromiso. Por lo tanto, podemos decir que las personas tienen un rol muy importante en este tipo de procesos.
Procesos ágiles
Los procesos ágiles ofrecen un enfoque diametralmente opuesto al de las metodologías predictivos para gestionar y controlar el desarrollo de productos y proyectos de software.
Se basan en principios tales como la temprana y continua entrega de software de valor; la actitud positiva frente al cambio de requerimientos en función de las necesidades del . cliente; la motivación individual de los integrantes del proyecto; la comunicacion fluida entre. el personal de desarrollo y de negocios; la excelencia técnica; la simplicidad; la comunicación personal; la emergencia y la autoorganización. Todos estos principios han sido extraídos del Manifiesto Ágil, un documento que surge como producto de la reunión realizada por un grupo de reconocidos ingenieros de software en cuya idea común crear un "llamado a las armas a favor de métodos más ágiles de desarrollo de software".
Las personas son muy importantes en Extreme Programming. De hecho, el motivo de su existencia según Kent Beck es mejorar la calidad de vida de los integrantes de los equipos de desarrollo de software.
A los programadores, XP les promete que serán capaces de trabajar en cosas que realmente les importan, cada día. No tendrán que enfrentarse solos a situaciones aterradoras. Podrán aprovechar todas sus energías para hacer que su sistema tenga éxito. Tomaran las decisiones que puedan tomar mejor y.no tomarán aquellas para los que no sean los mejores preparados
A los clientes y directivos, XP les promete que obtendrá el mayor valor posible de cada semana de programación. Cada pocas semanas podrán ver progresos concretos en las metas que les importan. Podrán cambiar la dirección del proyecto a mitad del desarrollo, sin incurrir en costes excesivos
Como se puede apreciar, estas promesas apuntan al bienestar social de los 2 stakeholders determinantes en un proceso de desarrollo: el equipo de desarrollo y el cliente.
Para lograr esto, se basa en un conjunto de valores humanos, a saber: comunicación, sencillez, realimentación y valentía. Estos valores se materializan a través de una serie de prácticas, entre ellas programación en parejas, 40 horas de trabajo semanales, diseño sencillo, comunicación con el cliente, propiedad colectiva del código.
En un proyecto de XP existen los siguientes roles :
Rol Descripción
El Programador Es el corazón de XP. Según Beck, si los programadores pudieran tomar
decisiones que cuidadosamente equilibrascn las prioridades a corto y largo
plazo no habría necesidad de otro personal técmco en el proyecto .
Además de un peñtl técnico, debe tener que tener habilidades de
comunicación y coordinación con otros programadores. el hábito de la
simplicidad evitando la "violencia intelectual" . estar dispuesto a dejar de
lado la propiedad del código.
El Cliente Es la otra mitad de la dualidad esencial de XP. El programador sabe como
programar, el cliente sabe que programar. Debe tener habilidades de
comunicación. un fuerte control sobre su sensación y ansias de poder sobre el
proyecto, capacidad de abstracción y comprensión funcional del proyecto.
El encargado de pruebas Es el responsable de ayudar al cliente a escoger y escribir pruebas
funcionales. Es responsable también de hacer funcionar las pruebas
regularmente y comunicar sus resultados al resto del equipo. Debe ser una
persona con capacidad de abstracción y mucho tacto y facilidad de
comunicación. dado que esta en un lugar intermedio entre los programadores
y el cliente.
El Controlador Es la conciencia del equipo . Su trabajo es cerrar el bucle de la
realimentación . Es responsable también de vigilar nformación sobre el estado del proyecto sin molestar al resto del equipo.
El Preparador Es el responsable del proceso en su conjunto, llamando la atención a los
integrantes del equipo cuando se desvían del proceso. Debe entender al
proceso con más profundidad que el resto de los integrantes y determinar en
que forma aplicarlo para obtener mejores resultados. Debe ser una persona
con fuerte temperamento, capaz de soportar y filtrar presiones políticas para
poder mantener la calma interna aun cuando hay mucha ansiedad fuera del
equipo. Debe poder también dirigir sin agobiar y saber cuando ser incisivo y
hasta grosero con un miembro del equipo. Además de las mencionadas, debe
tener habilidades parecidas a las del resto de los roles.
El Consultor Es una persona encargada. de dar solución a un problema puntual que el
equipo de XP no puede resolver
El Gran Jefe Es el jefe del proyecto. Sus principales características deben ser confianza,
coraje y brindar autonomía al equipo.
No hay comentarios:
Publicar un comentario