1er. conferenciaa octubre 2014

La Influencia de los

Requisitos en el

desarrollo de un

Proyecto exitoso

Octubre 2014

Tabla de Contenido

1. Introducción

2. La Realidad de los proyectos de software en cifras

3. Explicaciones a las cifras

4. Calidad y modelos de calidad en los requisitos

5. Requisitos de Sw : Propiedades y Atributos

6. El rol de la especificación de los requisitos

7. Actividades que aseguran la calidad de los requisitos

Conclusiones

Proyecto Exitoso?

Tiempo Alcance

Recursos ( $$$, Gente)

Calidad

¿Qué tan exitosos son los proyectos de SW?

Fuente :Chaos Report (Standish Group Report)

En la ultima decada

➔ Del 18% al 24% de los proyectos son cancelados antes de

terminarlos

➔Del 44% al 53% de los proyectos cuestan cerca del 189% del

presupuesto inicial

Primera Jornada de Conferencias en Gestión de Proyectos CIP NACIONAL

Octubre 2014


tres

doce

53%

16

%

cinco)

AÑO 1994


El 70% de lo proyectos de TI no alcanzan las metas de plazos, costos y calidad

(Fuente : Gartner)

El 50% de los proyectos de TI exceden su presupuesto : Gartner)

En general, el 66% de los proyectos de TI fracasan, el 52% se cancela, el 82% se entrega

fuera del plazo (Fuente CHAOS)

Menos del 40% alcanza sus objetivos comerciales un año después (Fuente KPMG)


Octubre 2014


Tabla de Contenido

1. Introducción





6. El rol de la especificacion de los requisitos


Conclusiones

Bibliografía

Calidad

2.1 Problemas en la capa de Gestión

El 70% de lo proyectos de TI no alcanzan las metas de plazos, costos y calidad

(Fuente : Gartner)

El 50% de los proyectos de TI exceden su presupuesto : Gartner)

En general, el 66% de los proyectos de TI fracasan, el 52% se cancela, el 82% se entrega

fuera del plazo (Fuente CHAOS)

Menos del 40% alcanza sus objetivos comerciales un año después (Fuente KPMG)


Octubre 2014

21 % de cambios en los objetivos definidos

31% de no utilización, o mala utilización de

metodologías de trabajo

48 % Problemas humanos, de conducción,

comunicación y conflictos entre la gente

2.1 Problemas en la capa de Gestión

Problemas de ámbito.

Problemas de comprensión.

Problemas de

volatilidad.

•Limite mal definido.

•Detalles tecnicos

innecesarios. •Ellos no estan seguros.

•No comprenden al 100% el

dominio del problema.

•Dificultad para comunicar

necesidades.•Problemas cambian

•Conforme pasa el tiempo.

2.2 Problemas en la capa Técnica

Algunos datos interesantes…

Requirements Errors(82%)

Requirements Requirements

ErrorsErrors

(82%)(82%)

Design Errors(13%)

Design ErrorsDesign Errors

(13%)(13%)

Coding Errors (1%)Coding Errors (1%)Coding Errors (1%)Other Errors (4%)Other Errors (4%)Other Errors (4%)

Requirements Errors(82%)

Requirements Requirements

ErrorsErrors

(82%)(82%)

Design Errors(13%)

Design ErrorsDesign Errors

(13%)(13%)

Coding Errors (1%)Coding Errors (1%)Coding Errors (1%)Other Errors (4%)Other Errors (4%)Other Errors (4%)Other Errors (4%)Other Errors (4%)Other Errors (4%)

Esfuerzo dedicado a corregir los defectos

Fuentes: James Martin, Barry Boehm

0 5 10 15 20 25

200

180

160

140

120

100

80

60

40

20

0

% O

ve

rcost

% Requirements Management Cost compared to total project cost

0- 5% invested in Req.

Management results in 80-200%

overcost8-14% invested in Req.


overcost

Project Analyzed

0 5 10 15 20 25

200

180

160

140

120

100

80

60

40

20

0

% O

ve

rcost

% Requirements Management Cost compared to total project cost

0- 5% invested in Req.


overcost8-14% invested in Req.


overcost

Project Analyzed

La importancia de los Requisitos


Octubre 2014

La realidad de los proyectos software

Como lo diseño el analista

Tabla de Contenido

1. Introducción







Conclusiones

Bibliografía


Octubre 2014

¿ Por qué fallan los Proyectos de SW?


Octubre 2014

