humberto ferreira da luz junior software para … · 1 introduÇÃo ... expande os casos de uso...

HUMBERTO FERREIRA DA LUZ JUNIOR

SOFTWARE PARA AVALIAÇÃO DE

CASO DE USO E GERÊNCIA DE CHECKLISTS

LONDRINA - PARANÁ

2010




Relatório Final de Estágio Obrigatório apresentado ao

Curso de Computação, Departamento de Computação

da Universidade Estadual de Londrina, como requisito

parcial para a obtenção do título de Bacharel, sob

orientação do Prof. Dr. Rodolfo Miranda de Barros.

LONDRINA - PARANÁ

2010




______________________________

Prof. Dr. Rodolfo Miranda de Barros

Universidade Estadual de Londrina

______________________________

Prof. Dr. Mario Lemes Proença Jr.


______________________________

Prof. Ms. Elieser Botelho Manhas Jr.


RESUMO

Atualmente na Fábrica de Projetos de Software e Tecnologia da Informação e

Comunicação (GAIA) do Departamento de Computação da Universidade Estadual de

Londrina todos os documentos de apoio às atividades de engenharia de software são

hospedados e manipulados no Google Docs, algumas vezes em planilhas e outras como

documentos de texto. Essa é uma boa solução para o desenvolvimento distribuído, porém

muitas vezes torna o acesso às informações mais difícil, diminui a organização da

documentação e não considera o relacionamento entre os documentos já que não foi criada

para este fim.

Durante o desenvolvimento deste trabalho foi desenvolvida uma aplicação

Web que armazena os documentos de avaliação dos casos de uso. Esta ferramenta Web

será desenvolvida utilizando a linguagem de programação Java EE 5, assim como também

os frameworks EJB 3.0 (utilizado nas camadas de regra de negócio e persistência), Java

Server Faces e Richfaces (camada web). Também foram utilizados o servidor de aplicação

Jboss AS 5.1.0 e o Sistema Gerenciador de Banco de Dados PostgreSQL 8.4.

É importante destacar que este sistema faz parte de um projeto maior que

implementa um ambiente de apoio ao processo de desenvolvimento de software e aborda

funcionalidades não descritas neste trabalho.

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................. 8

2 PROCEDIMENTOS METODOLÓGICOS ............................................................................. 11

2.1 MyEclipse IDE ...................................................................................................................................... 11

2.2 JBoss Application Server ...................................................................................................................... 11

2.3 JDK 1.5................................................................................................................................................. 11

2.4 Enterprise Javabeans 3.0 .................................................................................................................... 12

2.5 Java Server Faces ................................................................................................................................. 12

2.6 Richfaces ............................................................................................................................................. 12

2.7 PostgreSQL .......................................................................................................................................... 13

2.8 O Processo de Desenvolvimento ......................................................................................................... 13 2.8.1GAIA e o seu Processo de Desenvolvimento de Software .................................................................. 13

3 ESPECIFICAÇÕES DE CASOS DE USO ................................................................................ 17

3.1 Manter Checklist ................................................................................................................................. 17 3.1.1 Descrição ............................................................................................................................................ 17 3.1.2 Fluxo Básico ........................................................................................................................................ 17 3.1.3 Fluxos Alternativos ............................................................................................................................. 17 3.1.4 Requisitos especiais ............................................................................................................................ 18 3.1.5 Precondições ...................................................................................................................................... 18 3.1.6 Pós-condições ..................................................................................................................................... 18 3.1.7 Pontos de Extensão ............................................................................................................................ 18 31.8 Local View ............................................................................................................................................ 18 3.1.9 Definição dos atributos ...................................................................................................................... 19 3.1.10 Protótipo da Interface ...................................................................................................................... 20

3.2 Manter Histórico ................................................................................................................................. 21 3.2.1 Descrição ............................................................................................................................................ 21 3.2.2 Fluxo Básico ........................................................................................................................................ 21 3.2.3 Fluxos Alternativos ............................................................................................................................. 21 3.2.4 Requisitos especiais ............................................................................................................................ 22 3.2.5 Precondições ...................................................................................................................................... 22 3.2.6 Pós-condições ..................................................................................................................................... 22 3.2.7 Pontos de Extensão ............................................................................................................................ 22 3.2.8 Local View ........................................................................................................................................... 22 3.2.9 Definição dos atributos ...................................................................................................................... 23 3.2.10 Protótipo da Interface ...................................................................................................................... 24

3.3 Manter Revisão ................................................................................................................................... 25 3.3.1 Descrição ............................................................................................................................................ 25

3.3.2 Fluxo Básico ........................................................................................................................................ 25 3.3.3 Fluxos Alternativos ............................................................................................................................. 25 3.3.4 Requisitos especiais ............................................................................................................................ 25 3.3.5 Precondições ...................................................................................................................................... 26 3.3.6 Pós-condições ..................................................................................................................................... 26 3.3.7 Pontos de Extensão ............................................................................................................................ 26 3.3.8 Local View ........................................................................................................................................... 26 3.3.9 Definição dos atributos ...................................................................................................................... 27 3.3.10 Protótipo da Interface ...................................................................................................................... 28

4 DIAGRAMAS ............................................................................................................................. 29

4.1 Diagrama de Arquitetura ..................................................................................................................... 29

4.2 Diagrama de Entidade e Relacionamento ............................................................................................ 31

4.3 Diagrama de Classes ............................................................................................................................ 32

4.4 Diagramas de Atividade....................................................................................................................... 33 4.4.1 Manter Checklist ................................................................................................................................ 33 4.4.2 Manter Revisão .................................................................................................................................. 33 4.4.3 Manter Histórico ................................................................................................................................ 33

5 RELATÓRIO DE TESTES ....................................................................................................... 34

5.1 Histórico da Revisão ............................................................................................................................ 34

5.2 Introdução ........................................................................................................................................... 34 5.2.1 Ambiente ............................................................................................................................................ 34

5.3 Critérios de completeza ....................................................................................................................... 35

5.4 Especificação dos testes ...................................................................................................................... 35 5.4.1 Procedimentos de teste ..................................................................................................................... 35

5.5 Casos de teste e Incidentes dos Testes ................................................................................................ 39 5.5.1 Página Gerenciar Checklist ................................................................................................................. 39 5.5.2 Página Responder Checklist ............................................................................................................... 40 5.5.3 Página Visualizar Checklist ................................................................................................................. 41 5.5.4 Página Histórico .................................................................................................................................. 41 5.5.5 Página Gerenciar Revisão ................................................................................................................... 42

5.6 Relatório resumido dos testes ............................................................................................................. 42

5 DESIGN DAS PÁGINAS .......................................................................................................... 44

