Relatorio Final Rodrigo Becker Rabello 2012 PDF

UNIVERSIDADE FEDERAL DE SANTA CATARINA
INTEGRAO DE ENGENHARIA DE USABILIDADE EM UM

MODELO DE MATURIDADE/CAPACIDADE DE PROCESSO DE
SOFTWARE
Relatrio de Concluso de Curso
Rodrigo Becker Rabello
Orientadora:
Prof. Dr. rer. nat. Christiane Gresse von Wangenheim, PMP
Florianpolis, 2012/1
UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMTICA E ESTATSTICA
CURSO DE SISTEMAS DE INFORMAO

SOFTWARE
Relatrio de Concluso de Curso

apresentado como exigncia parcial
para obteno do Diploma de
Graduao
em
Sistemas
de
Informao da Universidade Federal
de Santa Catarina.
Orientadora: Prof. Dr. rer. nat.
Christiane Gresse von Wangenheim,
PMP
Florianpolis - SC 2012/1
2

SOFTWARE
Relatrio de Concluso de Curso apresentado como exigncia parcial para

obteno do Diploma de Graduao em Sistemas de Informao da
Universidade Federal de Santa Catarina.
__________________________________________________
Orientadora: Prof. Dr. rer. nat. Christiane Gresse von Wangenheim, PMP
Banca examinadora
__________________________________________________
Professor Jean Carlo Rossa Hauck
__________________________________________________
Professora Patrcia Vilain
Sumrio
ndice de Figuras ................................................................................................ 6
ndice de Quadros .............................................................................................. 7
ndice de Tabelas ............................................................................................... 8
Lista de Siglas e Abreviaturas ............................................................................ 9
Resumo ............................................................................................................ 10
1. Introduo .....................................................................................................11
1.1 Contextualizao .....................................................................................11
1.2 Problema ................................................................................................ 14
1.3 Objetivos ................................................................................................. 14
1.3.1 Objetivo Geral .................................................................................. 14
1.3.2 Objetivos Especficos ....................................................................... 14
1.4 Metodologia ............................................................................................ 15
1.5. Estrutura do trabalho ............................................................................. 16
2. Fundamentao Terica ............................................................................... 18
2.1 Modelos de Maturidade/Capacidade de Processo de Software ............. 18
2.1.1 Definio .......................................................................................... 18
2.1.2 Estrutura........................................................................................... 19
2.1.3 Principais Modelos de Maturidade Capacidade de Processo de
Software .................................................................................................... 20
2.2 Convergncia/Divergncia Digital ........................................................... 32
2.3 Usabilidade ............................................................................................. 35
2.3.1 Interao Homem-Computador ........................................................ 35
2.3.2 Engenharia de Usabilidade .............................................................. 37
2.3.3 Projeto Centrado no Usurio ............................................................ 38
3. Reviso do Estado da Arte ........................................................................... 44
3.1 Definio ................................................................................................. 44
3.2 Primeira Iterao de Busca..................................................................... 44
3.3 Segunda Iterao de Busca.................................................................... 45
3.4 Anlise das Informaes ......................................................................... 46
3.4.1 ISO/IEC 12207:2008 Systems and software engineering - Software
life cycle processes ................................................................................... 46
3.4.2 Amendment to ISO/IEC 12207:1995 Information Technology
Software life cycle processes .................................................................... 49
3.4.3 ISO/IEC CD 15504-5:2003 Information Technology Process
Assessment Part 5: An exemplar Process Assessment Model ............. 53
3.4.4 ISO/TR 18529:2000 Ergonomics - Ergonomics of human-system
interaction -- Human-centred lifecycle process descriptions ..................... 56
3.5 Integrao de Engenharia de Usabilidade com a Engenharia de Software
4
...................................................................................................................... 58
3.5.1 Aspects of Integrating User Centered Design into Software
Engineering Processes ............................................................................. 58
3.5.2 Integrating Usability Techniques into SW Development ................... 60
3.5.3 Framework for Integrating Usability Practices into the Software
Process ..................................................................................................... 63
3.6 Discusso ............................................................................................... 68
3.7 Mapeamento dos Modelos de Referncia de Engenharia de Usabilidade
...................................................................................................................... 69
4. Modelo de Maturidade/Capacidade de Processo de Software ..................... 77
4.1 Definio do Modelo de Referncia ........................................................ 78
4.1.1 Adaptando o Modelo para a Integrao de Processos de Usabilidade
.................................................................................................................. 81
4.1.2 Definio dos Processos de Usabilidade ......................................... 85
4.2 Framework de Medio .......................................................................... 87
4.2.1 Definio da Capacidade do Processo ............................................ 88
4.2.2 Definio da Maturidade Organizacional .......................................... 92
4.3 Descrio Detalhada dos Processos de Engenharia de Usabilidade
Adicionados .................................................................................................. 98
5. Avaliao do Modelo Proposto ................................................................... 103
5.1 Definio ............................................................................................... 103
5.2 Execuo .............................................................................................. 105
5.3 Anlise dos dados ................................................................................. 105
5.4 Discusso .............................................................................................. 111
6. Concluso ...................................................................................................113
Referncias .....................................................................................................114
Apndice A Resumo do Trabalho Enviado ...................................................119
Apndice B - Expert Panel Realizado para Avaliar o Modelo Proposto .......... 141
Apndice C Artigo do Trabalho .................................................................... 144
ndice de Figuras
Figura 1 Processos do ciclo de vida de software Fonte: Adaptado de ISO/IEC
12207, 2008. .................................................................................................... 12
Figura 2 Dimenses da ISO/IEC 15504 - Fonte: ISO/IEC, 2006. ..................... 21
Figura 3 Processos da ISO/IEC 15504-7 Fonte: Adaptado de ISO/IEC, 2008.
......................................................................................................................... 23
Figura 4 Processos do ciclo de vida de software Fonte: Adaptado de ISO/IEC
12207, 2008. .................................................................................................... 25
Figura 5 Componentes do CMMI Fonte: SEI, 2010....................................... 28
Figura 6 Componentes do MPS.BR Fonte: SOFTEX, 2011. ......................... 30
Figura 7 Convergncia Digital- Fonte: LIEB, 2010. .......................................... 33
Figura 8 Uso do Skype em dispositivos diferentes. Fonte: SKYPE, 2011. .... 33
Figura 9 Uso e contexto do IHC Fonte: ACM SIGCHI - Curricula for HumanComputer Interaction, 1996. ............................................................................. 36
Figura 10 Estrutura de usabilidade - Fonte: NBR ISO 9241-11, 2011. ............. 37
Figura 11 Projeto Centrado no Usurio - Fonte: Adaptado de NBR ISO 9241210, 2011.......................................................................................................... 38
Figura 12 Processos do ciclo de vida de software Fonte: Adaptado de
ISO/IEC 12207, 2008. ...................................................................................... 47
Figura 13 Processos da emenda ISO/IEC 12207 - Fonte: Adaptado de ISO/IEC
12207:1995/FDAM, 2001. ................................................................................ 50
Figura 14 Processos ISO/IEC CD 15504-5:2003 - Fonte: Adaptado de ISO/IEC
CD 15504-5, 2003. ........................................................................................... 54
Figura 15 Hierarquias semelhantes ES X EU (padres, modelos de processos e
processos operacionais Fonte: Adaptado de NEBE; ZIMMERMANN; 2007 . 59
Figura 16 Viso de alto nvel da definio dos requisitos Fonte: Adaptado de
ANDERSON et al., 2001. ................................................................................. 61
Figura 17 Viso de alto nvel da concepo e execuo do desenvolvimento
Fonte: Adaptado de ANDERSON et al., 2001. ................................................. 62
Figura 18 Mapeamento de atividades IHC para atividades de ES no processo
de software - Fonte: Adaptado de FERR; JURISTO; MORENO, 2005. ......... 65
Figura 19 Diviso dos ciclos iterativos em estgios - Fonte: Adaptado de
FERR; JURISTO; MORENO, 2005. ............................................................... 66
Figura 20 Elementos principais do processo de avaliao - Fonte: Adaptado de
ISO/IEC, 2003. ................................................................................................. 77
Figura 21 Relacionamentos no modelo de avaliao de Processo - Fonte:
Adaptado de ISO/IEC, 2003. ............................................................................ 78
Figura 22 Processos do ciclo de vida de software Fonte: Adaptado de
ISO/IEC 12207, 2008. ...................................................................................... 80
Figura 23 Processos do Modelo de Referencia Proposto com Extenso para
Engenharia de Usabilidade .............................................................................. 82
Figura 24 - Grfico das respostas da 1 pergunta do Expert Panel. .............. 106
Figura 33 - Grfico das respostas da 10 pergunta do Expert Panel. ............ 109
6
ndice de Quadros
Quadro 1 Nveis de Capacidade da ISO/IEC 15504 - Fonte: Adaptado de
ISO/IEC, 2006. ................................................................................................. 21
Quadro 2 Nveis de Maturidade da ISO/IEC 15504 - Fonte: Adaptado de
ISO/IEC, 2008. ................................................................................................. 22
Quadro 3 Exemplo de Processo ISO/IEC 12207 - Fonte: ISO/IEC 12207, 2008.
......................................................................................................................... 25
Quadro 4 Nveis de Capacidade do CMMI - Fonte: Adaptado de SEI, 2010. .. 27
Quadro 5 Nveis de Maturidade do CMMI - Fonte: Adaptado de SEI, 2010. ... 28
Quadro 6 Exemplo de rea de Processo CMMI - Fonte: SEI, 2010................. 29
Quadro 7 Nveis de maturidade do MR-MPS - Fonte: SOFTEX, 2011. ............ 31
Quadro 8 Exemplo de Processo MPS-BR - Fonte: SOFTEX, 2011. ................ 32
Quadro 9 Meios de entrada e sada de dispositivos. ........................................ 34
Quadro 10 Termos de busca ............................................................................ 44
Quadro 11 Materiais identificados .................................................................... 45
Quadro 12 Viso de Processo para Usabilidade - Fonte: ISO/IEC 12207, 2008.
......................................................................................................................... 48
Quadro 13 Processo de Usabilidade - Fonte: ISO/IEC 12207:1995/FDAM,
2001. ................................................................................................................ 51
Quadro 14 Processo de Usabilidade - Fonte: ISO/IEC CD 15504-5, 2003. ..... 55
Quadro 15 Nveis de capacidade do modelo - Fonte: ISO/TR 18529, 2000 ... 58
Quadro 16 Framework para integrao de usabilidade no processo de
software- Fonte: Adaptado de FERR; JURISTO; MORENO, 2005. ............... 67
Quadro 17 Mapeamento dos modelos de referncia de engenharia de
usabilidade ....................................................................................................... 70
Quadro 18 Nveis de Capacidade e seus respectivos atributos de processo Fonte: Adaptado de ISO/IEC, 2006. ................................................................. 88
Quadro 19 Escala de classificao dos atributos de processo - Fonte: Adaptado
de ISO/IEC, 2006. ............................................................................................ 91
Quadro 20 Pontuaes de nvel de capacidade - Fonte: Adaptado de ISO/IEC,
2006. ................................................................................................................ 92
Quadro 21 Processos associados aos nveis de maturidade ........................... 96
ndice de Tabelas
Tabela 1 Caractersticas dos paradigmas de avaliao - Fonte: PREECE;
ROGERS; SHARP; 2005.................................................................................. 41
Tabela 2 Relao entre paradigmas e tcnicas de avaliao - Fonte: PREECE;
ROGERS; SHARP; 2005.................................................................................. 42
Tabela 3 Processos do Modelo e suas prticas bases - Fonte: adaptado de
ISO/TR 18529, 2000. ....................................................................................... 57
Tabela 4 Processos do Modelo de Referencia Proposto com Extenso para
Engenharia de Usabilidade .............................................................................. 82
Tabela 5 Mapeamento dos processos e prticas unificadas em relao aos
processos das ISO/IEC 15504 e ISO/IEC 12207 ............................................. 85
Tabela 6 Nveis de Maturidade - Fonte: Adaptado de ISO/IEC, 2008. .............. 92
Tabela 7 Perguntas da avaliao ................................................................... 103
Tabela 8 Questes descritivas da avaliao .................................................. 104
Lista de Siglas e Abreviaturas

ABES - Associao Brasileira de Empresas de Software
ABNT - Associao Brasileira de Normas Tcnicas
BID - Banco Interamericano de Desenvolvimento
CMM - Capability Maturity Model
CMMI Capability Maturity Model Integration
FINEP - Financiadora de Estudos e Projetos
HCD - Human-Centred Development
EU Engenharia de Usabilidade
ES Engenharia de Software
IBSS - Indstria Brasileira de Software e Servios de TI
IEC International Engineering Consortium
IEEE Institute of Electrical and Electronic Engineers
IHC - Interao Homem-Computador
ISO International Organizational for Standardization
MCT Ministrio da Cincia e Tecnologia
MPS.BR Melhoria de Processo do Software Brasileiro
NBR Norma Brasileira
SEBRAE - Servio Brasileiro de Apoio s Micro e Pequenas Empresas
SEI Software Engineering Institute
SOFTEX Associao para Promoo da Excelncia do Software Brasileiro
SPCMM - Software Process Capability/Maturity Model
SPICE - Software Process Improvement and Capability Determintation
UCD - User-Centered Design
WiMax - Worldwide Interoperability for Microwave Access
Resumo
Contexto
O mercado brasileiro de desenvolvimento de software encontra-se em
franca expanso. Usabilidade um requisito necessrio para que se considere
um
software
com
qualidade,
porm
os
principais
modelos
de
maturidade/capacidade de processo de software no abordam esta questo.

Objetivo
O objetivo deste trabalho propor a extenso de um modelo de
maturidade/capacidade de processo de software integrando processos de
engenharia
de
usabilidade,
tornando-o
voltado
para
cenrio
de
convergncia/divergncia digital.
Metodologia
Para
realizao
do
trabalho,
primeiramente,
foi
feito
uma
fundamentao terica e uma anlise do estado da arte em relao aos

principais modelos de maturidade/capacidade de processo de software, dos
conceitos e do processo da Engenharia de Usabilidade e sobre os principais
conceitos sobre a convergncia/divergncia digital. Em seguida, com base na
anlise feita na reviso do estado da arte, foi proposta uma integrao de
processos voltados engenharia de usabilidade em um modelo de
maturidade/capacidade de processo de software (ISO/IEC 12207/15504). Ao
final, o modelo proposto ser avaliado atravs de um expert panel.
Resultados
Espera-se que o modelo proposto contribua para as organizaes que
desejam avaliar / melhorar seus processos de software e de usabilidade,
servindo como um guia de melhores prticas para orient-las. Principalmente
no cenrio da convergncia/divergncia digital, espera-se que a integrao de
aspectos
da
engenharia
de
usabilidade
em
um
SPCMM
contribua
positivamente na melhoria de processos de software e, consequentemente, na

melhoria de produtos de software em termos da usabilidade.
10
1. Introduo
1.1 Contextualizao
O setor de desenvolvimento de software brasileiro encontra-se em franca

expanso. Segundo a Associao Brasileira de Empresas de Software (ABES),
o setor atingiu a marca de 21,4 bilhes de dlares em 2011, um aumento de
12,4% em relao a 2010, e a indstria nacional passou da 11 para a 10
posio no ranking internacional do mercado.
De acordo com a Indstria Brasileira de Software e Servios de TI (IBSS),
a maioria destas, so empresas de pequeno porte. Essas empresas tem na
sua maioria uma gesto de fora tarefa reativa para resoluo de problemas,
causando atrasos nas entregas e problemas de qualidade nos sistemas de
software desenvolvidos (BORGES, 2009) (MCT, 2009) (THE STANDISH
GROUP, 2009). Isso demonstra, atualmente, uma imaturidade do processo de
software tpico nas empresas da rea.
Mesmo com o aumento da importncia do setor, o nmero de empresas
de software no Brasil que obteve uma avaliao oficial referente a um modelo
de maturidade/capacidade de processo de software (Software Process
Capability/Maturity Model SPCMM), alinhado ao modelo CMMI (SEI, 2010) ou
MPS.BR (SOFTEX, 2011) por exemplo, est ainda relativamente baixo (MCT,
2009).
A qualidade de software est ligada a dois pontos de vista distintos. A
qualidade do produto, aonde este deve apresentar certas caractersticas
desejveis, perceptveis ou no pelo usurio. E a qualidade do processo de
software, que o conjunto de atividades, mtodos, prticas e transformaes
utilizadas para desenvolver e manter um sistema de software e seus produtos
relacionados (plano de projeto, documentos de design, cdigo, casos de teste,
manuais de usurio, etc.) (IEEE Standards Board, 1990).
Ento, considerando-se que o objetivo final a qualidade do produto,
acredita-se que ela ser atingida atravs de um processo de software com
qualidade. Um produto sem um processo de software sistemtico adequado s
ter qualidade com sorte (Silva, 2010).
11
Por isso, atualmente, adota-se SPCMMs para orientar a avaliao e a

melhoria do processo de software, como por exemplo, os modelos CMMI,
ISO/IEC 15504 (ISO/IEC, 2003), ou MPS.BR. Tais modelos tm como objetivo
determinar a situao atual de um processo e/ou organizao, com base nisso
priorizar aes de melhoria e monitorar e controlar o impacto dessas aes.
Estes modelos descrevem aes recomendadas baseadas em boas
prticas de processos de software. Os modelos em questo apresentam uma
sequncia de nveis de maturidade/capacidade que representam uma evoluo
no nvel de amadurecimento do processo/organizao. O nvel mais baixo
representa um estado inicial com baixa maturidade/capacidade, seguindo um
caminho
de
melhoria
at
atingir
um
estgio
mais
elevado
de
maturidade/capacidade.
Tipicamente, estes SPCMMs abrangem o processo de software em geral.
Por exemplo, a norma ISO/IEC 15504, para avaliao do processo de software,
prope o uso o da norma ISO/IEC 12207 (ISO/IEC, 2008) como um modelo de
referncia para o processo de software. A ISO/IEC 12207 define um ciclo de
vida de software alto-nvel, desde a sua concepo como projeto at sua
descontinuidade, como mostra a figura 1.
Figura 1 Processos do ciclo de vida de software Fonte: Adaptado de ISO/IEC 12207, 2008.
12
Um dos requisitos observado para que se considere um software com

qualidade a usabilidade (NBR ISO/IEC 9126-1, 2003). Usabilidade a
medida na qual um produto pode ser usado por usurios especficos para
alcanar objetivos especficos com eficcia, eficincia e satisfao em um
contexto especfico de uso (NBR ISO 9241-11, 2011).
Sistemas com usabilidade pobre podem fazer com que os usurios no
consigam realizar suas tarefas como desejam, deixando-os frustrados. Em
algumas situaes, os efeitos de um sistema com usabilidade pobre pode
causar prejuzos at para a vida dos usurios ou dos envolvidos (KOPPEL et
al., 2005).
Sabe-se tambm que um bom projeto de interface de software pode
aumentar os ganhos, diminuir o suporte, ampliar a competitividade e
potencializar a satisfao e a produtividade dos usurios.
Porm, analisando os SPCMMs genricos como o CMMI, a ISO/IEC
15504, a ISO/IEC 12207 e o MPS.BR, percebe-se que estes no abordam a
engenharia de usabilidade (JOKELLA et al., 2006). Uma reviso sistemtica da
literatura levantando os atuais SPCMMs, tambm no identificou modelos
voltados especificamente para este foco (WANGENHEIM et al., 2010).
A mesma observao tambm pode ser obtida em outros guias de
conhecimento na rea de engenharia de software, como o SWEBOK
(SWEBOK, 2004), que no considera engenharia de usabilidade como parte da
engenharia de software, mas somente como uma disciplina relacionada ao
processo de desenvolvimento.
Na prtica, porm, o grande nmero de problemas de qualidade
relacionados usabilidade, demonstra a importncia da integrao da
engenharia de usabilidade no processo de software. E essa importncia cresce
ainda mais no cenrio atual da convergncia digital, que a tendncia em
unificar vrias funcionalidades/produtos/servios de tecnologia numa s
plataforma ou produto para simplificar a vida do usurio (MURPHY et al.,
2005).
Em relao a isso se criou tambm a necessidade da divergncia de
aplicaes, precisando adaptar uma aplicao de software existente para
diferentes dispositivos, por exemplo, migrando uma aplicao web para rodar
no celular e/ou TV Digital.
13
Dentro
deste
contexto,
uma
das
principais
dificuldades
no
desenvolvimento de software so o projeto e o design de interface com boa

usabilidade, para as diversas verses do sistema que sero utilizadas por
dispositivos diferentes.
1.2 Problema
O desenvolvimento ou adaptao de sistemas de software neste cenrio
da convergncia/divergncia digital demonstra a grande importncia da
engenharia de usabilidade, j que um dos principais aspectos a ser adaptado
o design de interface para diversos dispositivos. Assim, a importncia da
engenharia da usabilidade e a sua necessidade de ser executada de forma
madura e integrada ao processo de engenharia de software aumenta.
Os principais SPCMMs no abordam esta questo, portanto, no
fornecem
um
suporte
para
que
as
organizaes
possam
melhorar
sistematicamente o seu processo de software na parte da engenharia de

usabilidade.
Por outro lado, existem modelos e normas especficas para a engenharia
de usabilidade (JOKELLA et al., 2006) como, por exemplo, a NBR ISO 9241
(ABNT, 2011) e a ISO 13407 (ISO, 1999). Porm, no h integrao entre os
SPCMMs e aqueles que focam na engenharia de usabilidade, o que pode ser
considerando inadequado j que ambos os processos deveriam ocorrer
integrados e, consequentemente, fazerem parte dos SPCMMs.
1.3 Objetivos
1.3.1 Objetivo Geral
O objetivo deste trabalho propor a extenso de um modelo de
maturidade/capacidade de processo de software integrando processos de
engenharia
de
usabilidade,
tornando-o
voltado
para
cenrio
de
1.3.2 Objetivos Especficos
Os objetivos especficos desse trabalho so:
14
O1. Analisar o processo de software no cenrio da convergncia/divergncia

digital, principalmente no que tange a parte da engenharia de usabilidade e a
teoria de modelos de maturidade/capacidade de processo de software.
O2. Analisar o estado da arte dos modelos de maturidade/capacidade de

processo de software voltado ao cenrio de convergncia/divergncia digital
com foco na abrangncia da engenharia de usabilidade.
O3. Desenvolver uma integrao de engenharia de usabilidade em um modelo

de maturidade/capacidade de processo de software voltado ao cenrio de
O4. Avaliar este modelo de maturidade/capacidade de processo de software

voltado ao cenrio de convergncia/divergncia digital.
1.4 Metodologia
O presente trabalho ser realizado em quatro etapas:
Etapa 1. Fundamentao terica: Ser realizado um estudo na rea de

engenharia
de
software
em
relao
aos
principais
modelos
de
maturidade/capacidade de processo de software. Posteriormente, ser feito um

estudo sobre os principais conceitos sobre a convergncia/divergncia digital.
Por fim, ser feita uma anlise dos conceitos e do processo da Engenharia de
Usabilidade. As atividades desta etapa sero:
A1.1 Fundamentar a teoria dos modelos de maturidade/capacidade de
processo de software
A1.2 Fundamentar os conceitos sobre a convergncia/divergncia digital
A1.3 Fundamentar os conceitos e o processo da engenharia de
usabilidade
Etapa 2. Reviso do estado de arte: Ser feita uma reviso sistemtica, com
a
finalidade
de
comparar
identificar
os
principais
modelos
de
maturidade/capacidade de processo de software, e analisar a incluso de

15
processos ligados engenharia de usabilidade nesses modelos. Sero

tambm identificados e analisados modelos de maturidade/capacidade voltado
explicitamente para a engenharia de usabilidade. As atividades desta etapa
sero:
A2.1 Definio do estudo
A2.2 Execuo do estudo
A2.3 Extrao e anlise da informao
Etapa 3. Concepo e desenvolvimento do modelo: Com base na anlise

feita na reviso do estado da arte, ser proposta uma integrao de processos
voltados
engenharia
de
usabilidade
em
um
modelo
de
maturidade/capacidade de processo de software (ISO/IEC 12207/15504),

levando-se em considerao caractersticas especficas do cenrio da
convergncia/divergncia digital. As atividades desta etapa sero:
A3.1 Mapeamento/Unificao dos modelos existentes
A3.2 Anlise de processos/prticas relevantes no cenrio da engenharia
de usabilidade na convergncia digital.
A3.3
Incluso
dos
processos
definidos
em
um
modelo
de
maturidade/capacidade de processo de software (ISO/IEC 12207).
Etapa 4. Avaliao: O modelo proposto ser avaliado em relao aos

aspectos de qualidade da integrao proposta atravs de um Expert Panel, que
uma tcnica baseada na opinio de especialistas (BEECHAM et al., 2005).
A4.1 Definio da avaliao
A4.2 Planejamento da avaliao
A4.3 Execuo da avaliao
A4.4 Anlise dos dados
1.5. Estrutura do trabalho
O presente trabalho estruturado em 6 sees. A seo 2 relata sobre
todos os conceitos necessrios para o devido entendimento deste trabalho. Na
seo 3 realizada uma anlise do estado da arte buscando encontrar e
conhecer trabalhos com o mesmo objetivo. A seo 4 apresenta o SPCMM
estendido, objetivo do trabalho. Na seo 5 feita a avaliao da integrao
16
realizada e na seo 6 faz-se uma concluso e apresentam-se possveis

trabalhos futuros.
17
2. Fundamentao Terica
2.1 Modelos de Maturidade/Capacidade de Processo de Software
2.1.1 Definio
Um SPCMM um framework com as melhores prticas de
desenvolvimento de software e customizado para atender necessidades
especficas de qualidade para o domnio aonde ser utilizado (HAUCK, 2011).
Melhores prticas so o agrupamento de experincias que obtiveram
sucesso
que,
quando
repetidas,
atingem
resultados
semelhantes
(GOODMAN; GOLDMAN, 2007).

Podem-se considerar os SPCMMs como frameworks de melhores
prticas, pois estes agregam, sobre diferentes formas e estruturas, uma grande
quantidade de conhecimento sobre as melhores prticas em um formato que
permita sua reutilizao (WANGENHEIM et al., 2010).
Um modelo uma representao simplificada do mundo real. Os
SPCMMs contm os elementos essenciais de processos eficientes para uma
ou mais reas de conhecimento. Estes elementos se baseiam nos conceitos
desenvolvidos por Crosby, Deming, Juran e Humphrey (SEI, 2010).
Processo um ponto de apoio de melhoria sustentada de uma
organizao (SEI, 2010). Um processo de software consiste em atividades,
mtodos e prticas teis no desenvolvimento de um produto de software. As
atividades associadas a esse processo de software incluem a descrio e
preparao de esquemas que identifiquem a estrutura dos dados e elementos
de controle de um sistema, codificao, verificao e implantao do software.
(HUMPHREY, 1989).
O objetivo dos SPCMMs fornecer direcionamentos para melhorar os
processos
de
uma
organizao
sua
capacidade
de
gerenciar
desenvolvimento, aquisio e manuteno de produtos e servios (SEI, 2010).

Um SPCMM pode ser utilizado por uma organizao para ajudar a
definir os objetivos e prioridades de melhoria de processos e fornecer
direcionamento para assegurar processos estveis, capacitados e maduros
(SEI, 2010).
18
Na prtica, um SPCMM encoraja a organizao a manter um

aprimoramento contnuo do processo de software. A atual competio acirrada
no mercado de produtos e ferramentas de software induz as organizaes a
utilizarem padres. E com esta padronizao, tornou-se possvel medir
tamanho, contedo, valor ou qualidade de uma organizao de software
(BORGES, 2009; SEI, 2010).
2.1.2 Estrutura
Os SPCMMs, como o prprio nome j define, so estruturados na forma
de maturidade e/ou capacidade de processo de software (HAUCK, 2011). O
termo maturidade/capacidade de processo de software foi proposto por
Salviano & Figueiredo (2008) e completado em Wangenheim et al. (2010).
Software Process Capability/Maturity Models so modelos que
descrevem as melhores prticas para processos de ciclo de
vida do software, baseadas em bons princpios de engenharia
e gerenciamento de processos, e conjuntos atributo-processo
para aspectos de design de capacidade/maturidade.
(Wangenheim et al., 2010).
Eles possuem aspectos de maturidade/capacidade de processos que

auxiliam a atingir os aspectos de qualidade de determinado domnio. Assim, ao
focar na melhoria da qualidade de processo, os mesmos objetivam em ltima
instncia melhorar a qualidade do produto (SEI, 2010).
Os SPCMMs possuem diversas caractersticas, porm, Lahrmann &
Marx (2010) propem uma forma de classific-los de acordo com a sua
estrutura. Nesta classificao eles devem ser Multidimensionais; possurem
representao contnua, por estgios ou ambas; atenderem a audincias
nicas ou mltiplas e apresentarem avaliao qualitativa ou quantitativa.
Assim, possvel afirmar que os SPCMMs so as normas e modelos de
referncia que possuam ao menos duas dimenses: Dimenso de Processos e
a Dimenso de Maturidade/Capacidade (HAUCK, 2011).
A dimenso de maturidade/capacidade define os critrios que indicam a
capacidade que um processo, ou uma organizao, possui de alcanar seus
objetivos, estando relacionada com o atendimento aos atributos de processo
associados aos processos de cada nvel (SOFTEX, 2011; ISO/IEC, 2006).
19
A dimenso do processo define um conjunto de entidades que

descrevem o processo do ciclo de vida e prticas com base na boa engenharia
e princpios de gesto do processo. A norma ISO/IEC 15504-2 define os
requisitos mnimos de um modelo de referncia de processo, indicando que,
para cada processo, devem ser definidos: uma declarao de propsito e os
resultados de sua execuo (ISO/IEC, 2003).
2.1.3 Principais Modelos de Maturidade Capacidade de Processo de
Software
Existem diversos SPCMMs, alguns para domnios especficos e outros
mais genricos. Neste trabalho, ser feita uma descrio geral dos principais
modelos, ISO/IEC 15504, a ISO/IEC 12207, o CMMI e o MPS.BR.
ISO/IEC 15504
A ISO/IEC 15504 teve o incio da sua composio em 1993 pelo projeto
SPICE (Software Process Improvement and Capability Determintation), por isto,
ela tambm ficou conhecida pelo nome do projeto.
Ela uma norma internacional e tem como objetivos: (a) melhoria dos
processos, gerando um perfil dos processos, identificando os pontos fracos e
fortes que sero utilizados para a elaborao de um plano de melhorias; (b)
determinao da capacidade dos processos, viabilizando a avaliao de um
fornecedor em potencial (ISO/IEC, 2003).
A ISO/IEC 15504 tambm fornece um modelo de referncia para
avaliaes e possu as duas dimenses necessrias para ser considerada
como
um
SPCMM:
dimenso
de
processo
dimenso
de
maturidade/capacidade, como mostra a figura 2:
20
Figura 2 Dimenses da ISO/IEC 15504 - Fonte: ISO/IEC, 2006.
Esta norma estabelece uma abordagem contnua na avaliao de

processos de software. Este tipo de abordagem permite que a organizao
escolha as reas de processo que melhor atendam seus objetivos especficos
de negcio. Assim, na ISO/IEC 15504 cada processo pode ser avaliado
individualmente quanto a sua capacidade, por meio da determinao de um
modelo e das caractersticas de um mtodo de avaliao de processos de
software (ISO/IEC, 2006).
O quadro 1 apresenta os nveis de capacidade da ISO/IEC 15504:
Quadro 1 Nveis de Capacidade da ISO/IEC 15504 - Fonte: Adaptado de ISO/IEC, 2006.
Nveis de
Nveis de
Caractersticas dos Processos
Capacidade
Capacidade do
modelo contnuo
0
Incompleto
O processo no executado nem consegue alcanar a
sua finalidade.
1
Executado
O processo executado e consegue alcanar sua

finalidade.
Gerenciado
Estabelecido
Previsvel
O processo executado de uma forma controlada e seus

produtos de trabalho so estabelecidos, controlados e
mantidos.
O processo controlado executado utilizando um
processo definido, baseado em um processo padro, que
seja capaz de alcanar os resultados esperados.
O processo estabelecido opera agora dentro dos limites
definidos para conseguir seus resultados esperados.
Otimizao
O processo previsvel melhorado continuamente para

alcanar os objetivos de negcio.
A norma tambm possibilita determinar se uma organizao implementa

de forma consistente os seus processos em um escopo definido, ou seja,
21
avaliando a sua maturidade organizacional (lSO/IEC, 2008). Isto estabelece

uma escala que caracteriza a maturidade da organizao no mbito do modelo
de maturidade organizacional utilizado, onde cada nvel tem como base o
cumprimento do nvel anterior (ISO/IEC, 2008). A parte sete da norma
estabelece como exemplo os seguintes nveis de maturidade (quadro 2):
Quadro 2 Nveis de Maturidade da ISO/IEC 15504 - Fonte: Adaptado de ISO/IEC, 2008.
Nveis de
Nveis de Maturidade
Maturidade
do modelo em
estgios
0
Imaturo
A organizao no demonstra a aplicao eficaz dos
processos.
1
Bsico
A organizao demonstra que atinge os objetivos dos

processos.
Gerenciado
A organizao demonstra que consegue gerenciar os

processos.
Estabelecido
A organizao demonstra a efetiva definio e

implantao dos processos.
Previsvel
A organizao demonstra
quantitativa dos processos.
Inovao
A organizao demonstra a habilidade de mudar e

adaptar-se ao desempenho dos processos.
uma
compreenso
J na dimenso de processo, a parte dois da norma define os requisitos

mnimos de um modelo de referncia a ser utilizado. Na parte cinco, a norma
estabelece um modelo de referncia exemplar baseado na ISO/IEC 12207 e 48
processos. Na parte sete, a norma estabelece mais dois processos, totalizando
50 processos divididos em trs categorias (ISO/IEC, 2008). A figura 3 mostra
as categorias e seus processos.
22
Figura 3 Processos da ISO/IEC 15504-7 Fonte: Adaptado de ISO/IEC, 2008.
Os processos primrios de ciclo de vida so aqueles que esto mais

diretamente ligados ao desenvolvimento do produto de software. Eles so
divididos em quatro subgrupos: processos de aquisio, de fornecimento, de
engenharia e de operao.
Os processos de suporte fornecem amparo aos processos primrios de
ciclo de vida. (ISO/IEC, 2008).
Os processos de ciclo de vida organizacional so responsveis em
prover os recursos para a realizao dos demais processos e so divididos em
cinco subgrupos: de gerncia, de melhoria de processos, de recursos e
infraestrutura, de reuso e o de gerncia quantitativa (ISO/IEC, 2008).
ISO/IEC 12207
23
A norma ISO/IEC 12207 estabelece uma estrutura comum para os

processos do ciclo de vida de software que pode ser referenciada pela
indstria. Esta estrutura contm processos, atividades e tarefas que devem ser
usados para a aquisio, fornecimento, desenvolvimento, operao e
manuteno de produtos de software (ISO/IEC, 2008).
Estes atributos foram criados para serem adaptados de acordo com as
caractersticas especficas do contexto aonde ser utilizada a norma. O anexo
A da norma contm um processo especfico para auxiliar nesta adaptao dos
atributos (ISO/IEC, 2008).
Tal norma foi publicada em 1995 e atualizada nos anos de 2002 e 2004,
atravs das emendas 1 e 2, respectivamente. Estas emendas criaram novos
processos, definindo suas atividades e tarefas, e expandiram o escopo de
outros ao inserirem para cada processo o seu propsito e resultados (SOFTEX,
2011).
Estas modificaes representam a evoluo da Engenharia de Software,
as necessidades evidenciadas pelos usurios da norma e a compatibilizao
com a ISO/IEC 15504. Em 2008, ela foi reformulada, incluindo as alteraes
das emendas 1 e 2, harmonizada com a ISO/IEC 15288 e publicada como
padro IEEE (SOFTEX, 2011).
O modelo de referncia da norma descreve os propsitos, os resultados
esperados e a relao entre os processos. Tambm define as atividades e
tarefas necessrias para implementar em alto nvel os processos (ISO/IEC,
2008).
A norma possui dois grupos de processos, os processos contextuais de
sistema e os especficos de software. Os processos contextuais de sistema
fornecem subsdios para lidar com um produto de software ou servio ou um
sistema de software independente. Este grupo de processos dividido em
outros quatros subgrupos: Processos Contratuais, Processos Organizacionais
Capacitadores de Projetos, Processos de Projetos e os Processos Tcnicos
(ISO/IEC, 2008).
O grupo de processos especficos de software utilizado na
implementao de um produto ou servio de software que elemento de um
sistema maior. Ele dividido em trs subgrupos: Processos de Implementao
de Software, Processos de Apoio ao Software e Processos de Reuso de
24
Software (ISO/IEC, 2008).

A figura 4 demostra os processos da ISO/IEC 12207:
O quadro 3 apresenta a descrio de um processo da norma:

Quadro 3 Exemplo de Processo ISO/IEC 12207 - Fonte: ISO/IEC 12207, 2008.
Processo de Construo de Software
O objetivo do processo de construo de software produzir unidades de software que
atendam o projeto de software. Os resultados esperados da implementao deste processo so
(ISO/IEC 12207, 2008):
Definio de critrios de verificao das unidades de software com base em seus
requisitos;
Produo das unidades de software definidas no projeto;
Estabelecer rastreabilidade e consistncia entre as unidades de software,
requisitos e projetos;
Verificar as unidades de software com base nos seus requisitos e no projeto;
A atividade aplicvel a este processo a construo de software e as suas tarefas so:
desenvolver e documentar cada unidade de software, banco de dados; procedimentos e dados
para testes; testar cada unidade; e avaliar o cdigo de software e resultados de testes (ISO/IEC
12207, 2008).
25
CMMI
O Capability Maturity Model Integration (CMMI) foi criado pelo Software

Engineering Institute (SEI) da Universidade de Carnegie Mellon e o MITRE
Corporation em meados de 1986. Inicialmente, era um framework de
desenvolvimento de processos chamado de Capability Maturity Model (CMM),
baseado nas prticas adotadas por empresas privadas e governamentais em
destaque na poca (BORGES, 2009).
Ao longo do desenvolvimento do CMM, vrias verses com conceitos
das melhores prticas de gesto de processos surgiram. Para cada setor de
trabalho com necessidades especficas surgiu um modelo, como por exemplo,
o Capability Maturity Model for Software (SW-CMM) que descreve padres de
processo especficos para desenvolvimento de software (BORGES, 2009).
Embora estes modelos tenham sido teis para muitas organizaes, o
uso de diversos modelos tornou-se um problema. Por no serem desenvolvidos
de forma integrada, por apresentarem diferenas na arquitetura, no contedo e
na abordagem, os custos em treinamento, avaliaes e atividades de melhoria
aumentaram muito (BERTOLLO, 2006).
Com objetivo de resolver estes problemas e criar um sistema nico de
avaliao de empresas para a certificao, a SEI adotou a estratgia de
compatibilizar os modelos SW-CMM, o Electronic Industries Alliance Interim
Standard (EIA/IS) e o Integrated Product Development Capability Maturity
Model (IPD-CMM) com a norma ISO/IEC 15504, surgindo ento integrao
dos CMMs, o CMMI (HEIDRICH, 2005).
O CMMI estruturado em termos de reas de processo que so prticas
relacionadas e quando unidas satisfazem determinados objetivos. Um objetivo
genrico descreve o impulso necessrio para se atingir um nvel de capacidade
(modelo contnuo) ou de maturidade (modelo em estgios). Cada objetivo
genrico associado a um conjunto de prticas genricas que descrevem
atividades necessrias para a institucionalizao de processos em uma
determinada rea (SEI, 2010).
Cada rea de processo tambm contm objetivos e prticas que
possuem atividades essenciais para atingir os objetivos especficos. O CMMI
apresenta duas representaes diferentes de melhoria de processos, a
26
representao em estgios e representao contnua (SEI, 2010).

A representao em estgios estabelece um caminho de maturidade em
nveis, do inicial ao otimizado, onde o nvel imediatamente inferior utilizado
como condio para se atingir um nvel acima. Esta representao oferece uma
forma sistemtica e estruturada para abordar a melhoria de processo. Esta
representao a melhor escolha quando no se sabe por onde comear, pois
fornece um conjunto especfico de processos em cada nvel (SEI, 2010).
A representao contnua apresenta uma maior flexibilidade para a
melhoria de processos. Uma organizao pode definir um processo
problemtico isolado, ou determinar uma rea de processos, que esteja
diretamente alinhado aos objetivos estratgicos da organizao para focar
diretamente na melhoria destes. Esta representao deve ser adotada por
organizaes que conhecem os processos que devem ser melhorados e se as
dependncias entre as reas de processos so compreendidas (SEI, 2010).
A representao contnua possui nveis de capacidade para medir a
melhoria de processo, enquanto a representao em estgios utiliza nveis de
maturidade (SEI, 2010).
Os nveis de capacidade buscam a satisfao da melhoria de processos
de uma organizao. Eles visam melhorar de forma incremental os processos
correspondentes a uma determinada rea. Existem quatro nveis de
capacidade, onde cada um corresponde a uma meta genrica e a um conjunto
de prticas genricas e especficas (SEI, 2010).
O quadro 4 apresenta os nveis de capacidade do CMMI.
Quadro 4 Nveis de Capacidade do CMMI - Fonte: Adaptado de SEI, 2010.
Nveis de
Nveis de
Capacidade
Capacidade do
modelo contnuo
0
Incompleto
Um processo no executado ou executado
parcialmente.
1
Executado
Um processo satisfaz a metas especficas da rea de
processo.
2
Gerenciado
Um processo executado por pessoas qualificadas de
acordo com uma poltica, com recursos suficientes para
produzir sadas controladas.
3
Definido
Um processo que estabelece claramente os objetivos, as
entradas, as atividades, os papis, as medidas, etapas de
verificao, as sadas e os critrios de sada.
Os nveis de maturidade aplicam-se maturidade geral de uma

organizao. Eles so compostos por prticas especficas e genricas
27
relacionadas a um conjunto predefinido de reas de processo que melhoram o

desempenho geral da organizao. Existem cinco nveis de maturidade e cada
um uma camada que representa a base para as atividades de melhoria
contnua de processo (SEI, 2010).
O quadro 5 apresenta os nveis de maturidade do CMMI.
Quadro 5 Nveis de Maturidade do CMMI - Fonte: Adaptado de SEI, 2010.
Nveis de
Nveis de Maturidade
Maturidade
do modelo em
estgios
1
Inicial
Os processos so caticos.
2
Gerenciado
Os processos so planejados e executados por
pessoas qualificadas de acordo com uma poltica.
3
Definido
Os processos so bem caracterizados, entendidos e
gerenciados pr ativamente.
4
Gerenciado
Os processos so previsveis quantitativamente
Quantitativamente
atravs do controle de seu desempenho por meio de
tcnicas estatsticas e quantitativas.
5
Em Otimizao
Os processos so revisados continuamente por meio
de melhorias incrementais e inovadoras de processo
e de tecnologia.
O CMMI pode ter seus componentes agrupados em trs categorias:

requeridos, esperados e informativos (SEI, 2010), como mostra a figura 5:
Figura 5 Componentes do CMMI Fonte: SEI, 2010.
Os componentes requeridos demonstram o que a organizao deve

28
fazer para implementar uma rea de processo. Os componentes esperados

orientam o que uma organizao pode implementar para satisfazer um
componente requerido e os informativos auxiliam as organizaes na
implementao dos componentes requeridos e esperados (SEI, 2010).
O quadro 6 descreve uma rea de processo do CMMI:
Quadro 6 Exemplo de rea de Processo CMMI - Fonte: SEI, 2010.
rea de Processo Soluo Tcnica

A rea de processo Soluo Tcnica pertence ao nvel 3 (Definido) de maturidade do
CMMI e tem como objetivo fornecer auxlio para projetar, desenvolver e implementar solues
para os requisitos.
As prticas especficas desta rea se aplicam ao produto, aos seus componentes e aos
processos de ciclo de vida relacionados ao produto.
Segue abaixo as metas e prticas especficas desta rea de processo (SEI, 2010):
SG 1 Selecionar Solues de Componentes de Produto
SP 1.1 Desenvolver Solues Alternativas e Critrios de Seleo
SP 1.2 Selecionar Solues de Componentes de Produto
SG 2 Desenvolver Design
SP 2.1 Desenvolver o Design do Produto ou dos Componentes de Produto
SP 2.2 Estabelecer Pacote de Dados Tcnicos
SP 2.3 Projetar Interfaces Utilizando Critrios
SP 2.4 Analisar Alternativas: Desenvolver, Comprar ou Reusar
SG 3 Implementar Design do Produto
SP 3.1 Implementar Design
SP 3.2 Elaborar Documentao de Suporte ao Produto
MPS.BR
O modelo de Melhoria de Processo do Software Brasileiro (MPS.BR)
um programa mobilizador criado em dezembro de 2003 pela Associao para
Promoo da Excelncia do Software Brasileiro (SOFTEX), com apoio do
Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos
(FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas
(SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O objetivo do
MPS.BR a Melhoria de Processo do Software Brasileiro (SOFTEX, 2011).
O modelo baseia-se nos conceitos de maturidade e capacidade de
processo para a avaliao e melhoria da qualidade do produto de software e
servios correlatos. O modelo MPS dividido em trs componentes (Figura 6):
Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de
Negcio (MN-MPS) (SOFTEX, 2011).
29
Figura 6 Componentes do MPS.BR Fonte: SOFTEX, 2011.
As normas ISO/IEC 12207 e ISO/IEC 15504 foram utilizadas como base

tcnica para a construo e aprimoramento do modelo e o MR-MPS foi definido
de acordo com o CMMI (SOFTEX, 2011).
Os nveis de maturidade do MPS.BR so definidos como uma juno
entre processos e capacidade de processos. Os nveis so caracterizados por
estgios de melhoria de implementao de processos. O MR-MPS estabelece
sete nveis de maturidade (SOFTEX, 2011):
A (Em Otimizao);
B (Gerenciado Quantitativamente);
C (Definido);
D (Largamente Definido);
E (Parcialmente Definido);
F (Gerenciado);
G (Parcialmente Gerenciado);
A escala de maturidade inicia-se pelo nvel G e progride at o nvel A.

Cada nvel de maturidade possui um perfil e capacidade de processos que
mostra onde a organizao deve se esforar para melhorar e atender os
objetivos de negcio (SOFTEX, 2011).
A capacidade do processo representada por um conjunto de atributos
de processo descritos em termos de resultados esperados. O MR-MPS
descreve que, a cada nvel de maturidade que a organizao alcana, um
30
maior nvel de capacidade para desempenhar o processo deve ser atingido

(SOFTEX, 2011).
Os nveis so acumulativos, se a organizao est no nvel F, ela possui
o nvel de capacidade do nvel F, que inclui os atributos de processo dos nveis
G e F para todos os processos do nvel F, ou seja, ao passar do nvel G para o
F, os processos do nvel G de maturidade, devem ser executados no nvel de
capacidade F (SOFTEX, 2011).
O MPS.BR possui nove atributos de processos: AP 1.1 O processo
executado; AP 2.1 O processo gerenciado; AP 2.2 Os produtos de trabalho
do processo so gerenciados; AP 3.1. O processo definido; AP 3.2 O
processo est implementado; AP 4.1 O processo medido; AP 4.2 O processo
controlado e AP 5.1 O processo objeto de melhorias e inovaes; AP 5.2 O
processo otimizado continuamente (SOFTEX, 2011). O quadro 7 apresenta
os nveis de maturidade do MR-MPS, os processos e os atributos de processo
correspondentes a cada nvel (SOFTEX, 2011).
Quadro 7 Nveis de maturidade do MR-MPS - Fonte: SOFTEX, 2011.
31
Os processos do MR-MPS so descritos em termos de propsitos e

resultados esperados. O propsito estabelece o objetivo a ser atingindo e os
resultados esperados descrevem os resultados que devem ser obtidos com a
implementao do processo (SOFTEX, 2011).
O quadro 8 descreve um processo do MPS.BR:
Quadro 8 Exemplo de Processo MPS-BR - Fonte: SOFTEX, 2011.
Processo de Projeto e Construo do Produto
O processo de Projeto e Construo do Produto PCP pertence ao nvel D (Largamente
Definido) do MR-MPS, portanto os atributos de processo AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
devem ser alcanados. O PCP possui o propsito de projetar, desenvolver e implementar as
solues para atender os requisitos (SOFTEX, 2011).
O MR-MPS define os oito resultados esperados que esto abaixo para o PCP (SOFTEX,
2011):
PCP 1. Alternativas de soluo e critrios de seleo so desenvolvidas para atender aos
requisitos definidos de produto e componentes de produto;
PCP 2. Solues so selecionadas para o produto ou componentes do produto, com base em
cenrios definidos e em critrios identificados;
PCP 3. O produto e/ou componente do produto projetado e documentado;
PCP 4. As interfaces entre os componentes do produto so projetadas com base em critrios
predefinidos;
PCP 5. Uma anlise dos componentes do produto conduzida para decidir sobre sua construo,
compra ou reutilizao;
PCP 6. Os componentes do produto so implementados e verificados de acordo com o que foi
projetado;
PCP 7. A documentao identificada, desenvolvida e disponibilizada de acordo com os padres
estabelecidos;
PCP 8. A documentao mantida de acordo com os critrios definidos.
2.2 Convergncia/Divergncia Digital
O grande avano tecnolgico que vivenciamos, mudou drasticamente a

forma como lidamos com a Informao. O surgimento de diversos dispositivos
mveis, como tablets, TVs digitais e outros, oferecem uma grande quantidade
de opes para a disseminao de contedo digital. Hoje podemos fazer
ligaes de notebooks, interagimos com diversos programas em TVs digitais,
lemos jornais em iPads, entre outras coisas (PAGANI, 2007).
32
Neste
contexto,
convergncia
digital
busca
unificar
vrias
funcionalidades/produtos/servios de tecnologia em uma s plataforma ou

produto para simplificar a vida do usurio (MURPHY et al., 2005). Por exemplo,
os celulares passaram a possuir mquinas fotogrficas, tocadores de msicas,
clientes de e-mails entre outras aplicaes, deixando de serem usados apenas
para ligaes. A figura 7 ilustra este cenrio.
Figura 7 Convergncia Digital- Fonte: LIEB, 2010.
Em relao a isso, criou-se tambm a necessidade da divergncia de

aplicativos, precisando adaptar uma aplicao de software existente para
diferentes dispositivos, por exemplo, migrando uma aplicao web para ser
executada no celular e/ou TV Digital.
A figura 8 ilustra este cenrio de
divergncia digital.
Figura 8 Uso do Skype em dispositivos diferentes. Fonte: SKYPE, 2011.
33
De acordo com Baldwin, Mcvoy e Steinfeld (1996), a evoluo da tv digital

interativa, da telefonia celular, da internet, da WiMax e de outras plataformas
de comunicao digital, possibilitou a oferta de grande quantidade de servios
de maneira convergente, transparente e para multi-plataformas. Com isso, os
usurios passaram a acessar contedo digital de qualquer lugar e com
variados dispositivos com a mesma interface ou com interfaces semelhantes.
Porm,
poder
da
convergncia
digital
de
oferecer
novos
produtos/servios criados atravs da unio e integrao de tecnologias, faz

com que o desenvolvimento destes apresente uma complexidade sem
precedentes. A utilizao destas novas funcionalidades/produtos/servios em
diversos tipos de dispositivos faz com que o desenvolvimento de software deixe
de ser realizado para um dispositivo especfico, e passe a ser desenvolvido
para funcionar em mais de um tipo de arquitetura ou em sistemas operacionais
diferentes.
Neste contexto, o design de interface para esses variados tipos de
dispositivos
se
torna
uma
das
caractersticas
mais
importante
no
desenvolvimento, buscando-se sempre evitar problemas de usabilidade para o

usurio. Os principais problemas enfrentados nesta forma de desenvolvimento
so as diferenas dos meios de entradas e sadas, a pequena largura da banda
e os vrios contextos de uso que os dispositivos mveis permitem. Por isso, a
questo de engenharia de usabilidade se torna to importante (KIRDA et al.,
2005).
O quadro 9 apresenta as diferenas dos meios de entradas e sadas dos
dispositivos mais usados.
Dispositivo
Desktop
Notebook
Quadro 9 Meios de entrada e sada de dispositivos.

Tela
Entrada de dados
Tamanho
Resoluo
Maior que
800x600
Teclado numrico
15
1920*1200 pixels
Teclado QWERTY
Teclas direcionais + Boto Ok
Teclas de direita e esquerda
Click-wheel
Joystick isomtrico
Trackball
Tela sensvel ao toque
10.6 a 17
1024x768
Teclado numrico
1920x1200 pixels Teclado QWERTY
Teclas direcionais + Boto Ok
Teclas de direita e esquerda
Click-wheel
Joystick isomtrico
34
Smartphone
2 a 4.5
Feature phone
240x320
1280x800
pixels
96x64
480x320
pixels
Celular com
tela sensvel
ao toque.
3.7 a 4.3
480x800
1024x480 pixels
Tablets
7 14
800x480
1280x800 pixels
1280x720
1920x1080 pixels
iTV
E-readers
5 8
Trackball
tela sensvel ao toque
Teclado numrico,
Teclado QWERTY,
Teclado virtual na tela,
Toque, reconhecimento de voz
Teclado numrico,
Teclado QWERTY,
Toque, reconhecimento
de voz
Teclado numrico,
Teclado QWERTY,
Toque, reconhecimento de voz
Controle remoto:
Teclado numrico
Teclas direcionais + Boto de OK
Teclas coloridas.
800x600 pixels
Porm, mesmo que a convergncia digital esteja cada vez mais presente
no nosso dia-a-dia, ela no amplamente abrangida na Engenharia de
Software. O nmero de pesquisas e estudos para a integrao do design de
interface
em
SPCMMs
baixo.
Isso
gera
muito
problemas
de
interoperabilidade e de usabilidade no cenrio da convergncia digital, pois os

SPCMMs tradicionais so inadequados para resolverem estes problemas.
Novas metodologias e prticas de processo de software devem ser
desenvolvidas para este cenrio (KRONLF, 2008).
2.3 Usabilidade
2.3.1 Interao Homem-Computador
Interao Homem-Computador (IHC) um setor da informtica que busca
compreender os aspectos lingustico-visuais e psicolgicos da interao do
homem com o computador, visando sempre o melhor entendimento destas
relaes (MOREIRA, 2010).
A IHC uma rea direcionada para o projeto, avaliao e
implementao de sistemas computacionais interativos para o uso do ser
humano e com o estudo de seus fenmenos relacionados (ACM SIGCHI Curricula for Human-Computer Interaction, 1996).
35
Esta uma rea multidisciplinar que engloba conhecimentos das

disciplinas: Cincias da Computao, Psicologia Cognitiva, Psicologia Social e
Organizacional,
Ergonomia,
Lingustica,
Inteligncia
Artificial,
Filosofia,
Sociologia e Antropologia, Engenharia e Design (PREECE et al.; 1994).

Ela aborda a forma de se criar projetos de sistemas computacionais que
auxiliem as pessoas a executarem suas atividades com segurana e com
produtividade (ROCHA; BARANAUSKAS, 2000).
A figura 9 demostra o contexto da IHC:
Figura 9 Uso e contexto do IHC Fonte: ACM SIGCHI - Curricula for Human-Computer
Interaction, 1996.
Usabilidade a medida na qual um produto pode ser usado por usurios

especficos para alcanar objetivos especficos com eficcia, eficincia e
satisfao em um contexto especfico de uso. A usabilidade de um objeto pode
ser observada sempre que este possuir alguma forma de interao com o ser
humano (NBR ISO 9241-11, 2011) (Figura 10).
De acordo com a NBR ISO 9241-11 de 2011, eficcia pode ser definida
como a acurcia e completude com que os usurios alcanam objetivos
especficos, ou seja, mede a relao entre os resultados obtidos e os
36
resultados pretendidos. Eficincia so os recursos gastos em relao

acurcia e abrangncia que os usurios atingem os objetivos, em outras
palavras, o tempo gasto para completar uma tarefa. Satisfao ausncia do
desconforto e presena de atitudes positivas para com o uso de um produto, ou
seja, o conforto dos usurios ao utilizar o produto.
Figura 10 Estrutura de usabilidade - Fonte: NBR ISO 9241-11, 2011.
2.3.2 Engenharia de Usabilidade

A engenharia de usabilidade surgiu da necessidade das empresas e
organizaes desenvolverem sistemas interativos com boa usabilidade. Ela
ocupa-se da interface com o usurio. Conhecimentos sobre o sistema cognitivo
humano, sobre princpios e recomendaes ergonmicas e ainda sobre os
mtodos, tcnicas e ferramentas de desenvolvimentos centradas no usurio
constituem o ncleo da engenharia de usabilidade (CYBIS; BETIOL; FAUST;
2007).
A usabilidade deve ser uma considerao importante nos projetos de
produtos, pois ela se refere medida com que os usurios conseguem
trabalhar de modo eficaz, satisfeitos e de forma efetiva. Ela fornece atributos e
caractersticas conhecidas que so capazes de facilitar o trabalho dos usurios
em contextos especficos. A usabilidade tambm fornece um panorama da
complexidade da interao homem-mquina, os objetivos e caractersticas da
tarefa e outros elementos do contexto de uso (NBR ISO 9241-11, 2011).
37
2.3.3 Projeto Centrado no Usurio
Um projeto centrado no usurio (User-Centered Design - UCD) envolve

a aplicao de mtodos de usabilidade essenciais ao desenvolvimento de
produtos e sistemas interativos que atendam as necessidades do usurio
(Figura 11). No UCD, o usurio considerado como elemento chave desde o
incio do projeto (SOUZA; SPINOLA, 2006).
A
norma
NBR
ISO
9241-210
(2011)
descreve
um
ciclo
de
desenvolvimento interativo com ciclos de anlise, sntese e avaliao. Estes

ciclos podem ser repetidos at que se obtenha o resultado esperado. Quando
esta forma de desenvolvimento utilizada desde o incio do projeto, ela reduz
os riscos de falhas e atende melhor s necessidades do usurio.
Figura 11 Projeto Centrado no Usurio - Fonte: Adaptado de NBR ISO 9241-210, 2011.
O UCD um projeto multidisciplinar que engloba caractersticas

humanas, conhecimentos de ergonomia e tcnicas de aumento de eficcia e
eficincia, visando melhora nas condies humanas de trabalho, segurana e
desempenho (NBR ISO 9241-210, 2011).
A seguir ser feita uma descrio das trs etapas do ciclo de
desenvolvimento interativo: Anlise, Sntese e Avaliao.
38
2.3.3.1 Etapa de Anlise

Na etapa de anlise so avaliadas as informaes sobre os usurios,
sobre as tarefas e sobre os elementos dos ambientes envolvidos no contexto
de uso de um sistema especfico (NBR ISO 9241-210, 2011).
Durante a anlise dos usurios, estes so descritos, quem so, suas
atividades e objetivos, suas caractersticas, habilidades e experincias.
Tambm nesta etapa, os usurios so agrupados de acordo com seus atributos
comuns, grupos de Personas, buscando atender s necessidades dos mais
variados tipos de pessoas (HOBOLD; COELHO, 2011).
De acordo com Cybis, Betiol e Faust (2007), Persona descreve o perfil
de uma pessoa fictcia envolvida com o produto. As personas so os usurios
primrios do sistema com suas caractersticas comuns, fornecendo uma viso
de como os usurios se comportam, pensam, o que pretendem atingir e o
porqu. Elas fornecem uma maior compreenso dos usurios, colocando-os no
centro das decises de projeto.
Na etapa de anlise, as caractersticas das tarefas tambm precisam ser
descritas. Tarefa refere-se ao trabalho que atribudo por algum a outrem ou
a ele mesmo. J atividade define o trabalho que efetivamente realizado
(CYBIS; BETIOL; FAUST; 2007).
Preece, Rogers e Sharp (2005) afirmam que durante a anlise da tarefa,
procura-se entender o que o usurio est fazendo, o que est tentando fazer,
porque e como aceita isso. Estas informaes formam uma base de prticas
existentes, possibilitando criar novos requisitos ou novas tarefas.
Ainda de acordo com estes autores, as principais formas de extrair estas
informaes so atravs de cenrios, casos de uso e casos de usos
essenciais. Eles so utilizados para descrever tarefas existentes e tambm
para descrever tarefas novas e so, geralmente, utilizados em conjunto.
Tambm na etapa de anlise feito a descrio dos elementos
pertencentes aos ambientes envolvidos no contexto do uso do sistema. Estes
elementos podem pertencer ao ambiente tcnico (hardware, software), ao
ambiente fsico (temperatura, iluminao, espao) e ao ambiente social e
cultural (prticas de trabalho, estrutura organizacional e atitudes) (NBR ISO
9241-210, 2011).
O objetivo desta etapa o levantamento da maior quantidade possvel
39
de informao para se conhecer o contexto de uso do produto. As formas mais

comuns de se obter estas informaes so atravs de entrevistas,
observaes, pesquisas ou reviso da literatura (WANGENHEIM, 2011).
2.3.3.2 Etapa de Sntese

Na etapa de sntese proposto o modelo conceitual de como um
requisito do sistema ser transformando para atender as necessidades dos
usurios. Um modelo conceitual uma descrio do sistema proposto que seja
entendida pelos usurios. Tais modelos podem ser divididos em duas
categorias: modelos conceituais baseados em atividades e os baseados em
objetos (PREECE; ROGERS; SHARP; 2005).
Os baseados em atividades tratam os modos que os usurios utilizam
para interagir com o sistema. Os principais modos de interao so a instruo,
a conversao, a manipulao e a explorao. Os baseados em objetos
enfocam em como um objeto criado em analogia com algo do mundo fsico
utilizado (PREECE; ROGERS; SHARP; 2005).
Segundo Preece, Rogers e Sharp (2005), metforas de interface outra
forma de se descrever modelos conceituais, e definida como sendo um
modelo conceitual feito para ser parecido com uma entidade fsica, mas que
tambm possua comportamento e caractersticas prprias. Elas oferecem aos
usurios um mecanismo familiar para ajud-los a utilizar um sistema.
Outra fonte de auxlio para construir um modelo conceitual so os
Paradigmas de interao, que so uma filosofia ou maneira particular de
pensar em design de interao. Eles auxiliam os designers a decidirem quais
as perguntas que devem realizar (PREECE; ROGERS; SHARP; 2005).
De acordo com NBR ISO 9241-210 (2011), nesta etapa tambm se inicia
o processo de tornar as solues de projeto mais concretas, utilizando
cenrios, simulaes, maquetes/esboos ou outras formas de prottipos. Este
processo apresenta as vantagens de tornar as propostas de projetos mais
explcitas, permite que os designers explorem conceitos de projetos antes de
encolherem um, torna possvel obter um feedback dos usurios, possibilita
avaliar vrias interaes e melhora a qualidade e completude da especificao
funcional do projeto.
40
Ao final da etapa de sntese, os prottipos podem ser incrementados

com mais detalhes incluindo elementos como: caixas de dilogo, barra de
ferramentas, cones, menus e outros, gerando os prottipos de alta fidelidade.
Para isso, podem ser usadas uma grande variedade de princpios, guias e
normas que existem para auxiliar designers a construrem produtos com
usabilidade rica (WANGENHEIM, 2011).
2.3.3.3 Etapa de Avaliao
Segundo Preece, Rogers e Sharp (2005), o objetivo da etapa de

avaliao verificar se um design agrada os usurios e atende s
necessidades destes. Ainda segundo os autores, nesta etapa definido o qu,
o porqu e quando avaliar.
Aps estas definies, o paradigma de avaliao a ser usado deve ser
determinado. A escolha do paradigma realizada de acordo com os objetivos
definidos anteriormente. Os mais utilizados so o rpido e sujo, testes de
usabilidade, estudos de campo e avaliao preditiva. As caractersticas destes
so apresentadas na tabela 1 (PREECE; ROGERS; SHARP; 2005):
Tabela 1 Caractersticas dos paradigmas de avaliao - Fonte: PREECE; ROGERS; SHARP; 2005
Paradigma
Rpida e Suja
Testes
de Estudos
de Avaliao
Usabilidade
Campos
Preditiva
Papel
dos Comportamento Realizar
um Comportamento Sem
usurios
natural
conjunto
de natural
envolvimento
tarefas
Quem controla
Os avaliadores Muito
controle Os avaliadores Avaliadores
tm um mnimo dos avaliadores
tentam
experientes
de controle
desenvolver
relacionamentos
com os usurios
Local
Ambiente natural Laboratrio
Ambiente natural Orientada
a
ou laboratrio
laboratrios,
mas geralmente
ocorre
nas
instalaes do
usurio
Quando
A
qualquer Com
um Mais
Revises
de
utilizado
momento
que prottipo
ou frequentemente
especialistas
voc
quiser produto
utilizada
no com
um
obter feedback
incio do design. prottipo
que
podem ocorrer a
qualquer
momento
Tipo de dados
Geralmente
Quantitativos,
Descries
Lista
de
41
qualitativos,
descries
informais.
algumas vezes
validados
estatisticamente
qualitativas.
Como retornam
para o design
Esboos,
citaes,
relatrio
descritivo
Relatrio
de
desempenho,
erros.
Filosofia
Abordagem
centrada
usurio,
altamente
prtica
Descries que
incluem
citaes,
esboos,
curiosidades e
algumas vezes
logs
Pode
ser
observao
objetiva
ou
etnogrfica
no
Abordagem
aplicada,
baseada
em
experimentao
problemas
realizada pelos
revisores
especializados
Os
revisores
fornecem uma
lista
de
problemas,
geralmente com
sugestes
de
problemas.
Heursticas
prticas e a
experincia dos
profissionais
sustentam
as
revises
dos
especialistas.
Estes paradigmas de avaliao so utilizados em conjunto com tcnicas

de avaliao. As principais tcnicas so: observar os usurios, solicitar
opinies dos usurios e/ou de especialistas, testar o desempenho dos usurios
e modelar o desempenho das tarefas dos usurios. A tabela 2 resume as
categorias de tcnicas e indica como elas so normalmente utilizadas nos
quatro paradigmas de avaliao (PREECE; ROGERS; SHARP; 2005):
Tabela 2 Relao entre paradigmas e tcnicas de avaliao - Fonte: PREECE; ROGERS; SHARP;
2005
Paradigmas de Avaliao
Tcnicas
Rpida e Suja
Testes
de Estudos
de Avaliao
Usabilidade
Campos
Preditiva
Observar
os Importante para Logs de vdeo e A
observao N/A
usurios
observar
o interao
constitui
uma
comportamento
parte central de
em
seus
qualquer estudo
ambientes
de campo.
naturais
Perguntas aos Discusses
Questionrios de O
avaliador N/A
usurios
individuais com satisfao dos pode entrevistar
usurios
em usurios
so ou discutir o que
potencial
administrados
v
com
os
para coletar as participantes
opinies deles
Perguntar aos Fornecer crticas N/A
N/A
Os especialistas
especialistas
da usabilidade
utilizam
de um prottipo
heursticas logo
no
incio
do
design
Teste com os N/A
Testar usurios N/A
N/A
usurios
tpicos
na
realizao
de
tarefas
tpicas
em um ambiente
de
laboratrio
42
Modelar
o
desempenho
do usurio na
realizao das
tarefas
N/A
controlado
N/A
N/A
Os modelos so
utilizados para
prever a eficcia
de uma interface
O planejamento da avaliao vem a seguir. Neste momento, o contexto,

os dados, os participantes e os instrumentos que sero necessrios para a
avaliao devem ser selecionados (WANGENHEIM, 2011).
A partir da finalizao do planejamento, inicia-se a etapa da execuo
dos testes de usabilidade. Os resultados dos testes so ento interpretados e
documentados. Geralmente, estas trs etapas so realizadas em ciclos quando
os objetivos no so alcanados. A execuo dos testes, a interpretao dos
resultados e a documentao destes, tambm podem ser usadas em ciclos em
avaliaes futuras visando melhoria das interfaces (HOBOLD; COELHO, 2011).
43
3. Reviso do Estado da Arte

Neste captulo apresentado como se encontra o estado da arte para o
tema proposto neste trabalho.
3.1 Definio
O objetivo desta fase do trabalho conhecer os SPCMMs focados em
processos de engenharia de usabilidade no contexto da convergncia digital.
Os critrios de incluso e excluso dos estudos considerados sero os
seguintes:
Critrio de Incluso: SPCMMs ou modelos de ciclo de vida de
software que cobrem a rea de engenharia de usabilidade no
contexto de convergncia digital.
Critrios de excluso: SPCMMs ou modelos de ciclo de vida de
software que no envolvem processos relacionados engenharia
de usabilidade; modelos referentes a qualidade de produtos;
artigos apresentando casos de estudos ou aplicaes pilotos;
estudos que no foquem no desenvolvimento de software.
3.2 Primeira Iterao de Busca
Foi realizada uma busca no Google Scholar tentando identificar estudos
que descrevem SPCMMs focados em processos de engenharia de usabilidade.
Os termos de busca foram os seguintes:
Quadro 10 Termos de busca
Opes de Busca
Termos de busca
Idioma
Ingls
Perodo
2006-2011 (ltimos 5 anos)
Palavras Chaves no Titulo
Usability e com no mnimo uma das
palavras Maturity ou Capability
Esta pesquisa, realizada em outubro de 2011, retornou 13 resultados.

Analisando os resumos destes resultados e aplicando-se os critrios de
incluso e excluso, nenhum artigo relevante foi identificado.
Porm, entre os resultados encontrados, havia um artigo elaborado por
Jokella et. al. (2006), que focava nos aspectos de usabilidade, e indicava que
existiam iniciativas para integrar engenharia de usabilidade em SPCMMs.
Todavia, estes no abordavam o cenrio da convergncia/divergncia digital.
44
Com base nesta primeira iterao, pode-se observar que no foi

possvel encontrar trabalhos relevantes sobre a integrao de engenharia de
usabilidade aos SPCMMs.
3.3 Segunda Iterao de Busca
Aps no encontrar trabalhos relevantes na primeira iterao, uma
segunda iterao de busca foi realizada. Nesta, o escopo foi ampliado para
qualquer cenrio, sem delimitao de um perodo e no exclusivamente para o
cenrio da convergncia/divergncia digital.
Nesta iterao, as principais normas de maturidade/capacidade de
processo e de ciclo de vida de processo de software foram verificadas.
Analisando o conjunto dessas normas e/ou modelos, foi possvel observar que
as verses mais atuais da ISO/IEC 15504, da ISO/IEC 12207, do CMMI e do
MPS.BR no abordam a engenharia de usabilidade.
Porm, foram identificadas verses intermedirias / anexos de algumas
dessas normas que abordam a questo da engenharia de usabilidade
(integrada ou parcialmente integrada ao processo de software).
Por outro lado, identificou-se o relatrio tcnico ISO/TR 18529 que foca
exclusivamente em engenharia de usabilidade.
Resumindo, foram encontrados os trabalhos apresentados no quadro 11.
Quadro 11 Materiais identificados
Norma
Iniciativa
ISO/IEC 12207:2008 Systems and O Anexo E da norma fornece um
software engineering -- Software life conjunto de processos, atividades e
cycle processes.
tarefas
reunidas,
voltadas
para
usabilidade como exemplo para a
criao de viso de processos.
Amendment to ISO/IEC 12207:1995
Apresenta o processo de usabilidade
Information Technology Software
como um dos processos do processo de
life cycle processes
software.
ISO/IEC CD 15504-5:2003 Information Apresenta o processo de usabilidade
Technology Process Assessment como um dos processos do processo de
Part
5:
An
exemplar
Process software.
Assessment Model
ISO/TR 18529:2000 Ergonomics - Norma exclusiva para o processo de
Ergonomics
of
human-system engenharia de usabilidade.
interaction -- Human-centred lifecycle
process descriptions
A seguir so apresentadas as informaes extradas dos trabalhos

encontrados.
45
3.4 Anlise das Informaes

Este item apresenta uma breve descrio das informaes que foram
extradas dos trabalhos encontrados na segunda iterao de busca.
3.4.1 ISO/IEC 12207:2008 Systems and software engineering - Software life

cycle processes

usados para a aquisio, fornecimento, desenvolvimento, operao e
manuteno de produtos de software.
A norma tambm fornece um processo que pode ser utilizado para
definir, controlar e melhorar os processos de ciclo de vida de software. Os
processos, atividades e tarefas desta norma tambm podem ser aplicados,
sozinhos ou em conjunto, com a ISO/IEC 15288, durante a aquisio de um
sistema que contm software (ISO/IEC, 2008).
O objetivo da norma fornecer um conjunto de processos para facilitar a
comunicao entre compradores, fornecedores, desenvolvedores e outras
partes interessadas no ciclo de vida de um produto de software (ISO/IEC,
2008).
46
Tal norma no define nenhum processo voltado para engenharia de

usabilidade. Porm, o anexo E da norma descreve como criar uma viso de
processos utilizando usabilidade como exemplo (ISO/IEC, 2008).
Viso de processos a organizao de processos, atividades e tarefas
selecionadas da norma ISO/IEC 12207 ou da norma ISO/IEC 15288. Elas
podem ser empregadas em situaes que necessitam de um enfoque unificado
de atividades e tarefas selecionadas a partir de processos distintos para
auxiliar em domnios especficos (ISO/IEC, 2008).
A seguir, apresentada a viso de processo da norma para usabilidade.
47
Quadro 12 Viso de Processo para Usabilidade - Fonte: ISO/IEC 12207, 2008.

Viso de Processo para Usabilidade
Esta seo fornece um exemplo de aplicao de viso de processo que gera uma viso para
usabilidade, destinado a ilustrar como um projeto pode agregar processos, atividades e tarefas da
ISO/IEC 12207, de modo a dar ateno concentrada para se alcanar um produto com
usabilidade.
Esse exemplo aborda o grupo de interesses, geralmente chamado de Usabilidade, projeto
centralizado no usurio ou no humano (conforme descrito na ISO 13407) que possibilita
otimizao de suporte e treinamento, aumento de produtividade e qualidade de trabalho,
melhores condies humanas de trabalho e reduo da possibilidade do usurio rejeitar o
sistema.
Nome: Viso de Processo para Usabilidade
Objetivo: O objetivo da Viso de Processo para usabilidade garantir a considerao dos
interesses dos stakeholders a fim de possibilitar a otimizao de suporte e treinamento, aumento
de produtividade e qualidade de trabalho, melhores condies humanas de trabalho e reduo da
possibilidade do usurio rejeitar o sistema.
Como resultado da implementao bem-sucedida da Viso de Processo para usabilidade:
1) O sistema atende s necessidades dos usurios e leva em considerao suas
capacidades e limitaes humanas;
2) Os fatores humanos e o conhecimento e as tcnicas ergonmicas so incorporadas no
projeto do sistema;
3) As atividades de projeto centradas em humanos so identificadas e realizadas;
4) O projeto do sistema abordar os possveis efeitos adversos do seu uso na sade,
segurana e desempenho humano;
5) Os sistemas melhoraro a eficincia, a eficcia e a satisfao do usurio;
Nota: Embora o envolvimento dos usurios seja um princpio de projeto centrado em humanos, os
resultados permitem que as caractersticas desejadas no possam ser diretamente medidas, mas,
ao contrrio, que possam ser argumentadas e inferidas com base em outro produto ou
caractersticas do processo que possam ser medidas.
Processos, Atividades e Tarefas:
Esta Viso de Processo pode ser implementada usando-se os seguintes processos, atividades e
tarefas da ISO/IEC 12207.
a) O processo de Gesto de Portflio de Projetos (6.2.3), em particular o processo de
Iniciao de Processo (6.2.3.3.1), que viabiliza a definio e a manuteno de um foco nas
questes de usurios nas reas da organizao que lidam com mercados, conceito,
desenvolvimento e suporte, promovendo uma abordagem centrada em humanos.
b) O Processo de Gesto de Infraestrutura (6.2.2) apresenta uma especificao de como as
atividades de projeto centradas em humanos se enquadram em todo o processo de ciclo de
vida de sistemas e na organizao.
c) O Processo de Planejamento de Projeto (6.3.1) fornece: a escolha de mtodos e tcnicas
voltadas para humanos, planejamento do envolvimento dos usurios e outras partes
interessadas, planejamento das atividades voltadas aos humanos.
d) O Processo de Avaliao e Controle de Projeto (6.3.2) fornece o acompanhamento do grau
de atendimento dos requisitos e comunica os resultados as partes interessadas e aos
gerentes, garantindo uma abordagem voltada aos humanos na equipe de projeto. Tarefas
relevantes incluem 6.3.2.3.3.1 e 6.3.2.3.3.2.
e) O Processo de Definio dos Requisitos dos Stakeholders (6.4.1) fornece a identificao e
documentao do contexto de uso e da interao entre usurios e o sistema, considerando
as capacidades humanas e limitaes em termos de habilidades e a especificao de
sade, segurana, proteo, ambiente, treinamento, suporte e outros requisitos dos
48
stakeholders e as funes que abordem os possveis efeitos adversos do uso do sistema

