República Bolivariana De Venezuela

Ministerio Del Poder Popular Para La Educación Universitaria

Universidad Politécnica Territorial Estado Bolívar
PNF-Informática

Profesor: T.S.U:
Hermes Marcano José Celis
C.I. 25.036.783

Ciudad Bolívar, Abril de 2019

 Inspección, Validación, Completitud, Detección de Conflictos e
Inconsistencias de Requerimientos.

Inspección: La inspección también es conocida como revisión técnica formal, y

es el punto de vista más efectivo desde el punto de vista de aseguramiento de
calidad, y es dirigida por los ingenieros de software u otras personas. Para los
ingenieros la inspección es un medio efectivo para descubrir errores y mejorar
la calidad del software”. Las inspecciones 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.

Validación: Preferiblemente deben expresarse de manera cuantitativa, usando

métricas que faciliten su verificación y validación. Los requerimientos deben
estar escritos de forma que pueden ser objetivamente verificados: El problema
con estos requerimientos es el uso de términos “vagos” tales como “los errores
deben ser minimizados”. Los promedios de errores deben de estar
cuantificados.

Completitud: Todo lo que el software tiene que hacer está recogido en el

conjunto de requerimientos, es decir, deben describir toda la funcionalidad que
el sistema deberá implementar.

Detección de Conflictos: Es importante proveer racionalidad en los

requerimientos, ya que esto ayuda al desarrollador a entender el dominio de la
aplicación y el por qué los requerimientos se encuentran en su forma actual.
Esto es importante para el momento en que los requerimientos tienen que ser
cambiados. La disponibilidad de una racionalidad reduce el riesgo de tener
efectos inesperados.

Inconsistencia: Cada requerimiento debe tener una sola interpretación.

Debiendo poder expresarse de una manera sencilla, clara y sin ambigüedades
usando: - Lenguaje natural (español). - Lenguajes gráficos (UML) - Lenguajes
formales (Notación Z).
Tipos de Especificación: Textual, Notación gráfica y Lenguajes de
Representación (Lenguaje Unificado de Modelado UML y Notación
de Requerimientos de Usuario URN).

 Textual
Textual Tradicionalmente la especificación de requisitos se ha realizado
usando sobre todo especificaciones textuales en lenguaje natural. Las
herramientas de apoyo a la gestión de requisitos se han enfocado a la
manipulación de trozos de texto. Estos requisitos expresados textualmente se
enlazan formando un grafo de trazabilidad el cual se usa para gestionar los
requisitos y su trazabilidad. En este enfoque, las especificaciones generadas
en las otras actividades del desarrollo de software pueden también ser
añadidas al grafo de trazabilidad representándolas como texto.

Notación Grafica y Lenguajes de Representación (Lenguaje

Unificado de Modelado UML, Notación de Requerimiento de
Usuario URN).

 Notación gráfica: Incluye todas las notaciones que pueden demostrar el

flujo de información entre requisitos, apoyándose en diversas imágenes.
Estas notaciones permiten al usuario del sistema tener mayor comprensión
del software lo que hace y como lo hace. La más utilizada actualmente es el
Lenguaje Unificado de modelado (UML).

 UML: Es un lenguaje para la especificación, visualización, construcción y

documentación de los artefactos de un proceso de sistema intensivo. UML,
emergió en los '90 luego de la búsqueda de un lenguaje de modelamiento
que unificara a la industria. A pesar de que UML evolucionó de varios
métodos orientados al objeto de segunda generación (en nivel de notación),
su alcance extiende su uso más allá de sus predecesores. Es usado para la
comunicación. Es decir, un medio para capturar el conocimiento
(semánticas) respecto a un tema y expresar el conocimiento (sintaxis)
resguardando el tema propósito de la comunicación. Como un lenguaje
 para modelamiento, se enfoca en la comprensión de un tema a través de la
formulación de un modelo del tema (y su contexto respectivo). Cuidando la
unificación, integra las mejores prácticas de la ingeniería de la industria
tecnológica y sistemas de información pasando por todos Los tipos de
sistemas (software y no - software), dominios (negocios versus software) y
los procesos de ciclo de vida.

UML: es en cuanto a cómo se aplica para especificar sistemas, puede ser

usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema
puede ser realizado. En cuanto a cómo se aplica para visualizar sistemas,
puede ser usado para describir visualmente un sistema antes de ser realizado.
En cuanto a cómo se aplica para construir sistemas, puede ser usado para
guiar la realización de un sistema similar a los "planos”. En cuanto a cómo se
aplica para documentar sistemas, puede ser usado para capturar conocimiento
respecto a un sistema a lo largo de todo el proceso de su ciclo de vida.

