rio Para Identificacion de Riesgos Sei

Cuestionario Para Identificación de Riesgos

Taxonomy-Based Risk Identification (SEI, 1993)

Ref.

Clasificación y Enunciado Observaciones

1.- Ingeniería del producto

1.1.- Requerimientos

1.1.1.- Estabilidad ¿Están cambiando los requerimientos incluso cuando el producto está siendo construido?

[1] ¿Son los requerimientos estables? (NO) ¿Cual es el efecto en el sistema?

Calidad

Funcionalidad

Calendario

Integración

Diseño

Prueba

[2] ¿Están cambiando las interfases externas?

1.1.2.- Exactitud ¿Hay requerimientos perdidos o parcialmente especificados?

[3] ¿Hay especificaciones “pendientes de determinar”?

[4] ¿Hay requerimientos que sabes que deberían estar especificados pero no lo están?

(SI) ¿Serás capaz de incluir dichos requerimientos en el sistema?

[5] ¿Tiene el cliente requisitos o expectativas no documentadas?

(SI) ¿Hay forma de determinar esos requerimientos?

[6] ¿Están completamente definidas las interfases externas?

1.1.3.- Claridad ¿Son los requerimientos confusos o necesitan interpretación?

[7] ¿Eres capaz de comprender los requerimientos tal como están documentados?

(NO) ¿Están siendo resueltas las ambigüedades satisfactoriamente?

(SI) ¿No hay ambigüedades o problemas de interpretación?

1.1.4.- Validez ¿Llevarán los requerimientos al producto que el cliente tiene en mente?

[8] ¿Existe algún requerimiento que pueda especificar mal lo que el cliente tiene en mente?

(SI) ¿Cómo lo estás resolviendo?

[9] ¿Entendéis igual el cliente y tú los requerimientos?

(SI) ¿Hay algún proceso que demuestre esto?

[10] ¿Cómo validas los requerimientos? Prototipos

Análisis

Simulaciones.

Ref.


1.1.5.- Viabilidad ¿Son inviables los requerimientos desde un punto de vista analítico?

[11] ¿Hay algún requerimiento que es técnicamente difícil de implementar?

(SI) ¿Cómo?

(SI) ¿Por qué es difícil de implementar?

(NO) ¿Se han hecho estudios de viabilidad de esos requerimientos? En su caso ¿Cómo confianza merecen las suposiciones hechas en los estudios?

1.1.6.- Precedentes ¿Especifican los requerimientos algo no hecho nunca antes, o que tu organización no ha hecho antes?

[12] ¿Hay algún requerimiento en el “estado del arte” de la Tecnología, los Métodos, los Lenguajes o el Hardware ¿

(NO) ¿Hay alguna de estas cosas nueva para ¿Cómo?

(SI) ¿Tiene el equipo del proyecto suficiente conocimiento en esas áreas? Si no es así ¿Hay algún plan para adquirir el conocimiento necesario?

1.1.7.- Escala ¿Especifican los requerimientos algún producto más grande, más complejo, o que requiere una organización mayor que lo que es costumbre en la organización?

[13] ¿Es el tamaño y complejidad del sistema relevante?

(NO) ¿Has hecho algo de este tamaño y complejidad antes?

[14] ¿El tamaño requiere una organización mayor de lo habitual en tu organización?

1.2.- Diseño

1.2.1.- Funcionalidad ¿Hay algún problema potencial en cumplir los requerimientos funcionales?

[15] ¿Existe algún algoritmo especificado que puede no satisfacer los requerimientos?

(NO) ¿Alguno de los algoritmos o diseños son marginales para cumplir los requerimientos?

[16] ¿Cómo determinas la viabilidad de los algoritmos y diseños?

Prototipos

Modelos

Análisis

Simulaciones

1.2.2.- Dificultad ¿Será el diseño y/o su implementación difícil de lograr?

[17] ¿Depende el diseño de alguna asunción optimista o poco realista?

[18] ¿Existe algún requerimiento o función difícil de diseñar?

(NO) ¿Tienes soluciones para todos los requerimientos?

(SI) ¿Cómo requerimientos son?¿Por qué son difíciles?

