martes, 18 de mayo de 2010

AUTORES:

LUIS MARIO GÓMEZ LUNA

PATRICIA MOSQUEDA BÁEZ

JORGE LONA

miércoles, 24 de marzo de 2010

DIAPOSITIVAS

AQUÍ LES DEJO EL LINK DE DESCARGA DE LAS DIAPOSITIVAS DE LOS TEMAS QUE TRATA ESTE BLOG

http://rapidshare.com/files/367228399/Admin_de_Proyec.rar

martes, 16 de marzo de 2010

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

La gestión del proyecto de software comienza con un conjunto de actividades que en grupo se denominan planificación del proyecto. Antes de que el proyecto comience el gestor, del proyecto y el equipo de software deben estimar el trabajo que habrá de realizarse, los recursos que se requerirán y el tiempo que transcurrirá; desde el principio hasta el final.

McConell argumenta que cualquier proyecto puede encontrar el tiempo para planificar (y adaptar el plan a lo largo del proyecto) simplemente tomando un pequeño porcentaje del tiempo que se habría gastado en la reelaboración que ocurre debido a que no se planificó.


 

1.- OBSERVACIONES ACERCA DE LA ESTIMACIÓN

La planificación requiere que los gestores técnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este "compromiso" pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta automáticamente algún grado de incertidumbre.

La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica (métricas) y el valor para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y éste conduce a la incertidumbre.

La disponibilidad de información histórica tiene una fuerte influencia en el riesgo de la estimación. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las áreas donde surgieron problemas. Cuando hay disponibles amplias métricas de software de proyectos previos, las estimaciones se hacen con mayor seguridad, los programas de trabajo se pueden establecer para evitar dificultades pasadas y el riesgo global se reduce.

El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costos y programa de trabajo. Si el ámbito del proyecto se comprende en forma deficiente o los requisitos del proyecto están sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimación se incrementan peligrosamente. El planificador y, en forma más importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo.


 

2.- EL PROCESO DE PALNIFICACIÓN DEL PROYECTO

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además, las estimaciones deben intentar definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el equipo de software se embarca en un plan establecido como consecuencia de las tareas de planificación.


 

3.- ÁMBITO DEL SOFTWARE Y FACTIBILIDAD

El ámbito del software describe las funciones y características que se entregarán a los usuarios finales, los datos que son entrada y salida, el "contenido" que se presenta a los usuarios como consecuencia de emplear el software, así como el desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema.

Una vez identificado el ámbito (con la participación del cliente) es razonable preguntar: ¿es posible construir software para satisfacer este ámbito? ¿El proyecto es factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas (o gestores o clientes impacientes los presionan para hacerlo), sólo para verse enredados en un proyecto condenado al fracaso.


 

4.- RECURSOS

La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software. La figura muestra las tres grandes categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro características: descripción del recurso; un informe de disponibilidad; cuándo se requerirá el recurso; tiempo durante el cual el recurso se aplicará. Las últimas dos características se pueden ver como una ventana de tiempo. La disponibilidad del recurso para una ventana específica debe establecerse lo más pronto posible.



 

5.- ESTIMACIÓN DE PROYECTOS DE SOFTWARE

El software es el elemento más caro de virtualmente todos los sistemas basados en computadora. En sistemas complejos, personalizados, un gran error en la estimación del costo puede hacer la diferencia entre beneficio y pérdida. Rebasar el costo puede ser desastroso para el desarrollador.

La estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables —humanas, técnicas, ambientales, políticas— pueden afectar el costo final del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimación del proyecto de software se puede transformar de una práctica oscura en una serie de pasos sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones:

1.    Demorar la estimación hasta más tarde en el proyecto (obviamente, ¡se puede lograr 100 por ciento de estimaciones precisas después de que el proyecto esté terminado)

2.    Basar las estimaciones en proyectos similares que ya hayan sido completados.

3.    Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto.

4.    Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.

6.- TÉCNICAS DE DESCOMPOSICIÓN

La estimación del proyecto de software es una forma de resolver problemas; en la mayoría de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimación de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razón se descompone el problema, recaracterizándolo como un conjunto de problemas más pequeños (y, esperanzadoramente, más manejable).