Explicaciones


Octubre 2014

No entendí los requisitos


Octubre 2014

Ademas de ….

No controlar los recursos porque :


Octubre 2014

Y ahora que ?

EL PROBLEMA

ES ENTENDER EL

PROBLEMA

CUAL ES EL PROBLEMA ?

La Baja calidad de los requisitos

Los cuales menudo son ambiguos, confusos,

incompletos o contradictorios, conducirá a

altos índices de fracaso en este tipo de

proyectos

Falta de entendimiento de los requisitos

Si las necesidades no son entendidas el

sistema no podrá cumplirlas y el objetivo de

cualquier proyecto de desarrollo de software

es dar respuesta a las necesidades de

negocio.


Octubre 2014

LOS PROYECTOS DE CALIDAD

SE INICIAN CON REQUISITOS

DE CALIDAD

Tabla de Contenido

1. Introducción



4. Calidad y Modelos de calidad para los requisitos




Conclusiones

Bibliografía


Octubre 2014

Que es Calidad?


Octubre 2014

Calidad


Octubre 2014

ISO 9001- 2008

Basado en la ISO 9000


Octubre 2014

CMMI Dev


Octubre 2014

Areas de procesos CMMI Dev


Octubre 2014

PMBOK – Edición 2013

1. Alineamiento a la ISO 21500: 2012 3.

2. Se da más énfasis a los interesados y a las habilidades

interpersonales que debe tener el project manager

3. Complementar algunos procesos para hacerlos más

explicitos.

4. Asegurar armonización con otros estándares del PMI y

consistencia de la terminología PMI


Octubre 2014

Cambios en los Procesos en la Nueva

versión del PMBOK - Edición 2013


Octubre 2014


0.Planificar la

Gestión del

Alcance

Validar

Gestión del Alcance del Proyecto


Octubre 2014

Fuerzas que gobiernan un proyecto de sw

Problema de negocio

a resolver

Procesos de

negocio

Modelo de datos o

entidades de negocio

Modelo de interfaces,

integración y

cooperación

Tecnología y marcos

de referencia

tecnológicos

Aspectos

Humanos y

organizacionales

REQUERIMIENTOS

DE SW


Octubre 2014

Interesados en el proyecto


Octubre 2014

Factores ambientales de la Organización


Octubre 2014

Activos de la Organizacion


Octubre 2014



Octubre 2014

Nueva versión del PMBOK – Edición 2013

Tabla de Contenido

1. Introducción







Conclusiones

Bibliografía


Octubre 2014

Requisito

Un requerimiento es simplemente una declaración

abstracta de alto nivel de un servicio que debe

proporcionar un sistema o una restricción de este (Ian Sommerville, 2005:108)


Octubre 2014

Requisito de Software

Engineering Terminology IEEE 610


Octubre 2014

No es Requisito

1. Objetivo de negocio“Reducir las cuentas morosas a 10% o menos, dentro de tres meses ".

Consideración para la declaración del alcance (Business Objetivo)

2. Una restricción del proyecto "El software debe ser entregado el 31 de marzo de 2000"

A considerarse en el Plan de Proyecto o Declaración de Trabajo

2. Indicación de "cómo" va a funcionar la solución en lugar de "qué" ejemplo :"La ubicación se elegirá de una lista desplegable"

Considerado en la documentación de diseño


Octubre 2014

Piensa en los requisitos


Octubre 2014

Requisitos Generales del producto


Octubre 2014

Requisitos Generales del Servicio


Octubre 2014

Propiedades deseables y Atributos de los

requisitos del software

• Completo

• Consistente

•Necesario

•Conciso

•Clara (No ambiguo)

• Comprobable

(verificable)

• Trazable

• Alcanzable (factible)

Propiedades GlobalesPropiedades Individuales

Atributos

•Necesidad

•Prioridad

•Riesgo

Propiedades

Traceable

Tabla de Contenido

1. Introducción







Conclusiones

Bibliografía


Octubre 2014

Cual es el Rol de los Requisitos?

• Permite definir el alcance del proyecto

• Permite realizar la estimación de costos

• Permite elaborar el Presupuesto y la

programación del proyecto

• Con su análisis se realiza el diseño de software

• Son las bases para realizar las pruebas de software

• Se documentan y explican en Manuales de

documentación y formación


Octubre 2014

Requisitos : Componentes de los Productos de

Trabajo

Enunciado del Alcance de

la Solución

