INSPECCIÓN.
“Ingeniería de Software, un enfoque practico”
(1998): 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.
La calidad de los
productos de trabajo procedentes de la ingeniería de requisitos se evalúa
durante el proceso de validación. La validación de requisitos examina la
especificación, para asegurar que todos los requisitos de software se han
establecido de manera precisa, que se han detectado las inconsistencias,
omisiones y errores y que estos han sido
corregidos, y que los productos de trabajo cumplen con los estándares
establecidos para el proceso, proyecto y producto.
COMPLETITUD.
Es cuando La
funcionalidad del sistema satisface todos los requisitos, es decir se hizo lo
que el cliente pidió”.
La Completitud:
·
Significa que no hay
omisiones que comprometan la integridad de los requisitos o No faltan requisitos (propiedad global).
·
No faltan detalles en la
especificación de cada requisito (propiedad individual).
·
Es una propiedad difícil de
determinar (tan sólo podemos alcanzar una aproximación).
·
Contrastar con el cliente o
Comparar con proyectos semejantes.
·
Buscar la visión de
conjunto, detectar huecos o partes infra-especificadas.
·
Una manera de comprobarlo:
para cada requisito, comprobar que están presentes los demás requisitos
relacionados.
·
La buena organización
facilita la detección de faltas o
Ejemplo: organización por tipos de requisitos.
DETECCIÓN
DE CONFLICTOS E INCONSISTENCIA DE REQUERIMIENTOS.
Una vez recopilados
los requisitos, el producto obtenido configura la base del análisis de
requisitos. Los requisitos se agrupan por categorías y se organizan en
subconjuntos, se estudia cada requisito en relación con el resto, se examinan
los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en
base a las necesidades de los clientes/usuarios. Es corriente en clientes y
usuarios solicitar más de lo que puede realizarse, consumiendo recursos de
negocios limitados. También es relativamente común en clientes y usuarios el
proponer requisitos contradictorios, argumentando que se versión es “esencial
por necesidades especiales”.
El ingeniero del
sistema debe resolver estos conflictos a través de un proceso de negociación.
Los clientes, usuarios y el resto de intervinientes deberán clasificar sus
requisitos y discutir los posibles conflictos según su prioridad. Los riesgos
asociados con cada requisito serán identificados y analizados. Se efectúan
estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto
de cada requisito en el costo del proyecto y en el plazo de entrega. Utilizando
un procedimiento iterativo, se irán eliminando requisitos, se irán combinando
y/o modificando para conseguir satisfacer los objetivos planteados.
DOCUMENTOS
DE REQUERIMIENTOS DE SOFTWARE: CREACION,
USOS E IMPORTANCIA.
El documento de
requerimientos del software (algunas veces denominado especificación de
requerimientos del software o SRS) es la declaración oficial de que deben
implementar los desarrolladores del sistema. Debe incluir tanto los
requerimientos del usuario para el sistema como una especificación detallada de
los requerimientos del sistema. En algunos casos, los dos tipos de
requerimientos se pueden integrar en una única descripción. En otros, los
requerimientos del usuario se definen en una introducción a la especificación
de los requerimientos del sistema. Si existe un gran numero de requerimientos,
los detalles de los requerimientos del sistema se pueden presentar en un
documento separado.
El documento de requerimientos tiene un
conjunto diverso de usuarios que va desde los altos cargos de la organización
que pagan por el sistema, hasta los ingenieros responsables de desarrollar el
software. La diversidad de posibles usuarios significa que el documento de
requerimientos tiene que presentar un equilibrio entre la comunicación de los
requerimientos a los clientes, la definición de los requerimientos en el
detalle exacto para los desarrolladores y probadores, y la inclusión de
información sobre la posible evolución del sistema. La información sobre
cambios previstos puede ayudar a los diseñadores del sistema a evitar decisiones de diseño restrictivas y
a los ingenieros encargados del mantenimiento del sistema, quienes tienen que
adaptar el sistema a los nuevos requerimientos.
El nivel de detalle
que debe incluir en documentos de requerimientos depende del tipo de sistema
que de desarrolle y del proceso de desarrollo utilizado. Cuando el sistema se
desarrolle por un contratista externo, las especificaciones de los sistemas
críticos necesitan ser claras y muy detalladas. Cuando haya mas flexibilidad en
los requerimientos y cuando se utilice un proceso de desarrollo iterativo
dentro de la empresa, el documento de requerimientos puede ser mucho menos
detallado y cualquier ambigüedad resuelta durante el desarrollo del sistema.
Comienzo
del Proyecto de Software: Antes de empezar a
planificar un proyecto el desarrollador y el cliente deben ponerse de acuerdo
para definir el ámbito y los objetivos del proyecto. Los objetivos identifican
los fines globales del proyecto sin considerar como se llegara a ellos. El
ámbito identifica las funciones primordiales del Software y más importante aún,
intenta limitar esas funciones de manera cuantitativa.
Medición
y métricas: Las mediciones y las métricas nos
ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un
producto, como el propio producto.
Estimación:
La Planificación es una de las actividades
del proceso de Gestión de Proyectos de Software. Cuando se planifica un
proyecto de Software se tiene que obtener estimaciones: del esfuerzo humano
requerido (personas-mes), de la duración
cronológica del proyecto (en fechas) y del costo.
Análisis de Riesgos: El
análisis de riesgo es algo vital para una buena gestión del proyecto de software y, sin embargo, a pesar
de todo, se emprenden muchos proyectos sin que se hayan considerado los riesgos
concretos. El análisis de riesgo
consiste realmente en una serie de pasos de control de los riesgos tales como:
·
Identificación de riesgos.
·
Solución de riesgos.
·
Supervisión de riesgos,
entre otros.
·
Planificación Temporal.
·
Seguimiento
y Control: Si una tarea se sale de la agenda el gestor
puede utilizar una herramienta de planificación automática sobre el proyecto
para determinar el impacto del error de planificación sobre los hitos
intermedios y sobre la fecha final de entrega. De manera que se pueden
reasignar los recursos, reordenar las tareas o (como último recurso) modificar
los compromisos de entrega para resolver el problema no detectado. De este modo
se puede controlar mejor el desarrollo del software.
Integrantes:
Ascanio , Maryeling.
Chouza, Jose.
Prado, Williana.
Torrealba, Anadilis.
Zambrano, Jhoskary.
entra al link
ResponderEliminarhttp://MyMoneyHour.com/?userid=140998