• Author / Uploaded
• Daniel Enrique Erazo Mujica

Citation preview

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

Ingeniería Informática (Prof. Osmar Mavárez) Pagina para la práctica del Conocimiento

Unidad III INGENIERIA DEL SOFTWARE II TRAYECTO III FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS UNIDAD III ANÁLISIS DE REQUERIMIENTOS DE SOFTWARE    CONTENIDO 1. Inspección de requerimientos de software Impacto de los defectos del software en el costo El proceso de inspección 2. Documentos de Requerimientos de Software: Creación, usos e Importancia. 3. Métricas y herramientas para la ingeniería de requisitos.   UNIDAD III 1. INSPECCIÓN DE REQUERIMIENTOS DE SOFTWARE Las inspecciones de requerimientos de software surgen a partir de la necesidad de producir software de alta calidad. La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software. Es un grave error considerar que la calidad del software es algo en lo que solo deben preocuparse una vez que se ha generado el código. La SQA (Software Quality Assurance) engloba: Un enfoque de gestión de calidad Tecnología de Ingeniería de Software efectiva (métodos y herramientas) Revisiones técnicas formales que se aplican durante el proceso del software Una estrategia de prueba multiescalada

https://univertic.wordpress.com/unidad­iii/

1/10

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

Una estrategia de prueba multiescalada Un control de la documentación del software y de los cambios realizados Un procedimiento que asegure un ajuste a los estándares de desarrollo de software Mecanismos de medición y de generación de informes El control de la calidad es una serie de revisiones, y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. La garantía de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de información de la gestión. El objetivo de la garantía de la calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Es de esperar, que si los datos proporcionados mediante la garantía de la calidad identifican problemas, la gestión afronte los problemas y aplique los recursos necesarios para resolverlos. La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes: los ingenieros de software, que realizan trabajo técnico, y un grupo SQA, que tiene la responsabilidad de la planificación de garantía de calidad. En éste marco podemos ver a las inspecciones como una implementación de las revisiones formales del software las cuales representan un filtro para el proceso de ingeniería de software, éstas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden así ser eliminados. Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad de revisiones: El trabajo técnico necesita ser revisado por la misma razón que los lápices necesitan gomas: errar es humano. La segunda razón por la que necesitamos revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan más fácilmente al que los origina que a otras personas. El proceso de revisión es, por lo tanto la respuesta a la plegaria de Robert Burns: ¡Qué gran regalo sería poder vernos como nos ven los demás! Una revisión es una forma de aprovechar la diversidad de un grupo de personas para: 1. Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo 2. Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora. 3. Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud y Completitud principalmente. Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos. Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal técnico es una forma de revisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, que llamaremos Inspección de Software 1.1. Impacto de los defectos del software en el costo

https://univertic.wordpress.com/unidad­iii/

2/10

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