Requisitos de Alto Nivel

Requisitos Detallados


Octubre 2014

Componentes del Enunciado del Alcance

Define los límites de la solución:

•Objetivos, características y funciones

de negocio

•Contexto del Sistema e Interfaces

•Sistemas afectados

• Incluye informes, interfaces,


Octubre 2014

Requisitos _ Niveles

Requisitos de Alto

Nivel:

•Modelo de procesos de

negocio

•Requerimientos Funcionales

•Requerimientos de Interfaz

de usuario

•Requerimientos de

Interfaces

•Restricciones No

Funcionales

•Políticas de negocio

•Modelo conceptual

•Lista Inicial de CdU

• Relación de Involucrados

Requisitos

Detallados

-Reglas de Negocio

-- Modelo Lógico de

Datos

- Descripciones de

usuario

• Diccionario de datos

incluye atributos

derivados

•Prototipos


Octubre 2014

Componentes de los Requisitos detallados

Tabla de Contenido

1. Introducción

2. La Realidad de los proyectos de software





7. Conclusiones

Bibliografía


Octubre 2014

Especificación de requisito : Objetivo


Octubre 2014

Nivel de Detalle requerido en la Especificacion

Tabla de Contenido

1. Introducción






7. Conclusiones

Bibliografía


Octubre 2014

Corregir y Prevenir


Octubre 2014

Como se Asegura la calidad? VERIFICACION


Octubre 2014

Verificacion


Octubre 2014

Como se Asegura la calidad? VALIDACION


Octubre 2014

Validacion


Octubre 2014

Sospechosos Comunes

Tabla de Contenido

1. Introducción






7. Conclusiones

Bibliografía


Octubre 2014


Octubre 2014

Conclusiones

• Los Limites entre el sistema y su ambiente debe ser

definido

•Los factores sociales y organizacionales tienen mucha

influencia por lo que debe ser considerado


Octubre 2014

Conclusiones

Identifica los requisitos y los transmite

al equipo de desarrollo

• Representa el cliente /usuario

• Dueño del Caso de Negocio

Equipo de Desarrollo


Octubre 2014

Ingeniería de Requisitos

Es el Proceso de descubrir, analizar

documentar y verificar los servicios que

debe proporcionar el sistema y sus

restricciones

-Define un Proceso

-Facilita la comprensión de los que quiere

el cliente

Analizando sus Necesidades

Confirmando su viabilidad

Negociando la solución

Especificando la solucion sin

ambigüedad

Verificando y gestionando requisitos

para que el sistema pueda ser

operativo

The Ruta de Proyectos Exitosos

Errores Clasicos

Alto Costo y Cronograma Extenso

Algunas veces Costo y Cronograma Predecible

Costo y Cronograma Predecible Desarrollo Eficiente

Especializacion…

Para llegar hasta aqui se requiere usaralguna Buena Practica

Pero aplicarla realmente!

Reference: McConnell, Steve Rapid Development, Taming Wild Software Schedules.Microsoft Press, 1996

REFERENCIAS

Ingenieria de software Roger Pressman 6ta edición Ed .Mc Graw Hill

The Standish Group Report. Chaos. Standish Group Internal Report. 1995. Avalaible:

http://www.projectsmart.co.uk/docs/chaos_report.pdf [Citado Febrero

14 de 2009].

Identificacion temprana de aspectos, Betina Haak, Miguel Díaz, Claudia Marcos, Jane Pryor, ISISTAN Instituto de Sistemas Tandil,Facultad de Ciencias Exactas, UNICEN, Paraje Arroyo Seco, B7001BBO Tandil, Argentina E-mail: {cmarcos, jpryor,madiaz, bhaak}@exa.unicen.edu.ar

A requirements analysis tool based on natural, Mich, L., Garigliano, R. NL-OOPS:

language processing. Proceedings of the 3rd International Conference on Data Mining

2002. Bologna. P321-330. 2002.

Pertti Kellomäki. A Formal Basis for Aspect-Oriented Specification with Superposition. EnGary T. Leavens y Ron Cytron, editores, FOAL 2002 Proceedings: Foundations of Aspect-Oriented Languages, págs. 27–32, Abril 2002. ISU-TR02-06.

OWL Ontology WebLanguage Guide , Michael K. Smith, Chris Welty, y Deborah L. McGuinness, editores.. W3C Recommendation, Febrero 2004.


Octubre 2014

1er. conferenciaa octubre 2014

Documents