La presentación desarrolla una breve introducción teórica a la ISO 25000 de calidad de producto y luego se trabaja en una actividad altamente interactiva que muestra cómo pueden seguirse una serie de pasos básicos para crear el modelo de calidad de un producto de sofware

1. 12/11/2016
1
Calidad de productos de software
¿Es necesaria?
Lic. Pilar Barrio
Lic. Raúl Martínez
Noviembre 2016
Calidad de
productos de
software
¿Es necesaria?

2. 12/11/2016
2
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
• …
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

3. 12/11/2016
3
ISO/IEC 25000
Systems and software engineering —
Systems and software Quality
Requirements and Evaluation
(SQuaRE)
División de Extensiones 25050 - 25099
Organización de la serie de estándares
ISO/IEC 25000

4. 12/11/2016
4
ISO/IEC 25010
Systems and software engineering —
Systems and software Quality
Requirements and Evaluation (SQuaRE)
— System and software quality models

5. 12/11/2016
5

6. 12/11/2016
6
ISO/IEC 25000
Procesos propuestos

7. 12/11/2016
7
ISO/IEC 25030
Software engineering — Software product Quality
Requirements and Evaluation
(SQuaRE) — Quality requirements
ISO/IEC 25020
Software engineering – Software product quality
requirements and evaluation (SQuaRE) –
Measurement reference model and guide

8. 12/11/2016
8
ISO/IEC 25040
Systems and software engineering —
Systems and software Quality Requirements and
Evaluation (SQuaRE) — Evaluation process
ISO/IEC 25000
Estado actual

9. 12/11/2016
9
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

10. 12/11/2016
10
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
• Estados Unidos
APORTE DE VALOR
Proceso de adquisiciones

11. 12/11/2016
11
¿Qué buscamos?
¿Qué queremos hacer?
Adquirente
(comprar o desarrollar sistemas/software)
Adquirir la calidad esperada
Poder justificar y asegurar la adquisición correcta

12. 12/11/2016
12
Adquisiciones
Buenas
No tan buenas
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

13. 12/11/2016
13
¿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
<< riesgos
ayudando a definir
la calidad esperada
Permite priorizar
Fija objetivos
Permite medir en
base a evidencias
Ahorra re-trabajos

14. 12/11/2016
14
ACTIVIDAD
El caso y su contexto
Consigna
Desarrollo aplicando ISO/IEC 25000
Discusión
Conclusiones
El caso

15. 12/11/2016
15
Parte del contexto
• 1.200.000 muertes por
accidentes de coches
• 10% del efecto
invernadero debido a
los coches
• U$S 121.000.000.000
costo anual de las
congestiones de
tránsito (USA)
Parte del contexto

16. 12/11/2016
16
Parte del contexto
Parte del contexto

17. 12/11/2016
17
Parte del contexto
National Highway Traffic Safety Administration
(NHTSA)
Todo
humano
Parcialmente
automático
Algunas funciones
sin atención -
Crucero y mantener
su mano
Funciones
criticas
transferidas al
coche
Coche
totalmente
autónomo
Coche sin
posibilidad
de ser
conducido
Parte del contexto
Punto de
corte
Hoy

18. 12/11/2016
18
Parte del contexto
Ejemplo de implementación
Parte del contexto
Ejemplo de implementación

19. 12/11/2016
19
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

20. 12/11/2016
20

21. 12/11/2016
21
ACTIVIDAD – DISCUSIÓN DE UN
POSIBLE ENFOQUE
Primera identificación de requerimientos de calidad de un vehículo auto
conducido
Contexto
• Se asume:
– Tecnología no madura
– Regulaciones no maduras
– Desconocimiento de los compradores sobre el producto
• Dominio:
– Mercado regulado
– Varios proveedores
• No hay estándares
– Distintos compradores
• Distintas necesidades
• Distintos gustos
– Zonas geográficas / diferencias sociales y culturales
– Varios intervinientes en el modelo de negocio: seguros, sindicatos
• Restricciones
– Regulaciones geográficamente variables

