En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... En tercer lugar, el riesgo implica elección y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte, es una de las pocas cosas inevitables de la vida.
Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasara? El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general? Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad?
Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasara? El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general? Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad?
Riesgos del proceso del software
Las siguientes preguntas se han extraído sobre la evaluación de la ingeniería del software desarrollado por R. S. Pressman & Associates. Inc. Las preguntas se han adaptado del cuestionario de evaluación del proceso del software del Instituto de Ingeniería del Software (IIS).
Aspectos del Proceso
• ¿Apoyan sus gestores senior unas normas escritas que hagan hincapié en la importancia de un proceso estándar para el desarrollo del software?
• ¿Ha desarrollado su organización una descripción escrita del proceso del software a emplear en este proyecto?
• ¿Están de acuerdo los miembros del personal con el proceso del software tal y como está documentado y estan dispuestos a usarlo?
• ¿Se emplea este proceso del software para otros proyectos?
• ¿Ha desarrollado o adquirido su organización cursos de formación de ingeniería del software para jefes de proyecto y personal técnico?
• ¿Se ha proporcionado una copia de los estándares de ingeniería del software publicados a cada desarrollador y gestor de software?
• ¿Se han desarrollado diseños de documentos y ejemplos para todas las entregas definidas como parte del proceso del software?
• ¿Se llevan a cabo regularmente revisiones técnicas formales de las especificaciones de requisitos, diseño y código?
• ¿Se llevan a cabo regularmente: revisiones técnicas de los procedimientos de prueba y de los casos de prueba?
• ¿,Se documentan todos los resultados de las revisiones técnicas, incluyendo los errores encontrados y recursos empleados?
• ¿Existe algún mecanismo para asegurarse de que el trabajo realizado en un proyecto se ajusta a los estándares de ingeniería del software?
• ¿Se emplea una gestión de configuración para mantener la consistencia entre los requisitos del sistema/software, diseño, código y casos de prueba?
• ¿Hay algún mecanismo de control de cambios de los requisitos del cliente que impacten en el software?
• ¿Hay alguna declaración de trabajo documentada, una especificación de requisitos software y un plan de desarrollo del software para cada subcontratación?
• ¿Se sigue algún procedimiento para hacer un seguimiento y revisar el rendimiento de las subcontraciones?
Aspectos Tecnicos
• ¿Se emplean técnicas de especificación de aplicaciones para ayudar en la comunicación entre el cliente y el desarrollador?
• ¿Se emplean métodos específicos para el análisis del software?
• ¿Emplea un método específico para el diseño de datos y arquitectónico?
• ¿Está escrito su código en más de un 90 por ciento en lenguaje de alto nivel?
• ¿Se han definido y empleado reglas específicas para la documentación del código?
• ¿Emplea métodos específicos para el diseño de casos de prueba?
• ¿Se emplean herramientas de software para apoyar la planificación y el seguimiento de las actividades?
• ¿Se emplean herramientas de software de gestión de configuración para controlar y seguir los cambios a lo largo de todo el proceso del software?
• ¿Se emplean herramientas de software para apoyar los procesos de análisis y diseño del software?
• ¿Se emplean herramientas para crear prototipos software?
• ¿Se emplean herramientas de software para dar soporte a los procesos de prueba?
• ¿Se emplean herramientas de software para soportar la producción y gestión de la documentación?
• ¿Se han establecido métricas de calidad para todos los proyectos de software?
• ¿Se han establecido métricas de productividad para todos los proyectos de software?
Si la mayoría de las cuestiones anteriores se han respondido negativamente, el proceso del software es débil y el riesgo es alto.
Para profundizar en el tema de analisis y gestion de riesgo visitar: aqui
No hay comentarios:
Publicar un comentario