unidad 3 ing software2

8/18/2019 Unidad 3 Ing Software2

1/10

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

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

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

agina 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 softwareImpacto de los defectos del software en el costoEl 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 producirsoftware de alta calidad. La garantía de la calidad del software es una actividad de protección qu

se aplica a lo largo de todo el proceso de ingeniería de software. Es un grave error considerar quela calidad del software es algo en lo que solo deben preocuparse una vez que se ha generado elcódigo.

La SQA (Software Quality Assurance) engloba:

Un enfoque de gestión de calidadTecnología de Ingeniería de Software efectiva (métodos y herramientas)Revisiones técnicas formales que se aplican durante el proceso delsoftware

https://univertic.wordpress.com/https://univertic.wordpress.com/


2/10


https://univertic.wordpress.com/unidad-iii/ 2

Una estrategia de prueba multiescaladaUn control de la documentación del software y de los cambios realizadosUn procedimiento que asegure un ajuste a los estándares de desarrollo desoftwareMecanismos 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 deinformación de la gestión. El objetivo de la garantía de la calidad es proporcionar la gestión parainformar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo unavisión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Es desperar, que si los datos proporcionados mediante la garantía de la calidad identifican problemala 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 SQAque 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 revisionesformales 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 asser eliminados. Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad derevisiones:

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 gentees buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan másfácilmente al que los origina que a otras personas. El proceso de revisión es, por lo tanto larespuesta 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 equipo2. 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 yCompletitud principalmente.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de laingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o enun café es una forma de revisión, si se discuten problemas técnicos. Una presentación formal deun diseño de software a una audiencia de clientes, ejecutivos y personal técnico es una forma derevisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, quellamaremos Inspección de Software


3/10



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 losusuarios finales.

El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores duranteel 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 sepropaguen al paso siguiente del proceso de desarrollo del software (catarata de errores deMizuno).

Una serie de estudios (TRW, Nippon Electric y Mitre Corp., entre otros) indican que lasactividades del diseño introducen entre el 50% y 65% de todos los errores(y en último lugar, todolos defectos) durante el proceso de software. Si embargo se ha demostrado que las inspecciones dsoftware 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ónreduce substancialmente el costo de los pasos siguientes en las fases de desarrollo ymantenimiento.

