INGENIERIA DEL SOFTWARE CAPITULO 22 PARTE 1

Según el capítulo, ¿cuáles son las cuatro metas importantes para la mayoría de los proyectos de software?. Entregar a tiempo, mantener costos dentro del presupuesto, cumplir las expectativas del cliente y mantener un equipo de desarrollo óptimo y funcional. Entregar a tiempo, maximizar las ganancias del contratista, minimizar el número de reuniones y evitar por completo el cambio de requerimientos. Reducir costos por debajo del presupuesto original, superar las expectativas técnicas del cliente, evitar la rotación de personal y redactar la propuesta ganadora.

¿Cuál es la primera razón que da el capítulo para explicar por qué la gestión de software es particularmente desafiante en comparación con otros tipos de ingeniería?. El producto es intangible, por lo que los administradores no pueden constatar el progreso solo con observar el artefacto que se construye. El software siempre cuesta más que cualquier otro tipo de producto de ingeniería civil o nava. Los procesos de software están completamente estandarizados a nivel internacional, a diferencia de los procesos de otras ingenierías.

¿Por qué, según el capítulo, incluso administradores con vasta experiencia pueden encontrar difícil anticiparse a los problemas en grandes proyectos de software?. Porque los grandes proyectos de software con frecuencia son excepcionales, y los vertiginosos cambios tecnológicos pueden volver obsoleta la experiencia previa del administrador. Porque la ley exige que cada proyecto grande sea gestionado por un administrador sin experiencia previa, para fomentar la innovación. Porque los procesos de software son idénticos entre organizaciones, por lo que la experiencia nunca resulta relevante para nada.

¿Cuál de las siguientes NO se menciona en el capítulo como una de las principales actividades que asumen los administradores de proyecto?. Planeación del proyecto, informes, gestión del riesgo, gestión de personal y redacción de propuestas. Certificación anual obligatoria del código fuente ante un organismo regulador internacional. Supervisar el trabajo para verificar que se realice de acuerdo con los estándares requeridos y monitorizar el avance.

Respecto a la escritura de propuestas como actividad del administrador de proyecto, ¿qué afirma el capítulo?. Es una habilidad que se adquiere a través de práctica y experiencia, ya que no hay lineamientos establecidos para esta tarea. Siempre debe delegarse por completo al departamento legal de la organización, nunca al administrador del proyecto. Solo es necesaria quy obligatoria cuando el cliente es una entidad gubernamental, nunca en contratos privados.

¿En qué dos actividades específicas decide centrarse el capítulo 22, dejando la planeación de proyectos para el capítulo 23?. La gestión del riesgo y la gestión de personal. La calendarización de proyectos y la estimación algorítmica de costos. La redacción de propuestas y la fijación de precio al software.

¿Por qué la buena gestión de un proyecto de software, según el capítulo, NO garantiza por sí sola el éxito del proyecto?. Porque el texto señala que la buena gestión no puede garantizar el éxito, mientras que la mala gestión casi siempre conduce a la falla del proyecto. Porque, según el capítulo, el éxito de un proyecto depende únicamente de la suerte y no de ninguna decisión administrativa. Porque el capítulo afirma que ningún proyecto de software se ha entregado jamás a tiempo y dentro del presupuesto.

Según la definición del capítulo, ¿qué implica la gestión del riesgo?. Anticipar riesgos que pudieran alterar el calendario del proyecto o la calidad del software, y tomar acciones para evitar dichos riesgos. Eliminar por completo cualquier posibilidad de que ocurra un evento negativo durante el desarrollo del software. Transferir toda la responsabilidad legal de los errores de software del contratista hacia el cliente final.

¿Cuáles son las tres categorías de riesgo identificadas en el capítulo?. Riesgos del proyecto, riesgos del producto y riesgos empresariales. Riesgos técnicos, riesgos financieros y riesgos legales. Riesgos internos, riesgos externos y riesgos mixtos.