1.1. Impacto de los defectos del software en el costo Dentro del contexto de desarrollo de software, los términos “defecto” y “fallo” son sinónimos. Ambos implican un problema de calidad descubierto después de entregar el software a los usuarios finales. El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno). Una serie de estudios (TRW, Nippon Electric y Mitre Corp., entre otros) indican que las actividades del diseño introducen entre el 50% y 65% de todos los errores(y en último lugar, todos los defectos) durante el proceso de software. Si embargo se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores [JON86]. Con la detección y la eliminación de un gran porcentaje de errores, el proceso de inspección reduce substancialmente el costo de los pasos siguientes en las fases de desarrollo y mantenimiento. Para ilustrar el impacto sobre el costo de la detección anticipada de errores, consideremos una serie de costos (h p://www.monografias.com/trabajos4/costos/costos.shtml) relativos que se basan en datos de costos realmente recogidos en grandes proyectos (h p://www.monografias.com/trabajos12/pmbok/pmbok.shtml) de software [IBM81]. Supongamos que un error descubierto durante el diseño cuesta corregirlo 1,0 unidad monetaria. De acuerdo a este costo , el mismo error descubierto justo antes de que comience la prueba costará 6,5 unidades; durante la prueba 15 unidades; y después de la entrega, entre 60 y 100 unidades. 1.2‑ El proceso de inspección. Podemos ver a las inspecciones de software como un repaso detallado y formal del trabajo en proceso. Pequeños grupos de trabajadores (4 o 5) estudian el “”producto de trabajo”” independientemente y luego se reúnen para examinar el trabajo en detalle. El “”producto de trabajo”” representa 200 a 250 líneas de código, Requerimientos, diseño y otros productos de trabajo son inspeccionados en un tamaño similar. Los productos de trabajo son considerados en progreso hasta que la inspección y las correcciones necesarias estén completas. El tiempo de la inspección varía según cuan familiarizado esté el inspector con el material. La inspección consiste en seis pasos [Fagan 1986] : 1. Planificación: Cuando el desarrollador completa su un “”producto de trabajo””, se forma un grupo de inspección y se designa un moderador. El moderador asegura que el “”producto de trabajo”” satisfaga el criterio de inspección. Se le asignan diferentes roles a las personas que integran el grupo de inspección, así como la planificación de tiempos y recursos necesarios . 2. Overview: Si los inspectores no están familiarizados con el desarrollo de l proyecto, un vista general es necesaria en éste momento. Este es un paso opcional, pero no menos importante ya que en esta etapa se dará al grupo de inspección un “background” y el contexto a cubrir por

https://univertic.wordpress.com/unidad­iii/

3/10

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

que en esta etapa se dará al grupo de inspección un “background” y el contexto a cubrir por las inspecciones. 3. Preparación: Los inspectores se preparan individualmente para la evaluación en la reunión, estudiando los productos de trabajo y el material relacionado. Aquí es aconsejable la utilización de listas de chequeos para ayudar a encontrar defectos comunes, y . El tiempo que pueda llevar esta etapa va a depender de cuan familiarizado esté el inspector con el trabajo que debe analizar. 4. Examen: En esta etapa, los inspectores se reunen para analizar su trabajo individual en forma conjunta. El moderador deberá asegurarse que todos los inspectores están suficientemente preparados. La persona designada como lector presenta el “producto de trabajo”, interpretando o parafraseando el texto, mientras que cada participante observa en busca de defectos. Es recomendable que este examen no dure mas de 2 horas ya que la atención en busca de defectos va disminuyendo con el tiempo. Al terminar con la reunión, el grupo determina si el producto es aceptado o debe ser retrabajado para una posterior inspección. 5. Retrabajo: El autor corrige todos los defectos encontrados por los inspectores. 6. Seguimiento: El moderador chequea las correcciones del autor. Si el moderador está satisfecho, la inspección está formalmente completa, y el “producto de trabajo” es puesto bajo el control de configuración. A partir de estos seis pasos surge la necesidad de la conformación de: objetivos, participantes de la inspección y con qué roles, productos de trabajo a inspeccionar y cual deberá ser el resultado de las reuniones de inspección. Objetivos: El principal objetivo es encontrar defectos en el “producto de trabajo”, de esta manera debemos definir cuáles serán las metas a alcanzar para el cumplimiento de éste objetivo. En nuestra opinión el establecimiento de éstas metas están en relación directa con el tipo de proyecto, metodologías y herramientas utilizados Grupos de inspección: Se recomienda formar grupos entre 3 y 6 personas [IEEE STD 1028‑ 1988]. Dentro de éste grupo debe incluirse al autor de los productos de trabajo. Roles: Además del autor se deberá tener en cuenta al moderador quien dirige la inspección y deberá contar con mayor experiencia que el resto, el lector quien presenta los productos de trabajo en las reuniones y el escriba quien documenta la descripción y ubicación de los defectos encontrados. Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes tipos de productos de trabajo que pueden encontrarse en un desarrollo de software incluyendo requerimientos, diseño, código, test, guías de usuario y otro tipo de documentación. El estándar de la IEEE no especifica un tamaño , pero los productos de trabajo tienen un tamaño de 10 a 20 hojas para especificación de requerimientos, 200 o 250 líneas de código. En nuestra opinión también se debe tener en cuenta la división natural que pueda tener cada uno de éstos documentos, ya que toda especificación podremos dividirla en partes así como el diseño o el código. Resultado de las reuniones de inspección: Los dos resultados principales debe ser: Una lista de defectos a corregir , y un reporte de inspección que describa que es lo que se inspeccionó, quien inspeccionó qué y el número de defectos encontrados.

2.‑ DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE: CREACIÓN, USOS E

https://univertic.wordpress.com/unidad­iii/

4/10

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

2.‑ DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE: CREACIÓN, USOS E IMPORTANCIA 2.1. ¿Qué es un documento de requerimientos? El documento de requerimientos es la declaración oficial de qué es lo que deben implementar los desarrolladores de software. Debe incluir tanto los requerimientos a nivel de usuario para el sistema, como una especificación detallada de los requerimientos informáticos, siendo muy claro en las partes más críticas. ¿Cuál es el objetivo de un documento de requerimientos? Los documentos de requerimientos del software son la declaración acordada de los requerimientos del sistema. Se deben organizar de tal forma que puedan ser utilizados tanto por los clientes del sistema como por los desarrolladores del software. Los requerimientos para un sistema software determinan lo que debe hacer el sistema y definen las restricciones en su funcionamiento.   ¿Cuáles son los elementos de un documento de requerimientos? 1. Introducción Propósito del documento de requerimientos Alcance del producto Definiciones, acrónicos y abreviaturas Referencias Descripción del resto del documento 2. Descripción general Perspectiva del producto Funciones del producto Características de los usuarios Restricciones generales Suposiciones y dependencias 3. Requerimientos específicos: incluyen los requerimientos funcionales, no funcionales y de interfaz. Ésta es la parte más sustancial del documento. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el rendimiento del sistema, especificar los requerimientos lógicos de la base de datos, las restricciones de diseño, las propiedades emergentes del sistema y las características de calidad. Nota.‑ El equipo para esta exposición deberá mostrar y explicar el modelo de Documento de especificación de Requerimientos de software. Descargar Modelo (h ps://univertic.files.wordpress.com/2015/01/modelo‑de‑doc‑de‑req‑de‑software.doc)   3.‑ MÉTRICAS Y HERRAMIENTAS PARA LA INGENIERÍA DE REQUISITOS. https://univertic.wordpress.com/unidad­iii/

5/10

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez) 3.‑ MÉTRICAS Y HERRAMIENTAS PARA LA INGENIERÍA DE REQUISITOS.

30/3/2016

La ingeniería del software, necesita de métricas e indicadores para poder especificar, predecir, evaluar y analizar distintos atributos y características de los productos, procesos entre otros que participan en el desarrollo y mantenimiento del software. La aplicación de un enfoque cuantificable al desarrollo, operación y mantenimiento del software es una tarea compleja que requiere disciplina, estudio y conocimiento de las métricas e indicadores adecuados para los distintos objetivos de medición y evaluación, con el fin de garantizar calidad.                              METRICAS DE SOFTWARE En el campo de la ingeniería del software una métrica es cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u otra característica de un software o un sistema de información, generalmente para realizar comparativas o para la planificación de proyectos de desarrollo. Un ejemplo ampliamente usado es la llamada métrica de punto función. La métrica del punto función: es un método utilizado en ingeniería del software para medir el tamaño del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la implementación y mantenimiento. A veces en vez de hablar de métrica se usa el término “Indicadores” del software. Algunos ingenieros lo usan como sinónimos mientras que otros les atribuyen significados distintos. Algunas métricas o indicadores pueden ser: Índice de productividad = tamaño / esfuerzo = líneas de código generado / horas trabajadas Tasa de defectos = defectos / tamaño = número de errores / líneas de código generadas. Métricas de Proceso y Proyecto, Hay cuatro razones para medir: Caracterizar, Evaluar, Predecir y Mejorar. Medida: Valor asignado a un atributo de una entidad mediante una medición. Ejemplo: 35.000 líneas de código Medición: Es el acto de determinar una medida. Ejemplo: María será la encargada de medir las LDC de cada módulo del sistema. Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Incluye el método de medición. Ejemplo: La productividad de este proyecto fue de 500 líneas (LDC/persona‑mes) Indicador: Es una métrica o combinación de métricas que proporcionan una visión profunda del proceso de software. Ejemplo: La productividad media de nuestra empresa es de 500 (LDC/pm). 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 y el producto para intentar aumentar su calidad. https://univertic.wordpress.com/unidad­iii/ 6/10 La medición de software se clasifica en dos categorías.

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

La medición de software se clasifica en dos categorías. Medidas directas del proceso de software (Costo, esfuerzo) y del producto (Líneas de código producidas, rapidez de ejecución y efectos reportados.) Medidas indirectas del producto que incluyen funcionalidad, calidad, complejidad, eficiencia, confiabilidad, facilidad de mantenimiento, y muchas otras habilidades. TIPOS DE MÉTRICAS: Métricas orientadas al tamaño: Proceden de la normalización de las medidas de calidad o productividad considerando el tamaño del software que se ha producido Las métricas orientadas al tamaño se aceptan universalmente como la mejor forma de medir el tamaño del proceso. Métricas orientadas a la función: Se emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación. Métricas orientadas a objetos: No proporcionan suficiente granularidad para la planificación y los ajustes de esfuerzo. Métricas orientadas a casos de uso: El caso de uso se define en etapas tempranas del proceso de software, lo que permite emplearlo en la estimación antes de iniciar las actividades significativas de modelado construcción. Métricas de proyectos de ingeniería Web: El objetivo de los proyectos de ingeniería Web es construir una aplicación Web que proporcione una combinación de contenido y funcionalidad al usuario final. Entre las medidas que se recopilan existen las siguientes: Número de páginas web estáticas. Número de páginas web dinámicas. Número de vínculos internos de la página. Número de objetos de datos persistentes. Número de sistemas externos en interfaz. Número de objetos de contenido estático. Número de objetos de contenido dinámico. Número de funciones ejecutables. La meta primordial de la ingeniería del software es producir un sistema, aplicación o producto de alta calidad dentro de un marco temporal que satisfaga una necesidad del mercado. Medición de la calidad: Corrección Facilidad de mantenimiento Integridad

https://univertic.wordpress.com/unidad­iii/

7/10

30/3/2016

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez)