na sade e segurana humana.
Nota: Onde possvel, as normas aplicveis, por exemplo, ISO 13407 Processo de projeto
voltado ao humano para sistemas interativos, ISO 9241-11 Orientao em Usabilidade
(descreve o contexto de uso) e a ISO 9241 Fatores ergonmicos da interao humana-sistema
(norma com vrias partes de requisitos e recomendaes), e as prticas profissionais aceitveis
so usadas.
f)
O Processo de Anlise dos Requisitos do Sistema (6.4.2) fornece a especificao e

avaliao de contexto de uso e a usabilidade e requisitos de projetos voltados aos
humanos.
g) O Processo de Projeto de Arquitetura do Sistema (6.4.3) fornece a incorporao dos
critrios de projeto para abordar as metas de usabilidade e os requisitos ergonmicos.
h) O Processo de Integrao do Sistema (6.4.5) fornece o planejamento de integrao,
incluindo as consideraes para o treinamento de usurios e a garantia de alcance das
metas de usabilidade e a aderncia aos requisitos ergonmicos ser verificada e
registrada.
i) O Processo de Gesto da informao (6.3.6), em sua totalidade, fornece a especificao,
desenvolvimento e manuteno dos artefatos para a documentao e comunicao do grau
de realizao. Para usabilidade isso detalhado pela ISO/IEC 25062 Formato Comum para
relatrios de teste de usabilidade e normas futuras relacionadas.
j) O Processo de Medio (6.3.7), em sua totalidade, fornece a definio de uma abordagem
que relaciona as medidas s caractersticas desejadas. Para software, isso detalhado na
ISO/IEC 25020 Engenharia de Software Requisitos de Qualidade e Avaliao de Produto
de Software (SQuaRE) Modelo para referncia de medio e guia.
k) O Processo de Anlise de Requisitos de Software (7.1.2) fornece a especificao dos
requisitos ergonmicos de usabilidade e de software. A tarefa 7.1.2.3.1.1.(f) e a nota 3 so
relevantes.
l) O Processo de Manuteno de Software (6.4.9) fornece o uso do sistema. Garantir que os
requisitos de usabilidade so cumpridos apropriadamente envolve a monitorao da
operao do sistema. As tarefas 6.4.9.3.3.1 Nota 2, 6.4.9.3.4.1 3 6.4.9.3.5.1 so relevantes.
m) O Processo de Manuteno de Software sustenta as capacidades do sistema, incluindo
suas propriedades de usabilidade, e pode ser utilizado em sua totalidade.
Conclui-se que a norma reconhece a necessidade da customizao de

