27 de octubre de 2012

Control de Riesgos

PLANIFICACIÓN DE LA GESTIÓN DE RIESGOS

  • Consiste en la elaboración de un plan que controle cada  uno de los riesgos de prioridad alta identificados en  etapas anteriores.
  •  Hay que considerar cuatro opciones:
               – Investigar: establecer un plan para investigar el riesgo.
               – Aceptar: decidir aceptar el riesgo documentar las razones.
        – Observar: controlar las condiciones del riesgo para obtener indicaciones de cambio en la                  probabilidad o el impacto.
              – Mitigar: reasignar recursos e indicar acciones a realizar para reducir la probabilidad o el impacto potencial de los riesgos.


RESOLUCIÓN DE RIESGOS
  • Mediante el proceso de resolución de riesgos se pone en  práctica el plan elaborado en la etapa anterior.
  • Algunos de los métodos usados para tratar el riesgo son:
               – Evitar el riesgo
               – Trasladarlo a otra parte del sistema
               – Eliminar el origen del riesgo
               – Informar sobre el riesgo
               – Controlar el riesgo


MONITORIZACIÓN DE RIESGOS

El objetivo de la monitorización es la toma de decisiones efectivas, documentadas  y a tiempo mediante la  observación de los riesgos y de los planes de mitigación. 
  • Se necesita conocer cuando o donde se produce un cambio significativo en los atributos y la efectividad de los planes  de mitigación.
  • Las formas de proceder son las siguientes:
               – Replanificar: se requiere un plan nuevo o modificado cuando se excede un valor umbral.
             – Cerrar el riesgo: la probabilidad del riesgo es inferior al  valor umbral o el riesgo se convierte en un problema que se resuelve.
             – Invocar un plan de contingencia: se ha activado un disparador o se necesita realizar una acción. 
             – Continuar con el plan actual: no se requiere ninguna acción adicional porque todo está sucediendo como estaba previsto.
  • El control es un punto crucial  en la toma de decisiones sobre el proyecto.

Estimación de Riesgos

  • IDENTIFICACIÓN DE RIESGOS
La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario.

Grupo de riesgos:
  • Genéricos: son comunes a todos los proyectos. Son una amenaza potencial para los mismos.
  • Específicos: implican un conocimiento profundo del proyecto. Sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión.
Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista de comprobación se puede utilizar para identificar riesgos y se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:


1Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar.
  • Tamaño estimado del proyecto (LOC/PF)
  • Confianza en la estimación 
  • Número de programas, archivos y transacción
  • Tamaño relativo al resto del proyecto
  • Tamaño de la base de datos
  • Número de usuarios
  • Número de requerimientos previstos antes y después de la entrega
  • Cantidad de software utilizado

2. Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el mercado.
  • Efecto del producto en la cifra de ventas
  • Visibilidad desde la dirección de la organización
  • Fecha límite de entrega razonable
  • Número de clientes que usarán el producto
  • Sofisticación del usuario final
  • Cantidad y calidad de la documentación a entregar al cliente
  • Límites legales y gubernamentales
  • Costes asociados al retraso en la entrega

3. Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.
  • Hay experiencias anteriores con dicho cliente
  • Tiene una idea clara de lo que precisa
  • Habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos

4. Definición del proceso:  riesgos asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo.
  • Hay una política clara de normalización y seguimiento de una metodología
  • Existe una metodología escrita para el proyecto
  • Se ha utilizado en otros proyectos
  • Están los gestores y desarrolladores formados
  • Conoce todo el mundo los estandares
  • Se dispone de metricas de productividad 
  • Se dispone de metricas de calidad para todos los proyectos de software
  • Se utilizan herramientas para soportar la base de pruebas
  • Se utilizan herramientas para la gestión, generación y mantenimiento de la documentación

5. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto. 
  • Hay herramientas de gestión de proyectos
  • Hay herramientas de gestión del proceso de desarrollo
  • Se hace uso de una base de datos o repositorio centralizado

6. Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología punta que contiene el sistema.
  • Se trata de una tecnología nueva en la organización
  • Se requieren nuevos algoritmos o tecnologías de I/O
  • Se debe interactuar con hardware nuevo
  • Se debe interactuar con software que no ha sido probado
  • Se debe interactuar con una base de datos cuya funcionalidad y rendimiento no ha sido probada
  • Se deben utilizar métodos nuevos de análisis, diseño o pruebas

7. Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo.  
  • Es el mejor personal disponible
  • Tienen los miembros las técnicas aprobadas
  • Hay suficiente gente disponible
  • Está el personal comprometido en toda la duración del proyecto
  • Tiene el personal la necesaria formación

  • ANÁLISIS DE RIESGOS
Es el proceso de examinar los riesgos en detalle para  determinar su extensión,  sus interrelaciones y su importancia.

Las actividades básicas son:

       – Evaluación: mejor comprensión del riesgo. Se cuantifican los siguientes conceptos:
                          » Impacto: pérdida que ocasiona el riesgo.
                          » Probabilidad: probabilidad de que ocurra el riesgo.
                          » Marco de tiempo: periodo de tiempo  en el que es posible mitigar el riesgo.

      – Clasificación: se clasifican los riesgos para entender su naturaleza y elaborar planes de mitigación.

  • PRIORIZACIÓN DE RIESGOS
Es el proceso de ordenar los riesgos en función de su importancia para determinar cuales se deben solucionar antes y a cuales hay que asignarle más recursos.
  • Los riesgos pueden ordenarse según la magnitud de la  exposición al riesgo:                         Exposición al riesgo = f (magnitud del impacto,  probabilidad)
  •  La asignación de prioridades se realizará en el orden  resultante del paso anterior.
  • Hay que considerar la posibilidad de priorizar grupos de riesgos encadenados.
  • La asignación de prioridades  depende de la precisión y exactitud de las estimaciones de la magnitud del impacto y de la probabilidad del riesgo.
  • Las condiciones y prioridades pueden cambiar a lo largo del proyecto por lo que el  análisis y asignación de prioridades debe realizarse de manera continuada aprovechando la información disponible en cada momento.


26 de octubre de 2012

Análisis y Gestión de Riesgos


ESTRATEGIAS DE RIESGO PROACTIVAS VS. REACTIVAS

Reactiva: supervisa el proyecto en prevención de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas. Lo mas frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal.

Proactiva: empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una prioridad según su importancia. Después el equipo de software establece un plan para controlar el riesgo.

RIESGO DEL SOFTWARE

El riesgo siempre implica dos características:
  •  Incertidumbre: el acontecimiento que caracteriza al riego puede o no ocurrir.
  • Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas ó pérdidas.
Cuando se analizan los riegos es importante cuantificar el nivel de incertidumbre y grado de pérdida asociados a cada riego. Para hacerlo se consideran diferentes categorías de riesgos:

- Riesgos del proyecto: si se hacen realidad , es posible que la planificación temporal del proyecto se retrase y que los costos aumenten. Identifican problemas potenciales de presupuesto, calendario, personal, recursos,etc.

- Riesgos técnicos: amenazan la calidad y la planificación temporal del software (problemas de diseño, implementación, interfaz, verificación, mantenimiento, ambigüedades de especificaciones, incertidumbres técnica, etc).

- Riesgos del negocio: amenazan la viabilidad del soft a construir. A menudo ponen en peligro el proyecto o el producto.

  Candidatos para los 5 principales riesgos del negocio:

• Construir un producto o sistema excelente que no quiere nadie en realidad (riego de mercado)
• Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico)
• Construir un producto que el departamento de ventas no sabe cómo vender
• Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgos de       dirección)
• Perder presupuesto o personal asignado (riesgos de presupuesto)


Otra categorización general de los riesgos ha sido propuesta por Charette:

Los riesgos conocidos: son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo). 

Los riesgos predecibles: se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento). 

Los riesgos impredecibles: son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado.


COMPONENTES Y CONTROLADORES DEL RIESGO

En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

  • riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido;
  • riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto;
  • riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado;
  • riesgo de la planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto: despreciable, marginal, crítico y catastrófico.

20 de octubre de 2012

Ciclo de Vida de un Proyecto de Software

El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su fin. Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables.

La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente implica y, por lo general, está definida por alguna forma de transferencia técnica.

Generalmente, los productos entregables de una fase se revisan para verificar si están completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que una fase comience antes de la aprobación de los productos entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables.







FASES DE UN PROYECTO

Fase Inicial


Fase conceptual: Es la etapa donde nace la idea, se formula el proyecto al analizar los puntos clave, se toma la decisión favorable de iniciar actividades del proyecto, se establecen las metas, se hacen los principales nombramientos y asignaciones de recursos.

Consumo de Recursos: 5%

Producto: Acta de inicio, enunciado del alcance


Fases Intermedias