En el ejemplo de la renuncia de un diseñador experimentado, ¿por qué el capítulo indica que este evento puede clasificarse simultáneamente en las tres categorías de riesgo?. Porque altera el calendario (riesgo de proyecto), un sustituto menos experimentado puede cometer errores (riesgo de producto), y la experiencia de ese programador es vital para obtener nuevos contratos (riesgo empresarial). Porque el capítulo establece que todo riesgo, sin excepción, pertenece siempre a las tres categorías al mismo tiempo, sin ningún criterio adicional. Porque la renuncia de personal se considera, según el capítulo, exclusivamente un riesgo de producto y nunca un riesgo de proyecto o empresarial.

¿Qué es un «riesgo de producto», según la definición precisa del capítulo?. Un riesgo que afecta la calidad o el rendimiento del software que se está desarrollando. Un riesgo que altera exclusivamente el calendario o los recursos asignados al proyecto. Un riesgo que afecta únicamente a la organización que adquiere o comercializa el software.

¿Cuál es un ejemplo de «riesgo empresarial» mencionado explícitamente en el capítulo?. Que un competidor introduzca un nuevo producto, lo cual puede hacer que las suposiciones sobre ventas de productos existentes resulten demasiado optimistas. Que un componente de software adquirido no se desempeñe como se esperaba, afectando el rendimiento del sistema. Que un diseñador experimentado renuncie, retrasando únicamente el calendario del proyecto.

¿Dónde deben registrarse los resultados del análisis de riesgo, según el capítulo, y qué deben incluir?. En el plan del proyecto, junto con un análisis de consecuencias para el proyecto, el producto y la empresa. Únicamente en un correo electrónico informal enviado al cliente al finalizar el proyecto. En el contrato legal del proyecto, y solo si el cliente lo solicita expresamente por escrito.

¿Cuáles son las cuatro etapas del proceso de gestión del riesgo ilustradas en la figura 22.2 del capítulo?. Identificación del riesgo, análisis de riesgos, planeación del riesgo y monitorización del riesgo. Identificación del riesgo, mitigación del riesgo, transferencia del riesgo y cierre del riesgo. Análisis de riesgos, aceptación del riesgo, evitación del riesgo y auditoría final del riesgo.

¿Por qué se describe el proceso de gestión del riesgo como «iterativo», según el capítulo?. Porque continúa a lo largo de todo el proyecto: conforme se dispone de más información, se vuelven a analizar los riesgos y se ajustan los planes. Porque debe repetirse exactamente una vez al inicio y una vez al final del proyecto, sin ninguna otra revisión intermedia. Porque cada etapa del proceso debe ejecutarse simultáneamente por equipos distintos sin ninguna coordinación entre ellos.

¿Cuáles son los seis tipos de riesgo que el capítulo recomienda incluir en una lista de verificación para la identificación del riesgo?. Tecnológicos, personales, organizacionales, de herramientas, de requerimientos y de estimación. Tecnológicos, financieros, legales, de mercado, de calidad y de infraestructura. De personal, de presupuesto, de calendario, de alcance, de comunicación y de proveedores.

Según el capítulo, ¿de qué se derivan específicamente los «riesgos organizacionales»?. Del entorno organizacional donde se desarrolla el software. De las tecnologías de software o hardware que se usan para desarrollar el sistema. De los cambios a los requerimientos del cliente y del proceso de gestionarlos.

El ejemplo «se subestima el tamaño del software» corresponde, según la figura 22.3 del capítulo, a un riesgo de tipo: Estimación. Requerimientos. Herramientas.

El ejemplo «los clientes no entienden las repercusiones de los cambios a los requerimientos» corresponde, según el capítulo, a un riesgo de tipo: Requerimientos. Personal. De organización.

¿Por qué, según el capítulo, es necesario reducir la lista inicial de riesgos identificados a un tamaño razonable?. Porque si existen demasiados riesgos, será prácticamente imposible seguir la huella de todos ellos. Porque las normas internacionales de gestión de proyectos prohíben identificar más de cinco riesgos por proyecto. Porque cada riesgo adicional identificado incrementa automáticamente el presupuesto total del proyecto.