seus processos para o emprego em domnios especficos. A norma tambm
confirma a importncia da engenharia de usabilidade e de sua integrao no
processo de software, ao us-la como exemplo para a construo de vises de
processos para domnios especficos.
3.4.2 Amendment to ISO/IEC 12207:1995 Information Technology
Software life cycle processes
Esta emenda da norma faz uma reviso provisria da ISO/IEC 12207,

estabelecendo um conjunto coordenado de informaes de processos de
software que pode ser utilizado para definio, avaliao e melhoria de
processos. Tal projeto inclui os requisitos das normas e dos relatrios tcnicos
do comit ISO/IEC SC 7, particularmente a ISO/IEC 12207 e a ISO/IEC TR
49
15504 (ISO/IEC 12207:1995/FDAM, 2001).

Outras normas, como a ISO/IEC 14598 e a ISO/IEC 15939, assim como
a experincia no uso da ISO/IEC 12207, resultaram em algumas lies
aprendidas e forneceram subsdios valiosos para esta atualizao (ISO/IEC
12207:1995/FDAM, 2001).
A figura 13 demostra os processos da emenda da ISO/IEC 12207,
destacando
processo
de
usabilidade:
Figura 13 Processos da emenda ISO/IEC 12207 - Fonte: Adaptado de ISO/IEC 12207:1995/FDAM,

2001.
De todas as atualizaes da emenda, a que interessa para o escopo do

trabalho em questo a incluso do processo de usabilidade ao grupo de
50
processos de apoio, como mostra a figura 13.

O grupo de processos de apoio possui o objetivo de auxiliar os outros
processos, buscando atingir o sucesso e a qualidade do projeto. No quadro 13
apresentada a descrio do processo de usabilidade proposto pela norma:
Quadro 13 Processo de Usabilidade - Fonte: ISO/IEC 12207:1995/FDAM, 2001.
Processo de Usabilidade
Propsito:
O propsito do Processo de Usabilidade garantir que sejam considerados os interesses e
necessidades dos envolvidos (stakeholders) de forma a proporcionar otimizao do suporte e do
treinamento, aumento da produtividade e da qualidade do trabalho, melhoria das condies para o
trabalho humano e reduo das chances de rejeio do sistema por parte do usurio.
Resultados:
Como resultados da implementao bem-sucedida do Processo de Usabilidade:
1) o sistema atende s necessidades dos usurios e considera suas capacidades e limitaes;
2) os fatores humanos e os conhecimentos e tcnicas de ergonomia so incorporados ao
projeto dos sistemas;
3) as atividades de projeto focadas no humano so identificadas e executadas;
4) o projeto do sistema considera possveis efeitos adversos do seu uso em relao sade,
segurana e ao desempenho humanos; e
5) os sistemas melhoram a eficcia, a eficincia e a satisfao do usurio.
Atividades e tarefas do processo de usabilidade
O Processo de Usabilidade contm as atividades e tarefas do especialista em usabilidade. O
processo contm as atividades que consideram os interesses e necessidades dos indivduos e/ou
grupos que usaro ou trabalharo com a sada de um sistema durante o desenvolvimento e a
operao do software ou sistema. O Processo de Usabilidade garante a qualidade em uso do
software. Detalhes dos processos de projeto centrado no ser humano podem ser encontrados na
ISO 13407. Detalhes da especificao da qualidade em uso podem ser encontrados na ISO/IEC
9126-1.
O desenvolvedor gerencia o Processo de Usabilidade em nvel de projeto. O especialista em
usabilidade integra as atividades de usabilidade e os seus resultados com os processos do ciclo
de vida: Desenvolvimento (5.3), Operao (5.4) e Apoio (6.3, 6.4, 6.5).
Lista de atividades. Este processo consiste nas seguintes atividades:
1) Implementao do processo
2) Projeto centrado no humano
3) Aspectos humanos de estratgia, implantao e suporte
NOTA Essas atividades e tarefas associadas podem se sobrepor ou interagir e podem ser
executadas iterativa ou recursivamente.
Implementao do processo. Essa atividade consiste nas seguintes tarefas:
Planejar e gerenciar o processo de projeto centrado no ser humano. Especificar como as
atividades centradas no ser humano se encaixam no processo do ciclo de vida do sistema como
um todo e na empresa.
O desenvolvedor e o especialista em usabilidade iro:
a) consultar os envolvidos e usurios;
b) identificar e planejar o envolvimento do usurio;
c) selecionar mtodos e tcnicas centrados no humano;
d) assegurar uma abordagem centrada no humano dentro da equipe de projeto;
51
e) planejar as atividades de projeto centrado no humano;

f)
gerenciar as atividades de projeto centrado no humano;
g) patrocinar uma abordagem centrada no humano; e

h) fornecer suporte para o projeto centrado no humano.
Projeto centrado no humano. Essa atividade consiste nas seguintes tarefas:
Estabelecer os requisitos organizacionais, dos envolvidos e de outras partes interessadas para o
sistema. Essa tarefa considera a totalidade das necessidades, competncias e ambiente de
trabalho dos principais envolvidos com o sistema.
O especialista em usabilidade, em associao com o desenvolvedor, ir:
a) esclarecer e documentar as metas do sistema;
b) analisar os envolvidos e usurios;
c) avaliar o quo significante e relevante o sistema para cada grupo de envolvidos;
d) avaliar o risco para os envolvidos e usurios;
e) definir o uso do sistema;
f)
especificar os requisitos organizacionais e dos envolvidos; e
g) estabelecer os objetivos da qualidade em uso.

Um entendimento e uma especificao do contexto de uso so determinados. Identificar,
esclarecer e registrar as caractersticas dos envolvidos e usurios, suas tarefas e ambientes fsico
e organizacional no qual o sistema ir operar.
O especialista em usabilidade ir:
a) identificar e documentar as tarefas dos usurios;
b) identificar e documentar os atributos significativos dos usurios;
c) identificar e documentar o ambiente organizacional;
d) identificar e documentar o ambiente tcnico; e
e) identificar e documentar o ambiente fsico.
As solues de projeto so produzidas. Criar solues de projeto potenciais, utilizando o estadoda-arte das prticas de projeto, a experincia e o conhecimento dos participantes e os resultados
do contexto de uso.
O desenvolvedor, auxiliado pelo especialista em usabilidade, ir:
a) alocar funes;
b) produzir o modelo de tarefas combinadas;
c) explorar o projeto do sistema;
d) usar o conhecimento existente para desenvolver solues de projeto;
e) especificar o sistema e o seu uso;
f)
desenvolver prottipos;
g) desenvolver treinamento do usurio; e

h) definir suporte ao usurio.
A avaliao dos projetos em relao aos requisitos realizada. Obter feedback dos usurios finais
e de outras fontes representativas sobre o projeto em desenvolvimento.
O especialista em usabilidade ir:
a) especificar e validar o contexto da avaliao;
b) avaliar prottipos iniciais de maneira a definir os requisitos para o sistema;
c)avaliar prottipos de maneira a melhorar o projeto;
d) avaliar o sistema de maneira a verificar se os requisitos organizacionais e dos envolvidos
foram atendidos;
e) avaliar o sistema de maneira a verificar se a prtica requerida foi seguida; e
f) avaliar o sistema em uso de maneira a garantir que ele continua atendendo s necessidades
organizacionais e dos usurios.
Aspectos humanos de estratgia, implantao e suporte. Essa atividade consiste nas
52
seguintes tarefas:
Assegurar que a estratgia de sistemas contemple o projeto centrado no humano. Estabelecer e
manter um foco nas questes dos envolvidos e usurios em cada parte da organizao que trata
do mercado, conceito, desenvolvimento e suporte ao sistema.
O especialista em usabilidade trabalhar com especialistas relevantes em estratgia e marketing
para:
a) representar os envolvidos e usurios;
b) coletar o conhecimento sobre o mercado;
c) definir e planejar a estratgia do sistema;
d) obter feedback do mercado; e
e) analisar tendncias dos usurios.
Implantar e operar o sistema. Estabelecer aspectos de suporte e implementao relativos
interao humana com o sistema.
O especialista em usabilidade trabalhar com especialistas em implantao do produto,
treinamento e suporte para facilitar:
a) o gerenciamento de mudanas;
b) a determinao do impacto na organizao, nos envolvidos e nos usurios;
c) a adaptao e localizao do projeto;
d) a disponibilizao do treinamento para o usurio;
e) o suporte para os usurios nas atividades planejadas; e
f) a conformidade com a legislao sobre ergonomia do posto de trabalho.
Pode-se verificar ento, que esta emenda da norma recomendava a

adoo de um processo de usabilidade completo com propsito, atividades e
tarefas, como apoio aos processos fundamentais do ciclo de vida de processo
de software.
Atravs
desta
recomendao,
pode-se
concluir
que
comit
responsvel pela elaborao da emenda, confirma a importncia de que a

engenharia de usabilidade seja abordada de forma paralela e conjunta ao
processo de software.
3.4.3 ISO/IEC CD 15504-5:2003 Information Technology Process
Assessment Part 5: An exemplar Process Assessment Model
A ISO/IEC 15504 uma norma internacional e tem como objetivos: (a)
melhoria dos processos, gerando um perfil dos processos, identificando os
pontos fracos e fortes que sero utilizados para a elaborao de um plano de
melhorias; (b) determinao da capacidade dos processos, viabilizando a
avaliao de um fornecedor em potencial (ISO/IEC, 2003).
Esta parte da norma contm um modelo de avaliao exemplar
projetado para fornecer orientaes sobre a construo de modelos de
53
avaliao em conformidade com os requisitos da parte dois da mesma norma

(ISO/IEC, 2003).
A figura 14 demostra os processos ISO/IEC CD 15504-5:2003,
destacando o processo de usabilidade:
Figura 14 Processos ISO/IEC CD 15504-5:2003 - Fonte: Adaptado de ISO/IEC CD 15504-5, 2003.
Neste relatrio tcnico intermedirio, os processos de suporte foram

divididos em 3 grupos: o grupo de controle de configurao, o grupo de
garantia de qualidade e o grupo de qualidade do produto. Neste ltimo grupo,
foi includo um processo de usabilidade (ISO/IEC CD 15504-5, 2003).
Os processos de suporte consistem de processos inclusos no modelo de
54
referncia que podem ser empregados por qualquer um dos processos em

vrios pontos do ciclo de vida do software. O grupo de processos de qualidade
do produto formado pelos processos do modelo de referncia que objetivam
garantir que os produtos tenham boa qualidade (ISO/IEC CD 15504-5, 2003).
A seguir ser apresentada a descrio do processo de usabilidade
proposto pela norma:
Quadro 14 Processo de Usabilidade - Fonte: ISO/IEC CD 15504-5, 2003.
ID
do PRO.1
Atualizado em
25/06/2003
processo
Nome
do Usabilidade
Processo
Finalidade
A finalidade do Processo de Usabilidade garantir que sejam considerados os
do processo interesses e necessidades dos envolvidos de forma a proporcionar otimizao
do suporte e do treinamento, aumento da produtividade e da qualidade do
trabalho, melhoria das condies para o trabalho humano e reduo das
chances de rejeio do sistema por parte do usurio.
Resultados
do processo
Como resultados
Usabilidade:
da
implementao
bem-sucedida
do
Processo
de
1) 1) o sistema atende s necessidades dos usurios e considera suas

capacidades e limitaes;
2) os fatores humanos e os conhecimentos e tcnicas de ergonomia so
incorporados ao projeto dos sistemas;
3) as atividades de projeto focadas no humano so identificadas e
executadas;
4) o projeto do sistema considera possveis efeitos adversos do seu uso em
relao sade, segurana e ao desempenho humanos; e
5)
Prticas
base
os sistemas melhoram a eficcia, a eficincia e a satisfao do usurio.
NOTA 1: A prticas a seguir abrangem o ciclo de vida do sistema.

PRO.1.BP1: Incluir um especialista em usabilidade na equipe de
desenvolvimento do sistema. Definir e atribuir funes e responsabilidades
sobre usabilidade (tais como anlise, planejamento, apoio, decidir,
implementar, rever). [Tarefas 1.1, 1.2].
NOTA 2: Essas aes como: definir, identificar, analisar e implementar so
atividades conjuntas de desenvolvedores e especialistas em usabilidade.
PRO.1.BP2: Identificar a tipologia de pessoas envolvidas na utilizao do
sistema e especificar suas necessidades de uso [Tarefas 1.2, 2.1, 3.1,
Resultado 1].
PRO.1.BP3: Definir os aspectos da interface do usurio e o comportamento do
sistema relacionado com a realizao das necessidades especificadas, tendo
em conta a no necessidade do usurios: 1) de aprender detalhes tcnicos,
que no so pertinentes com o servio a ser prestado pelo sistema, 2) de
empregar as habilidades humanas especiais para operar o sistema [Resultado
1].
PRO.1.BP4: Definir e analisar os requisitos de sistema e software de acordo
com a interface do usurio identificada e o comportamento do sistema. Ter em
conta o impacto ambiental e questes de segurana. [Tarefa 2.3, Resultados 1,
3 e 4].
55
PRO.1.BP5: Implementar Projeto Centrado no Humano. Analisar e selecionar

solues de projeto de software para satisfazer a interface do usurio definida
e os requisitos de sistema. Levar em considerao questes de instabilidade
ao lidar com o feedback do usurio na criao de prottipos e na operao.
[Tarefa 2.5, Resultado 2].
PRO.1.BP6: Identificar vantagens e desvantagens de design que tm impacto
sobre a eficcia do usurio e eficincia, e priorizar as solues de design de
sistema [Resultado 5].
PRO.1.BP7: Validar o projeto de software em relao aos requisitos de
usabilidade definidos [Todos os resultados].
PRO.1.BP8: Implementar as interfaces de usurio e os aspectos relacionados
com a usabilidade do sistema, e valid-los em relao aos requisitos de
usabilidade definidos [Todos os resultados].
PRO.1.BP9: Implementar treinamento do usurio, assistncia ao usurio
atravs de call centers ou outros mecanismos de comunicao [Todos os
resultados, Tarefa 3.2]
PRO.1.BP10: Implementar mudanas no sistema com o ajuste da interface do
sistema e do comportamento relacionadas s necessidades definidas, bem
como s mudanas nas necessidades do usurio [Todos os resultados, Tarefa
3.3].
Produtos de Trabalho
Entradas
Sadas
24-00 Produto de trabalho
24-00 Produto de trabalho
Percebe-se que, neste relatrio tcnico intermedirio, um processo

completo de usabilidade com finalidade, resultados esperados e prticas bases
fornece suporte para os processos primrios do ciclo de vida de software, nos
mesmos moldes da emenda da ISO/IEC 12207:1995.
Atravs disso, pode-se afirmar que o equipe responsvel pela
elaborao deste relatrio tcnico reconhece que a engenharia de usabilidade
deve ser empregada de forma integrada ao processo de software para que o
produto final tenha a qualidade desejada.
3.4.4 ISO/TR 18529:2000 Ergonomics - Ergonomics of human-system
interaction -- Human-centred lifecycle process descriptions
Este relatrio fornece um modelo para melhoria e avaliao dos
processos de projetos centrados no humano. Ele baseado na ISO 13407 e o
modelo de maturidade de usabilidade est em conformidade com a ISO/IEC
15504 (ISO/TR 18529, 2000).
O Modelo apresenta sete processos para o desenvolvimento centrado
no humano (human-centred development - HCD), no qual cada um possui um
conjunto de prticas bases. Estes so apresentados na tabela 3 (ISO/TR
56
18529, 2000):
Tabela 3 Processos do Modelo e suas prticas bases - Fonte: adaptado de ISO/TR 18529, 2000.
Desenvolvimento de
sistema centrado no
humano
HCD 1
HCD 2
HCD 3
HCD 4
HCD 5
HCD 6
HCD 7
Garantir que
o
desenvolvim
ento
centrado no
humano
esteja no
projeto do
sistema.
Planejar e
gerenciar o
processo
de
desenvolvi
mento
centrado no
humano.
Especificar
os
requisitos
do usurio
e os
organizacio
nais.
Compreende
re
especificar o
contexto de
uso.
Produzir
solues de
projeto.
Avaliar
projetos em
relao aos
requisitos.
Introduzir e
operar o
sistema.
Representar os
stakeholders
Coletar
inteligncia de
mercado
Definir e
planejar uma
estratgia do
sistema
Consultar os
stakeholders
Planejar o
envolvimento
dos usurios
Selecionar
tcnicas
centradas no
humano
Esclarecer os
objetivos do
sistema
Definir os
stakeholders
Avaliar os
Assegurar uma
riscos para as
abordagem
partes
centrada no
interessadas.
humano
Coletar opinies
do mercado
Analisar as
tendncias dos
usurios
Planejar e
Definir o
gerenciar
sistema
atividades de
desenvolviment
o centrado no
Produzir os
humano
requisitos
Defender a
abordagem de
desenvolviment Definir a
qualidade dos
o centrado no
objetivos em
humano
uso
Apoiar
desenvolviment
o centrado no
humano
Identificar e
documentar as
tarefas dos
usurios
Alocar funes
Identificar e
documentar as
caractersticas
dos usurios
Explorar o
projeto do
sistema
Identificar e
documentar o
ambiente
organizacional
Identificar e
documentar o
ambiente tcnico
Identificar e
documentar o
ambiente fsico
Produzir modelo
de tarefas
Especificar o
contexto de
avaliao
Avaliar os
primeiros
prottipos, a fim
de definir os
requisitos para o
sistema Avaliar
Usar o
melhorias no
conhecimento exi
projeto
stente para
desenvolver solu
Avaliar os
es de projeto
prottipos, a fim
de melhorar o
Especificar o
projeto
sistema e o uso
Desenvolver
prottipos
Desenvolver
treinamento para
os usurios
Desenvolver o
suporte aos
usurios
Avaliar o
sistema, a fim de
verificar se os
requisitos dos
stakeholders e
organizacionais
foram cumpridos
Gerenciar
mudanas
Determinar
impactos
Customizao e
projeto no local
Oferecer
treinamento aos
usurios
Suporte aos
usurios
Conformidade
com os
requisitos
ergonmicos
Avaliar o sistema
a fim de verificar
que a prtica
desejada foi
seguida
Avaliar o
sistema em uso,
a fim de
garantir que ele
continua a
satisfazer as
necessidades
organizacionais
e dos usurios
O Modelo tambm apresenta sete nveis de capacidade que uma

57
organizao pode alcanar no desempenho desses processos. Estes nveis

so descritos no quadro 16 (ISO/TR 18529, 2000):
Quadro 15 Nveis de capacidade do modelo - Fonte: ISO/TR 18529, 2000
Nveis
de Nveis
de Caractersticas dos Processos
Capacidade
Capacidade
0
Incompleto
A organizao no capaz de executar o processo.
1
Executado
Alguns processos so executados
2
Gerenciado
Tempo, qualidade e recursos necessrios para execuo
do processo so conhecidos e controlados.
3
Definido
Processo realizado, conforme especificado pela
organizao, os recursos so definidos.
4
Previsvel
O desempenho e a qualidade dos processos so
conhecidos.
5
Otimizado
A organizao pode otimizar o processo para requisitos
especficos.
Este modelo ainda apresenta em seus anexos, o mapeamento dos

processos de desenvolvimento centrados no humano em relao as ISO/IEC
15504, ao CMM e ao SE-CMM (ISO/TR 18529, 2000).
Atravs deste modelo, pode-se observar que International Organizational
for Standardization ISO, um dos principais rgos de padronizaes do
mundo, confirma a importncia da engenharia de usabilidade no ciclo de vida
de software ao instituir um modelo de processos para ela.
3.5 Integrao de Engenharia de Usabilidade com a Engenharia de

Software
Devido ao nmero baixo de trabalhos encontrados nas duas iteraes de
busca, uma nova iterao foi realizada. Nesta iterao, tentou-se encontrar
trabalhos sobre integrao de engenharia de usabilidade com engenharia de
software.
Nesta iterao, alguns trabalhos foram identificados. A seguir ser
apresentada uma breve descrio destas propostas.
3.5.1 Aspects of Integrating User Centered Design into Software

Engineering Processes
Neste trabalho, Nebe e Zimmermann (2007) esclarecem que os
processos de engenharia de usabilidade (EU) , quando aplicados de forma
58
isolada, no causam o impacto desejado e no so totalmente absorvidos pela