Se ha examinado el enfoque de descomposición desde dos diferentes puntos de vista: descomposición del problema y descomposición del proceso. La estimación emplea una o ambas formas de partición. Pero antes de que pueda realizarse una estimación, el planificador del proyecto debe entender el ámbito del software que se construirá y generar una estimación de su "tamaño".

6.1 TAMAÑO DEL SOFTWARE

La precisión de la estimación de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se construirá; 2) la habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero (una función de la disponibilidad de las métricas de software confiables a partir de proyectos previos); 3) el grado en el cual el plan del proyecto refleja las habilidades del equipo de software; y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería del software.

En esta sección se considera el problema del tamaño del software. Puesto que la estimación de un proyecto sólo es tan buena como la estimación del tamaño del trabajo para realizarlo, el tamaño representa el primer gran desafío del planificador del proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a un resultado cuantificable del proyecto de software.


 

7.- MODELOS EMPÍRICOS DE ESTIMACIÓN

Un modelo de estimación para software de computadora utiliza fórmulas obtenidas empíricamente para predecir el esfuerzo como una función de LDC o PF.

Los datos empíricos que apoyan la mayoría de los modelos de estimación proceden de una muestra limitada de proyectos. Por esta razón, ningún modelo de estimación es apropiado para todas las clases de software ni en todos los entornos de desarrollo. En consecuencia, los resultados obtenidos a partir de tales modelos se deben emplear juiciosamente.

Un modelo de estimación debe calibrarse para reflejar las condiciones locales. El modelo debe probarse mediante la aplicación de los datos recopilados a partir de proyectos completados, colocar los datos en el modelo y luego comparar los resultaos reales con los predichos. Si la concordancia es insuficiente, el modelo debe afinarse y ponerse a prueba nuevamente antes de que se pueda utilizar.

7.1 LA ESTRUCTURA DE LOS MODELOS DE ESTIMACIÓN

Un modelo de estimación típico se deriva mediante el análisis de regresión de los datos recopilados de proyectos de software previos. La estructura global de tales modelos toma la forma

E = A + B x (ey) c

Donde A, B y C son constantes obtenidas empíricamente, E es el esfuerzo en persona-mes y ev es la variable de estimación.


 

7.2 LA ECUACIÓN DEL SOFTWARE

La ecuación de software es un modelo multivariable que supone una distribución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. El modelo procede de datos de productividad recopilados de casi 4 000 proyectos de software contemporáneos. Con base en estos datos, un modelo de estimación de la forma

E = [LDC x B0.333/P]3 x (1/t4)

Donde

E = esfuerzo en personas-mes o personas-año

t = duración del proyecto en meses o años

B = "factor especial de habilidades"


 

8.- ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS

1. Desarrollar estimaciones aplicando la descomposición de esfuerzo, análisis de PF y cualquier otro método que sea aplicable en aplicaciones convencionales.

2. Aplicar el modelado de análisis orientado a objetos, desarrollar casos de uso y determinar un conteo. Reconocer que el número de casos de uso puede cambiar conforme avance el proyecto.

3. A partir del modelo de análisis, determinar el número de clases clave (llamadas clases de análisis).

4. Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicador para las clases de soporte:

Tipo de interfaz

Multiplicador

Sin IUG

2.0

Interfaz del usuario basada en texto

2.25

IUG

2.25

IUG compleja

3.0


 

Multiplicar el número de clases clave por el multiplicador para obtener una estimación del número de clases de soporte.

5. Multiplicar el número total de clases (clave + soporte) por el número promedio de unidades de trabajo por clase. Se sugiere de 15 a 20 personas-día por clase.

6. Comprobar de manera cruzada la estimación basada en clase al multiplicar el número promedio de unidades de trabajo por caso de uso.


 

9.- TÉCNICAS DE ESTIMACIÓN ESPECIALIZADAS