Fase organizacional: Contempla el período de planificar e idear la mejor forma de hacer realidad lo planteado en la fase conceptual. Se diseña la organización y constituye el equipo de proyecto, se buscan los recursos y se hace el plan maestro y detallado de actividades.

Consumo de Recursos: 15% - 20%

Producto: Plan integral del proyecto

Fase ejecutiva: En esta etapa es donde se ejecutan los trabajos principales del proyecto como el desarrollo de los programas, la construcción de las instalaciones, las pruebas, las entregas, etc.


Fase Final

Fase de completación: Es el período donde se terminan las actividades, se cierran los contratos se transfieren los recursos y compromisos a otras organizaciones, se hace la puesta en marcha, etc.

Consumo de Recursos: 15%

Producto: Acta de cierre del proyecto


CARACTERÍSTICAS DE LOS CICLOS DE VIDA DE UN PROYECTO
Los ciclos de vida del proyecto generalmente definen:

• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se debe realizar el trabajo del diseñador web?)

• Cuándo se deben generar los productos entregables en cada fase y cómo se revisa, verifica y valida cada producto entregable.

• Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere que los analistas estén involucrados en las fases de requisitos y de diseño)

• Cómo controlar y aprobar cada fase.


La mayoría de los ciclos de vida de proyectos comparten determinadas características comunes:


  • En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos. 
  • El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto. 
  • El nivel de coste y de personal es bajo al comienzo, alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión. 

  • El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el coste final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto.



19 de octubre de 2012

Gestión de Proyectos de Software

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.


PERSONAL: La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60. De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) «para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software».

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal  que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del  trabajo y desarrollo cultural y de espíritu de equipo.


  • Los participantes.
El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:

1.- Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
5.- Usuarios finales, que interaccionan con el software una vez que ha entregado para la producción.

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

  • Los jefes de equipo.
Weinberg sugiere que el éxito de los gestores de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas. Es decir, un gestor de proyectos de software debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.


Motivación. La habilidad para motivar (con un «tira y afloja») al personal técnico para que produzca conforme a sus mejores capacidades.
Organización. La habilidad para amoldar procesos existentes (o inventar unos nuevos) que permita al concepto inicial transformarse en un producto final.
Ideas o innovación. La habilidad para motivar al personal para crear y sentirse creativos incluso cuando deban de trabajar dentro de los límites establecidos para un producto o aplicación de software particular.
Incentivos por logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la iniciativa y los logros, y demostrar a través de sus propias acciones que no se penalizará si se corren riesgos controlados.
Influencia y construcción de espíritu de equipo. Un gestor de proyecto eficiente debe ser capaz de «leer» a la gente; debe ser capaz de entender señales verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas señales. El gestor debe mantener el control en situaciones de gran estrés.

  • El equipo de software.
Existen casi tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello.
Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:

1. n individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto.
2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen <<equipos>> informales.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales.

La <<mejor>> estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Mantei sugiere tres organigramas de equipo genéricos:

Descentralizado democrático (DD). Este equipo de ingeniería del software no tiene un jefe permanente. Más bien, <<se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas>>.

Descentralizado controlado (DC). Este equipo de ingeniería de software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas.

Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo.

Mantei describe siete factores de un proyecto que deberían considerarse cuando se planifica el organigrama de equipos de ingeniería del software:

· La dificultad del problema que hay que resolver.
· El tamaño del programa(s) resultante(s) en líneas de código o puntos de función.
· El tiempo que el equipo estará junto (tiempo de vida del equipo).
· El grado en que el problema puede ser modularizado.
· La calidad requerida y fiabilidad del sistema que se va a construir.
· La rigidez de la fecha de entrega.
· El grado de sociabilidad (comunicación) requerido para el proyecto.

Los equipos CC y DC producen menos defectos que los equipos DD, pero estos datos tienen mucho que ver con las actividades específicas de garantía de calidad que aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo tiempo son mejores cuando se precisa una gran cantidad de comunicación.

Constantine sugiere cuatro <<paradigmas de organización>> para equipos de ingeniería del software:

1.- Un paradigma cerrado estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC).

2.- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo.

3.- El paradigma abierto intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero también utiliza el paradigma aleatorio.

4.- El paradigma sincronizado se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Constantine propone una variación en el equipo descentralizado democrático defendiendo a los equipos con independencia creativa cuyo enfoque de trabajo podría ser mejor llamado <<anarquía innovadora>>. Para conseguir un equipo de alto rendimiento:

· Los miembros del equipo deben confiar unos en otros.
· La distribución de habilidades debe adecuarse al problema.
· Para mantener la unión del equipo, los inconformistas tienen que ser excluidos del mismo.

  • Aspectos sobre la coordinación y la comunicación.

Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbre es corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto. La interoperatividad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.

Estas características del software moderno, son aspectos de la vida. Para enfrentarse a ellos eficazmente, un equipo de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre múltiples equipos.


PRODUCTO: El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.

  • Ámbito del software.
El ámbito se define respondiendo a las siguientes cuestiones:

Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?

Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?

Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

  • Descomposición del problema.
La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.


PROCESO: El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software.


  • Maduración del producto y del proceso.
La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:

· Comunicación con el cliente: tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación: tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo: tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería: tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega: tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente: tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.



  • Descomposición del proceso
Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.



PROYECTO: Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:

1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.


16 de octubre de 2012

Fases Genéricas de la Ingeniería del Software

Fase de Definición: se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: ingeniería de sistemas o de información, planificación del proyecto del software y análisis de los requisitos.

Fase de Desarrollo: se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: diseño del software, generación de código y prueba del software.

Fase de Mantenimiento: se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:
  • Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.
  •  Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.
  •  Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos  funcionales originales.
  •  Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Las fases y los pasos relacionados descritos se complementan con un número de actividades protectoras. Entre las actividades típicas de esta categoría se incluyen:

     - Seguimiento y control del proyecto de software
     - Revisiones técnicas formales
     - Garantía de calidad del software
          -  Gestión de configuración del software
          -  Preparación y producción de documentos
     Gestión de reutilización
     Mediciones
     - Gestión de riesgos

12 de octubre de 2012

Capas de la Ingeniería del Software

La Ingeniería del software es un tecnología multicapa. Cualquier enfoque de ingeniería (incluida ingeniería del software) debe apoyarse sobre un compromiso de organización de calidad.





PROCESO: El fundamento de la ingeniería del software es la capa de proceso. El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de Áreas clave de proceso (ACPs) que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software. Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

MÉTODOS: Los métodos de la ingeniería del software indican «cómo» construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Los métodos de la ingeniería del software dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas. 

HERRAMIENTAS: Las herramientas de la Ingeniería del software proporcionan un enfoque automático o semi-automático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (CASE).

Ingeniería de Software

Aunque cientos de autores han desarrollado definiciones personales de la ingeniería del software, una definición propuesta por Fritz Bauer en una conferencia de gran influencia sobre estos temas va a servir como base de estudio:

[La ingeniería del software] es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

No dice mucho sobre los aspectos técnicos de la calidad del software; no se enfrenta directamente con la necesidad de la satisfacción del cliente o de la entrega oportuna del producto; omite la mención de la importancia de mediciones y métricas; tampoco expresa la importancia de un proceso avanzado. Y sin embargo, la definición de Bauer nos proporciona una línea base. ¿Cuáles son los «principios robustos de la ingeniería» aplicables al desarrollo de software de computadora? ¿Cómo construimos el software «económicamente» para que sea «fiable»? ¿Qué se necesita para crear programas de computadora que funcionen «eficientemente» no en una máquina si no en diferentes «máquinas reales»? Éstas son cuestiones que siguen siendo un reto para los ingenieros del software.

El IEEE [IEE93] ha desarrollado una definición más completa:

Ingeniería del software: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques como en (1).

Crisis del Software

El término crisis del software se usó desde finales de 1960 hasta mediados de 1980 para describir los frecuentes problemas que aparecían durante el proceso de desarrollo de nuevo software. Tras la aparición de nuevo hardware basado en circuitos integrados, comenzaron a desarrollarse sistemas y aplicaciones mucho más complejos que hasta entonces no era posible construir puesto que el hardware disponible no lo permitía. Estos nuevos proyectos de desarrollo de software, en la mayoría de ocasiones, no se terminaban a tiempo, lo cual también provocaba que el presupuesto final del software excediera de aquel que se había pactado. Algunos de estos proyectos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. Además, en muchos casos el software no daba respuesta a las verdaderas necesidades del cliente o había que ser un usuario experto para poder utilizarlo, todo ello sumado a que el mantenimiento de los productos era complejo y muy costoso.