6 CONSIDERAÇÕES FINAIS ..................................................................................................... 45

7 BIBLIOGRAFIA ........................................................................................................................ 47

LISTA DE FIGURAS

FIGURA 2.1: PROCESSO DE DESENVOLVIMENTO 1 .......................................................................................... 15 FIGURA 3.1: LOCAL VIEW ............................................................................................................................. 18 FIGURA 3.2: PROTÓTIPO DA INTERFACE ....................................................................................................... 20 FIGURA 3.3: PROTÓTIPO DA INTERFACE ....................................................................................................... 20 FIGURA 3.4: PROTÓTIPO DA INTERFACE ....................................................................................................... 20 FIGURA 3.5: LOCAL VIEW ............................................................................................................................. 22 FIGURA 3.6: PROTÓTIPO DA INTERFACE ...................................................................................................... 24 FIGURA 3.7: LOCAL VIEW ............................................................................................................................. 26 FIGURA 3.8: PROTÓTIPO DA INTERFACE ....................................................................................................... 28 FIGURA 4.4.1.1: DIAGRAMA DE ATIVIDADE 1.......................................................................................... ANEXO FIGURA 4.4.1.2: DIAGRAMA DE ATIVIDADE 2.......................................................................................... ANEXO FIGURA 4.4.1.3: DIAGRAMA DE ATIVIDADE 3.......................................................................................... ANEXO FIGURA 6.1: DIAGRAMA DE CASO DE USO 1 .................................................................................................... 45

LISTA DE TABELAS TABELA 3.1: DEFINIÇÃO DOS ATRIBUTOS ........................................................................................................ 19 TABELA 3.2: DEFINIÇÃO DOS ATRIBUTOS ........................................................................................................ 23 TABELA 3.3: DEFINIÇÃO DOS ATRIBUTOS ........................................................................................................ 27

LISTA DE ABREVIATURAS

AJAX - Asynchronous Javascript And XML

ANSI - American National Standards Institute

API - Application Programming Interface

CRUD - Create, Retrieve, Update e Delete, que são operações relativas a Cadastro,

Busca, Atualização e Exclusão

CSS - Cascading Style Sheets

EJB - Enterprise Javabeans

HTML - HyperText Markup Language

IDE - Integrated Development Environment

JDK - Java Development Kit

JSF - Java Server Faces

JSP - Java Server Pages

MPS-BR - Melhoria de Processos do Software Brasileiro

PDS - Processo de Desenvolvimento de Software

PMBOK - Project Management Body of Knowledge

POJO - Plain Old Java Objects

RUP - Rational Unified Process

SGBD - Sistema Gerenciador de Banco de Dados

SGBDOR - Sistema Gerenciador de Banco de Dados Objeto Relacional

SQL - Structured Query Language

UML - Unified Modeling Language

V&V - Verificação e Validação

XML - Extensible Markup Language

8

1 INTRODUÇÃO

Qualidade de software de forma mais geral é “a satisfação de requisitos

funcionais e de desempenho explicitamente declarados, normas de desenvolvimento

explicitamente documentadas e características implícitas que são esperadas em todo o

software desenvolvido profissionalmente” [3]. Para satisfazer todas as características

esperadas no software, atividades de verificação e validação são necessárias. Verificação e

validação é “o nome dado aos processos de verificação e análise que asseguram que o

software cumpra com suas especificações e atenda às necessidades dos clientes que estão

pagando por ele. A verificação e validação constituem um processo de ciclo de vida

completo, começando com as revisões dos requisitos e continuando com as revisões de

projeto e as inspeções de código até chegar aos testes de produto. Deve haver atividades de

V&V em cada estágio do processo de software. Essas atividades verificam se os resultados

das atividades de processo estão conforme o especificado” [8].

Dentro da área de conhecimento de Integração do PMBOK, o processo que se

preocupa com a verificação e validação é tanto o de Monitoramento e controle do trabalho

do projeto, como também o de Realização do controle integrado de mudanças. O primeiro

processo inclui “a coleta, medição e distribuição das informações de desempenho e a

avaliação das medições e tendências para efetuar melhorias no processo”. Além disso, uma

de suas preocupações é a “manutenção de uma base de informações precisas e oportunas a

respeito do produto(s) do projeto e suas relativas documentações do início ao término do

projeto”. Já o segundo é “o processo de revisão de todas as solicitações, aprovação e

gerenciamento de mudanças em entregas, ativos de processos organizacionais, documentos

de projeto e plano de gerenciamento de projeto”, dentre as suas atividades está a de

“revisar, aprovar ou rejeitar todas as ações corretivas e preventivas” recomendadas pelo

processo de monitoramento e controle de projeto já citados”. [9]

Segundo Hrvoje & Filjar [2] “as empresas de desenvolvimento de software

deveriam organizar o trabalho em atividades de desenvolvimento de software de forma que

possam obter sucesso no mercado global”. Estas atividades variam de acordo com a

metodologia de processo de desenvolvimento de software (PDS) utilizada.

9

Um dos PDSs mais tradicionais é o Rational Unified Process (RUP), que é

“um processo adaptável e iterativo que é centrado na arquitetura e orientado a riscos”. Os

processos do RUP são organizados em quatro fases: concepção, elaboração, construção e

transição. [4]

Dentro da fase de concepção “os requisitos de negócio fundamentais são

descritos por meio de casos de uso preliminares” [3], já a fase de elaboração “refina e

expande os casos de uso preliminares que foram desenvolvidos a partir da fase de

concepção”. Um caso de uso de acordo com Brooch, G., et al [5] é “uma descrição de um

conjunto de sequências de ações, inclusive variantes, que um sistema executa para produzir

um resultado de valor observável por um ator”.

Apesar de o RUP ser especialmente adequado à UML, ela é amplamente

independente de processo, porém “para obter o máximo proveito da UML, é preciso levar

em consideração um processo que seja orientado a caso de uso, centrado na arquitetura,

iterativo e incremental”. Ser orientado a caso de uso quer dizer que eles serão utilizados

para “o estabelecimento do comportamento do sistema, para a verificação e validação da

arquitetura do sistema, para a realização de testes e para a comunicação entre os

participantes do projeto”. Centrado na arquitetura significa que “a arquitetura do sistema é

utilizada como principal artefato para a conceituação, a construção, o gerenciamento e a

evolução do sistema em desenvolvimento”. Iterativo é aquele processo que gera versões

executáveis em sequência, enquanto incremental quer dizer que essas versões executáveis

serão integradas continuamente. [5]

Uma das características principais que definem uma fábrica de software é a

capacidade de obter feedback do que já foi realizado para reconhecer e lidar com

oportunidades de melhoria do processo [6]. Este feedback é obtido através de métricas do

