La Administración de la Configuración del Software (SCM) es la disciplina de identificar la configuración de un sistema en distintos puntos en el tiempo, con el propósito de controlar sistemáticamente cambios en la configuración del software y mantener la integridad y la rastreabilidad de la configuración a través del ciclo de vida del sistema. Esta área del conocimiento incluye seis subáreas.
La primera subárea es la administración del proceso de SCM. Cubre los tópicos del contexto de la organización para SCM, las restricciones y las guías para SCM, planeando para SCM, el plan mismo del SCM y la vigilancia del SCM.
La segunda subárea es la identificación de la configuración del software, la cual identifica los elementos que se controlarán, establece esquemas de identificación para los elementos y sus versiones, y establece las herramientas y las técnicas que se utilizarán en la adquisición y manejo de los artículos controlados. Los tópicos en esta subárea son, primero la identificación de los artículos que se controlarán y la biblioteca del software.
La tercera subárea es el control de la configuración del software, que es la administración de cambios durante el ciclo de vida del software. Los asuntos son, primero, solicitando, evaluando y aprobando los cambios al software, y segundo, implementar los cambios al software, y tercero, desviaciones y renuncias.
La cuarta subárea es contabilización del estado de la configuración del software. Sus tópicos son información de estado de la configuración del software y reportes de estado.
La quinta subárea es la revisión de la configuración del software. Que consiste en revisión de la configuración funcional del software, revisión de la configuración física del software y de revisiones en proceso de una línea base del software.
La última subárea es la administración de versiones y entrega, que cubre la construcción de software y la administración de versiones.
viernes, 31 de diciembre de 2010
Aseguramiento de la calidad dentro de un proyecto de software
La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar su valor. Está cuantificada por el valor que se le da al conjunto de propiedades seleccionadas. De esta manera la calidad es subjetiva y, como dice James Bach, es circunstancial. Es subjetiva porque depende de los atributos elegidos para medirla y es circunstancial porque el conjunto de atributos elegidos puede variar en situaciones diferentes.
Cuando aplicamos el concepto de calidad al software, éste deja de ser subjetivo porque se determinan cuales son los atributos de calidad del software. Pero no deja de ser accidental ya que en ciertas situaciones, un determinado conjunto de características de calidad puede ser más importante que en ciertas otras.
Resumiendo, la calidad del software es medible y varía de un sistema a otro o de un
Cuando aplicamos el concepto de calidad al software, éste deja de ser subjetivo porque se determinan cuales son los atributos de calidad del software. Pero no deja de ser accidental ya que en ciertas situaciones, un determinado conjunto de características de calidad puede ser más importante que en ciertas otras.
Resumiendo, la calidad del software es medible y varía de un sistema a otro o de un
Verificación, validación y pruebas.
La verificación se reduce a confirmar que se están uniendo justo las componentes que
se planteo ensamblar, justo en la forma que se planeo ensamblarlas.
La “validación” pregunta si se “construye lo correcto”.
Las pruebas de funciones y módulos se ejecutan de dos maneras. La primera vez se
aíslan como pruebas de unidades. La segunda, en el contexto de toda la aplicación.
Pruebas de unidades en el contexto:
• Deben crearse controladores para realizar las pruebas de unidades de
funciones y clases, con la posibilidad de errores innecesarios y cobertura
incompleta.
• Es posible probar otros módulos.
• Las pruebas de interfaz confirman la validez de las interfaces entre los
módulos.
• El propósito de las pruebas de regresión es verificar que las adiciones al
sistema no hayan degradado las capacidades preexistentes.
• La prueba de integración se realiza sobre un sistema parcialmente construido
para verificar que el resultado de integrar software adicional opera como se
planeo.
• La prueba del sistema se realiza en toda la aplicación o en las versiones
designadas. Las pruebas del sistema y de integración se realizaron contra la
arquitectura.
• Las pruebas de uso validan la aceptación de la aplicación por los usuarios
finales.
• La prueba de instalación se hace con la aplicación instalada en la plataforma
dada.
• El cliente hace las pruebas de aceptación para validar la aceptación de la
aplicación.
se planteo ensamblar, justo en la forma que se planeo ensamblarlas.
La “validación” pregunta si se “construye lo correcto”.
Las pruebas de funciones y módulos se ejecutan de dos maneras. La primera vez se
aíslan como pruebas de unidades. La segunda, en el contexto de toda la aplicación.
Pruebas de unidades en el contexto:
• Deben crearse controladores para realizar las pruebas de unidades de
funciones y clases, con la posibilidad de errores innecesarios y cobertura
incompleta.
• Es posible probar otros módulos.
• Las pruebas de interfaz confirman la validez de las interfaces entre los
módulos.
• El propósito de las pruebas de regresión es verificar que las adiciones al
sistema no hayan degradado las capacidades preexistentes.
• La prueba de integración se realiza sobre un sistema parcialmente construido
para verificar que el resultado de integrar software adicional opera como se
planeo.
• La prueba del sistema se realiza en toda la aplicación o en las versiones
designadas. Las pruebas del sistema y de integración se realizaron contra la
arquitectura.
• Las pruebas de uso validan la aceptación de la aplicación por los usuarios
finales.
• La prueba de instalación se hace con la aplicación instalada en la plataforma
dada.
• El cliente hace las pruebas de aceptación para validar la aceptación de la
aplicación.
Arquitectura de software-modelo, marcos de trabajo y patrones de diseño
Arquitectura del software de un programa o de un cálculo el sistema es la estructura o las estructuras del sistema, que abarcan componentes de software, las características externaly visibles de esos componentes, y las relaciones entre ellas.
El término también refiere a la documentación de una arquitectura del software del sistema.
La documentación de arquitectura del software facilita la comunicación en medio tenedores de apuestas, las decisiones tempranas de los documentos sobre diseño de alto nivel, y permiten la reutilización de los componentes y de los patrones del diseño entre los proyectos.
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características.
Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
El término también refiere a la documentación de una arquitectura del software del sistema.
La documentación de arquitectura del software facilita la comunicación en medio tenedores de apuestas, las decisiones tempranas de los documentos sobre diseño de alto nivel, y permiten la reutilización de los componentes y de los patrones del diseño entre los proyectos.
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características.
Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Metricas del Software
En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad.
El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión.
1.¿Cuáles son las métricas apropiadas para el proceso y para el producto?
2.¿Cómo se deben utilizar los datos que se recopilan?
3.¿Es bueno usar medidas para comparar gente, procesos o productos?
Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo que no se ha medido en el pasado.
La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas.
Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
El principio, podría parecer que la necesidad de la medición e s algo evidente. Después de todo es lo que nos permite cuantificar y por consiguiente gestionar de forma más efectiva. Pero la realidad puede ser muy deferente. Frecuentemente la medición con lleva una gran controversia y discusión.
1.¿Cuáles son las métricas apropiadas para el proceso y para el producto?
2.¿Cómo se deben utilizar los datos que se recopilan?
3.¿Es bueno usar medidas para comparar gente, procesos o productos?
Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo que no se ha medido en el pasado.
La medición es muy común en el mundo de la ingeniería. Medimos potencia de consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos por mencionar algunos aspectos. Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería del software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar las medidas.
Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
Administracion de Riesgos
La Administración de Riesgos es un proceso realizado por personas que involucra a toda la organización. Identifica eventos potenciales que afecten a la empresa y maneja los riesgos según su aceptación o apetito de riesgo, dando seguridad razonable a la empresa.
Horwath Castillo Miranda no sólo ayuda a las compañías a evaluar los riesgos de negocios que enfrentan, ni sólo recomienda estrategias para reducir su exposición, sino les muestra cómo transformar las funciones de auditoría interna para que, además de enfocarse en el cumplimiento legal y de regulación, logren un acercamiento al manejo del riesgo empresarial.
Hoy, el sólo cumplimiento con requisitos reguladores no resolverá suficientemente las demandas de inversionistas y accionistas. Nuestra Firma ha desarrollado estrategias dirigidas a ayudar a nuestros clientes a transformar su programa tradicional de auditoría interna en un correcto entendimiento del manejo del riesgo empresarial.
Horwath Castillo Miranda no sólo ayuda a las compañías a evaluar los riesgos de negocios que enfrentan, ni sólo recomienda estrategias para reducir su exposición, sino les muestra cómo transformar las funciones de auditoría interna para que, además de enfocarse en el cumplimiento legal y de regulación, logren un acercamiento al manejo del riesgo empresarial.
Hoy, el sólo cumplimiento con requisitos reguladores no resolverá suficientemente las demandas de inversionistas y accionistas. Nuestra Firma ha desarrollado estrategias dirigidas a ayudar a nuestros clientes a transformar su programa tradicional de auditoría interna en un correcto entendimiento del manejo del riesgo empresarial.
Personal Software Process(PSP)
Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
Nivel 1 - inicial:
Nivel 2 - repetible:
Nivel 3 - Definido:
Nivel 4 - Controlado:
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
Nivel 1 - inicial:
Nivel 2 - repetible:
Nivel 3 - Definido:
Nivel 4 - Controlado:
Modelo de madurez de capacidad
El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
•Definidas en un procedimiento documentado
•Provistas (la organización) de los medios y formación necesarios
•Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
•Medidas
•Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de América (en particular del Departamento de Defensa, DoD), desarrolló una primera definición de un modelo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1) se publicó en febrero de 1993.
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
•Definidas en un procedimiento documentado
•Provistas (la organización) de los medios y formación necesarios
•Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
•Medidas
•Verificadas
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
Antipatrones de la administración de proyectos
Un antipatrón es una solución negativa a un problema de desarrollo de software. Existen antipatrones de administración, diseño, programación, gestión de proyectos.
Los anti-patrones, también llamados trampas, son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una auditoria.
El término anti-patrón se origina como una contra parte al término patrón, acuñado en arquitectura de software, para definir las buenas prácticas de programación, diseño o gestión de sistemas. De tal manera podríamos hablar de que un sistema “bien hecho” está lleno de patrones, y debería carecer de anti-patrones; al menos ese sería un sistema ideal.
Los anti-patrones, también llamados trampas, son ejemplos bien documentados de malas soluciones para problemas. Se estudian a fin de poderlos evitar en el futuro, y en su caso, para que su presencia pueda ser reconocida fácilmente al investigar sistemas disfuncionales durante una auditoria.
El término anti-patrón se origina como una contra parte al término patrón, acuñado en arquitectura de software, para definir las buenas prácticas de programación, diseño o gestión de sistemas. De tal manera podríamos hablar de que un sistema “bien hecho” está lleno de patrones, y debería carecer de anti-patrones; al menos ese sería un sistema ideal.
Aseguramiento de la calidad de software
Aseguramiento de la calidad de software
Determina si las necesidades de los usuarios están siendo satisfechas adecuadamente. Además de determinar los costos que puede causar el añadir ciertas características al producto. Se deben de evaluar tres áreas:
Objetivos: De cualquier usuario deben de estar en armonía con los objetivos de la organización.
Métodos: Deben contener u observar las políticas, procedimientos y estándares de la organización,
Ejecución: Optimización del uso de hardware y software al implementar los productos de software.
¿Qué es la calidad del Software?
Conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro.
¿Cómo Obtener un Software de Calidad?
Implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.
Como controlar la calidad del Software
Es necesario, ante todo, definir los parámetros, indicadores o criterios de medición.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los siguientes pasos:
Definir el software que va a ser controlado
Seleccionar una medida que pueda ser aplicada al objeto de control.
Crear o determinar los métodos de valoración de los indicadores
Definir las regulaciones organizativas para realizar el control
Integración, verificación y validación del software
Integración e software
Es imprescindible poder integrar los desarrollos de software en forma de productos y soluciones para que puedan ponerse en uso.
Algunas tareas que suelen realizarse con la integración del software es la creación de paquetes, la creación de distribuciones clásicas o de distribuciones «live», la integración de servicios para entornos de trabajo en grupo, migraciones de sistemas, etc.
Verificación del software
Verificación del software es una disciplina amplia y compleja de tecnología de dotación lógica de quién meta es asegurar que el software satisface completamente todos los requisitos previstos.
Hay dos acercamientos fundamentales a la verificación:
· Verificación dinámica, también conocido como prueba o Experimentación
· Verificación estática, también conocido como Análisis
Verificación dinámica (prueba, experimentación)
La verificación dinámica se realiza durante la ejecución del software, y comprueba dinámicamente su comportamiento; se conoce comúnmente como Prueba fase.
Verificación estática (análisis)
La verificación estática es el proceso de comprobar que el software resuelve requisitos haciendo una inspección física de él.
Validación del software
Es necesaria ya que proporciona un alto grado de confianza y seguridad en el software y en los resultados que se obtienen al aplicarlo.
Principios generales para validación
Especificación de los requisitos: Es la base para la validación.
Prevención de defectos: Es donde se fija la atención, la complejidad de la mayoría de software impiden que sea probado exhaustivamente sin embargo es una actividad necesaria.
Tiempo y esfuerzo: Debe comenzarse con anticipación la conclusión final que muestre que el software fue validado debe estar basada en evidencia recolectada.
Ciclo de vida del software: Contiene las tareas de ingeniería de software y la documentación necesaria para soportar la validación del software.
Planificación: Define lo que será logrado a través del proceso de validación de software, y especifican aspectos tales como el alcance, el método de validación, los recursos, el cronograma etc.
Procedimientos: Establecen el cómo, quién, y cuando se llevara a cabo la validación del software
Validación del software después de un cambio: Un cambio pequeño puede tener un impacto significativo, el estado de validación debe ser restablecido cuando surjan cambios.
Alcance de la validación: Debe estar basado en la complejidad del software y en los riesgos, la selección de las actividades y tareas a llevar a cabo durante la validación deben corresponderse con la complejidad del software.
Arquitectura de software
Arquitectura de software
Es la estructura o estructuras del sistema que comprende los componentes de software, las propiedades visibles de esos componentes y las relaciones entre ellos.
Objetivos
· Comprender y mejorar la estructura de las aplicaciones complejas.
· Reutilizar dicha estructura (o partes de ella) para resolver problemas similares.
· Planificar la evolución de la aplicación, identificando las partes mutables e inmutables de la misma, así como los costes de los posibles cambios.
· Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales.
· Permitir el estudio de alguna propiedad específica del dominio.
Modelos
Modelos estructurales: Sostienen que la AS está compuesta por componentes, conexiones entre ellos y (usualmente) otros aspectos tales como configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes.
Modelos de framework: Su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición.
Modelos dinámicos: Enfatizan la cualidad conductual de los sistemas. “Dinámico” puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de la computación, tales como valores cambiantes de datos.
Modelos de proceso: Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa construcción.
Modelos funcionales: Una minoría considera la arquitectura como un conjunto de componentes funcionales, organizados en capas que proporcionan servicios hacia arriba.
Marcos
Marcos de trabajo: Definen una arquitectura adaptada a las particularidades de un determinado dominio de aplicación, definiendo de forma abstracta una serie de componentes y sus interfaces y estableciendo las reglas y mecanismos de interacción entre ellos.
Marcos de trabajo de caja blanca: Que se extienden mediante herencia, concretamente mediante la implementación de las clases y métodos abstractos definidos como puntos de entrada.
Marcos de trabajo de caja de cristal: Admiten la inspección de su estructura e implementación, pero no su modificación ni extensión, excepto en los puntos de entrada.
Marcos de trabajos horizontales: Válidos para todos los dominios de aplicación concretados en un aspecto del sistema.
Marcos de trabajo verticales: Desarrollados específicamente para un dominio de aplicación.
Patrones de diseño
Un patrón es una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparecen repetidamente en algún campo.
Métrica de software
Métrica de software
¿Qué es?
Las métricas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento
Las métricas del software es un término que se asigna a un amplio rango de actividades diversas.
En software hay tres clases de entidades cuyos atributos podemos querer medir:
Procesos: Son actividades software que normalmente conllevan el factor tiempo.
Productos: son entregables, artefactos o documentos generados en el ciclo de vida del software. Recursos: son todos aquellos elementos que hacen de entrada a la producción software.
Las métricas Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
MÉTRICAS TÉCNICAS: Se centran en las características de software pro ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo esta hecho.
MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente.
MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar.
MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla.
Administración de riesgos
Administración de Riesgos
Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar estos y crear planes para minimizar sus efectos en el proyecto se llama administración de riesgos. La metodología del Proceso Unificado de Desarrollo brinda una estructura que permite caracterizar un riesgo, (Nombre del Riesgo, Magnitud, Descripción, Impacto, Indicador, Estrategia de Anulación, Estrategia de Mitigación, Plan de Contingencia.
Se cuenta con una estrategia de anulación que persigue reducir la probabilidad de que el riesgo surja; así como una estrategia de mitigación que significa reducir el impacto del mismo; en el caso que esta última no sea efectiva, se cuenta con un plan de contingencia.
Características de los riesgos de software
· Incertidumbre. Pueden o no ocurrir.
· Pérdida. Si el riesgo se cumple, habrán consecuencias no deseadas o pérdidas.
Tipos de riesgos
Riesgos del proyecto. Amenazan el plan del proyecto, si los riesgos se presentan, es probable que la planeación se atrase y los costos aumenten.
Riesgos técnicos. Amenazan la calidad y la planeación temporal, si los riesgos se presentan, la implementación puede ser difícil o imposible.
Riesgos del negocio. Amenazan la viabilidad del software a construir. Ponen en peligro al proyecto al producto.
Riesgo de mercado. Construir un producto que nadie quiera.
Riesgo estratégico. Construir un producto que no encaje en la estrategia comercial de la empresa.
Riesgo de ventas. Construir un producto que el departamento de ventas no sepa cómo vender.
Riesgo de dirección. Perder el apoyo de la dirección por cambio de personal o de enfoque.
Riesgo de presupuesto. Perder presupuesto o personal asignado.
jueves, 30 de diciembre de 2010
Aseguramiento de la Calidad dentro de un Proyecto de Software
Aseguramiento de la Calidad dentro de un Proyecto de Software
Ante todo se debe conocer:
- Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la
confianza adecuada de que un producto o servicio satisfará los requerimientosdados sobre calidad". - Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el
producto (software) satisfará los requisitos dados de calidad.
El aseguramiento de calidad del software se diseña para cada
La garantía, puede confundir con garantía de productos, mientras que el aseguramiento pretende
El aseguramiento de calidad del software está
- Métodos y herramientas de análisis,
diseño ,programación y prueba. - Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software.
- Estrategias de prueba multiescala.
- Control de la documentación del software y de los
cambios realizados. - Procedimientos para ajustarse a los estándares (y
dejar clarocuando se está fuera de ellos). - Mecanismos de medida (métricas).
- Registro de auditorias y realización de informes.
Las actividades para el aseguramiento de calidad del software se detallan en:
- Métricas de software para el control del
proyecto . - Verificación y validación del software a lo largo del ciclo de
vida (Incluye las pruebas y los procesos de revisión e inspección). - La gestión de la configuración del software.
Algunos métodos del aseguramiento:
- Revisiones técnicas y de gestión (su objetivo es la evaluación).
- Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto correcto?.
- Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto correctamente?.
- Auditorias (su objetivo es la confirmación del cumplimiento).
Adriana Esther Moreno Martínez Grupo C
Arquitectura de Software
Arquitectura de Software
Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.
- Definir los módulos principales
- Definir las responsabilidades que tendrá cada uno de estos módulos
- Definir la interacción que existirá entre dichos módulos:
- Control y flujo de datos
- Secuenciación de la información
- Protocolos de interacción y comunicación
- Ubicación en el hardware
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.
Modelos
Modelos Estructurales: representan la arquitectura como una colección organizada de componentes.
Modelos Frameworks: identifican patrones de diseño arquitectónico repetibles que se encuentran en aplicaciones similares.
Modelos Dinámicos: muestran los aspectos del comportamiento dinámico de la arquitectura, indicando cómo la estructura o la configuración del sistema pueden cambiar en función de eventos externos.
Modelos de Procesos: se enfocan en el diseño de los procesos del negocio que el sistema debe soportar.
Modelos Funcionales: pueden utilizarse para representar la jerarquía funcional de un sistema.
Patrones de Diseño
"Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a este problema, de tal ,modo que esta solución se pueda aplicar esta solución un millón de veces, sin hacer lo mismo
Los patrones de diseño hacen que sea más fácil reutilizar
Los patrones de creación tienen que
Adriana Esther Moreno Martínez Grupo C
Administración de Riesgos
Administración de Riesgos
Se llama administración de riesgos a la aplicación de estrategias para evitar o reducir los costes generados por los riesgos.
Esto se logra con el diseño e implantación de: EstrategiasSon los compromisos que establecen las personas para crear una política de riesgos. Sobre ésta se define la estrategia de negocio, el nivel de riesgo tolerable y al responsable de mitigar cada riesgo. ProcesosSe refieren al enfoque sistemático para evaluar los distintos tipos de riesgo que se enfrentan de forma integral. La clave para una correcta evaluación de riesgos consiste en:
EstructurasEs la forma en que se organiza una entidad y cómo aplica sus recursos y técnicas para cumplir con las estrategias. La Administración de Riesgos concierne a todos los miembros de una entidad e involucra a todos sus niveles de organización. Su actividad no es estática, ya que siempre habrá nuevos y diferentes riesgos al estar dentro de un entorno cambiante. |
Adriana Esther Moreno Martínez Grupo C
Personal Software Process (PSP)
Personal Software Process (PSP)
Es una técnica probada para mejorar el funcionamiento y la productividad individuales de los ingenieros. Surge de la necesidad que tiene los individuos programadores de automatizar sus procesos.
Ayuda a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería del software, enseñándoles a planificar y dar seguimiento a un trabajo, utilizar un proceso bien definido y medido, a establecer metas mesurables y finalmente a rastrear constantemente para obtener las metas definidas.
Los siguientes son los niveles y las KPAs que se manejan en cada uno:
Nivel 2 - Inicial:
· Seguimiento y control de proyectos
· Planeación de los proyectos
· Nivel 3 - Repetible:
· Revisión entre colegas.
· Ingeniería del producto de software.
· Manejo integrado del software.
· Definición del proceso de software.
· Foco del proceso de software
Nivel 4 - Definido:
· Control de calidad.
· Administración cuantitativa del proyecto.
· Nivel 5 - Controlado:
· Administración de los cambios del proceso.
· Administración del cambio tecnológico.
· Prevención de defectos.
Su objetivo es proporcionar un marco para el personal De procesos de software, no para enseñar las características específicas de los distintos ámbitos del proceso.
Gastos personales
Los gastos personales de un PSP son los siguientes.
• El tiempo necesario para aprender y utilizar.
• El coste emocional de mantener la necesaria disciplina.
• El riesgo potencial para su ego.
Beneficios
• El conocimiento obtenido en sus talentos y habilidades.
• La estimulación de un casi ilimitado flujo de las ideas.
• El marco que ofrece para la mejora personales.
• El grado de control que usted gane más de su trabajo.
• El sentimiento de orgullo y de logro.
• Un mejor base para un trabajo en equipo eficaz.
• La condena a hacer el trabajo de la manera que usted debe saber
Modelos de madurez de capacidades
Modelos de madurez de capacidades
¿Qué es?
Es un conjunto de áreas clave del proceso, que describen las funciones de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica, agrupadas en cinco niveles inclusivos.
En las Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
El primer nivel (Caos)
Está caracterizado por una aproximación intuitiva al proceso de desarrollo del software. El éxito depende del esfuerzo individual.
En el segundo nivel (Repetible)
La madurez metodológica de la organización permite estimar fiablemente el tamaño funcional o físico del sistema, así como recursos, esfuerzo, costes y calendario.
El tercer nivel (Definido)
Se conoce la forma de construcción del sistema.
El cuarto nivel (Medible) o gestionado
Se añade la gestión a un proceso definido. Se usa realimentación desde las primeras actividades del proyecto para seleccionar prioridades en las actividades actuales y conocer cómo se emplean los recursos.
El quinto nivel (Mejora continua) u optimizado
Existe una mejora continua de los procesos. Las medidas de actividades se usan para mejorar el proceso, eliminando y añadiendo actividades y reorganizando su estructura como respuesta a los resultados de las medidas.
lunes, 27 de diciembre de 2010
Personal Software Process (PSP)
Una medida significativa en la mejora de la calidad del software es la esencia del PSP, ya que PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software.
PSP se concentra en las practicas de trabajo de los ingenieros en una forma individual, sirve para producir software de calidad, cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.
PSP se diseño para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería de software. Así mismo les enseña como planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y medido, a establecer metas y a la utilización del rastreo constante para alcanzar dichas metas.
PSP le demuestra a los ingenieros a como manejar la calidad desde el principio del trabajo, a como analizar los resultados de cada trabajo, y a como utilizar los resultados para mejorar el proceso del proyecto siguiente.
El diseño de PSP se basa en los siguientes principios de calidad y planeacion:
Para producir constantemente productos de calidad, los ingenieros deben de planear, medir y rastrear constantemente la calidad del producto y deben centrarse en la calidad desde el principio de un trabajo.
En conclusión PSP son procedimientos que nos ayudan a obtener un software de calidad, no siempre es el mismo procedimiento para cualquier software, si no depende de los requerimientos de este, para alcanzar la calidad del producto.
Aporte: Karen Almeida Chavez
PSP se concentra en las practicas de trabajo de los ingenieros en una forma individual, sirve para producir software de calidad, cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.
PSP se diseño para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería de software. Así mismo les enseña como planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y medido, a establecer metas y a la utilización del rastreo constante para alcanzar dichas metas.
PSP le demuestra a los ingenieros a como manejar la calidad desde el principio del trabajo, a como analizar los resultados de cada trabajo, y a como utilizar los resultados para mejorar el proceso del proyecto siguiente.
El diseño de PSP se basa en los siguientes principios de calidad y planeacion:
- Cada ingeniero es diferente, es decir los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales.
- Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar procesos bien definidos y medidos.
- Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus producto.
- Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes.
- Es mas eficiente prevenir defectos que encontrarlos y arreglarlos.
- La manera correcta de hacer las cosas es siempre la mas rápida y mas barata de hacer un trabajo.
Para producir constantemente productos de calidad, los ingenieros deben de planear, medir y rastrear constantemente la calidad del producto y deben centrarse en la calidad desde el principio de un trabajo.
En conclusión PSP son procedimientos que nos ayudan a obtener un software de calidad, no siempre es el mismo procedimiento para cualquier software, si no depende de los requerimientos de este, para alcanzar la calidad del producto.
Aporte: Karen Almeida Chavez
domingo, 26 de diciembre de 2010
Métricas de Software
A diferencia de otras disciplinas, la ingeniería de software no esta basada en leyes cuantitativas básicas, se intenta obtener un conjunto de medidas indirectas que dan lugar a las métricas que proporcionan una indicación de la calidad de algún tipo de representación de software.
La medición es necesaria si se desea conseguir la calidad. Para eso se usan las siguientes métricas:
Métricas de Software:
Las métricas de software se refiere a un amplio elenco de mediciones para el software de computadora. La medición se puede aplicar al proceso de software con el intento de mejorarlo sobre una base continua.
Características fundamentales de las métricas de software:
La medición es necesaria si se desea conseguir la calidad. Para eso se usan las siguientes métricas:
Métricas de Software:
Las métricas de software se refiere a un amplio elenco de mediciones para el software de computadora. La medición se puede aplicar al proceso de software con el intento de mejorarlo sobre una base continua.
Características fundamentales de las métricas de software:
- Simples y fáciles de calcular: Deberán ser fáciles aprender a obtener la métrica y su calculo no deberá demandar esfuerzo o cantidad de tiempo inusuales.
- Empírica e intuitiva mente persuasivas: Satisfacer las nociones intuitivas del ingeniero sobre el atributo del producto en cuestión.
- Consistentes y objetivas: Deberán siempre producir resultados sin ambigüedad. Un tercer equipo debería ser capaz de obtener el mismo valor de una métrica usando la misma información del software.
- Consistentes en el empleo de unidades y tamaños: El calculo matemático de la métrica debería emplear medidas que eviten extrañas convinaciones de unidades.
- Independientes del lenguaje de programación: Deberán basarse en un modelo de análisis, diseño o en la estructura de un programa.
- Eficaces en el mecanismo para la realimentación de la calidad: Proporcionar al desarrollador de software información que le lleve a un producto final de mayor calidad.
Como se ha descrito es importante seguir ciertas métricas ya establecidas, para obtener una buena calidad del software que se esta elaborando, estas nos indicaran si el software va por buen camino o hay que corregir ciertas cosas para considerar que se elaboro un buen software.
miércoles, 22 de diciembre de 2010
Integración, Verificación y Validación del Sistema
Integración, Verificación y Validación del Sistema
Verificación y validación es el proceso de comprobación de que un producto, servicio o sistema cumple con las especificaciones y que cumple su propósito. Estos son componentes críticos de un sistema de gestión de calidad como ISO 9000. A veces precedidos por "independientes" (o IV y V)para asegurar que la validación sea realizada por un tercero desinteresado.
La verificación es un control de calidad de proceso que se utiliza para evaluar si o no un producto, servicio o sistema cumple con las normas, especificaciones o condiciones impuestas en el inicio de una fase de desarrollo. La verificación puede ser en el desarrollo, ampliación, o la producción. Esto es a menudo un proceso interno.
La validación es una garantía de la calidad del proceso de establecimiento de pruebas que proporciona un alto grado de certeza de que un producto, servicio o sistema cumple con sus requisitos previstos. Esto a menudo implica la aceptación de aptitud para el uso con los usuarios finales y otros interesados del producto.
A veces se dice que la validación se puede expresar por la consulta "¿Está construyendo lo correcto?" y verificación por parte de "¿Está construyendo bien?" "Construir lo correcto" se refiere a las necesidades del usuario, mientras que "la construcción de la derecha" comprueba que las especificaciones se apliquen correctamente en el sistema. En algunos contextos, se requiere tener por escrito los requisitos para ambos, así como los procedimientos formales o protocolos para determinar el cumplimiento.
Integración: Integración es el proceso a través del cual la organización aprende a introducir criterios y especificaciones en sus procesos y en sus sistemas de modo que satisfagan a todos sus clientes (internos, externos, institucionales, partes interesadas, etc.) de forma simultánea, ahorrando costes y esfuerzos, con un espíritu innovador, autocrático y comprometido con la mejora continua.
La integración de sistemas es el éxito de reunir los diversos componentes, ensamblajes y subsistemas de un sistema y que ellos trabajen juntos para realizar lo que el sistema estaba destinado a hacer. De ello se desprende la fase de codificación en el ciclo de vida de desarrollo y se entrelaza con la prueba.
Adriana Esther Moreno Martínez grupo C
martes, 21 de diciembre de 2010
Métricas del Software
Métricas del Software
El IEEE define como métrica "una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado".
Se dice que la medición es esencial, si es que se desea realmente conseguir la calidad en software.
Es por eso que existen distintos tipos de métricas para poder evaluar, mejorar y clasificar al software final, en donde serán manejadas dependiendo del entorno de desarrollo del software al cual pretendan orientarse.
¿Qué son las métricas de software?
Las métricas son la maduración de una disciplina, que, según Pressman van a ayudar a la evaluación de los modelos de análisis y de diseño, en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente, y ayudaran en el diseño de pruebas más efectivas. Es por eso que propone un proceso de medición, el cual se puede caracterizar por cinco actividades:
Formulación: La obtención de medidad y métricas del software apropiadas para la representación de software en cuestión.
Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
Análisis: El cálculo de las métricas y la aplicación matemáticas.
Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación.
Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software.
Modelo de Madurez de Capacidades (CMM)
Modelo de Madurez de Capacidades (CMM)
El Modelo de Madurez de Capacidades (conocido en inglés como "Capability Maturity Model" o por su sigla CMM) es un modelo de prácticas fundamentales que deben ser implementadas por toda organización interesada en desarrollar y mejorar la calidad de sus productos y su productividad. Este modelo está basado en conceptos de calidad total y de mejoramiento continuo; ha sido elaborado por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon y ha sido ampliamente aceptado por la comunidad de ingeniería de software. Rápidamente se ha convertido en el estándar de facto en los Estados Unidos de América, y también a nivel internacional, para evaluar la madurez de procesos que tienen las organizaciones que producen software. Este modelo se puede utilizar no solamente como un manual de prácticas recomendables, sino que además como referencia para llevar a cabo auditorias y evaluaciones internas en las organizaciones que desarrollan y mantienen software.
Algunas empresas también han identificado modelos propietarios de versiones del CMM. Sin embargo, hay cinco etapas definidas.
Ad-Hoc/Crisis: La organización cuenta con pocos procesos comunes. El éxito de sus proyectos depende de la fortaleza y habilidades de la gente. La organización contribuye poco a generar un ambiente de soporte que ayude a que todos los proyectos sean exitosos. La mayoría de las organizaciones están en esta etapa aunque muchas de ellas dicen estar en el nivel 0 o incluso -1 en son de broma.
Administración de Proyectos Estándar: La organización ha implementado procesos estándares para la administración de proyectos y utiliza estos procesos comunes en todos los proyectos. Está tratando de establecer los cimientos sobre los cuales mejorar en el futuro. La mayoría de las organizaciones que buscan seguir la ruta del CMM están tratando de alcanzar este nivel.
Desarrollo estándar de software: Se está tratando de alcanzar la estandarización en el proceso de desarrollo de software, de la misma forma en que se hizo para la administración de proyectos en el nivel 2. Esto incluye procesos comunes y repetibles de desarrollo de software, entregables, herramientas, etc.
Retroalimentación Gestionada: Se recopilan métricas en todos los aspectos de los procesos de desarrollo de software y de administración de proyectos. Se cuenta con un repositorio de métricas y aprendizajes de proyectos pasados que pueden ser apalancados por nuevos proyectos.
Optimización / mejora continua: Se tiene un ciclo cerrado de ejecución de procesos, medición de desempeño y mejora continúa. Frecuentemente
Adriana Esther Moreno Martínez Grupo C
sábado, 18 de diciembre de 2010
Personal Software Process
El PSP (Personal Software Process) es una técnica probada para mejorar el
funcionamiento y la productividad individuales de los ingenieros. Surge de
la necesidad que tiene los individuos programadores de automatizar sus procesos.
PSP fue diseñado para ayudar a los profesionales del software para que
utilicen constantemente practicas sanas de ingeniería del software, enseñándoles
a planificar y dar seguimiento a un trabajo, utilizar un proceso bien
definido y medido, a establecer metas mesurables y finalmente a rastrear
constantemente para obtener las metas definidas.
El Proceso Personal de Software es una versión pequeña de CMM, se trata de como :
•Definir los procesos
•Medida de la calidad
•Medir la productividad
Se trata de un enfoque de uso general que se puede utilizar en casi cualquier parte del el proceso del software.
El PSP es similar al Modelo de Madurez de Capacidad (CMM), excepto que se centra en el proceso personal.
Los beneficios de una PSP son las siguientes :
• El que comprender bien sus talentos y habilidades
• El estímulo de un flujo casi ilimitado de ideas
• El marco que ofrece para la mejora personal
• El grado de control que hacerse con su trabajo
• El sentimiento de orgullo y logro
• Una mejor base para el trabajo en equipo eficaz
• La convicción de que hacer el trabajo de la manera que usted sabe que debe.
Metricas del Software
“Cuando puedas medir lo que estás diciendo y expresarlo en números, sabrás algo acerca de eso;
pero cuando no puedes medirlo, cuando no puedes expresarlo en números, tus conocimientos serán escasos y no satisfactorios”
Lord Kelvin
“Lo que no sea medible, hazlo medible”
Galileo Galilei
--------------------------------------------------------------------------------------
Metricas Del Software
Es una forma de medir y una escala, definidas para realizar mediciones de uno o varios atributos.
Se aplica las métricas para valorar la calidad de los productos de ingeniería o los sistemas que se construyen.
Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas claramente definidas.
Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.
Conyeban una calidad del Software
Los requisitos de este Software son la base de las medidas de calidad.
La falta de concordancia con los requisitos es una falta de calidad.
Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera
en que se hace la ingeniería del Software. Si no se siguen los criterios , habrá seguramente poca calidad.
Existe un conjunto de requisitos implícitos que ha menudo no se nombran.
Si el software cumple con sus requisitos explícitos pero falla en los implícitos , la calidad del software no será fiable.
viernes, 17 de diciembre de 2010
Antipatron de Administración de proyectos
ANTIPATRON DE ADMINISTRACIÓN DE PROYECTOS
Se define como la forma de capturar la experiencia de los desarrolladores para poder ser asimilada más fácilmente por otros desarrolladores.
Entonces usar un patrón que haya sido usado anteriormente podemos obtener como beneficio superar en cierto grado las consecuencias de su utilización.
Algunos ejemplos de antipatron son los siguientes:
Analysis Paralysis: Suele ocurrir cuando se busca la perfección y la completitud en la etapa de análisis, cuando apenas se avanza en el diseño.
2.- Death by planning: Suele ocurrir cuando el proyecto se demora por excesiva dedicación a la preparación de planes para el desarrollo del proyecto.
3.- Intelectual Violence: Suele ocurrir cuando alguien que comprende una teoría, técnica o tecnología, usa este conocimiento para intimidar a otros en una reunión.
4.- Smoke and mirrors: Ocurre cuando el equipo se compromete a cumplir expectativas del cliente que escapan las capacidades tecnológicas de la organización.
5.- The Mythical Month Man: Consiste en la creencia de que asignar más personal a un proyecto, Llega un punto donde entre más personal se asigne, más se retrasa el proyecto.
6.- Project Miss-management: Se refiere a la jefa o jefe que no sabe coordinar. 7.- Corncob: Los empleados se obstaculizan unos a otros. Personas conflictivas o difíciles de tratar que formen parte del equipo de desarrollo, desvían u obstaculizan el proceso de producción.
Administracion de Riesgos
Consiste en identificar, analizar, atacar y eliminar el origen de los riesgos antes de que se conviertan en amenazas para completar exitosamente un proyecto de software.
Identificar factores que implican un riesgo para el proyecto desde que comienza, algunas de las prácticas para identificarlos son:
*Lluvia de ideas : utilizando grupos homogéneos en cuanto a rol y jerarquía
*Utilizar la lista de riesgos comunes de la empresa : hay que aprender de las
experiencias pasadas de los proyectos.
*Circula la lista de riesgos del proyecto.
*Desde la fase de Concepción hay que identificar los primeros riesgos e incluso atacar
los más graves desde esa fase.
*A lo largo de todo el proyecto hay que monitorearlos y en las juntas
de seguimiento tratar de identificar nuevos riesgos.
El análisis de Riesgo se refiere a la evaluación de la probabilidad e impacto de cada riesgo,
se obtiene con la exposición al riesgo y se calcula con la siguiente fórmula:
Exposición al riesgo = Impacto x Probabilidad
Impacto : Tiempo de retraso que ocasionaría si el riesgo ocurriera
Probabilidad : Probabilidad de que ocurra el riesgo
Se debe de planear que hacer con cada uno de los riesgos prioritarios para ir disminuyendo su exposición al riesgo.
Cada riesgo debe tener:
*Un responsable de resolverlo
*Una fecha planeada de resolución
*Lista de actividades planeadas para disminuir la probabilidad de que ocurra
*Lista de actividades realizadas para resolverlo a la fecha
*La probabilidad actual de que ocurra y la exposición al riesgo
*Los riesgos se administran a lo largo de todas las fases, el principal responsable es el administrador del proyecto, aunque se deben de asignar responsables de atacar cada uno de los riesgos.
Suscribirse a:
Entradas (Atom)