1.2.3.- Interfases ¿Están las interfases externas (hardware y software) bien definidas y controladas?

[19] ¿Están las interfases internas bien definidas? Software con Software y Software con Hardware

[20] ¿Hay algún proceso para definir las interfases internas?

(SI) ¿Hay un proceso de control de cambios para interfases internas?

[21] ¿Se está desarrollando hardware en paralelo con software?

(SI) ¿Están cambiando las especificaciones del hardware?

Ref.


(SI) ¿Han sido definidas todas las interfases con el software?

(SI) ¿Existen modelos de diseño de ingeniería que se puedan usar para probar el software?

1.2.4.- Rendimiento ¿Hay algún requerimiento estricto de tiempo de respuesta o de procesamiento?

[22] ¿Hay algún problema con el rendimiento? Capacidad de procesamiento

Planificación de eventos asíncronos en tiempo real

Respuesta en tiempo real

Tiempos límite de recuperación

Tiempos de respuesta

Acceso, contención o respuesta de base de datos

[23] ¿Se ha hecho un análisis de rendimiento? (SI) Cual es tu nivel de confianza en el análisis del rendimiento?

(SI) ¿Tienes un modelo para vigilar el rendimiento durante el diseño y el desarrollo?

1.2.5.- Facilidad de prueba ¿Es difícil o imposible probar el producto?

[24] ¿Es fácil probar el software que se está escribiendo?

[25] ¿Incluye el diseño características que ayuden a la prueba?

[26] ¿Están las personas que han de probar involucrados en el análisis de los requerimientos?

1.2.6.- Restricciones del hardware ¿Hay restricciones severas en el hardware a utilizar?

[27] ¿Limita el hardware tus posibilidades de cumplir con algún requerimiento?

Arquitectura

Capacidad de memoria

Velocidad de procesamiento


Tiempo de respuesta

Tiempos límite de recuperación

Rendimiento de la base de datos

Fiabilidad

Disponibilidad

1.2.7.- Software no desarrollado ¿Hay problemas con software usado en el proyecto pero no desarrollado en él?

Si existe software reutilizado o reescrito:

[28] ¿Estas reusando o reescribiendo software no desarrollado en el proyecto?

(SI) ¿Preves algún problema?

Ref.


Documentación

Rendimiento

Funcionalidad

Entrega a tiempo

Adaptación

Si se utiliza algún paquete comercial:

[29] ¿Existe algún problema asociado al uso de software empaquetado?

Insuficiente documentación para determinar interfases, tamaño o rendimiento

Mal rendimiento

Requiere una gran cantidad de memoria o almacenamiento en base de datos

Dificultad para integrarse con el software de aplicación

No está debidamente probado

No está suficientemente depurado (tiene bugs)

No está adecuadamente mantenido

Lenta respuesta del vendedor

[30] ¿Preves algún problema con las actualizaciones o versiones del paquete que se está integrando?

1.3.- Codificación y prueba unitaria

1.3.1.- Viabilidad ¿Es difícil o imposible la implementación del diseño?

[31] ¿Hay alguna parte de la implementación del producto que no esté completamente definida en el diseño?

[32] ¿Son los diseños y algoritmos seleccionados fácil de implementar?

1.3.2.- Prueba unitaria ¿Es adecuado el nivel y dedicación especificado para la prueba unitaria?

[33] ¿Comienzas la prueba unitaria antes de verificar el código respecto al diseño?

[34] ¿Ha sido especificada suficiente prueba unitaria?

[35] ¿Hay suficiente tiempo para realizar la prueba unitara que crees debería ser realizada?

[36] ¿Se harán compromisos respecto a la prueba unitaria si hay retrasos?

1.3.3.- Codificación / Implementación ¿Hay problemas con la codificación e implementación?

[37] ¿Son las especificaciones del diseño suficientemente detalladas para escribir el código?

Ref.


[38] ¿Se cambia el diseño mientras se está codificando?

[39] ¿Hay restricciones al sistema que hacen el código difícil de escribir?

Tiempo

Memoria

Almacenamiento externo

[40] ¿Es el lenguaje adecuado para producir el software de este proyecto?