projeto, que são “medidas quantitativas do grau em que um sistema, componente ou

processo possui um determinado atributo” [10] e “nos dão um modo sistemático de avaliar

qualidade com base em um conjunto de regras claramente definidas”[3], desta forma os

problemas podem ser corrigidos antes que se tornem mais graves.

Dentro da Fábrica de Software há documentos de avaliação que coletam estas

métricas, dentre eles estão o documento de revisão de caso de uso e o plano de testes. Estes

documentos são gerados iterativamente até que a qualidade mínima exigida seja obtida.

10

Devido à importância destes documentos surge a necessidade de automatizar

esse processo, de forma que a criação e manutenção dos documentos seja facilitada e que

também agilize a coleta de métricas para as próximas iterações do mesmo projeto, como

também para outros projetos de software.

Este trabalho esta dividido da seguinte forma: no Capítulo 2 estão descritos os

procedimentos metodológicos incluindo as ferramentas de desenvolvimento utilizadas

como também o processo de desenvolvimento de software adotado, no capítulo 3 são

apresentados os três casos de uso implementados neste trabalho, no capítulo 4 são

encontrados os diagramas criados no projeto, no capítulo 5 é descrita a situação corrente do

trabalho, o capítulo 6 realiza as considerações finais e no último capítulo (7) é apresentada

a bibliografia na qual esta dissertação se apoiou.

11

2 PROCEDIMENTOS METODOLÓGICOS

As ferramentas e tecnologias utilizadas neste trabalho estão descritas nas

subseções seguintes:

2.1 MyEclipse IDE

O MyEclipse é uma IDE java construída sobre a plataforma Eclipse que integra

soluções proprietárias e open source no ambiente de desenvolvimento [12]. Dentre as

vantagens agregadas pelo MyEclipse estão o suporte ao JSF e principalmente à engenharia

reversa que ele faz sobre o projeto físico do banco de dados, gerando as classes de

persistência e suas respectivas operações de manipulação do banco de dados, de forma que

apenas algumas adaptações sejam necessárias nestas classes java.

Atualmente este ambiente de desenvolvimento se encontra na versão 8.6, que

foi lançada recentemente. Porém no desenvolvimento deste trabalho a versão 8.5 foi a

selecionada para ser utilizada no projeto.

2.2 JBoss Application Server

O JBoss Application Server (ou JBoss AS) é o servidor de aplicação Java mais

utilizado no mundo atualmente. Ele é uma plataforma java EE para desenvolvimento e

implantação de aplicações java empresariais para a web. Alguns dos serviços

disponibilizados por ele estão a clusterização, caching, e persistência. Uma variedade de

configurações muito grande é disponibilizada de modo que se aumente sua segurança e

escalabilidade com facilidade. [11]

A vantagem de sua utilização é a de poder utilizar os frameworks Enterprise

Javabeans (EJBs) e Java Server Faces (JSF) sem a necessidade de configuração adicional.

A única necessidade de configuração no JBoss AS é o arquivo data-source, que contém as

configurações de conexão com o banco de dados.

2.3 Java Development Kit 1.5

A versão JDK 1.5 apresenta novas extensões para a linguagem de programação

Java. Possui um número de classes muito maior do que as versões anteriores (mais de

12

3500), além disso, inclui diversas alterações significativas à própria linguagem, tornando-a

mais fácil para os programadores e fornecendo novos recursos já populares em outras

linguagens.

2.4 Enterprise Javabeans 3.0

A tecnologia Enterprise Javabeans (EJB) é a arquitetura de componente do

lado do servidor para a plataforma Java. A tecnologia EJB permite um desenvolvimento

rápido e simplificado de aplicações distribuídas, transacionais, seguras e portáveis

baseadas na tecnologia java. [10]

O EJB 3.0 permite persistir dados no banco de dados sem o uso de SQL,

trabalhando sempre com objetos java simples (POJOs) e utilizando session beans (também

conhecidos como façades) para implementar as operações CRUD (Create, Retrieve,

Update e Delete) de persistência. Essas classes podem implementar inclusive outras

características das tabelas de bancos de dados, como por exemplo a de autogerar o

identificador das tabelas e também a possibilidade de buscar um objeto de uma tabela e

junto com ele todos os outros objetos de outras tabelas que tenham relacionamento com

ele.

2.5 Java Server Faces

Java Server Faces (JSF) é um framework java que traz o desenvolvimento

rápido de interfaces web de usuário. Ele gerencia regras de navegação, validação e

conversão de campos de formulários. [15]

O JSF ainda é capaz ainda de se integrar ao EJB, mesmo que esta integração

não seja com perfeição, já que é requerido mais código do que deveria ser necessário. O

framework JBoss Seam foi criado para resolver este problema e unir o JSF e o EJB a um

único bloco, porém este framework não é abordado nem utilizado neste trabalho.

2.6 Richfaces

Richfaces é uma biblioteca de componentes para JSF e um framework

avançado para integrar o AJAX às aplicações de negócio. Entres suas vantagens está o

mecanismo chamado skinnability que permite que você altere o visual da sua aplicação

13

inteira modificando apenas uma linha de um arquivo, além disso ele também possui uma

grande comunidade para suporte. [13]

2.7 PostgreSQL

O PostgreSQL é um sistema gerenciador de banco de dados objeto relacional

(SGBDOR) desenvolvido como projeto de código aberto. Sua vantagem é que além de ser

gratuito, ele não possui limite no tamanho máximo do banco de dados, sua implementação

está dentro do padrão ANSI-SQL92/99, possui suporte completo a sub-queries e diversas

funcionalidades mais complexas que o deixa no mesmo nível de diversos SGBDs pagos.

[14]

2.8 O Processo de Desenvolvimento

O processo de desenvolvimento de software compreende um conjunto de

atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de produzir

softwares que atendam aos requisitos especificados pelos usuários (clientes).

A equipe de desenvolvimento de software possui uma missão: entregar

software de qualidade, dentro do prazo e custo, que atenda aos requisitos do negócio e que

seja flexível para acomodar as mudanças futuras nas necessidades dos usuários. O processo

tem que ser customizável para não “engessar” a equipe numa forma de trabalho

burocrática.

2.8.1 GAIA e o seu Processo de Desenvolvimento de Software

Uma fábrica de software é uma organização que provê serviços de

desenvolvimento de sistemas com alta qualidade, baixo custo e de forma rápida, utilizando

um processo de desenvolvimento de software bem definido e tecnologia de ponta, além de

algumas formas de feedback para reconhecer e lidar com oportunidades de melhoria do

processo [16].

Basicamente, as Fábricas de Software podem ser classificadas em Fábricas de

Programas, Fábricas de Teste e Fábricas de Projetos. As Fábricas de Programas