Las técnicas de estimación estudiadas en las secciones 6, 7 y 8 se pueden aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de software encuentra una duración de proyecto extremadamente corta (semanas más que meses) —que probablemente tengan una continua corriente de cambios— la planificación del proyecto en general y la estimación en particular se deben abreviar.

    9.1 ESTIMACIÓN PARA DESARROLLO ÁGIL

Puesto que los requerimientos para un proyecto ágil se definen como un conjunto de escenarios de usuario es posible desarrollar un enfoque de estimación informal, aunque razonablemente disciplinado y significativo dentro del contexto de la planificación del proyecto para cada incremento de software.

La estimación para los proyectos ágiles aplica un enfoque de descomposición que abarca los pasos siguientes:

1.    Cada escenario de usuario se considera por separado respecto de propósitos de estimación.

2.    El escenario se descompone en el conjunto de funciones y las tareas de ingeniería del software que se requerirán para desarrollarlo.

3a. Cada tarea se estima por separado.

3b. Alternativamente, el "volumen" (tamaño) del escenario se puede estimar en LDC, PF o alguna otra medida orientada a volumen.

4a. Las estimaciones de cada tarea se suman para crear una estimación para el escenario.

4b. Alternativamente, el volumen estimado para el escenario se traduce en es-fuerzo mediante la aplicación de datos históricos.

5. Las estimaciones de esfuerzo acerca de todos los escenarios que se imple-mentarán para un incremento de software dado se suman con el fin de desarrollar el esfuerzo estimado para el incremento.


 

9.2 ESTIMACIÓN PARA PROYECTOS DE INGENIERÍA WEB

Como se asentó anteriormente, los proyectos de ingeniería Web con frecuencia adoptan el modelo de proceso ágil. Es factible emplear una medición de punto de función modificada, con el fin de desarrollar una estimación para la WebApp.

Roetzheim sugiere los siguientes valores de dominio de información cuando se adaptan puntos de función para la estimación WebApp:

•    Entradas: son cada pantalla o formato de entrada (por ejemplo, CGI o Java), cada pantalla de mantenimiento y, si en alguna parte utiliza una etiqueta de metáfora de cuaderno, cada etiqueta.

•    Salidas: son cada página Web estática, cada guión de página Web dinámica (por ejemplo, ASP, ISAPI u otro guión DHTML) y cada reporte (ya sea que esté basado en Web o sea del todo administrativo).

•    Tablas: son cada tabla lógica en la base de datos más, si emplea XML para almacenar datos en un archivo, cada objeto XML (o colección de atributos XML).

•    Las interfaces retienen su definición como archivos lógicos (por ejemplo, formatos de registro únicos) en las fronteras exteriores del sistema.

•    Consultas: son cada interfaz publicada externamente o utiliza una interfaz orientada al mensaje. Un ejemplo típico son las referencias externas DCOM o COM.

Los puntos de función (calculados empleando los valores de dominio de información anotados) son un indicador razonable del volumen para una WebApp.


 

10.- LA DESICIÓN DESARROLLAR-COMPRAR

A menudo, en muchas áreas de aplicación de software es más rentable adquirir que desarrollar software de computadora. Los gestores de ingeniería del software enfrentan una decisión de desarrollar-comprar que tal vez se complique aún más por varias opciones de adquisición: 1) el software se puede comprar (o adquirir la licencia) ya desarrollado, 2) los componentes de software de "experiencia completa" o "experiencia parcial" se pueden adquirir y luego modificar e integrar para satisfacer necesidades específicas, o 3) el software se puede construir de manera personalizada por medio de un contratista externo para satisfacer las necesidades del comprador.

Los pasos involucrados en la adquisición los definen lo crucial del software que se comprará y el costo final. En el análisis final, la decisión desarrollar-comprar se realiza basándose en las siguientes condiciones: 1) ¿El producto de software estará disponible antes que el software desarrollado de manera interna? 2) ¿El costo de adquisición más el costo de personalización será menor que el costo de desarrollar el software de manera interna? 3) ¿El costo del soporte externo (por ejemplo, un contrato de mantenimiento) será menor que el costo del soporte interno? Estas condiciones se aplican a cada una de las opciones de adquisición.


 

lunes, 8 de marzo de 2010