organizao de desenvolvimento.
Os autores objetivavam identificar potenciais pontos de troca de
informaes ou compartilhamento de recursos e esforos, em diferentes nveis,
que poderiam servir de elo para integrao entre engenharia de software (ES)
e EU.
Para que essa integrao seja satisfatria, os autores acreditam que
cada nvel da hierarquia das duas disciplinas deve ser examinado. Eles
assumem os seguintes nveis hierrquicos: nvel de padres ou normas, nvel
de modelo de processos e o nvel operacional.
No nvel de normas, deve-se demonstrar que os aspectos de ES e EU
podem coexistir e serem integrados. No nvel de modelo de processos
necessrio analisar como os aspectos de EU podem ser incorporados em
modelos de ES. J no nvel operacional, uma estreita colaborao deve ser
atingida, resultando em razoveis esforos organizacionais e operacionais
adicionais (NEBE; ZIMMERMANN; 2007).
A figura abaixo demonstra os nveis hierrquicos das duas disciplinas e
a sua integrao:
Figura 15 Hierarquias semelhantes ES X EU (padres, modelos de processos e processos

operacionais Fonte: Adaptado de NEBE; ZIMMERMANN; 2007
As normas definem um framework para garantir e estabelecer padres

59
de qualidade. Os modelos de processos so adaptaes realizadas de acordo

com as condies organizacionais, com a seleo de atividades, tarefas,
papis para que possam atingir o objetivo. O nvel operacional consiste na
aplicao destes modelos de processo (NEBE; ZIMMERMANN; 2007).
3.5.2 Integrating Usability Techniques into SW Development

O objetivo deste trabalho era combinar anlise orientada a objetos com
prticas de projetos e tcnicas de usabilidade, a fim de obter uma forma
unificada de desenvolver software, tornando o projeto e a avaliao centrada
no usurio
visto como componente essencial deste desenvolvimento
(ANDERSON et al., 2001).

Segundo Anderson et al. (2001), para que esta integrao fosse bem
sucedida, as equipes de desenvolvimento e as de usabilidade deveriam passar
a trabalhar juntas.
Os principais desafios encontrados para essa integrao foram:
A compreenso dos processos, do vocabulrio e ferramentas
utilizados pela outra equipe;
O Alinhamento das ferramentas usadas pelas equipes de
desenvolvimento;
A capacidade de cada elemento de ambas as equipes abordarem
os
desenvolvedores,
independente
de
sua
formao
experincia;
A capacidade da equipe de usabilidade de explicar como integrar
o projeto centrado no usurio em qualquer um dos processos de
desenvolvimento;
Mudana cultural e organizacional;
As figuras 16 e 17 demonstram como as equipes integraram ES e EU no

desenvolvimento dos produtos:
60
Figura 16 Viso de alto nvel da definio dos requisitos Fonte: Adaptado de ANDERSON et al.,
2001.
61
Figura 17 Viso de alto nvel da concepo e execuo do desenvolvimento Fonte: Adaptado de

ANDERSON et al., 2001.
No final, os autores concluram que o enfoque no usurio, durante todo

processo, o caminho primordial para que se atinjam os dois objetivos
primordiais do desenvolvimento: a qualidade do produto e a eliminao ou
diminuio ao mximo do retrabalho (ANDERSON et al., 2001).
3.5.3 Framework for Integrating Usability Practices into the Software

Process
O estudo em questo oferece s organizaes de desenvolvimento de
software um framework para que, os desenvolvedores destas, possam integrar
prticas de usabilidade em seu processo definido de software (FERR;
JURISTO; MORENO, 2005).
Os autores selecionaram tcnicas de Interao Homem-Computador
(IHC) que melhor se adequaram integrao a um processo definido de
software. Estas tcnicas foram caracterizadas sob a perspectiva da engenharia
de software (ES), a fim de utilizar uma nomenclatura familiar para os
desenvolvedores.
Segundo Ferr, Juristo e Moreno (2005), este framework uma
ferramenta flexvel o suficiente, de modo que no se faz necessrio nenhum
modelo de processo particular para sua aplicao. O nico requisito necessrio
para sua a aplicao que os processos de desenvolvimento j existentes
devem ser baseados em refinamentos iterativos, caracterstica fundamental
para o desenvolvimento centrado no usurio.
Foram identificadas 95 tcnicas de IHC na literatura. Este nmero foi
considerado muito grande para os desenvolvedores levarem em considerao
no processo de desenvolvimento. Por esta razo, os autores selecionaram
apenas as tcnicas que mais se adequaram ao propsito da integrao
(FERR; JURISTO; MORENO, 2005).
Os critrios levados em considerao pelos autores para esta seleo
foram os seguintes:
Participao do usurio:
Tcnicas
que
incentivam
esta
participao sero de grande importncia, visto que este um

dos princpios bsicos de IHC;
Necessidades de treinamento: Tcnicas que exigem menos
formao dos desenvolvedores tero menos custo de serem
aplicadas com sucesso pelas organizaes;
Aplicabilidade geral: Tcnicas que so aplicveis a uma grande
variedade de projetos de software, visto que este o objetivo dos
autores, sero selecionadas primeiramente;
Proximidade da ES: Tcnicas que possuam princpios e
63
abordagens semelhantes s tcnicas de ES tero a integrao

mais facilitada;
Relao melhoria de usabilidade/esforo: Este critrio referese ao quanto o uso da tcnica pode melhorar a usabilidade de um
produto em comparao ao esforo necessrio sua aplicao;
Representatividade: Tcnicas que possuam um maior consenso
entre os autores da literatura IHC possuem maior eficincia;
Aplicando-se estes critrios, os autores classificaram as tcnicas em:

muito teis, teis e no muito teis. Para a integrao, foram eliminadas as
tcnicas consideradas no muito teis, reduzindo assim o universo de tcnicas
para um total de 35 (FERR; JURISTO; MORENO, 2005).
Aps esta seleo, o mapeamento entre as atividades de IHC e as
atividades do processo de software foi realizado. Ao fazer este mapeamento,
dois tipos de atividades foram identificadas em relao ES: as que
compartilham objetivos e as que lidam com questes que no so comumente
tratadas nos processos de ES (FERR; JURISTO; MORENO, 2005).
Este mapeamento est representado na figura 18:
64
Figura 18 Mapeamento de atividades IHC para atividades de ES no processo de software - Fonte:

Adaptado de FERR; JURISTO; MORENO, 2005.
Nesta integrao, os autores afirmam que o maior grau de semelhana

encontra-se nas atividades de requisitos. J as atividades de Projeto de
Interao e Avaliao de Usabilidade, por no apresentarem semelhanas com
outras
atividades
de
ES,
foram
acrescentadas
ao
processo
de
desenvolvimento.
Ainda segundo os autores, algumas tcnicas de IHC atingem um melhor
65
resultado de usabilidade quando empregadas em determinados momentos do

desenvolvimento. Desta maneira, eles caracterizam as tcnicas em relao a
sua eficcia em determinados momentos de desenvolvimento da seguinte
forma:
Especialmente bem-integrada: Tcnicas sero de grande
utilidade se aplicadas na fase em questo;
Neutras: Tcnicas podem ser aplicadas na fase em questo, mas
no tero tanta utilidade.
No usual: No o estgio mais apropriado para o uso desta
tcnica.
Para que esta classificao pudesse ser empregada de forma efetiva, o

tempo de desenvolvimento foi definido em ciclos iniciais, ciclos centrais e ciclos
de evoluo, com dois marcos delimitadores entre eles. A figura 19 demonstra
estes ciclos e seus marcos.
Figura 19 Diviso dos ciclos iterativos em estgios - Fonte: Adaptado de FERR; JURISTO;
MORENO, 2005.
O quadro 16 apresenta o Framework proposto pelos autores para a

integrao da usabilidade no processo de desenvolvimento de software.
66
Quadro 16 Framework para integrao de usabilidade no processo de software- Fonte: Adaptado

de FERR; JURISTO; MORENO, 2005.
Legenda: PU: Participao do Usurio; NT: Necessidade de Treinamento; AG: Aplicabilidade

Geral; PES: Proximidade da ES; MEU: Relao Melhoria Usabilidade/Esforo; REP:
Representatividade; CI: Ciclos Iniciais; CC: Ciclos Centrais; CE: Ciclos de Evoluo; S: Sim; N:
No; A: Alta; M: Mdia; B: Baixa; EBC: Especialmente bem-combinada; NT: Neutra; NU: No
Usual
67
Para utilizar o framework, o desenvolvedor deve procurar o tipo de

atividade que est interessado, escolher uma ou mais tcnicas IHC, de acordo
com os critrios de seleo de tcnicas que melhor lhe atenda (PU, NT, AG,
PES, MEU e REP), e para o estgio de desenvolvimento que deseja (CI, CC E
CE) (FERR; JURISTO; MORENO, 2005).
Os autores ainda representaram as tcnicas Muito teis com um fundo
branco e as teis com um fundo cinza.
Ao final do estudo, os autores afirmam que a integrao de atividades
IHC em ES um processo difcil. Isto ocorre devido s diferenas entre as
abordagens de desenvolvimento, entre as terminologias e entre as vises de
questes processuais.
Porm, aps esta integrao, as compreenses das exigncias e dos
nveis de usabilidade dos produtos de software melhoraram bastante,
ocasionando uma maior satisfao do usurio. Os desenvolvedores tambm
passaram a conhecer onde aplicar as tcnicas IHC e tornaram-se mais
conscientes sobre a importncia da usabilidade no desenvolvimento de
software (FERR; JURISTO; MORENO, 2005).
3.6 Discusso
Atravs das buscas realizadas, identificou-se que no existem trabalhos
voltados ao escopo do trabalho em questo. Porm, percebeu-se que, em
determinados momentos nos desenvolvimentos dos SPCMMs, a questo da
engenharia de usabilidade foi levada em considerao.
Verificou-se tambm que formas diferentes de abordar a usabilidade
foram usadas. Em alguns momentos, esta foi considerada como um processo
particular, em outros ela foi abordada apenas como exemplo para se adaptar
as normas para domnios especficos. E outras normas focaram a engenharia
de usabilidade como um modelo completo com vrios processos, atividades,
prticas e nveis de capacidade.
Nota-se que tais iniciativas datam do incio dos anos 2000 e no levaram
em
considerao
cenrio
da
convergncia/divergncia
digital
que
vivenciamos nos dias de hoje.

Tambm atravs da reviso do estado da arte, alguns trabalhos que
buscavam integrar Engenharia de Usabilidade a Engenharia de Software nos
68
mostraram que este um processo difcil. Porm, apesar disso, esta integrao
apresenta grandes benefcios para qualidade final do produto.
3.7 Mapeamento dos Modelos de Referncia de Engenharia de
Usabilidade
Com o objetivo de definir os processos de engenharia de usabilidade
que sero integrados ao SPCMM, um mapeamento dos processos das verses
intermedirias/anexos das normas apresentadas no subcaptulo 3.3 (segunda
iterao de busca) e identificadas no quadro 11 foi realizado. Este mapeamento
foi realizado no nvel de prticas-bases, sendo utilizadas como base todas as
prticas identificadas nas normas apresentadas no subcaptulo 3.3. O
mapeamento demonstrado no quadro 17.
69
Quadro 17 Mapeamento dos modelos de referncia de engenharia de usabilidade

Processos Unificados
Prticas Bases
Unificadas
Descrio
ISO/IEC 12207:2008
GC*
Processo de gesto do
desenvolvimento
centrado no humano
PB1: Representar
os Stakeholders.
Atuar
como
advogado
dos
usurios finais e dos stakeholder
na empresa e na equipe de
desenvolvimento do sistema.
Viso
de
processo
para
usabilidade / Processo de
Gesto
de
Portflio
de
Projetos.
P*
Atividades:
Implementao do processo.
PB2:
Coletar
inteligncia
de
mercado.
Realizar investigao prospectiva

em grupos de usurios potenciais,
a fim de identificar necessidades
futuras,
novos
usurios
ou
organizaes usurios para o
sistema.
Estabelecer
procedimentos para descobrir a
aceitao
dos
usurios
no
contexto esperado.
Obter
informaes
sobre
o
mercado atual
como uma
viso. Operacionalizar esta viso
em
estratgia
de
implementao. Utilize ciclo
de
vida de contabilidade de custos, a
fim de avaliar o custo de uma
abordagem HCD.
Executar pesquisa otimizada para
refinar e consolidar a estratgia do
sistema, com base no feedback
dos usurios e no usurios no
mercado do sistema.
Procure mudanas
em:
usurios (por
exemplo, suas
habilidades e treinamento para
organizaes de
usurios, bem
como as necessidades e desejos
de produtos
de
consumo),
tarefas (por
exemplo,
mudanas no tipo de trabalho ou
de volumes de trabalho), contexto
(por
exemplo,
mudanas em ambientes
de trabalho e de vida , as novas
tecnologias, costumes sociais e
polticos e
as
expectativas). Analisar essas
informaes
para estimar
as
necessidades futuras.
Estabelecer estruturas, mecanism
os
e
procedimentos para
assegurar
que as
partes
interessadas sejam
Viso
de
processo
para
Gesto
de
Portflio
de
Projetos.
Processo de Usabilidade /
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
Viso
de
processo
para
Planejamento de Projeto.
Viso
de
processo
para
Gesto
de
Portflio
de
Projetos.
Viso
de
processo
para
Definio dos Requisitos dos
Stakeholders, Processo de
Anlise dos Requisitos do
Sistema e o Processo de
Anlise de Requisitos de
Software
PB3:
Definir
e
planejar
uma
estratgia
do
sistema.
PB4.
Coletar
opinies
do
Mercado.
PB5. Analisar as
tendncias
dos
usurios.
Planejamento
gerenciamento
processo
desenvolvimento
e
do
de
PB1:. Consultar os
stakeholders.
GC
ISO/IEC CD 155045:2003
GC
ISO/TR 18529:2000
GC
Processo HCD1 Garantir que

o desenvolvimento centrado
no humano esteja no projeto
do
sistema.
/
PB1:
Representar os Stakeholder.
T*
Processo
de
Usabilidade
/
PRO.1.BP1: Incluir um
especialista
em
usabilidade na equipe
de desenvolvimento do
sistema.
-*

do sistema. / PB2: Coletar
inteligncia de mercado.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.

do sistema. / PB3: Definir e
planejar uma estratgia do
sistema.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.

do sistema. / PB4. Coletar
opinies do Mercado.
do sistema. / PB5. Analisar as
tendncias dos usurios
Atividade:
Implementao do Processo.
Processo
de
Usabilidade
/
especialista
em
Processo HCD2 Planejar e

gerenciar o processo de
desenvolvimento centrado no
humano / PB1: Consultar os
Amendment to ISO/IEC
12207:1995
/
centrado no humano.
PB2: Planejar o
envolvimento dos
usurios.
PB3:
Selecionar
tcnicas centradas
no humano.
PB4:
Assegurar
uma abordagem
centrada
no
humano.
PB5:
Planejar
atividades
de
desenvolvimento
centrado
no
humano.
PB6:
Gerenciar
atividades
de
desenvolvimento
centrado
no
humano.
PB7: Defender a
abordagem
de
desenvolvimento
centrado
no
humano.
PB8:
Apoiar
desenvolvimento
centrado
no
humano.
efetivamente envolvidas
e
consultadas em
cada aspecto
significativo do desenvolvimento e
implementao do sistema.
Decidir
sobre a
forma
mais
eficaz para
provocar a
participao do usurio em cada
etapa do projeto, aproveitando o
melhor
da boa
prtica estabelecida
no trabalho
em equipe e o envolvimento
apropriado do usurio.
Decidir
quais
mtodos sero
includos e
como
eles
sero unidos no
processo
de
desenvolvimento. Definir
como este ir
interagir com
a
metodologia do ciclo de vida
particular
a
ser utilizado
no desenvolvimento do sistema
Estabelecer uma cultura multidisciplinar na equipe
do
projeto. Manter o foco em uma
abordagem centrada
no
ser
humano. Identificar
as
competncias
especializadas necessrias e
planejar como us-las.
Desenvolver
um
plano especificando como
as
atividades centradas
no
homem sero
integradas
no processo
global de
sistema.
stakeholders.
Viso
de
processo
para
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.

humano / PB2: Planejar o
envolvimento dos usurios.
Viso
de
processo
para
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.

humano / PB3: Selecionar
tcnicas centradas no
humano.
Viso
de
processo
para
Gesto de Portflio de Projetos
e o Processo Avaliao e
Controle de Projeto.
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.

humano / PB4: Assegurar uma
abordagem centrada no
humano.
Viso
de
processo
para
Atividade:

humano / PB5: Planejar
atividades de desenvolvimento
centrado no humano.
Levar
em
conta problemas
especficos
dos
usurios na
gesto de
projetos
e
departamentos
de
desenvolvimento. Certifiquese que
o
processo
de desenvolvimento
do
sistema leva em conta a opiniao
do usurio.
Promover
uma
abordagem centrada
no
ser
humano dentro da empresa.
Viso
de
processo
para
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.

humano / PB6: Gerenciar
atividades de desenvolvimento
centrado no humano.
Viso
de
processo
para
Atividade:
Viso
de
processo
para
Atividade:

humano / PB7: Defender a
abordagem de
humano.
humano / PB8: Apoiar
Incluir elementos centrados

homem em procedimentos
suporte (por exemplo,garantia
qualidade, controle
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
no
de
de
de
71
Especificao
dos
requisitos do usurio e
os organizacionais.
PB1: Esclarecer os
objetivos
do
sistema.
mudanas, gesto
de
recursos). Certifique-se que estas
aes so realizadas como parte
integrante da gesto de infraestrutura da empresa.
Descrever
os
objetivos que o
usurio ou
a
organizao usurio deseja
atingir atravs
da
utilizao
do sistema.
PB2: Definir
stakeholders.
os
Identificar e analisar os papis de

cada grupo
de stakeholders susceptveis de
serem
afetadas pelo
sistema. Avaliar
a
relevncia
do sistema para cada grupo de
participantes que sero usurios
finais do sistema e / ou sero
afetados por entradas ou sadas
do sistema.
Rever os riscos a segurana, a
sade e ao bem-estar para os
stakeholders
do sistema. Relacionar
isto
com a avaliao
do
risco
global para o sistema.
PB3: Avaliar
riscos para
partes
interessadas.
os
as
PB4:
Definir
sistema.
Definir e
aprovar
o comportamento e
o
desempenho
do sistema
em
levando
em
conta
a
experincia dos stakeholders com
o sistema.
PB5: Produzir os
requisitos.
Desenvolver uma
declarao
explcita dos
requisitos
dos
stakeholders e do sistema.
PB6:
Definir
a
qualidade
dos
objetivos em uso.
Gerar e
aceitar
critrios mensurveis para avaliar
a
qualidade
exigida na utilizao do sistema.
sistema.
humano.
Viso
de
processo
para
usabilidade
/
Processo
Software.
Viso
de
processo
para
usabilidade
/
Processo
Software.
Atividade:
Projeto Centrado no Humano
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo HCD3 Especificar os

requisitos do usurio e os
organizacionais / PB1:
Esclarecer os objetivos do
sistema.
Atividade:
Processo
de
Usabilidade
/
PRO.1.BP2: Identificar
a tipologia de pessoas
envolvidas
na
utilizao do sistema e
especificar
suas
necessidades de uso.

organizacionais / PB2: Definir
os stakeholders.
Viso
de
processo
para
usabilidade
/
Processo
Software.
Viso
de
processo
para
usabilidade
/
Processo
Sistema, o Processo de
Gesto da Informao e o
Processo de Anlise de
Requisitos de Software.
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.

organizacionais / PB3: Avaliar
os riscos para as partes
interessadas.
Atividade:

o sistema.
Viso
de
processo
para
usabilidade
/
Processo
Software.
Viso
de
processo
para
usabilidade / O Processo de
Medio.
Atividade:
Processo
de
Usabilidade
/
PRO.1.BP3: Definir os
aspectos da interface
do
usurio
e
o
comportamento
do
sistema
relacionado
com a realizao das
necessidades
especificadas
Processo
de
Usabilidade
/
PRO.1.BP4: Definir e
analisar os requisitos
de sistema e software.

organizacionais / PB5:
Produzir os requisitos.
Atividade:
Processo
de
Usabilidade
/
PRO.1.BP7: Validar o
projeto de software em
relao aos requisitos
de usabilidade.

a qualidade dos objetivos em
uso
72
Especificao
contexto de uso
do
PB1: Identificar e
documentar
as
tarefas
dos
usurios.
Descrever as atividades que os

usurios executam para atingir os
objetivos do sistema.
PB2: Identificar e
documentar
as
caractersticas dos
usurios.
Descrever
as
caractersticas
relevantes dos usurios. Isso ir
incluir
o
conhecimento,
a
linguagem,
as
capacidades
fsicas, nvel de experincia com
as tarefas do trabalho e dos
equipamentos
relevantes
do
sistema.
Descrever os meios sociais e
organizacionais
relevantes,
estrutura de gesto e prticas
organizacionais, etc.
PB3: Identificar e
documentar
o
ambiente
organizacional.
PB4: Identificar e
documentar
o
ambiente tcnico.
PB5: Identificar e
documentar o
ambiente fsico.
Produo de solues de
projeto
PB1:
funes.
Alocar
PB2:
Produzir
modelo de tarefas.
PB3: Explorar o
projeto
do
sistema.
Descrever
as
caractersticas
relevantes
de
qualquer
equipamento a ser utilizado. Uma
ateno especial deve ser dada
ao equipamento com o qual os
usurios interagem diretamente.
Descrever o local, equipamentos
de
trabalho
e
condies
ambientais.
Por
exemplo,
iluminao, rudo, vibrao, etc.
Analisar o contexto de uso e as

funes
necessrias
e
desempenho do sistema, para
distribuir as funes entre o
homem,
a
mquina
e
componentes organizacionais do
sistema a fim de satisfazer melhor
cada funo.
Desenvolver um modelo vivel
de novas tarefas do usurio a
partir
do
conhecimento
existente das melhores prticas,
os requisitos, o contexto de uso, a
alocao
de
restries de
funo e projeto para o sistema.
Gerar
e analisar
uma
srie
de opes
de
projeto para
cada aspecto
do
sistema
relacionado com a sua utilizao e
Viso
de
processo
para
Sistema e Processo de Anlise
de Requisitos de Software.
Viso
de
processo
para
Atividade:
Projeto centrado no humano.
Atividade:
Viso
de
processo
para
Viso
de
processo
para
Viso
de
processo
para
-
Atividade:
Atividade:
Atividade:
Atividade:
Atividade:
Atividade:
73
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
a tipologia de pessoas
envolvidas
na
utilizao do sistema e
especificar
suas
necessidades de uso.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo HCD4 Compreender

e especificar o contexto de
uso. / PB1: Identificar e
documentar as tarefas dos
usurios.

documentar as caractersticas
dos usurios.

documentar
o
ambiente
organizacional.

uso. / PB4. Identificar e
documentar
o
ambiente
tcnico.

uso. / PB5. Identificar e
documentar o ambiente fsico.
Processo
HCD5
Produzir
solues de projeto. / PB1:
Alocar funes.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
PRO.1.BP5:
Implementar
Projeto
Processo
HCD5
Produzir
Produzir modelo de tarefas.
Processo
HCD5
Produzir
Explorar o projeto do sistema.
PB4.
Usar
o
conhecimento
existente
para
desenvolver
solues
de
projeto.
PB5. Especificar o
sistema e o uso.
PB6. Desenvolver
prottipos.
PB7. Desenvolver
treinamento para
os usurios.
PB8. Desenvolver
o suporte aos
usurios.
Avaliao das solues

de Projeto
PB1: Especificar o
contexto
de
avaliao.
PB2: Avaliar os
primeiros
prottipos, a fim
de
definir
os
requisitos para o
sistema.
seu efeito sobre os stakeholders.

Aplicar informaes relevantes da
cincia humana na concepo do
sistema.
Incluir
todos
os
stakeholders,
os
requisitos
organizacionais, o contexto de
uso, as normas internacionais, os
requisitos legais, as patentes
existentes, as boas prticas, os
guia de estilos e padres de
projeto, etc. no projeto.
Produzir um projeto para os
componentes relacionados
aos
usurios do sistema. Produzir
a descrio de como o sistema
ser utilizado. Alterar o projeto em
relao
ao
feedback das
avaliaes.
Produzir solues de projeto mais
concretas atravs de simulaes,
de modelos, etc. Desenvolver
simulaes ou implementao
experimental de aspectos chaves
do sistema para testes com
usurios ou stakeholders.
Identificar, especificar e produzir o
treinamento necessrio para que
os usurios relevantes possam
executar as tarefas de forma
eficaz usando o sistema. Cobrir ou
incluir todas alteraes propostas
nos processos de negcio, projeto
de trabalho e tarefas.
Identificar, especificar
e produzir
os servios de
suporte
ao
usurio do sistema. Levar em
conta as alteraes propostas nos
processos
de
negcio e de
projeto de trabalho.
Descrever e verificar as condies
em que um
sistema
testado ou avaliado. Descrever o
relacionamento e,
especialmente, as
discrepncias, entre o contexto de
avaliao e do contexto de uso.
De
referncia
de
sistemas
adequados de acordo com
critrios relevantes. Testar a
usabilidade
de
sistemas
concorrentes / alternativas e / ou
sistemas
conceitos.
Use
prottipos para estimular a
contribuio dos stakeholders aos
requisitos do sistema. Teste de
Atividade:
Viso
de
processo
para
-
Atividade:
Atividade:
Viso
de
processo
para
Integrao do Sistema.
Atividade:
Viso
de
processo
para
Integrao do Sistema.
Viso
de
processo
para
Avaliao e Controle de
Projeto.
Viso
de
processo
para
Projeto.
Centrado no Humano
Processo
de
Usabilidade
/
PRO.1.BP5:
Implementar
Projeto
Centrado no Humano
Processo
HCD5
Produzir
solues de projeto. / PB4.
Usar
o
conhecimento
existente para desenvolver
solues de projeto.
Processo
de
Usabilidade
/
PRO.1.BP5:
Implementar
Projeto
Centrado no Humano
Processo
HCD5
Produzir
Especificar o sistema e o uso.
Processo
de
Usabilidade
/
PRO.1.B8:
Implementar
as
interfaces de usurio.
Processo
HCD5
Produzir
Desenvolver prottipos.
Processo
de
Usabilidade
/
PRO.1.BP9:
Implementar
treinamento do usurio
Processo
HCD5
Produzir
Desenvolver treinamento para
os usurios.
Atividade:
Processo
HCD5
Produzir
Desenvolver o suporte aos
usurios.
Atividade:
Processo
HCD6
Avaliar
projetos em relao aos
requisitos./ PB1: Especificar o
contexto de avaliao.
Atividade:
Processo
de
Usabilidade
/
especialista
em
sistema.
-
Processo
HCD6
Avaliar
requisitos./ PB2: Avaliar os
primeiros prottipos, a fim de
definir os requisitos para o
sistema.
74
PB3: Avaliar os
prottipos, a fim
de melhorar o
projeto.
Introduo e operao do
sistema.
estabilidade dos requisitos.

Gerar
e analisar
uma
srie
de opes
de
projeto para
cada aspecto
do
sistema
relacionado com a sua utilizao e
seu efeito sobre os stakeholders.
Viso
de
processo
para
Projeto.
Atividade:
PB4. Avaliar o
sistema, a fim de
verificar se os
requisitos
dos
stakeholders e os
organizacionais
foram cumpridos.
PB5.
Avaliar o
sistema a fim de
verificar que a
prtica desejada
foi seguida.
Testar o desenvolvimento ou
sistema final para garantir que ele
atenda
aos
requisitos
dos
usurios, das tarefas e do
ambiente, conforme definido na
sua especificao.
Viso
de
processo
para
Projeto.
Atividade:
Verifique nos sistemas a adeso

na aplicao de cincias no
conhecimento humano, guias de
estilos, normas, diretrizes e
legislao.
Viso
de
processo
para
Projeto.
Atividade:
PB6. Avaliar o
sistema em uso, a
fim de garantir que
ele continua a
satisfazer
as
necessidades
organizacionais e
dos usurios.
PB1:
Gerenciar
mudanas.
Checar o sistema em uso para

verificar mudanas nos requisitos
do usurio, organizacionais, dos
stakeholders e usabilidade e para
garantir que o sistema continua a
atender esses requisitos.
Viso
de
processo
para
Projeto.
Atividade:
Facilitar, supervisionar
e assegurar os
aspectos HCD na implementao
do sistema.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
PB2:
Determinar
impactos.
Avaliar o impacto humano e

organizacional do sistema a ser
introduzido.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
PB3:
Customizao e
projeto no local.
Fornecer
suporte para
personalizao do sistema
para
atender
s necessidades
culturais ou
operacionais
locais. Fornecer
suporte para
personalizao e
configurao para atender s
necessidades de usurios
especficos. Fornecer detalhes de
personalizao
para o
gerenciamento de configurao.
Oferecer treinamentos
e
Viso
de
processo
para
Projeto de Arquitetura do
Integrao do Sistema e o
Processo de Manuteno de
Software.
Viso
de
processo
para
Software.
Viso
de
processo
para
Software.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
Viso
Processo
PB4:
Oferecer
de
processo
para
75
de
Usabilidade
Processo
de
Usabilidade
/
vantagens
e
desvantagens
de
design.
Processo
de
Usabilidade
/
de
usabilidade
definidos
Processo
de
Usabilidade
/
de
usabilidade
definidos
-
Processo
HCD6
Avaliar
requisitos./ PB3: Avaliar os
prottipos, a fim de melhorar
o projeto.
Processo
HCD6
Avaliar
requisitos./ PB4. Avaliar o
sistema, a fim de verificar se
os requisitos dos stakeholders
e os organizacionais foram
cumpridos.
Processo
HCD6
Avaliar
requisitos./ PB5. Avaliar o
sistema a fim de verificar que
a
prtica
desejada
foi
seguida.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
de
Usabilidade
/
especialista
em
sistema.
Processo
HCD6
Avaliar
requisitos. / PB6. Avaliar o
sistema em uso, a fim de
garantir que ele continua a
satisfazer as necessidades
organizacionais
e
dos
usurios.
Processo HCD7 Introduzir e
operar o sistema. / PB1:
Gerenciar mudanas.

Determinar impactos.

Customizao e projeto no
local.
Processo
de
treinamentos aos
usurios.
PB5: Suporte aos

usurios.
PB6:
Conformidade
com os requisitos
ergonmicos.
oficinas aos usurios para atender

s necessidades de formao
identificadas e facilitar a transio
para novos modelos de empregos
e novos arranjos de trabalho em
equipe.
Manter contato com os usurios e
a organizao cliente em toda a
definio,
desenvolvimento
e
introduo de um sistema.
Levantamento dos locais de

trabalho, usurios e programas de
treinamento para garantir que o
hardware, software e ambiente de
trabalho atendam os requisitos da
legislao nacional.
Software.
Viso
de
processo
para
Software.
Viso
de
processo
para
Software.
Atividade:
Aspectos
estratgia,
suporte.
P
humanos
implantao
Usabilidade
PRO.1.BP9:
Implementar
treinamento
usurio.
de
e
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
Atividade:
Aspectos
humanos
de
estratgia,
implantao
e
suporte.
GC = Grau de cobertura;
T = Totalmente coberto;
P = Parcialmente Coberto;
- = Sem cobertura;
76
Processo
Usabilidade
PRO.1.BP9:
Implementar
treinamento
usurio.

Oferecer treinamentos aos
usurios.
do
de
/

Suporte aos usurios.

Conformidade
com
os
requisitos ergonmicos.
do
Processo
de
Usabilidade
/
PRO.1.BP9:
Implementar
mudanas no sistema.
4. Modelo de Maturidade/Capacidade de Processo de Software

Como concluso, um modelo de maturidade/capacidade de processo de
software para avaliao e melhoria no desenvolvimento de software com boa
usabilidade
estendido,
levando
em
considerao
contexto
da
A ISO/IEC 15504 utilizada como base para implementao deste
modelo. Esta norma fornece um framework para a avaliao e melhoria dos
processos e pode ser usada por organizaes envolvidas no planejamento, na
gesto, no acompanhamento, no controle e na melhoria da aquisio, no
fornecimento, no desenvolvimento, na operao, na evoluo e no suporte do
produto (ISO/IEC, 2003).
A figura 20 apresenta os principais elementos do processo de avaliao
segundo a ISO/IEC 15504.
Figura 20 Elementos principais do processo de avaliao - Fonte: Adaptado de ISO/IEC, 2003.
O modelo de avaliao compatvel com os requisitos definidos na parte

2 da norma ISO/IEC 15504 e o modelo de processo foi selecionado de acordo
com o domnio de interesse. Para o domnio especfico da engenharia de

software o modelo selecionado a ISO/IEC 12207.
A relao entre o modelo de referncia de processo, a estrutura de
medio e o modelo de avaliao de processo pode ser visto na figura 21. Este
modelo bidimensional formado por um conjunto de processos, com seus
propsitos e resultados, e uma estrutura de medio que possui um conjunto
de atributos que se aplicam a todos os processos.
Os processos so agrupados em nveis de capacidade para determinar
qual o seu nvel. O resultado da avaliao possui um conjunto de perfis de
processos e, opcionalmente, uma classificao de nvel de capacidade para
cada processo avaliado.
Figura 21 Relacionamentos no modelo de avaliao de Processo - Fonte: Adaptado de ISO/IEC,

2003.
4.1 Definio do Modelo de Referncia

Os modelos de referncia fornecem o mecanismo pelo qual os modelos
de avaliao so relacionados com o framework de medio estabelecido pela
ISO/IEC 15504. O modelo de referncia definido externamente ISO/IEC
15504 e prov a base para um ou mais modelos de avaliao.
Os modelos de avaliao so baseados nas descries de processo
fornecidas nos modelos de referncia. Para assegurar que os resultados da
avaliao possam ser traduzveis em um perfil de processo da ISO/IEC 15504
78
de maneira repetvel e confivel, este deve possuir certos requisitos.

O modelo de referncia possui uma declarao de domnio, uma
descrio dos processos dentro do escopo do modelo de referncia, uma
descrio do relacionamento entre o modelo de referncia e o contexto de uso
pretendido, uma descrio do relacionamento entre os processos definidos no
modelo de referncia e cada processo definido dentro do modelo tem uma
descrio e identificao nica.
O modelo de referncia tambm documenta a comunidade de interesse
do modelo e as aes tomadas para se chegar a um consenso dentro desta.
As descries dos processos dentro do escopo do modelo so
elementos fundamentais de um modelo de referncia. Estas descries
incorporam uma declarao do propsito do processo juntamente com o
conjunto de resultados que demonstram a sua realizao com sucesso.
Tais descries possuem os seguintes requisitos: o processo descrito
em termos de propsito e resultados; o conjunto de resultados necessrio e
suficiente para que seja atingido o seu propsito; e as descries so tais que
nenhum dos aspectos da estrutura de medio esteja contido ou implcito.
Com base no objetivo deste trabalho, a norma ISO/IEC 12207 fornece
uma base adequada para a definio de um modelo de referncia de processo.
usados
para
aquisio,
fornecimento,
desenvolvimento,
operao
manuteno de produtos de software (ISO/IEC, 2008).

O modelo de referncia da norma descreve os propsitos, os resultados
esperados e a relao entre os processos. Tambm define as atividades e
tarefas necessrias para implementar em alto nvel os processos (ISO/IEC,
2008).
O anexo B da norma define um modelo de referncia, em um nvel de
abstrao mais elevado do que o texto principal, adequado para o uso na
avaliao de processos de acordo com a parte 2 da norma ISO/IEC 15504
(ISO/IEC, 2008).
A norma possui dois grupos de processos, os processos contextuais de
sistema e os especficos de software. Os processos contextuais de sistema
79
fornecem subsdios para lidar com um produto de software ou servio ou um

sistema de software independente. Este grupo de processos dividido em
outros quatros subgrupos: Processos Contratuais, Processos Organizacionais
Capacitadores de Projetos, Processos de Projetos e os Processos Tcnicos
(ISO/IEC, 2008).
O grupo de processos especficos de software utilizado na
implementao de um produto ou servio de software que elemento de um
sistema maior. Ele dividido em trs subgrupos: Processos de Implementao
de Software, Processos de Apoio ao Software e Processos de Reuso de
Software (ISO/IEC, 2008).
Todos os processos destes grupos so descritos em termos de seu
propsito e resultados esperados, bem como a lista de aes utilizadas para
atingir os resultados (ISO/IEC, 2008).
80
4.1.1 Adaptando o Modelo para a Integrao de Processos de Usabilidade

Para atender as caractersticas e necessidades especficas de um
determinado domnio, modelos de referncia devem ser adaptados. Para atingir
o objetivo deste trabalho, a norma ISO/IEC 15504 adaptada, incluindo
processos relevantes ao contexto da convergncia/divergncia digital e
usabilidade.
A dimenso de processo baseada na norma ISO / IEC 12207 como
modelo de referncia para o processo de software geral. Em conformidade com
o processo de adaptao, previsto no Anexo A desta mesma norma, uma
extenso do padro proposto, definindo um grupo de processos adicionais de
Engenharia de Usabilidade, mostrado na Figura 23 (marcados em verde) e
detalhados na Tabela 4.
Alm disso, mais processos (marcados em azul e amarelo na Figura 23)
so adicionados do mesmo modo que so estabelecidos na norma ISO / IEC
15504 partes 5 e 7, a fim de manter a conformidade com a estrutura de
maturidade definido por esta, j que estes processos no so cobertos pela
ISO / IEC 12207.
A figura 23 e a tabela 4 apresentam este modelo resultante, seus grupos
e processos. A tabela 4 tambm inclui as referncias para fonte de cada um
dos processos.
81
Figura 23 Processos do Modelo de Referencia Proposto com Extenso para Engenharia de

Usabilidade
Tabela 4 Processos do Modelo de Referencia Proposto com Extenso para Engenharia de

Usabilidade
Nmero do Nome do Processo
Origem
Nmero Nome do Processo na
Processo
do
origem
process
82
1
1.1
1.1.1
1.1.2
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.6
1.4.7
1.4.8
1.4.9
Processos do ciclo de
vida do sistema
Processos contratuais
Processo de aquisio
Processo de Fornecimento
Processos
organizacionais
de
habilitao de projeto
Processo de gesto de
modelo de ciclo de vida
infraestrutura
portflio de projetos
recursos humanos
qualidade
Processo
de
gesto
organizacional
desempenho quantitativo
Processo de melhoria de
processo quantitativa
Processos de Projeto
Processo de planejamento
de projeto
Processo de controle e
avaliao de projeto
Processo de tomada de
deciso
risco
configurao
informao
medio
Processos tcnicos
Processo de definio dos
requisitos dos Stakeholders
Processo de anlises dos
requisitos do sistema
Processo de projeto de
arquitetura de sistema
Processo
de
implementao
Processo de integrao de
sistema
Processo de teste de
qualificao de sistema
Processo de instalao de
software
Processo de suporte de
aceitao de software
Processo operao de
ISO/IEC 12207:2008
o
na
origem
6
ISO/IEC 12207:2008
ISO/IEC 12207:2008
ISO/IEC 12207:2008
ISO/IEC 12207:2008
6.1
6.1.1
6.1.2
6.2
ISO/IEC 12207:2008
6.2.1
ISO/IEC 12207:2008
6.2.2
ISO/IEC 12207:2008
6.2.3
ISO/IEC 12207:2008
6.2.4
ISO/IEC 12207:2008
6.2.5
ISO/IEC 15504-5:2006
MAN.2
ISO/IEC 15504-7:2008
QNT.1
ISO/IEC 15504-7:2008
QNT.2
ISO/IEC 12207:2008
ISO/IEC 12207:2008
6.3
6.3.1
ISO/IEC 12207:2008
6.3.2
ISO/IEC 12207:2008
6.3.3
ISO/IEC 12207:2008
6.3.4
ISO/IEC 12207:2008
6.3.5
ISO/IEC 12207:2008
6.3.6
ISO/IEC 12207:2008
6.3.7
ISO/IEC 12207:2008
ISO/IEC 12207:2008
6.4
6.4.1
ISO/IEC 12207:2008
6.4.2
ISO/IEC 12207:2008
6.4.3
ISO/IEC 12207:2008
6.4.4
ISO/IEC 12207:2008
6.4.5
ISO/IEC 12207:2008
6.4.6
ISO/IEC 12207:2008
6.4.7
ISO/IEC 12207:2008
6.4.8
ISO/IEC 12207:2008
6.4.9
vida do sistema
Processos contratuais
Processo de aquisio
Processo de Fornecimento
Processos
organizacionais
de
habilitao de projeto
modelo de ciclo de vida
infraestrutura
portflio de projetos
recursos humanos
qualidade
Processo
de
gesto
organizacional
Processo de gerncia do
desempenho quantitativo
Processo de melhoria de
processo quantitativa
Processos de Projeto
Processo de planejamento
de projeto
Processo de controle e
avaliao de projeto
Processo de tomada de
deciso
risco
configurao
informao
medio
Processos tcnicos
Processo de definio dos
requisitos dos Stakeholders
Processo de anlises dos
requisitos do sistema
arquitetura de sistema
Processo
de
implementao
sistema
qualificao de sistema
Processo de instalao de
software
Processo de suporte de
aceitao de software
Processo operao de
83
1.4.10
1.4.11
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
2.2.9
2.3
2.3.1
2.3.2
2.3.3
2.4
2.4.1
2.4.2
software
Processo de manuteno
de software
Processo de desativao
de software
vida do software
Processos
de
implementao
de
software
Processo
de
implementao de software
Processo de anlise de
requisito de software
Processo de arquitetura de
software
software
Processo de construo de
software
software
qualificao de software
Processos de apoio ao
software
documentao de software
configurao de software
Processo de garantia de
qualidade de software
Processo de verificao de
software
Processo de validao de
software
Processo de reviso de
software
Processo de auditoria de
software
Processo de resoluo de
problema de software
solicitaes de mudanas
Processos de reuso de
software
Processo de engenharia de
domnio
reuso de ativos
programa de reuso
Processos de engenharia
de usabilidade
desenvolvimento
centrado no humano
Processo
de
especificao
do
contexto de uso
ISO/IEC 12207:2008
6.4.10
ISO/IEC 12207:2008
6.4.11
ISO/IEC 12207:2008
ISO/IEC 12207:2008
7.1
ISO/IEC 12207:2008
7.1.1
ISO/IEC 12207:2008
7.1.2
ISO/IEC 12207:2008
7.1.3
ISO/IEC 12207:2008
7.1.4
ISO/IEC 12207:2008
7.1.5
ISO/IEC 12207:2008
7.1.6
ISO/IEC 12207:2008
7.1.7
ISO/IEC 12207:2008
7.2
ISO/IEC 12207:2008
7.2.1
ISO/IEC 12207:2008
7.2.2
ISO/IEC 12207:2008
7.2.3
ISO/IEC 12207:2008
7.2.4
ISO/IEC 12207:2008
7.2.5
ISO/IEC 12207:2008
7.2.6
ISO/IEC 12207:2008
7.2.7
ISO/IEC 12207:2008
7.2.8
ISO/IEC 15504-5:2006
SUP.10
ISO/IEC 12207:2008
7.3
ISO/IEC 12207:2008
7.3.1
ISO/IEC 12207:2008
7.3.2
ISO/IEC 12207:2008
7.3.3
ISO/TR 18529:2000
ISO/TR 18529:2000
HCD 1
ISO/TR 18529:2000
HCD 4
software
Processo de manuteno
de software
Processo de desativao
de software
vida do software
Processos
de
implementao
de
software
Processo
de
implementao de software
Processo de anlise de
requisito de software
Processo de arquitetura de
software
software
Processo de construo de
software
software
qualificao de software
Processos de suporte ao
software
documentao de software
configurao de software
Processo de garantia de
qualidade de software
Processo de verificao de
software
Processo de validao de
software
Processo de reviso de
software
Processo de auditoria de
software
Processo de resoluo de
problema de software
solicitaes de mudanas
Processos de reuso de
software
Processo de engenharia de
domnio
reuso de ativos
programa de reuso
Processos de engenharia
de usabilidade
desenvolvimento
centrado no humano
Processo
de
compreenso
e
especificao
do
84
2.4.3
Processo de produo de
solues de projeto
Processo de avaliao
das solues de projeto
2.4.4
ISO/TR 18529:2000
HCD 5
ISO/TR 18529:2000
HCD 6
contexto de uso
Processo de produo de
solues de projeto
Processo de avaliao
dos projetos em relao
aos requisitos
4.1.2 Definio dos Processos de Usabilidade

Esta parte do trabalho visa justificar a definio dos processos de
usabilidade que so integrados ao modelo de maturidade/capacidade do
processo de software.
A definio dos processos de engenharia de usabilidade baseada em
uma comparao e mapeamento de processos de Engenharia de Usabilidade
de vrios modelos de referncia, apresentado no subcapitulo 3.7 (Mapeamento
dos modelos de referncia de engenharia de usabilidade).
A Tabela 5 ilustra a forma como os processos e prticas bases
unificadas correspondem a processos da ISO / IEC 12207, utilizada como base
para o modelo de referncia de processo de software, ou a atributos da
estrutura de medio definido pela norma ISO / IEC 15504.
Com base nos resultados desta avaliao de correspondncia, as
decises sobre a forma de integrar os respectivos processos e prticas no
SPCMM proposto so mostradas na Tabela 5 (Colunas 5-6).
Tabela 5 Mapeamento dos processos e prticas unificadas em relao aos processos das ISO/IEC
15504 e ISO/IEC 12207
Processos e Prticas Unificadas
Correspondentes
Deciso de design do
Modelo
Processos
/
Processos
Prticas Bases
Prticas
Atributo de
Prticas Bases
Processos
Bases
Unificados
Unificadas
Processo
Processo
Inexistente
Inexistente
Integrado
Integradas
Representar os
de gesto Stakeholders;
totalmente
as prticas
do
no modelo. como
as
Coletar inteligncia de
desenvolv mercado;
Novo
mesmas
imento
processo
foram
Definir e planejar uma
centrado
chamado:
definidas
estratgia do sistema;
no
Gesto
do no
novo
Coletar opinies do
humano
desenvolvim processo.
Mercado;
ento
centrado no
Analisar as tendncias
humano
dos usurios;
Planejam
ento e
gerencia
mento do
processo
Consultar
Stakeholders;
os
Planejar
envolvimento
o
dos
PA 2.1 Atributo
de gerncia
de execuo ISO/IEC
15004
Identificar
objetivos
execuo
processo;
Planejar
os
de
do
e
No houve a
necessidade
de
integrao
Mantidas
as prticas
do atributo
de
processo
85
de
desenvolv
imento
centrado
no
humano.
usurios;
Selecionar tcnicas
centradas no humano;
Assegurar
uma
abordagem centrada no
humano;
Planejar e gerenciar
atividades
de
desenvolvimento
centrado no humano;
Defender
abordagem
desenvolvimento;
a
de
Apoiar
desenvolvimento
centrado no humano;
Especifica
o dos
requisitos
do
usurio e
os
organizaci
onais.
Esclarecer
os
objetivos do sistema;
Definir
Stakeholders;
os
Avaliar os riscos para

as partes interessadas;
Definir o sistema;
Produzir
requisitos;
6.4.1
Processo de
definio dos
requisitos dos
Stakeholders ISO/IEC
12207
os
Definir a qualidade
dos objetivos em uso;
Especifica
o do
contexto
de uso
Identificar
e
documentar as tarefas
dos usurios;
Identificar
documentar
caractersticas
usurios;
monitorar
a
execuo
do
processo;
Ajustar
a
execuo
do
processo;
Definir
responsabilidade
e autonomia para
execuo
do
processo;
Identificar
e
disponibilizar
recursos
para
execuo
do
processo;
Gerenciar
o
relacionamento
entre as partes
envolvidas;
Identificao
dos
Stakeholders;
Identificao
dos requisitos;
Avaliao dos
requisitos;
Acordo
dos
requisitos;
Registro
dos
requisitos;
PA 2.1
No houve a
necessidade
de
integrao
Mantidas
as prticas
do
processo
6.4.1
Inexistente
Inexistente
Integrado
totalmente
no modelo.
Novo
processo
chamado:
Especifica
o
do
contexto de
uso
Integradas
as prticas
como
as
mesmas
foram
definidas
no
novo
processo.
Inexistente
Inexistente
Integrado
totalmente
no modelo.
Novo
processo
chamado:
Produo de
solues de
projeto.
Integradas
as prticas
como
as
mesmas
foram
definidas
no
novo
processo.
e
as
dos
Identificar
e
documentar o ambiente
organizacional;
Identificar
e
tcnico;
Identificar
e
fsico;
Produo
de
solues
de projeto
Alocar funes;
Produzir modelo de
tarefas;
Explorar o projeto do
sistema;
Usar
o
conhecimento existente
para
desenvolver solues
86
de design;
Especificar o sistema
e o uso;
Desenvolver
prottipos;
Desenvolver
treinamento para
usurios;
os
Desenvolver
o
suporte aos usurios;
Avaliao
das
Solues
de Projeto
Especificar o contexto
de avaliao;
Inexistente
Inexistente
Integrado
totalmente
no modelo.
Novo
processo
chamado:
Avaliao
das
Solues de
Projeto
Integradas
as prticas
como
as
mesmas
foram
definidas
no
novo
processo.
6.4.9
Processo
Operao de
software ISO/IEC
12207
Prepara para a
operao;
Teste
operacional
e
check-out;
Uso
operacional;
Suporte
ao
cliente;
Resoluo de
problema
de
operao;
No houve a
necessidade
de
integrao
Mantidas
as prticas
do
processo
6.4.9
Avaliar os primeiros
prottipos, a fim de
definir os requisitos para
o
sistema
Avaliar
melhorias no projeto;
Avaliar os prottipos,
a fim de melhorar o
projeto;
Avaliar o sistema, a
fim de verificar se os
requisitos
dos
stakeholders
e
organizacionais foram
cumpridos;
Avaliar o sistema a
fim de verificar que a
prtica desejada foi
seguida;
Avaliar o sistema em
uso, a fim de garantir
que ele continua a
satisfazer
as
necessidades
organizacionais e dos
usurios;
Introdu
oe
operao
do
sistema.
Gerenciar mudanas;
Determinar impactos;
Customizao
projeto no local;
Oferecer treinamento
aos usurios;
Suporte aos usurios;
Conformidade com os
requisitos ergonmicos;
4.2 Framework de Medio

O framework de medio, em relao representao contnua,
baseado nos nveis de capacidade da parte 2 da ISO/IEC 15504. J os nveis
87
de maturidade da parte 7 da mesma norma so utilizados como referncia para

a avaliao da maturidade organizacional.
4.2.1 Definio da Capacidade do Processo

Na norma ISO/IEC 15504, em sua parte 2, a capacidade de um
processo pode ser caracterizada em uma escala de 6 pontos, do nvel
incompleto ao nvel otimizado. No nvel incompleto o processo no executado
nem consegue alcanar a sua finalidade (ISO/IEC, 2006).
Cada nvel intermedirio que o processo melhora sua capacidade, o
mesmo fica mais prximo de atingir seus objetivos de negcio e quando atinge
o nvel otimizado, este previsvel e melhorado continuamente (ISO/IEC,
2006).
Nesta estrutura de medio, a capacidade baseada em um conjunto
de atributos de processos, aonde cada um define um aspecto particular desta
capacidade. A determinao do nvel de capacidade do processo feita pela
combinao do alcance do atributo com o agrupamento definido de atributos de
processo.
O quadro 18 mostra os nveis de capacidade e seus respectivos
atributos de processo.
Quadro 18 Nveis de Capacidade e seus respectivos atributos de processo - Fonte: Adaptado de
ISO/IEC, 2006.
Nvel
de Definio
do Atributos
Definio dos atributos de processos
capacidade
nvel
de de
capacidade
processo
Nvel
0: O processo no
Incompleto
executado
nem consegue
alcanar a sua
finalidade.
Nvel
1: O processo PA
1.1 O atributo de execuo do processo uma medida do grau com
Executado
executado
e Atributo de que o propsito do processo atingido. O resultado do alcance
consegue
execuo
completo deste atributo :
alcanar
sua do
a) O processo atinge seus resultados definidos;
finalidade.
processo
88
Nvel
2:
Gerenciado
Nvel
3:
Estabelecido
O processo
executado
de
uma
forma
controlada
e
seus produtos
de trabalho so
estabelecidos,
controlados
e
mantidos.
O
processo
controlado
executado
utilizando
um
processo
definido,
baseado em um
processo
padro,
que
seja capaz de
alcanar
os
resultados
esperados.
PA
2.1
Atributo de
gerncia de
execuo
O atributo de gerncia de execuo uma medida da extenso