caracterizam-se por atuarem em apenas uma porção do processo produtivo do software.

Seu objetivo é codificar e testar programas conforme um acordo de níveis de serviços com

14

o cliente ou usuário. As Fábricas de teste atuam no teste do software verificando e

validando se a codificação está em conformidade com a especificação de requisitos. E as

Fábricas de Projetos, por sua vez, atuam com um pouco mais de abrangência no processo

de produção, englobando além das atividades inerentes à Fábrica de Programas e à Fábrica

de Testes, fases como modelagem de negócio, requisitos, análise e design.

Tem-se também, a chamada Fábrica de Projetos de Software ou Fábrica de

Projetos Ampliada que, além da abrangência da Fábrica de Projetos, atua também na

arquitetura da solução. Seu objetivo é a conceituação do software, preocupando-se em

projetar uma solução em que o software se caracteriza apenas como um dos componentes.

O processo de desenvolvimento de software compreende um conjunto de

atividades que engloba métodos, ferramentas e procedimentos, com o objetivo de produzir

softwares que atendam aos requisitos especificados pelos usuários ou clientes. A Fábrica

GAIA utiliza um processo de desenvolvimento baseado no Processo Unificado, iterativo e

incremental [17], direcionado a casos de uso e centrado na arquitetura.

A partir de uma perspectiva de gerenciamento baseada no PMBOK [18], o

Processo de Desenvolvimento de Software da GAIA é dividido em seis fases, cada uma

concluída por um marco principal. A Fig. 2.1 apresenta este Processo e a forma como a

Gerência de Comunicação atua com o Processo GAIA, ou seja, em paralelo a este

Processo. Cada fase do processo é composta por atividades, sendo que cada uma destas

atividades são descritas por um fluxo de trabalho composto por tarefas a serem realizadas

pelos atores do processo, gerando artefatos (atas, documentos, código fonte, planos de

testes).

15

Figura 2.1: Processo de Desenvolvimento 1

Análise Inicial: reunião com o cliente para entendimento do problema e definição do

escopo. O número de reuniões é definido pela equipe de analistas, visto que, por

política organizacional [19], a GAIA investe na qualidade deste escopo, minimizando

ao máximo problemas de falta de entendimento, insatisfações futuras do cliente pelo

fato do sistema não atender suas necessidades, evitando com isso o retrabalho. O

resultado deste investimento é a minimização dos riscos do projeto. Para cada reunião é

gerada uma ata que deve ser assinada por todos os participantes, firmando o

comprometimento de todos os envolvidos e para que os assuntos tratados sejam

disponibilizados eletronicamente a todos os demais integrantes do desenvolvimento

deste produto. Ao término desta etapa, tem-se uma proposta para o cliente, incluindo o

escopo que é representado por uma Work Breakdown Structure (WBS), premissas,

riscos, o prazo (em meses) para o desenvolvimento e o custo do projeto. Para

estabelecimento dos prazos e custos utiliza-se um banco de dados histórico do

desempenho da equipe em projetos similares;

Análise e Planejamento: Após a aprovação da proposta, deve-se iniciar o

planejamento do projeto, por meio da definição dos casos de uso e das respectivas

especificações, dos riscos e prioridades de desenvolvimento, da expansão da WBS, da

alocação de pessoas, da elaboração do cronograma, do estabelecimento de pontos de

controle, do número de iterações e de quais casos de uso serão desenvolvidos em cada

iteração. É gerado um artefato intitulado Plano de Projeto. Vale ressaltar que esta fase

do processo de desenvolvimento da GAIA ocorre de maneira iterativa, ou seja, após

16

definirmos e iniciarmos a primeira iteração, no término da mesma, caso o

desenvolvimento deva continuar, esta fase é disparada novamente. Nesta fase também

ocorre o estabelecimento do grau de severidade para a aprovação ou não dos resultados

das atividades pelo projeto. O grau de rigorosidade implica diretamente no controle da

qualidade do projeto, ou seja, quanto menor a grau de rigorosidade, mais rígido é o

processo de garantia de qualidade do projeto;

Monitoramento e Controle: Paralelamente a Análise e Planejamento, deve-se iniciar

o monitoramento e controle do projeto, buscando verificar se o que está sendo feito

está de acordo com o planejado, tomando ações corretivas quando necessário. Esta

verificação deverá ser feita nos pontos de controle indicados no artefato Plano de

projeto;

Execução: Nesta fase ocorre a especificação e a implementação dos respectivos casos

de uso e os testes unitários. A especificação dos casos de uso deve ser verificada e

validada. Caso ocorra uma quantidade igual ou superior de não conformidades

aceitáveis para o projeto em questão, a iteração deve ser cancelada e um novo

planejamento deve ser estabelecido levando-se em consideração os atrasos e as

consequências dos mesmos. Após uma análise do resultado dos testes, decide-se,

baseado também no grau de rigorosidade, por corrigir as não conformidades

encontradas e realizar novamente os testes e partirmos para a próxima fase intitulada

Entrega ou cancelarmos a iteração e voltarmos para a fase de Análise e Planejamento;

Entrega: Esta fase está responsável por executar os testes de integração que, caso

registre um resultado positivo, iniciará a entrega e implantação da parte do produto

desenvolvida até a presente iteração. Se o projeto ainda não terminou, a fase de Análise

e Planejamento é iniciada novamente. Do contrário, a fase de Finalização é iniciada;

Finalização: Nesta faze é realizada um reunião de término do projeto, na qual são

levantadas as lições aprendidas, sendo as mesmas registradas em ata para futuras

consultas e melhorias no processo de desenvolvimento. É gerado um documento

indicando o recebimento do produto pelo cliente e o término do projeto.

Todas as fases do processo foram definidas com o propósito de ser o mais

simples possível, porém mantendo o formalismo para garantir a qualidade do

desenvolvimento nas nuvens.

17

3 ESPECIFICAÇÕES DE CASOS DE USO

Nesta seção são apresentadas as especificações de caso de uso desenvolvidas

durante a análise de requisitos.

Um modelo de caso de uso consiste no conjunto de todos os casos de uso para

o sistema, ou uma porção do sistema, junto com o conjunto de todos os atores que

interagem com estes casos de uso, descrevendo assim a funcionalidade completa do

sistema. Ele fornece um modelo das funções planejadas do sistema e seu ambiente, e pode

servir como um contrato entre o cliente e os desenvolvedores.

3.1 Manter Checklist

3.1.1 Descrição

Caso de uso para cadastro, edição e remoção de checklists. Estas checklists

nada mais são do que perguntas utilizadas para verificação e validação.

3.1.2 Fluxo Básico

Este caso de uso é disparado pelo gerente de projeto que desejar inserir uma