[41] ¿Se utilizan múltiples lenguajes en el proyecto? (SI) ¿Hay compatibilidad de interfase entre el código producido por los diferentes compiladores?

[42] ¿El el ordenador de desarrollo el mismo que el de producción?

(NO) ¿Hay diferencias del compilador entre ellos?

Si se utiliza hardware en desarrollo

[43] ¿Son las especificaciones del hardware adecuadas para codificar el software?

[44] ¿Cambian las especificaciones del hardware mientras se escribe el código?

1.4.- Integración y prueba

1.4.1.- Equipamiento ¿Es adecuado el equipamiento de integración y prueba?

[45] ¿Se dispondrá de suficiente hardware para hacer una integración y prueba adecuada?

[46] ¿Hay algún problema con el desarrollo de escenarios realistas y datos de prueba para demostrar algún requerimiento?

Tráfico de datos especificado


Manejo asíncrono de eventos

Interacción multi-usuario

[47] ¿Puedes verificar el rendimiento en tus instalaciones?

[48] ¿Facilita las pruebas la instrumentación del hardware y software?

(SI) ¿Es suficiente para toda la prueba?

1.4.2.- Producto ¿Es inadecuada la definición de interfases, las instalaciones o el tiempo insuficiente?

[49] ¿Estará el hardware de producción disponible cuando se necesite?

[50] ¿Se han acordado criterios de aceptación para todos los requerimientos?

(SI) ¿Hay un acuerdo formal?

[51] ¿Están las interfases externas definidas, documentadas y versionadas?

[52] ¿Hay algún requerimiento que puede ser difícil de probar?

[53] ¿Se ha especificado suficientemente la integración del producto?

[54] ¿Se ha asignado tiempo suficiente para la integración y prueba del producto?

Ref.


Si hay un paquete comercial

[55] ¿Se aceptarán los datos del vendedor como verificación de los requerimientos asignados al paquete?

(SI) ¿El claro el contrato al respecto?

1.4.3.- Sistema ¿Integración del sistema descoordinada, mala definición de interfases o inadecuadas instalaciones?

[56] ¿Ha sido especificada suficiente integración del sistema?

[57] ¿Se ha asignado suficiente tiempo para la integración y prueba del sistema?

[58] ¿Forman parte todos los contratistas del equipo de integración?

[59] ¿Será el producto integrado en un sistema existente?

(SI) Hay un periodo de paralelo con el sistema actual? Si no es así ¿Cómo garantizarás que el producto correrá correctamente cuando se integre?

[60] ¿Se realizará la integración del sistema en las instalaciones del cliente?

1.5.- Especialidades de ingeniería

1.5.1.- Mantenibilidad ¿Será la implementación difícil de comprender o mantener?

[61] ¿Crean la arquitectura, el diseño o el código dificultades para el mantenimiento?

[62] ¿Se ha involucrado en el comienzo del diseño la gente responsable del mantenimiento?

[63] ¿La documentación del producto es adecuada para su mantenimiento por una organización externa?

1.5.2.- Fiabilidad ¿Son difíciles de cumplir los requerimientos de fiabilidad o disponibilidad?

[64] ¿Han sido asignados al software requisitos de fiabilidad?

[65] ¿Han sido asignados al software requisitos de disponibilidad?

(SI) ¿Suponen algún problema los tiempos límite de recuperación?

1.5.3.- Seguridad (Safety) ¿Son los requisitos de seguridad inviables o no demostrables?

[66] ¿Hay requisitos de seguridad asignados al software?

(SI) ¿Ves alguna dificultad en cumplir dichos requisitos?

[67] ¿Será difícil verificar el cumplimiento de los requisitos de seguridad?

1.5.4.- Seguridad (Security) ¿Son los requisitos de seguridad más estrictos de lo habitual o de la experiencia en proyectos?

[68] ¿Hay requerimientos de seguridad sin precedentes o en el “estado del arte”?

[69] ¿El sistema ha de ser certificado en cuanto a la seguridad, por ejemplo con los “Common Criteria”?

[70] ¿Has implementado antes este nivel de seguridad?

Ref.


