Parcial 1: Examen de Procesos de Desarrollo de Software (PDF)

**Parcial 1** 1. ¿Cuales son las características del proceso? Definido, Visible, Asistido, Aceptable, Mantenible, Confiable, Robusto, Agil 2. ¿Cuales son las fases del modelo en espiral? **Planificar objetivos**: Identificar metas, restricciones y requisitos. **Identificar y reducir riesgos**...

**Parcial 1** 1. ¿Cuales son las características del proceso? Definido, Visible, Asistido, Aceptable, Mantenible, Confiable, Robusto, Agil 2. ¿Cuales son las fases del modelo en espiral? **Planificar objetivos**: Identificar metas, restricciones y requisitos. **Identificar y reducir riesgos**: Analizar riesgos y establecer estrategias para mitigarlos. **Desarrollo y validación**: Implementar soluciones y validar entregables. **Planeación**: Planificar la próxima iteración del ciclo basándose en los resultados obtenidos. 3. ¿Que son las métricas del proceso y cuales se pueden recoger? ### **Métricas del proceso:** **Definición**: Son indicadores que se utilizan para evaluar la eficiencia y efectividad del proceso de desarrollo de software, basándose en los resultados del proceso. **Métricas que se pueden recoger**: - **Errores detectados antes de la entrega**: Mide la capacidad del proceso para encontrar errores antes de la implementación. - **Defectos reportados por usuarios**: Indica problemas no detectados en pruebas internas. - **Productos entregados**: Evalúa la productividad del equipo. - **Esfuerzo humano y tiempo**: Refleja el costo del desarrollo. - **Cumplimiento de la planificación**: Mide si se cumplen los tiempos establecidos. - **Tareas específicas**: Analiza características relacionadas con actividades de ingeniería de software. 4. ¿Que son los indicadores de proyecto? ### **Indicadores de proyecto:** Los indicadores de proyecto son datos cuantitativos utilizados para evaluar el progreso, calidad y eficiencia del proyecto. Ejemplos: - Avance del cronograma. - Coste acumulado. - Número de defectos detectados y corregidos. - Velocidad del equipo (en metodologías ágiles). **Indicadores del proyecto, permiten:** - Evaluar el estado del proyecto - Seguir la pista de los riesgos potenciales - Detección de áreas de problemas antes de que se conviertan en algo crítico - Ajustar flujo y tareas del trabajo - Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos 5. Métricas de Software. Explique Son medidas para el software de computadora, la medición se puede aplicar al proceso para mejorarlo, en el proyecto, para ayudar en la estimación o realizar control de calidad, o en el ingeniero de software, para evaluar calidad de productos o ayudar en toma de decisiones Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso tiene un atributo dado 6. Cual es el proceso de administración de riesgos? Explique ### **Proceso de administración de riesgos:** 1. **Identificación de riesgos**: Reconocer posibles problemas. 2. **Análisis de riesgos**: Evaluar la probabilidad e impacto. 3. **Priorización**: Ordenar los riesgos según su criticidad. 4. **Planificación de mitigación**: Diseñar estrategias para reducir o eliminar riesgos. 5. **Seguimiento y control**: Supervisar y ajustar los planes según sea necesario. Como se identifican los riesgos? Descubriendo problemas potenciales dentro del proyecto como por ejemplo la existencia de que en un deposito se pueda ocasionar un incendio, por lo cual se deben tomar estrategias colaborativas, buscar problemas desde diversas fuentes, ver riesgos desde dos direcciones, tanto los topicos potenciales como sus consecuencias probables, como las consecuencias probables y sus causas probables Analisis de riesgos: convertir los datos de riesgos en info para toma de decisiones, comprender por que se puede ocasionar el incendio y los costes de daño, por lo cual se evalua probabilidad, impacto y exposicion Diseño del PLAN de riesgos: planificar como evitar o minimizar el riesgos, prevenir el incendio, mediante cinco areas claves como Investigar, Aceptar, Evadir, Mitigar, Contingencia Rastreo de riesgos: monitoreo de riesgos y planes de mitigacion Control de riesgos, se controlan los resultados del rastreo de riesgos y retirar este mismo si se tomo la accion, para controlar los riesgos se deben adaptarse las prioridades de los riesgos segun los cambios, reaccionar a variaciones del plan, responder a eventos disparadores, evaluar el proceso de administracion de riesgos 7. Que es la complejidad ciclomática? ### **Complejidad ciclomática:** Es una métrica de software que mide la cantidad de caminos independientes a través de un programa. Se calcula utilizando: M=E−N+2PM = E - N + 2PM=E−N+2P Donde: - EEE = Número de aristas en el grafo. - NNN = Número de nodos. - PPP = Número de componentes conectados. **Uso**: Ayuda a estimar la prueba mínima necesaria y evaluar la mantenibilidad del código. 8. ¿Que es la calidad? ¿Como exploraría el coste, garantía y control de calidad? **Definición**: Grado en el que un software cumple con los requisitos especificados y satisface las necesidades del usuario. **Coste de calidad**: - **Prevención**: Inversiones para evitar defectos. - **Evaluación**: Costes de pruebas y revisiones. - **Fallos**: Costes derivados de errores no detectados. **Garantía y control de calidad**: - **Garantía de calidad (QA)**: Enfoque preventivo para asegurar estándares en el proceso. - **Control de calidad (QC)**: Inspección de entregables para identificar defectos. 9. Situación: Estás gestionando un proyecto de software para una empresa, el proyecto debe completarse en 6 meses ### **Gestión de riesgos en un proyecto de software:** **Riesgos posibles y evaluación**: 1. **Falta de recursos clave**: - Probabilidad: Alta - Impacto: Alto - Mitigación: Contratar personal externo o redistribuir tareas. 2. **Cambios en los requisitos del cliente**: - Probabilidad: Media - Impacto: Alto - Mitigación: Usar metodologías ágiles para adaptarse a cambios. 3. **Problemas técnicos imprevistos**: - Probabilidad: Media - Impacto: Alto - Mitigación: Reservar tiempo en el cronograma para investigación técnica. 4. **Retrasos en entregas de terceros**: - Probabilidad: Media - Impacto: Medio - Mitigación: Identificar proveedores alternativos y establecer márgenes en el cronograma. 5. **Falta de cumplimiento del cronograma**: - Probabilidad: Alta - Impacto: Medio - Mitigación: Monitorear el progreso regularmente y ajustar tareas según prioridad. **Matriz de riesgos**: ------------------------------- ------------------ ------------- ---------------------------------------- **Riesgo** **Probabilidad** **Impacto** **Mitigación** Falta de recursos clave Alta Alto Contratar personal externo. Cambios en requisitos Media Alto Metodología ágil. Problemas técnicos Media Alto Reservar tiempo para investigación. Retrasos en entregas Media Medio Márgenes de seguridad en cronograma. Incumplimiento del cronograma Alta Medio Monitoreo continuo y ajuste de tareas. ------------------------------- ------------------ ------------- ---------------------------------------- - **La Ingeniería de software concierne a las teorías, métodos y herramientas para el desarrollo, administración y evolución de productos de software** - **Los productos de software están conformados por programas y documentación. Los atributos de los productos deben ser, mantenibilidad, confiabilidad, eficiencia y usabilidad.** - **Un proceso de software consiste en aquellas actividades involucradas en su desarrollo** - **El modelo de cascada considera cada actividad del proceso como una actividad discreta.** - **El modelo de desarrollo evolutivo considera actividades del proceso en forma concurrente.** - **El modelo de espiral se basa en análisis de riesgos.** - **La visibilidad del proceso involucra la creación de documentos o resultados de las actividades.** - **Los Ingenieros de software deben tener responsabilidades éticas, sociales y profesionales.** **¿Cuáles son los productos de Software?** - Productos genéricos: son producidos por la organización para ser vendidos al por mayor - Hechos a medida: producidos con el fin de brindarle el servicio a un cliente/desarrollador específico La mayor parte del gasto del software es en productos genéricos, pero hay mas esfuerzo en el desarrollo de los sistemas hechos a medida Características de los **Productos de Software** - Mantenible: el sw debe evolucionar y seguir cumpliendo con sus requerimientos - Confiable: el software no debe causar fallos físicos o económicos - Eficiente: el software no debe desperdiciar los recursos del sistema - Fácil de usar: el software debe proporcionar una interfaz intuitiva para el cliente **¿Cuál es la importancia de las características del producto?** La importancia depende del tipo de trabajo y ambiente del cual será utilizado, dado que algunos atributos pueden dominar, como en el caso de un software de seguridad críticos de tiempo real, donde la confiabilidad y la eficiencia tienen que estar casi presentes, dado que el sistema debe tener alta disponibilidad y tolerancia a fallos. Los costos tienden a crecer exponencialmente si requieren niveles estrictos de determinadas características **Que es el proceso de software?** Conjunto estructurado de actividades requeridas para desarrollar un sistema de software, estas están constituidas en - Especificación - Diseño - Validación - Evolución Las actividades varían dependiendo de la organización y el tipo de sistema a desarrollar Debe estar explícitamente modelado si va a ser bien administrado **Características del proceso** - Definido: debe estar bien definido y comprensible - Visible: el proceso debe estar visible - Asistido: Soporte del proceso por herramientas case - Aceptable: el proceso debe ser aceptado por el personal involucrado - Confiable: los errores del proceso deben ser descubiertos antes de que sean errores del producto - Robusto: el proceso debe seguir a pesar de los problemas inesperados - Mantenible: el proceso debe evolucionar para cumplir con objetivos organizacionales - Agil: el proceso debe producirse con rapidez **¿Cuál es el modelo de Ingeniería del Proceso?\ ** - Especificación: se debe establecer los reqs y restricciones del sistema - Diseño: modelar la solución - Construccion: desarrollar el sistema - Prueba: verificar y validar que el sistema cumpla con las especificaciones requeridas - Instalacion: entregar el sistema al usuario y asegurar su funcionamiento - Mantenimiento: reparar fallos en el sistema cuando sean descubiertos **Que problemas puede tener el modelo de proceso?** - Especificaciones incompletas o anómalas - Nula existencia de distinguir con precisión la especificación, diseño y construcción - No se puede probar el sistema hasta que se haya producido - El software no se puede reemplazar siempre durante el mantenimiento **Modelos Genéricos de Desarrollo de Software** - Modelo de Cascada: Separa en distintas fases las especificación y el desarrollo - Desarrollo Evolutivo: a diferencia del cascada, la especificación y el desarrollo están intercalados - Prototipado: un modelo sirve de prototipo para construir el sistema final - Transformación Formal: un modelo matemático del sistema se transforma formalmente en la implementación - Desarrollo basado en reutilización: el modelo es reensamblado a partir de componentes existentes **Modelo de cascada en que consiste? Es decir, ¿Cuáles son sus fases?** - Definición de requerimientos - Diseño del sistema y del software - Implementación y unit test - Integración y pruebas del sistema - Operación y mantenimiento La dificultad del modelo reside en realizar cambios entre etapas **Desarrollo Evolutivo** **Desarrollo Evolutivo: Problemas y aplicabilidad** problemas: - Poca visibilidad en el proceso - Los sistemas están pobremente especificados - Se requieren habilidades especiales aplicabilidad: - sistemas interactivos pequeños o medianos - partes de sistemas grandes (ej: interfaz de usuario) - sistemas de corta vida **Prototipado** Prototipado exploratorio: el objetivo es trabajar con clientes hasta llegar a un sistema final, a partir de una especificación inicial, se debe comenzar igual con especificaciones bien entendidas Prototipado throw-away: el objetivo es entender los requerimientos del sistema, se puede comenzar con especificaciones poco entendidas **Problemas y riesgos con los modelos** **Cascada:** - Alto riesgos en sistemas nuevos debido a problemas en la especificaciones y en el diseño - Bajo riesgo para desarrollos bien comprendidos usando tecnología conocida **Prototipado:** - Bajo riesgo para apps nuevas dado que las especificaciones y diseño se llevan a cabo paso a paso - Alto riesgo debido a falta de visibilidad **Evolutivo:** - Alto riesgo debido a la necesidad de tecnología avanzada y habilidades del grupo desarrollador **Que son los modelos de procesos híbridos?** - Los sistemas grandes están hechos usualmente de varios subsistemas - No es necesario usar el mismo modelo de proceso para todos los subsistemas - El prototipado es recomendado cuando existen especificaciones de alto riesgo - El modelo de cascada es usado en desarrollos bien comprendidos **FASES DEL MODELO EN ESPIRAL** - Planeamiento de objetivos: se identifican los objetivos para cada fase del proyecto - Identificación y reducción de riesgos: los riesgos clave se identifican y analizan, la información sirve para minimizar los riegos - Desarrollo y validación: se elige un modelo apropiado para la siguiente fase del desarrollo - Planeación: se revisa el proyecto y se trazan planes para la siguiente ronda del espiral **Ventajas del modelo en espiral:** - Centra su atención en reutilizar componentes y eliminar errores en información descubierta en fases iniciales - Los objetivos de calidad son primordiales - Integra desarrollo con mantenimiento - Provee un marco de desarrollo de HW/SW **Problemas con el Modelo de Espiral:** - El desarrollo contractual específica el modelo del proceso y los resultados a entregar por adelantado - Requiere de experiencia en identificar riesgos - Requiere refinamiento para uso generalizado **Visibilidad del modelo**  - **Es muy difícil formular una especificación de requerimientos completa y consistente.** - **Una definición de requerimientos, una especificación de requerimientos y una especificación de Software son una manera de especificar el Software para diferentes tipos de lectores.** - **El Documento de Requerimientos es una descripción para clientes y desarrolladores.** - **Los errores en los requerimientos son usualmente muy caros de corregir una vez desarrollado el sistema.** - **La revisión debe involucrar al cliente y al staff de contratistas para validar los requerimientos del sistema.** - **El establecer requerimientos está relacionado con las actividades del cliente para el Software.** - **Los requerimientos volátiles dependen del contexto en que se use el sistema.** **Que es la ingeniería de requerimientos?** Es el proceso de establecer los servicios que el cliente requiere de un sistema y los límites los cuales opera y se desarrolla, dichos requerimientos pueden ser funcionales o no funcionales, el primero se centra en servicios y funciones mientras que el segundo está orientado a las limitaciones del sistema o de proceso de desarrollo **¿Qué es un requerimiento?** Es un rango de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar una especificación funcional matemática Así es inevitable como los requerimientos pueden servir en una función dual, puede ser la base para declarar un contrato, por ende debe estar abierto a interpretación, o tambien puede ser la base para el contrato en sí, por lo cual, debe ser definido en detalle **Definición/Especificación de Requerimientos** Definición de requerimientos: declaración en un lenguaje natural incluye diagramas de los servicios del sistema y sus límites operacionales, escrito para clientes Especificación de Requerimientos: un documento estructurado con descripción o detalles de los servicios del sistema, escrito como un contrato entre el cliente y el contratista Especificación de Software: descripción detallada de software, la cual, puede servir como base para diseño o implementación, escrito para desarrolladores **¿Cuál es el proceso de la ingeniería de requisitos?** **Estudio de Factibilidad**: encuentran usuarios actuales que sus necesidades son satisfechas dada la tecnología y presupuesto disponible? **Análisis de Requerimientos**: encontrar que el sistema requiere de mantener intereses **Definición de Requerimientos:** definir los reqs en forma comprensible para el cliente **Especificación de Requerimientos**: define los reqs en detalle **Documento de Requerimientos:** - Declaración oficial de lo que se requiere para ser desarrollado - Incluye definición y especificación de requerimientos - No es un documento de diseño, sino un conjunto de lo que es el sistema y lo que se hará **Requerimientos del Documento de Requerimientos** - Especificación de la conducta externa del sistema - Especificar límites de implementacion - Fácil de cambiar - Sirve como una herramienta de referencia para mantenimiento - Recuerda el ciclo de vida del sistema, esto es, predice cambios - Proporciona respuestas características a un evento no esperado **Estructura del Documento de Requerimientos** - **Introducción**: describe necesidad de crear el sistema y cuales son sus objetivos - **Glosario**: define los términos técnicos usados - **Modelos del Sistema**: define los modelos que muestran componentes del sistema las relaciones entre ellos - **Definicion de Requerimientos Funcionales**: define servicios que serán proporcionados - **Definición de Requerimientos No-funcionales**: Definir límites de sistema y el proceso de desarrollo - **Evolución del Sistema**: definir las suposiciones fundamentales en las cuales el sistema se basa y se anticipan los cambios - **Especificación de requerimientos**: especificación detallada de reqs funcionales del sistema - **Apéndices**: descripción de la plataforma de Hardware del Sistema, reqs de la DB - **Índice** **Validación de Requerimientos** Son la demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere, los costos en estos reqs son altos por lo cual validarlos es muy importante y el prototipado es una técnica importante dentro de validar requerimientos pag 18 **Chequeando Requerimientos** - Validación. Provee al sistema las funciones que mejor soporten las necesidades del cliente? - Consistencia. Existe cualquier conflicto en los requerimientos? - Completo. Están incluidas todas las funciones requeridas por el cliente? - Realismo. Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? **Revisión de Requerimientos** - Una revisión regular puede ayudar mientras la definición de requerimientos está siendo hecha. - Tanto el cliente como el staff de contratistas deben estar involucrados en la revisión. - La revisión debe ser formal (con los documentos completos) o informal. - Una buena comunicación entre desarrolladores, clientes y usuarios puede resolver problemas en las primeras etapas. **Chequeo de la Revisión** - Verificabilidad. Es el Requerimiento realmente probable? - Entendibilidad. Es el Requerimiento comprendido propiamente? - Probabilidad. Es el origen de los requerimientos claramente establecido? - Adaptabilidad. Puede el requerimiento ser cambiado sin causar un gran impacto en otros requerimientos?  **Evolución de Requerimientos** - Los requerimientos siempre involucran como comprender mejor el desarrollo de las necesidades de los usuarios y como los objetivos de la organización pueden cambiar. - Es esencial planear posibles cambios en los requerimientos cuando el sistema sea desarrollado y utilizado. **Clases de Requerimientos** - Requerimientos Durables. Establecer requerimientos derivados de las actividades de la organización del cliente. Por ejemplo, un hospital siempre tendrá doctores, enfermeras, etc. Puede ser derivado de modelos de dominio. - Requerimientos Volátiles. Los requerimientos cambian durante el desarrollo o cuando el sistema está en uso. En un hospital, los requerimientos se derivan de las políticas salud-cuidados. **Clasificación de Requerimientos** - **Requerimientos Cambiantes.** - **Surgimiento de los Requerimientos.** - **Requerimientos en Consecuencia.** - **Requerimientos Compatibles.** **Cambios en el Documento de Requerimientos** - El documento de requerimientos debe ser organizado, de tal forma que los cambios en los requerimientos puedan ser hechos sin tener que re-escribir demasiado. - Las referencias externas deben ser minimizadas y las secciones del documento deben ser tan modulares como sea posible. - Los cambios son fáciles cuando se trata de un documento electrónico. Sin embargo, la falta de estándares para documentos electrónicos lo hace difícil. **¿Qué es la administración de proyectos?** Es organizar, planear y calendarizar proyectos de software, son las actividades que permiten asegurar que el software se lleva a cabo a tiempo y acorde a la planificación, así como de acuerdo a los requerimientos del software **¿Cuál es la importancia de la administración?** La ingeniería de software en sí, es una actividad económica importante sujeta a restricciones económicas y no técnicas, los proyectos bien administrados a veces fallan mientras que los mal administrados siempre fallan. El objetivo del curso es introducir las actividades de la administración, en lugar de enseñar a ser el admin, solo se puede aprender si se desempeña la función en primer lugar **Características de la Administración de Software** - El producto a desarrollar es intangible - El producto tiene su propia flexibilidad - La ingeniería de software no es reconocida como una disciplina de la ingeniería con el mismo estatus de la mecanica, electrica, matemática, etc - El proceso de desarrollo de sw no está estandarizado - La mayoría de proyectos de software son "on-off" **Actividades de la Administración** - Escritura de la propuesta - Estimación del coste de proyecto - Planear proyectos y planificar tiempos - Monitorear proyecto y hacer revisiones - Seleccionar personal y evaluarlos - Escribir presentaciones y reportes **¿Cuáles son los casos comunes de la administración?** Las actividades de la administración no son sólo particulares en esta disciplina, muchas técnicas de la ingeniería de proyectos o investigación de operaciones son igualmente aplicables a la administración de proyectos y los proyectos de ingeniería complejos tienden a sufrir los mismos problemas que los sistemas de software **Personal del Proyecto** Puede ser imposible reclutar a la gente ideal para trabajar en el proyecto dado por el presupuesto del proyecto, quizas no pueda permitir pagar altos salarios de gente experimentada, o que esta no esté disponible, e inclusive la organizacion prefiere capacitar a sus empleados en las capacidades necesarias para desarrollar proyectos de software **Planeación del Proyecto** - Conjunto de actividades necesarias para desarrollar el proyecto. - Probablemente es la actividad que más consume tiempo. - Existe una actividad continua desde el concepto inicial del proyecto hasta que este es liberado. Los planes deben de ser revisados regularmente a medida que está disponible nueva información. **Estructura del plan del proyecto** - Introducción - Organización del proyecto - Análisis de riesgos - Requerimientos de software y hardware - Repartición del trabajo - Planificación del trabajo - Monitorización y mecanismos de reporte. **Organización de actividades** - Las actividades en un proyecto deben ser organizadas para producir resultados tangibles para que la administración pueda juzgar el progreso. - Los "Milestones" son los puntos finales de alguna actividad. - Los "deliverables" son los resultados del proyecto que serán entregados a los clientes. - El proceso de "cascada" permite una definición precisa de los "milestones". **Problemas en la Planificación** - Es difícil estimar la longitud y dificultad de las tareas, por lo que la estimación del coste es mas difícil. - La productividad no es proporcional a el número de personas trabajando en una tarea. - Incluir personal en un proyecto en avance, retrasa el proyecto por "overheads" en la comunicación. - Lo inesperado siempre sucede. Es necesario considerar siempre contingencias. **Organización de actividades** - Las actividades en un proyecto deben ser organizadas para producir resultados tangibles para que la administración pueda juzgar el progreso. - Los "Milestones" son los puntos finales de alguna actividad. - Los "deliverables" son los resultados del proyecto que serán entregados a los clientes. - El proceso de "cascada" permite una definición precisa de los "milestones".  Como se identifican los riesgos? Descubriendo problemas potenciales dentro del proyecto como por ejemplo la existencia de que en un deposito se pueda ocasionar un incendio, por lo cual se deben tomar estrategias colaborativas, buscar problemas desde diversas fuentes, ver riesgos desde dos direcciones, tanto los topicos potenciales como sus consecuencias probables, como las consecuencias probables y sus causas probables Analisis de riesgos: convertir los datos de riesgos en info para toma de decisiones, comprender por que se puede ocasionar el incendio y los costes de daño, por lo cual se evalua probabilidad, impacto y exposicion Diseño del PLAN de riesgos: planificar como evitar o minimizar el riesgos, prevenir el incendio, mediante cinco areas claves como Investigar, Aceptar, Evadir, Mitigar, Contingencia Rastreo de riesgos: monitoreo de riesgos y planes de mitigacion Control de riesgos, se controlan los resultados del rastreo de riesgos y retirar este mismo si se tomo la accion, para controlar los riesgos se deben adaptarse las prioridades de los riesgos segun los cambios, reaccionar a variaciones del plan, responder a eventos disparadores, evaluar el proceso de administracion de riesgos **ESTRATEGIAS DE RIESGO PROACTIVAS Y REACTIVAS** - **Reactiva**: supervisa el proyecto en prevención de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas. Lo mas frecuente es que el equipo de soft no haga nada respecto a los riesgos hasta que algo va mal. - **Proactiva**: empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una prioridad según su importancia. Después el equipo de soft establece un plan para controlar el riesgo. **RIESGOS DEL SOFTWARE** **El riesgo siempre implica dos características:** - Incertidumbre: el acontecimiento que caracteriza al riego puede o no ocurrir. - Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y grado de pérdida asociados a cada riego. Para hacerlo se consideran diferentes categorías de riesgos: - Riesgos del proyecto: si se hacen realidad, es posible que la planificación temporal del proyecto se retrase y que los costos aumenten (problemas potenciales de personal, cliente, requisitos, etc.). - Riesgos técnicos: amenazan la calidad y la planificación temporal del soft (problemas de diseño, implementación, interfaz, verificación, mantenimiento- ambigüedades de especificaciones, incertidumbres técnicas, etc.). - Riesgos del negocio: amenazan la viabilidad del soft a construir. A menudo ponen en peligro el proyecto o el producto. **Candidatos para los 5 principales riesgos del negocio:** - Construir un producto o sistema excelente que no quiere nadie en realidad (riego de mercado) - Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico) - Construir un producto que el departamento de ventas no sabe como vender - Perder el apoyo de una gestión experta debido a cambios de enfoque o cambios de personal. - Perder presupuesto o personal asignado. **Otra categorización**: - Riesgos conocidos: se pueden descubrir después de una cuidadosa evaluación del plan del proyecto. - Riesgos predecibles: se extrapolan de la experiencia en proyectos anteriores. - Riesgos impredecibles: son difíciles de identificar por adelantado. **IDENTIFICACIÓN DEL RIESGO** La identificación del riego es un intento sistemático para especificar las amenazas al plan del proyecto. Existen dos tipos: - Riesgos genéricos: Son una amenaza potencial para todos los proyectos de soft. - Riesgos específicos: se pueden identificar si se tiene una clara visión de la tecnología, el personal y el entorno específico del proyecto. Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgos. La lista de comprobación se puede utilizar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas: - tamaño del producto - impacto en el negocio - características del cliente - definición del proceso - entorno del proceso - entorno a construir - tecnología a construir - tamaño y experiencia de la plantilla. **Componentes de riesgo:** - riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido. - riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto. - riesgo de soporte: el grado de incertidumbre de la facilidad del soft para corregirse, adaptarse y ser mejorado. - riesgo de planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo. **PROYECCIÓN DEL RIESGO** También denominada estimación del riesgo, intenta medir el riesgo de dos maneras: - la probabilidad de que el riego sea real y las consecuencias de los problemas asociados con el riego, si ocurriera cuatro actividades de proyección de riesgo: 1\) establecer una escala que refleje la probabilidad percibida del riesgo. 2\) Definir las consecuencias del riesgo. 3\) Estimar el impacto del riesgo en el proyecto y en el producto 4\) Apuntar la exactitud general de la proyección del riego de manera que no haya confusiones. **REDUCCIÓN, SUPERVICION Y GESTION DEL RIESGO** Todas las actividades de análisis de riesgo tienen un solo objetivo: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: - Evitar el riesgo - Supervisar el riesgo - Gestión del riesgo y planes de contingencia Si un equipo de soft adopta un enfoque A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo. La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad. - **RIESGOS Y PELIGROS PARA LA SEGURIDAD** La seguridad del software y el análisis del peligro son actividades para garantizar la calidad del software que se centra en la identificación y evaluación de peligros potenciales que pueden impactar al software negativamente y provocar que falle el sistema entero. ¿Qué son las métricas de software? Son medidas para el software de computadora, la medición se puede aplicar al proceso para mejorarlo, en el proyecto, para ayudar en la estimación o realizar control de calidad, o en el ingeniero de software, para evaluar calidad de productos o ayudar en toma de decisiones ¿Qué es una medida? Indicación cuantitativa de extensión cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto Medición: Acto de determinar una medida Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso tiene un atributo dado Indicador: se obtiene de la recopilación de medidas y desarrollo de métricas Indicadores de proceso, permiten - Tener visión de la eficiencia de un proceso ya existente - Evaluar lo que funciona y lo que no - Las métricas se recopilan de todos los proyectos un largo tiempo Indicadores del proyecto, permiten: - Evaluar el estado del proyecto - Seguir la pista de los riesgos potenciales - Detección de áreas de problemas antes de que se conviertan en algo crítico - Ajustar flujo y tareas del trabajo - Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos **MÉTRICAS DEL PROCESO** La eficiencia de un proceso de soft se mide indirectamente. Se extrae un juego de métricas según los resultados que provienen del proceso. Entre los resultados se incluyen: \- Errores detectados antes de la entrega del soft. \- Defectos detectados e informados por los usuarios finales. \- Productos de trabajo entregado \- Esfuerzo humano y tiempo consumido \- Ajuste con la planificación \- Características de tareas específicas de la ing del software. **Para diferentes tipos de datos de proceso existen métricas de:** **Uso privado**: entre los ejemplos de métricas que son privadas del individuo se incluyen: \- indices de defectos \- índices de defectos por módulos \- errores encontrados durante el desarrollo **Uso público**: algunas métricas del proceso son privadas para el equipo del proyecto, pero son públicas para todos los miembros del equipo. Entre los ejemplos se incluyen: \- defectos informados de funciones importantes del software \- errores encontrados durante revisiones técnicas formales y líneas de código o puntos de función por módulo y función **El análisis de fallos funciona de la siguiente manera:** 1\) todos los errores y defectos se categorizan por origen 2\) se registra tanto el coste de corregir cada error como el defecto. 3\) El número de errores y de defectos de cada categoría se cuentan y se ordenen en orden descendente. 4\) Se computa el coste global de errores y defectos de cada categoría. 5\) Los datos resultantes se analizan para detectar las categorías que producen el costo más alto para la organización. 6\) Se desarrollan planes para modificar el proceso con el intento de eliminar la clase de errores y defectos que sean más costosos. La colección de métricas del proceso es el conductor para la creación del diagrama en espina completo desde el cual se puede analizar para extraer los indicadores que permitan a una organización modificar su proceso para reducir la frecuencia de errores y defectos **METRICAS DEL PROYECTO** \- Se deben recopilar métricas de proyectos anteriores que se utilizan como base para estimaciones (medidas de esfuerzo y tiempo). \- Se miden índices de producción. \- Se miden horas de revisión \- Los puntos de función \- Líneas fuentes entregadas. \- Se sigue la pista de los errores detectados \- Se recopilan las métricas técnicas para evaluar la calidad del diseño. **El uso de métricas para el proyecto tiene dos aspectos fundamentales:** \- Minimizar la planificación de desarrollo \- Evaluar la calidad de los productos en el momento actual **Otro modelo de métricas sugiere que todos los proyectos deberían medir:** \- Entradas: la dimensión de los recursos (personas, entorno) que se requieren para realizar el trabajo \- Salidas: medidas de las entregas o productos creados durante el proceso de ingeniería del soft. \- Resultados: medidas que indican la efectividad de las entregas. Este modelo se puede aplicar tanto al proceso como al proyecto. Las salidas de una actividad se convierten en las entradas de las siguientes. **MEDICIONES DEL SOFTWARE** Medidas directas: \- Del proceso de la ingeniería del software: se incluyen el coste y el esfuerzo aplicados. \- Del producto: se incluyen las líneas de código producidas, velocidad de ejecución, tamaño de memoria y los defectos. Medidas indirectas: \- Se incluyen la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento. Las métricas del software se dividen en métricas de: \- proceso \- proyecto \- producto **METRICAS ORIENTADAS AL TAMAÑO** \- Provienen de la normalización de las medidas de calidad y/o tamaño productividad considerando el "tamaño" del software que se haya producido. \- Si una organización de soft mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño. La tabla lista cada proyecto de desarrollo de soft de últimos años y las medidas correspondientes de cada proyecto. \- Se seleccionan líneas de código como valor de normalización (LDC) Métricas simples orientadas al tamaño: \- errores por KLDC (miles de líneas de código, KiloLDC) \- defectos por KLDC \- \$ por LDC - páginas de documentación por KLDC \- errores/persona-mes \- LDC por persona-mes \- \$/página dedocumentación. **METRICAS ORIENTADAS A LA FUNCION** Utilizan una medida de la funcionalidad entregada por la aplicación como valor de normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. **Punto de función**: se derivan con una relación empírica según las medidas contables (directas) del dominio de información del soft y las evaluaciones de la complejidad del soft. Para aplicaciones de sist de inf de gestión. Se determinan cinco (5) características de dominios de información. Los valores de dominios se definen de la forma siguiente: \- número de entradas de usuario \- número de salidas de usuario \- número de peticiones de usuario \- números de archivos \- número de interfaces externas. Una vez que se han recopilado los datos, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de punto de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. Para calcular puntos de función (PF) se utilizan la siguiente relación: **PF= cuenta total \* (0.65 + 0.01 \* Fi)**  **Actividades del proceso** - Comprensión del dominio - Colección de requerimientos - Clasificación - Solución de conflictos - Priorización - Validación de requerimientos