UML: no es Un lenguaje de programación visual, sino un lenguaje de

modelamiento visual Una herramienta o depósito de especificación, sino un
lenguaje para modelamiento de especificación. Un proceso, sino que habilita
procesos.

Otra notación que se puede usar es la notación de requerimientos de

usuario (URN).

Técnicas para escribir requerimientos de alta calidad.

En todas las técnicas involucradas descritas en la unidad I de la ingeniería de

requerimientos, las actividades y características resaltantes para obtener o
escribir requerimientos de alta calidad son los siguientes.

• Identificar las clases de usuario del producto esperado.

• Extraer las necesidades de los individuos que representan cada clase de

usuario.
• Comprender las tareas y metas del usuario y los objetivos de negocio con los
que esas tareas se alinean.

• Analizar la información recibida de los usuarios para distinguir sus objetivos

de tarea de requerimientos funcionales, requerimientos no-funcionales, reglas
de negocio, y otros

• Destinar partes de los requerimientos de alto nivel a definir componentes de

software en la arquitectura sistema.

• Comprender la importancia de los atributos de calidad.

• Negociar las prioridades de implementación.

• Traducir las necesidades de usuario escritas dentro de las especificaciones y

modelos de requerimientos

• Examinar los requerimientos documentados para asegurar el conocimiento

común de los requerimientos presentados por los usuarios y corregir cualquier
problema antes de que el grupo de desarrolladores los acepte.

• Definir el punto de partida de los requerimientos.

• Revisar y evaluar el impacto de cada requerimiento cambiado antes de

aprobarlo.

• Seguir cada requerimiento en su diseño, código fuente y pruebas.

• Agrupar los requerimientos según rendimiento y actividad de cambio durante

todo el proyecto.

• La iteración es una clave para el éxito del desarrollo de los requerimientos.

Documento de Requisitos (DRS).

El resultado del proceso de definición de requerimientos es un Documento de

Requerimientos elaborado por el usuario, que servirá como base para el
análisis y diseño del sistema de información. Para la elaboración del
documento se presenta a continuaciones definiciones, pasos y características
propias de un requerimiento.

Usos:

Comunicar de manera precisa los requerimientos, objetivos y presunciones del

dominio.

Contrato – legal, documento interno o a modo de memorando.

Base para estimación (tamaño, costo, tiempo) y planificación de proyecto.

Base para evaluación de producto final – verificación y validación – Debería

tener suficiente información para decidir si el producto final es aceptable
(satisface los requerimientos).

Base para el control de cambios – Requerimientos cambian, software

evoluciona, el entorno evoluciona.

Importancia: En este documento de especificación de requisitos se plasma lo

que el sistema es esencia, y su importancia radica en evitar el malentendido de
determinadas situaciones, ya que el cliente participa activamente en la
elaboración del documento. Basándose en estos requisitos, el ingeniero de
software procederá al modelado de la futura aplicación. Este documento es de
mucha utilidad en el futuro ya que permite a los usuarios aprender el
funcionamiento del sistema en un nivel básico.
Métricas Modelo de Análisis

MÉTRICAS
La medición es esencial para cualquier disciplina de ingeniería y la ingeniería
de sistemas no es una excepción. Las métricas de sistemas se refieren a un
amplio rango de medidas para el sistema de computadoras dentro del contexto
de la planificación del proyecto de sistemas, las métricas de calidad pueden ser
aplicadas a organizaciones, procesos y productos los cuales directamente
afectan a la estimación de costos. En este existen métricas que podemos
utilizar para evaluar lo que estamos haciendo en ingeniería de sistema.

Criterios-Atributos que debe tener toda métrica para poder ser aceptable.

Métricas para:
Análisis
Diseño
Codificación
Prueba de Proyecto orientadas a (tamaño y funcionalidad)
Atributos de una Métrica

La métrica tiene varios atributos importantes en lo que cabe mencionar:

A. Simple y calculable Persuasiva.
B. Consistente y Objetiva
C. Consistente en sus unidades
D. Independiente del lenguaje Eficaz.

MÉTRICAS PARA ANÁLISIS

En esta fase es deseable que las métricas-técnicas proporcionen una visión

interna a la calidad del modelo de análisis. Estas métricas examinan el modelo
de análisis con la intención de predecir el “tamaño” del sistema resultante; es
probable que el tamaño y la complejidad del diseño estén directamente
relacionados.