1.5.5.- Factores humanos ¿Será el sistema difícil de usar debido a una mala definición de la interfase de usuario?

[71] ¿Ves alguna dificultad en cumplir con los requerimientos relativos a factores humanos?

(NO) ¿Cómo vas a asegurarte de que cumples los requerimientos relativos a la interfase de usuario?

Si se hacen prototipos:

¿Es un prototipo temporal (usar y tirar)?

En caso contrario, ¿Estás haciendo un desarrollo evolutivo? Y si es así:

1. ¿Tienes experiencia en este tipo de desarrollos?

2. ¿Se instalan las versiones intermedias?

3. ¿Complica esto el control de cambios?

1.5.6.- Especificaciones ¿Es la documentación adecuada para diseñar, implementar y probar el sistema?

[72] ¿Es la documentación de los requerimientos de software adecuada para el diseño?

[73] ¿Son las especificaciones del hardware adecuadas para diseñar e implantar el software?

[74] ¿Están bien especificados los requerimientos de interfases externas?

[75] ¿Son adecuadas las especificaciones de las pruebas para una completa prueba del sistema?

Si estamos en una fase de implementación

[76] ¿Son las especificaciones de diseño adecuadas para implantar el sistema?

Interfases internas

2.- Ambiente de desarrollo

2.1.- Proceso de desarrollo

2.1.1.- Formalismo ¿Será la implementación difícil de comprender o mantener?

[77] ¿Se está utilizando más de un modelo de desarrollo?

Espiral

Cascada

Incremental

(SI) ¿Es un problema la coordinación entre ellos?

[78] ¿Hay planes formales y controlados para todas las actividades de desarrollo?

Análisis de requerimientos

Diseño

Codificación

Integración y prueba

Instalación

Ref.


Aseguramiento de la calidad

Gestión de la configuración

(SI) ¿Especifican los planes bien cada proceso?

(SI) ¿Están los desarrolladores familiarizados con los planes?

