wise: uma abordagem de ferramenta de software … · tabela 4.1: requisitos funcionais para a...
TRANSCRIPT
UNIVERSIDADE DA AMAZÔNIACENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
CARLOS ALBERTO COSTA DE ALBUQUERQUE JÚNIOR JOÃO AMÉRICO FREITAS FONSECA SANTOS
JULIO CEZAR COSTA FURTADO
WISE: UMA ABORDAGEM DE FERRAMENTA DE SOFTWARE PARA O AUXÍLIO NO MODELO DE
AVALIAÇÃO DO MPS.BR
BELÉM2008
UNIVERSIDADE DA AMAZÔNIACENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
CARLOS ALBERTO COSTA DE ALBUQUERQUE JÚNIOR JOÃO AMÉRICO FREITAS FONSECA SANTOS
JULIO CEZAR COSTA FURTADO
WISE: UMA ABORDAGEM DE FERRAMENTA DE SOFTWARE PARA O AUXÍLIO NO MODELO DE
AVALIAÇÃO DO MPS.BR
Trabalho Final de Graduação submetido à Banca Examinadora do Curso de Ciência da Computação da Unama para a obtenção do Grau de Bacharel em Ciência da Computação, orientado pelo Prof. Dr. Sandro Ronaldo Bezerra Oliveira.
BELÉM2008
UNIVERSIDADE DA AMAZÔNIACENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
AUTOR: CARLOS ALBERTO COSTA DE ALBUQUERQUE JÚNIOR JOÃO AMÉRICO FREITAS FONSECA SANTOSJULIO CEZAR COSTA FURTADO
WISE: UMA ABORDAGEM DE FERRAMENTA DE SOFTWARE PARA O AUXÍLIO NO MODELO DE
AVALIAÇÃO DO MPS.BR
TRABALHO FINAL DE GRADUAÇÃO SUBMETIDO À AVALIAÇÃO DA BANCA EXAMINADORA APROVADA PELO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO DA UNAMA E JULGADA ADEQUADA PARA OBTENÇÃO DO GRAU DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO.
APROVADA EM ____/_____/_____
CONCEITO ___________________
BANCA EXAMINADORA:
Prof. Dr. Sandro Ronaldo Bezerra Oliveira(ORIENTADOR – UNAMA)
Prof. (MEMBRO – UNAMA)
Prof .(MEMBRO – UNAMA)
VISTO:
Prof. Msc. Cláudio Alex Rocha(COORDENADOR DO BCC/UNAMA)
AGRADECIMENTOS
Primeiramente agradeço a Deus por ter me dado saúde, inteligência e força para
vencer as dificuldades da vida. Agradeço também ao nosso orientador, Sandro Bezerra, por
sua paciência e dedicação na criação de nossa monografia. Agradeço aos meus amigos e pais
(Francilene e Carlos Albuquerque) no incentivo dado a mim para que sempre eu me dedicasse
no estudo e desenvolvimento de nossa monografia e também pelo carinho e amizade de todos,
que estavam comigo nos momento bons e ruins, me ajudando nesses momentos.
Carlos Alberto Costa de Albuquerque Júnior
À minha mãe Aracy pelo carinho, atenção, dedicação e por todas as oportunidades que
ela me proporcionou e não mediu esforços para dar o melhor à mim. Ao meu segundo pai,
José Maria Cavalheiro de Macedo, pelo apoio e incentivo constante ao meu crescimento e
amadurecimento profissional e pessoal. Ao meu pai José Américo, por todos os momentos que
passamos juntos, que me fizeram crescer e ser uma pessoa melhor. À minha esposa Lorena
pela oportunidade de descobrir o significado da palavra paternidade.
João Américo Freitas Fonseca Santos
Gostaria de agradecer em primeiro lugar à minha mãe Delma Costa Furtado que não
mediu esforços para conquistar tudo de bom e me oferecer, sem ela nada disso teria
acontecido. Ofereço esta conquista de minha vida à ela. Ao meu orientador Prof. Dr. Sandro
Ronaldo Bezerra Oliveira, que transformou este trabalho de uma mera idéia à realidade,
corrigindo nossos pontos fracos e fornecendo o apoio intelectual para nossas dúvidas. Minha
namorada Andrelina Eudeny pelo amor, amizade e companheirismo, pela alegria e momentos
de descontração, por estar sempre ao meu lado. E à meus companheiros neste trabalho, Carlos
e João, que passaram comigo por todas as dificuldade na construção deste projeto de nossas
vidas.
Julio Cezar Costa Furtado
“A ciência de hoje é a
tecnologia de amanhã.”
Edward Teller
RESUMO
Este trabalho visa analisar o método de avaliação do modelo de qualidade MPS.BR e, com
base nestes resultados, implementar um ferramenta sistematizada que venha a facilitar a tarefa
de avaliação realizada por um avaliador credenciado, visto que há pouco esforço com este
foco. Primeiramente será descrito os conceitos e características do processos de software. Em
seguida será discutida qualidade para processos de software, descrevendo os modelos de
qualidade ISO/IEC 12207, ISO/IEC 15504, CMMI e MPS.BR. Após será descrita a WISE,
ferramenta implementada a partir dos resultados, assim como será exposto um estudo de caso
onde a ferramenta WISE foi utilizada em um processo de avaliação real do MPS.BR.
PALAVRAS-CHAVE: Processo de software, Modelo de qualidade, MPS.BR, Avaliação.
ABSTRACT
This study aims to examine the evaluation method of MPS.BR model quality and on the basis
of these results, implement a systematic tool to come to facilitating the evaluation task made
by an accredited evaluator, since it is a poor effort with this focus. First of all, it is described
the concepts and features of software processes. Then it will discuss the quality for software
processes, describing the ISO/IEC 12207, ISO/IEC 15504, CMMI and MPS.BR quality
models. Following it will be described the WISE, tool developed from the results, as it will be
explained a case study which the WISE tool was used in a real evaluation process of
MPS.BR.
KEYWORDS: Software Process, Model Quality, MPS.BR, Evaluation.
LISTA DE FIGURAS
Figura 2.1: Visão geral do meta-processo de software ....................................................... 16Figura 3.1: Processos fundamentais da ISO/IEC 12207...................................................... 22Figura 3.2: Níveis de maturidade do MPS.BR ................................................................... 28Figura 4.1: Processo de prototipação .................................................................................. 32Figura 4.2: Modelo Entidade Relacional ............................................................................ 33Figura 4.3: Diagrama de Pacotes ........................................................................................ 34Figura 4.4: Lógica de comunicação .................................................................................... 34Figura 4.5: Diagrama de Caso de Uso (Administrador) ..................................................... 40Figura 4.6: Diagrama de Caso de Uso (Avaliado) .............................................................. 41Figura 4.7: Diagrama de Caso de Uso (Avaliador) ............................................................. 42Figura 4.8: Diagrama de Atividade (Geral) ........................................................................ 43Figura 4.9: Diagrama de Atividade (Administrador) .......................................................... 44Figura 4.10: Diagrama de Atividade (Avaliado) ................................................................. 45Figura 4.11: Diagrama de Atividade (Avaliador) ................................................................ 46Figura 4.12: Menu principal Administrador ....................................................................... 47Figura 4.13: Lista de projetos ............................................................................................. 48Figura 4.14: Cadastro de projetos ....................................................................................... 48Figura 4.15: Lista de usuários ............................................................................................. 49Figura 4.16: Cadastro de usuários ....................................................................................... 49Figura 4.17: Gerência de níveis .......................................................................................... 50Figura 4.18: Lista e cadastro de instituições avaliadoras .................................................... 51Figura 4.19: Alocar esforço ................................................................................................. 52Figura 4.20: Menu principal Avaliado ................................................................................ 53Figura 4.21: Enviar artefatos ............................................................................................... 54Figura 4.22: Log de envio ................................................................................................... 54Figura 4.23: Realizar avaliação ........................................................................................... 55Figura 4.24: Realizar entrevista .......................................................................................... 56Figura 4.25: Consolidar avaliação ...................................................................................... 56Figura 4.26: Relatar resultados ........................................................................................... 57Figura 4.27: Log de eventos do servidor ............................................................................ 58
LISTA DE TABELAS
Tabela 4.1: Requisitos funcionais para a ferramenta do Administrador .............................. 35Tabela 4.2: Requisitos funcionais para a ferramenta do Avaliado ...................................... 36Tabela 4.3: Requisitos funcionais para a ferramenta do Avaliador ..................................... 36Tabela 4.4: Requisitos não funcionais da ferramenta .......................................................... 36Tabela 4.5: Tabela de Rastreabilidade ................................................................................. 37Tabela 4.6: Casos de Uso da ferramenta ............................................................................. 38Tabela 4.7: Casos de Uso da ferramenta ............................................................................. 39
SUMÁRIO
1 - INTRODUÇÃO .............................................................................................................. 111.1 - FUNDAMENTAÇÃO TEÓRICA ............................................................................ 111.2 - PROBLEMÁTICA ................................................................................................... 111.3 - JUSTIFICATIVA ...................................................................................................... 111.4 - OBJETIVOS ............................................................................................................ 121.5 - METODOLOGIA .................................................................................................... 121.6 - ESTRUTURA DO TRABALHO ............................................................................. 12
2 - PROCESSO DE SOFTWARE: UMA VISÃO GERAL .............................................. 132.1 - DEFINIÇÃO ............................................................................................................ 132.2 - CICLO DE VIDA DE PROCESSO (META-PROCESSO) ..................................... 152.3 - AVALIAÇÃO DE PROCESSO ............................................................................... 16
3 - MODELOS DE QUALIDADE PARA PROCESSO DE SOFTWARE ...................... 203.1 - QUALIDADE: VISÃO GERAL ............................................................................. 203.2 - MODELOS DE MELHORIA .................................................................................. 21
3.2.1 - ISO/IEC 12207 ............................................................................................ 213.2.2 - ISO/IEC 15504 (SPICE) ............................................................................ 233.2.3 - CMMI .......................................................................................................... 233.2.4 - MPS.BR ....................................................................................................... 24
3.2.4.1 - Modelo de Referência Para Melhoria de Processo de Software .... 254 - WISE: UM SOFTWARE PARA AUXÍLIO NA AVALIAÇÃO DO MPS.BR ........... 30
4.1 - POR QUE MPS.BR? ............................................................................................... 304.2 - METODOLOGIA DE CONCEPÇÃO DA FERRAMENTA ................................... 314.3 - CONCEPÇÃO DA WISE ........................................................................................ 32
4.3.1 - Arquitetura da WISE ................................................................................. 334.3.2 - Requisitos de Software e Hardware .......................................................... 354.3.3 - Requisitos da ferramenta ........................................................................... 35
4.3.3.1 - Requisitos funcionais para a ferramenta do Administrador ........... 354.3.3.2 - Requisitos funcionais para a ferramenta do Avaliado .................... 364.3.3.3 - Requisitos funcionais para a ferramenta do Avaliador .................. 364.3.3.4 - Requisitos não funcionais .............................................................. 364.3.3.5 - Tabela de rastreabilidade ............................................................... 374.3.3.6 - Casos de uso .................................................................................. 384.3.3.7 - Diagrama de casos de uso .............................................................. 40
4.3.4 - Fluxo ............................................................................................................ 434.3.5 - Protótipo ...................................................................................................... 47
4.3.5.1 - Administrador ................................................................................. 474.3.5.2 - Avaliado .......................................................................................... 534.3.5.3 - Avaliador ........................................................................................ 554.3.5.4 - Servidor .......................................................................................... 58
4.4 - ESTUDO DE CASO DA FERAMENTA WISE ...................................................... 595 - CONCLUSÃO ................................................................................................................. 61
5.1 - REVISÃO DO TRABALHO ................................................................................... 615.2 - REVISÃO DO PROPOSTO .................................................................................... 625.3 - TRABALHOS FUTUROS ....................................................................................... 62
5.3.1 - Promover melhorias ................................................................................... 625.3.2 - Alterar arquitetura ..................................................................................... 625.3.3 - Estender aplicação ...................................................................................... 62
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................... 63
11
1 - INTRODUÇÃO
Neste capítulo serão apresentados as motivações para o desenvolvimento desta
monografia, seus objetivos e a estrutura desta.
1.1 - FUNDAMENTAÇÃO TEÓRICA
A qualidade de um produto de software está diretamente ligada à maturidade na
execução dos processos de software de uma fábrica. Assim as fábricas de software buscam a
maturidade através da implementação de normas de qualidade em seus setores de
desenvolvimento, normas como: a ISO/IEC 12207[ISO.98] e a ISO/IEC 15504[ISO.04], os
modelos de maturidade CMMI[CMMI.06] e o modelo de qualidade MPS.BR[MPS.07]. Estes
modelos ajudam as empresas dando um guia de como deve-se fazer os processos de software,
de seu planejamento até sua entrega e manutenção junto ao cliente.
O MPS.BR é um modelo criado para a realidade das empresas brasileiras, e criado a
partir de estudo de um modelo e normas internacionais. Este modelo é dividido em sete níveis
de maturidade. Sua avaliação é feita pelos processos e a empresa escolhe em que nível e em
que setor da sua fábrica deve ser avaliado.
1.2 - PROBLEMÁTICA
No processo de avaliação de maturidade do MPS.BR (Melhoria de Processo do
Software Brasileiro), o avaliador realiza a tarefa quase que manualmente, apenas auxiliado
por editores de texto e planilha, o que gera uma perda de tempo que poderia ser melhor
aplicado no restante da tarefa de avaliação, o que pode tornar este trabalho um processo
moroso. Em função deste problema há necessidade de um trabalho de pesquisa, de tal maneira
que a mesma tarefa possa ser realizada em menos tempo, com menos custo e de forma quase
que automatizada. Há também muitas premissas e regras para a execução da avaliação que
demandam tempo de aprendizado dos executores.
1.3 - JUSTIFICATIVA
Este trabalho tratar-se-á de uma das primeiras soluções sistematizadas aplicada a tal
problemática, tendo em vista que não existe ferramenta homologada pela SOFTEX
(Associação para Promoção da Excelência do Software Brasileiro) para auxílio na avaliação
do modelo de qualidade MPS.BR. Foi eleito o MPS.BR como modelo de qualidade devido ao
12
seu menor custo de implementação e avaliação, mais acessível às empresas devido ao
incentivo do Governo Federal e por ser um modelo que é aderente às recomendações de
vários outros modelos já em uso.
1.4 - OBJETIVOS
Este trabalho tem como objetivo geral de desenvolver um sistema que auxilie os
avaliadores no processo de análise da aderência ao modelo fazendo com que os avaliadores
utilizem apenas o software específico no auxílio da avaliação.
Tendo como objetivo específicos eliminar uso de planilhas, reduzir perda e
redundância de informação, manter a segurança e integridade dos dados, definir uma
ferramenta CASE (Computer-Aided Software Engineering) para avaliação e definir formas de
avaliação mais sistêmicas.
1.5 - METODOLOGIA
Para o desenvolvimento deste trabalho foi usado como base: o entendimento do
escopo; levantamento de requisitos; implementação e correção de possíveis problemas. O
entendimento do escopo e o levantamento de requisitos ocorreram através de entrevistas com
um avaliador certificado pela SOFTEX e leitura dos guias do MPS.BR disponibilizados
livremente pela SOFTEX. A implementação foi feita em Java com arquitetura Desktop.
1.6 - ESTRUTURA DO TRABALHO
A organização da monografia foi feita da seguinte forma:
O capítulo 2, tem por objetivo explicar o que é processo de software, conceito e
definição de processo e meta-processo.
O capítulo 3, é dedicado a explicar os principais modelos de qualidade de processo de
software (CMMI, ISO 12207, ISO 15504) e o modelo de qualidade escolhido MPS.BR.
O capítulo 4, é apresentado a arquitetura do sistema proposto e justifica as escolhas
seguidas no projeto.
O capítulo 5, será realizada a conclusão do trabalho proposto, comentando os
resultados obtidos e propostas para trabalhos futuros.
Por último as referências bibliográficas com toda a base referencial de conhecimento
utilizada para realização deste trabalho.
13
2 - PROCESSO DE SOFTWARE: UMA VISÃO GERAL
Neste capítulo será dado o conhecimento necessário para o entendimento do que é
proposto neste trabalho, através da explicação do conceito básico de processo de software e
seu ciclo de vida. Irá também ser explanado os métodos de avaliação de processo.
2.1 - DEFINIÇÃO
Um processo de software é formado por um conjunto de passos de processos
parcialmente ordenados, relacionados com conjuntos de artefatos, pessoas, recursos,
estruturas organizacionais e restrições, e tem como objetivo produzir e manter os produtos de
software finais requeridos [Reis.98].
O processo de software é um conjunto de atividades que é seguido para transformar os
requisitos do usuário, em informações úteis, para que esses requisitos possam ser
transformados em um produto de software ao final do processo, ou seja, processo de software
é a seqüência em que as atividades devem ser executadas. Na definição de processo de
software deve-se levar em consideração as seguintes especificações: o conjunto de atividades
que serão realizadas; recursos utilizados; artefatos gerados e consumidos; procedimentos
adotados; paradigma e tecnologia adotados; e o modelo de ciclo de vida a ser utilizado.
Passos de processos são formados por atividades ou tarefas, onde uma atividade
produz mudanças visíveis em um produto de software. A execução das atividades pode ser
feita de maneira escalonável, onde a execução da atividade seguinte pode depender do
resultado da atividade anterior ou conjunto de atividades anteriores. Uma atividade aloca
recurso (por exemplo, máquinas e orçamento), é escalonada, monitorada, e atribuída a
desenvolvedores (agentes), que podem utilizar ferramentas para executá-la [Reis.98]. A
execução de uma atividade tem como objetivo criar ou modificar um determinado produto
(artefato).
14
Processos bem definidos ajudam na realização das tarefas da equipe envolvida no
projeto. Quanto mais definido for o processo melhor será sua execução. Sendo assim um
processo de software bem claro, ou seja, bem definido, dá condição para que as pessoas
envolvidas na equipe do projeto compreendam melhor seu trabalho e como a sua atividade se
integra com a atividade de outros membros da equipe.
Um agente está ligado às atividades de um processo e é o responsável pela execução
desta tarefa. Um agente pode ser uma pessoa ou uma ferramenta automatizada. Os agentes
podem estar distribuídos em diferentes cargos e funções para que possam ter visões diferentes
sobre o que acontece no processo de software e se distribuam pelas atividades de forma que
suas habilidades sejam escolhidas de acordo com a atividade.
Um artefato é o produto de um processo. Assim, uma atividade obtém tal produto
como resultado e este produto pode ser utilizado como artefato de entrada na realização de
mais uma atividade que irá gerar outro produto, artefato de saída. Os produtos são
freqüentemente persistentes e possuem versões [Reis.98]. Os processos são limitados pelas
restrições, onde a realização de um processo deve satisfazer tal restrição antes ou depois de
ser executado.
Um modelo de processo de software é uma representação feita com uma linguagem de
modelagem de processo de software onde são descritas as informações necessárias para
realização dos passos do processo. Este modelo de processo ao ser executado chama-se
modelo do processo instanciado ou processo executável.
Um projeto é a instância de um processo, com objetivos e restrições específicos
[Pressman.00]. Um projeto é o esforço de uma organização, que aloca recursos e tempo,
tendo como produto final a realização de um produto de software.
15
2.2 - CICLO DE VIDA DE PROCESSO (META-PROCESSO)
Um processo de software e seu modelo não devem ser estáticos após sua criação, e sim
evoluir e melhorar com o tempo para agregar as mudanças ocasionadas por situações não
contempladas à princípio. Cada processo pode ser constituído de uma ou mais atividades, que
podem ser chamadas de meta – atividades. Todo processo de software e seu modelo sofrem
constante evolução, devido a necessidade de melhoria e correções do processo e de seu
modelo. O modelo é inicialmente criado para representar um mundo real no seu estado inicial,
que durante seu tempo de vida pode sofrer modificações causadas por eventos planejados, ou
não planejados interno ou externos à organização. Estas modificações que ocorrem no modelo
que o processo está seguindo como referência e esta evolução dos processos de software são
conhecidos como meta-processo. Este meta-processo é representado por fases, que por sua
vez podem se subdividir em fases menores, aumentando, assim, o nível de detalhamento sobre
o processo.
O ciclo de vida do processo de software é dependente das entradas e saídas do que
foram estabelecidas inicialmente. Quando definimos a entrada de um processo, estamos
definindo seu início, e quando definimos as saídas deste mesmo processo estamos definindo
o final. A Figura 2.1 a seguir mostra um exemplo de meta-processo.
16
Figura 2.1: Visão geral do meta-processo de software [Reis.99b]
2.3 - AVALIAÇÃO DE PROCESSO
Segundo a norma ISO/IEC15504 [ISO 2004] e Humphrey em [Humphrey.89], avaliar
um processo de software consiste em examinar a aplicabilidade do processo em uma
determinada organização para validar se esta organização atinge as metas definidas naquele
processo cujo modelo de referência adotado especifica.
Sempre um processo de software estará ligado a um modelo de referência, ou seja, na
avaliação do processo os resultados que o modelo sugere para um determinado processo, têm
de estar compatíveis com os resultados do processo que está sendo avaliado de acordo com o
modelo adotado, assim avaliando a maturidade da organização quanto aquele processo.
Os modelos de processos de software não servem somente para especificar se o
processo avaliado está de acordo com o modelo adotado, mas também para especificar os
17
pontos fortes e fracos do processo avaliado, com isso promover uma base para um plano de
melhoria de processo de software.
Segundo Humphrey em [Humphrey.89], avaliação de processo de software não é uma
auditoria, mas uma revisão da organização de software que visa recomendar à gerência e a
seus profissionais ações de melhoria da operação.
A norma ISO/IEC 15504 [ISO/IEC 15504.04], entre outros modelos de referências
classificam as avaliações em três tipos, dependendo de quem executa o papel principal na
avaliação:
● Auto avaliação: Realizado internamente na organização, com o intuito de avaliar o
processo de software da organização, para descobrir os pontos fortes e fracos para
promover planos de melhoria de processos da organização;
● Avaliação de segunda parte: Executada por avaliadores externos, com objetivo geral
de avaliar a capacidade da organização para atender os requisitos especificados em
contrato geralmente feito pelo cliente para avaliar seu fornecedor;
● Avaliação de terceira parte: Executada por uma organização que não está ligada à
organização a ser avaliada, tem por fim avaliar se a organização possui habilidade para
desenvolver produtos de software.
Toda avaliação tem um processo de avaliação, ou seja, o processo avaliativo tem
passos que devem ser seguidos em ordens estabelecidas previamente, isso é denominado de
plano de execução.
Este plano de execução tem todos os passos a serem realizados durantes as atividades
avaliativas. O processo de avaliação que ser realizado por um avaliador capacitado, que está
sendo guiado por um plano de execução.
Uma avaliação deve conter no mínimo três etapas: a preparação da avaliação; a
18
avaliação propriamente dita;e as recomendações pós-avaliação.
A preparação para a avaliação trata de identificar a organização a ser avaliada qual, ou
quanto ela será avaliada, como será o processo avaliativo. Logo em seguida avaliar a
organização seguindo o plano de execução da avaliação. Feita a avaliação emite-se
recomendações necessárias para à organização avaliada com relatórios claros e específicos
informando os pontos fortes e fracos que a organização obteve, sugestões de melhorias para
os processos que não obtiveram êxito na avaliação , estabelecer novos marcos para melhoria
contínua dos processos.
Uma forma muito comum de avaliar processo de software, é o uso de métricas. Uma
métrica é a medição de atributo, propriedades ou características de um determinado processo.
Com métricas a organização pode avaliar a produtividade do processo, de forma
qualitativa e quantitativa para propor uma melhoria em todo o processo de desenvolvimento
de software. Com avaliações baseada em métricas a organização pode formar baseline para
montar estimativas e com isso melhorar a exatidão das estimativas.
Uma baseline é um conjunto de especificações ou produtos de trabalho que foram
formalmente revisados e sobre os quais foi feito um acordo, que serve como base para
desenvolvimento posterior e que pode ser modificado somente através dos procedimentos de
controle de mudanças. Seria uma forma de padrão oficial básico para as atividades
subseqüentes da organização.
Uma métrica deve conter as seguintes características: ela tem que quantificar o que
queremos medir; produz os mesmo resultados dadas as mesmas condições; fácil de computar
e fácil de interpretar.
As métricas podem ser divididas em dois tipos: métricas diretas e métricas indiretas.
Diretas são aquelas que estão ligadas diretamente com o processo, métricas indiretas são
19
aquelas derivadas das métricas diretas, o seja, sua criação foi devido a necessidade de uma
métrica direta.
Existem também métricas de qualidade, que oferecem quanto aquele processo está
adequado ao modelo de referência. Para caracterizar o processo como válido, ele deve está de
acordo com as métricas que o modelo estabelece para o determinado processo em questão.
20
3 - MODELOS DE QUALIDADE PARA PROCESSO DE SOFTWARE
Neste capítulo serão descritos os principais modelos de qualidade para processo de
software na atualidade, com maior ênfase no MPS.BR por ser o foco deste trabalho.
3.1 - QUALIDADE: VISÃO GERAL
Em um processo de software são muitas as atividades que afetam diretamente a
qualidade do produto. A execução ineficiente ou a não execução de algumas delas pode
acarretar na obtenção de um produto de software que não esteja alinhado com as expectativas
e requisitos dos usuários. Por esta razão, já é amplamente aceito que a qualidade do produto
seja fortemente dependente da qualidade da execução do processo que o gerou [Pfleeger.98].
“Qualidade... a gente sabe o que é, e, ao mesmo tempo, não sabe. Isso é
contraditório. Mas algumas coisas são melhores que outras, ou seja, têm mais
qualidade. Porém, se a gente tenta definir qualidade, isolando-a das outras
coisas que a possuem, então ' puf ' - já não há mais o que falar.”
Robert Pirsig em "Zen e a arte da manutenção de motocicletas"
Como a qualidade do produto se dá pela qualidade na produção do mesmo, e com o
crescimento da preocupação da qualidade de software, as empresas passaram a adotar normas
como: a ISO/IEC 12207[ISO.98] e a ISO/IEC 15504[ISO.04], e o modelos de maturidade
CMMI[CMMI.06]. Com isso, definindo processos de softwares que ajudarão a: reduzir
custos; aumentar a produtividade; reduzir os riscos de desenvolvimento; e por último e mais
importante, melhorar a qualidade do produto final.
Assim, pode-se observar que a qualidade do produto depende de vários fatores que
vão desde a escolha de um processo de software adequado à empresa que irá desenvolver o
produto até a entrega de um produto, com qualidade, ao cliente.
A ISO 8402 [ISO.94] diz que a qualidade de software se dá com “a totalidade de
características de uma entidade que lhe confere a capacidade de satisfazer às necessidades
explícitas e implícitas”.
Explícitas são as necessidades do cliente, ou seja, os requisitos que ele propôs.
Definindo o objetivo do produto, funções e desempenho esperado.
Implícitas são aquelas que não são pedidas pelo cliente, mas que são necessárias para
o desenvolvimento sem erros e com todas as suas funções, como por exemplo: quando o
21
usuário for entrar no sistema ele tenha um usuário e senha, e caso não tenha apareça uma
mensagem de erro.
3.2 - MODELOS DE MELHORIA
Para garantir a melhoria dos processos de softwares, foram criadas as normas e os
modelos de melhoria. Como se vive em um mundo em que a economia é globalizada e com o
advento dos padrões internacionais, foram adotados as seguintes normas ISO/IEC 12207 e
ISO/IEC 15504 e modelos de maturidade CMMI, e o modelo de referência
MPS.BR[MPS.07].
Estes modelos foram criados para serem guias destinadas a melhorar os processos
organizacionais e habilidades de gerenciar o desenvolvimento, aquisição e manutenção dos
produtos e serviços. Apesar de cada modelo ter uma visão própria, todos visam preparar os
envolvidos no projeto, para que melhorem e dêem mais qualidade ao produto.
3.2.1 – ISO/IEC 12207
A norma ISO/IEC 12207 foi criada pela ISO (Institute of Organization for
Standardization) e o IEC (Internetional Ectrotechnical Commission) em um esforço conjunto
dessas duas organizações. Esta norma foi proposta em 1988, com sua primeira versão sendo
publicada em agosto de 1995, mas a versão brasileira só foi publicada em 1998. Em 2002 e
2004 foram feitas atualizações na norma gerando as ementas 1 e 2 respectivamente
[Machado.06].
Tem como objetivo estabelecer um padrão para os processos de ciclo de vida de
software que possuem uma terminologia bem definida e que podem ser referenciadas pela
indústria de software. A estrutura contém processos, atividades e tarefas que servem para
serem aplicadas durante a aquisição de um sistema que contém software, de um produto de
software independente ou de um serviço de software, e durante o fornecimento,
desenvolvimento, operação e manutenção de produtos de software [ISO.98].
Esta norma fornece uma arquitetura para o ciclo de vida do projeto, de forma a ser
aplicada em todo o ciclo de vida do início ao fim, e com isso engloba todos os envolvidos na
produção do software. Existem casos em que esta norma é aplicada apenas nas fases iniciais
do processo, mas isso só se faz necessário quando o contratando deixa explícito no contrato.
Esta norma foi adaptada pelos Estados Unidos como a norma IEEE/EIA 12207 e é
22
considerada base, a nível organizacional, dos projetos de softwares de diversos setores de
atividades, quer sejam clientes internos ou internacionais.
Os processos desta norma são agrupados de acordo com seu objetivo. Este
agrupamento resultou em três classes fundamentais, como mostra a Figura 3.1:
• Processos primários: são os processos necessários para dar a início ao ciclo
de vida do software, tais como: Aquisição, Fornecimento, Desenvolvimento,
Operação e Manutenção.
• Processos de suporte: como o próprio nome já diz, este dá suporte a outros
processos para que estes sejam desenvolvidos de forma mais organizada, são
estes: Documentação, Gestão de Configuração, Garantia de Qualidade,
Verificação, Validação, Revisões Conjuntas, Auditoria e Usabilidade, Gerência
de Resolução de Problemas, Gerência de Solicitação de Mudanças e Avaliação
do Produto.
• Processos organizacionais: são processos empregados para estabelecer ou
implementar uma estrutura subjacente feita a partir de processos associados,
como pessoas e melhoramento. Fazem parte desse grupo: Gestão de Ativos,
Infra-estrutura, Gerência, Engenharia de Domínio, Gestão de Programa de
Reuso e Recursos Humanos.
Figura 3.1: Processos fundamentais da ISO/IEC 12207
23
3.2.2 - ISO/IEC 15504(SPICE)Devido às organizações mundiais estarem muito dependentes dos sistemas de
informática ou de softwares para fazer suas atividades de forma mais rápida e mais
automatizada, e com o crescimento da quantidade de softwares que não atendem as
expectativas dos usuários, foi criado o projeto SPICE (Software Process Improvement and
Capability Determination) que suas origens bem próximas do SPA (Software Process
Assessment). As falhas em produtos de software vêm sendo uma das principais fontes de
gastos nas organizações [ISO.98].
Outro motivo do surgimento desta norma foram às iniciativas dos governos dos
Estados Unidos e da Inglaterra, nos anos 80, para reduzir os custo com software, melhorar a
seleção de seus fornecedores de softwares, reduzir os riscos associados aos projetos de
software e melhorar a qualidade do produto final. No início dos anos 90 vários métodos para
melhoria dos processos e determinação de capacitação tiveram início em diversos países.
Dentre os métodos criados os que mais se destacam são: CMM[Paulk.95], BOOTSTRAP
[Zahran.98], e como todos procuravam identificar as fraquezas e os riscos, haveria de existir
um consenso internacional para avaliação do processo de software, pela facilidade de se
trabalhar e pela possibilidade de se comparar os resultados.
Este modelo pode ser aplicado quando se deseja melhorar suas capacidades em:
planejar, gerenciar, monitorar, controlar e melhorar aquisição, fornecimento,
desenvolvimento, operação, evolução e suporte de software.
3.2.3 - CMMI
O propósito do CMMI (Capability Maturity Model Integration) é fornecer guias para
o aperfeiçoamento de processos e para o gerenciamento do desenvolvimento, aquisição, e
manutenção de produtos e serviços [CMMI.06].
O CMMI é um modelo baseado em maturidade e pode ser aplicado em muitas das
empresas que têm como seu foco a área de informática.
O CMMI contém duas visões: contínua e estágio. A contínua possui uma abordagem
mais flexível para melhoria do processo, com seu foco em áreas de processo específicas,
diretamente relacionadas ao objetivo de negócio da organização, sendo esta similar à ISO/IEC
15504. E a visão em estágios um passo a passo contendo os detalhes de como prover a
melhoria do processo, descrevendo sobre os níveis de maturidade, que é um grupo de
seqüência de execução das áreas de processo, e quando esse nível de maturidade é alcançado
24
indica uma pequena melhoria do processo, e esta é similar a SW-CMM (Capability Maturity
Model for software).
3.2.4 - MPS.BR
Teve seu início em dezembro de 2003 quando sete renomadas instituições brasileiras,
que têm em sua área de atuação a melhoria de processos de software em empresas,
participaram do projeto de Melhoria do Processo de Software Brasileiro (MPS.BR): a
Sociedade SOFTEX, coordenadora do projeto; três instituições de ensino e pesquisa e centros
tecnológicos (COPPE/UFRJ, CESAR, CenPRA); uma sociedade de economia mista, a
Companhia de Informática do Paraná (CELEPAR), hospedeira do Subcomitê de Software da
Associação Brasileira de Normas Técnicas (ABNT); duas organizações não-governamentais
integrantes do Programa SOFTEX (Sociedade Núcleo de Apoio à produção e Exportação de
Software do Rio de Janeiro – RIOSOFT e Sociedade Núcleo SOFTEX 2000 de Campinas).
Desde o início do projeto, a COPPE/UFRJ convidou a Universidade Católica de Brasília
(UCB) para ser sua parceira no projeto, que assim se uniu ao grupo.
Este modelo tem como intuito fazer com que micro, pequenas e médias empresas,
principalmente, melhorem seu processo de software. É focado nessas empresas, por ter um
custo bem acessível e por ter incentivos monetários de órgãos governamentais. Seu objetivo
principal é definir e implementar o Modelo de Referência para melhoria de processo de
software (MR MPS) em empresas. E os objetivos secundários, disseminar em diversos locais
no país: a capacitação no uso do modelo (cursos de Introdução ao MR MPS e cursos e provas
para Consultores de Implementação e Avaliação do modelo); o credenciamento de instituições
implementadoras e/ou avaliadoras do modelo, especialmente instituições de ensino e centros
tecnológicos; a implementação e avaliação do modelo com foco em grupos de empresas.
Em modelos como CMMI, o custo de implementação e avaliação é muito alto, mesmo
que em seus níveis mais baixos, como 2 e 3, o que faz com que fique inviável para micro e
pequenas empresas, especialmente no Brasil, tenham um poder aquisitivo muito baixo. E
como solução para este problema foram criados o Modelo de Referência para melhoria do
processo de software (MR MPS) e o Modelo de Negócio para melhoria do processo de
software (MN MPS).
A partir das experiências que algumas instituições e alguns Agentes SOFTEX tiveram,
com a implementação e certificação ISO 9000 [ISO.91] e implementação e avaliação CMM e
25
CMMI, foram criados um modelo de negócios para o projeto MPS.BR que prevê duas
situações:
- MNE (Modelo de Negócio Específico) que se dá de forma personalizado para uma
empresa;
- MNC (Modelo de Negócio Cooperado) mais acessível para micro, pequenas e
médias empresas, por dividir proporcionalmente parte dos custos entre as empresas e por se
buscar outras fontes de financiamento.
A implementação e avaliação do MR MPS só podem ser feitas a partir de instituições
credenciadas. Este credenciamento é feito pelo Fórum de Credenciamento e Controle (FCC)
do projeto. Quando a empresa é credenciada, a Sociedade SOFTEX assina um convênio com
as instituições credenciadas.
Quando se tem Modelo de Negócio Específico as empresas, uma a uma, que querem
se qualificar no MPS.BR, negocia a implementação, e assina um contrato junto à Instituição
Credenciada para Implementação (ICI) do MR MPS, e para avaliação faz o mesmo processo
com a Instituição Credenciada para Avaliação (ICA). E a coordenadora do projeto MPS.BR
(Sociedade SOFTEX) só toma conhecimento, a partir das ICI ou ICA, do contrato e dos
resultados gerados pelas duas empresas, de implementação e de avaliação.
No Modelo de Negócio Cooperado as empresas formam um grupo com as empresas
interessadas na implementação do MR. Este grupo pode começar a partir de um agente
SOFTEX. E o resto acontece da mesma forma que o anterior, com a diferença apenas que
quem faz a negociação e assina os contratos é a coordenação do grupo.
3.2.4.1. Modelo de Referência Para Melhoria de Processo de Software
O projeto MPS.BR não tem finalidade de criar um novo modelo, com novas Normas
ou novos Modelos de Maturidade. O que este projeto traz de novo é: a estratégia adotada para
sua implementação, que teve como base para sua criação a realidade brasileira; e o Modelo de
Negócio, que tem grande potencial de uso em países com as mesmas características do Brasil,
como por exemplo os países latino-americanos.
A definição do MR teve como início análise da norma ISO/IEC 12207, a norma
ISO/IEC 15504 e o modelo CMMI (Capability Maturity Model Integration).
A norma de referência para os processos de ciclo de vida de software no MR MPS é a
ISO/IEC 12207 conforme atualização publicada em 2002 [Weber.04]. Nesta norma existe a
26
definição dos processos organizacionais, por ela definir bem a arquitetura, terminologia e
responsabilidade inerente a processos. Com a atualização foram acrescentados: processos e
sua descrição de propósito e resultados de implementação, o que possibilita a avaliação da
capacidade do processo. Esta norma é composta destes seguintes itens:
Processos fundamentais: atendem ao início, à contratação entre o adquirente e o
fornecedor e a execução do Desenvolvimento, da Operação ou Manutenção de
produtos de software durante o ciclo de vida do software [Machado.01]. E também
fazem parte dos processos fundamentais os processos de Aquisição e Fornecimento;
Processos de apoio: auxiliam e contribuem para o sucesso e a qualidade do projeto de
software, como estes: Documentação, Gerência de Configuração, Garantia da
Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria, Resolução de
Problemas e Usabilidade;
Processos Organizacionais: responsável por estabelecer e implementar uma estrutura
constituída pelos processos de ciclo de vida e pelo pessoal envolvido no projeto de
software. Eles são geralmente empregados fora do domínio de projeto e contratos
específicos; entretanto, os ensinamentos desses projetos e contratos contribuem para a
melhoria da organização, são eles: Processos de Gerência, Infra-estrutura, Melhoria, e
Treinamento [Machado.01]. E também fazem parte desses processos os Recursos
Humanos, Gestão de Ativos, Gestão de Programa de Reuso e Engenharia de Domínio.
A maturidade do MPS de acordo o MR é dividido em duas dimensões:
Dimensão de capacidade: (capability dimension) são os diversos atributos de um
processo que têm a finalidade de medir o grau de institucionalização e refinamento de
um processo na organização, e uma maior capacidade de desempenhar um projeto é
atingido quando se evolui nos níveis;
Dimensão de processo: (process dimension) é baseada na norma ISO/IEC 12207 e
estabelece o que deveria ser feito para se ter qualidade na produção, fornecimento,
aquisição e operação de software.
Existem sete níveis, são eles, como mostra a Figura 3.2: nível G – Parcialmente
Gerenciado, composto pelos processo: Gerência de Projeto e Gerência de Requisitos; nível F
– Gerenciado, composto pelos processos no nível anterior e dos processos: Aquisição,
Gerência de Configuração, Garantia de Qualidade e Medição; nível E – Parcialmente
Definido, composto pelos processos dos níveis anteriores acrescidos de: Avaliação e Melhoria
27
do Processo Organizacional, Definição do Processo Organizacional, Gerência de Recursos
Humanos, Gerência de Reutilização e Gerência de Projetos; nível D – Largamente Definido,
composto dos processos dos níveis anteriores acrescido dos processos Desenvolvimento de
Requisitos, Integração do Produto, Validação, Verificação e Projeto e Construção do Produto;
nível C – Definido, composto dos processos dos níveis anteriores acrescido dos processos
Análise de Decisão e Resolução, Desenvolvimento para Reutilização, Gerência de Risco e
Gerência de Reutilização; nível B – Gerenciado Quantitativamente, composto pelos processos
dos níveis anteriores, sendo que o processo Gerência de Projeto teve novos resultados a serem
acrescentados; nível A – Em Otimização, composto pelos processo dos níveis anteriores
acrescido do processo de Análise de Causa de Problemas e Resolução.
28
Figura 3.2: Níveis de maturidade do MPS.BR
O método de avaliação teve como base a norma ISO/IEC 15504, e é realizada
considerando que cada nível suas áreas de processo e que a cada avaliação dos níveis acima,
os que estão abaixo serão avaliados novamente.
O processo de avaliação é feito a partir de indicadores, onde estes irão medir o nível
de implementação das práticas relacionadas a cada área de processo, estes são definidos pela
empresa para cada uma das práticas, e podem ser divididos em três tipos: Direto, Indireto ou
29
Afirmação. Indicadores Diretos são produtos intermediários, resultados de uma atividade.
Indicadores Indiretos são, na maioria das vezes, documentos que indicam que uma atividade
foi realizada. Afirmações são os resultados das entrevistas que os entrevistados relatam como
uma prática foi implementada. O nível de implementação de uma prática é avaliado de acordo
com quatro níveis: TI – Totalmente Implementado; LI – Largamente Implementado; PI –
Parcialmente Implementado, e, NI – Não Implementado. Esta escala deve ser entendida como
uma porcentagem que representa o grau de alcance de completude de cada artefato. Mas o
resultado final é dado pela equipe de avaliação, considerando os resultados da avaliação nos
projetos avaliados.
Para que uma empresa seja considerada de um nível A, B, C, D, E, F ou G todas as
áreas da empresa devem ter sido avaliadas naquele nível. Uma empresa pode requerer
avaliação de apenas um ou algum dos seu setores. É possível que em uma avaliação parte da
empresa alcance um nível e outra parte alcance outro nível diferente. Mas de qualquer forma,
será emitido um documento que explicará o objetivo da avaliação e o nível de maturidade
resultante.
Como pré-requisitos da avaliação, tem-se todos os projetos concluídos e todos os que
estão em andamento. No momento do planejamento da avaliação, a Instituição avaliadora
deve escolher um subconjunto de projetos que garanta a representatividade da organização a
ser avaliada, e este número de projetos não pode ser inferior a dois. Existem algumas
empresas que desenvolvem apenas um produto, porém isso não impede que esta faça a
avaliação, pois projetos são entendidos de sentido bem amplo, como por exemplo projetos de
manutenção do produto. A avaliação tem validade de dois anos.
30
4 - WISE: UM SOFTWARE PARA AUXÍLIO NA AVALIAÇÃO DO MPS.BR
Neste capítulo será dito quais motivos da escolha pelo MPS.BR como modelo base
para o estudo deste trabalho e desenvolvimento do sistema. Também serão exibidas
características da ferramenta, tais como: metodologia de concepção e desenvolvimento da
ferramenta.
4.1 - POR QUE MPS.BR?
Foi optado por este modelo por ser um modelo nacional, que foi criado pensando nas
características do mercado brasileiro de desenvolvimento software. O modelo é bem aceito
internacionalmente, sendo aderente ao modelo CMMI, então quando se implementar, por
exemplo os níveis G e F, o nível 2 do CMMI está sendo contemplado porém a partir de um
procedimento de implementação menos moroso, já que o MPS.BR está divido em mais níveis
de maturidade que os outros modelos, facilitando assim a adequação da empresa e diminuindo
os custos daquela implementação/avaliação, sem um grande custo para a empresa. É também
aderente às normas ISO/IEC 12207 e ISO/IEC 15504.
Outro ponto forte para sua escolha é que este modelo tem grandes chances de
ascensão, por ter incentivos financeiros, fazendo com que as empresas de médio e pequeno
porte tenham a possibilidade de serem qualificadas no MPS.BR e ter um selo de qualidade
que comprove a maturidade dos seus processos e a capacidade em se desenvolver produtos de
software seguindo tais processo, podendo assim, fornecer seus produtos com mais facilidade e
para consumidores de maior nome. Estes incentivos não ficam restritos apenas a empresas de
pequeno e médio porte, mas também a empresa de grande porte que estejam interessadas à
investirem na qualidade de seus produtos. Principalmente para as empresas que buscam
software com qualidade e que querem algo que possa garantir a qualidade daquele produto.
O modelo MPS.BR conta com o apoio do Ministério da Ciência e Tecnologia (MCT),
da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de
Desenvolvimento (BID). Entidades responsáveis pelos incentivos financeiros aos interessados
na implantação do modelo na sua instituição. O MPS.BR também vem conquistando já um
reconhecimento internacional como modelo de qualidade a se fixar, já que muitas empresas
na América Latina também têm demostrado interesse no modelo brasileiro de qualidade.
31
4.2 - METODOLOGIA DE CONCEPÇÃO DA FERRAMENTA
A ferramenta WISE foi desenvolvida para atender as necessidades dos stakeholders do
processo avaliativo do modelo MPS.BR.
O WISE é uma ferramenta para ajudar neste processo tanto para os avaliados quanto
para os avaliadores envolvidos neste processo. A metodologia utilizada para o
desenvolvimento da ferramenta foi divido em 3 (três) etapas. A primeira etapa foi uma
entrevista com o Avaliador Líder, certificado pela SOFTEX, para que ele provesse todo o
ciclo em que o processo de avaliação é definido. Nas entrevistas com o Avaliador, em um
primeiro momento foi descrito o processo como um todo para que pudesse ser verificada os
requisitos básicos que a ferramenta deveria contemplar. Posteriormente foi feito o estudo dos
guias do MPS.BR que estão disponíveis no site da SOFTEX (http://www.softex.br/mpsbr).
O primeiro guia a ser consultado para a elaboração da ferramenta foi o Guia Geral que
contém uma descrição geral do modelo MPS.BR e explica o modelo de referência. A segunda
etapa foi o Guia de Avaliação, onde explica como será a avaliação do nível que está sendo
solicitado os critérios da avaliação, os requisitos para a avaliação ser feita.
O processo de desenvolvimento da ferramenta foi feito através de prototipação
evolutiva, ou seja, um protótipo inicial produzido após a validação inicial, onde irão sendo
adicionado novas funcionalidades ao protótipo minimizando assim a possibilidade de erros no
desenvolvimento do projeto, pois os usuários da ferramenta estão em contato constante com
ela, podendo mostrar os pontos em que a ferramenta não atende as necessidades dos usuários,
ou algum requisito que não foi contemplado nos protótipos ou mesmo no levantamento dos
requisitos iniciais, quando ainda não se tem um protótipo desenvolvido. A prototipação
evolutiva tinha um ciclo pré-definido pelos os stakeholders, haviam marcos a ser seguidos,
com reuniões para avaliar o protótipo que estava sendo exposto, levantando os pontos fracos e
fortes da ferramenta, melhorias que deveriam ocorrer ou novos requisitos que surgiram
durante o processo de desenvolvimento da ferramenta. Todas as reuniões eram acompanhadas
por um avaliador do modelo de referência MPS.BR credenciado, que validava a ferramenta e
acrescentava novos requisitos.
A Figura 4.1 abaixo demostra como é o processo de prototipação:
32
Figura 4.1: Processo de prototipação
Esta metodologia de prototipação foi usada durante toda e fase de desenvolvimento da
ferramenta, e análise dos requisitos. Sendo que os requisitos eram analisados de acordo com
as validações efetivadas, ou seja, a cada validação era apresentado um novo requisito ou uma
melhora em algum já existente.
4.3 - CONCEPÇÃO DA WISE
Foi definido que a ferramenta WISE teria três perfis de acesso: o perfil administrador,
que seria utilizado apenas pela SOFTEX, onde seria responsável pela gerência do sistema; o
perfil avaliado, que seria utilizado pelas entidades que se candidatassem à uma avaliação de
nível de maturidade do MPS.BR; e o perfil avaliador, que seria o perfil utilizado pelos
avaliadores credenciados pela SOFTEX para realizar a avaliação. Estes foram divididos em
mesma quantidade de módulos funcionais. Cada um com seu devido perfil e seus atributos. E
além dos perfis existe um servidor que fica ativo pra envio e recepção de dados dos
avaliadores e avaliados.
33
4.3.1 - Arquitetura da WISE
A seguir serão discutidos alguns modelos de projeto usados como base para a
definição da arquitetura.
A arquitetura da ferramenta WISE divide-se em três camadas, sendo estas: Interface
Gráfica - GUI (Graphic User Interface), Negócio e Banco de Dados. Será mostrado na
Figura 4.2 o MER (Modelo Entidade Relacional);
Figura 4.2: Modelo Entidade Relacional
34
A Figura 4.3 representa o diagrama de Pacotes da UML para a Ferramenta.
Figura 4.3: Diagrama de Pacotes
A Figura 4.4 exibe a lógica de comunicação entre os clientes e a base de dados.
Figura 4.4: Lógica de comunicação
35
4.3.2 - Requisitos de Software e Hardware
O sistema deve ser executado sobre a plataforma Windows com a máquina virtual Java
na versão 1.6 (JRE 1.6) instalada, e por este motivo, o hardware deve atingir os requisitos
recomendados para a execução da plataforma Windows e da máquina virtual Java.
Há também a necessidade de uma conexão com a Internet em banda-larga nos
momentos em o cliente for sincronizar seus dados com o servidor, sincronização esta que será
explicada mais a frente.
4.3.3 - Requisitos da ferramenta
As seções a seguir retratam os requisitos levantados para o desenvolvimento da
ferramente WISE.
4.3.3.1 - Requisitos funcionais para a ferramenta do Administrador
Tabela 4.1: Requisitos funcionais para a ferramenta do Administrador R1 O administrador deve poder cadastrar projetos;R2 O administrador deve poder alterar projetos;R3 O administrador deve poder excluir projetos;R4 O administrador deve poder cadastrar usuários;R5 O administrador deve poder alterar usuários;R6 O administrador deve poder excluir usuários;R7 O administrador deve poder cadastrar níveis;R8 O administrador deve poder alterar níveis;R9 O administrador deve poder excluir níveis;R10 O administrador deve poder cadastrar instituições avaliadoras;R11 O administrador deve poder alterar instituições avaliadoras;R12 O administrador deve poder excluir instituições avaliadoras;R13 O administrador deve poder gerenciar esforço, podendo atribuí-lo ou modificá-lo;
R14 O administrador deve poder gerenciar cronograma, podendo atribuí-lo ou modificá-lo.
R23 Os usuários devem fazer login.
36
4.3.3.2 - Requisitos funcionais para a ferramenta do Avaliado
Tabela 4.2: Requisitos funcionais para a ferramenta do Avaliado
R15 O avaliado deve poder receber os dados, com as informações necessárias de seu projeto;
R16 O avaliado deve poder preencher planilha de artefatos, com as informações necessárias para que a avaliação seja feita;
R17 O avaliado deve poder enviar dados, como, sua planilha preenchida e os artefatos que a compõem;
R23 Os usuários devem fazer login.
4.3.3.3 - Requisitos funcionais para a ferramenta do Avaliador
Tabela 4.3: Requisitos funcionais para a ferramenta do Avaliador
R18 O avaliador deve poder receber os dados, com as informações necessárias do projeto a ser avaliado;
R19 O avaliador deve poder analisar a planilha;R20 O avaliador deve poder analisar resultados da planilha;R21 O avaliador deve poder relatar os resultados;
R22 O avaliador deve poder fazer a entrevista guardando as conversar para analise posterior;
R23 Os usuários devem fazer login.
4.3.3.4 - Requisitos não funcionais
Tabela 4.4: Requisitos não funcionais da ferramentaRNF1 Deve ser criada sala para conversar na entrevista;RNF2 Deve ser dada nota nas análises de planilha e de resultados;RNF3 Fazer atualização recebendo ou enviando dados.
37
4.3.3.5 - Tabela de rastreabilidade
A seguir a tabela representa a rastreabilidade tida como premissa para o gerenciamento
de requisitos:
Tabela 4.5: Tabela de RastreabilidadeRequisitos não
funcionaisRequisitos não
funcionaisRequisitos não
funcionaisRequisitos funcionais RNF1 RNF2 RNF3
R1R2R3R4R5R6R7R7R8R9R10R11R12R13R14R15R16R17 XR18 XR19 XR20 XR21R22 XR23
38
4.3.3.6 - Casos de uso
A partir dos requisitos levantados os seguintes casos de uso foram especificados:
Tabela 4.6: Casos de Uso da ferramentaCasos de Uso Ator Objetivo Descrição
Cadastrar Projetos
Administrador Inserir projeto no banco de dados
O administrador informa todos os dados do projeto para que o mesmo seja guardado no sistema.
Alterar Projetos Administrador Alterar projeto no banco de dados
O administrador informa todos os dados do projeto para que o mesmo seja alterado no sistema.
Excluir Projetos Administrador Excluir projeto no banco de dados
O administrador exclui o projeto selecionando o mesmo.
Listar Projetos Sistema Exibir projetos cadastrados
O sistema exibi todos os projeto previamente cadastrados.
Cadastrar Usuários
Administrador Inserir usuário no banco de dados
O administrador informa todos os dados do usuário para que o mesmo seja guardado no sistema.
Alterar Usuários Administrador Alterar usuário no banco de dados
O administrador informa todos os dados do usuário para que o mesmo seja alterado no sistema.
Excluir Usuários Administrador Excluir usuário no banco de dados
O administrador exclui o usuário selecionando o mesmo.
Listar Usuários Sistema Exibir usuário cadastrados
O sistema exibi todos os usuário previamente cadastrados.
Cadastrar Instituição Avaliadora
Administrador Inserir instituição avaliadora no banco de dados
O administrador informa todos os dados do instituição avaliadora para que o mesmo seja guardado no sistema.
Alterar Instituição Avaliadora
Administrador Alterar instituição avaliadora no banco de dados
O administrador informa todos os dados do instituição avaliadora para que o mesmo seja alterado no sistema.
Excluir Instituição Avaliadora
Administrador Excluir instituição avaliadora no banco de dados
O administrador exclui o instituição avaliadora selecionando o mesmo.
Listar Instituição Avaliadora
Sistema Exibir instituição avaliadora cadastrados
O sistema exibi todos os instituição avaliadora previamente cadastrados.
Gerenciar Esforço
Administrador Manipular informações sobre esforço
Inserir e modificar informações do esforço.
Gerenciar Cronograma
Administrador Manipular informações sobre cronograma
Inserir e modificar informações do cronograma.
39
Tabela 4.7: Casos de Uso da ferramentaCasos de Uso Ator Objetivo Descrição
Fazer Login Administrador, Avaliador e Avaliado
Entrar em partes restritas nos sistema
Entrar e obter informações restritas por usuário.
Enviar Dados Avaliado Atualizar dados no servidor
Manda dados das tabelas preenchidas.
Preencher Planilha de Artefatos
Avaliado Inserir dados do projeto
Insere dados necessários para avaliação.
Receber dados Avaliado e Avaliador
Receber informações
Recebe informações necessárias para preenchimento de tabela do avaliado ou do avaliador para avaliação.
Registrar Entrevista
Avaliador Guardar conversas
Registra conversas para posterior análise.
Relatar Resultados
Avaliador Fornece resultados
Dizer os pontos fortes, fracos e oportunidades de melhoria.
Analisar Planilha Avaliador Dar nota a cada evidência da planilha
Dá nota a cada evidência, atribuindo uma cor pra cada evidência.
Analisar Resultados
Avaliador Analisar Resultados
Analisa resultados gerados pelas evidências para poder dar nota por processo.
40
4.3.3.7 - Diagrama de casos de uso
Para um melhor entendimento dos casos de uso, estes foram divididos em três
diagramas, são eles:
Administrador que representa as funcionalidades do programa no perfil do
administrador, representado pela Figura 4.5;
Figura 4.5: Diagrama de Casos de Uso (Administrador)
41
Avaliado: que representa as funcionalidades do programa no perfil do avaliado,
representado pela Figura 4.6;
Figura 4.5: Diagrama de Casos de Uso (Avaliado)
42
Avaliador: que representa a funcionalidade do programa no perfil do avaliador,
representado pela Figura 4.7.
Figura 4.7: Diagrama de Casos de Uso (Avaliador)
43
4.3.4 - Fluxo
Para um entendimento das atividades da ferramenta, foram definidos alguns diagramas
de atividades da UML, estes diagramas, assim como os casos de uso, serão divididos em três
perfis. Cada um com suas características específicas. E mais um fluxo geral, para mostrar a
seqüência que o programa deve seguir, mostrado na Figura 4.8.
Os diagramas são: administrador, mostrado na Figura 4.9; avaliado, mostrado na
Figura 4.10 e avaliador, mostrado na Figura 4.11.
Figura 4.8: Diagrama de Atividade (Geral)
44
Figura 4.9: Diagrama de Atividade (Administrador)
45
Figura 4.10: Diagrama de Atividade (Avaliado)
46
Figura 4.11: Diagrama de Atividade (Avaliador)
47
4.3.5 - Protótipo
Nesta seção serão discutidas as interfaces gráficas projetadas para o protótipo da
ferramenta WISE, com o intuito de representar as funcionalidades de execução da ferramenta.
4.3.5.1 - Administrador
A tela representada da Figura 4.12 mostra o menu principal do perfil do
Administrador, onde o usuário poderá escolher entre manipular os dados de projeto, usuário,
nível, instituições avaliadoras e alocar esforço.
Figura 4.12: Menu principal Administrador
Na tela representada pela Figura 4.13 serão mostrados todos os projetos cadastrados,
podendo-se cadastrar novos projetos inserindo as informações do projeto e da empresa a ser
avaliada. mostrado na Figura 4.14, possibilitando cadastrar novos projetos, alterar e excluir
projetos já cadastrados.
48
Figura 4.13: Lista de projetos
Figura 4.14: Cadastro de projetos
49
Figura 4.15: Lista de usuários
Figura 4.16: Cadastro de usuários
50
Na tela representada pela Figura 4.15 serão mostrados todos os usuários cadastrados,
podendo-se cadastrar novos usuários com informações, como, senha, perfil, id e nome,
mostrado na Figura 4.16, possibilitando cadastrar novos usuários, alterar e excluir usuários já
cadastrados.
Na tela representada pela Figura 4.17 serão mostrados todos os níveis cadastrados,
podendo-se cadastrar novos níveis inserindo informações sobre os níveis e as informações
contidas neles tendo como base o modelo MPS.BR, além de alterar e excluir níveis já
cadastrados. A ferramenta tem suas informações atualizadas quando o modelo for atualizado.
Nesta tela como na anterior apenas o administrador terá acesso.
Figura 4.17: Gerência níveis
51
Na tela representada pela Figura 4.18 serão mostrados todos as instituições
avaliadoras cadastrados, podendo-se cadastrar novas instituições necessitando apenas do
nome e o CNPJ da mesma, além de alterar e excluir as instituições avaliadoras já cadastrados.
Figura 4.18: Lista e cadastro de instituições avaliadoras
52
Na tela representada pela Figura 4.19 serão cadastrados e alterados os esforços a
serem alocados a cada projeto, atribuindo os avaliadores, disponíveis na instituição avaliadora
atribuída anteriormente, ao projeto escolhido, e nessa tela o administrador também fará o
organograma da avaliação, atribuindo um tempo pra cada tarefa que cada avaliador terá que
fazer.
Figura 4.19: Alocar esforço
53
4.3.5.2 - Avaliado
A tela representada pela Figura 4.20 mostra o menu principal do perfil do Avaliado,
onde será preenchida uma tabela, mostrada na Figura 4.21, com as informações necessárias
para a avaliação da empresa, tais como: evidência, fonte e o arquivo atribuído a cada
evidência, onde cada evidência está relacionada com pelo menos um projeto.
Figura 4.20: Menu principal Avaliado
A tela representada na Figura 4.22 mostra o envio dos dados preenchidos pela
empresa avaliada ao servidor, atualizando as informações para que posteriormente possa ser
enviada aos avaliadores.
54
Figura 4.21: Enviar artefatos
Figura 4.22: Log de envio
55
4.3.5.3 - Avaliador
A tela representada na Figura 4.23 mostra o foco principal do perfil do Avaliador,
onde serão avaliados as evidências enviadas pela empresa avaliada, atribuindo uma cor que
será a nota de cada evidência que posteriormente será feita a análise para a nota final.
Figura 4.23: Realizar avaliação
A tela representada na Figura 4.24 mostra onde será feita a entrevista com os
funcionários da empresa guardando as conversas para que possam ser analisadas.
A tela representada na Figura 4.25 mostra onde será feita a avaliação por processos e
o avaliador poderá atribuir a nota não mais evidência por evidência e sim pelo processo
tirando um média das notas das evidências.
56
Figura 4.24: Realizar entrevista
Figura 4.25: Consolidar avaliação
57
A tela representada na Figura 4.26 onde serão relatados os resultados finais da
avaliação com informações dos pontos onde a empresa atende ao esperado e onde pode ser
melhorado.
Figura 4.26: Relatar resultados
58
4.3.5.4 - Servidor
A tela representada na Figura 4.27 mostra o log com todos os clientes que se
conectaram, o que eles requisitaram ao servidor e se o mesmo enviou algum arquivo.
Possibilitando uma auditoria às atividades realizadas.
Figura 4.27: Log de eventos do servidor
59
4.4 - ESTUDO DE CASO DA FERAMENTA WISE
Como forma de avaliar a sistematização em uma ferramenta de software o modelo de
avaliação proposto pelo MPS.BR, as regras e ativos promovidos por este modelo inicialmente
foram instanciados na visão de Administração da WISE. Assim foram inseridos níveis de
maturidade e seus resultados esperados, bem como os níveis de capacidade e os atributos de
processo.
Com base nisso, foi usado a visão do Avaliado para compor o preenchimento das
evidências que caracterizam a base para o procedimento Avaliativo. Este trabalho foi
realizado pelo próprio Avaliador já que a ferramenta não foi disponibilizada em tempo hábil à
unidade organizacional que teve seus processos avaliados. Em se falar desta unidade, a
mesma trata-se de uma fábrica de software situada em Curitiba - PR, com foco no
desenvolvimento de produtos de software para a área de varejo, tendo em sua estrutura
equipes formadas por 56 (cinqüenta e seis) recursos humanos, caracterizando-se como uma
empresa de médio porte dado seus clientes em potencial: Pão de Açúcar, WallMart, Carrefour,
Casas Bahia, entre outros.
A avaliação decorria na análise das evidências do nível G do MPS.BR, tida como uma
das mais complexos por implementadores e avaliadores do MPS.BR, dada a imaturidade da
organização[MPS.07]. O avaliador que fez uso da ferramenta caracteriza-se como Avaliador
Líder autorizado pela SOFTEX, pertence à Instituição Avaliadora SWQuality.
Após a realização de todo o procedimento avaliativo, usando a WISE como base, o
avaliador conseguiu os seguintes pontos fortes:
● Atende a todo o processo descrito no modelo de avaliação MA-MPS, sistematizando
em todos os casos regras tidas como complexas na realização desta avaliação;
● Organiza em diferentes visões os serviços promovidos pelo modelo MA-MPS, o que
facilita em entendimento das tarefas de forma automatizada;
● Redução do tempo dispendido nas análises das evidências, realização das entrevistas e
caracterização do conceito final na avaliação;
● Sincronização adequada dos dados entre as visões do Avaliado e Avaliador, garantindo
segurança e confiabilidade das informações geradas.
60
Porém algumas melhorias também foram detectados para aperfeiçoar a operação dos
serviços providos:
● Organizar mais claramente os componentes da interface gráfica garantindo maior
intuitividade no processo avaliativo;
● Prover um serviço de impressão de todas as informações geradas com foco em
comprovações;
● A ferramenta hoje dá suporte para uso até o nível F, pois nos demais níveis a mesma
apresentou um erro na composição da planilha para visualização de todos os ativos;
● Prover um serviço de remoção de todas as informações geradas ao final da avaliação
para cumprir um requisito de confidencialidade promovido pela SOFTEX;
● Sincroniza os resultados da avaliação para o repositório da SOFTEX a fim de
possibilitar auditoria nas informações geradas;
● Caracterizar melhor as cores usadas no processo de avaliação de acordo com o usado
manualmente e possibilitar que a interface gráfica possa ser maximizada garantindo
melhor visibilidade aos avaliadores.
No mais, o Avaliador acredita que a WISE está preparada para possibilitar avaliações
usando o modelo MA-MPS.
61
5 - CONCLUSÃO
Neste capítulo será explanado as informações conclusivas da monografia. Tais como:
construção do sistema, informações sobre a utilização e trabalhos futuros.
5.1 - REVISÃO DO TRABALHO
Para o melhor entendimento do escopo da ferramenta foi necessário o estudo de
processo de software e qualidade de software. Processo que são passos que devem ser
seguidos na criação de um software que atenda a todas as expectativas e necessidades do
cliente. Cada processo tem seu ciclo, que por sua vez, não pode ser estático, e sim, deve-se
modificar e evoluir ao longo do tempo com a intenção de contemplar mudanças não pensadas
no princípio. O processo de software também sofre avaliação, que tem como base algumas
normas e modelos de qualidade. Um dos focos principais é o MPS.BR, modelo de qualidade
aderente à outras principais normas, tais como: CMMI, ISO15504 e ISO12207. Este modelo
foi adotado para o estudo deste trabalho pois foi criado para a realidade brasileira, tendo um
método de avaliação separado em níveis de implementação e que cada nível tem sua área de
processo relacionado. Para que uma empresa possa fazer uma avaliação de um nível superior
todos os outros níveis abaixo devem estar de acordo e passarem na avaliação, ou caso
contrário a empresa será qualificada no menor nível em que foi aprovada.
A ferramenta WISE propõe facilitar a avaliação do que se foi implementado na
empresa, fazendo com que o avaliador não tenha que fazer uso de diversas ferramentas não
específicas, por exemplo, fazer relatório em um editor de textos ou fazer planilhas em editores
de planilhas, o que pode demandar muito tempo. A ferramenta tende a diminuir o tempo gasto
pelo avaliador, que foi o maior foco deste trabalho, por ser o que demanda mais esforço
fazendo a avaliação, porém ele não será o único beneficiado, a empresa avaliada e a empresa
responsável pela coordenação do modelo MPS.BR, a SOFTEX, também ganharão melhorias
na sistematização de suas tarefas neste processo de avaliação. A empresa avaliada ganhará
preenchendo a tabela de artefatos de maneira sistêmica, que conterá as informações
necessárias para a avaliação e a SOFTEX ganhará com a facilidade na gerência das
avaliações.
62
5.2 - REVISÃO DO PROPOSTO
O foco do trabalho era se fazer um estudo sobre o modelo de qualidade MPS.BR para
que fosse criado um software que auxiliasse a avaliação do mesmo em menos tempo e de
forma mais fácil. O software foi usado em uma avaliação oficial do MPS.BR trazendo
redução no tempo de avaliação, como foi descrito no estudo de caso realizado no Capítulo 4.
5.3 - TRABALHO FUTUROS
Além do que foi construído neste trabalho, foram sugeridas algumas melhorias que
poderão ser desenvolvidos futuramente.
5.3.1 - Promover melhoria
Melhorar o sugerido pelo avaliador, na seção estudo de caso, que ao usar a ferramenta
notou uns pontos com chance de melhoria, como interface gráfica e impressão de relatórios.
5.3.2 - Alterar a arquitetura
A ferramenta foi desenvolvida para ser uma aplicação Desktop, mas poderá ser
estendida para uma arquitetura WEB. Fazendo assim com que o sistema possa ser utilizado de
qualquer ambiente e em qualquer lugar, e todas as informações seriam acessadas remotamente
pelos usuários.
5.3.3 - Estender a aplicação
Implementar outros métodos de avaliação de qualidade organizacional, por exemplo o
CMMI, para que o avaliador possa avaliar esses modelos usando também a ferramenta.
63
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT (Associação Brasileira de Normas Técnicas), NBR ISO 8402/1994 – Gestão da
Qualidade e Garantia da Qualidade, Terminologia, Brasil, 1994.
BOOCH, G. & RUMBAUGH, J. & JACOBSON, I., UML: The Unified Modeling
Language User Guide, Addison-Wesley, 1999.
CMMI Product Team, Capability Maturity Model Integration (CMMI) for Software
Engineering Version 1.1, Staged Representation, Carnegie Mellon, USA, 2006.
GOMES, Augusto Gonçalves, Avaliação de Processos de Software baseada em Medições,
Orientadora: Ana Regina Rocha e Káthia Marçal de Oliveira. Dissertação de Mestrado,
COPPE/UFRJ, 2001.
HUMPHREY, Watts S., Managing the Software Process, The SEI Series in Software
Engineering. Addison-Wesley, 1989.
ISO 9000-3, Quality management and quality assurance standards – parte 3:
guidelines for the application of ISSO 9001:1994 to the development, supply and
maintenance of computer software. International Organization for Standardization, 1991.
ISO/IEC TR 15504, Information technology – software process assessment. International
Organization for Standardization, 2004.
MACHADO, Luís Filipe C. & SANTOS, Gleison & OLIVEIRA, Káthia M. & ROCHA,
Ana Regina, Def-Pro: Uma ferramenta para apoiar a definição do procesos padrão. XI
CITS – Conferência Internacional de Tecnologia de Software. Curtiba, PR, 2000.
64
MACIEL, Teresa Maria de Medeiros & CAMPELÔ, Gabriela Moreira Carneiro, Suporte
de Ferramentas CASE na Implantação do CMM, Orientador: Alexandre Vasconcelos.
Monografia de Disciplina. Centro de Informática – UFPE, 2000.
NBR ISO/IEC 12207:1995, Tecnologia de informação – processos de ciclo de vida de
software. Associação Brasileira de Normas Técnicas, 1998.
OLIVEIRA, Sandro Ronaldo Bezerra, Gerência do Desenvolvimento de Software,
Orientador Alexandre Marcos Lins de Vasconcelos. Monografia apresentada a disciplina
Engenharia de Software constante no programa de Mestrado. CIN/UFPE, 2000.
OLIVEIRA, Sandro Ronaldo Bezerra, ToolManger: Um Gerenciador de Ferramentas
CASE, Orientador Alexandre Marcos Lins de Vasconcelos. Dissertação de Mestrado, CIN/
UFPE, 2001.
PAULK, M. C., WEBER, C.V., CURTIS, B., CHRISSIS, M.B., The Capability Maturity
Model: Guidelines for Improving Software Process, Addison – Wesley, USA, 1995.
PRESSMAN, R. S., Software Engineering: A Practioner’s Approach, 5th edition.
MacGraw-Hill International Edition, 2000.
REIS, Carla Alessandra Lima, Um Gerenciador de Processos de Software para o
Ambiente PROSOFT, Orientador Daltro José Nunes. Dissertação de Mestrado. PPGC –
UDFRGS, 1998.
ROCHA, Ana Regina Cavalcanti da & MALDONADO, José Carlos & WEBER, Kival
Chaves, Qualidade de Software: Teoria e Prática, São Paulo: Prentice Hall, 2001.
Softex - Sociedade para Promoção da Excelência do Software Brasileiro, MPS.BR -
Melhoria de Processo do Software Brasileiro, Guia Geral, versão 1.2, 2007.
65
Softex - Sociedade para Promoção da Excelência do Software Brasileiro, MPS.BR -
Melhoria de Processo do Software Brasileiro, Guia de Avaliação, versão 1.1, 2007.
WEBER, Kival C. et al, Modelo de Referência para Melhoria de Processo de Software:
uma abordagem brasileira, Conferência Latinoamericana de Informática – CLEI,
Arequipa-Peru, 2004.
XML Metadata Interchange (XMI) Specification, OMG Document ad/98-10-05.
Framingham, MA: Object Management Group, 1998.
ZAHRAN, S., Software Process Improvement, Addison Wesley Longman Inc, 1998.