4. Crisis del software
Muchos desarrollos de software han concluido
insatisfactoriamente por motivos diversos
1995. CHAOS publica un estudio en donde los resultados de los
proyectos de software son demoledores, a pesar de las
herramientas existentes
Los tres principales factores de éxito de los proyectos software:
Implicación de los usuarios, Apoyo de los directivos, Enunciado
claro de los requisitos
Los tres principales factores de fracaso: Falta de información por
parte de los usuarios, Especificaciones y requisitos
incompletos, Especificaciones y requisitos cambiantes
10/03/2010 gplinvestigacionydesarrollo@gmail.com 4
5. Ingeniería del software. 1967
“Establecimiento y uso de principios sólidos de la
ingeniería para obtener económicamente un
software confiable y que funcione de modo
eficiente en máquinas reales” Fritz Bauer. 1969
1)Aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo,
operación y mantenimiento del software; es
decir, la aplicación de la ingeniería de software .
2) El estudio de enfoques como en 1). IEEE.
1993
10/03/2010 gplinvestigacionydesarrollo@gmail.com 5
6. La parte más difícil de construir de un
sistema software es decidir qué construir.
[...] Ninguna otra parte del trabajo afecta
más negativamente al sistema final si se
realiza de manera incorrecta. Ninguna
otra parte es más difícil de rectificar
después.“
[Brooks 1995]
10/03/2010 gplinvestigacionydesarrollo@gmail.com 6
8. Concepto
IEEE Standard Glossary of Software Engineering Terminology
(1990):
Una condición o capacidad necesaria por un usuario para
solucionar un problema o lograr un objetivo.
Una condición o capacidad que debe cumplir o poseer un sistema o
componente de un sistema para satisfacer un contrato, estándar,
especificación u otro documento formalmente impuesto.
Una representación documentada de una condición o capacidad
como en 1 o 2.
Una especificación de qué se debería implementar. Son
descripciones de cómo se debe comportar el sistema, o de un
atributo o propiedad del sistema. Puede ser una restricción en
el proceso de desarrollo de un sistema (Somerville y
Sawler,(1997)).
10/03/2010 gplinvestigacionydesarrollo@gmail.com 8
10. Dimensiones - Ámbito
A nivel del sistema: Hardware y Software
10/03/2010 gplinvestigacionydesarrollo@gmail.com 10
11. Dimensiones - Características
Funcionales: Comportamiento del sistema.
Tareas que el sistema debe realizar.
No Funcionales: Restringen la solución
De información: Establecen qué información
debe almacenar el sistema por ser relevante
para las necesidades y objetivos de clientes
y usuarios.
10/03/2010 gplinvestigacionydesarrollo@gmail.com 11
12. Dimensiones - Audiencia
Clientes y usuarios:Servicios y restricciones
expresadas como requisitos abstractos de
alto nivel, representadas mediante en
lenguaje natural o natural estructurado,
notación gráfica y otro medio
Desarrolladores: Especificación de requisitos
utilizando técnicas
10/03/2010 gplinvestigacionydesarrollo@gmail.com 12
13. Propiedades
Comprensible: Canal de comunicación
Correcto: Representa propiedad requerida
No ambiguo: Una sola interpretación
Completo: Todo lo que hace el sistema. Todas
las respuestas.
Consistente: No entra en conflicto con otro
documento
Verificable: proceso finito, medible
Modificable: Permitir cambios(fácil, completa y
consistente)
Rastreable: origen de futuros documentos
10/03/2010 gplinvestigacionydesarrollo@gmail.com 13
16. Concepto
“La IR puede ser definida como el proceso
sistemático de desarrollo de los requerimientos
a través de un proceso cooperativo e iterativo
del análisis del problema, documentando las
observaciones resultantes en una variedad de
representaciones y chequeando la certeza del
conocimiento ganado”. Pohl (1993)
“Ayuda a entender mejor el problema en cuya
solución trabajarán…..comprender cuál será el
impacto del sw sobre el negocio….” Pressman.
2006
10/03/2010 gplinvestigacionydesarrollo@gmail.com 16
18. … Proceso
Obtención: conocer y comprender las
necesidades y problemas del cliente
Análisis: Sintetizar información, priorizarla,
delimitar los límites del sistema, definir su
interacción con el entorno
Especificación: plasmarlas en forma de
requisitos en los documentos estableciendo
la guía desarrollo y los criterios de validación
del producto final
10/03/2010 gplinvestigacionydesarrollo@gmail.com 18
19. …Proceso
V&V: Los requisitos deben ser formal y
técnicamente correctos (verificación), y
satisfacer las necesidades del sistema, sin
omitir ninguna ni incluir funcionalidades
innecesarias (validación).
Gestión. Poder trazar en cada cambio todas
las partes afectadas, así como poder medir el
impacto que cada modificación implica en la
planificación del proyecto.
10/03/2010 gplinvestigacionydesarrollo@gmail.com 19
21. … Ámbito
Descripción del sistema. Documento dirigido
a los usuarios; describe las características
del sistema propuesto. IEEE Std. 1362-1998.
Requisitos del (SRS).
software.
Especificación de las funciones que
realiza un determinado producto de
software, programa o conjunto de
programas en un determinado entorno.
10/03/2010 gplinvestigacionydesarrollo@gmail.com 21
22. Modelos
Modelo de Pohl
10/03/2010 gplinvestigacionydesarrollo@gmail.com 22