El software no se producía como el hardware, que tenía un proceso de fabricación definido y dividido en fases. El resultado eran productos de pésima calidad en los que se habían invertido mucho tiempo y dinero pero que o bien no llegaban a terminarse o bien a la larga no daban el resultado que se esperaba. Se detectó que los métodos de desarrollo de software informales que hasta entonces habían bastado para proyectos pequeños no eran suficientes para los nuevos y grandes proyectos, y que se necesitaban profesionales especializados en esta nueva disciplina que fueran capaces de lidiar con la creciente complejidad de los nuevos sistemas.

Una de las primeras y más conocidas referencias a los conceptos crisis el software e ingeniería del software fue hecha por Edsger Dijkstra, durante la presentación de 1972 titulada “The Humble Programmer” en la Association for Computing Machinery, cuando se le hizo entrega de un Premio Turing.

Durante décadas, resolver la crisis del software desencadenó en que compañías e investigadores produjeran más y más herramientas software. Cada nueva tecnología o práctica que apareció entre 1970 y 1990 fue tratada como una “bala de plata” (en inglés, silver bullet) que solucionaría la crisis del software.

En 1986, Fred Brooks publicó el artículo No Silver Bullet, argumentando que ninguna tecnología o práctica por sí misma podría mejorar en un diez por ciento la productividad en los siguientes diez años. El debate sobre las balas de plata continuó durante la siguiente década, dando lugar a numerosas interpretaciones sobre el artículo de Brooks.

Los defensores de lenguajes como Ada, o de los procesos software continuaron apostando por que su tecnología sería la que solucionaría la crisis. Sin embargo, hubo gente que interpretó el hecho de que no se encontrara una solución única y efectiva al cien por cien como un fracaso de la ingeniería del software.

Si bien es cierto que la búsqueda de una única solución no funcionó, también había que ser consciente de que tampoco existían balas de plata en ninguna otra profesión. Así, con el transcurso de los años, casi todo el mundo aceptó que no se encontraría ninguna bala de plata, pero se tomó esto como una prueba de que la ingeniería del software finalmente había madurado y que los proyectos debían tener éxito gracias al trabajo duro y al esfuerzo. El campo de la ingeniería del software es demasiado complejo y diverso para que una única solución resuelva todos los problemas, pero el conjunto de todas las prácticas que surgieron y de las que surgen hoy en día son las que, bien aplicadas, permiten que la ingeniería del software desarrolle productos de calidad.

Video Crisis del Software


9 de octubre de 2012

Mitos del Software

Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron información errónea y confusión. Los mitos del software tienen varios atributos que los hacen insidiosos: por ejemplo, aparecieron como declaraciones razonables de hechos (algunas veces conteniendo elementos verdaderos), tuvieron un sentido intuitivo y frecuentemente fueron promulgados por expertos que «estaban al día».


MITOS DE GESTIÓN. Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Igual que se agarra al vacío una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia sólo disminuya la presión temporalmente.

Mito. Tenemos ya un libro que está lleno de estándares y procedimientos para construir software, ¿no le proporciona ya a mi gente todo lo que necesita saber?

Realidad. Está muy bien que el libro exista, pero se usa?.¿conocen los trabajadores su existencia?,refleja las prácticas modernas de desarrollo de software?, ¿es completo?, ¿está diseñado para mejorar el tiempo de entrega mientras mantiene un enfoque de calidad? En muchos casos, la respuesta a todas estas preguntas es «no».

Mito. Mi gente dispone de las herramientas de desarrollo de software más avanzadas, después de todo, les
compramos las computadoras más modernas.

Realidad. Se necesita mucho más que el último modelo de computadora grande o de PC para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE) son más importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores del software todavía no las utilicen eficazmente.

Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el llamado algunas veces «concepto de la horda Mongoliana»).

Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks: «...añadir gente a un proyecto de software retrasado lo retrasa aún más». Al principio, esta declaración puede parecer un contrasentido. Sin embargo, cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero sólo de una manera planificada y bien coordinada.


MITOS DEL CLIENTE. Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software.

Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas podemos dar los detalles más adelante.

Realidad. Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista.

Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.

Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el coste. Cuando los cambios se solicitan durante el diseño del software, el impacto en el coste crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño; es decir, coste adicional. Los cambios en la función, rendimiento, interfaces u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante sobre el coste. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.


MITOS DE LOS DESARROLLADORES. Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.

Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.

Realidad. Alguien dijo una vez: «cuanto más pronto se comience a escribir código, más se tardará en terminarlo». Los datos industriales indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez.

Mito. Hasta que no tengo el programa «ejecutándose», realmente no tengo forma de comprobar su calidad.

Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un «filtro de calidad» que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos en el software.

Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando.