na qual a execuo do processo gerenciada. Os resultados do
alcance completo deste atributo so:
a) Os objetivos para a execuo do processo so identificados;
b) A execuo do processo planejada e monitorada;
c) A execuo do processo ajustada para atender aos planos;
d) As responsabilidades e autoridades para execuo do
processo so definidas, atribudas e comunicadas;
e) Os recursos e as informaes necessrias para a execuo
do processo so identificados, alocadas e utilizadas;
f) As interfaces entre as partes envolvidas so gerenciadas para
garantir tanto a comunicao efetiva quanto a atribuio claras
das responsabilidades;
PA
2.2
Atributo de
gerncia de
produto de
trabalho
O atributo de gerncia de produto de trabalho uma medida da

extenso na qual os produtos de trabalho so gerenciados
apropriadamente. Os resultados do alcance completo deste
atributo so:
a) Os requisitos para produtos de trabalho do processo so
definidos;
b) Os requisitos para a documentao e controle dos produtos
de trabalho so definidos;
c) Os produtos de trabalho so identificados, documentados e
controlados apropriadamente;
d) Os produtos de trabalho so revisados de acordo com o
planejado e ajustados, quando necessrio, para atender os
requisitos;
O atributo de definio de processo uma medida da extenso
na qual um processo-padro mantido para apoiar a
implementao do processo definido. Os resultados do alcance
completo deste atributo so:
a) Um processo-padro, incluindo diretrizes apropriadas para
sua adaptao, definido para descrever os elementos
fundamentais que devem ser incorporados num processo
definido;
b) A sequencia e interao do processo-padro com outros
processos so determinadas;
c) As competncias e papis requeridos para a execuo do
processo so identificados como parte do processo-padro;
d) A infraestrutura e o ambiente de trabalho requeridos para
execuo de um processo so identificados como parte do
processo-padro;
e) Os mtodos apropriados para monitorar a eficcia e
adequada dos processos so determinados
O Atributo de implementao de processo uma medida da
extenso na qual o processo-padro efetivamente
implementado como um processo definido para atingir seus
resultados. Os resultados do alcance completo deste atributo
so:
a) Um processo definido implementado com base em um
processo-padro apropriadamente selecionado e/ou adaptado;
b) Os papis, responsabilidades e autoridades requeridas para
a execuo do processo definido so atribudos e comunicados;
c) As pessoas que executam o processo definido so
competentes em termos de educao, treinamento e
experincia apropriados;
PA
3.1
Atributo de
definio
de
processo
PA
3.2
Atributo de
implementa
o
de
processo
89
Nvel
4:
Previsvel
O
processo
estabelecido
opera
agora
dentro
dos
limites definidos
para conseguir
seus resultados
esperados.
PA
4.1
Atributo de
medio de
processo
PA
4.2
Atributo de
controle de
processo
Nvel
5:
Otimizao
O
processo
previsvel
melhorado
continuamente
para alcanar os
objetivos
de
negcio.
PA
5.1
Atributo de
inovao
de
processo
d) Os recursos e informaes requeridos para a execuo do

processo definido so disponibilizados, alocados e utilizados;
e) A infraestrutura e o ambiente de trabalho requerido para a
execuo do processo so disponibilizados, gerenciados e
mantidos;
f) Dados apropriados so coletados e analisados, constituindo
uma base para o entendimento do comportamento do processo,
para demonstrar a adequao e eficcia do processo, e avaliar
onde pode ser feita a melhoria continua do processo;
O atributo de medio de processo uma medida que quantifica
a utilizao dos resultados de medies para garantir que a
execuo do processo apoie o alcance de objetivos relevantes
de desempenho deste, para suportar o alcance das metas
definidas para o negcio. Os resultados do alcance completo
deste atributo so:
a) As necessidades de informao de processo so
estabelecidas para apoiar o alcance de metas de negcio
definidas e relevantes;
b) Os objetivos de medio de processo so derivados de
necessidades de informao de processo;
c) Os objetivos quantitativos para o desempenho do processo
so estabelecidos em apoio ao alcance de metas relevantes de
negcio;
d) As medidas e frequncias de medies so identificadas e
definidas de forma alinhada com os objetivos de medio de
processo e os objetivos quantitativos para o desempenho do
processo;
e) Os resultados da medio so coletados, analisados e
comunicados para monitorar a extenso na qual os objetivos
quantitativos para o desempenho do processo so alcanados;
f) Os resultados de medio so usados para caracterizar o
desempenho do processo;
O atributo de controle de processo uma medida da extenso
na qual o processo gerenciado quantitativamente, resultando
em um processo estvel, capaz e previsvel dentro de limites
definidos. Os resultados do alcance completo deste atributo so:
a) Tcnicas de anlise e controle so determinadas e aplicadas
onde apropriado;
b) Limites de controle de variao so estabelecidos para o
desempenho normal do processo;
c) Dados de medio so analisados para identificar causas
especiais de variao;
d) Aes corretivas so tomadas para tratar as causas especiais
de variao;
e) Limites de controle so estabelecidos (se necessrio)
seguindo a ao corretiva;
O atributo de inovao de processo uma medida da extenso
na qual as mudanas ocorridas no processo so identificadas
atravs de anlises das causas comuns de variao em sua
execuo e da investigao de abordagens inovadoras para a
definio e implementao do processo. Os resultados do
alcance completo deste atributo so:
a) Objetivos de melhoria de processo so definidos para o
processo em questo, a fim de apoiar os objetivos de negcios
relevantes;
b) Dados apropriados so analisados para identificar as causas
comuns das variaes na execuo do processo;
c) Dados apropriados so analisados para identificar
oportunidades para melhores prticas e inovao;
d) Oportunidades de melhoria derivadas de novas tecnologias e
novos conceitos de processo so identificadas;
90
e) Uma estratgia de implementao estabelecida, visando

atingir os objetivos de melhoria do processo;
PA
5.2
Atributo de
otimizao
de
processo
O atributo de otimizao de processo uma medida da

extenso na qual as mudanas na definio, gerenciamento e
execuo do processo resultam em um impacto eficaz, que
atende aos objetivos relevantes de melhoria do processo. Os
resultados do alcance completo deste atributo so:
a) O impacto de todas as mudanas propostas avaliado em
relao aos objetivos do processo definido e do processo
padro;
b) A implementao de todas as mudanas acordadas
gerenciada para garantir que qualquer mau funcionamento da
execuo do processo seja compreendido e aes sejam
tomadas;
c) A eficcia da mudana no processo, com base na execuo
real, avaliada com relao aos requisitos definidos para o
produto e aos objetivos do processo, visando determinar se os
resultados so devido a causas comuns ou especiais.
A extenso do alcance de um atributo de processo classificada

utilizando a escala ordinal apresentada no quadro 19.
Quadro 19 Escala de classificao dos atributos de processo - Fonte: Adaptado de ISO/IEC, 2006.
Classificao
Definio
Percentual de alcance
N (No atingido)
Existe pouco ou nenhuma evidncia do 0 a 15% de alcance
alcance do atributo definido no processo
avaliado
P
(Parcialmente Existe alguma evidncia do alcance do > 15% a 50% de
atingido)
atributo definido no processo avaliado. alcance
Alguns aspectos de alcance do atributo
podem ser imprevisveis
L
(Largamente Existe
evidncia
de
aproximao > 50% a 85% de
atingido)
sistemtica e de alcance significativo do alcance
atributo definido no processo avaliado.
Podem existir alguns pontos fracos
relacionados com este atributo no
processo avaliado
F
(Completamente Existe evidencia de uma aproximao > 85% a 100% de
atingido)
completa e sistemtica e de alcance total alcance
do atributo definido no processo
avaliado. No existem pontos fracos
significativos relacionados com este
atributo no processo avaliado
Cada atributo de processo classificado seguindo a escala ordinal

definida no quadro 19. A cada pontuao de atributo de processo atribudo
um identificador que registre o nome do processo e o atributo de processo
avaliado.
O nvel de capacidade atingido por um processo derivado das
pontuaes de seu atributo, de acordo com o modelo de nvel de capacidade
de processo definido no quadro 20.
91
Quadro 20 Pontuaes de nvel de capacidade - Fonte: Adaptado de ISO/IEC, 2006.

Nvel
de Atributos de processo
Pontuao
capacidade
Nvel
1: Execuo de Processo
Largamente ou completamente
Executado
Nvel
Completamente
Gerenciado
Gerncia de Execuo
Gerncia de Produto de Trabalho
Nvel
Completamente
Estabelecido Gerncia de Execuo
Completamente
Completamente
Definio de Processo
Implementao de Processo
Nvel
Completamente
Previsvel
Gerncia de Execuo
Completamente
Completamente
Definio de Processo
Completamente
Completamente
Medio de Processo
Controle de Processo
Nvel
Completamente
Otimizao
Gerncia de Execuo
Completamente
Completamente
Definio de Processo
Completamente
Completamente
Medio de Processo
Completamente
Controle de Processo
Completamente
Inovao de Processo
Otimizao de Processo
4.2.2 Definio da Maturidade Organizacional

A norma ISO/IEC 15504, em sua parte 7, define maturidade
organizacional como uma expresso do grau em que uma organizao
implementa seus processos de forma madura, dentro de um escopo definido,
contribuindo para a realizao dos objetivos de negcio atuais ou futuros
(lSO/IEC, 2008).
Esta parte da norma estabelece uma escala que caracteriza a
maturidade da organizao no mbito organizacional utilizado, onde cada nvel
tem como base o cumprimento do nvel anterior. Na tabela 6, os nveis de
maturidade so apresentados:
Nveis de
Maturidade
0 - Imaturo
Tabela 6 Nveis de Maturidade - Fonte: Adaptado de ISO/IEC, 2008.

Caractersticas dos
Benefcios ao atingir este nvel
Nvel de avaliao
Processos
dos processos
A
organizao
no
demonstra a aplicao
eficaz dos processos.
Pelo
menos
um
processo do conjunto
bsico de processos
avaliado no nvel
de capacidade 0.
92
1 Bsico
A
organizao
demonstra que atinge os
objetivos dos processos.
2 - Gerenciado
A
organizao
demonstra que consegue
gerenciar os processos.
3 - Estabelecido
A
organizao
demonstra
a
efetiva
definio e implantao
dos processos.
a) A organizao implementa os
processos
requeridos
para
suportar o seu negcio;
b) A organizao executa um
conjunto de atividades e tarefas
que atingem o propsito destes
processos
a) A organizao estabelece
planos
de
execuo
dos
processos que so fundamentais
para suportar seu negcio;
b) A organizao age para
assegurar a comunicao efetiva
em relao execuo dos
processos, atravs da atribuio
de responsabilidade e autoridade
das partes envolvidas;
c) A organizao aloca recursos
adequados para assegurar a
implementao dos planos;
d) A organizao monitora o
desempenho dos processos em
relao aos planos nas instncias
individuais;
e) A organizao toma aes para
tratar desvios do desempenho
planejado do processo;
f)
A
organizao
identifica
requisitos para gerenciar produtos
de trabalho desenvolvidos pelos
processos;
g) A organizao toma aes
atravs de revises apropriadas e
mecanismos de controles para
assegurar que os requisitos da
gerncia de produtos de trabalho
sejam satisfeitos;
Todos os processos
do conjunto bsico
de processos so
avaliados no nvel de
capacidade 1 ou
mais alto.
descries do processo padro
cobrindo todo o conjunto de
processos bsicos e estendidos
empregado como rotina bsica
desta;
b) A organizao assegura que
implementaes individuais de
processos so executadas como
processo
definido
com
a
adaptao
apropriada
dos
processos padro;
c) A organizao coleta e analisa
os dados e informaes de
desempenho do processo definido
e armazena estes dados para
uso;
d) A organizao usa os dados e
as informaes coletadas para
melhoria dos processos definido e
Todos os processos
do conjunto bsico
de processos so
capacidade 3 ou
mais alto.
O conjunto estendido
de processos para o
nvel de maturidade 2
incorpora processos
adicionais
que
asseguram que os
processos
sejam
estabelecidos
e
implementados
usando o processo
definido que capaz
de
alcanar
sua
sada. Os processos
do
conjunto
Todos os processos
do conjunto bsico
de processos so
capacidade 2 ou
mais alto.
de processos para o
incorpora processos
adicionais
que
asseguram
o
gerenciamento
do
desempenho
de
processo
e
a
integridade
do
produto de trabalho.
Os processos do
conjunto
estendido
de processo so
capacidade 2 ou
mais alto.
93
padro;
4 - Previsvel
A
organizao
demonstra
uma
compreenso
quantitativa
dos
processos.
objetivos
quantitativos
de
desempenho
de
processo,
baseados nos objetivos de
negcio;
b) A organizao seleciona
processos
para
anlise
de
desempenho
de
processo,
cobrindo no mnimo o conjunto de
processos bsicos, com base na
sua relevncia e significncia para
alcance dos objetivos de negcio;
c)
A
organizao
emprega
medies efetivas para coletar,
armazenar e analisar dados do
desempenho
dos
processos
selecionados;
d) A organizao identifica causas
especiais
de
variao
no
desempenho
dos
processos
selecionados e toma as aes
corretivas
e
preventivas
apropriadas para trata-las;
e) A organizao estabelece
desempenho estvel, capaz e
previsvel
dos
processos
selecionados dentro de limites de
controle.
5 - Inovao
A
organizao
demonstra a habilidade
de mudar e adaptar-se
ao desempenho dos
processos.
a) A organizao identifica causas

comuns
de
variao
no
desempenho
do
processo,
baseada nos resultados das
anlises de desempenho do
processo, e identifica melhorias
candidatas para tratar, luz dos
objetivos de negcio;
b) A organizao identifica
inovaes com potencial para
melhorar o desempenho de
processo e sucesso do negcio;
c)
A
organizao
identifica
oportunidades para realizar pilotos
de melhorias incrementais e
inovativas com controle de riscos
associados;
d) A organizao coleciona e
analisa
dados
das
estendido
de
processo
so
capacidade 3 ou
mais alto
Pelo
menos
um
bsico de processos,
selecionado
com
base
na
sua
relevncia
e
significncia
para
suportar os objetivos
de
negcio
da
organizao,
avaliado no nvel 4
ou mais alto.
de processos para o
incorpora processos
adicionais
que
suportam o alcance
do
entendimento
quantitativo
do
desempenho
dos
processos relevantes
no
perfil
de
processos global da
organizao.
Os
processos
do
conjunto
estendido
de processos so
capacidade 3 ou
mais alto, um ou
mais processos do
conjunto
estendido
pode(m)
ser
avaliados(s) no nvel
de capacidade 4 ou
mais alto.
Pelo
menos
um
bsico de processos,
selecionado
com
base
na
sua
relevncia
e
significncia
para
suportar os objetivos
de
negcio
da
organizao,
avaliado no nvel 5.
de processos para o
incorpora processos
adicionais
que
suportam a melhoria
contnua e previsvel
do desempenho do
94
implementaes-piloto, e usa os
resultados das anlises para
selecionar
melhorias
para
implementao na organizao
com base nos seus impactos no
desempenho do processo e
sucesso do negcio;
e) A organizao implementa as
melhorias,
monitora
o
desempenho das melhorias de
processos
e
compara
os
resultados das melhorias com
valores esperados
processo.
Os
processos
do
conjunto
estendido
de processos so
capacidade 3 ou
mais alto, um ou
mais processos do
conjunto
estendido
pode(m)
ser
avaliados(s) no nvel
de capacidade 5.
Nesta estrutura, cada nvel de maturidade caracterizado pela

demonstrao do alcance dos nveis especificados de capacidade de processo,
em conjunto de processos retirados do modelo de avaliao de processo
definido.
Os processos so categorizados com base na sua contribuio para se
atingir os objetivos de negcio. O conjunto de processos bsicos so aqueles
fundamentais para suportar o objetivo de negcio.
Cada nvel de maturidade, acima do nvel 1, caracterizado pela
implementao de um conjunto de processos que direciona o alcance das
capacidades relevantes para cada nvel de maturidade. Estes processos
pertencem ao conjunto de processos estendidos.
O modelo de maturidade apresenta um domnio especfico de aplicao.
O domnio para o modelo proposto englobar todo tipo de sistema que possua
alguma interao com o ser humano, excluindo-se os que no necessitam
desta interao, como por exemplo, os sistemas embarcados.
O modelo especifica um subconjunto contnuo de nveis de maturidade,
definidos no framework de medio, comeando no nvel 1 e para todos os
nveis de maturidade dentro do escopo.
O modelo de maturidade inclui um conjunto de elementos a partir do
modelo de avaliao de processo, constituindo o processo bsico ajustado
para o modelo. O conjunto de processos bsicos inclui uma lista mnima de
elementos que definem o nvel 1 de maturidade, elementos adicionais que so
requeridos em avaliaes em domnios especficos e elementos adicionais
opcionais.
As especificaes para incluso de processos adicionais no conjunto de
processos bsicos, em circunstncias particulares, esto includas no modelo.
95
O modelo tambm define os processos que constituem o conjunto de

processos bsicos, com base no modelo de referncia do processo.
O modelo de maturidade inclui um conjunto de elementos constituindo
os conjuntos de processos estendidos para cada nvel de maturidade. Estes
conjuntos incluem um conjunto mnimo de elementos que definem o nvel
especificado de maturidade, elementos adicionais requeridos para avaliaes
em escopos particulares e elementos adicionais opcionais.
As especificaes para incluso de processos adicionais no conjunto de
processos estendidos, em circunstncias particulares, esto includas no
modelo. O modelo tambm define os processos que constituem o conjunto de
processos estendidos, com base no modelo de referncia do processo.
Com base no exemplo de modelo de maturidade organizacional
apresentado no Anexo A da ISO / IEC 15504-7, o conjunto de processos,
inclusive os quatros novos processos de engenharia de usabilidade, foram
associados aos nveis de maturidade, como indicado no quadro 21.
Os processos 2.4.2 Especificao do contexto de uso, 2.4.3 Produo
de solues de projeto e 2.4.4 Avaliao das Solues de Projeto que
representam processos tcnicos do ciclo de vida da engenharia de usabilidade
esto associadas ao conjunto mnimo de processos do nvel de maturidade 1,
em correspondncia a associao de processos tcnicos de software para este
nvel de maturidade tais como a anlise dos requisitos do sistema, construo
de software, etc.
O processo 2.4.1 Gesto do desenvolvimento centrado no ser humano
est associado ao nvel de maturidade 3, devido ao foco do nvel 3 na gesto
organizacional e estratgica.
Como a base para a dimenso do processo do SPCMM estendido foi a
ISO / IEC 12207, os processos do modelo de maturidade organizacional
exemplar
(ISO
IEC
15504-5)
foram
substitudos
pelos
processos
correspondentes da ISO / IEC 12207, como mostrado no quadro 21.

Quadro 21 Processos associados aos nveis de maturidade
Lista de Processos
Conjunto
Processos Adicionais
Mnimo
Identificao
Condies
1.4.1 Definio dos requisitos dos Stakeholders
1.4.1
1.4.2
Necessrio quando o
1.4.2 Anlise dos requisitos do sistema
1.4.4
1.4.3
desenvolvimento
1.4.3 Projeto de arquitetura do sistema
1.4.5
abrange questes de
1.4.4 Implementao
2.1.2
1.4.6
sistema.
Conjun
to
Bsico
de
Proces
sos
ML
96
2.1.2 Anlise das especificaes do software

2.1.3 Projeto de arquitetura de software
2.1.4 Processo de software
2.1.5 Construo do software
2.1.6 Integrao do software
2.1.7 Teste de qualificao de software
1.4.5 Integrao do sistema
1.4.6 Teste de qualificao do sistema
1.4.7 Instalao do software
1.4.8 Suporte de aceitao de software
1.4.9 Operao de software
1.4.10 Manuteno do software
1.4.11 Desativao de software
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.4.2
2.4.3
2.4.4
1.4.7
1.4.8
1.4.9
1.4.10
1.4.11
Necessrio quando a
organizao
responsvel
pela
instalao
do
produto de software
no
ambiente
do
cliente
Necessrio quando a
organizao
responsvel
pela
manuteno
e
evoluo
permanente
do
software
e/ou
sistema.
Conjunto Estendido de Processos
2.4.2 Compreenso e especificao do

contexto de uso
2.4.3 Produo da soluo HCD
2.4.4 Avaliao do projeto em relao
aos requisitos HCD
2.2.1 Gesto de documentao de software

2.2.2 Gesto de configurao de software
2.2.3 Garantia de qualidade de software
2.2.4 Verificao de software
2.2.5 Validao de software
2.2.6 Reviso de software
2.2.8 Resoluo de problemas de software
2.2.9 Gesto de solicitaes de mudana
1.3.1 Planejamento de projeto
1.3.2 Controle e avaliao de projeto
1.3.3 Tomada de deciso
1.3.4 Gesto de risco
1.3.5 Gesto de configurao
1.3.6 Gesto de informao
2.2.1
2.2.2
2.2.3
2.2.4
2.2.8
2.2.9
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.1.1
2.2.5
2.2.6
1.1.1 Aquisio
1.1.2 Fornecimento
1.1.2
Necessrio quando
fornecedores
internos ou externos
esto envolvidos em
projetos
de
desenvolvimento
Necessrio quando a
confirmao
da
aptido
para
utilizao
dos
produtos de trabalho
de
responsabilidade da
organizao
Opcional quando o
trabalho
na
organizao envolve
acordos
com
os
stakeholders.
Opcional quando o
trabalho
na
organizao envolve
apoio de aceitao
de produto.
97
1.2.1 Gesto de modelo de ciclo de vida

1.2.2 Gesto de infraestrutura
1.2.3 Gesto de portflio de projetos
1.2.4 Gesto de recursos humanos
1.2.5 Gesto de qualidade
1.2.6 Gesto organizacional
1.3.7 Gesto de medio
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.3.7
2.2.7
2.4.1
2.3.1
2.3.2
2.3.3
Opcional
se
a
organizao tem um
programa
de
reutilizao
estruturado em vigor.
2.2.7 Auditoria de software

2.3.1 Engenharia de domnio
2.3.2 Gesto de reuso de ativos
2.3.3 Gesto de programa de reuso
2.4.1 Gesto do desenvolvimento

centrado no humano
4
5
1.2.7 Gesto do desempenho quantitativo

1.2.8 Melhoria de processo quantitativa
4.3 Descrio Detalhada dos Processos de Engenharia de Usabilidade

Adicionados
A seguir, os quatro processos de engenharia de usabilidade adicionados
na extenso so descritos nos mesmos moldes das descries de processos
da norma ISO/IEC 15504, com nome, objetivo, resultados e prticas-base.
ID do Processo
Nome do Processo
Objetivo do Processo
2.4.1
Gesto do desenvolvimento centrado no humano
O objetivo do processo de gesto do desenvolvimento centrado no
humano estabelecer e manter foco sobre as questes dos
stakeholders e dos usurios em cada parte da organizao que
lidam com mercado de sistemas, conceito, desenvolvimento e
suporte.
Resultados do Processo
Como resultado da implementao bem-sucedida do processo de

gesto do desenvolvimento centrado no humano:
a) O marketing levar em considerao usabilidade, ergonomia e
questes scio tcnicas;
b) Os sistemas atendero as necessidades e expectativas dos
usurios;
c) Os projetistas levaro em considerao os stakeholders e os
requisitos organizacionais;
d) Os sistemas sero mais suscetveis s mudanas dos usurios
(suas necessidades, tarefas, contexto, etc);
e) A empresa ser mais susceptvel s mudanas dos usurios; e
f) Os sistemas sero mais aceitos pelo mercado;
PB1: Representar os Stakeholders: Atuar como advogado dos
usurios finais e dos stakeholder na empresa e na equipe de
Prticas-base
PB2: Coletar inteligncia de mercado: Realizar investigao

prospectiva em grupos de usurios potenciais, a fim de identificar
necessidades futuras, novos usurios ou organizaes usurios
98
para o sistema. Estabelecer procedimentos para descobrir a

aceitao dos usurios no contexto esperado.
PB3: Definir e planejar uma estratgia do sistema: Obter
informaes
sobre
o
mercado atual
como uma
viso. Operacionalizar esta
viso
em
estratgia
de
implementao. Utilize ciclo de vida de contabilidade de custos, a
fim de avaliar o custo de uma abordagem HCD.
PB4.
Coletar
opinies
do
Mercado:
Executar pesquisa otimizada para refinar e consolidar a estratgia
do sistema, com base no feedback dos usurios e no usurios no
mercado do sistema.
PB5. Analisar as tendncias dos usurios: Procure mudanas
em: usurios (por exemplo, suas habilidades e treinamento para
organizaes de usurios, bem como as necessidades e desejos
de produtos de consumo), tarefas (por exemplo, mudanas no
tipo de trabalho ou de volumes de trabalho), contexto (por exemplo,
mudanas em ambientes de trabalho e de vida, as novas
tecnologias,
costumes
sociais e
polticos e
as
informaes
para estimar
as
ID do Processo
Nome do Processo
Prticas-base
2.4.2
Especificao do contexto de uso
O objetivo do processo de compreenso e especificao do
contexto de uso identificar, esclarecer e registrar as
caractersticas dos stakeholders, suas tarefas e do ambiente
organizacional e fsico que o sistema ir operar.
compreenso e especificao do contexto de uso:
a) Definio das caractersticas dos usurios;
b) Definio das tarefas que os usurios devem realizar;
c) Definiao da organizao e do ambiente em que o sistema
utilizado; e
d) O contexto de uso conhecido e levado em considerao
durante todo o ciclo de vida de desenvolvimento;
PB1: Identificar e documentar as tarefas dos usurios:
Descrever as atividades que os usurios executam para atingir os
objetivos do sistema.
NOTA 1 - As tarefas so descritas em termos de usurio e
atividades organizacionais, no apenas em termos de funes do
equipamento ou recursos.
NOTA 2 - As tarefas podem mudar (ou evoluir) durante o ciclo de
vida do sistema
PB2: Identificar e documentar as caractersticas dos usurios:
Descrever as caractersticas relevantes dos usurios. Isso ir
incluir o conhecimento, a linguagem, as capacidades fsicas, nvel
de experincia com as tarefas do trabalho e dos equipamentos
relevantes do sistema.
PB3: Identificar e documentar o ambiente organizacional:
Descrever os meios sociais e organizacionais relevantes, estrutura
de gesto e prticas organizacionais, etc.
PB4. Identificar e documentar o ambiente tcnico: Descrever as
caractersticas relevantes de qualquer equipamento a ser utilizado.
99
Uma ateno especial deve ser dada ao equipamento com o qual

os usurios interagem diretamente.
NOTA 3 - Para novos sistemas as caractersticas do equipamento
dependem das solues de projeto do sistema e no sero
conhecidas no inicio do ciclo de vida.
PB5. Identificar e documentar o ambiente fsico: Descrever o
local, equipamentos de trabalho e condies ambientais. Por
exemplo, iluminao, rudo, vibrao, etc.
ID do Processo
Nome do Processo
Prticas-base
2.4.3
Produo de solues de projeto
O objetivo do processo de produo de solues de projeto criar
possveis solues de projeto recorrendo a prticas estabelecidas
no estado da arte, a experincia e o conhecimento dos
participantes e os resultados da anlise do contexto de uso.
produo de solues de projeto:
a) O sistema scio tcnico completo, em que todos os
componentes tcnicos operaram, ser considerado no projeto. ;
b) As caractersticas e necessidades dos usurios sero levadas
em considerao na compra de componentes do sistema;
c) As caractersticas e necessidades dos usurios sero levadas
em considerao na concepo do sistema;
d) Conhecimentos existentes sobre engenharia de sistemas scio
tcnicos, ergonmicos, psicologia, cincia cognitiva e outras
disciplinas relevantes sero integrados no sistema;
e) A comunicao entre os stakeholders ser melhorada, pois as
decises de projeto sero mais explicitas;
f) A equipe de desenvolvimento ser capaz de explorar vrios
conceitos de projetos antes de decidirem por um;
g) As opinies dos usurios finais e dos outros stakeholders sero
incorporadas ao projeto logo no incio do processo de
desenvolvimento;
h) Ser possvel avaliar vrias iteraes e alternativas de projetos;
i) A interface entre o usurio e os componentes de hardware,
software e organizacional do sistema ser projetada;
j) Treinamento dos usurios e suporte ser desenvolvido;
PB1: Alocar funes: Analisar o contexto de uso e as funes
necessrias e desempenho do sistema, para distribuir as funes
entre o homem, a mquina e componentes organizacionais do
sistema afim de satisfazer melhor cada funo.
PB2: Produzir modelo de tarefas: Desenvolver um modelo vivel
de novas tarefas do usurio a partir do conhecimento existente das
melhores prticas, os requisitos, o contexto de uso, a alocao de
restries de funo e projeto para o sistema.
PB3: Explorar o projeto do sistema: Gerar e analisar uma srie
de opes de projeto para cada aspecto do sistema relacionado
com a sua utilizao e seu efeito sobre os stakeholders.
PB4. Usar o conhecimento existente para desenvolver
solues de projeto: Aplicar informaes relevantes da cincia
humana na concepo do sistema. Incluir todos os stakeholders, os
requisitos organizacionais, o contexto de uso, as normas
internacionais, os requisitos legais, as patentes existentes, as boas
prticas, os guia de estilos e padres de projeto, etc. no projeto.
100
PB5. Especificar o sistema e o uso: Produzir um projeto para os

componentes relacionados aos usurios do sistema. Produzir
a descrio de como o sistema ser utilizado. Alterar o projeto em
relao ao feedback das avaliaes.
PB6. Desenvolver prottipos: Produzir solues de projeto mais
concretas atravs de simulaes, de modelos, etc. Desenvolver
simulaes ou implementao experimental de aspectos chaves do
sistema para testes com usurios ou stakeholders.
PB7. Desenvolver treinamento para os usurios: Identificar,
especificar e produzir o treinamento necessrio para que os
usurios relevantes possam executar as tarefas de forma eficaz
usando o sistema. Cobrir ou incluir todas alteraes propostas nos
processos de negcio, projeto de trabalho e tarefas.
PB8. Desenvolver o suporte aos usurios: Identificar, especificar
e produzir os servios de suporte ao usurio do sistema. Levar em
conta as alteraes propostas nos processos de negcio e de
projeto de trabalho.
ID do Processo
Nome do Processo
2.4.4
Avaliao das solues de Projeto
O objetivo do processo de avaliao dos projetos em relao aos
requisitos coletar feedback sobre o projeto em desenvolvimento.
Este feedback ser obtido dos utilizadores finais e de outras fontes
representativas.
avaliao dos projetos em relao aos requisitos:
a) O feedback ser fornecido para melhorar o projeto; ;
b) Haver uma avaliao se os objetivos organizacionais e dos
stakeholders foram atingidos ou no;
c) O uso em longo prazo do sistema ser monitorado;
No caso de avaliao para identificar melhorias para o sistema, a
implementao bem sucedida do processo ir demonstrar:
a) Problemas potenciais e possibilidades de melhorias na
tecnologia, no material de apoio, no ambiente fsico e
organizacional e treinamento;
b) Opo de projeto que melhor se encaixa aos requisitos
funcionais, dos stakeholders e dos organizacionais;
c) Feedback and outros requisitos dos usurios;
Prticas-base
No caso de avaliao para descobrir se os objetivos foram

