2.5 PERSONAL DE PROYECTOS
Ingeniería de SoftwareINF - 163
Resumen preparado por Miguel Cotaña1
29/08/2011
2
En un proyecto Software el factor
humano es esencial!!!
Personal
3
El SEI ha desarrollado un modelo de
madurez de la capacidad de gestión
de personal (MMCGP), que define:
Reclutamiento;
Selección;
Gestión del desempeño;
Entrenamiento;
Diseño de la organización;
Retribución;
Desarrollo de la carrera;
Desarrollo de la cultura de
equipo.4
5
Reclutamiento
Selección
Entrenamiento
Gestión del desempeño
Retribución
Diseño de la organización
Desarrollo de la cultura en
equipo
Desarrollo de la carrera
Gestión del Personal
Se clasifican en 5
categorías:
Gestores ejecutivos;
Gestores (técnicos)
del proyecto;
Profesionales;
Clientes, ;
Usuarios finales.
Los participantes
6
Weinberg, sugiere un modelo de
liderazgo:
Motivación;
Organización;
Ideas o innovación;
Otra visión, define los rasgos:
Resolución de problemas;
Dotes de gestión;
Incentivos;
Influencia y fomento de la cultura
en equipo,
Líderes de equipo
7
La mejor estructura de equipo
depende del estilo de gestión de cada
organización, del número de personas
que integran el equipo y de sus
grados de habilidad. Los factores:
La dificultad del problema;
El tamaño del programa;
El tiempo que el equipo;
El grado de modularidad;
La calidad y confiabilidad;
La rigidez en fechas de entrega.
El equipo de software
8
Por lo general, los líderes de proyectostienen que seleccionar a las personaspara trabajar en su proyecto. Deforma ideal, estará disponiblepersonal con habilidades y experienciaapropiada para trabajar en elproyecto.
Sin embargo, en muchos casos, losadministradores tienen que establecerun equipo ideal mínimo para elproyecto.
Manejo del personal
9
Las razones para esto son:
El presupuesto del proyecto no cubre la
contratación de personal con sueldos altos.Se tiene que contratar personal con menosexperiencia y menos sueldo pero mejoraprovechados.
El personal con experiencia apropiada noestá. Dentro de la organización, las mejorespersonas ya se han asignado a otrosproyectos.
La organización desea desarrollar lashabilidades de sus empleados. El personalinexperto puede ser asignado al proyectopara aprender y adquirir experiencia.
10
Se debe contar con un plan paradesarrollar habilidades.
Los líderes de proyectos tienen queresolver problemas técnicos y notécnicos, motivar a la gente, planear yorganizar su trabajo, asegurando queeste se realice de manera adecuada.
La administración pobre del personales unos de los factores másimportantes para el fracaso de losproyectos.
11
Los líderes deben motivar a laspersonas que trabajan con ellos.Maslow (1954) señaló que laspersonas se motivan al satisfacer susnecesidades y que esas necesidadesse ordenan en una serie de niveles:
1. Necesidades Fisiológicas;
2. Necesidades de Seguridad;
3. Necesidades Sociales;
4. Necesidades de Estima.12
Las personas que crean software
practican el arte, la maestría o la
disciplina llamada IS.
Que es la práctica de la IS ?
Es una colección de conceptos,
principios, métodos y herramientas a
las que un ingeniero de sistemas
recurre a diario.
13
La esencia de la práctica de la IS, fue
propuesto por George Polya:
1. Entender el problema (comunicación y
análisis);
2. Planear una solución (modelado y diseño
de software);
3. Llevar a cabo el plan (generación de
código);
4. Examinar el resultado para probar la
precisión (realización de pruebas y
aseguramiento de la calidad).
La práctica de la IS
La esencia de la práctica
14
Antes de que los requisitos del cliente
puedan analizarse, modelarse o
especificarse, estos deben recopilarse por
medio de la comunicación.
La comunicación efectiva (entre pares
técnicos, con el cliente u otros
participantes del software y con los
gerentes de proyecto) esta entre las
actividades mas desafiantes que enfrenta
un IS.
Prácticas de comunicación
15
Muchos de los principios se aplican del
mismo modo a las formas de comunicación
P1: escuchar;
P2: prepararse antes de comunicar;
P3: alguien debe facilitar la actividad;
P4: la comunicación cara a cara;
P5: tomar notas y documentar;
P6: buscar la colaboración;
P7: examinar un módulo a la vez;
P8: si algo no esta claro, se hace un dibujo;
P9: continuar, continuar…..;
P10: las partes ganan en base a la negociación16
1. Identificar al cliente;
2. Reunirse con el cliente primario;
3. Desarrollar un enunciado;
4. Revisar el enunciado;
5. Colaborar con el cliente y el usuario;
6. Desarrollar una breve descripción;
7. Iterar con el cliente para refinar;
8. Asignar prioridades;
9. Revisar la información;
10. Prepararse para la planeación.
Tareas genéricas para la comunicación
17
Abarca un conjunto de prácticas técnicas
y de gestión que permiten al equipo de
software definir un mapa del camino
mientras se viaja a través de su meta
estratégica y objetivos tácticos.
La planeación insuficiente es una receta
para el caos.
La planeación se debe producir con
moderación, lo suficiente para
proporcionar una guía útil ni mas ni
menos
Prácticas de la Planeación
18
Los siguientes principios se aplican:
P1: entender los alcances del proyecto;
P2: innovar al cliente;
P3: reconocer que la planeación es iterativa;
P4: estimar en base a la experiencia;
P5: considerar el riesgo;
P6: ser realista;
P7: ajustar la granularidad;
P8: definir cómo asegurar la calidad;
P9: describir cómo se pretende el cambio;
P10: adaptar el plan y hacer los ajustes cuando
estos se requieran.19
Boehm, llamo principio W5HH (why, what,
when, who, where, how, how):
Por qué está en desarrollo este sistema?
Que se hará?
Cuándo se terminara?
Quién es el responsable de una función?
En dónde se ubican dentro de la organización?
Cómo se realizará el trabajo en los sentidos técnico y de
gestión?
Cuánto se necesita de cada recurso?20
1. Reevaluar el ámbito del proyecto;
2. Evaluar los riesgos;
3. Desarrollar o refinar los escenarios;
4. Extraer funciones y características;
5. Definir las funciones técnicas;
6. Agrupar las funciones y características;
7. Crear un plan de proyecto;
8. Crear un plan con granularidad fina;
9. Rastrear el progreso de manera regular.
Tareas genéricas para la planeación
21
Los modelos se crean para obtener un
mejor entendimiento de la entidad real
que se construirá.
Cuando la entidad es un objeto físico, se
puede construir un modelo idéntico en
forma y tamaño, pero en menor escala.
Cuando la entidad es lógico, debe ser
capaz de representar la información que
el software transforma, la arquitectura y
las funciones que permiten que ocurra la
transformación.
Práctica del Modelado
22
Modelo de análisis: representa los
requisitos del cliente al presentar el
software en 3 dominios (información,
funcional, del comportamiento)
Modelo de diseño: representan
características del software que ayudan a
los profesionales a construirlo de manera
efectiva (la arquitectura, la interfaz de
usuario, el detalle a nivel componentes).
23
Principios del modelado de análisis
Todos los métodos de análisis están
relacionados por principios operativos:
P1: el dominio de un problema deben
representarse y entenderse;
P2: definir funciones que ejecuta el software;
P3: representar el comportamiento del Sw;
P4: los modelos que presentan información,
función y comportamiento deben partirse de
manera estratificada;
P5: la tarea del análisis debe moverse de la
información esencial hacia el detalle de la
implementación.24
1. Revisar los requisitos del negocio, las
características/necesidades del usuario,
las salidas visibles, las restricciones, y
otros requisitos determinados durante
la comunicación y planeación;
2. Expandir y refinar los escenarios del
usuario
Definir a todos los actores;
Representar la forma de interactuar;
Extraer funciones a partir de escenarios;
Revisar escenario del usuario.
Tareas genéricas para el modelado del análisis
25
3. Modelar el dominio de la información
Representar todos los objetos;
Definir los atributos;
Representar las relaciones.
4. Modelar el dominio funcional
Mostrar la forma en que las funciones
modifican los objetos de datos;
Refinar las funciones;
Escribir una narración del procesamiento
que describa cada función y subfunción;
Revisar los modelos funcionales.
26
Principios de modelado del diseño
Siguen un conjunto de principios:
P1: el diseño debe ser rastreable;
P2: siempre considerar la arquitectura;
P3: el diseño de datos es importante;
P4: las interfaces deben diseñarse con cuidado;
P5: el diseño de interfaz del usuario debe
ajustarse a las necesidades del usuario final;
P6: el diseño al nivel de componentes debe ser
independiente del modo funcional;
P7: los componentes deben estar apareados;
P8: representaciones deben ser comprensibles;
P9: el diseño se desarrolla de manera iterativa.27
1. Utilizar el modelado de análisis,
seleccionar un estilo arquitectónico;
2. Dividir el modelo de análisis en
subsistemas de diseño y ubicar estos
dentro de la arquitectura:
Tener la certeza de que cada subsistema
es coherente en el sentido funcional;
Diseñar interfaces de subsistema;
Ubicar las clases o funciones de análisis
para cada subsistema;
Diseñar estructuras de datos apropiadas
Tareas genéricas para el diseño
28
3. Diseñar la interfaz del usuario:
Revisar los resultados del análisis de
tareas;
Especificar la secuencia de acción con
base en los escenarios del usuario;
Crear un modelo de comportamiento de
la interfaz;
Definir los objetos de la interfaz y
mecanismos de control;
Revisar el diseño de la interfaz y
ajustarlo como sea necesario.29
4. Conducir el diseño a nivel de
componente:
Especificar todos los algoritmos en un
grado relativamente bajo de abstracción
Refinar la interfaz de cada componente;
Definir las estructuras de datos en el
nivel de componente;
Revisar el diseño en el nivel de
componente.
5. Desarrollar un modelo de despliegue.
30
Abarca una serie de tareas de codificación
y realización de pruebas. En la IS
moderna, la codificación puede ser:
1) Creación directa de código fuente;
2) Generación automática de código
fuente al utilizar una representación
intermedia del diseño del componente
que será construido;
3) Generación automática de código
mediante un lenguaje de
programación de última generación.
Práctica de la construcción
31
Inicialmente las pruebas está al nivel de
componentes, llamadas pruebas de unidad.
Los otros niveles de prueba:
1) Pruebas de integración (mientras el
sistema está en construcción);
2) Pruebas de validación, los cuales
evalúan si los requisitos han sido
satisfechos para el sistema completo;
3) Pruebas de aceptación, que realiza el
cliente en un esfuerzo encaminado a
ejercitar las características y funciones.
32
1. Construir la infraestructura
arquitectónica:
Revisar el diseño arquitectónico;
Codificar y probar los componentes que
forman la infraestructura arquitectónica
Adquirir patrones arquitectónicos
reutilizables;
Probar la infraestructura para asegurar
la integridad de la interfaz.
Tareas genéricas para la construcción
33
2. Construir un componente del software:
Revisar el diseño al nivel de
componentes;
Crear una serie de pruebas de unidad
para el componente;
Codificar las estructuras de datos y la
interfaz del componente;
Codificar los algoritmos internos y las
funciones de procesamiento
relacionados;
Revisar el código conforme se escribe;
34
Buscar la exactitud;
Asegurarse de que se han mantenido
los estándares de codificación;
Asegurarse de que el código se
documenta así mismo.
3. Realizar pruebas de unidad al
componente:
Dirigir todas la pruebas de unidad;
Corregir errores descubiertos;
Aplicar de nuevo las pruebas de unidad.4. Integrar el componente terminado a la
infraestructura arquitectónica.35
Principios de las pruebas
En un libro sobre pruebas realizadas al
software. Glen Myers, establece reglas:
Las pruebas consisten en un proceso en el
que se ejecuta un programa con la intención
de encontrar un error que aún no se
descubre;
Un buen caso de prueba es aquel en el
que hay una gran probabilidad de encontrar
un error que aún no se descubre;
Una prueba exitosa es aquella que
encuentra un error que aún no se
descubría.36
Davis, sugiere los siguientes principios:
P1: todas las pruebas deben ser
rastreables hasta los requisitos del
cliente. Los defectos más severos son
aquellos que hacen fallar el programa al
tratar de satisfacer sus requisitos;
P2: las pruebas se deben planear
mucho antes de que comience el
proceso de prueba. Las pruebas se deben
planear y diseñar antes de que se haya
generado cualquier código;37
P3: el principio de Pareto es aplicable
para las pruebas de software. Implica
que 80% de los errores descubiertos
durante la prueba con probabilidad serán
rastreables hasta 20% de todos los
programas;
P4: las pruebas se deben comenzar
“en lo pequeño” y progresar hacia “lo
grande”;
P5: las pruebas exhaustivas no son
posibles.38
1. Diseñar pruebas de unidad;
2. Desarrollar una estrategia de
integración;
3. Desarrollar una estrategia de
validación;
4. Dirigir las pruebas de integración y
validación;
5. Dirigir las pruebas con mucho orden;
6. Coordinar con el cliente las pruebas de
aceptación.
Tareas genéricas para las pruebas
39
Abarca 3 acciones:
Cada ciclo de entrega le proporciona al
cliente un incremento de Sw. operativo ;
Cada ciclo de soporte proporciona
documentación y asistencia humana para
funciones y características introducidas
durante los ciclos de despliegue;
Cada ciclo de retroalimentación ofrece
al equipo de software una guía
importante que conduce a modificaciones
en las funciones.
Despliegue
40
Cuando el equipo se prepara para crear un
incremento, se sigue los principios:
P1: se debe administrar las expectativas que el
cliente tiene del software;
P2: Se debe ensamblar y probar un paquete de
entrega completo;
P3: Se debe establecer un régimen de soporte
antes de entregar el software;
P4: Se debe proporcionar material instructivo
apropiado a los usuarios finales;
P5: El software con errores se debe arreglar
primero y entregarse después.41
1. Crear medios de entrega;
2. Establecer la persona o grupo encargado
del soporte humano;
3. Establecer mecanismos de
retroalimentación;
4.Diseminar los medios de entrega;
5.Dirigir las funciones de soporte continuas;
6.Recopilar la retroalimentación del usuario.
Tareas genéricas para el despliegue
42
Top Related