¿Qué proceso se sugiere en el capítulo como forma de llevar a cabo la identificación del riesgo?. Puede ser un proceso de equipo donde éste se reúne para pensar en posibles riesgos, o el administrador puede identificarlos con base en su experiencia. Debe realizarse exclusivamente mediante una auditoría externa contratada antes de iniciar cualquier proyecto. Debe delegarse siempre y sin excepción al cliente, ya que solo él conoce los riesgos reales del negocio.

Según el capítulo, ¿en qué se debe apoyar el administrador para valorar la probabilidad y gravedad de un riesgo, dado que no existe una forma sencilla de hacerlo?. En su propio juicio y en la experiencia obtenida en proyectos anteriores. Exclusivamente en fórmulas matemáticas estandarizadas que garantizan una valoración numérica precisa. En una tabla fija publicada por el IEEE que asigna un valor numérico único a cada tipo de riesgo posible.

¿Cuáles son las cinco bandas para valorar la PROBABILIDAD de un riesgo, según el capítulo?. Muy baja (menos del 10%), baja (10-25%), moderada (25-50%), alta (50-75%) y muy alta (más del 75%). Nula, baja, media, alta y crítica, cada una definida en incrementos exactos del 20%. Improbable, posible, probable, muy probable y segura, sin ningún porcentaje asociado en el capítulo.

¿Cuáles son las cuatro categorías para valorar los EFECTOS de un riesgo, según el capítulo?. Catastróficos, graves, tolerables e insignificantes. Catastróficos, graves, moderados y despreciables. Críticos, altos, medios y bajos.

En la figura 22.4 del capítulo, el riesgo «es imposible reclutar personal con las habilidades requeridas» se clasifica con probabilidad y efecto: Alta y catastrófico. Moderada y grave. Baja y catastrófico.

En la misma figura 22.4, el riesgo «problemas financieros de la organización fuerzan reducciones en el presupuesto del proyecto» se clasifica con probabilidad y efecto: Baja y catastrófico. Alta y catastrófico. Moderada y grave.

Según Boehm (1988), citado en el capítulo, ¿cuántos riesgos principales recomienda identificar y monitorizar, y qué matiz agrega el capítulo sobre esta cifra?. Recomienda monitorizar los 10 riesgos principales, aunque el propio Boehm considera que esta cifra es más bien arbitraria. Recomienda monitorizar exactamente 25 riesgos, cifra que el capítulo describe como un estándar internacional obligatorio. Recomienda monitorizar un solo riesgo a la vez, para no saturar de información al equipo de desarrollo.

Según el capítulo, a partir de los riesgos identificados en la figura 22.4, ¿cuántos riesgos se consideró adecuado incluir en la lista final de riesgos a gestionar (figura 22.5), y bajo qué criterio?. Ocho riesgos, aquellos que tienen consecuencias catastróficas o graves. Los catorce riesgos completos identificados originalmente, sin ningún filtro adicional. Únicamente los dos riesgos con probabilidad «alta», sin importar la gravedad de sus efectos.

¿Por qué el capítulo advierte que la tabla de análisis de riesgos (figura 22.4) debe actualizarse durante cada iteración del proceso de riesgo?. Porque tanto la probabilidad como la valoración de los efectos de un riesgo pueden cambiar conforme se dispone de más información y se implementan planes de gestión. Porque la tabla caduca automáticamente cada 30 días naturales según el estándar descrito en el capítulo. Porque el cliente debe firmar una nueva versión de la tabla en cada reunión de avance, sin relación con cambios reales en el riesgo.

¿Qué debe considerar el administrador para cada riesgo clave durante el proceso de planeación del riesgo, según el capítulo?. Las acciones que puede tomar para minimizar la perturbación del proyecto si ocurre el problema, y la información que necesite recopilar para anticipar problemas. Exclusivamente el costo monetario exacto que tendría cada riesgo si llegara a materializarse por completo. El nombre del responsable legal que deberá pagar una indemnización en caso de que el riesgo se materialice.