Para ilustrar el impacto sobre el costo de la detección anticipada de errores, consideremos unaserie de costos (hp://www.monografias.com/trabajos4/costos/costos.shtml) relativos que se basaen datos de costos realmente recogidos en grandes proyectos(hp://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 enproceso. 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 detrabajo”” representa 200 a 250 líneas de código, Requerimientos, diseño y otros productos detrabajo son inspeccionados en un tamaño similar. Los productos de trabajo son considerados enprogreso 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 ungrupo de inspección y se designa un moderador. El moderador asegura que el “”producto detrabajo”” satisfaga el criterio de inspección. Se le asignan diferentes roles a las personas queintegran 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 vistageneral es necesaria en éste momento. Este es un paso opcional, pero no menos importante ya

http://www.monografias.com/trabajos12/pmbok/pmbok.shtmlhttp://www.monografias.com/trabajos4/costos/costos.shtml


4/10



que en esta etapa se dará al grupo de inspección un “background” y el contexto a cubrir porlas 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 lautilización de listas de chequeos para ayudar a encontrar defectos comunes, y . El tiempo quepueda llevar esta etapa va a depender de cuan familiarizado esté el inspector con el trabajo qudebe analizar.

4. Examen: En esta etapa, los inspectores se reunen para analizar su trabajo individual en formaconjunta. El moderador deberá asegurarse que todos los inspectores están suficientementepreparados. La persona designada como lector presenta el “producto de trabajo”,interpretando o parafraseando el texto, mientras que cada participante observa en busca dedefectos. 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 grupodetermina 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á satisfech

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 dela inspección y con qué roles, productos de trabajo a inspeccionar y cual deberá ser el resultado dlas reuniones de inspección.

Objetivos: El principal objetivo es encontrar defectos en el “producto de trabajo”, de estamanera debemos definir cuáles serán las metas a alcanzar para el cumplimiento de ésteobjetivo. En nuestra opinión el establecimiento de éstas metas están en relación directa con eltipo 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 ydeberá contar con mayor experiencia que el resto, el lector quien presenta los productos detrabajo en las reuniones y el escriba quien documenta la descripción y ubicación de losdefectos encontrados.Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes tipos deproductos de trabajo que pueden encontrarse en un desarrollo de software incluyendorequerimientos, 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ñode 10 a 20 hojas para especificación de requerimientos, 200 o 250 líneas de código. En nuestraopinión también se debe tener en cuenta la división natural que pueda tener cada uno de éstodocumentos, ya que toda especificación podremos dividirla en partes así como el diseño o elcódigo.Resultado de las reuniones de inspección: Los dos resultados principales debe ser: Una lista ddefectos 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.


5/10



2.‑ DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE: CREACIÓN, USOS EIMPORTANCIA2.1. ¿Qué es un documento de requerimientos?

El documento de requerimientos es la declaración oficial de qué es lo que deben implementar losdesarrolladores de software. Debe incluir tanto los requerimientos a nivel de usuario para elsistema, 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 losrequerimientos del sistema. Se deben organizar de tal forma que puedan ser utilizados tanto porlos clientes del sistema como por los desarrolladores del software. Los requerimientos para unsistema software determinan lo que debe hacer el sistema y definen las restricciones en sufuncionamiento.

¿Cuáles son los elementos de un documento de requerimientos?

1. IntroducciónPropósito del documento de requerimientosAlcance del productoDefiniciones, acrónicos y abreviaturasReferenciasDescripción del resto del documento

2. Descripción generalPerspectiva del productoFunciones del productoCaracterísticas de los usuariosRestricciones generalesSuposiciones y dependencias

3. Requerimientos específicos: incluyen los requerimientos funcionales, no funcionales y deinterfaz. Ésta es la parte más sustancial del documento. Los requerimientos puedendocumentar 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 deespecificación de Requerimientos de software. Descargar Modelo(hps://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.files.wordpress.com/2015/01/modelo-de-doc-de-req-de-software.doc


6/10



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 queparticipan en el desarrollo y mantenimiento del software.

La aplicación de un enfoque cuantificable al desarrollo, operación y mantenimiento del softwarees una tarea compleja que requiere disciplina, estudio y conocimiento de las métricas eindicadores adecuados para los distintos objetivos de medición y evaluación, con el fin degarantizar calidad.

METRICAS DE SOFTWARE

En el campo de la ingeniería del software una métrica es cualquier medida o conjunto de medidadestinadas a conocer o estimar el tamaño u otra característica de un software o un sistema deinformación, generalmente para realizar comparativas o para la planificación de proyectos dedesarrollo. 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 lafuncionalidad entregada al usuario independientemente de la tecnología utilizada para laconstrucción y explotación del software, y también ser útil en cualquiera de las fases de vida delsoftware, 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. Algunosingenieros 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 trabajadasTasa 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 yMejorar.

Medida: Valor asignado a un atributo de una entidad mediante una medición. Ejemplo: 35.00líneas de códigoMedición: Es el acto de determinar una medida. Ejemplo: María será la encargada de medir laLDC de cada módulo del sistema.

Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee unatributo dado. Incluye el método de medición. Ejemplo: La productividad de este proyecto fude 500 líneas (LDC/persona‑mes)Indicador: Es una métrica o combinación de métricas que proporcionan una visión profundadel 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 unproducto, como el propio producto. El proceso para intentar mejorarlo y el producto para intentaaumentar su calidad.


7/10



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ódigoproducidas, rapidez de ejecución y efectos reportados.)Medidas indirectas del producto que incluyen funcionalidad, calidad, complejidad, eficienciaconfiabilidad, 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 eltamaño del software que se ha producidoLas métricas orientadas al tamaño se aceptan universalmente como la mejor forma de medir etamaño del proceso.

Métricas orientadas a la función: Se emplean como un valor de normalización una medida de lafuncionalidad que entrega la aplicación.

Métricas orientadas a objetos: No proporcionan suficiente granularidad para la planificación y loajustes de esfuerzo.

Métricas orientadas a casos de uso: El caso de uso se define en etapas tempranas del proceso desoftware, lo que permite emplearlo en la estimación antes de iniciar las actividades significativasde modelado construcción.

Métricas de proyectos de ingeniería Web: El objetivo de los proyectos de ingeniería Web esconstruir 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 dalta calidad dentro de un marco temporal que satisfaga una necesidad del mercado.

Medición de la calidad:

CorrecciónFacilidad de mantenimiento


8/10


9/10



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.

Al trabajar como equipo, la ingeniería del software y los gestores del negocio pueden confeccionuna 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ísticascuantitativas por ejemplo, tamaño, costo, tiempo de desarrollo, estas preguntas se derivan de subobjetivos 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 clientecontiene la información requerida para evaluar adecuadamente el cambio y luego implementarloen una forma oportuna? ¿Cuán grande es el registro de petición de cambio? ¿El tiempo derespuesta para fijar los bugs es aceptable con base en as necesidades del cliente? ¿Se sigue elproceso de control de cambios? ¿Los cambios de alta prioridad se implementan en formaoportuna?

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 srefinan en preguntas que posteriormente se refinan en entidades y atributos que entonces serefinan en métricas.

CONCLUSION

Hemos dicho que las métricas servían en informática para hacer mediciones del software. Cuand

se implanta un sistema se usan las métricas para comprobar que se producen cambios reales en esoftware que produce la empresa. Cuando el cliente nos da una especificación de requisitos delsoftware (ERS) se procede a cuantificar el tamaño y complejidad de lo que nos piden para poderhacer un presupuesto. La técnica más utilizada para estimar el tamaño es la técnica del puntofunción, una técnica que trata de enumerar las consultas, datos, informes, etc. que van a sernecesarios para obtener el producto terminado.

Las métricas nos permiten saber, el número o importancia de los errores que se detectan en lostest o correspondientes a reclamaciones recibidas del cliente. Si en cada proyecto medimos elgrado de error con el tiempo tendremos un histórico que nos irá diciendo si vamos mejorando o


10/10


htt // i ti d / id d iii/ 10

no. También nos servirá para realizar predicciones sobre cómo el volumen de errores y tiempo decorrección que será necesario en nuevos proyectos antes de la fase de pruebas del mismo.

Blog de WordPress.com.

El tema Enterpris
https://wordpress.com/themes/enterprise/https://es.wordpress.com/?ref=footer_blog

unidad 3 ing software2

Documents