atingidos, implementao bem sucedida do processo ir
demonstrar:
a) O quo bem o sistema atinge seus objetivos organizacionais;
b) Que um projeto particular atende aos requisitos de
desenvolvimento centrado no humano;
c) Conformidade com exigncias legais nacionais e internacionais;
PB1: Especificar o contexto de avaliao: Descrever e verificar
as condies em que um sistema testado ou avaliado. Descrever
o relacionamento e, especialmente, as discrepncias, entre o
contexto de avaliao e do contexto de uso.
PB2: Avaliar os primeiros prottipos, a fim de definir os
requisitos para o sistema: D referncia de sistemas adequados
de acordo com critrios relevantes. Testar a usabilidade de
sistemas concorrentes / alternativas e / ou sistemas conceitos. Use
prottipos para estimular a contribuio dos stakeholders aos
101
requisitos do sistema. Teste de estabilidade dos requisitos.

PB3: Avaliar os prottipos, a fim de melhorar o projeto: Gerar
e analisar uma srie de opes de projeto para cada aspecto do
sistema relacionado com a sua utilizao e seu efeito sobre os
stakeholders.
PB4. Avaliar o sistema, a fim de verificar se os requisitos dos
stakeholders e os organizacionais foram cumpridos: Testar o
desenvolvimento ou sistema final para garantir que ele atenda aos
requisitos dos usurios, das tarefas e do ambiente, conforme
definido na sua especificao.
PB5. Avaliar o sistema a fim de verificar que a prtica
desejada foi seguida: Verifique nos sistemas a adeso na
aplicao de cincias no conhecimento humano, guias de estilos,
normas, diretrizes e legislao.
PB6. Avaliar o sistema em uso, a fim de garantir que ele
continua a satisfazer as necessidades organizacionais e dos
usurios: Checar o sistema em uso para verificar mudanas nos
requisitos do usurio, organizacionais, dos stakeholders e
usabilidade e para garantir que o sistema continua a atender esses
requisitos.
102
5. Avaliao do Modelo Proposto

Neste captulo apresentada a avaliao do modelo proposto com o
objetivo de verificar se o mapeamento dos modelos de referncia de
engenharia de usabilidade est correto, se a conformidade, a qualidade, a
completude e se o modelo proposto est correto.
5.1 Definio
A avaliao realizada conforme definido no
subcapitulo 1.4
(Metodologia), por meio de um expert panel, um mtodo de avaliao emprica

baseada na opinio de especialistas, Beecham et al. (2005).
Para definir sistematicamente os dados a serem coletados na avaliao,
o mtodo GQM Goal/Question/Metric (BASILI et al., 1994)foi utilizado. O
mtodo GQM suporta a definio sistemtica de objetivos e a derivao de
perguntas que, quando respondidas, atendem estes objetivos. A Tabela 7
mostra as perguntas identificadas para cada um dos objetivos da avaliao.
Tabela 7 Perguntas da avaliao
Objetivo
Perguntas
Mapeamento
Os processos esto mapeados corretamente para um

conjunto de processos unificados?
Mapeamento
As prticas esto mapeadas corretamente para um conjunto

de prticas bases unificado?
Extenso do
A extenso proposta est em conformidade com a norma
SPCMM
ISO/IEC 15504?
Extenso do
Os processos e prticas de engenharia de usabilidade
SPCMM
propostos na extenso representam corretamente a mesma?
Extenso do
SPCMM
propostos na extenso so suficientes para atender os

objetivos da mesma?
Extenso do
SPCMM
propostos na extenso so consistentes com a definio do

processo de software conforme definido pela norma ISO/IEC
103
12207?
Extenso do
SPCMM
propostos na extenso no duplicam processos j definidos

pela norma ISO/IEC 12207?
Extenso do
A representao continua do framework de medio como
SPCMM
proposto definido pela norma ISO/IEC 15504-2 assim

como ela ?
Extenso do
A representao por estgios do framework de medio
SPCMM
como proposto definida pela norma ISO/IEC 15504-7

assim como ela ?
Extenso do
A associao proposta dos processos adicionados para os
SPCMM
nveis de maturidade representa adequadamente o caminho

evolucionrio recomendado para uma organizao que quer
melhorar os processos de engenharia de usabilidade?
Tambm referente aos objetivos de avaliao, quatro questes foram

elaboradas a fim de obter um feedback maior dos especialistas e encontrar os
pontos fortes, fracos e possveis pontos de melhorias no modelo. Estas
questes so apresentadas por objetivo na tabela 8.
Tabela 8 Questes descritivas da avaliao
Objetivo
Questes Descritivas
Mapeamento
Alguma sugesto de melhoria em relao ao mapeamento?
Extenso do
Em sua opinio, quais so os principais pontos fortes da
SPCMM
extenso proposta?
Extenso do
Em sua opinio, quais so os principais pontos fracos da
SPCMM
extenso proposta?
Extenso do
Alguma outra sugesto ou comentrio?
SPCMM
A partir da decomposio dos objetivos em perguntas foi elaborado um

questionrio para coletar dados referentes s questes identificadas. No
questionrio usado para as perguntas da tabela 7 uma escala likert de 5
pontos entre 1 (discordo totalmente) e 5 (concordo totalmente).
104
Alm disso, so includos perguntas de forma aberta referente s

questes descritivas (tabela 8).
5.2 Execuo
A execuo da avaliao ocorreu entre os dias 16 de abril a 06 de maio
de 2012.
Para esta avaliao, os especialistas foram selecionados por sua
expertise em relao a modelos de maturidade/capacidade de processo de
software, a engenharia de usabilidade ou a engenharia de software.
Basicamente,
foram
selecionados
os
autores
das
normas/artigos/estudos apresentados neste trabalho e outros considerados de