Integridad Facilidad de uso Métricas para organizaciones pequeñas: Un enfoque de sentido común respecto a la implementación de cualquier actividad relacionada con el proceso de software es mantenerlo simple, personalizado para satisfacer las necesidades locales y asegurarse de que valor agregar. Mantenerlo simple: consiste en enfocarse no sobre las mediciones sino más bien sobre los resultados. Entrevistar al grupo de software para definir un objetivo sencillo que requiere mejora. Una organización pequeña puede seleccionar el siguiente conjunto de medidas: Tiempo transcurrido desde el momento en que se hizo una solicitud hasta que la Esfuerzo para realizar la evaluación. Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de cambio del personal. Esfuerzo requerido para hacer el cambio. Tiempo requerido para hacer el cambio. Errores descubiertos durante el trabajo para hacer el cambio. Defectos descubiertos después de que el cambio es liberado a la base de clientes. LA ISO 9001 EN RELACIÓN AL SOFTWARE La ISO 9001: es una normativa de cumplimiento opcional para el aseguramiento de la calidad en las empresas. Esta norma trata de definir los procesos que se siguen dentro de la empresa para estandarizarlos y controlarlos. Es de carácter genérico. El cumplimiento de la norma ISO 9001 no garantiza que se esté controlando que la calidad del producto final sea buena. Simplemente garantiza que la empresa ha adoptado una organización definida y controlada. CMMI: son las siglas de un modelo utilizado en el ámbito de la informática para evaluar si una empresa mantiene ciertos niveles de calidad en relación al software. Una empresa que quiera acreditarse como cumplidora del modelo CMMI habrá de pasar una evaluación. Cuando se implanta un sistema de calidad como CMMI, se usan las métricas para comprobar que se producen cambios reales en el software que produce la empresa. METRICAS PARA ESTABLECER UN PUNTO DE VENTA Establecimiento de un programa de métricas de software: Está dirigido por metas según el SEI (SOFTWARE ENGINEERING INSTITUTE) y define los siguientes pasos: Identificar los objetivos de la empresa. Identificar lo que se quiere conocer o aprender. Identificar los sub objetivos Identificar las entidades y atributos relacionados con los objetivos secundarios. Formalizar los objetivos de la medición. Identificar preguntas cuantificables y los indicadores relacionados que se emplearan como apoyo para lograr los objetivos de sus mediciones. Identificar los elementos de datos que se recopilaran para construir los indicadores que https://univertic.wordpress.com/unidad­iii/ ayudaran a responder las preguntas.