¿Cuáles son las tres categorías de estrategias de gestión del riesgo descritas en el capítulo?. Estrategias de evitación, estrategias de minimización y planes de contingencia. Estrategias de transferencia, estrategias de aceptación y estrategias de eliminación total. Estrategias preventivas, estrategias correctivas y estrategias punitivas.

En la figura 22.5 del capítulo, ¿qué estrategia se sugiere específicamente para el riesgo de «componentes defectuosos»?. Sustituir los componentes potencialmente defectuosos con la compra de componentes de conocida fiabilidad. Alertar al cliente de dificultades potenciales y de la posibilidad de demoras en la entrega del proyecto. Reorganizar los equipos de manera que haya más traslape de trabajo entre los miembros.

¿Qué estrategia se sugiere en la figura 22.5 para el riesgo de «enfermedad del personal»?. Reorganice los equipos de manera que haya más traslape de trabajo y, así, las personas comprendan las labores de los demás. Prepare un documento informativo para altos ejecutivos que muestre la contribución del proyecto a las metas de la empresa. Investigue la posibilidad de comprar una base de datos de mayor rendimiento que la actual.

¿Cuál de las siguientes describe correctamente una «estrategia de minimización», según la definición precisa del capítulo?. Es una estrategia que reduce el EFECTO del riesgo si éste llega a ocurrir. Es una estrategia que reduce la PROBABILIDAD de que el riesgo llegue a surgir. Es una estrategia que garantiza que el riesgo jamás ocurrirá bajo ninguna circunstancia.

¿Con qué otro conflicto de la ingeniería de software establece el capítulo una «clara analogía» respecto a las estrategias de gestión del riesgo (evitar, minimizar, contingencia)?. Con las estrategias utilizadas en los sistemas críticos para garantizar fiabilidad, seguridad y protección (evitar, tolerar o recuperarse de fallas). Con las técnicas de estimación algorítmica de costos que se estudian en el capítulo 23 del libro. Con los patrones arquitectónicos de sistemas embebidos estudiados en el capítulo 20 del libro.

¿Qué comprueba específicamente el proceso de monitorización del riesgo, según el capítulo?. Que no han cambiado las suposiciones sobre riesgos del producto, el proceso y la empresa. Que el presupuesto total del proyecto no ha sido modificado desde la firma del contrato original. Que ningún miembro del equipo ha cambiado de puesto de trabajo desde el inicio del proyecto.

Según la figura 22.6 del capítulo, ¿cuál es un indicador potencial de riesgo «tecnológico»?. Entrega tardía de hardware o software de soporte, y muchos problemas tecnológicos reportados. Chismes en la organización y falta de acción de los altos ejecutivos. Muchas peticiones de cambio de requerimientos y quejas de los clientes.

¿Cuál es un indicador potencial de riesgo «de estimación», según la figura 22.6?. Falla para cumplir con el calendario acordado y falla para corregir los defectos reportados. Baja moral de personal y malas relaciones entre miembros del equipo. Renuencia de los miembros del equipo para usar herramientas CASE.

¿Con qué frecuencia deben monitorizarse los riesgos, según el capítulo, y qué debe hacerse en cada revisión administrativa?. Deben monitorizarse comúnmente en todas las etapas del proyecto, reflexionando y estudiando cada riesgo clave por separado en cada revisión administrativa. Únicamente una vez, durante la reunión de cierre del proyecto, para documentar las lecciones aprendidas. Solo cuando el cliente lo solicita expresamente por escrito, nunca por iniciativa propia del administrador.

Según el capítulo, ¿cuáles son los cuatro factores críticos en la gestión de personal, desde la perspectiva del autor?. Consistencia, respeto, inclusión y honestidad. Autoridad, disciplina, jerarquía y control. Puntualidad, productividad, rentabilidad y competitividad.