relevncia. Foram selecionados 30 especialistas para participarem desta
avaliao.
Estes especialistas foram convidados a participar do expert panel via email. Tambm foi disponibilizado um resumo do trabalho para que os
especialistas pudessem fazer a avaliao de forma mais efetiva. Este resumo
encontra-se no apndice A deste Trabalho.
Atravs da plataforma Google Docs (https://docs.google.com), o
questionrio foi disponibilizado para que os especialistas o respondessem na
forma de um formulrio web. O formulrio utilizado na avaliao encontra-se no
apndice B deste trabalho.
5.3 Anlise dos dados

Ao total, seis especialistas responderem a avaliao, representando uma
taxa de 20% de retorno.
Caracterizao dos Especialistas

Dentre os seis especialistas que responderam a avaliao, dois eram do
Brasil, um do Reino Unido, um da Esccia, um da Itlia e outro da Finlndia.
Possuam de dez a vinte anos de experincia com SPCMMs e, em relao
engenharia de usabilidade, dois no possuam experincia, um possua dois
anos, um possui 15 anos, outro possui 28 anos e o ltimo possua quarenta
anos de experincia na rea.
105
Destes especialistas, um no se sentiu confortvel para responder as

questes na escala likert e s respondeu s questes descritivas. Devido a
isso, o seu feedback foi levado em considerao apenas em relao as
sugestes de melhorias, os pontos fortes e fracos apontados.
Anlise das respostas referentes ao mapeamento dos modelos de

referncia de engenharia de usabilidade
Primeiramente, so analisadas as referentes ao mapeamento dos
modelos de referncia de engenharia de usabilidade.
Como se pode verificar nas figuras 24 e 25, a maioria dos especialistas
considerou que o mapeamento foi feito de forma correta, sendo que, apenas
um deles discordou parcialmente do mapeamento para o conjunto de
processos unificados.
Figura 24 - Grfico das respostas da 1 pergunta do Expert Panel.
Os especialistas sugeriram que a ISO / TS 18152:2010 - Ergonomics of

human-system interaction -- Specification for the process assessment of
human-system issues poderia ser til como recurso para o modelo quando
utilizado para grandes projetos.
106
Outra sugesto foi utilizao da ISO/IEC TR 24774:2010 - Systems

and software engineering -- Life cycle management -- Guidelines for process
description para descrever as definies dos processos adicionados.
Eles tambm sugeriram a utilizao de outros trabalhos e fontes que no
se encaixam no perfil dos modelos tpicos de maturidade para servir como
orientao para o mapeamento.
Anlise das respostas referentes extenso do SPCMM

Em relao conformidade com a ISO/IEC 15504 e, se a mesma
representa corretamente a engenharia de usabilidade, a maior parte dos
especialistas concordou com a extenso proposta, como pode ser visto nas
figuras 26 e 27.
Trs especialistas concordaram que a extenso proposta suficiente

para atingir os objetivos da engenharia de usabilidade, porm dois deles
discordaram, conforme mostra figura 28.
107
A maioria das respostas quanto consistncia na definio dos

processos de software, conforme definido pela norma ISO/IEC 12207, foi
positiva. Porm, um dos especialistas discordou parcialmente disto (Figura 29).
A figura 30 mostra que os especialistas no concordaram e nem

discordaram quando questionados se a extenso no repete nenhum
processo/prtica j definido na ISO/IEC 12207.
Os especialistas concordaram que a representao contnua da

proposta est em conformidade com a parte dois da ISO/IEC 15504 (Figura
108
31). J em relao representao em estgios, no houve um consenso

entre as respostas, como pode ser visto na figura 32.
Quando questionados se os processos adicionados aos nveis de

maturidade
representam
adequadamente
caminho
evolucionrio
recomendado para uma organizao melhorar seus processos de engenharia

de usabilidade, grande parte dos especialistas concordou com a extenso
proposta, porm, um deles discordou plenamente (Figura 33).
109
Pontos Fortes
Em relao aos pontos fortes, os especialistas concordam que o modelo
pode fornecer recursos para ajudar a promover a usabilidade dos produtos,
recursos estes, geralmente inexistentes nos modelos de referncia de
processos.
A utilizao da ISO/IEC 15504 e da ISO/IEC 12207, como modelos
base, foi apontada como ponto forte, assim como o detalhamento do trabalho
que, de acordo com um dos especialistas, suficiente para que o mesmo, aps
suas atualizaes, possa ser apresentado para o comit da ISO/IEC como uma
nova proposta de item de trabalho para estender os modelos de avaliao de
processo da srie ISO/IEC 33000.
Pontos Fracos
Os especialistas ressaltaram a falta da integrao com outras partes da
ISO/IEC 12207 que incluem aspectos de ergonomia. Outro ponto fraco
levantado foi que o modelo de processos precisa ser melhorado, utilizando-se
das definies da ISO / IEC 24774.
Eles tambm recomendaram que a ISO/IEC CD 15504-5:2003 seja
substituda pela ISO/IEC 15504-5:2012, tornando assim as referncias
utilizadas no modelo mais atuais.
Um dos especialistas alegou que as organizaes que desejarem
melhorar apenas o processo de software e de usabilidade, mas no outros
atributos de software, podem adaptar a ISO/IEC 15504 com outras normas,
montando o perfil que desejam avaliar ou melhorar, o que pode tornar o modelo
proposto desnecessrio.
Sugestes ou comentrios
Um dos especialistas sugeriu a excluso da extenso do modelo de
maturidade, pois os processos de engenharia de usabilidade que so de
maior interesse para o trabalho. E props a alterao do formato das respostas
em escala likert do expert panel para que elas permitam maiores comentrios.
Tambm foi sugerido que os processos adicionados no nvel 1 de
maturidade no possuam prticas que so necessrias apenas em nveis mais
elevados, e que o processo de gesto do desenvolvimento centrado no
110
humano seja alocado ao conjunto mnimo de processos do nvel 2 de

maturidade, pois lida com o planejamento e por isso, deve contribuir para um
planejamento global.
5.4 Discusso
Nesta avaliao os especialistas levantaram pontos fortes, pontos fracos
e sugestes de melhorias para o modelo. A atualizao e aprimoramento do
modelo proposto, atravs da utilizao de outras normas e padres, devem ser
considerados para que o mesmo atinja seus objetivos, de forma mais
abrangente, nos setores/organizaes/projetos aonde isto no est ocorrendo
no momento. A descrio dos processos tambm pode ser melhorada
utilizando-se da norma especfica para isso.
Os processos de engenharia de usabilidade adicionados devem ser
revistos para verificar se os objetivos so atendidos em sua totalidade, pois
este item foi o que obteve maior grau de discordncia entre todos os itens
avaliados. Eles tambm podem ser revisados mais a fundo para verificar se
no repetem prticas j definidas na norma ISO/IEC 12207.
Algumas prticas bases dos processos alocados ao nvel de maturidade
1 devem ser checadas para verificar a existncia de prticas necessrias
apenas em nveis mais elevados, e deve ser avaliado se o processo gesto do
desenvolvimento centrado no humano deve ser alocado ao nvel 2 de
maturidade.
Apesar das consideraes dos especialistas, todos eles concordaram
que o modelo til e possui recursos que podem ser usados por organizaes
que desejam avaliar/melhorar seu processo de software alinhado com
usabilidade. O modelo tambm foi visto com embasamento e detalhamento
suficiente para que possa ser apresentado, aps suas melhorias, a um comit
ISO como uma nova proposta de trabalho.
Ameaas validade
Alguns fatores podem ameaar ou influenciar de alguma forma os
resultados desta avaliao. O fato de ser uma avaliao inicial envolvendo um
111
nmero baixo de especialista faz com que o grau de generalizao dos

resultados seja muito baixo.
O formato escolhido para as questes, uma escala likert entre discordo e
concordo, no permite maiores consideraes e pode ter sido inadequado
nesse estado da pesquisa. Esta situao ocorreu com um dos especialistas e
outro deles sugeriu a alterao no formato destas. Porm, o formato das
perguntas foi bem aceito pelos demais participantes da avaliao.
A inexperincia em relao engenharia de usabilidade de alguns
especialistas tambm pode distorcer ou deformar os resultados da avaliao. O
perodo curto de avaliao pode ter feito com que as avaliaes ocorressem de
forma apressada e com menos critrios do que a mesma necessitaria.
Outra ameaa a validade dos resultados pode ter sido introduzido pelo
resumo do trabalho que pode ter suprimido informaes importantes, levando a
avaliaes equivocadas por parte dos especialistas.
112
6. Concluso
Neste trabalho, primeiramente, o contexto do tema proposto foi
analisado, buscando-se conhecer na fundamentao terica os conceitos que
envolvem os SPCMMs, convergncia/divergncia digital e usabilidade. Em um
segundo passo, a reviso do estado da arte foi realizada com o objetivo de
encontrar SPCMMs focados em processos de engenharia de usabilidade no
contexto da convergncia digital. Nesta fase, verificou-se que no existem
trabalhos com este objetivo.
Embasado na fundamentao terica e na reviso do estado da arte foi
feito um mapeamento dos modelos de referncia de engenharia de usabilidade,
a fim de criar um conjunto unificado de processos e prticas de usabilidade
para serem integrados no modelo. Em seguida, foi criada a definio da
extenso do modelo de referncia e do framework de medio com a adio
dos processos de usabilidade. Aps isso, uma avaliao atravs de um expert
panel foi realizada.
Com o trabalho finalizado, espera-se que o modelo proposto contribua
para as organizaes que desejam avaliar / melhorar seus processos de
software e de usabilidade, servindo como um guia de melhores prticas para
orient-las. Principalmente no cenrio da convergncia/divergncia digital,
espera-se que a integrao de aspectos da engenharia de usabilidade em um
SPCMM contribua positivamente na melhoria de processos de software e,
consequentemente, na melhoria de produtos de software em termos da
usabilidade.
Como trabalhos futuros, pretende-se evoluir o modelo proposto
destacando ainda mais os pontos fortes, corrigindo ou diminuindo ao mximo
os pontos fracos e implementando as sugestes de melhoria dos especialistas.
E aps estas atualizaes, realizar uma nova avaliao para verificar se tais
melhorias realmente foram efetivas.
113
Referncias
ABNT ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. Parte 11 Orientaes sobre
Usabilidade. In: NBR 9241 - Requisitos Ergonmicos para Trabalho com dispositivos de
Interao Visual. 2011.
ABNT ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. Parte 210 Projeto Centrado
no Ser Humano para Sistemas Interativos. In: NBR 9241 - Requisitos Ergonmicos para
Trabalho com dispositivos de Interao Visual. 2011.
ACM SIGCHI - Curricula for Human-Computer Interaction. Definition of HCI. 1996. Disponvel
em: < http://old.sigchi.org/cdg/cdg2.html#2_1>. Acesso em: setembro de 2011.
ANDERSON, J. et al. Integrating Usability Techniques into SW Development. IEEE

SOFTWARE, 2001.
ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. Software e Servios de TI: Consideraes de Mercado. So Paulo, 2011.
ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro.2011.Disponvel em:
<http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf>.
Acesso
em
setembro de 2011.
BALDWIN, T. F.; MCVOY, D. S., STEINFELD, C. Convergence: Integrating Media,

Information & Communication. Thousand Oaks: SAGE Publications, 1996. 440 p.
BASILI, V. R. et al. The Goal Question Metric Approach. Maryland, 1994.

Disponvel em: <ftp://ftp.cs.umd.edu/pub/sel/papers/gqm.pdf> Acesso em fevereiro de 2012.
BEECHAM, S.; HALL, T.; BRITTON, C.; COTTEE, M.; RAINER, A. Using an Expert Panel to
Validate a Requirements Process Improvement Model. The Journal of Systems and
Software, v. 76, 2005.
BERTOLLO, G. Definio de Processos Em Um Ambiente de Desenvolvimento de

Software. Vitria, 2006.
BORGES, A. Anlise Situacional de Processos com Base em CMMI de Empresas

Prestadoras de Servio. Florianpolis, 2009.
114
BRASIL, Ministrio da Cincia e Tecnologia. Pesquisa de Qualidade no Setor de Software

Brasileiro 2009. 2010.
CYBIS, W. A.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos,

Mtodos e Aplicaes. So Paulo: Novatec, 2007. 344p.
FERR, X.; JURISTO, N.; MORENO, A. M. Framework for Integrating Usability Practices into
the Software Process.In: 6th International Conference on Product Focused Software
Process Improvement. Oulu, Finland: 2005.
GOODMAN, B. D.; GOODMAN, S. N. Freeing Creativity by Understanding the Role of Best

Practices.19th IEEE International Engineering Management Conference, Austin, 2007.
HAUCK, J. C. R. Um Mtodo de Aquisio de Conhecimento Para Customizao de

Modelos de Capacidade/Maturidade de Processos. 02/2011.
HEIDRICH, E. C. Comparativo entre o Mtodo gil XP e uma Viso Tradicional de

Desenvolvimento
de
Software.
Florianpolis,
2005.
Disponvel
em:
<http://projetos.inf.ufsc.br/projetos.php>. Acesso em: agosto de 2011.
HOBOLD, G. C.; COELHO, L. S. Desenvolvimento de Prottipos de Interfaces HumanoComputador na rea de Sade para Convergncia Digital. Florianpolis, 2011.
HUMPHREY, W.; KITSON, D.; KASSE, T. The State of Software Engineering Practice: A
Preliminary Report.In: 11Th International Conference on Software Engineering. 1989.
IEEE
STANDARDS
BOARD.
IEEE
Standard
Glossary
of
Software
Engineering
Terminology. New York, 1990.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15504: Information

Technology - Process Assessment.2003.

Technology - Process Assessment Part 5: An Exemplar Process Assessment Model.
2006.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. Erro! Fonte de referncia no

encontrada.: Information Technology - Process Assessment Part 5: An Exemplar
Process Assessment Model. 2003.
115

Technology - Process Assessment Part 7: Assessment of Organizational. 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207:Processo do

Ciclo de Vida do Software. 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207:1995/FDAM:

Processo do Ciclo de Vida do Software. 2001.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 13407:Human-Centred

Design Process for Interactive System. 1999.
INTERNATIONAL
Ergonomics
of
ORGANIZATION
human-system
FOR
STANDARDIZATION.
interaction
--
Human-centred
ISO/TR
18529:2000
lifecycle
process
descriptions. 2000.
JOKELLA, T. et al. A Survey of Usability Capability Maturity Models: Implications for

Practice and Research. Behaviour & Information Technology, Vol. 25, No. 3. 2006.
KIRDA, E. et al. Supporting Multi-Device Enabled Web Services: Challenges and Open
Problems. In:10th IEEE International Workshops on Enabling Technologies: Infrastructure for
Collaborative Enterprises (WETICE 2001), 20-22 June 2001, Cambridge, MA, USA. pages 4954, IEEE Computer Society, 2001.
KITCHENHAM, B. A. Guidelines for performing Systematic Literature Reviews in Software

Engineering. Version 2.3 Technical report. University of Durham, Keele, UK, 2007.
KOPPEL, R. et al. Role of Computerized Physician Order Entry Systems in Facilitating

Medication Errors. Journal of the American Medical Association JAMA - Vol. 293 No. 10.
2005.
KRONLOF, K. M. Boosting Productivity in Embedded Systems Development. In: ITEA 2

Symposium, 2008, Rotherdam, Netherlands.
LAHRMANN, G.; MARX, F. Systematization of Maturity Model Extensions. Lecture Note in

Computer Science. v. 6105. 2010.
LIEB, R. Multiple Marketing Channels, or Just Plain Digital?. Blog ECONSULTANCY.

05/01/2011. Disponvel em:
<
http://econsultancy.com/us/blog/5188-multiple-marketing-channels-or-just-plain-digital-2>.
116
Acesso em: agosto de 2011.
MOREIRA, N. S.; MELAR, A. V.S.; MICALI, D. L. C. Anlise dos Preceitos Semiticos e

Psicolgicos como Instrumentos para a Compreenso e Estruturao de Interfaces
Homem-Computador,
2010.
Disponvel
em:
<http://www.revistasapere.inf.br/download/segunda/MOREIRA_MELARE_MICALI.pdf>. Acesso
em: Setembro de 2011.
MURPHY et al. The Converged Appliance: I Love It But I Hate It. 2005. Novell PTY Ltda,
The University of Melbourne, Monash University, Aalborg University.
NEBE, K.; ZIMMERMANN, D. Aspects of Integrating User Centered Design into Software
Engineering Processes. Proc. of 12th Int. Conf. on Human-computer interaction: interaction
design and usability, 2007.
PAGANI, M. Challenges of Usability Evaluations in the Emerging Multimedia

Environment. Italia, 2007.
PATERN, F.; SANTOS, I. Designing and Developing Multi-User, Multi-Device Web

Interfaces. Bucharest, Junho 2006.
PREECE, J.; ROGERS, Y.; SHARP, H. Design de Interao: Alm da Interao HomemComputador. Porto Alegre: Bookman, 2005. 548p
PREECE, J. et al. Human-Computer Interaction. EUA:Addison-Wesley. 1994
ROCHA, H. V; BARANAUSKAS, M. C. C., Design e avaliao de interfaces humanocomputador, Escola de Computao, 2000, So Paulo, IME-USP.
SALVIANO, C. F.; FIGUEIREDO, A. M. C. M. Unified Basic Concepts for Process Capability

Models. 20th International Conference on Software Engineering and Knowledge Engineering
SEKE. Redwood. 2008.
SILVA, R. P. Engenharia de Software. INE5614 Notas de Aula. Universidade Federal de

Santa Catarina. Florianpolis, 2010.
SKYPE. O que o Skype. Disponvel em:

< http://www.skype.com/intl/pt-br/prices/call-rates/chamadas-baratas-para-bahamas/>. Acesso
em: setembro de 2011.
117
SOFTWARE ENGINEERING INSTITUTE. CMMI Capability Maturity Model Integration.

Disponvel em <http://sei.cmu.edu/cmmi>. Acesso em maio 2011.
SOFTWARE ENGINEERING INSTITUTE. CMMI for Development V1.3. 2010. Disponvel

em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em abril 2011.
SOUZA, L. S.; SPINOLA, M. M. Requisitos de Usabilidade em Projetos de Interface

Centrado no Usurio de Software de Dispositivos Mveis. Associao Brasileira de
Engenharia de Produo. Outubro de 2006.
STANDISH GROUP. CHAOS Report, 2009.
SWEBOK. Guide to the Software Engineering Body of Knowledge. 2004 Version. A project
of
the
IEEE
Computer
Society
Professional
Practices
Committee.
Disponvel
em:
<http://www.swebok.org>.
Acesso em Setembro de 2011.
WANGENHEIM, C. G. V. et al. Systematic Literature Review of Software Process

Capability/Maturity Models.SPICE - 10th International Conference on Software Process.
Improvement and Capability dEtermination, Pisa/Italy, 2010.
WANGENHEIM, C. G. V. INE5624 Engenharia de Usabilidade. Notas de Aula. UFSC.
Florianpolis, 2011/1.
118
Apndice A Resumo do Trabalho Enviado

No Expert Panel
INTEGRATION OF USABILITY ENGINEERING IN A SOFTWARE

PROCESS CAPABILITY/ MATURITY MODEL
- SUMMARY FOR EVALUATION-

Christiane Gresse von Wangenheim
Software Quality Group - GQS

National Institute for Research and Technology on Digital Convergence - INCOD
Department of Informatics and Statistics - INE
Federal University of Santa Catarina - UFSC
88049-200 Florianpolis - SC
Brazil
119
1. Introduction
An important quality of software products is usability. Usability is the extent to
which a product can be used by specified users to achieve specified goals with
effectiveness, efficiency and satisfaction in a specified context of use (ISO 9241-11,
1998). Systems with poor usability can hinder users to perform their tasks, leaving
them frustrated. In some situations, the effects of poor usability can even harm the lives
of people (Koppel et al., 2005). On the other hand, adequate usability can increase
user satisfaction and productivity and consequently increase revenue and enhance
competitiveness of software organizations.
Especially, in the current scenario of digital convergence/divergence with
applications to be present via diverse devices (computers, tablets, mobile phones,
digital interactive TV, etc.), the importance of usability has even increased, as one of
the principal challenges is the customization of these application to different input and
output formats (display size, keyboard vs. touchscreen vs. remote control, etc.).
Considering this increased focus on usability as a product quality, we can also
observe a need for guidance for the improvement of the usability engineering process.
Yet, today, commonly adopted models and standards for software process
improvement, such as, the CMMI framework (SEI, 2010) or ISO/IEC 15504 (ISO/IEC,
2003) do not address usability engineering (JOKELLA et al., 2005). A systematic
literature review of SPCMMs also failed to identify models tailored with this focus
(Wangenheim et al., 2010). This lack of integration of usability engineering within the
software process can also be observed in general in the Software Engineering area.
For example, neither the standard ISO/IEC 12207:2008 describing the software life
cycle process nor the SWEBOK describing the Software Engineering body of
knowledge, cover explicitly Usability Engineering.
On the other hand, there exist specific models and standards for usability
engineering (JOKELLA et al., 2005). And, although, in the past various authors have
already suggested the integration of usability engineering into the software process
((NEBE & ZIMMERMANN, 2007), (ANDERSON et al., 2001), (FERR; JURISTO;
MORENO, 2005)) , so far, such an integration has not taken place permanently within
popular software capability/maturity models.
2. Research
Therefore, the objective of this research is to propose an extension to a Software
Process Capability/Maturity Model (SPCMM) integrating the usability engineering
process. The context of use of this extension is directed to the development and
maintenance of software products requiring usability as an important quality, especially
in the scenario of digital convergence/divergence.
Based on an analysis of the background and a systematic literature review, we
have identified the following sources as a basis for the definition of the extension:
SPCMM
ISO/IEC 15504-2
Process dimension
Software process
(in general)
ISO/IEC 12207:2008
ISO/IEC 15504-5 (Organization Management; Change Request
Management)
ISO/IEC 15504-7 (Quantitative Performance Management Process;
Quantitative Process Improvement Process)
120
Usability engineering
process
ISO/TR 18529:2000
ISO/IEC CD 15504-5:2003 PRO.1 Usability
Amendment 1 to ISO/IEC 12207:1995
ISO/IEC 12207:2008 E.4 Process View for Usability
Measurement framework
Capability levels
ISO/IEC 15504-2
Maturity levels
ISO/IEC 15504-7
Following the SPCMM bi-dimensional structure as defined by ISO/IEC 15504-2,

we define a process dimension and a measurement framework.
Figure 1 Process assessment model relationships (ISO/IEC 15504, 2003)
In order to define an extension to the software process as defined in ISO/IEC

12207:2008 (used as a reference model for the software process in general), we
defined a new group a processes representing the usability engineering process. This
group of processes has been defined in accordance to the tailoring process as defined
in ISO/IEC 12207:2008 Annex A. In a first step, we mapped the sources for the
usability engineering process into a unique set of processes and practices (Annex A)
and then we integrated the unified set of processes and practices into the reference
model based on ISO/IEC 12207. During this step, we added new processes, which are
not covered by ISO/IEC 12207:2008 as new process. Content of unified processes and
practices covered either by other processes of ISO/IEC 12207:2008 or through process
attributes of the measurement dimension defined through 15504 are identified and
mapped (Table 2). For each of the new added processes a detailed process description
has been defined based on the identified unified practices.
With respect to the measurement framework, we basically adopt the capability
level definition from ISO/IEC 15504-2 as is. With respect to the definition of maturity
levels, we also adopt the definition from ISO/IEC 15504-7 basically as is, adding only
the usability processes to the respective maturity levels.
3. SPCMM Extension for Usability Engineering

3.1 Definition of the Process Dimension
121
The process dimension is based on ISO/IEC 12207:2008 as a general reference

model for the software process. In accordance with the tailoring process prescribed in
Annex A of ISO/IEC 12207:2008, we propose an extension of the standard by defining
an additional process group of Usability Engineering processes as shown in Figure 2
(marked green) and detailed in Table 2.
In addition, the further processes (marked blue and yellow in Figure 2) are added
as defined in ISO/IEC 15504-7 in order to maintain conformance to the maturity
framework defined by ISO/IEC 15504-7 (as these processes are not covered by
ISO/IEC 12207:2008).
Figure 2 Process Reference Model with Usability Engineering Extension
122
Process
number
1
1.1
1.1.1
1.1.2
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
Table 1 Process Reference Model with Usability Engineering Extension

Process Name
Source
Source
Source
Process
Process
Name
Number
System Life Cycle ISO/IEC
6
System Life Cycle
Processes
12207:2008
Processes
Agreement Processes ISO/IEC
6.1
Agreement Processes
12207:2008
Acquisition
ISO/IEC
6.1.1
Acquisition
12207:2008
Supply
ISO/IEC
6.1.2
Supply
12207:2008
Organizational
ISO/IEC
6.2
Organizational
Project-Enabling
12207:2008
Project-Enabling
Processes
Processes
6.2.1
Life
Cycle
Model
Life
Cycle
Model ISO/IEC
12207:2008
Management
Management
Infrastructure
Management
Project
Portfolio
Management
Human
Resource
Management
Quality Management
1.3
Organization
Management
Quantitative
Performance
Management
Quantitative Process
Improvement
Project Processes
1.3.1
Project Planning
1.3.2
1.3.3
Project
Assessment
and Control
Decision Management
1.3.4
Risk Management
1.3.5
1.3.7
Configuration
Management
Information
Management
Measurement
1.4
Technical Processes
1.4.1
Stakeholder
Requirements
Definition
System Requirements
Analysis
System
Architectural
Design
Implementation
1.2.7
1.2.8
1.3.6
1.4.2
1.4.3
1.4.4
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
15504-5:2006
ISO/IEC
15504-7:2008
6.2.2
ISO/IEC
15504-7:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
QNT.2
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
6.4.2
6.2.3
6.2.4
6.2.5
MAN.2
Infrastructure
Management
Project
Portfolio
Management
Human
Resource
Management
Quality Management
6.3
Organization
Management
Quantitative
Performance
Management
Quantitative Process
Improvement
Project Processes
6.3.1
Project Planning
6.3.2
6.3.3
Project
Assessment
and Control
Decision Management
6.3.4
Risk Management
6.3.5
6.3.7
Configuration
Management
Information
Management
Measurement
6.4
Technical Processes
6.4.1
Stakeholder
Requirements
Definition
System Requirements
Analysis
System
Architectural
Design
Implementation
QNT.1
6.3.6
6.4.3
6.4.4
123
1.4.5
System Integration
1.4.6
System
Qualification
Testing
Software Installation
1.4.7
1.4.8
1.4.9
Software Acceptance
Support
Software Operation
1.4.10
Software Maintenance
1.4.11
Software Disposal
2.1.5
Software Life Cycle

Processes
Software
Implementation
Processes
Software
Implementation
Software Requirements
Analysis
Software Architectural
Design
Software
Detailed
Design
Software Construction
2.1.6
Software Integration
2.1.7
2.2.4
Software Qualification
Testing
Software
Support
Processes
Software
Documentation
Management
Software Configuration
Management
Software
Quality
Assurance
Software Verification
2.2.5
Software Validation
2.2.6
Software Review
2.2.7
Software Audit
2.2.8
Software Problem
Resolution
Change Request
Management
Software Reuse
Processes
Domain Engineering
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.2.1
2.2.2
2.2.3
2.2.9
2.3
2.3.1
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
6.4.5
System Integration
6.4.6
System
Qualification
Testing
Software Installation
6.4.7
6.4.8
6.4.9
Software Acceptance
Support
Software Operation
6.4.10
Software Maintenance
6.4.11
Software Disposal
7.1.5
Software Life Cycle

Processes
Software
Implementation
Processes
Software
Implementation
Analysis
Software Architectural
Design
Software
Detailed
Design
Software Construction
7.1.6
Software Integration
7.1.7
7.2.4
Software Qualification
Testing
Software
Support
Processes
Software
Documentation
Management
Software Configuration
Management
Software
Quality
Assurance
Software Verification
7.2.5
Software Validation
7.2.6
Software Review
7.2.7
Software Audit
7.2.8
Software Problem
Resolution
Change Request
Management
Software Reuse
Processes
Domain Engineering
7.1
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
7.1.1
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/IEC
15504-5:2006
ISO/IEC
12207:2008
ISO/IEC
7.2.2
7.1.2
7.1.3
7.1.4
7.2
7.2.1
7.2.3
SUP.10
7.3
7.3.1
124
2.3.2
2.3.3
2.4
2.4.1
2.4.2
2.4.3
2.4.4
Reuse
Asset
Management
Reuse Program
Management
Usability Engineering
Processes
Human-Centered
Design Management
Context of Use
Specification
Development of Design
Solutions
Evaluation of Design
Solutions
12207:2008
ISO/IEC
12207:2008
ISO/IEC
12207:2008
ISO/TR
18529:2000
ISO/TR
18529:2000
ISO/TR
18529:2000
ISO/TR
18529:2000
ISO/TR
18529:2000
7.3.2
7.3.3
HCD 1
HCD 4
HCD 5
HCD 6
Reuse
Asset
Management
Reuse Program
Management
Usability Engineering
Processes
Ensure HCD content in
system strategy
Understand and specify
the context of use
Produce
design
solutions
Evaluate
designs
against requirements
3.1.1 Definition of the Usability Engineering Processes

The definition of the Usability Engineering Processes has been based on a
comparison and mapping Usability Engineering processes of several reference models
as presented in Annex A.
Table 2 illustrates how the processes and base practices correspond to either
processes in ISO/IEC 12207 (being used as a basis software process reference model)
or to process attributes of the measurement framework as defined by ISO/IEC 15504.
Based on the results of this evaluation of correspondence, the decisions on how to
integrate the respective processes/practices into the extended SPCMM are also shown
in Table 2 (Column 5-6).
Table 2 Mapping the unified processes in relation to the processes of ISO/IEC 12207 or process
attributes of ISO/IEC 15504
Unified processes and practices
based on Annex A
Unified
Unified Best
Process
Practices
HumanCentered
Design
Management
HumanCentered
Design Project
Management
Represent
Stakeholders;
Collect market
intelligence;
Define and
plan system
strategy;
Collect market
feedback;
Analyze user
trends;
Consult
Stakeholders;
Plan user
involvement;
Select humancentred methods;
Ensure a
human-centred
approach;
Plan and
manage HCD
activities;
Champion HC
Correspondence to processes or
process attributes
Correspondent
Processes/
Base Practices
Process Attribute
Inexistent
Inexistent
PA 2.1
Performance
management
Process attribute ISO/IEC 15004
Identify the
objectives;
Plan and monitor
the performance of
the process;
Adjust the
performance of the
process;
Define
responsibilities and
authorities for
performing the
process;
Decision for designing the

reference model extension
Base
Practices
Process
Added to the
model through a
new process
called: Humancentered design
management
Definition of
base practices
as is into the
new process.
Represented
through PA 2.1 1
no need for
changes.
Represented
through PA 2.1
no need for
changes.
125
approach;
Support HCD;
HumanCentered
Requirements
Development
Context of Use
Specification
Development of
Design
Solutions
Evaluation of
Design
Solutions
HumanCentered
Clarify system
goals;
Analyze
stakeholders;
Assess H&S
risk;
Define system;
Generate
requirements;
Set quality in
use objectives;
Identify users
task;
Identify user
attributes;
Identify
organizational
environment;
Identify
technical
environment;
Identify
physical
environment;
Allocate
functions;
Produce task
model;
Explore
system design;
Develop
design solutions;
Specify system
and use;
Develop
prototypes;
Develop user
training;
Develop user
support;
Specify context
of evaluation;
Evaluate for
requirements;
Evaluate to
improve design;
Evaluate
against system
requirements;
Evaluate
against required
practice;
Evaluate in
use;
Manage
change;
6.4.1 Stakeholder
requirements
definition process ISO/IEC 12207
Identify and make

available resources
to perform the
process;
Manage the
interfaces between
involved parties;
Stakeholder
identification;
Requirements
identification;
Requirements
Evaluation;
Requirements
agreement;
Requirement
recording;
Represented
through 6.4.1 1
no need for
changes.
Represented
through 6.4.1
no need for
changes.
Inexistent
Inexistent
Added to the
model through a
new process
called: Context of
Use Specification
Definition of
base practices
as is into the
new process.
Inexistent
Inexistent
Added to the
model through a
new process
called:
Development of
Design Solutions
Definition of
base practices
as is into the
new process.
Inexistent
Inexistent
Added
to
the
model through a
new
process
called: Evaluation
of
Design
Solutions
Definition
of
base practices
as is into the
new process.
Preparation for
operation;
Represented
through 6.4.9 no
Represented
through 6.4.9
6.4.9 Software
operation process
126
Design
Operation
Determine
impact
Customization
and local design;
Deliver user
training;
Support users;
Conformance
to ergonomic
legislation;
- ISO/IEC 12207
Operation
activation and
check-out;
Operational use;
Customer
Support;
Operation
problem resolution;
need for changes.
no need for
changes.
3.1.2 Detailed process description of the added Usability Engineering processes

Process ID
2.4.1
Process
Name
Human-Centered Design Management
Process
Purpose
The purpose of the process Human-Centered Design Management is to

establish and maintain a focus on stakeholder and user issues in each part of
the organization which deal with system markets, concept, development and
support.
Process
Outcomes
As a result of successful implementation of this process:

- marketing will take account of usability, ergonomics and socio-technical issues
- systems will be targeted to meet users needs and expectations
- planners will consider stakeholder and organization requirements in setting out
systems strategy
- systems will be more responsive to changes in users (their needs, tasks,
context, etc.)
- the enterprise will be more responsive to changes in its users
- systems are less likely to be rejected by the market.
Base
Practices
PB1: Represent stakeholders: Act as advocate for end users and other
stakeholders in the system development enterprise and the development team.
PB2: Collect market intelligence: Perform foresight research into potential
user groups in order to identify forthcoming needs for systems and new users or
user organizations. Identify expected context of use of future systems. Set up
procedures to elicit user input regarding future systems in their expected context.
PB3: Define and plan system strategy: Present market information as a vision
(e.g. for senior management approval).
Operationalize vision into
implementation strategy. Use lifecycle cost accounting in order to assess the
cost of an HCD approach.
PB4. Collect market feedback: Perform optimizing research to refine and
consolidate system strategy, based on feedback from users and non-users in the
systems marketplace.
PB5. Analyze trends in users: Look for changes in: users (e.g. their skills and
training for user organizations, as well as needs and desires for consumer
products), tasks (e.g. changes in type of work or volumes of work), context (e.g.
changes in working and living environments, new technologies, social and
political mores and expectations). Analyze this information to estimate future
needs.
127
Process ID
2.4.2
Process
Name
Context of Use Specification
Process
Purpose
The purpose of the process Context of Use Specification is to identify, clarify

and record the characteristics of the stakeholders, their tasks and the
organizational and physical environment in which the system will operate.
Process
Outcomes
As a result of successful implementation of this process the following will be

achieved:
- definition of the characteristics of the intended users
- definition of the tasks the users are to perform
- definition of the organization and environment in which the system is used
- the context of use is available and used at all relevant points in the lifecycle.
Base
Practices
PB1: Identify and document users tasks Describe the activities which users
perform to achieve system goals.
PB2: Identify and document significant user attributes Describe the relevant
characteristics of the end-users of the system. This will include knowledge,
language, physical capabilities, level of experience with job tasks and with
relevant systems equipment etc..
PB3: Identify and document organizational environment: Describe the
relevant social and organizational milieu, management structure and
organizational practices, etc.
PB4. Identify and document technical environment: Describe the relevant
characteristics of any equipment to be used. Particular attention should be paid
to the equipment with which the users will directly interact.
PB5. Identify and document physical environment: Describe the location,
workplace equipment and ambient conditions. For example, lighting, noise
levels, vibration etc.
Process ID
2.4.3
Process
Name
Development of Design Solutions
Process
Purpose
The purpose of the process Development of Design Solutions is to create

potential design solutions by drawing on established state-of-the-art practice, the
experience and knowledge of the participants and the results of the context of
use analysis.
Process
Outcomes
As a result of successful implementation of the process:

- the whole socio-technical system in which any technical components operate
will be considered in the design
- user characteristics and needs will be taken into account in the purchasing of
system components
- user characteristics and needs will be taken into account in the design of the
system
- existing knowledge of best practice from socio-technical systems engineering,
ergonomics, psychology, cognitive science and other relevant disciplines will be
128
integrated into the system

- communication between stakeholders in the system will be improved because
the design decisions will be more explicit
- the development team will be able to explore several design concepts before
they settle on one
- feedback from end users and other stakeholders will be incorporated in the
design early in the development process
- it will be possible to evaluate several iterations of a design and alternative
designs
- the interface between the user and the software, hardware and organizational
components of the system will be designed
- user training and support will be developed.
Base
Practices
PB1: Allocate functions: Analyze the context of use and the required functions
and performance of the system, to distribute functions between the human,
machine and organizational components of the system best able to fulfill each
function.
PB2: Produce composite task model: Develop a feasible model of the users
new tasks from existing knowledge of best practice, the requirements, context of
use, allocation of function and design constraints for the system.
PB3: Explore system design: Generate and analyses a range of design
options for each aspect of the system related to its use and its effect on
stakeholders.
PB4. Use existing knowledge to develop design solutions: Apply relevant
human science information to the design of the system. Include the stakeholder
and organizational requirements, context of use, international standards,
legislative requirements, existing patents, good practice, style guides and project
standards etc. in the design.
PB5. Specify system and use: Produce a design for the user-related
components of the system. Produce description(s) of how the system will be
used. Change design in the light of feedback from evaluations.
PB6. Develop prototypes: Make design solution(s) more concrete using
simulations, models, mock-ups etc. Develop simulation or trial implementation
of key aspects of the system for the purposes of testing with users or user
representatives
PB7. Develop user training: Identify, specify and produce the training required
to enable relevant users to perform tasks effectively using the new system.
Cover or include any proposed changes in business processes, job design and
tasks.
PB8. Develop user support: Identify, specify and produce the user support
services for the system. Take into account the proposed changes in business
processes and job design.
Process ID
2.4.4
Process
Name
Evaluation of Design Solutions
Process
Purpose
The purpose of the process Evaluation of Design Solutions is to collect feedback

on the developing design. This feedback will be collected from end users and
other representative sources.
129
Process
Outcomes
As a result of successful implementation of this process:

- feedback will be provided to improve the design
- there will be an assessment of whether stakeholder and organizational
objectives have been achieved or not
- long-term use of the system will be monitored
In the case of evaluation to identify improvements to the system (formative
evaluation), successful implementation of the process will reflect:
- potential problems and scope for improvements in: the technology, supporting
material, organizational or physical environment and the training
- which design option best fits the functional and stakeholder and organizational
requirements
- feedback and further requirements from the users.
In the case of evaluation to assess whether objectives have been met
(summative evaluation), successful implementation of the process will
demonstrate:
- how well the system meets its organizational goals
- that a particular design meets the human-centred requirements
- conformity to international, national and/or statutory requirements.
Base
Practices
PB1: Specify and validate context of evaluation: Describe and verify the
conditions under which a system is tested or otherwise evaluated. Describe the
relationship, and especially discrepancies, between the context of evaluation
and the context of use.
PB2: Evaluate early prototypes in order to define the requirements for the
system: Benchmark appropriate systems using relevant criteria. Test the
usability of competing/alternative systems and/or system concepts. Use
prototypes to stimulate stakeholder input to system requirements. Test stability
of requirements.
PB3: Evaluate prototypes in order to improve the design: Collect user input
on the quality in use of the developing system. Present the results to the design
team(s) in the most appropriate format.
PB4. Evaluate the system in order to check that the stakeholder and
organizational requirements have been met: Test the developing or final
system to ensure that it meets the requirements of the users, the tasks and the
environment, as defined in its specification.
PB5. Evaluate the system in order to check that the required practice has
been followed: Check systems for adherence to applicable human science
knowledge, style guides, standards, guidelines, and legislation.
PB6. Evaluate the system in use in order to ensure that it continues to
meet organizational and user needs: Check the system in use for changes in
organizational, user, other stakeholder, and usability needs and to ensure that it
continues to meet these needs.
3.2 Measurement Framework

The measurement framework of the extended SPCMM is based on ISO/IEC
15504 defining a continuous and staged representation.
3.2.1 Definition of Continuous Representation
Here we adopt the continuous representation from ISO/IEC 15504-2, where
process capability is defined on a sic point ordinal scale that enables capability to be
130
assessed from the bottom of the scale, incomplete, through to the top end of the scale,
optimizing. The measure of capability is based upon a set of Process Attributes taken
from ISO/IEC 15504-2 as is.
3.2.2 Definition of Staged Representation
As defined by ISO/IEC 15504-7, organizational Maturity is defined as an
expression of the extent to which an organization consistently implements processes
within a defined scope that contributes to the achievement of its business goals
(current or projected). Organizational maturity is expressed on a six point ordinal scale
of maturity from Maturity Level 0 through Maturity Level 5, taking the definition by
ISO/IEC 15504-7 as is.
Based on the Exemplar Organizational Maturity Model as defined in Annex A of
ISO/IEC 15504-7, we extend the process sets associated to maturity levels by
including the four new added Usability Engineering processes (as indicated in Table 2).
The processes 2.4.2 Context of Use Specification, 2.4.3 Development of Design
Solution, 2.4.4 Evaluation of Design Solution, which represent technical processes of
the Usability Engineering life cycle are associated to the basic process set of maturity
level 1 in correspondence to the association of basic technical software processes to
this maturity level (such as, system requirements analysis, software construction etc.).
The process 2.4.1 Human-Centered Design Management is associated to maturity
level 3 due to the focus of level 3 on organizational and strategic management.
As we base the process dimension of the extended SPCMM here on ISO/IEC
12207, we also substituted the respective processes as listed in the exemplar
organizational maturity model (based on ISO/IEC 15504-5) through the corresponding
ISO/IEC 12207 processes (as indicated in Table 3).
ML
Basic Process Set
Table 3 Association of Processes to Maturity Levels (extending ISO/IEC 15504-7)

List of Processes
Minimum
Additional Processes
Set
ID
Conditions
1.4.1
1.4.2
Required where
1.4.1 Stakeholder Requirements Definition
1.4.4
1.4.3
development covers
1.4.2 System Requirements Analysis
1.4.5
system issues and not
1.4.3 System Architectural Design
2.1.2
1.4.6
exclusively software
1.4.4 Implementation
2.1.3
issues.
2.1.4
2.1.2 Software Requirements Analysis
2.1.5
1.4.7
Required when the
2.1.3 Software Architectural Design
2.1.6
organization is responsible
2.1.4 Software Detailed Design
2.1.7
for installing the software
2.1.5 Software Construction
product in the customer
2.4.2
2.1.6 Software Integration
environment
2.4.3
1.4.8
Required where the
2.1.7 Software Qualification Testing
2.4.4
1.4.9
organization is
1.4.10 responsible for ongoing
1.4.5 System Integration
1.4.11 maintenance and
1.4.6 System Qualification Testing
evolution of the software
1.4.7 Software Installation
and/or system.
1.4.8 Software Acceptance Support
1.4.9 Software Operation
1.4.10 Software Maintenance
1.4.11 Software Disposal
2.4.2 Context of Use Specification
2.4.3 Development of Design Solution
2.4.4 Evaluation of Design Solution
131
Extended Process Sets
2.2.1 Software Documentation Management

2.2.2 Software Configuration Management
2.2.3 Software Quality Assurance
2.2.4 Software Verification
2.2.5 Software Validation
2.2.6 Software Review
2.2.8 Software Problem Resolution
2.2.9 Change Request Management
1.3.1 Project Planning
1.3.2 Project Assessment and Control
1.3.3 Decision Management
1.3.4 Risk Management
1.3.5 Configuration Management
1.3.6 Information Management
1.1.1 Acquisition
1.1.2 Supply
1.2.1 Life Cycle Model Management
1.2.2 Infrastructure Management
1.2.3 Project Portfolio Management
1.2.4 Human Resource Management
1.2.5 Quality Management
1.2.6 Organization Management
2.2.1
2.2.2
2.2.3
2.2.4
2.2.8
2.2.9
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.3.7
2.2.7
2.4.1
1.3.7 Measurement
1.1.1
Required where external

or internal suppliers of
product components,
services or infrastructure
are involved in the
development projects.
2.2.5
2.2.6
Optional
Optional where the work
in the organization involves
agreements with
stakeholders.
1.1.2
Optional where the work

in the organization involves
product acceptance
support.
2.3.1
2.3.2
2.3.3
Optional if the organization

has a structured reuse
program
in force - the three
processes are mutually
reinforcing.
2.2.7 Software Audit

2.3.1 Domain Engineering
2.3.2 Reuse Asset Management
2.3.3 Reuse Program Management
4
5
2.4.1
Human-Centered
Management
1.2.7 Quantitative Performance
Management
1.2.8 Quantitative Process
Improvement
Design
Acknowledgements
This work was supported by the CNPq (Conselho Nacional de Desenvolvimento
Cientfico e Tecnolgico), an entity of the Brazilian government focused on scientific
and technological development, the MCT (Ministrio da Cincia e Tecnologia)/FINEP
(Financiadora de Estudos e Projetos) and FAPESC (Fundao de Amparo Pesquisa
e Inovao do Estado de Santa Catarina).
References
SOFTWARE, 2001.
FERR, X.; JURISTO, N.; MORENO, A. M. Framework for Integrating Usability Practices into
the Software Process.In: 6th International Conference on Product Focused Software
Process Improvement. Oulu, Finland: 2005.
132

Technology - Process Assessment.2003.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9241: Ergonomic
requirements for office work with visual display terminals (VDTs) -- Part 11: Guidance on
usability.1998.
Technology - Process Assessment Part 5: An Exemplar Process Assessment Model.
2006.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC CD 15504-5.4:
Information Technology - Process Assessment Part 5: An Exemplar Process
Assessment Model. 2003.
Technology - Process Assessment Part 7: Assessment of Organizational. 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207:Processo do
Ciclo de Vida do Software. 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207:1995/FDAM:
Processo do Ciclo de Vida do Software. 2001.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 13407:Human-Centred
Design Process for Interactive System. 1999.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/TR 18529:2000
Ergonomics of human-system interaction -- Human-centred lifecycle process
descriptions. 2000.
JOKELLA, T. et al. A Survey of Usability Capability Maturity Models: Implications for
Practice and Research. Behaviour & Information Technology, Vol. 00, No. 0. 2005.
KOPPEL, R. et al. Role of Computerized Physician Order Entry Systems in Facilitating
Medication Errors. Journal of the American Medical Association JAMA - Vol. 293 No. 10.
2005.
NEBE, K.; ZIMMERMANN, D. Aspects of Integrating User Centered Design into Software
Engineering Processes. Proc. of 12th Int. Conf. on Human-computer interaction: interaction
design and usability, 2007.
SOFTWARE ENGINEERING INSTITUTE. CMMI Capability Maturity Model Integration.
Disponvel em <http://sei.cmu.edu/cmmi>. Acesso em maio 2011.
SOFTWARE ENGINEERING INSTITUTE. CMMI for Development V1.3. 2010. Disponvel
em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em abril 2011.
SOUZA, L. S.; SPINOLA, M. M. Requisitos de Usabilidade em Projetos de Interface
Centrado no Usurio de Software de Dispositivos Mveis. Associao Brasileira de
Engenharia de Produo. Outubro de 2006.
Capability/Maturity Models. SPICE - 10th International Conference on Software Process.
Improvement and Capability dEtermination, Pisa/Italy, 2010.
133
Annex A
Mapping of Reference Models of Usability Engineering
DC = Degree of coverage: T = Fully covered; P = Partially covered; - = No coverage;
Unified Process
Human-Centered Design
Management
Unified Best
Practice
Description
ISO/IEC 12207:2008
E.4 Process View for
Usability
DC
PB1: Represent
stakeholders.
Act as advocate for end users and

other stakeholders in the system
development enterprise and the
development team.
Usability Process View / Project

Portfolio Management process.
PB2: Collect
market
intelligence.
Perform foresight research into

potential user groups in order to
identify forthcoming needs for
systems and new users or user
organizations. Identify expected
context of use of future systems.
Set up procedures to elicit user
input regarding future systems in
their expected context.

PB3: Define and

plan system
strategy.
Present market information as a

vision (e.g. for senior
management approval).
Operationalize vision into
implementation strategy. Use
lifecycle cost accounting in order
to assess the cost of an HCD
approach.
PB4. Collect
market feedback.
PB5. Analyze
trends in users.
Amendment 1 to ISO/IEC
12207:1995
DC
ISO/IEC CD 155045:2003 PRO.1

Usability
DC
ISO/TR 18529:2000
DC
Usability Process / Activities:

Process implementation.
Usability Process/
PRO.1.BP1: Include a
usability specialist in
the system developing
team.
Process HCD1 Ensure HCD

content in systems strategy. /
PB1: Represent stakeholders.

Human aspects of strategy,
introduction and support.
-*

PB2: Collect market
intelligence.

Planning Process.


PB3: Define and plan system
strategy.
Perform optimizing research to

refine and consolidate system
strategy, based on feedback from
users and non-users in the
systems marketplace.



PB4: Collect market
feedback.
Look for changes in: users (e.g.

their skills and training for user
organizations, as well as needs
and desires for consumer
products), tasks (e.g. changes in
type of work or volumes of work),
context (e.g. changes in working
and living environments, new
technologies, social and political
mores and expectations). Analyze
Usability Process View /

Stakeholder Requirements
Definition process, System
Requirements Analysis
Process and Software
Process.


PB5: Analyze trends in users.
this information to estimate future

needs.
Project Management
PB1: Consult
stakeholders.
Establish structures, mechanisms

and procedures to ensure that
relevant stakeholders are
effectively involved and consulted
in each significant aspect of the
system development and
implementation.

Usability Process /
team.
Process HCD2 Plan and

manage the HCD process /
PB1: Consult stakeholders.
PB2: Identify and

plan user
involvement.
Decide on the most effective way

to elicit user input at each stage of
the project, taking best advantage
of established good practice in
team work and appropriate user
involvement.

Planning Process.

Usability Process /
team.

PB2: Identify and plan user
involvement.
PB3: Select
human-centred
methods and
techniques.
Decide which methods will be

included and how they will link
together in the development
process. Define how this will
interface to the particular lifecycle
methodology being used in the
development of the system.

Planning Process.

Usability Process /
team.

PB3: Select human-centred
methods and techniques.
PB4: Ensure a
human-centred
approach within
the project team.
Establish a multi-disciplinary
culture in the project team.
Maintain staff focus on a humancentred approach. Identify the
specialist skills required and plan
how to provide them.

Portfolio Management process
and Project Assessment and
Control Process.

Usability Process /
team.

PB4: Ensure a human-centred
approach within the project
team.
PB5: Plan humancentred design

activities.
Develop a plan specifying how the

human-centred activities integrate
into the overall system
development process.

Planning Process.

Usability Process /
team.

PB5: Plan human-centred
design activities.
PB6: Manage
human-centred
activities.
Take specific account of user

issues in management of projects
and development departments.
Ensure that the system
development process takes
account of user input. Take
account of stakeholder and user
issues in support activities (e.g.
contracts management and
purchasing).

Planning Process.

Usability Process /
team.

PB6: Manage human-centred
activities.
PB7: Champion
human-centred
approach.
Promote a human-centred
approach within the enterprise.
Establish and communicate a
policy for human-centred ness

Control Process.

Usability Process /

PB7: Champion humancentred approach.
135
within the enterprise.
Requirements
Development
team.
PB8: Provide
support for
human-centred
design.
Include human-centred elements

in support procedures (e.g. quality
assurance, change control,
process and method
maintenance, resource
management). Ensure that these
are carried out as an integral part
of the infrastructure management
for the enterprise.

Control Process.

Usability Process /
team.

PB8: Provide support for
human-centred design.
PB1: Clarify and

document system
goals.
Describe the objectives which the

user or user organization wants to
achieve through use of the
system.

Process.

Human-centred design
Usability Process /
team.
Process HCD3 Specify the

stakeholder and organizational
requirements. / PB1: Clarify
and document system goals.
PB2: Analyze
stakeholders.
Identify and analyses the roles of

each group of stakeholders likely
to be affected by a system.
Assess the significance and
relevance of the system to each
stakeholder group which will be
end users of the system and/or
will be affected by input to or
output from the system.

Process.

Usability Process /
PRO.1.BP2: Identify
the typology of people
involved in the use of
the system and specify
their usage needs.

requirements. / PB2: Analyze
stakeholders.
PB3: Assess risk

to stakeholders.
Review the safety, health and wellbeing risks to the stakeholders of

the system. Relate this to the
overall risk assessment for the
system.

Process.

Usability Process /
team.

requirements. / PB3: Assess
risk to stakeholders.
PB4: Define the

use of the system.
Set and agree the required

behavior and performance of the
system in terms of the total
experience of the relevant
stakeholders and/or the user
organization with the system. The
total experience covers each
aspect of a relevant stakeholders
relationship with the system from
its commissioning to its decommissioning.

Process, Information
Management Process and
Analysis Process.

Usability Process /
PRO.1.BP3: Define
the aspects of user
interface and system
behavior related to the
achievement of the
specified needs

requirements. / PB4: Define
the use of the system.
PB5: Generate the

stakeholder and
organizational
Develop an explicit statement of

the stakeholder and organizational
requirements for the system.


Usability Process /
PRO.1.BP4: Define
and review system and

requirements. / PB5: Generate
136
requirements.
Context of Use
Specification
software requirements.
the stakeholder and

organizational requirements.
PB6: Set quality in

use objectives.
Generate and agree on

measurable criteria for the
required quality in use of the
system.

Measurement Process.

Usability Process /
PRO.1.BP7: Validate
the software design
against the defined
usability requirements.

requirements. / PB6: Set
quality in use objectives.
PB1: Identify and

document users.
Process HCD4 Understand and

specify the context of use. / PB1:
Identify and document users.

Process.

Human-centred design.
Usability Process /
team.
Process HCD4 Understand

and specify the context of
use. / PB1: Identify and
document users.
PB2: Identify and

document
significant user
attributes.
Describe the relevant

characteristics of the end-users of
the system. This will include
knowledge, language, physical
capabilities, level of experience
with job tasks and with relevant
systems equipment etc...

Process.

Usability Process /
PRO.1.BP2: Identify
the typology of people
involved in the use of
the system and specify
their usage needs.

document significant user
attributes.
PB3: Identify and

document
organizational
environment.
Describe the relevant social and

organizational milieu,
management structure and
organizational practices, etc.

Process.

Usability Process /
team.

document organizational
environment.
PB4: Identify and

document
technical
environment.
Describe the relevant

characteristics of any equipment
to be used. Particular attention
should be paid to the equipment
with which the users will directly
interact.

Process.

Usability Process /
team.

document technical
environment.
Describe the location, workplace

equipment and ambient
conditions. For example, lighting,
noise levels, vibration etc.

Process.

Usability Process /
team.

document physical
environment.
Analyze the context of use and the

required functions and
performance of the system, to

Usability Process /
Process HCD5 Produce

design solutions. / PB1:
Allocate functions.
PB5: Identify and

document physical
environment.
Development of Design
Solutions
Process.
PB1: Allocate
functions.
137
distribute functions between the

human, machine and
organizational components of the
system best able to fulfill each
function.

team.
PB2: Produce
composite task
model.
Develop a feasible model of the

users new tasks from existing
knowledge of best practice, the
requirements, context of use,
allocation of function and design
constraints for the system.

Usability Process /
team.

Produce composite task
model.
PB3: Explore
system design.
Generate and analyses a range of

design options for each aspect of
the system related to its use and
its effect on stakeholders.

Usability Process /
PRO.1.BP5:
Implement Human
Centered Design

Explore system design.
PB4. Use existing

knowledge to
develop design
solutions.
Apply relevant human science

information to the design of the
system. Include the stakeholder
and organizational requirements,
context of use, international
standards, legislative
requirements, existing patents,
good practice, style guides and
project standards etc. in the
design.

Usability Process /
PRO.1.BP5:
Implement Human
Centered Design

design solutions. / PB4: Use
existing knowledge to develop
design solutions.
PB5. Specify
system and use.
Produce a design for the userrelated components of the system.

Produce description(s) of how the
system will be used. Change
design in the light of feedback
from evaluations.

Process.

Usability Process /
PRO.1.BP5:
Implement Human
Centered Design

Specify system and use.
PB6. Develop
prototypes.
Make design solution(s) more

concrete using simulations,
models, mock-ups etc. Develop
simulation or trial implementation
of key aspects of the system for
the purposes of testing with users
or user representatives.

Usability Process /
PRO.1.B8: Implement
the user interfaces.

Develop prototypes.
PB7. Develop user

training.
Identify, specify and produce the

training required to enable
relevant users to perform tasks
effectively using the new system.
Cover or include any proposed
changes in business processes,
job design and tasks.
Usability Process View / O

System Integration process.

Usability Process /
PRO.1.BP9:
Implement user
training

Develop user training.
PB8. Develop user
Identify, specify and produce the
Usability Process View / O
138
Evaluation of Design
Solutions
support.
user support services for the

system. Take into account the
proposed changes in business
processes and job design.
System Integration process.
PB1: Specify and

validate context of
evaluation.
Describe and verify the conditions

under which a system is tested or
otherwise evaluated. Describe
the relationship, and especially
discrepancies, between the
context of evaluation and the
context of use.

Assessment and Control
Process.

Usability Process /
team.
Process HCD6 Evaluate

designs against requirements.
/ PB1: Specify and validate
context of evaluation.
PB2: Evaluate
early prototypes in
order to define the
requirements for
the system.
Benchmark appropriate systems

using relevant criteria. Test the
usability of competing/alternative
systems and/or system concepts.
Use prototypes to stimulate
stakeholder input to system
requirements. Test stability of
requirements.

Process.


/ PB2: Evaluate early
prototypes in order to define
the requirements for the
system.
PB3: Evaluate
prototypes in
order to improve
the design.
Collect user input on the quality in

use of the developing system.
Present the results to the design
team(s) in the most appropriate
format.

Process.

Usability Process /
PRO.1.BP6: Identify
design tradeoffs which
impact on user
effectiveness and
efficiency, and
prioritize system
design solutions.

/ PB3: Evaluate prototypes in
order to improve the design.
PB4. Evaluate the

system in order to
check that the
stakeholder and
organizational
requirements
have been met.
Test the developing or final system

to ensure that it meets the
requirements of the users, the
tasks and the environment, as
defined in its specification.

Process.

Usability Process /
PRO.1.BP7: Validate
the software design
against the defined
usability requirements

designs against requirements./
PB4: Evaluate the system in
order to check that the
requirements have been met.
PB5. Evaluate the

system in order to
check that the
required practice
has been
followed.
Check systems for adherence to

applicable human science
knowledge, style guides,
standards, guidelines, and
legislation.

Process.

Usability Process /
PRO.1.BP7: Validate
the software design
against the defined
usability requirements

order to check that the
required practice has been
followed.
PB6. Evaluate the

system in use in
order to ensure
that it continues to
meet
organizational and
user needs.
Check the system in use for

changes in organizational, user,
other stakeholder, and usability
needs and to ensure that it
continues to meet these needs.

Process.


use in order to ensure that it
continues to meet
organizational and user
needs.
139

Develop user support.
Operation
PB1: Management
of change.
Facilitate, oversee and ensure the

HCD aspects of system
implementation

System Architectural Design
process, System Integration
process and Software
Maintenance process.

Usability Process /
team.
Process HCD7 Introduce and

operate the system. / PB1:
Management of change.
PB2: Determine
impact.
Assess the human and

organizational impact of the
system to be introduced.


Usability Process /
team.

Determine impact on
organization and
stakeholders.
PB3:
Customization
and local design.
Provide support for customization

of the system to meet local
cultural or operational needs.
Provide support for customization
and configuration to meet the
needs of specific users. Provide
details of customization to
configuration management.


Usability Process /
team.

Customization and local
design.
PB4: Deliver user

training.
Deliver training and workshops to

users to meet identified training
needs and facilitate the transition
to new designs of jobs and new
team working arrangements.


Usability Process /
PRO.1.BP9:
Implement user
training.

Deliver user training.
PB5: Support
users.
Maintain contact with users and

the client organization throughout
the definition, development and
introduction of a system.


Usability Process /
PRO.1.BP9:
Implement user
training.

Support users.
PB6: Conformance
with ergonomic
requirements.
Survey of workplaces, users and

training programmes to ensure
that the software, hardware and
workplace meet the requirements
of national legislation.


Usability Process /
PRO.1.BP10:
Implement changes in
the system.

Conformance with ergonomic
requirements.
140
Apndice B - Expert Panel Realizado para Avaliar o Modelo

Proposto
Evaluation - Extending a Software Process Capability/Maturity
Model by Usability Engineering
We are inviting you to participate in an Expert Panel to evaluate an extension of a Software
Process Capability/Maturity Model (SPCMM) by Usability Engineering processes.
In this context, we understand SPCMMs, models describing life cycle processes, based on
good engineering and process management principles and a set of process attributes
comprising the capability/maturity aspects, suitable for the purpose of assessing and/or
improving processes.
The SPCMM is defined based on ISO/IEC 15504, including a process and measurement
dimension. The process dimension based on ISO/IEC 12207:2008 is extended through a
process group on Usability Engineering based on Mapping of reference models of usability
engineering (including ISO/TR 18529:2000, ISO/IEC CD 15504-5:2003 PRO.1 Usability,
Amendment 1 to ISO/IEC 12207:1995 and ISO/IEC 12207:2008 E.4 Process View for Usability).
The continuous representation of the measurement framework is based on ISO/IEC 15504-2 as
is, and the staged representation is based on ISO/IEC 15504-7 (extending only the processes
associated to maturity levels).
Our research has been motivated by the fact, that although the importance of usability as a
software quality has even increased in the digital convergence/divergence scenario, commonly
accepted SPCMMs do not cover explicitly Usability Engineering. Therefore, we have
systematically developed an extension to a SPCMM based on ISO/IEC 15504 and would like to
invite you, as author or co-author of one or more papers in this area, to review and evaluate the
method. As part of the review, we would like to ask you review the summary on the SPCMM
extension and to answering a short questionnaire indicating if you consider the proposed
extension complete, correct, consistent, adequate etc. We recognize that your participation in
such an evaluation represents a considerable investment of your time and would be very
grateful for your dedication.
The
summary
on
the
proposed
extension
is
available
at:
http://www.inf.ufsc.br/~rodrigo.rabello/TCC/IntegrationofusabilitySPCMM.pdf.
In
order
to
facilitate reading we are only citing parts that are taken directly from ISO/IEC 12207 and/or
ISO/IEC 15504. If you need further background information on these models to understand the
summary, please get in contact.
The responses will be analyzed and results will be presented only in an accumulated
anonymous form. The results of the evaluation will be published as part of a undergraduate
thesis and research paper. As soon as completed, we would of course, be very happy to share
the results of this evaluation with you, as well as send you the updated version of the extension
based on the review feedback.
The research is being realized by Rodrigo B. Rabello under the coordination of Prof. rer. nat.
Christiane Gresse von Wangenheim, PMP at the GQS Software Quality Group of the INCoD National Research Institute on Digital Convergence (http:// www.incod.ufsc.br). If you have any
questions, please get in contact via email: rodrigo.becker.rabello@gmail.com.
We would appreciate if you could complete the questionnaire no later than 30th April 2012.
Thank you very much your contribution is crucial to the success of this study!
*Required
Name:
Organization:
Country*:
Email:
Years of experience with Software Process Capability/Maturity Models *:
Years of experience with Usability Engineering *:
Mapping of Usability Engineering Models

Evaluation of the mapping of Usability Engineering Models as presented in Annex A.
The processes are mapped correctly to a set of unified processes.
Strongly Disagree
Strongly Agree
The practices are mapped correctly to a set of unified base practices.
Strongly Disagree
Strongly Agree
Any improvement suggestion with respect to the mapping?
SPCMM extension on Usability Engineering

The proposed extension is conformance with ISO/IEC 15504. *
Strongly Disagree
Strongly Agree
The Usability Engineering processes/practices proposed in the extension represent Usability

Engineering correctly. *
Strongly Disagree
Strongly Agree
The Usability Engineering processes/practices proposed in the extension are sufficient to meet
the goals of usability engineering. *
Strongly Disagree
Strongly Agree
The Usability Engineering processes/practices proposed in the extension are consistent with the
definition of the software process as defined by ISO/IEC 12207. *
Strongly Disagree
Strongly Agree
The Usability Engineering processes/practices proposed in the extension do not repeat any
process/practice already defined by ISO/IEC 12207. *
5
142
Strongly Disagree
Strongly Agree
The continuous representation of the measurement framework can - as proposed - be defined

by ISO/IEC 15504-2 as is. *
Strongly Disagree
Strongly Agree
The staged representation of the measurement framework can - as proposed - be defined by

ISO/IEC 15504-7. *
Strongly Disagree
Strongly Agree
The proposed association of the added processes to maturity levels represents adequately the
evolutionary path recommended for an organization that wants to improve Usability Engineering
processes. *
Strongly Disagree
5
Strongly Agree
General Observations
What are the principal strengths of the proposed extension in your opinion?
What are the principal weaknesses of the proposed extension in your opinion?
Any further comment?
Thanks a lot for your participation. Your feedback is very

valuable!
143
Apndice C Artigo do Trabalho
INTEGRAO DE ENGENHARIA DE USABILIDADE EM

UM MODELO DE CAPACIDADE/MATURIDADE DE
PROCESSO DE SOFTWARE
Christiane Gresse Von Wangenheim1
Rodrigo Becker Rabello1
1
Grupo de Qualidade de Software - GQS

Instituto Nacional de Cincia e Tecnologia para Convergncia Digital- INCOD
Departamento de Informtica e Estatsticas - INE
Universidade Federal de Santa Catarina UFSC
88049-200 - Florianpolis SC - Brasil
{gresse,rodrigo.becker.rabello}@gmail.com
Resumo. Especialmente no atual cenrio de convergncia/divergncia digital, a

insero da Engenharia de Usabilidade nos Processos de Engenharia de Software pode
qualificar o projeto de interface, aumentando os ganhos, diminuindo o suporte,
ampliando a competitividade e potencializando a satisfao e a produtividade dos
usurios. Contudo, os principais SPCMMs no integram Processos de Usabilidade.
Assim, este estudo prope uma extenso para um SPCMM que integra processos de
engenharia de usabilidade. Tal extenso foi construda a partir de uma reviso de
literatura sobre os principais modelos de maturidade/capacidade de processo de
softwares existentes e da definio estado da arte, no qual esses modelos foram
analisados e comparados buscando identificar processos ligados engenharia de
usabilidade neles includos. Depois de elaborada, essa extenso foi avaliada atravs de
um Expert Panel.
Palavras-chave: Engenharia de Usabilidade, Modelos de Maturidade/Capacidade,
Interao Humano-Computador.
1. Introduo
Uma qualidade importante de produtos de software a usabilidade. Usabilidade a
medida na qual um produto pode ser usado por usurios especficos para atingir
objetivos especficos com eficcia, eficincia e satisfao em um contexto especfico de
uso (ISO 9241-11, 1998). Sistemas com baixa usabilidade podem impedir que os
usurios executem suas tarefas, deixando-os frustrados. Em algumas situaes, os
efeitos da m usabilidade pode at prejudicar a vida das pessoas (Koppel et al., 2005).
Por outro lado, uma boa usabilidade pode aumentar a satisfao e a produtividade do
usurio e, conseqentemente, aumentar o lucro e a competitividade das organizaes de
software.
Especialmente, no cenrio atual da convergncia/divergncia digital em que as
aplicaes podem estar presentes em diversos dispositivos (computadores, tablets,
celulares, TV digital interativa, etc.), a importncia da usabilidade tem aumentado, pois
um dos principais desafios a customizao dessas aplicaes para os diferentes meios
de entrada e de sada dos dados (tamanho da tela, teclado vs touchscreen vs controle
remoto, etc.)
Tambm podemos observar uma necessidade de orientao para a melhoria do
processo de engenharia de usabilidade, voltado para uma melhoria na qualidade dos
144
produtos. No entanto, hoje, modelos e normas comumente adotados para melhoria de

processo de software, tais como, o framework CMMI (SEI, 2010) ou ISO / IEC 15504
(ISO / IEC, 2003) no abordam engenharia de usabilidade (JOKELLA et al., 2006) .
Uma reviso sistemtica da literatura dos modelos de maturidade/capacidade de
processo de software (SPCMM) tambm no conseguiu identificar modelos adaptados
com este foco (Wangenheim et al., 2010). Esta falta de integrao de engenharia de
usabilidade dentro do processo de software pode tambm ser observada, em geral, na
rea de Engenharia de Software. A norma ISO / IEC 12207:2008 que descreve o
processo de ciclo de vida do software, e o SWEBOK, um guia de conhecimento de
Engenharia de Software, por exemplo, no abordam explicitamente a Engenharia de
Usabilidade.
Existem modelos e padres especficos para a engenharia de usabilidade
(JOKELLA et al., 2006). Contudo, apesar de nos ltimos anos vrios autores j terem
sugeridos a integrao de engenharia de usabilidade no processo de software nos
ltimos anos ((Nebe & ZIMMERMANN, 2007), (ANDERSON et al, 2001), (FERRE,.
JURISTO; MORENO, 2005)), at o presente momenteo, tal integrao no ocorreu de
forma permanente nos SPCMMs mais utilizados.
2. Problema de Pesquisa
O objetivo desta pesquisa propor uma extenso para um SPCMM integrar o processo
de engenharia de usabilidade. O contexto de uso dessa extenso direcionado para o
desenvolvimento e manuteno de produtos de software que requerem usabilidade como
uma qualidade importante, especialmente no cenrio de convergncia/ divergncia
digital.
Com base em uma reviso e anlise da literatura, identificou-se as seguintes
fontes como base para a definio da extenso:
SPCMM
ISO/IEC 15504-2
Dimenso de Processo
Processos de Software (em geral)
ISO/IEC 12207:2008
ISO/IEC 15504-5 (Gesto Organizacional; Gesto de Solicitaes de Mudanas)
ISO/IEC 15504-7 (Gesto do Desempenho Quantitativo; Melhoria de Processo
Quantitativa)
Processos de Engenharia de
Usabilidade
ISO/TR 18529:2000
ISO/IEC CD 15504-5:2003 PRO.1 Usabilidade
Amendment 1 to ISO/IEC 12207:1995
ISO/IEC 12207:2008 E.4 Viso de Processo para Usabilidade
Framework de Medio
Nveis de Capacidade
ISO/IEC 15504-2
Nveis de Maturidade
ISO/IEC 15504-7
Seguindo a estrutura bidimensional de SPCMM definido pela norma ISO / IEC

15504-2, foi estabelecida uma dimenso de processo e um framework de medio. A
relao entre o modelo de referncia de processo, a estrutura de medio e o modelo de
avaliao de processo pode ser visto na figura 1. Este modelo bidimensional formado
por um conjunto de processos, com seus propsitos e resultados, e uma estrutura de
medio que possui um conjunto de atributos que se aplicam a todos os processos. Os
processos so agrupados em nveis de capacidade para determinar qual o seu nvel. O
resultado da avaliao possui um conjunto de perfis de processos e, opcionalmente, uma
145
classificao de nvel de capacidade para cada processo avaliado.
Figura 1 Relacionamentos no modelo de avaliao de Processo - Fonte: Adaptado

de ISO/IEC, 2003.
A fim de elaborar uma extenso para o processo de software conforme proposta

na norma ISO / IEC 12207:2008 (utilizada como modelo de referncia para o processo
de software em geral), definiu-se um novo grupo de processos que representam o
processo de engenharia usabilidade. Este grupo de processos foi definido de acordo com
o processo de adaptao definido no anexo A da norma ISO / IEC 12207:2008. Num
primeiro passo, as fontes de processo de engenharia usabilidade foram mapeadas em um
nico conjunto de processos e prticas (Anexo A). Depois, esse conjunto unificado de
processos e prticas foi integrado no modelo de referncia com base na ISO / IEC
12207. Durante esta etapa, processos que no so cobertos pela norma ISO / IEC
12207:2008 foram adicionados como novos processos. O contedo dos processos e
prticas unificadas abrangidas por outros processos da ISO / IEC 12207:2008 ou
atributos de processo de medio da dimenso definida na ISO/IEC 15504 so
identificados e mapeados na Tabela 2. Para cada um dos novos processos adicionados
uma descrio detalhada processo foi definida com base nas prticas unificadas
identificadas.
A respeito da estrutura de medio, basicamente adotou-se a definio dos nveis
de capacidade da ISO / IEC 15504-2. No que diz respeito definio de nveis de
maturidade, tambm se adotou a definio da norma ISO / IEC 15504-7, adicionando
apenas os processos de usabilidade para os respectivos nveis de maturidade.
3. Extenso de um SPCMM para Engenharia de Usabilidade

3.1 Definio da Dimenso de Processo
A dimenso de processo baseada na norma ISO / IEC 12207:2008 como modelo de
referncia para o processo de software geral. Em conformidade com o processo de
adaptao, previsto no Anexo A da norma ISO / IEC 12207:2008, uma extenso do
padro foi proposta, definindo um grupo de processos adicionais de Engenharia de
Usabilidade, mostrado na Figura 2 (marcado em verde) e detalhados na Tabela 1.
Alm disso, mais processos (marcado em azul e amarelo na Figura 2) foram
adicionados conforme eles so estabelecidos na norma ISO / IEC 15504 partes 5 e 7, a
fim de manter a conformidade com a estrutura de maturidade definido pela mesma (pois
estes processos no so cobertos pela ISO / IEC 12207:2008).
146
Figura 2 Processos do Modelo de Referencia com Extenso para Engenharia de

Usabilidade
Tabela 1 Processos do modelo de referncia para Usabilidade*
Nmero
Processo
do
2.4
2.4.1
2.4.2
2.4.3
2.4.4
Nome do Processo
Origem
Processos
de
engenharia
de
usabilidade
Processo
de
gesto
do
desenvolvimento
centrado
no
humano
Processo de especificao do
contexto de uso
Processo de produo de solues
de projeto
Processo de avaliao das solues
de projeto
ISO/TR 18529:2000
Nmero do
processo
na origem
ISO/TR 18529:2000
HCD 1
ISO/TR 18529:2000
HCD 4
ISO/TR 18529:2000
HCD 5
ISO/TR 18529:2000
HCD 6
Nome do Processo na origem

Processos
de
engenharia
de
usabilidade
Processo
de
gesto
do
desenvolvimento
centrado
no
humano
Processo
de
compreenso
e
especificao do contexto de uso
Processo de produo de solues
de projeto
Processo de avaliao dos projetos
em relao aos requisitos
* Tabela completa em RABELLO, 2012.

3.1.1 Definio dos Processos de Engenharia de Usabilidade
A definio dos processos de engenharia de usabilidade foi baseada em uma
comparao e mapeamento de processos de Engenharia de Usabilidade de vrios
modelos de referncia, tal como apresentado no anexo A.
A Tabela 2 ilustra a forma como os processos e prticas bases unificadas
correspondem aos processos da ISO / IEC 12207 (utilizados como base para o modelo
de referncia de processo de software) ou aos atributos da estrutura de medio tal como
definido pela norma ISO / IEC 15504. Com base nos resultados desta avaliao da
correspondncia, as decises sobre a forma de integrar os respectivos processos e
prticas no SPCMM estendido so mostradas na Tabela 2 (Colunas 5-6).
Tabela 2 Mapeamento dos processos e prticas unificadas em relao aos processos
das ISO/IEC 15504 e ISO/IEC 12207*
Processos e Prticas Unificadas
Processos
Prticas Bases
Correspondentes
Processos /
Prticas Bases
Atributo de
Deciso de design do Modelo

Processos
Prticas Bases
147
Unificados
Processo de
gesto do
desenvolviment
o centrado no
humano
Unificadas
Processo
Representar os Stakeholders;
Coletar inteligncia de
mercado;
Inexistente
Inexistente
Integrado
totalmente
no
modelo.
Novo
processo
chamado: Gesto
do
desenvolvimento
centrado
no
humano
Integradas
as
prticas como
as
mesmas
foram definidas
no
novo
processo.
PA 2.1 Atributo de
gerncia de
execuo - ISO/IEC
15004
Identificar
os
objetivos de execuo
do processo;
Planejar e monitorar
a execuo do processo;
Ajustar a execuo
do processo;
Definir
responsabilidade
e
autonomia
para
execuo do processo;
Identificar
e
disponibilizar recursos
para
execuo
do
processo;
Gerenciar
o
relacionamento entre as
partes envolvidas;
No houve a
necessidade
de
integrao
Mantidas
as
prticas
do
atributo
de
processo PA 2.1
Definir e planejar uma

estratgia do sistema;
Coletar opinies do Mercado;
Analisar as tendncias dos
usurios;
Planejamento e
gerenciamento
do processo de
desenvolviment
o centrado no
humano.
Consultar os Stakeholders;
Planejar o envolvimento dos
usurios;
Selecionar tcnicas centradas no
humano;
Assegurar uma abordagem
centrada no humano;
Planejar e gerenciar atividades
de desenvolvimento centrado no
humano;
Defender a abordagem
desenvolvimento;
de
Apoiar
desenvolvimento
centrado no humano;

3.2 Framework de Medio
O framework de medio do SPCMM estendido baseado na norma ISO / IEC 15504,
que possui representao contnua e por estgios.
3.2.1 Definio da Representao Contnua
Adotamos a representao contnua da ISO / IEC 15504-2, onde a capacidade do
processo definido em uma escala ordinal de seis pontos, que permite que a capacidade
seja avaliada a partir do inicio da escala, nvel incompleto, at a extremidade superior
desta, nvel otimizado. A medida da capacidade baseia-se em no conjunto de atributos
de processos da ISO / IEC 15504-2.
3.2.2 Definio da Representao por Estgios
Conforme a ISO / IEC 15504-7, maturidade organizacional definido como uma
expresso do grau em que uma organizao implementa seus processos de forma
consistente dentro de um escopo definido, o que contribui para a o alcance de seus
objetivos de negcios atuais ou futuros. A maturidade organizacional expressa numa
escala de seis pontos ordinais, do nvel de maturidade 0 ao nvel de maturidade 5, assim
como a definio pela ISO / IEC 15504-7.
Com base no exemplo de modelo de maturidade organizacional apresentado no
Anexo A da ISO / IEC 15504-7, o conjunto de processos foi associado aos nveis de
maturidade, incluindo os quatro novos processos de engenharia de usabilidade (como
indicado na Tabela 2).
Os processos 2.4.2 Especificao do contexto de uso, 2.4.3 Produo de
solues de projeto e 2.4.4 Avaliao das Solues de Projeto que representam
processos tcnicos do ciclo de vida da engenharia de usabilidade esto associadas ao
conjunto mnimo de processos do nvel de maturidade 1 em correspondncia a
148
associao de processos de tcnicos de software para este nvel de maturidade (tais

como a anlise dos requisitos do sistema, construo de software, etc.). O processo 2.4.1
Gesto do desenvolvimento centrado no ser humano est associado ao nvel de
maturidade 3, devido ao foco do nvel 3 em gesto organizacional e estratgica.
Como a base para a dimenso do processo SPCMM estendido foi a ISO / IEC
12207, os processos do modelo de maturidade organizacional exemplar (ISO / IEC
15504-5), foram substitudos pelos processos correspondentes da ISO / IEC 12207
(Tabela 3).
Tabela 3 Processos associados aos nveis de maturidade
ML
Lista de Processos
1.4.1 Definio dos requisitos dos Stakeholders
1.4.2 Anlise dos requisitos do sistema
1.4.3 Projeto de arquitetura do sistema
1.4.4 Implementao
Conjunto Bsico de Processos
2.1.2 Anlise das especificaes do software

2.1.3 Projeto de arquitetura de software
2.1.4 Processo de software
2.1.5 Construo do software
2.1.6 Integrao do software
2.1.7 Teste de qualificao de software
1.4.5 Integrao do sistema
1.4.6 Teste de qualificao do sistema
1.4.7 Instalao do software
1.4.8 Suporte de aceitao de software
1.4.9 Operao de software
1.4.10 Manuteno do software
1.4.11 Desativao de software
Conjunto
Mnimo
1.4.1
1.4.4
Processos Adicionais
Identificao
Condies
1.4.2
1.4.3
1.4.5
1.4.6
1.4.7
Necessrio
quando
o
desenvolvimento
abrange
questes de sistema.
2.4.2
2.4.3
2.4.4
1.4.8
1.4.9
1.4.10
1.4.11
Necessrio
quando
a
organizao responsvel
pela manuteno e evoluo
permanente do software e/ou
sistema.
2.2.1
2.2.2
2.2.3
2.2.4
2.2.8
2.2.9
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.1.1
Necessrio
quando
fornecedores internos ou
externos esto envolvidos em
projetos de desenvolvimento
2.2.5
Necessrio
quando
a
confirmao da aptido para
utilizao dos produtos de
trabalho
de
responsabilidade
da
organizao
2.2.6
Opcional quando o trabalho

na organizao envolve
acordos com os stakeholders.
1.1.2
Opcional quando o trabalho

na organizao envolve apoio
de aceitao de produto.
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
Necessrio
quando
a
organizao responsvel
pela instalao do produto de
software no ambiente do
cliente
Conjunto Estendido de Processos
2.4.2 Compreenso e especificao do contexto de uso

2.4.3 Produo da soluo HCD
2.4.4 Avaliao do projeto em relao aos requisitos HCD
2.2.1 Gesto de documentao de software

2.2.2 Gesto de configurao de software
2.2.3 Garantia de qualidade de software
2.2.4 Verificao de software
2.2.5 Validao de software
2.2.6 Reviso de software
2.2.8 Resoluo de problemas de software
2.2.9 Gesto de solicitaes de mudana
1.3.1 Planejamento de projeto
1.3.2 Controle e avaliao de projeto
1.3.3 Tomada de deciso
1.3.4 Gesto de risco
1.3.5 Gesto de configurao
1.3.6 Gesto de informao
1.1.1 Aquisio
1.1.2 Fornecimento
149
1.2.1 Gesto de modelo de ciclo de vida

1.2.2 Gesto de infraestrutura
1.2.3 Gesto de portflio de projetos
1.2.4 Gesto de recursos humanos
1.2.5 Gesto de qualidade
1.2.6 Gesto organizacional
1.3.7 Gesto de medio
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.3.7
2.2.7
2.4.1
2.3.1
2.3.2
2.3.3
Opcional se a organizao
tem um programa de
reutilizao estruturado em
vigor.
2.2.7 Auditoria de software

2.3.1 Engenharia de domnio
2.3.2 Gesto de reuso de ativos
2.3.3 Gesto de programa de reuso
2.4.1 Gesto do desenvolvimento centrado no humano
4
1.2.7 Gesto do desempenho quantitativo
1.2.8 Melhoria de processo quantitativa
4. Avaliao do Modelo Proposto

O modelo proposto foi avaliado com o objetivo de verificar se o mapeamento dos
modelos de referncia de engenharia de usabilidade est correto, se a conformidade, a
qualidade, a completude e se o modelo proposto est correto.
4.1 Definio
A avaliao foi realizada por meio de um expert panel, um mtodo de avaliao
emprica baseada na opinio de especialistas, Beecham et al. (2005).
Para definir sistematicamente os dados a serem coletados na avaliao, o mtodo
GQM Goal/Question/Metric (BASILI et al., 1994) foi utilizado. O mtodo GQM
suporta a definio sistemtica de objetivos e a derivao de perguntas que, quando
respondidas, atendem estes objetivos.
Tambm referente aos objetivos de avaliao, quatro questes descritivas foram
elaboradas a fim de obter um feedback maior dos especialistas e encontrar os pontos
fortes, fracos e possveis pontos de melhorias no modelo.
A partir da decomposio dos objetivos em perguntas foi elaborado um
questionrio para coletar dados referentes s questes identificadas. No questionrio foi
usado para as perguntas, uma escala likert de 5 pontos entre 1 (discordo totalmente) e 5
(concordo totalmente).
Alm disso, foram includas perguntas de forma aberta referente s questes
descritivas.
4.2 Execuo
A execuo da avaliao ocorreu entre os dias 16 de abril a 06 de maio de 2012.
Para esta avaliao, os especialistas foram selecionados por sua expertise em
relao a modelos de maturidade/capacidade de processo de software, a engenharia de
usabilidade ou a engenharia de software.
Basicamente, foram selecionados os autores das normas/artigos/estudos
apresentados neste trabalho e outros considerados de relevncia. Foram selecionados 30
especialistas para participarem desta avaliao.
Estes especialistas foram convidados a participar do expert panel via e-mail.
Tambm foi disponibilizado um resumo do trabalho para que os especialistas pudessem
fazer a avaliao de forma mais efetiva.
150
Atravs da plataforma Google Docs (https://docs.google.com), o questionrio foi

disponibilizado para que os especialistas o respondessem na forma de um formulrio
web.
4.3 Anlise dos dados
Ao total, seis especialistas responderem a avaliao, representando uma taxa de 20% de
retorno.
Caracterizao dos Especialistas
Dentre os seis especialistas que responderam a avaliao, dois eram do Brasil,
um do Reino Unido, um da Esccia, um da Itlia e outro da Finlndia. Possuam de dez
a vinte anos de experincia com SPCMMs e, em relao engenharia de usabilidade,
dois no possuam experincia, um possua dois anos, um possui 15 anos, outro possui
28 anos e o ltimo possua quarenta anos de experincia na rea.
Destes especialistas, um no se sentiu confortvel para responder as questes na
escala likert e s respondeu s questes descritivas. Devido a isso, o seu feedback foi
levado em considerao apenas em relao as sugestes de melhorias, os pontos fortes e
fracos apontados.
Anlise das respostas referentes ao mapeamento dos modelos de referncia
de engenharia de usabilidade
Primeiramente, foram analisadas as questes referentes ao mapeamento dos
modelos de referncia de engenharia de usabilidade.
A maioria dos especialistas considerou que o mapeamento foi feito de forma
correta, sendo que, apenas um deles discordou parcialmente do mapeamento para o
conjunto de processos unificados.
Os especialistas sugeriram que a ISO / TS 18152:2010 - Ergonomics of humansystem interaction -- Specification for the process assessment of human-system issues
poderia ser til como recurso para o modelo quando utilizado para grandes projetos.
Outra sugesto foi utilizao da ISO/IEC TR 24774:2010 - Systems and
software engineering -- Life cycle management -- Guidelines for process description
para descrever as definies dos processos adicionados.
Eles tambm sugeriram a utilizao de outros trabalhos e fontes que no se
encaixam no perfil dos modelos tpicos de maturidade para servir como orientao para
o mapeamento.
Anlise das respostas referentes extenso do SPCMM
Em relao conformidade com a ISO/IEC 15504 e, se a mesma representa
corretamente a engenharia de usabilidade, a maior parte dos especialistas concordoram
com a extenso proposta.
Trs especialistas concordaram que a extenso proposta suficiente para atingir
os objetivos da engenharia de usabilidade, porm dois deles discordaram disto.
A maioria das respostas quanto consistncia na definio dos processos de
software, conforme definido pela norma ISO/IEC 12207, foi positiva. Porm, um dos
especialistas discordou parcialmente disto.
Os especialistas no concordaram e nem discordaram quando questionados se a
extenso no repete nenhum processo/prtica j definido na ISO/IEC 12207.
Os especialistas concordaram que a representao contnua da proposta est em
conformidade com a parte dois da ISO/IEC 15504. J em relao representao em
estgios, no houve um consenso entre as respostas.
151
Quando questionados se os processos adicionados aos nveis de maturidade

representam adequadamente o caminho evolucionrio recomendado para uma
organizao melhorar seus processos de engenharia de usabilidade, grande parte dos
especialistas concordou com a extenso proposta, porm, um deles discordou
plenamente disto.
Pontos Fortes
Em relao aos pontos fortes, os especialistas concordam que o modelo pode
fornecer recursos para ajudar a promover a usabilidade dos produtos, recursos estes,
geralmente inexistentes nos modelos de referncia de processos.
A utilizao da ISO/IEC 15504 e da ISO/IEC 12207, como modelos base, foi
apontada como ponto forte, assim como o detalhamento do trabalho que, de acordo com
um dos especialistas, suficiente para que o mesmo, aps suas atualizaes, possa ser
apresentado para o comit da ISO/IEC como uma nova proposta de item de trabalho
para estender os modelos de avaliao de processo da srie ISO/IEC 33000.
Pontos Fracos
Os especialistas ressaltaram a falta da integrao com outras partes da ISO/IEC
12207 que incluem aspectos de ergonomia. Outro ponto fraco levantado foi que o
modelo de processos precisa ser melhorado, utilizando-se das definies da ISO / IEC
24774.
Eles tambm recomendaram que a ISO/IEC CD 15504-5:2003 seja substituda
pela ISO/IEC 15504-5:2012, tornando assim as referncias utilizadas no modelo mais
atuais.
Um dos especialistas alegou que as organizaes que desejarem melhorar apenas
o processo de software e de usabilidade, mas no outros atributos de software, podem
adaptar a ISO/IEC 15504 com outras normas, montando o perfil que desejam avaliar ou
melhorar, o que pode tornar o modelo proposto desnecessrio.
Sugestes ou comentrios
Um dos especialistas sugeriu a excluso da extenso do modelo de maturidade,
pois os processos de engenharia de usabilidade que so de maior interesse para o
trabalho. E props a alterao do formato das respostas em escala likert do expert panel
para que elas permitam maiores comentrios.
Tambm foi sugerido que os processos adicionados no nvel 1 de maturidade
no possuam prticas que so necessrias apenas em nveis mais elevados, e que o
processo de gesto do desenvolvimento centrado no humano seja alocado ao conjunto
mnimo de processos do nvel 2 de maturidade, pois lida com o planejamento e por isso,
deve contribuir para um planejamento global.
4.4 Discusso
Nesta avaliao os especialistas levantaram pontos fortes, pontos fracos e sugestes de
melhorias para o modelo. A atualizao e aprimoramento do modelo proposto, atravs
da utilizao de outras normas e padres, devem ser considerados para que o mesmo
atinja seus objetivos, de forma mais abrangente, nos setores/organizaes/projetos
aonde isto no est ocorrendo no momento. A descrio dos processos tambm pode ser
melhorada utilizando-se da norma especfica para isso.
Os processos de engenharia de usabilidade adicionados devem ser revistos para
verificar se os objetivos so atendidos em sua totalidade, pois este item foi o que obteve
maior grau de discordncia entre todos os itens avaliados. Eles tambm podem ser
152
revisados mais a fundo para verificar se no repetem prticas j definidas na norma

ISO/IEC 12207.
Algumas prticas bases dos processos alocados ao nvel de maturidade 1 devem
ser checadas para verificar a existncia de prticas necessrias apenas em nveis mais
elevados, e deve ser avaliado se o processo gesto do desenvolvimento centrado no
humano deve ser alocado ao nvel 2 de maturidade.
Apesar das consideraes dos especialistas, todos eles concordaram que o
modelo til e possui recursos que podem ser usados por organizaes que desejam
avaliar/melhorar seu processo de software alinhado com usabilidade. O modelo tambm
foi visto com embasamento e detalhamento suficiente para que possa ser apresentado,
aps suas melhorias, a um comit ISO como uma nova proposta de trabalho.
Ameaas validade
Alguns fatores podem ameaar ou influenciar de alguma forma os resultados
desta avaliao. O fato de ser uma avaliao inicial envolvendo um nmero baixo de
especialista faz com que o grau de generalizao dos resultados seja muito baixo.
O formato escolhido para as questes, uma escala likert entre discordo e
concordo, no permite maiores consideraes e pode ter sido inadequado nesse estado
da pesquisa. Esta situao ocorreu com um dos especialistas e outro deles sugeriu a
alterao no formato destas. Porm, o formato das perguntas foi bem aceito pelos
demais participantes da avaliao.
A inexperincia em relao engenharia de usabilidade de alguns especialistas
tambm pode distorcer ou deformar os resultados da avaliao. O perodo curto de
avaliao pode ter feito com que as avaliaes ocorressem de forma apressada e com
menos critrios do que a mesma necessitaria.
Outra ameaa a validade dos resultados pode ter sido introduzido pelo resumo
do trabalho que pode ter suprimido informaes importantes, levando a avaliaes
equivocadas por parte dos especialistas.
5. Concluso
Neste trabalho, primeiramente, o contexto do tema proposto foi analisado, buscando-se
conhecer na fundamentao terica os conceitos que envolvem os SPCMMs,
convergncia/divergncia digital e usabilidade. Em um segundo passo, a reviso do
estado da arte foi realizada com o objetivo de encontrar SPCMMs focados em processos
de engenharia de usabilidade no contexto da convergncia digital. Nesta fase, verificouse que no existem trabalhos com este objetivo.
Embasado na fundamentao terica e na reviso do estado da arte foi feito um
mapeamento dos modelos de referncia de engenharia de usabilidade, a fim de criar um
conjunto unificado de processos e prticas de usabilidade para serem integrados no
modelo. Em seguida, foi criada a definio da extenso do modelo de referncia e do
framework de medio com a adio dos processos de usabilidade. Aps isso, uma
avaliao atravs de um expert panel foi realizada.
Com o trabalho finalizado, espera-se que o modelo proposto contribua para as
organizaes que desejam avaliar / melhorar seus processos de software e de
usabilidade, servindo como um guia de melhores prticas para orient-las.
Principalmente no cenrio da convergncia/divergncia digital, espera-se que a
integrao de aspectos da engenharia de usabilidade em um SPCMM contribua
positivamente na melhoria de processos de software e, consequentemente, na melhoria
de produtos de software em termos da usabilidade.
153
Como trabalhos futuros, pretende-se evoluir o modelo proposto destacando

ainda mais os pontos fortes, corrigindo ou diminuindo ao mximo os pontos fracos e
implementando as sugestes de melhoria dos especialistas. E aps estas atualizaes,
realizar uma nova avaliao para verificar se tais melhorias realmente foram efetivas.
Agradecimentos
Este trabalho foi apoiado pelo CNPq (Conselho Nacional de Desenvolvimento
Cientfico e Tecnolgico), uma entidade do governo brasileiro focada no
desenvolvimento cientfico e tecnolgico, o MCT (Ministrio da Cincia e Tecnologia)
/ FINEP (Financiadora de Estudos e Projetos) e FAPESC (Fundao de Amparo
Pesquisa e Inovao do Estado de Santa Catarina).
Referncias
SOFTWARE, 2001.
BASILI, V. R. et al. The Goal Question Metric Approach. Maryland, 1994.
Disponvel em: <ftp://ftp.cs.umd.edu/pub/sel/papers/gqm.pdf> Acesso em fevereiro
de 2012.
BEECHAM, S.; HALL, T.; BRITTON, C.; COTTEE, M.; RAINER, A. Using an
Expert Panel to Validate a Requirements Process Improvement Model. The
Journal of Systems and Software, v. 76, 2005.
FERR, X.; JURISTO, N.; MORENO, A. M. Framework for Integrating Usability
Practices into the Software Process.In: 6th International Conference on Product
Focused Software Process Improvement. Oulu, Finland: 2005.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15504:
Information Technology - Process Assessment.2003.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9241:
Ergonomic requirements for office work with visual display terminals (VDTs) -Part 11: Guidance on usability.1998.
Information Technology - Process Assessment Part 5: An Exemplar Process
Assessment Model. 2006.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC CD
15504-5.4: Information Technology - Process Assessment Part 5: An Exemplar
Process Assessment Model. 2003.
Information Technology - Process Assessment Part 7: Assessment of
Organizational. 2008.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION.
12207:Processo do Ciclo de Vida do Software. 2008.
ISO/IEC
154
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION.

12207:1995/FDAM: Processo do Ciclo de Vida do Software. 2001.
ISO/IEC
INTERNATIONAL
ORGANIZATION
FOR
STANDARDIZATION.
13407:Human-Centred Design Process for Interactive System. 1999.
ISO
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/TR

18529:2000 Ergonomics of human-system interaction -- Human-centred
lifecycle process descriptions. 2000.
JOKELLA, T. et al. A Survey of Usability Capability Maturity Models:
Implications for Practice and Research. Behaviour & Information Technology,
Vol. 25, No. 3. 2006.
KOPPEL, R. et al. Role of Computerized Physician Order Entry Systems in
Facilitating Medication Errors. Journal of the American Medical Association
JAMA - Vol. 293 No. 10. 2005.
NEBE, K.; ZIMMERMANN, D. Aspects of Integrating User Centered Design into
Software Engineering Processes. Proc. of 12th Int. Conf. on Human-computer
interaction: interaction design and usability, 2007.
RABELLO, R. Integrao de Engenharia de Usabilidade em um Modelo de
Maturidade/Capacidade de Processo de Software. UFSC, 2012.
SOFTWARE ENGINEERING INSTITUTE. CMMI Capability Maturity Model
Integration. Disponvel em <http://sei.cmu.edu/cmmi>. Acesso em maio 2011.
SOFTWARE ENGINEERING INSTITUTE. CMMI for Development V1.3. 2010.
Disponvel em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em abril
2011.
SOUZA, L. S.; SPINOLA, M. M. Requisitos de Usabilidade em Projetos de
Interface Centrado no Usurio de Software de Dispositivos Mveis. Associao
Brasileira de Engenharia de Produo. Outubro de 2006.
Capability/Maturity Models. SPICE - 10th International Conference on Software
Process. Improvement and Capability dEtermination, Pisa/Italy, 2010.
155
Anexo A
Mapeamento dos modelos de referncia de engenharia de usabilidade*
GC = Grau de cobertura; T = Totalmente coberto; P = Parcialmente coberto; - = Sem cobertura;
Processos Unificados
Prticas Bases
Unificadas
Descrio
ISO/IEC 12207:2008
GC*
desenvolvimento centrado
no humano
PB1: Representar os
Stakeholders.
Atuar como advogado dos usurios

finais e dos stakeholder na empresa e
na equipe de desenvolvimento do
sistema.
Viso
de
processo
para
usabilidade / Processo de Gesto
de Portflio de Projetos.
P*
Processo
de
Usabilidade
Atividades:
Implementao do processo.
PB2:
Coletar
inteligncia
de
mercado.
Realizar investigao prospectiva em

grupos de usurios potenciais, a fim
de identificar necessidades futuras,
novos usurios ou organizaes
usurios para o sistema. Estabelecer
procedimentos para descobrir a
aceitao dos usurios no contexto
esperado.
Obter
informaes
sobre
o
mercado atual
como uma
viso. Operacionalizar esta viso em
estratgia
de
implementao. Utilize ciclo
de
vida de contabilidade de custos, a fim
de
avaliar
o
custo de
uma
abordagem HCD.
Executar pesquisa otimizada para
refinar e consolidar a estratgia do
sistema, com base no feedback dos
usurios e
no
usurios no
mercado do sistema.
Procure mudanas em: usurios (por
exemplo, suas
habilidades e
treinamento para organizaes de
usurios, bem como as necessidades e
desejos de produtos de consumo),
tarefas (por exemplo, mudanas no
tipo de trabalho ou de volumes de
trabalho), contexto (por exemplo,
mudanas em ambientes de trabalho e
de vida, as novas tecnologias,
costumes sociais e polticos e as
informaes
para estimar
as
Viso
de
processo
para
Processo
de
Usabilidade
/
Atividade:
Aspectos humanos de estratgia,
implantao e suporte.
Viso
de
processo
para
Viso
de
processo
para
Viso
de
processo
para
Stakeholders,
Processo
de
Sistema e o Processo de Anlise
de Requisitos de Software
PB3:
Definir
e
planejar
uma
estratgia
do
sistema.
PB4.
opinies
Mercado.
Coletar
do
PB5. Analisar as
tendncias
dos
usurios.
Amendment to ISO/IEC
12207:1995
GC
ISO/IEC CD 155045:2003
GC
ISO/TR 18529:2000
GC
Processo HCD1 Garantir que o

humano esteja no projeto do
sistema. / PB1: Representar os
Stakeholder.
T*
especialista
em
usabilidade na equipe de
desenvolvimento
do
sistema.
-*

sistema.
/
PB2:
Coletar
inteligncia de mercado.
Processo
de
Usabilidade
/
Atividade:

sistema. / PB3: Definir e planejar
uma estratgia do sistema.
Processo
de
Usabilidade
/
Atividade:
Processo
de
Usabilidade
/
Atividade:

sistema. / PB4. Coletar opinies
do Mercado.
sistema. / PB5. Analisar as
tendncias dos usurios

Relatorio Final Rodrigo Becker Rabello 2012 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Relatorio Final Rodrigo Becker Rabello 2012 PDF

Caricato da

Copyright:

Formati disponibili

UNIVERSIDADE FEDERAL DE SANTA CATARINA

INTEGRAO DE ENGENHARIA DE USABILIDADE EM UM

Rodrigo Becker Rabello

UNIVERSIDADE FEDERAL DE SANTA CATARINA

INTEGRAO DE ENGENHARIA DE USABILIDADE EM UM

Rodrigo Becker Rabello

Relatrio de Concluso de Curso

Rodrigo Becker Rabello

INTEGRAO DE ENGENHARIA DE USABILIDADE EM UM

Relatrio de Concluso de Curso apresentado como exigncia parcial para

Lista de Siglas e Abreviaturas

maturidade/capacidade de processo de software no abordam esta questo.

fundamentao terica e uma anlise do estado da arte em relao aos

positivamente na melhoria de processos de software e, consequentemente, na

O setor de desenvolvimento de software brasileiro encontra-se em franca

Por isso, atualmente, adota-se SPCMMs para orientar a avaliao e a

Um dos requisitos observado para que se considere um software com

desenvolvimento de software so o projeto e o design de interface com boa

sistematicamente o seu processo de software na parte da engenharia de

O1. Analisar o processo de software no cenrio da convergncia/divergncia

O2. Analisar o estado da arte dos modelos de maturidade/capacidade de

O3. Desenvolver uma integrao de engenharia de usabilidade em um modelo

O4. Avaliar este modelo de maturidade/capacidade de processo de software

Etapa 1. Fundamentao terica: Ser realizado um estudo na rea de

maturidade/capacidade de processo de software. Posteriormente, ser feito um

maturidade/capacidade de processo de software, e analisar a incluso de

processos ligados engenharia de usabilidade nesses modelos. Sero

Etapa 3. Concepo e desenvolvimento do modelo: Com base na anlise

maturidade/capacidade de processo de software (ISO/IEC 12207/15504),

maturidade/capacidade de processo de software (ISO/IEC 12207).

Etapa 4. Avaliao: O modelo proposto ser avaliado em relao aos

realizada e na seo 6 faz-se uma concluso e apresentam-se possveis

(GOODMAN; GOLDMAN, 2007).

desenvolvimento, aquisio e manuteno de produtos e servios (SEI, 2010).

Na prtica, um SPCMM encoraja a organizao a manter um

Eles possuem aspectos de maturidade/capacidade de processos que

A dimenso do processo define um conjunto de entidades que

maturidade/capacidade, como mostra a figura 2:

Figura 2 Dimenses da ISO/IEC 15504 - Fonte: ISO/IEC, 2006.

Esta norma estabelece uma abordagem contnua na avaliao de

O processo executado e consegue alcanar sua

O processo executado de uma forma controlada e seus

O processo previsvel melhorado continuamente para

A norma tambm possibilita determinar se uma organizao implementa

avaliando a sua maturidade organizacional (lSO/IEC, 2008). Isto estabelece

A organizao demonstra que atinge os objetivos dos

A organizao demonstra que consegue gerenciar os

A organizao demonstra a efetiva definio e

A organizao demonstra a habilidade de mudar e

J na dimenso de processo, a parte dois da norma define os requisitos

Figura 3 Processos da ISO/IEC 15504-7 Fonte: Adaptado de ISO/IEC, 2008.

Os processos primrios de ciclo de vida so aqueles que esto mais

A norma ISO/IEC 12207 estabelece uma estrutura comum para os

Software (ISO/IEC, 2008).

O quadro 3 apresenta a descrio de um processo da norma:

O Capability Maturity Model Integration (CMMI) foi criado pelo Software

representao em estgios e representao contnua (SEI, 2010).

Os nveis de maturidade aplicam-se maturidade geral de uma

relacionadas a um conjunto predefinido de reas de processo que melhoram o

O CMMI pode ter seus componentes agrupados em trs categorias:

Figura 5 Componentes do CMMI Fonte: SEI, 2010.

Os componentes requeridos demonstram o que a organizao deve

fazer para implementar uma rea de processo. Os componentes esperados