nova checklist à base de dados. Primeiramente os dados da nova checklist a ser inserida

devem ser preenchidos no formulário. A seguir as perguntas associadas àquele checklist

criado devem ser inseridas. Finalmente o botão de envio dos dados deve ser pressionado.

Neste momento ocorre a validação dos dados, se a validação ocorrer com sucesso a

checklist será salva na base de dados, caso contrário irá para o primeiro fluxo alternativo.

3.1.3 Fluxos Alternativos

Formulário não é validado com sucesso : caso algum dos campos do

formulário não seja preenchido corretamente, a mesma página será exibida novamente para

que o ator faça a correção e possa realizar a submissão com sucesso.

Ator deseja editar os dados de uma checklist: neste caso o ator seleciona

uma das checklists disponíveis exibidas em formato de tabela, utilizando opcionalmente

um dos filtros de busca, e clica na opção de edição da checklist correspondente. A seguir o

18

usuário edita os dados do formulário (incluindo o questionário da checklist) e os submete

clicando em um botão.

Ator deseja excluir uma checklist: neste caso o ator seleciona uma das

checklists exibidas em formato de tabela, utilizando opcionalmente um dos filtros de

busca, e clica na opção de exclusão da checklist correspondente.

Ator deseja apenas visualizar os dados de uma checklist: neste caso o ator

seleciona uma das checklists exibidas em formato de tabela, utilizando opcionalmente um

dos filtros de busca, e clica na opção de edição da checklist correspondente. Uma janela irá

surgir com todos os dados da pergunta solicitada.

3.1.4 Requisitos especiais

Este caso de uso não possui requisitos especiais.

3.1.5 Precondições

Este caso de uso não possui pré-condições.

3.1.6 Pós-condições

Este caso de uso não possui pós-condições.

3.1.7 Pontos de Extensão

Este caso de uso não possui pontos de extensão.

31.8 Local View

Figura 3.1: Local View

19

3.1.9 Definição dos atributos Nome da

variável

Tipo Limitações Descrição Interface Obrigatório

idPergunta Integer - Identificador da pergunta s/interface, será

gerado

automáticamente.

Sim

enunciado String Até 200

caracteres.

Enunciado da pergunta Inputtext Sim

tipo char 1 caracter. Tipo da pergunta (múltipla escolha ou

dissertativa)

Dropbox Sim

alternativas String[] Até 100

caracteres.

Alternativas de resposta (caso múltipla escolha) Datatable Não

resposta String Até 100

caracteres.

Resposta correta da múltipla escolha ou da

dissertativa

Inputtext Sim

data_hora Date - Horário em que a resposta foi submetida s/interface, será

gerado

automáticamente.

Sim

Tabela 3.1: Definição dos Atributos

20

3.1.10 Protótipo da Interface

Protótipo para adicionar checklist:

Figura 3.2: Protótipo da Interface

Protótipo para adicionar perguntas dissertativas:


Protótipo para adicionar perguntas dissertativas:


21

3.2 Manter Histórico

3.2.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um

histórico dos testes realizados em projetos de software.

3.2.2 Fluxo Básico

O caso de uso é disparado pelo analista de sistemas que armazena no histórico

uma ficha que está sendo persistida (de Revisão ou Checklist por exemplo). O ator

preenche os dados requeridos (ver tabela na seção 8) e clica em salvar. Após isto ocorre a

validação do formulário, se o formulário não for validado corretamente o sistema entrará

no fluxo alternativo 2.2.2, caso contrário os dados serão persistidos na base de dados.


Alterar um histórico cadastrado: o ator pode alterar um histórico de uma

revisão ou checklist já cadastrada através de uma tabela exibida na tela, clicando em seu

respectivo botão de edição. Os dados deverão ser modificados, então validados e salvos. Se

os dados não forem validados corretamente o fluxo irá para 2.2.2.

Formulário não validado: após a não validação a página será reexibida para a

correção do preenchimento do formulário. Após a correção os dados serão validados

novamente.

Excluir um histórico cadastrado: o ator pode excluir um histórico já

cadastrado através de uma tabela exibida na tela, clicando em seu respectivo botão de

exclusão. Será mostrado um aviso informando que essa operação não poderá ser desfeita,

oferecendo a opção de confirmar e de cancelar, selecionando-se a opção de Confirmar o

sistema exclui o procedimento de teste selecionado.

22

3.2.4 Requisitos especiais

Este caso de uso não possui requisitos especiais.

3.2.5 Precondições

Antes da execução deste caso de uso o sistema deverá ter executado ao menos

um dos seguintes casos de uso:

Manter Casos de Teste;

Manter Procedimentos de Teste;

Manter Relatório Resumido;

Manter Checklist;

Manter Atas;

Manter Revisão.





3.2.8 Local View


23

3.2.9 Definição dos atributos Nome da variável Tipo Limitações Descrição Interface Obrigatório

idDocumento Integer - Id do documento em sua respectiva tabela

(chave estrangeira)

- Sim

tipoDocumento Char 1 caracter Indica a que tipo de documento o histórico se

refere.

- Sim

idHistorico Integer - Id do histórico

data Date - Data em que foram feitas alterações Calendar Sim

versão String 1 a 10 caracteres Versão corrente do teste Campo de

texto

Sim

descrição String 1 a 100 caracteres Descrição do teste feito Campo de

texto

Sim

autor String 1 a 40 caracteres Autor do teste Campo de

texto

Sim


24



25

3.3 Manter Revisão

3.3.1 Descrição

Esse caso de uso destina-se a cadastrar, manter atualizado e excluir um

histórico dos testes realizados em projetos de software.

3.3.2 Fluxo Básico

O caso de uso é disparado pelo analista de sistemas que armazena no histórico

uma ficha que está sendo persistida (de Revisão ou Checklist por exemplo). O ator

preenche os dados requeridos (ver tabela na seção 8) e clica em salvar. Após isto ocorre a

validação do formulário, se o formulário não for validado corretamente o sistema entrará

no fluxo alternativo 2.2.2, caso contrário os dados serão persistidos na base de dados.


Alterar um histórico cadastrado: o ator pode alterar um histórico de uma

revisão ou checklist já cadastrada através de uma tabela exibida na tela, clicando em seu

respectivo botão de edição. Os dados deverão ser modificados, então validados e salvos. Se

os dados não forem validados corretamente o fluxo irá para 2.2.2.

Formulário não validado: após a não validação a página será reexibida para a

correção do preenchimento do formulário. Após a correção os dados serão validados

novamente.

Excluir um histórico cadastrado: o ator pode excluir um histórico já

cadastrado através de uma tabela exibida na tela, clicando em seu respectivo botão de

