aprovechando al máximo los estándares 10/16 cpci
TRANSCRIPT
19/10/2016
1
Aprovechando al máximo
los estándares
Calidad de producto de software
Lic. Pilar Barrio
Lic. Raúl Martínez
Octubre 2016
El mal uso de los estándares • Encararlos por motivos ajenos a su finalidad
• Afán o presión por certificar
• Burocracia innecesaria
• Simular cumplimiento
• …
19/10/2016
2
El camino hacia la adopción • Certificar puede o no ser importante /
necesario
• Aporte de valor durante el camino
• Certificar es sólo el inicio
• El estándar es parte de un camino, no el destino
ISO/IEC 25000
Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE)
19/10/2016
3
División de Extensiones 25050 - 25099
Organización de la serie de estándares ISO/IEC 25000
ISO/IEC 25010
Systems and software engineering —
Systems and software Quality
Requirements and Evaluation (SQuaRE) — System and software quality models
19/10/2016
4
19/10/2016
5
19/10/2016
6
ISO/IEC 25000
Procesos propuestos
ISO/IEC 25030 Software engineering — Software product Quality Requirements and Evaluation
(SQuaRE) — Quality requirements
19/10/2016
7
ISO/IEC 25020 Software engineering – Software product quality requirements and evaluation (SQuaRE) – Measurement reference model and guide
ISO/IEC 25040 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process
19/10/2016
8
APORTE DE VALOR
Proceso de adquisiciones
¿Qué buscamos?
19/10/2016
9
¿Qué queremos hacer?
Adquirente (comprar o desarrollar sistemas/software)
Adquirir la calidad esperada
Poder justificar y asegurar la adquisición correcta
Adquisiciones
Buenas
No tan buenas
19/10/2016
10
Adquirir lo correcto porque…
Una no tan buena adquisición
– Riesgos
• técnicos,
• financieros,
• sociales
– Decisión tendenciosa o interesada
– Informal
– Puede salir bien por casualidad (no repetible)
Una buena adquisición
– Ahorra dinero y tiempo
– Disminuye riesgos
– Justifica la selección
– Se adquiere la calidad esperada o acordada
– Repetible
¿Tiene costo? SÍ
• Definir qué da valor al producto a adquirir • Entender los modelos de calidad relacionados
• Usarlos – Identificar en los modelos las características de interés
– Priorizar
– Especificar
– Adquirir por desarrollo o compra
– Buscar evidencias de existencia de las características y cumplimiento de objetivos
– …
– Mantener y mejorar
19/10/2016
11
<< riesgos ayudando a definir la calidad esperada
Permite priorizar
Fija objetivos
Permite medir en base a evidencias
Ahorra re-trabajos
ISO/IEC 25000
Estado actual y utilización
19/10/2016
12
Estado actual • IRAM • ISO
IRAM-ISO/IEC 25000:2014
IRAM-ISO/IEC 25001
IRAM-ISO/IEC 25010
IRAM-ISO/IEC 25012
IRAM-ISO/IEC 25020
IRAM-ISO/IEC 25030
IRAM-ISO/IEC 25021
IRAM-ISO/IEC 25040
ISO/IEC 25000:2014
ISO/IEC 25001:2014
ISO/IEC 25010:2011
ISO/IEC 25011
ISO/IEC 25012:2008
ISO/IEC 25020:2007
ISO/IEC 25021:2012
ISO/IEC 25022
ISO/IEC 25023
ISO/IEC 25024
ISO/IEC 25030:2007
ISO/IEC 25040:2011
ISO/IEC 25051:2014
Utilización en distintos países (*)
• Argentina
• España
• Francia
• Italia
• Chile
• Alemania (SAP)
• Otros (China, América Latina)
* Información publicada / conocida
19/10/2016
13
Países que trabajan en la redacción / revisión de la norma ISO/IEC 25000
• Japón • China • Italia • Canadá • Malasia • Corea del sud • India • Francia • Argentina • Brasil • Reino Unido
ACTIVIDAD
El caso y su contexto Consigna Desarrollo aplicando ISO/IEC 25000 Discusión Conclusiones
19/10/2016
14
El caso
Parte del contexto
19/10/2016
15
Parte del contexto
Parte del contexto National Highway Traffic Safety Administration (NHTSA)
19/10/2016
16
Parte del contexto Ejemplo de implementación
Consigna
• Realizar una primera identificación de requerimientos de calidad de un vehículo auto conducido, en base a los modelos ISO/IEC 25000
19/10/2016
17
19/10/2016
18
Dilemas
Las tres leyes robóticas Manual de Robótica – 56ª edición – Año 2058
1. Un robot no hará daño a un ser humano o, por su inacción, dejará que un ser humano sufra daño.
2. Un robot debe obedecer las órdenes que le son dadas por un ser humano, excepto cuando estas órdenes están en oposición con la Primera Ley.
3. Un robot debe proteger su propia existencia, hasta donde esta protección no esté en conflicto con la Primera o Segunda Leyes.
Isaac Asimov – I Robot - 1950
19/10/2016
19
Gracias
Lic. Raúl Martínez
@RaulMartinez582
Lic. Pilar Barrio
Grupo de Linkedin: Mejora de Procesos de TI