Realidad. Un programa que funciona es sólo una parte de una configuración del software que incluye muchos elementos. La documentación proporciona el fundamento para un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software. 

Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.











La Evolución del Software

Hoy en día el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículo para entregarlo. Como producto, hace entrega de la potencia informática que incorpora el hardware informático o, más ampliamente, una red de computadoras que es accesible por hardware local. Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia. Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y entornos).

El papel del software informático ha sufrido un cambio significativo durante un periodo de tiempo superior a 50 años. Enormes mejoras en rendimiento del hardware, profundos cambios de arquitecturas informáticas, grandes aumentos de memoria y capacidad de almacenamiento y una gran variedad de opciones de entrada y salida han conducido a sistemas más sofisticados y más complejos basados en computadora. La sofisticación y la complejidad pueden producir resultados deslumbrantes cuando un sistema tiene éxito, pero también pueden suponer grandes problemas para aquellos que deben construir sistemas complejos.

Libros populares publicados durante los años 70 y 80 proporcionan una visión histórica útil dentro de la percepción cambiante de las computadoras y del software, y de su impacto en nuestra cultura. Osborne hablaba de una «nueva revolución industrial». Toffler llamó a la llegada de componentes microelectrónicos la «tercera ola del cambio» en la historia de la humanidad, y Naisbitt  predijo la transformación de la sociedad industrial a una «sociedad de información ». Feigenbaum y McCorduck sugirieron que la información y el conocimiento (controlados por computadora) serían el foco de poder del siglo veintiuno, y Stoll argumentó que la «comunidad electrónica » creada mediante redes y software es la clave para el intercambio de conocimiento alrededor del mundo.

Al comienzo de los años 90, Toffler describió un «cambio de poder» en el que las viejas estructuras de poder (gubernamentales, educativas, industriales, económicas y militares) se desintegrarían a medida que las computadoras y el software nos llevaran a la democratización del conocimiento». A Yourdon le preocupaba que las compañías en Estados Unidos pudieran perder su competitividad en empresas relativas al software y predijo «el declive y la caída del programador americano». Hammer  y Champy argumentaron que las tecnologías de información iban a desempeñar el papel principal en la ingeniería de la compañía». A mediados de los años 90, la persistencia de las computadoras y del software generó una erupción de libros por «neo-Luddites» (por ejemplo: Resisting the Virtual Life, editado por James Brook y Ian Boal, y The Future Does not Compute de Stephen Talbot). Estos autores critican enormemente la computadora, haciendo énfasis en preocupaciones legítimas pero ignorando los profundos beneficios que se han llevado a cabo. Al final de los años 90, Yourdon volvió a evaluar las perspectivas del software profesional y sugirió la «resurrección y elevación» del programador americano.
A medida que internet creció en importancia, su cambio de pensamiento demostró ser correcto. Al final del siglo veinte, el enfoque cambió una vez más. Aquí tuvo lugar el impacto de la «bomba de relojería». Aunque muchos vieron las predicciones de los críticos del Y2K como reacciones, sus populares lecturas devolvieron la difusión del software a sus vidas.

Hoy en día, «la computación omnipresente» ha producido una generación de aplicaciones de información que tienen conexión en banda ancha a la Web para proporcionar «una capa de conexión sobre nuestras casas, oficinas, y autopistas». El papel del software continúa su expansión.
El programador solitario de antaño ha sido reemplazado por un equipo de especialistas del software, cada uno centrado en una parte de la tecnología requerida para entregar una aplicación concreta.



6 de octubre de 2012

Bibliografía

  • Pressman Séptima o Sexta edición.
  • Mario Piattini. Medición y estimación del software. Alfa y Omega 2007.
  • Lan Sommeville.Ingeniería de Software. Peason.
  • Beind Bruegge. Ingeniería de Software Orientada a Objetos. Printice Hal 2002.
  • Steve Mc Conell. Desarrollo de Proyectos Informáticos. Mc Graw Hill.

Objetivos Generales

  • Conocer las actividades para desarrollar un software de calidad.
  • Aplicar los conceptos dados en el desarrollo de un software de calidad. 

Contenido

I. Introducción.
II. Gestión de proyectos de software.
III. Modelos de evaluación de calidad de proceso-producto.
IV. Aseguramiento de calidad.
V. Pruebas del software.
VI. Mantenimiento del software.

Trabajos y Talleres


Trabajo_independiente(1)