8/10

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez) Identificar los elementos de datos que se recopilaran para construir los indicadores que ayudaran a responder las preguntas. Definir las medidas que se emplearan y hacer que estas definiciones sean operativas. Identificar las acciones que se tomaran para implementar las medidas. Prepara un plan para implementar las medidas.

30/3/2016

Al trabajar como equipo, la ingeniería del software y los gestores del negocio pueden confeccionar una lista de metas priorizadas del negocio. Mejorar la satisfacción de los clientes con los productos. Hacer que los productos sean más fáciles de usar. Reducir el tiempo que toma poner un producto en el mercado. Simplificar el soporte para los productos. Mejora la obtención global de utilidades. El personal de software desarrolla un conjunto de preguntas relacionadas con características cuantitativas por ejemplo, tamaño, costo, tiempo de desarrollo, estas preguntas se derivan de sub objetivos relacionadas con las entidades y actividades realizadas como parte del proceso del software. Para esto se puede derivar la siguiente lista de preguntas: ¿la solicitud del cambio del cliente contiene la información requerida para evaluar adecuadamente el cambio y luego implementarlo en una forma oportuna? ¿Cuán grande es el registro de petición de cambio? ¿El tiempo de respuesta para fijar los bugs es aceptable con base en as necesidades del cliente? ¿Se sigue el proceso de control de cambios? ¿Los cambios de alta prioridad se implementan en forma oportuna? En base a la pregunta se puede deducir el sub‑objetivo: Mejorará el desempeño del proceso de gestión de cambio. Se identifican entidades y atributos del proceso de software. Según el SEI en esencia se aplica un proceso de refinamiento paso a paso en el que los objetivos se refinan en preguntas que posteriormente se refinan en entidades y atributos que entonces se refinan en métricas. CONCLUSION Hemos dicho que las métricas servían en informática para hacer mediciones del software. Cuando se implanta un sistema se usan las métricas para comprobar que se producen cambios reales en el software que produce la empresa. Cuando el cliente nos da una especificación de requisitos del software (ERS) se procede a cuantificar el tamaño y complejidad de lo que nos piden para poder hacer un presupuesto. La técnica más utilizada para estimar el tamaño es la técnica del punto función, una técnica que trata de enumerar las consultas, datos, informes, etc. que van a ser necesarios para obtener el producto terminado. Las métricas nos permiten saber, el número o importancia de los errores que se detectan en los test o correspondientes a reclamaciones recibidas del cliente. Si en cada proyecto medimos el grado de error con el tiempo tendremos un histórico que nos irá diciendo si vamos mejorando o https://univertic.wordpress.com/unidad­iii/ no. También nos servirá para realizar predicciones sobre cómo el volumen de errores y tiempo de9/10

Unidad III | Ingeniería Informática (Prof. Osmar Mavárez) grado de error con el tiempo tendremos un histórico que nos irá diciendo si vamos mejorando o no. También nos servirá para realizar predicciones sobre cómo el volumen de errores y tiempo de corrección que será necesario en nuevos proyectos antes de la fase de pruebas del mismo.

30/3/2016

Blog de WordPress.com. El tema Enterprise.

https://univertic.wordpress.com/unidad­iii/

10/10