2.1.2.- Adecuación ¿Es el proceso adecuado al modelo de desarrollo (espiral, prototipo,...?

[79] ¿Es el proceso de desarrollo adecuado para este producto?

[80] ¿Está el proceso de desarrollo soportado por un juego compatible de procedimientos, métodos y herramientas?

2.1.3.- Control de procesos ¿Está el proceso de desarrollo de software forzado, vigilado y controlado usando métricas?¿Son coordinados los centros de desarrollo distribuidos?

[81] ¿Todo el mundo sigue el proceso de desarrollo? (SI) ¿Como se comprueba?

[82] ¿Puedes medir si el proceso de desarrollo está logrando tus objetivos de calidad y productividad?

Si hay centros de desarrollo distribuidos

[83] ¿Existe la adecuada coordinación entre los diferentes centros de desarrollo?

2.1.4.- Familiarización ¿Tienen experiencia los miembros del equipo del proyecto en el uso del proceso de desarrollo?¿Se comprende el proceso por parte de todos los miembros del equipo?

[84] ¿Está cómoda la gente con el proceso de desarrollo?

2.1.5.- Control del producto ¿Existen mecanismos para controlar los cambios en el producto?

[85] ¿Existe un mecanismo para la trazabilidad de los requerimientos que siga los requerimientos desde la especificación inicial a los casos de prueba?

[86] ¿Se utiliza el mecanismo de trazabilidad para el análisis de impacto de los cambios de requerimientos?

[87] ¿Hay un proceso formal de control de cambios? (SI) ¿Cubre todos los cambios en la baseline de requerimientos, diseño , código fuente y documentación?

[88] Los cambios a cualquier nivel, ¿son mapeados a nivel del sistema y en detalle hasta el nivel de prueba?

[89] ¿Existe un análisis adecuado cuando nuevos requerimientos se añaden al sistema?

[90] ¿Tienes un sistema de controlar las interfases?

[91] ¿Se actualizan los planes de prueba y los procedimientos como parte del proceso de cambios?

2.2.- Plataforma de desarrollo

Ref.


2.2.1.- Capacidad ¿Hay suficiente capacidad de proceso, memoria o disco?

[92] ¿Hay suficientes terminales y capacidad de proceso para todo el equipo de trabajo?

[93] ¿Hay suficiente capacidad para las fases solapadas ,como codificación, integración y prueba?

2.2.2.- Adecuación ¿Soporta el sistema de desarrollo todas las fases, actividades y funciones?

[94] ¿Soporta la plataforma de desarrollo todos los aspectos del proyecto?

Análisis de requerimientos

Análisis de rendimiento

Diseño

Codificación

Prueba

Documentación


Seguimiento por la dirección

Trazabilidad de requerimientos

2.2.3.- Usabilidad ¿Es fácil de usar la plataforma de desarrollo?

[95] ¿Encuentra la gente fácil de usar la plataforma?

[96] ¿Hay buena documentación acerca de la plataforma de desarrollo?

2.2.4.- Familiaridad ¿Hay poca experiencia previa en la compañía o el equipo de trabajo con la plataforma de desarrollo?

[97] ¿Ha utilizado la gente del equipo estas herramientas y métodos anteriormente?

2.2.5.- Fiabilidad ¿Sufre la plataforma de desarrollo de bugs, caídas o insuficiente respaldo interno?

[98] ¿Se considera fiable la plataforma? Compilador

Herramientas de desarrollo

Hardware

2.2.6.- Soporte ¿Existe soporte rápido por parte de expertos o del vendedor?

[99] ¿Está la gente formada en el uso de las herramientas de desarrollo?

[100] ¿Tienes acceso a expertos en el uso de la plataforma?

[101] ¿Responde el proveedor a los problemas con rapidez?

2.2.7.- Entrega ¿Están presupuestados los requisitos de definición y aceptación para entregar al cliente la plataforma de desarrollo?.

Ref.


Nota: Si los participantes dudan al respecto, probablemente esto no es un aspecto significativo desde la perspectiva de la gestión del riesgo.

[102] ¿Vas a entregar al cliente la plataforma de desarrollo?

(SI) ¿Tienes suficiente presupuesto, plazo y recursos asignados para esta entrega?

2.3.- Proceso de gestión

2.3.1.- Planificación ¿Se confecciona un plan, se actualiza y se hacen planes de contingencias?

[103] ¿Se gestiona el proyecto de acuerdo con el plan? (SI) ¿La gente lo incumple rutinariamente para apagar fuegos?

[104] ¿Se replanifica cuando ocurre una discontinuidad?

[105] ¿Está la gente a todos los niveles involucrada en planificar su propio trabajo?

[106] ¿Hay planes de contingencias para los riesgos conocidos?

(SI) ¿Como determinas cuando activar las contingencias?

[107] ¿Se gestionan adecuadamente los riesgos a largo plazo?

2.3.2.- Organización de proyectos ¿Están claros los papeles y las relaciones de supervisión en el equipo?

[108] ¿Es eficaz la organización del proyecto?

[109] ¿Comprende la gente su papel y el de los demás en el proyecto?

[110] ¿Sabe la gente quien tiene autoridad para cada cosa?

2.3.3.- Experiencia de los directivos ¿Tienen experiencia los directivos en el desarrollo de software, la gestión de software, el área de aplicación, el proceso de desarrollo o en grandes proyectos?

[111] ¿Tiene el proyecto gestores experimentados en..? Gestión de software

Experiencia práctica en desarrollo de software

Con este procedimiento de desarrollo

En el área funcional de la aplicación

En proyectos de este tamaño o complejidad

2.3.4.- Relaciones externas del proyecto ¿Hay malas relaciones con el cliente, otros contratistas, alta dirección o gerentes del mismo nivel?

[112] ¿Comunican los gestores los problemas hacia arriba y abajo en la organización?

[113] ¿Se documentan y resuelven los conflictos con el cliente en el momento adecuado?

[114] ¿Involucran los gestores a los miembros del equipo adecuados en las reuniones con el cliente?

Técnicos expertos

Desarrolladores

Analistas

Ref.


[115] ¿Se aseguran los gestores de que todos los departamentos o grupos del cliente estén representados en las reuniones relativas a funcionalidad u operación?

[116] ¿Se considera políticamente correcto presentar una imagen optimista al cliente o la dirección?

2.4.- Métodos de gestión

2.4.1.- Monitorización ¿Están definidas métricas de gestión y seguido el progreso del desarrollo?

[117] ¿Se hacen informes de progreso estructurados periódicamente?

(SI) ¿Se obtiene alguna respuesta de los informes de progreso?

[118] ¿Se remite la información apropiada a los niveles organizativos correctos?

[119] ¿Se sigue el progreso versus el plan? (SI) ¿Tiene la gerencia una clara imagen de como van las cosas?

2.4.2.- Gestión del personal ¿Está formado y asignado apropiadamente el personal del proyecto?

[120] ¿Está la gente formada en las habilidades requeridas por el proyecto?

(SI) ¿Está incluida la formación en el plan de proyecto?

[121] ¿Hay personas asignadas al proyecto que no tienen la experiencia necesaria para su trabajo?

[122] ¿Resulta fácil para los miembros del equipo conseguir que los gestores actúen?

[123] ¿Están enterados los miembros del equipo de su situación respecto al plan de trabajo?¿

[124] ¿Es consciente el personal de la importancia de seguir el plan?

[125] ¿Consultan los responsables del proyecto con el personal antes de adoptar decisiones que afectan a su trabajo?

[126] ¿Incluyen los responsables del proyecto a los miembros del equipo adecuados en las reuniones con el cliente?

Técnicos expertos

Desarrolladores

Analistas

2.4.3.- Aseguramiento de la calidad ¿Existen procedimientos y recursos adecuados para asegurar la calidad de los productos?

[127] ¿Tiene el personal adecuado la función de aseguramiento de la calidad en el proyecto?

[128] ¿Existen mecanismos definidos para asegurar la calidad?

(SI) ¿Tienen procedimientos de calidad todas las áreas y fases?

(SI) ¿¿Está la gente acostumbrada a trabajar con esos procedimientos?

2.4.4.- Gestión de la configuración ¿Son adecuados los procedimientos de control de cambios y versiones, incluyendo la puesta en producción?

[129] ¿Se dispone de un sistema adecuado de gestión de la configuración?

[130] ¿Tiene asignado suficiente personal la función de

Ref.


gestión de la configuración?

[131] ¿Se requiere la coordinación con un sistema ya instalado?

(SI) ¿Existe una gestión de la configuración adecuada para el sistema ya instalado?

(SI) Sincroniza el sistema de gestión de la configuración tu trabajo con los cambios en el centro?

[132] ¿Se está instalando en múltiples centros de proceso?

(SI) ¿El sistema de gestión de la configuración soporta múltiples centros?

2.5.- Ambiente de trabajo

2.5.1.- Actitud respecto a la calidad ¿Existe una baja orientación hacia la calidad del trabajo?

[133] ¿Está todo el equipo de trabajo convencido acerca del uso de los procedimientos de calidad?

[134] ¿La disposición del calendario de trabajo se ajusta a la calidad del trabajo?

2.5.2.- Cooperación

[135] ¿Trabaja el personal cooperando por encima de límites funcionales?

[136] ¿Trabaja el personal eficazmente hacia objetivos comunes?

[137] ¿Se requiere a veces la intervención de la dirección para conseguir que la gente trabaje conjuntamente?

2.5.3.- Comunicación ¿Hay poca conciencia de misión u objetivos, mala comunicación de la información técnica entre colegas y gerentes?

[138] ¿Hay buena comunicación entre los miembros del proyecto?

Gerentes

Técnicos expertos

Programadores

Probadores



[139] ¿Son receptivos los gestores a la comunicación procedente del equipo del proyecto?

(SI) ¿Te sientes libre de pedir ayuda a los gestores?

(SI) ¿Son los miembros del equipo capaces de avisar de riesgos sin tener la solución preparada?

[140] ¿Disponen los miembros del equipo de información a tiempo acerca de los sucesos que puedan afectar a su trabajo?

(SI) ¿Es formal o informal?

2.5.4.- Moral ¿Hay una atmósfera improductiva y no creativa?¿Siente la gente que no hay reconocimiento o premio por un buen trabajo?

[141] ¿Es buena la moral en el proyecto? (NO) ¿Cual es el principal factor que contribuye a una moral baja?

[142] ¿Hay algún problema para retener la gente necesaria?

Ref.


3.- Restricciones del proyecto

3.1.- Recursos

3.1.1.- Calendario ¿Es el calendario inadecuado o inestable?

[143] ¿Ha sido el calendario estable?

[144] ¿Es realista el calendario? (SI) ¿Está basado el método de estimación en datos históricos?

(SI) ¿Ha funcionado bien el método de estimación en el pasado?

[145] ¿Hay algo para lo que no fué asignado suficiente tiempo en el calendario?

Análisis y estudios


Formación

Cursos de actualización

Equipamiento material

Entrega del entorno de desarrollo al cliente

[146] ¿Existen dependencias externas que puedan impactar en el calendario?

3.1.2.- Equipo de trabajo

[147] ¿Hay algún área en la que faltan conocimientos técnicos en el equipo de trabajo?

Ingeniería de software y métodos de análisis de requerimientos

Dominio de algoritmos

Métodos de diseño y diseño de software

Lenguajes de programación

Métodos de integración y test

Fiabilidad

Mantenibilidad

Disponibilidad

Ergonomía y factores humanos



Plataforma de producción

Nivel de seguridad

Paquetes de software comercial

Reutilización de software

Sistemas operativos

Bases de datos

Ref.


Ámbito funcional de la aplicación

Análisis de rendimiento

Aplicaciones de misión crítica

[148] ¿Tienes el adecuado personal para formar el equipo de trabajo?

[149] ¿Es estable el equipo de trabajo?

[150] ¿Tienes acceso a la gente adecuada cuando la necesitas?

[151] ¿Han desarrollado los miembros del equipo algún sistema de este tipo?

[152] ¿Depende el proyecto de unas pocas personas clave?

[153] ¿Hay algún problema para conseguir personal adecuado?

3.1.3.- Presupuesto ¿Es la financiación insuficiente o inestable?

[154] ¿Es estable el presupuesto?

[155] ¿Está basado en estimaciones realistas? (SI) ¿Está basado el método de estimación en datos históricos?

(SI) ¿Ha funcionado bien en el pasado el método de estimación?

[156] ¿Se han suprimido funciones o características en un esfuerzo por ajustar el diseño al coste?

[157] ¿Hay algún aspecto para el que se ha asignado el suficiente presupuesto?

Análisis y estudios


Formación

Cursos de actualización

Equipamiento material

Entrega del entorno de desarrollo al cliente

[158] ¿Se hacen cambios al presupuesto cuando se cambian los requerimientos?

(SI) ¿Es una parte estándar del proceso de control de cambios?

3.1.4.- Instalaciones y equipamiento ¿Son adecuadas las instalaciones y el equipamiento para construir y entregar el producto?

[159] ¿Son adecuadas las instalaciones y el equipamiento?

[160] ¿Es adecuada la plataforma de integración?

3.2.- Contrato

3.2.1.- Tipo de contrato ¿Es el tipo de contrato una fuente de riesgos para el proyecto?

[161] ¿Qué tipo de contrato tienes? (Coste más margen, precio fijo, ...) ¿Presenta algún problema?

[162] ¿Crea problemas el contrato en algún aspecto del Definición del trabajo

Ref.


proyecto?

Especificaciones

Descripción de datos

Partes del contrato

Excesiva involucración del cliente

[163] ¿Crea problemas la documentación requerida? Cantidad excesiva

Cliente quisquilloso

Largo ciclo de aprobación

3.2.2.- Restricciones ¿Causa el contrato alguna restricción?

[164] ¿Hay problemas con derechos de propiedad? Paquetes de software comercial

Software de desarrollo

3.2.3.- Dependencias ¿Tiene el proyecto alguna dependencia de productos o servicios externos?

[165] ¿Hay dependencias de productos o servicios externos que puedan afectar al producto, el presupuesto o los plazos?

Contratista principal, subcontratistas o contratistas asociados

Vendedores o proveedores

Software o equipo adaptado al cliente

3.3.- Interfases del proyecto

3.3.1.- Cliente ¿Hay algún problema con el cliente, como podría ser: lento ciclo de aprobación de documentos, mala comunicación o poca experiencia en el dominio funcional?

[166] ¿Es muy lento el ciclo de aprobación del cliente? Documentación

Revisión de programas

Revisiones formales

[167] ¿Alguna vez avanzas antes de recibir la aprobación del cliente?

[168] ¿Comprende el cliente los aspectos técnicos del sistema?

[169] ¿Sabe el cliente lo que es el software?

[170] ¿Interfiere el cliente con el proceso o el personal?

[171] ¿Consigue el trabajo de la gerencia con el cliente alcanzar decisiones acordadas con el cliente en el momento adecuado?

Comprensión de requerimientos

Criterios de test

Ajustes a los calendarios

Interfases

[172] ¿En qué medida son efectivos los mecanismos de Grupos de trabajo (¿con efectos contractuales?)

Ref.


conseguir acuerdos con el cliente?

Reuniones de intercambio técnico (¿con efectos contractuales')

[173] ¿Están todas las áreas necesarias de la organización cliente involucradas en lograr los acuerdos?

(SI) ¿Hay un proceso definido formalmente?

Si hay contratistas asociados

3.3.2.- Contratistas asociados ¿Hay problemas con contratistas asociados como interfases inestables o mal definidas, mala comunicación o falta de cooperación?

[175] ¿Cambian las interfases externas sin adecuada notificación, coordinación o procedimientos formales de cambio?

[176] ¿Hay un adecuado plan de transición? (SI) ¿Está soportado por todos los contratistas y el personal de la instalación?

[177] ¿Hay algún problema con lograr fechas o datos de interfase de los contratistas asociados?

(NO) ¿Pero son precisos?

Si hay subcontratistas:

3.3.3.- Subcontratistas ¿Depende el proyecto de subcontratistas para algún área crítica?

[178] ¿Hay ambigüedades en la definición de las tareas del subcontratista?

[179] ¿Son los procedimientos de información y seguimiento del subcontratista diferentes de los del proyecto?

[180] ¿Se hace la administración y gestión técnica del subcontratista desde una organización separada?

[181] ¿Es el proyecto altamente dependiente del conocimiento de un subcontratista en algún área?

[182] ¿Se transfiere a la compañía el conocimiento técnico del subcontratista?

[183] ¿Hay problemas para conseguir compromisos de fechas o datos de interfases de los subcontratistas?

Si el proyecto es una subcontrata:

3.3.4.- Contratista principal ¿Hay problemas en el proyecto con el contratista principal?

[184] ¿Son ambiguas las definiciones de tareas?

[185] ¿Te relaciones con varias organizaciones principales para la administración y la gestión técnica?

[186] ¿Depende el proyecto fuertemente de los conocimientos del contratista principal en algún área?

[187] ¿Hay problemas para conseguir compromisos de fechas o datos de interfases del contratista principal?

Ref.


3.3.5.- Gestión corporativa ¿Falta soporte o gestión detallada de la alta dirección?

[188] ¿Comunica la dirección del proyecto los problemas a la alta dirección?

(SI) ¿Resulta eficaz?

[189] ¿Presta soporte a tiempo la alta dirección a la dirección del proyecto para resolver los problemas?

[190] ¿Tiende la alta dirección a realizar una gestión muy detallada?

[191] ¿Presenta la dirección del proyecto una imagen realista u optimista a la alta dirección?

3.3.6.- Proveedores ¿Dan buena respuesta los proveedores a las necesidades del proyecto?

[192] ¿Depende el proyecto de la entrega de componentes críticos por parte de proveedores ?

Compiladores

Hardware

Paquetes de software comercial

3.3.7.- Política ¿Sufre el proyecto problemas por causas políticas?

[193] ¿Afecta la política al proyecto? Compañía

Cliente

Contratistas asociados

Subcontratistas

[194] ¿Afecta la política a decisiones técnicas?

rio Para Identificacion de Riesgos Sei

Documents

Transcript of rio Para Identificacion de Riesgos Sei