UNIVERSIDADE DA AMAZÔNIA CENTRO 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ÉM 2008
65
Embed
WISE: UMA ABORDAGEM DE FERRAMENTA DE SOFTWARE … · Tabela 4.1: Requisitos funcionais para a ferramenta do Administrador ..... 35 Tabela 4.2: Requisitos funcionais para a ferramenta
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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.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.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
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