exclusão. Será mostrado um aviso informando que essa operação não poderá ser desfeita,

oferecendo a opção de confirmar e de cancelar, selecionando-se a opção de Confirmar o

sistema exclui o procedimento de teste selecionado.

3.3.4 Requisitos especiais Este caso de uso não possui requisitos especiais.

26

3.3.5 Precondições Antes da execução deste caso de uso o sistema deverá ter executado ao menos

um dos seguintes casos de uso:

Manter Casos de Teste;

Manter Procedimentos de Teste;

Manter Relatório Resumido;

Manter Checklist;

Manter Atas;

Manter Revisão.





3.3.8 Local View


27

3.3.9 Definição dos atributos Nome da variável Tipo Limitações Descrição Interface Obrigatório

idDocumento Integer - Id do documento em sua respectiva tabela

(chave estrangeira)

- Sim

tipoDocumento Char 1 caracter Indica a que tipo de documento o histórico se

refere.

- Sim

idHistorico Integer - Id do histórico

data Date - Data em que foram feitas alterações Calendar Sim

versão String 1 a 10 caracteres Versão corrente do teste Campo de

texto

Sim

descrição String 1 a 100 caracteres Descrição do teste feito Campo de

texto

Sim

autor String 1 a 40 caracteres Autor do teste Campo de

texto

Sim


28



29

4 DIAGRAMAS

4.1 Diagrama de Arquitetura

O desenvolvimento do aplicativo Web se baseará na arquitetura demonstrada

pela figura 4.1.

A Camada de Apresentação é onde é feita a interface para o usuário, seu acesso se

dá via navegador Web;

A Camada Web é o intermediador entre as camadas de Apresentação e de Regra de

Negócios. É programada nas linguagens de programação JSP, HTML e CSS. É a

camada onde é utilizado o framework JSF Richfaces;

A Camada de Regra de Negócios é quem contém os métodos e ações que podem

ser acessados pela camada de apresentação graças ao mapeamento XML oferecido

pelo framework JSF;

A Camada de Persistência é onde se utiliza a persistência do EJB que segue o

padrão da Java Persistence API (JPA), que cria automaticamente as classes

relacionadas a cada tabela do banco de dados (do SGBD PostgreSQL) vinculando-

as com as tabelas através do mapeamento XML.

30

Figura 4.1: Diagrama de Arquitetura

31

4.2 Diagrama de Entidade e Relacionamento

Um diagrama entidade-relacionamento é o projeto lógico do banco de dados,

que tem seus dados representados de forma abstrata e conceitual. Ele é a base para o

projeto físico (SQL) necessário para desenvolver a aplicação na fase de desenvolvimento.

O diagrama entidade-relacionamento deste projeto está abaixo.

Figura 4.2: Diagrama Entidade-Relacionamento

32

4.3 Diagrama de Classes

Dentro da engenharia de software, segundo a UML um diagrama de classe é

um tipo de diagrama de estrutura estática que descreve a estrutura de um sistema através de

suas classes, seus atributos, e os relacionamentos entre elas. O diagrama de classes

desenvolvido neste projeto está disponível em um anexo deste trabalho.

33

4.4 Diagramas de Atividade

O diagrama de atividade não representa apenas o comportamento esperado do

sistema, como também a sequência das ações que deverão ocorrer. Ele é essencialmente

um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra.

4.4.1 Manter Checklist

A figura 4.4.1.1 contendo o diagrama de atividade da página Manter Checklist

está em anexo a este trabalho.

4.4.2 Manter Revisão

A figura 4.4.1.2 contendo o diagrama de atividade da página Manter Revisão


4.4.3 Manter Histórico

A figura 4.4.1.3 contendo o diagrama de atividade da página Manter Histórico


34

5 RELATÓRIO DE TESTES

5.1 Histórico da Revisão

Data Versão Descrição Autor

02/10/2010 1.0 Teste da Ferramenta de Gerência de Checklists Humberto

5.2 Introdução

O objetivo deste teste é verificar e validar a ferramenta de gerência de

Checklists e de Revisões de Especificações de Caso de Uso em um Ambiente de

Desenvolvimento de Software (ADS), desenvolvida como parte do Estágio Curricular

Obrigatório (5EST314), do curso de Ciência da Computação no ano de 2010 da

Universidade Estadual de Londrina.

Este teste é de característica funcional, ou seja, as funcionalidades da

ferramenta proposta devem estar em conformidade com os casos de uso apresentados.

5.2.1 Ambiente

O ambiente em que foram executados os testes, características da máquina

usada para teste, bem como drivers, stubs, arquivos ou bancos de dados criados para os

testes, entre outros.

Notebook Intel Core 2 Duo 2,2GHz, 4 Gb. de Memória RAM, Navegador

Google Chrome 7.0.536.2 dev, Windows 7 64 bits

Foram usados os seguintes itens:

Número

de ordem

Item Comentários

1 Banco de Dados PostgreSQL Foi utilizado um banco de dados

fictício para teste, no servidor remoto

de Banco de Dados do GAIA – Fábrica

35

de Projetos de TIC.

Tabela 5.2.1: Ambiente 1

5.3 Critérios de completeza

Definem-se aqui as condições que devem ser satisfeitas e o estado que deve ser

atingido, para que o conjunto de testes seja considerado bem-sucedido.

Número de

ordem

Critério

1 Todos os campos de cada uma das partes da ferramenta devem ser salvos

corretamente no banco de dados.

2 Todas as alterações feitas em algum campo da ferramenta devem ser

salvas corretamente no banco de dados.

3 No caso de existirem tabelas auxiliares nas telas da ferramenta, cada item

dessa tabela auxiliar deve ser salvo corretamente e ainda estar associado

com a chave primária da tabela principal para que possa ser feito a

rastreabilidade dos itens.

4 As exclusões devem ocorrer de maneira correta e não apresentar erros.

5 Quando um item de uma tabela principal for excluído todos os itens

relacionados a ele nas tabelas auxiliares devem ser excluídos também.

Tabela 5.3: Critérios de completeza 1

5.4 Especificação dos testes Nesta parte do documento são ser descritos os procedimentos e os casos de

teste a serem aplicados. Aqui são registrados, excepcionalmente, os eventos ocorridos

durante a execução dos testes, podendo ser resultados obtidos e anomalias ocorridas.

5.4.1 Procedimentos de teste São definidos aqui os procedimentos associados ao conjunto de testes. Foi

utilizada a sigla GC (Gerência de Checklists), RC (Responder Checklists) e VC (Visualizar

Checklists) para a identificação dos testes.

Página Checklist

Identificação GC_teste1

Objetivo Verificar se a inclusão de um item na página “Checklist” da

ferramenta é feita corretamente.

