Embed Size (px)
Citation preview
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?
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
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
12/11/2016
4
ISO/IEC 25010
Systems and software engineering —
Systems and software Quality
Requirements and Evaluation (SQuaRE) — System and software quality models
12/11/2016
5
12/11/2016
6
ISO/IEC 25000
Procesos propuestos
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
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
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
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
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/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
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
12/11/2016
14
ACTIVIDAD
El caso y su contexto Consigna Desarrollo aplicando ISO/IEC 25000 Discusión Conclusiones
El caso
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
12/11/2016
16
Parte del contexto
Parte del contexto
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
12/11/2016
18
Parte del contexto Ejemplo de implementación
Parte del contexto Ejemplo de implementación
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
12/11/2016
20
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
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
Stak
eh
old
er
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
/ R
egu
lad
or
Co
mp
rad
or
Car
acte
ríst
ica
de
Cal
idad
Ad
ecu
ació
n
Fun
cio
nal
Efic
ien
cia
Co
mp
atib
ilid
ad
Usa
bili
dad
Co
nfi
abili
dad
Segu
rid
ad
Man
ten
ibili
dad
Port
abili
dad
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>
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
Co
mp
rad
or
Co
mp
rad
or
Co
mp
rad
or
Co
mp
rad
or
Co
mp
rad
or
Co
mp
rad
or
Característica de Calidad
Co
nfi
abili
dad
/
Dis
po
nib
ilid
ad
Co
nfi
abili
dad
/
Tole
ran
cia
a fa
llas
Segu
rid
ad /
C
on
fid
enci
alid
ad
Segu
rid
ad /
In
tegr
idad
Man
ten
ibili
dad
Red
ucc
ión
Rie
sgo
s /
Segu
rid
ad f
ísic
a
Fabricante X X X X X X
Prioridad C C C C C C
Valor objetivo <Valor> <Valor> <Valor> <Valor> <Valor> <Valor>
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
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
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
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
Lic. Pilar Barrio
Grupo de Linkedin: Mejora de Procesos de TI
