El inicio de una buena relación El inicio de una buena relación
Sonia I. López Pérez
Este genio no se entera
de nada!
Este mortal no sabe lo que quiere
¿Por qué hablar de Requisitos?
¿Por qué hablar de Requisitos?
Otros Código4%
1%
Diseño Requisitos 13%
82%
Requisitos 56%
Diseño 27%
Otros Código 10%
7%
Distribución de Defectos Distribución de esfuerzo en reparación de Defectos
Fuente: James Martin Fuente: Dean Leffingwell
¿Por qué hablar de Requisitos?
¿Por qué hablar de Requisitos?
Boehm, 1975: 45% de los errores tienen su origen en los requisitos y en el diseño preliminar.
DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto software se deben a una mala
especificación de requisitos.
Chaos Report, 1995: Los factores principales que conducen al fracaso en los proyectos Software son:
Falta de comunicación con los usuarios Requisitos incompletos
Cambios a los requisitos
La fábrica de software: dos aspectos La fábrica de software: dos aspectos
Desarrolla un producto software
Requisitos del cliente Requisitos del producto
Requisitos del Software
Alcance del servicio Requisitos del cliente
Requisitos internos de la organización de TI Aspectos cuantitativos del servicio
Aspectos cualitativos del servicio
Presta un servicio
Requisitos de Nivel de Servicio
Una visión global e integrada Una visión global e integrada
DESARROLLO DESARROLLO MANTENIMIENTO MANTENIMIENTO
OPERACI OPERACIÓÓNN
Gobierno Gobierno
Solicitudes del cliente Entrega al cliente
SERVICOS SERVICOS
PRODUCTO PRODUCTO
Requisitos de Producto
Ciclo de Vida
Buenas Prácticas de la Industria Buenas Prácticas de la Industria
Solicitudes del cliente Entrega al cliente
SERVICOS SERVICOS
La fábrica de software: el producto La fábrica de software: el producto
Desarrolla un producto software
Requisitos del cliente Requisitos del producto
Requisitos del Software
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
1. Gestión de Requisitos. Asegurar que los requisitos están libres de inconsistencias no solo entre los
propios requisitos sino entre éstos y los work
products. Se gestionan requisitos funcionales y no
funcionales, generados por el cliente o por las propias necesidades del producto. Incluye actividades de
revisión, documentación, gestión de cambios, etc.
2. Desarrollo de Requisitos. Analizar las decisiones tomadas a lo largo del desarrollo para conocer su impacto en los requisitos. Crear y analizar los tres tipos de requisitos identificados por CMMi: de cliente, de producto y de los componentes del producto.
Desarrollo y Gestión de Requisitos?
¿ Cómo nos ayuda CMMi ? (staged)
¿ Cómo nos ayuda CMMi ? (staged)
SG1 Gestión de Requisitos
SP 1.1 Obtener y entender los requisitos SP 1.2 Obtener acuerdos sobre los Requisitos
SP 1.3 Gestionar los cambios en los Requisitos SP 1.4 Mantener trazabilidad bidireccional
SP 1.5 Identificar inconsistencias entre el trabajo del proyecto y los Requisitos
Gestión de Requisitos
(Engineering-REQM)
¿ Cómo nos ayuda CMMi ? (staged)
¿ Cómo nos ayuda CMMi ? (staged)
SG1 Desarrollo de Requisitos de Cliente SP1.1 Elicitar las necesidades
SP1.2 Desarrollar las necesidades del cliente SG2 Desarrollo de Requisitos de Producto
SP 2.1 Establecer Requisitos de Producto y Producto-Componente SP 2.2 Asignar Requisitos de Producto-Componente
SP 2.3 Identificar Requisitos de Interface SG 3 Analizar y validar los Requisitos
SP 3.1 Establecer conceptos operacionales y escenarios
SP 3.2 Establecer una deficinicón de la funcionalidad requerida SP 3.3 Analizar los Requisitos
SP 3.4 Analizar los Requisitos para alcanzar un equilibrio SP 3.5 Validar los Requisitos con método exhaustivos
Desarrollo de Requisitos
(Engineering-RD)
¿ Cómo nos ayuda CMMi ?
¿ Cómo nos ayuda CMMi ?
Los procesos de negocio.
Los interesados (stakeholders). Los afectados por el sistema.
Conocimiento del dominio de la aplicación.
El entorno físico que rodea al sistema.
El entorno organizacional.
Fuentes de requisitos
Requisitos de Producto: Estandares, Normas, ...
Requisitos de Producto: Estandares, Normas, ...
IEEE Std. 610.12-1990 Glosario estándar de terminología de Ingeniería del Software
IEEE 830-1998 Estándar para especificación de requisitos software
IEEE Std. 829-1983 Estándar para documentación de pruebas del software
DoD: DI-IPSC-81431, DI-IPSC-81434, DI-IPSC-81441 Estándares para especificación de requisitos software SMAP-DID-P200-SW Estándar de la NASA para el SRS
ESA-PSS-05 Estándares y Guías para Ingeniería del Software de la Agencia Espacial Europea
ISO/IEC TR 15504 ó SPICE
Requisitos de Producto:
Métodos de especificaciónRequisitos de Producto:
Métodos de especificaciónENTENDIMIENTO
PRECISIÓN + +
Lenguaje natural
Lenguaje estructurado
Metodologías Case, etc.
Especificaciones formales, UML, etc
Requisitos de Producto: Características Requisitos de Producto: Características
Especificado por escrito Completos
Sin conflictos, consistentes No redundantes
Entendible ( claros, sin ambigüedades ) Posible de probar o verificar
Posibles de hacerles cambios
No describir ningún detalle del diseño del software, de su verificación o de la dirección del proyecto
Que recojan las expectativas y necesidades actuales y futuras de los usuarios.
Incluir requisitos negativos si es necesario
Alcance del servicio Requisitos del cliente
Requisitos internos de la organización de TI Aspectos cuantitativos del servicio
Aspectos cualitativos del servicio
La fábrica de software: el servicio La fábrica de software: el servicio
Presta un servicio
Requisitos de Nivel de Servicio
¿ Cómo nos ayuda ITIL ?
¿ Cómo nos ayuda ITIL ?
Niveles de Madurez PMF
Sistemas certificables: BS 15000 e ISO 20000
Profesionales certificables (EXIN, ISEB)
Foundation Certificate in IT Service Management Practitioner's Certificate in IT Service Management Manager's Certificate in IT Service Management
Vigente la versión 2 de ITIL OGC e itSMF están trabajando
actualmente en la actualización de ITIL.
La nueva versión aparecerá en el 2006.
¿ Cómo nos ayuda ITIL ?
¿ Cómo nos ayuda ITIL ?
IT IT I I nfrastructure nfrastructure L L ibrary ibrary
¿ Cómo nos ayuda ITIL ?
¿ Cómo nos ayuda ITIL ?
Service Delivery
¿ Cómo nos ayuda ITIL ?
¿ Cómo nos ayuda ITIL ?
Proceso de Gestión de los Niveles de Servicio Identificación
Comprensión Procesos de Negocio del cliente Identificación de Requisitos
Definición
Definición de Requisitos
Finalización
Negociar con el cliente los ANS
Monitorización
Monitorizar los ANS
Información
Informar al cliente y a nuestra organización de los niveles alcanzados
Revisión
Identificar oportunidades de mejora
¿ Cómo nos ayuda ITIL ?
¿ Cómo nos ayuda ITIL ?
Cambios en los Requisitos de Servicio
Alcance del servicio Requisitos del cliente
Requisitos internos de la organización de TI Aspectos cuantitativos del servicio
Aspectos cualitativos del servicio
La fábrica de software: integración La fábrica de software: integración
Presta un servicio
Desarrolla un producto software
Requisitos de Nivel de Servicio
Requisitos del cliente Requisitos del producto
Requisitos del Software
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI
Configuration Management Change Management
Release Management
Configuration Management
Incident Management Problem Management
Verification
Causal Analysis & Resolution
Service Desk ???
Service Level Management
Application Management
Requirements Management Requirements Development Technical Solution
Product Integration Verification, Validation
Integrated Project Management.
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI Functional
requirements.
Non-functional requirements.
Usability requirements.
Change cases.
Testing requirements.
Requirements
management checklist.
Organization of the requirements team.
Requirements Management (PA:
Engineering)
SG1 Manage requirements
Obtain understanding of requirements Obtain commitment to requirements Manage requirements changes
Maintain bi-directional traceability
Identify inconsistencies between project work and Requirements
ApplicationManagement Requirements
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI
Functional requirements Non-functional
requirements
Usability requirements Change cases
Testing requirements Requirements
management checklist Organization of the requirements team
Requirements Development (PA: Engineering) SG 1 Develop customer requirements
Elicit needs
Develop the customer requirements
SG 2 Develop product requirements
Establish product & product-component reqts.
Allocate product-component reqts.
Identify interface requirements
SG 3 Analyze and validate requirements
Establish operational concepts & scenarios Establish definition of required functionality Analyze requirements
Analyze requirements to achieve balance Validate reqts with comprehensive models
ApplicationManagement Requirements
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI Design for non-functional
requirements/manageability.
Risk-driven scheduling.
Managing tradeoffs.
Application-independent design guidelines and application
Frameworks.
Design management checklist.
Problems with design guidelines.
Testing the requirements.
Organization of the design team.
Technical Solution (PA: Engineering) SG 1 Select product component solutions
– Develop detailed alternatives and selection criteria
– Evolve operational concepts & scenarios – Select product component solutions
SG 2 Develop the design
Design the product or product component solution
Establish a technical data package Design interfaces using criteria
Perform make, buy, or reuse analyses
SG 3 Implement the product design
Implement the design
Develop product support documentation
ApplicationManagement Design
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI
Consistent coding conventions.
Application-independent building
Guidelines.
Operability testing.
Build management checklist.
Organization of the build team .
Product Integration (PA: Engineering) SG1 Prepare for product integration
– Determine integration sequence
– Establish the integration environment
– Establish integration procedures and criteria
SG 2 Ensure interface compatibility
Review interface description for completeness Manage interfaces
SG 3 Assemble product deliver product
Confirm readiness for integration Assemble product components Evaluate assembled components
Package and deliver the product or component
ApplicationManagement Build
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Procesos/Funciones ITIL Áreas de Procesos CMMI
Consistent coding conventions.
Application-independent building
Guidelines.
Operability testing.
Build management checklist.
Organization of the build team .
Verification (PA: Engineering) SG1 Prepare for verification
– Select work products for verification – Establish the verification environment
– Establish verification procedures and criteria
SG 2 Perform peer reviews
Prepare for peer reviews Conduct peer reviews Analyze peer review data
SG 3 Analyze selected work products
Perform verification
Analyze verification results and identify corrective action
ApplicationManagement Build
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Aportación de ITIL a CMMi
Punto único de contacto con usuarios Consultas sobre servicios o productos Problemas en servicios o productos
Solicitudes de cambios en servicios o productos
Cubre más funcionalidad que el Help Desk tradicional No gestiona solo problemas
Proporciona información relevante:
– Al cliente: funcionamiento de los sistemas, estado de los servicios – A la Fábrica de Software: información detallada acerca de las
incidencias facilitando la detección de mejoras y solución de posibles problemas
Punto Crítico de la integración: Service Desk
Integración ITIL / CMMi: Requisitos Integración ITIL / CMMi: Requisitos
Aunque son modelos distintos enfocados a diferentes áreas de TI existen relaciones y coincidencias entre ambos modelos pudiéndose generalizar algunos procesos y prácticas
Gestión de Requisitos Gestión de Configuración Gestión de Cambios
Gestión de Releases
Verificación y Validación
Gestión de Incidencias y Problemas
Integración ITIL / CMMi: Recomendaciones Integración ITIL / CMMi: Recomendaciones
Los grupos de explotación que gestionan la operación y servicio deben participar en el establecimiento de
requisitos de los productos que van a ser desarrollados o mejorados con los requisitos del servicio que faciliten la operación de éste
Variantes de implantación:
a) Tratar los servicios usando CMMi
b) Tratar los servicios como productos usando CMMi
Requiere interpretación para ajuste
c) Tratar el desarrollo de productos con CMMi, los servicios usando ITIL e integrando los procesos de ITIL y CMMi
Gestionar eficazmente CMMI e ITIL en una organización requiere:
Definir claramente el interfaz entre los procesos de ambos
Definir las fronteras de responsabilidades entre las organizaciones de desarrollo y explotación
Estudiar en detalle la información que comparten ambos grupos de procesos.
Entradas a procesos CMMI que provienen de salidas de ITIL
Entradas a procesos de ITIL que provienen de procesos de CMMI
Integración ITIL / CMMi: Recomendaciones
Integración ITIL / CMMi: Recomendaciones
Beneficios Beneficios
Mejora la predictibilidad en tiempo y presupuesto (20%
aprox.)
Mejorar plazos de entrega y tiempo en el desarrollo de un proyecto
Mejorar la disponibilidad, confianza y seguridad de los servicios IT de misión crítica
Incremento de la calidad en productos y servicios
Incrementa la satisfacción del cliente un 30% aprox. (mayor cooperación y menores defectos)
Decrece costes de no calidad (con la detección de errores en etapas tempranas)
Proporcionar servicios que se adecuen a las necesidades del negocio, del cliente y del usuario
Referencias de interés Referencias de interés
www.itgi.org IT Governance Institute
www.isaca.org Information Systems Audit and Control Assoc.
www.itil.co.uk UK Office of Government Commerce www.itsmf.com IT Service Management Forum
www.sei.cmu.edu Software Engineering Institute http://seir.sei.cmu.edu SEIR (SEI Repository) www.ndia.org National Defense Industrial Assoc.
Sonia I. López Pérez
Gerente Consultoría
Tecnología y Calidad de Software, S.A.
C/ Chile, 4 Edificio II Oficina 20 28290 Las Rozas
www.tqs-es.com
ANEXO: CMMI
ANEXO: CMMI
SP 1.1 Obtener y entender los requisitos
Establish criteria for distinguishing appropriate requirements providers
Establish objective criteria for the acceptance of requirements.
Analyze requirements to ensure that the established criteria are met.
Reach an understanding of the requirements with the requirements provider so the project participants can commit to them.
Gestión de Requisitos (Engineering-REQM) Gestión de Requisitos (Engineering-REQM)
Subprácticas
SP 1.2 Obtener acuerdos sobre los Requisitos Assess the impact of requirements on existing commitments.
Negotiate and record commitments
Subpr.
SP 1.3 Gestionar los cambios en los Requisitos
Capture all requirements and requirements changes that are given to or generated by the project
Maintain the requirements change history with the rationale for the changes.
Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
Make the requirements and change data available to the project.
Subprácticas
Gestión de Requisitos (Engineering-REQM)
Gestión de Requisitos (Engineering-REQM)
SP 1.4 Mantener trazabilidad bidireccional
Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented.
Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes, and work products
Maintain horizontal traceability from function to function and across interfaces
Generate the requirements traceability matrix.
Subprácticas
Gestión de Requisitos (Engineering-REQM)
Gestión de Requisitos (Engineering-REQM)
SP 1.1 Obtener y entender los requisitos
Establish criteria for distinguishing appropriate requirements providers
Establish objective criteria for the acceptance of requirements.
Analyze requirements to ensure that the established criteria are met.
Reach an understanding of the requirements with the requirements provider so the project participants can commit to them.
Subprácticas
Gestión de Requisitos (Engineering-REQM)
Gestión de Requisitos (Engineering-REQM)
ANEXO: CMMI
ANEXO: CMMI
SG 1 Desarrollar Requisitos de Cliente
Elicit Needs
Develop the Customer Requirements
Spec.Practices
SG 2 Desarrollar Requisitos de Producto
Establish Product and Product-Component Requirements Allocate Product-Component Requirements
Identify Interface Requirements
Spec.Practices
Desarrollo de Requisitos (Engineering-RD)
Desarrollo de Requisitos (Engineering-RD)
SG 3 Analizar y validar los Requisitos
Establish Operational Concepts and Scenarios Establish a Definition of Required Functionality Analyze Requirements
Analyze Requirements to Achieve Balance
Validate Requirements with Comprehensive Methods
SpecificPractices
Desarrollo de Requisitos (Engineering-RD)
Desarrollo de Requisitos (Engineering-RD)
ANEXO: ITIL
ANEXO: ITIL
Requisitos de Nivel de Servicio Requisitos de Nivel de Servicio
Ejemplo de Diseño de Servicio
Alcance: desarrollo, mantenimiento y operación de todos los sistemas de información del ERP.
Requisitos:
1. Los mantenimientos correctivos tendrán prioridad sobre los mantenimientos evolutivos y los nuevos desarrollos.
2. Cada fin de mes se dará prioridad a los procesos de facturación sobre la operación o corrección de
cualquier otro sistema.
3. Cada fin de año se dará prioridad a los procesos de cierre contable sobre la operación o corrección de cualquier otro sistema.
Requisitos de Nivel de Servicio Requisitos de Nivel de Servicio
Ejemplo de Diseño de Servicio
Alcance: desarrollo, mantenimiento y operación de todos los sistemas de información del ERP.
Servicios:
Dpto. Financiero Dpto. RRHH Dpto. Compras Dpto. Logística Dpto. Att. Cliente Dpto. Ventas
Mantenimiento Correctivo Mantenimiento Evolutivo Operación
Nuevos desarrollos
Requisitos de Nivel de Servicio Requisitos de Nivel de Servicio
Ejemplo de Diseño de Servicio
Servicio: Mantenimiento Correctivo - Dpto Financiero
Requisitos:
Los mantenimientos correctivos que se precisen para solventar un incidente en explotación deberán ser
realizados e implantados no más allá de 3 horas desde la detección del incidente.
Servicio: Operación - Dpto Financiero Requisitos:
El primer día laborable de Enero se realizarán los
procesos de cierre contable. Los procesos no tendrán una duración superior a 24 horas.