Requisitos

Especiais

Nenhum

Selecionar no menu o item “Gerenciar Checklist” que irá abrir a

página para cadastrar uma checklist.

36

Fluxo

Preencher todos os campos de texto com o mesmo nome de seu

respectivo outputtext (quando possível), e o mesmo se aplica aos

campos utilizados em tabelas auxiliares.

Clicar em salvar.

Verificar no banco de dados se o item foi salvo corretamente, e se os

itens da(s) tabela(s) auxiliar(es) foram salvos corretamente.

Tabela 5.4.1: Procedimento de teste 1


Objetivo Verificar se as alterações feitas num item na página “Checklist” da

ferramenta são salvas corretamente.

Requisitos

Especiais

Deve existir algum item cadastrado anteriormente.

Fluxo

Selecionar no menu o item “Gerenciar Checklist” que irá abrir a

página para alterar uma checklist.

Modificar todos os campos da página, bem como os campos utilizados

em tabelas auxiliares.

Clicar em atualizar.

Verificar no banco de dados se o item foi atualizado corretamente, e

se os itens da(s) tabela(s) auxiliar(es) foram atualizados corretamente.



Objetivo Verificar se a exclusão de um item é feita de maneira correta e não

apresenta erros.

Requisitos

Especiais


Fluxo

Selecionar no menu o item “Checklist” que irá abrir a página para

excluir uma checklist.

Clicar em Sim.

Verificar no banco de dados se o item foi deletado corretamente, e se

os itens da(s) tabela(s) auxiliar(es) referentes a ele foram excluídos

corretamente.


Página Responder Checklist

Identificação RC_teste1

Objetivo Verificar se a submissão da resposta de uma checklist na página

“Responder Checklist” da ferramenta é feita corretamente.

37

Requisitos

Especiais

Deve existir uma checklist já cadastrada anteriormente.

Fluxo

Selecionar no menu o item “Responder Checklist” que irá abrir a

página para responder as perguntas de uma checklist.

Preencher todas as perguntas de uma checklist com uma string ou

selecionar uma das alternativas de acordo com o tipo da pergunta.

Clicar em responder.

Verificar no banco de dados se o item foi salvo corretamente.


Página Visualizar Checklist

Identificação VC_teste1

Objetivo Verificar se a resposta de uma checklist é visualizada corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Visualizar Checklist” que irá abrir a

página para visualizar as respostas de uma checklist.

Clicar no botão da respectiva resposta presente em uma tabela.

Verificar se as informações contidas na janela que abrir estão corretas.

Fechar a janela.


Página Histórico

Identificação GC_historico1

Objetivo Verificar se a inclusão de um item na página “Histórico” da

ferramenta é feita corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Histórico” que irá abrir a página para

cadastrar um histórico.

Selecionar todos os itens pertinentes, além de preencher os campos de

texto com o mesmo nome de seu respectivo outputtext (quando

possível).

38

Clicar em salvar.



Identificação GT_historico2

Objetivo Verificar se as alterações feitas num item na página “Histórico” da


Requisitos

Especiais


Fluxo


alterar um histórico.

Modificar todos os campos da página.


Verificar no banco de dados se o item foi atualizado corretamente.


Identificação GT_historico3


apresenta erros.

Requisitos

Especiais


Fluxo


excluir um histórico.

Clicar em Sim.

Verificar no banco de dados se o item foi deletado corretamente.


Página Revisão

Identificação GR_teste1

Objetivo Verificar se a inclusão de um item na página “Revisão” da ferramenta

é feita corretamente.

Requisitos

Especiais

Nenhum

Fluxo

Selecionar no menu o item “Gerenciar Revisão” que irá abrir a página

para cadastrar uma revisão.

Preencher todos os campos de texto com o mesmo nome de seu

respectivo outputtext (quando possível), ou preencher com números

inteiros sequenciais quando for o caso.

39

Clicar em salvar.




Objetivo Verificar se as alterações feitas num item na página “Revisão” da


Requisitos

Especiais


Fluxo

Selecionar no menu o item “Gerenciar Revisão” que irá abrir a página

para alterar uma revisão.

Modificar todos os campos da página, bem como os campos utilizados

em tabelas auxiliares.


Verificar no banco de dados se o item foi atualizado corretamente.




apresenta erros.

Requisitos

Especiais


Fluxo

Selecionar no menu o item “Revisão” que irá abrir a página para

excluir uma revisão.

Clicar em Sim.

Verificar no banco de dados se o item foi deletado corretamente.


5.5 Casos de teste e Incidentes dos Testes

Serão descritos aqui cada um dos casos de teste listados no tópico

Procedimentos de Teste.

5.5.1 Página Gerenciar Checklist

GC_teste1

40

No teste foram digitados os valores de todos os campos de texto da página

(com o nome de seu respectivo outputtext), existiam 2 modalPanel (de pergunta e de

alternativa, sendo que foram salvas duas instâncias de cada no teste da checklist) contendo

itens que seriam armazenados em tabelas auxiliares, esses itens foram preenchidos da

mesma maneira, depois foi observado se eles eram salvos corretamente no banco de dados

nas suas respectivas tabelas.

No processo descrito não foram encontradas falhas que fizessem com que o

sistema apresentasse erro. Todos os valores foram salvos corretamente e em suas

respectivas tabelas.

O sistema não apresentou uma mensagem confirmando o sucesso da operação.

GC_teste2

No teste foram feitas alterações num item já cadastrado, as alterações foram

salvas com sucesso.

O sistema também não apresentou uma mensagem confirmando o sucesso da

operação.

GC_teste3

Nesse teste é mostrada uma mensagem para que o usuário tenha certeza da

exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente a checklist e cada

item que compõe seu relacionamento.


5.5.2 Página Responder Checklist

RC_ teste1

Neste teste foi selecionada uma checklist em um h:selectOneMenu que a

carrega em uma rich:dataTable. Após isso foram respondidas as questões discursivas e as

objetivas.




41


5.5.3 Página Visualizar Checklist

VC_teste1

Neste teste foi selecionada uma checklist em um h:selectOneMenu que carrega

em uma rich:dataTable suas instâncias de resposta. Após isso uma instância salva com

respostas objetivas e dissertativas foi selecionada, abrindo um modalPanel com as

respostas daquela instância específica.


sistema apresentasse erro. Todos os valores foram exibidos corretamente.

5.5.4 Página Histórico

GC_historico1

No teste foram selecionados: qual documento seria usado no histórico, o teste

referente àquele histórico, o autor e foram digitados os valores de todos os campos de texto

da página, não existiam modalPanel na página, depois foi observado se os dados foram

salvos corretamente no banco de dados.