CONCEPTOS DE GESTIÓN DE PROYECTOS

21. CONCeptos de Gestión de Proyectos

21.1 EL ESPECTRO DE LA GESTIÓN

La gestión eficaz de la gestión de proyectos de software se enfoca sobre las cuatro P: personal, producto, proceso, proyecto.

21.1.1 El Personal

El factor humano es tan importante que el Software Engineering Institute ha desarrollado un modelo de madurez de la capacidad de gestión del personal (MMCGP). Este modelo define áreas claves para el personal de software: reclutamiento, selección, gestión del desempeño, entrenamiento, retribución desarrollo de la carrera, diseño de la organización y el trabajo, y desarrollo de la cultura en equipo. Las organizaciones que logran altos niveles de madurez en el área de gestión de personal tienen una mayor probabilidad de implementar efectivas prácticas de ingeniería del software.

21.1.2 El Producto

21.1.3 El Proceso

Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Incluye:

  • Número pequeño de actividades.
  • Conjunto de tareas diferentes (productos de trabajo y puntos de control de calidad).
  • Actividades protectoras (control de calidad del software, la gestión de configuración del software y la medición) ocurren durante todo el proceso.

21.1.4 El Proyecto

21.2 PERSONAL

21.2.1 Los Participantes

El proceso de software lo integran participantes que pueden clasificarse dentro en una de cinco categorías:

  1. Gestores ejecutivos: definen los aspectos del negocio que usualmente tienen una influencia significativa en el proyecto.
  2. Gestores (técnicos) del proyecto: quienes planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo de software.
  3. Profesionales: quienes proporcionan las habilidades técnicas necesarias para realizar la ingeniería de un producto o aplicación.
  4. Clientes: quienes especifican los requisitos para la ingeniería del software y otros elementos que tienen un interés mínimo en el resultado.
  5. Usuarios finales: quienes interactúan con el software.

21.2.2 Lideres del equipo

Para ser eficaz, el equipo del proyecto debe estar organizado en una forma que maximice las capacidades y habilidades de cada persona. Esta es la labor del líder del equipo.

Modelo MOI de liderazgo (Motivación, Organización, Ideas o Innovación)

Los líderes de proyecto exitosos aplican un estilo de gestión de resolución de problemas. Esto es: un gestor de proyecto de software debe concentrarse en entender el problema que será resuelto, gestionar el flujo de ideas y, al mismo tiempo, hacer que todos los que forman el equipo conozcan (con palabras, y mucho más importante, con acciones) que la calidad es relevante y que no será comprometida.

Características que definen un gestor de proyecto eficiente:

Resolución de problemas, Dotes de gestión, Incentivos y la Influencia y fomento de la cultura de equipo.

21.2.3 El equipo del software

La mejor estructura de equipo depende del estilo de gestión de cada organización, del número de personas que integraran el equipo y de sus grados de habilidad, así como de la dificultad global del sistema.

Factores que se deben considerar cuando se elige la estructura de un equipo de software:

  • La dificultad del problema que se resolverá.
  • El tamaño de programa(s) resultante(s) en líneas de código o puntos de función.
  • El tiempo que el equipo estará junto (vida del equipo).
  • El grado en el que el problema puede separarse en módulos.
  • La calidad y la confiabilidad requeridos del sistema que se construirá.
  • La rigidez de la fecha de entrega.
  • El grado de sociabilidad (comunicación) que se requiere del proyecto.

Paradigmas organizacionales estructura de un equipo de software:

Paradigma cerrado: estructura un equipo a lo largo de una jerarquía tradicional de autoridad.

Paradigma aleatorio: estructura un equipo libremente y depende de la iniciativa individual de los miembros del equipo.

Paradigma abierto: el trabajo se desarrolla en colaboración, la solida comunicación y la toma de decisiones se basa en el consenso.
Intenta estructurar un equipo en una forma que logre algunos de los controles asociados con el paradigma cerrado, pero también mucha de la innovación que ocurre cuando se aplica el paradigma aleatorio.

