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