Apuntes para todos los estudiantes y cursos

La especificación de los requisitos del software se produce

Cascada:Definir requisitos, diseño sistema, implementación, integración y pruebas, funcionamiento y mantenimiento)

Desarrollo evolutivo se basa en la implementación de un sistema inicial, exponerla a los comentarios de los usuarios y depurarla, bucle(especificación, desarrollo, validación) hasta el sistema deseado.

Modelo de entrega incremental: modelo intermedio,mix Cascada y evolutivo

Las etapas principales de especificación de software son:
– Estudio de viabilidad
– Obtención y análisis de requisitos.
– Especificación de requisitos.
– Validación de requisitos.

Validación de software



– Prueba de componentes
– Prueba del sistema
– Prueba de aceptación

Crisis del software


la dificultad que existía para dev programas, que además de funcionar correctamente, fueran comprensibles, verificables, adaptables y menos costosos. Los principales problemas eran:
– No terminaban en la fecha establecida.
– Superaban de manera sustancial el presupuesto inicial.
– No se cumplían con las especificaciones establecidas.
– Se desarrollaba código de baja calidad.

Requisitos deben de ser:


Comprensibles, Necesario, No ambiguo, Completo, Consistente, Verificable, Realizable, Modificable, Rastreable, Priorizable

RF


Describen con detalle los servicios y funcione que un sistema debe hacer. Como debe reaccionar ante una entrada particular y como debe comportarse ante situaciones particulares, excepcionales,…

RNF


Describen las restricciones que afectan a los servicios o funcionalidades del sistema. Son restricciones sobre los RF. Pueden ser del tipo:
– Producto: especifican o restringen el comportamiento del producto obtenido, ejemplo: memoria requerida o velocidad de ejecución.(usabilidad,fiabilidad,eficiencia[rendimiento,espacio],portabilidad)
– Organizacionales: pueden ser procesos estándar utilizados, fechas de entrega, documentación a entrega.(entrega,implementación,estándares)
– Externos: describen factores externos al sistema, ejemplo: LOPD. (Inteoperabilidad,ético,legislativos[privacidad,seguridad])

RDom


Provienen del dominio de aplicación del sistema, reflejando las carácterísticas y restricciones de ese dominio. Pueden ser RF o RNF. Ejemplo: Debido a las restricciones de la licencia CEDRO, algunos documentos solo podrán ser visualizados online.

SRS



Software

Requirements Specifications. Debe incluir todo lo que los desarrolladores del software deben implementar, es decir, una descripción general de las funcionalidades, necesidades y restricciones del software a desarrollar. Debe de incluir tanto los requisitos de usuario como los del sistema.

Elicitación


Hasta las últimas décadas la elicitación de requisitos no era considerada como parte de un proyecto de desarrollo de software ya que se asumía que los clientes debían proporcionar los requisitos por lo que estas tareas, de elicitación y validación, no se consideraban necesarias. A partir de la “crisis del software”  fue cuando se empezaron a considerar importantes estas tareas. Esta actividad es donde se capturan y obtienen los requisitos. Los participantes o stakeholders son aquellas personas que se verán afectadas por el software que se va a desarrollar. La elicitación y análisis de requisitos se puede estructurar en cuatro puntos:
– Descubrimiento de requisitos.
– Clasificación y organización de requisitos.
– Ordenación por prioridades y negociación de requisitos.
– Documentación de requisitos
Técnicas de elicitación:
– Entrevistas individuales/grupales
– Cuestionarios
– Escenarios
– Casos de uso
– Brainstorming
– Reutilización de requisitos.
– Prototipos.
– Revisión de documentación técnica.
– Ingeniería inversa
– Talleres de discusión.

Entrevistas


cerradas/abiertas. Comprender las necesidades del software. Fase preparación/realización/análisis.

Brainstorming


participantes experiencia en diferentes disciplinas para ideas creativas. No juzgar ideas. No se descarta ninguna. Fase Preparación, Generación, Consolidación, Documentación.

Casos de uso


Se basa en escenarios para obtener los RF de un software. Un caso de uso es un escenario que representa la interacción entre los actores y el software. Un actor caracteriza las interacciones que los usuarios pueden tener con el sistema y puede participar en uno o más casos de uso al igual que un caso de uso puede estar relacionado con uno o varios actores.

Prototipos


  dev representativo y a pequeña escala de las necesidades del usuario simulando el  software a desarrollar. Fases: Captura de requisitos;Definición de objetivos del software e identificación de requisitos por parte de desarrolladores y clientes;Diseño rápido del software, centrándose en los elementos que interactuarán con el usuario (entradas y salidas);Construcción del prototipo.

JAD


técnica de trabajo grupal en la que se involucra a todos los stakeholders para realizar un desarrollo preliminar del software a desarrollar. Tipos de participantes: Jefe del JAD, analista, Patrocinador ejecutivo, Representantes de los usuarios, Representantes de los sistemas, Especialista.

Ingeniería inversa


Es una técnica que se utiliza para obtener información de un software ya existente con la finalidad de entender como funciona, y así, poder modificarlo, mejorarlo, evolucionarlo y rediseñarlo.

Validación de requisitos


Es la actividad en la que se verifica que todos los requisitos obtenidos, descritos y documentados en los pasos anteriores son válido. Durante esta validación debemos controlar que estos requisitos son: válidos, consistentes, completos, reales, verificables, comprensibles, trazables, adaptables

No se permite realizar comentarios.