Paradigma sincrónico: se apoya en la compartimentalización natural de un problema y organiza a los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Para lograr un equipo de alto rendimiento: los miembros del equipo deben tenerse mutua confianza, la distribución de las actividades debe adecuarse al problema.

21.2.4 Equipos ágiles

  • La filosofía ágil alienta la satisfacción del cliente y la temprana entrega incremental de software; pequeños equipos de trabajo enormemente motivados, métodos informales, mínimos productos de trabajo de ingeniería del software y simplicidad global del desarrollo.

Características:

  • Los equipos agiles son autoorganizados
  • Competencia individual
  • La planificación se mantiene en el mínimo.
  • Al equipo se le permite seleccionar su propio enfoque (proceso, métodos, herramientas) solo restringido por los requisitos del negocio y los estándares organizacionales.

21.3 EL PRODUCTO

21.3.1 Ámbito del software

La primera actividad de gestión de un proyecto de software es la determinación del ámbito del software.

El ámbito se define al responder las siguientes preguntas:

Contexto. ¿Cómo encaja el software que se desarrollara en un sistema más grande, producto o contexto de negocios, y que restricciones se imponen como resultado del contexto?

Objetivos de información. ¿Qué objetos de datos visibles al usuario se producen como resultado del software? ¿Qué objetos de datos se requieren de entrada?

Función y desempeño. ¿Qué funciones realiza el software para transformar los datos de entrada en salida? ¿Existen algunas características de desempeño especiales que deban abordarse?

21.3.2 Descomposición del problema

Partición o elaboración del problema, es una actividad que se asienta en un núcleo del análisis de requisitos de software.

La descomposición se aplica en dos grandes áreas:

  1. La funcionalidad que debe entregarse.
  2. El proceso que se empleara para entregarla.

21.4 EL PROCESO

El gestor del proyecto debe decidir cual modelo de proceso es más adecuado para:

  1. Los clientes que han solicitado el producto y el personal que hará el trabajo
  2. Las características del producto mismo
  3. El ambiente del proyecto en el que trabaja el equipo del software

21.4.1 Combinación del producto y el proceso

La planeación del proyecto comienza con la combinación del producto y el proceso. Se realiza mediante el marco de trabajo del proceso que establece un esqueleto para la planificación del proyecto. Se adapta al ubicar un conjunto de tareas adecuadas para el proyecto. Se debe crear un plan completo, que refleje las tareas de trabajo requeridas para cubrir las actividades del marco de trabajo.

21.4.2 Descomposición del proceso

Una vez elegido el modelo de proceso, el marco de trabajo respectivo se adapta a él. La descomposición del proceso comienza cuando el gerente de proyecto pregunta:

¿Cómo logramos esta actividad del marco de trabajo?

Tareas de trabajo para la actividad de comunicación:

  1. Revisar la petición del cliente
  2. Planificar y programar una reunión formal con el cliente
  3. Llevar a cabo investigaciones para especificar la solución propuesta
  4. Preparar un documento de trabajo y una agenda para la reunión formal
  5. Celebrar la reunión

21.5 EL PROYECTO

La gestión de un proyecto de software exitoso requiere entender que puede salir mal (de modo que sea factible evitar los problemas).

Señales de que un proyecto de sistemas de información está en peligro:

  1. El personal de software no entiende las necesidades de sus clientes
  2. El ámbito del producto está mal definido
  3. Los cambios se gestionan mal
  4. La tecnología elegida cambia
  5. Las necesidades comerciales cambian(o están mal definidas)
  6. Los plazos de entrega no son realistas
  7. Los usuarios se resisten
  8. Se pierde el patrocinio
  9. El equipo del proyecto carece d personal con las habilidades apropiadas
  10. Los gestores evitan las mejores prácticas y las lecciones aprendidas

¿Cómo actúa un gestor para evitar estos problemas?

  • Comience con el pie derecho
  • Mantenga el ímpetu
  • Rastree el progreso
  • Tome decisiones inteligentes
  • Realice un análisis de resultados

21.6 EL PRINCIPIO W5HH

Enfoque que aborda los objetivos del proyecto, los hitos, planificación, responsabilidades, gestión, enfoques técnicos y recursos requeridos.