sistema apresentasse erro. Todos os valores foram salvos corretamente. O sistema

apresentou uma mensagem confirmando o sucesso da operação.

GC_ historico2


salvas com sucesso.

O sistema também apresentou uma mensagem confirmando o sucesso da

operação.

GC_ historico3


exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente o relatório.

42

O sistema apresentou uma mensagem confirmando o sucesso da operação.

5.5.5 Página Gerenciar Revisão

GR_teste1

No teste foram digitados os valores de todos os campos de texto da página

(com o nome de seu respectivo outputtext ou com números sequenciais), depois foi

observado se eles eram salvos corretamente no banco de dados em sua respectiva tabela.




O sistema apresentou não apresentou uma mensagem confirmando o sucesso

da operação.

GR_teste2


salvas com sucesso, porém foi constatado que as listas de projeto e autor do formulário

foram duplicadas por não terem suas variáveis limpas antes de carregar novamente a lista.

O sistema também não apresentou uma mensagem confirmando o sucesso da

operação.

GR_teste3


exclusão, pois essa não pode ser desfeita. O sistema excluiu corretamente a revisão.


5.6 Relatório resumido dos testes

Este relatório foi realizado sobre cinco páginas que são composição do mesmo

sistema. Três destas páginas estão conectadas por compartilharem as mesmas tabelas,

outras duas páginas são independentes.

43

A página de revisão apresentou um erro que foi descrito no teste. Nenhuma das

páginas apresentou mensagens de sucesso ou falha da operação. Apesar disso os casos de

uso foram aprovados no teste, já que estas falhas não comprometem a funcionalidade do

sistema, porém elas devem ser solucionadas.

44

5 DESIGN DAS PÁGINAS No início do projeto foi definida a utilização do design padrão do Java Server

Faces para as páginas, porém no decorrer do projeto, com a entrada de um designer na

equipe, as páginas passaram a ser redesenhadas. Este processo ainda está em andamento e

as telas demonstradas abaixo indicam o novo padrão de design adotado em algumas

páginas do ADS.

Figura 5.1: Página inicial do ADS.

Figura 5.2: Novo padrão utilizado nas páginas internas do ADS.

45

6 CONSIDERAÇÕES FINAIS

No início do ano foi proposto um Ambiente de Desenvolvimento de Software

(ADS), sendo que apenas parte deste ambiente entrou no escopo deste trabalho como pode

ser visualizado no diagrama de caso de uso da figura 6.1. O escopo incluiu uma página

para cadastro de revisões de especificações de caso de uso, uma página para gerenciar o

histórico das fichas e uma página para gerenciar checklists, que serão utilizadas em outros

formulários.

Figura 6.1: Diagrama de Caso de Uso 1

46

Todas as atividades planejadas para a disciplina de estágio obrigatório foram

executadas dentro do cronograma planejado e nenhum imprevisto ocorreu no decorrer do

projeto. Os testes foram realizados e as falhas encontradas corrigidas adequadamente.

A ferramenta de Gerência de Testes em software está hospedada no servidor da

GAIA – Fábrica de Projetos de TIC e acessada em http://gaia.uel.br/ADSWeb/index.faces.

47

7 BIBLIOGRAFIA

[1] Siy, H.P.; Herbsleb, J.D.; Mockus, A.; Krishnan, M.; Tucker, G.T.; Making the

software factory work: lessons from a decade of experience. Software Metrics

Symposium, 2001. METRICS 2001. Proceedings. Seventh International , vol., no., pp.317-

326, 2001

[2] Sertic, H.; Filjar, R.; Pozgaj, Z.; Efficient software development organization based

on unified process. Electronics in Marine, 2004. Proceedings Elmar 2004. 46th

International Symposium , vol., no., pp. 390- 395, 16-18 June 2004.

[3] Pressman, R.; Engenharia de Software, 2006.

[4] Heijstek, W; Chaudron, M.R.V.; Evaluating RUP Software Development Processes

Through Visualization of Effort Distribution. 34th

Euromicro Conference Software

Engineering and Advanced Applications, Leiden Institute of Advanced Computer Science,

Foundations of Software Technology, Software Engineering Section, Leiden, The

Netherlands.Marques, H.M.; Silva, I.G.L.; [5] Booch, G.; Rumbaugh, J.; Jacobson, I.;

UML Guia do Usuário. Addison Wesley Longman Publishing Co., Inc. 2005.

[6] Ramos, R.T.; Maciel, T.M.M.; Fábricas de Software e o processo de

desenvolvimento segundo a experiência do Fábrica Um.

[7] Costa, B.G.S.; Andrade, C.A.R.; Júnior, C.R.S.; Borba, C.C.; Almeida, E.S.; Ferreira,

F.C.D.; Leite, L.E.C.; França, M.P.R; Vanderley, T.A.; Moura, V.B.X; Medeiros, V.N.;

Fábrica de Software: da Definição às Lições Aprendidas.

[8] Geary, D.; Horstmann, C.; Core JavaServer Faces. Alta Books, 2007.

[9] MyEclipse 8.0. Documentação e download disponíveis em

http://www.myeclipseide.com

[10] Enterprise JavaBeans 3.0. Documentação, download e especificações disponíveis em

http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html

[11] JBoss Application Server (JBoss AS). Documentação, download e especificações

disponíveis em http://www.jboss.org/jbossas/downloads/

[12] JDK 1.5. Documentação, download e especificações disponíveis em

http://java.sun.com/javase/downloads/index_jdk5.jsp

[13] Richfaces. Documentação, download de biliotecas, especificações e demonstrações

disponíveis em http://www.jboss.org/richfaces

http://www.myeclipseide.com/

http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html

http://www.jboss.org/jbossas/downloads/

http://java.sun.com/javase/downloads/index_jdk5.jsp

http://www.jboss.org/richfaces

48

[14] PostgreSQL. . Documentação, download, especificações e suporte disponíveis em

http://www.postgresql.org.br/

[15] Java Server Faces . Documentação, download, especificações e suporte disponíveis

em http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html

[16] Making the Software Factory Work: Lessons from a Decade of Experience,

http://mockus.us/papers/factory.pdf

[17] Kruchten, P.: Introdução ao RUP - Rational Unified Process. Ciência Moderna,

Rio de Janeiro (2003)

[18] Project Management Institute: A Guide to the Project Management Body of

Knowledge – PMBOK® Guide, Pennsylvania, USA (2008)

[19] Associação para Promoção da Excelência do Software Brasileiro: MPS.BR –

Guia Geral. Brasília (2009)

http://www.postgresql.org.br/

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html

http://mockus.us/papers/factory.pdf

humberto ferreira da luz junior software para … · 1 introduÇÃo ... expande os casos de uso...

Documents