22. 12/11/2016
22
Stakeholders
(a priorizar)
• Reguladores
• Fabricantes
• Autopartistas
• Mecánicos y servicios
• Agencias
• Compradores
• Compañías de seguros
• Transportistas (pasajeros y carga)
• Sindicatos (taxistas, conductores de ómnibus y carga,…)
• Hoteles
• Compañías de combustibles
• Aerolíneas de corta distancia
• Garajes, estacionamientos
• …
Calidad de producto
Stakeholder
Comprador/
Regulador
Comprador
Comprador/
Regulador
Comprador/
Regulador
Comprador/
Regulador
Comprador/
Regulador
Comprador/
Regulador
Comprador
Característica
deCalidad
Adecuación
Funcional
Eficiencia
Compatibilidad
Usabilidad
Confiabilidad
Seguridad
Mantenibilidad
Portabilidad
Fabricante X X X X X X X X
Prioridad R C R R R R R C
Valor
objetivo
<Valor> <Valor> <Valor> <Valor> <Valor> <Valor> <Valor> <Valor>

23. 12/11/2016
23
Características de calidad compuestas
• Dependability: Capacidad para actuar cuando y como se lo
requiera
Dependability
Disponibilidad
Tolerancia a fallas
Confidencialidad
Integridad
Mantenibilidad
Seguridad física
Dependability
Capacidad para actuar cuando y como se lo requiera
Stakeholder
Comprador
Comprador
Comprador
Comprador
Comprador
Comprador
Característica
de Calidad
Confiabilidad/
Disponibilidad
Confiabilidad/
Toleranciaafallas
Seguridad/
Confidencialidad
Seguridad/
Integridad
Mantenibilidad
ReducciónRiesgos
/Seguridadfísica
Fabricante X X X X X X
Prioridad C C C C C C
Valor objetivo <Valor> <Valor> <Valor> <Valor> <Valor> <Valor>

24. 12/11/2016
24
ACTIVIDAD – CONCLUSIONES
Primera identificación de requerimientos de calidad de un vehículo auto
conducido
Conclusiones
Proceso de elicitación
• Determinar características de calidad de un
coche auto conducido
– Detectar stakeholders
– Detectar necesidades de calidad de cada
stakeholder
– Cuantificar / fijar objetivos
– Resolver conflictos, analizar riesgos y priorizar
– Listar requerimientos de calidad consensuados

25. 12/11/2016
25
Conclusiones
Evaluación de riesgos
D:
Pérdida
económica
insignificante
C:
Pérdida
económica
significativa
(Organiza-
ción
afectada)
B:
Pérdida
económica
importante
(Organiza-
ción en
peligro)
A:
Desastre
financiero
(Organización
no sobrevive)
Aspectos
económicos
D:
Riesgos no
identificados
C:
Protección
contra
errores
B:
Protección
de datos y
servicios
críticos
A:
Protección
de datos y
servicios
estratégicos
Aspectos de
seguridad
Conclusiones
Evaluación de riesgos
D:
Daño
menor o
sin riesgo
para
personas
C:
Daño a
propiedad
o amenaza a
las personas
B:
Amenaza
a la vida
de
personas
A:
Mata a
muchas
personas
Aspectos de inocuidad
o seguridad física
D:
Sin riesgos
C:
Polución
local
B:
Daño
ambiental
recupera-
ble
A:
Daño
ambiental
irrecupera-
ble
Aspectos
ambientales

26. 12/11/2016
26
Consideraciones que surgen del análisis
De ingeniería
De factor
humano en el
diseño
De seguridad pública
…
De tipo
• Ético
• Psicológicas
• Sociológicas
Comerciales
Dilemas

27. 12/11/2016
27
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
Gracias
Lic. Raúl Martínez
@RaulMartinez582
rmartinez@rmya.com.ar
Lic. Pilar Barrio
pbarrio@rmya.com.ar
Grupo de Linkedin: Mejora de Procesos de TI