tcc

5/14/2018 tcc - slidepdf.com

http://slidepdf.com/reader/full/tcc5571ffd849795991699e4084 1/159

CRISTIANO CAMPOS SILVAKLEYTON FARIAS DE SOUSA

SAMUEL DIAS DANTAS

METODESMETODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE

Monografia apresentada como requisito parcial paraaprovação na disciplina Trabalho de Conclusão de Curso– TCC, do Curso de Bacharelado em Sistemas deInformação da Faculdade Cenecista de Brasília, soborientação do Professor Esp. André Gustavo BastosLima.

CEILÂNDIA – DFNOVEMBRO DE 2006



FACULDADE CENECISTA DE BRASÍLIA – FACEB

Aprender e Conviver

Credenciada pela Portaria MEC n.º 998, de 14/07/2000.

CURSO DE SISTEMAS DE INFORMAÇÃOReconhecido pela Portaria do MEC N.º. 591, de 28 de fevereiro de 2005.

Trabalho de Conclusão de Curso – TCC

Área de Concentração: Engenharia de Software.

Alunos: Cristiano Campos Silva, Kleyton Farias de Sousa e Samuel Dias Dantas.

Monografia aprovada em:

Ceilândia, 11 de dezembro de 2006.

Banca Examinadora

_________________________________________________

Prof. Esp. André Gustavo Bastos Lima (Orientador)

_________________________________________________Prof. Esp. José Eduardo Amaral de Oliveira Teixeira

_________________________________________________Prof. MsC. Cláudio da Silva Lobo

_________________________________________________Prof. Esp. Luís Marcelo Morici Bisinotto



RESUMO

Este trabalho visa apresentar a METODES, metodologia de desenvolvimento de software,desenvolvida sob as considerações e o contexto acadêmico da Faculdade Cenecista de Brasília

(FACEB). Essa metodologia foi concebida para fornecer aos alunos do curso de Bachareladoem Sistemas de Informação da FACEB, uma opção viável para auxílio na realização doTrabalho de Conclusão de Curso que envolva o desenvolvimento de software. Tem-se comoresultado deste trabalho a descrição da METODES, que apresenta um conjunto de disciplinase atividades básicas para o desenvolvimento iterativo e incremental de software, adotando aUML como linguagem para modelagem de sistemas. Além disso, recomenda um conjunto deferramentas e modelos de artefatos para ser utilizado no processo de desenvolvimento. Parachegar a esses resultados, realizou-se pesquisa bibliográfica nas obras dos principais autoresda Engenharia de Software. Foi feita, também, uma comparação entre processos comerciaispara desenvolvimento de software, RUP, XP e PRÁXIS, além da observação empírica darealização trabalhos dos trabalhos dos alunos do segundo semestre de 2006.

Palavras-chave: Software. Processo de Desenvolvimento. Metodologia. Engenharia deSoftware. UML.



ABSTRACT

This paper presents METODES, a Software’s Development Methodology, designed to attendthe considerations and the academic context of the Faculdade Cenecista de Brasilia (FACEB).

This Methodology was conceived to help out the alumni of the Graduation in InformationalSystems of FACEB, an option that excells in auxiliaring the Final Work of is course thatenvolves the development of the Software. Regarding the results of this paper, the descriptionof METODES was obtained as a presentation of disciplines and basic activities to theinterative development and advance of this software, adopting an UML as a language tomodel the systems. Beyond that, it recommends a set of tools and artifact models to beutilized in the process of development. To get to these results, a bibliographic research with adeep look into the authors’s approaches in the field of Software Engineering. Also, acomparison was made between the commercial processes of the Software’s Development,RUP, XP and Praxis, moreover, the empiric observation of the alumni of the second semesterof 2006.

Key words: Software. Development Process. Methodology. Sofware Engineering. UML.



“Escrever software é como cultivar, caçar lobisomem ou abater

dinossauros num fosso de piche.”(Fred Brooks , 1995)



S U M Á R I O

1 INTRODUÇÃO ................................................................ ........................................................................ ........ 12

2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ....................................................................... 152.1 Definição....................................................................................................................................................152.2 Modelos de ciclo de vida...........................................................................................................................16

2.2.1 Modelo cascata............................. ........................................................................ ............................... 162.2.2 Modelo iterativo e incremental ........................................................................ ................................... 18

2.3 Software na visão do usuário...................................................................................................................192.4 A engenharia de software e sucesso no desenvolvimento ................................................................ ...... 202.5 Qualidade de software........................................................................ ...................................................... 212.6 Norma NBR ISO/IEC 12207....................................................................................................................222.7 Métricas e estimativas de software..........................................................................................................232.8 Processos comerciais de desenvolvimento de software..........................................................................25

2.8.1 RUP - Rational Unified Process............................................................. ............................................. 252.8.1.1 Características do RUP..................................................................................................................................252.8.1.2 Elementos do RUP ....................... .......................... ..................... ........................ ......................... .................262.8.1.3 O ciclo de vida RUP......................................................................................................................................262.8.1.4 Benefícios......................................................................................................................................................26

2.8.2 XP - Extreme Programming................ ........................................................................ ........................ 272.8.2.1 Processo do XP..............................................................................................................................................27

2.8.2.1.1 Metodologia de desenvolvimento no XP...............................................................................................272.8.2.1.2 Programação..........................................................................................................................................28

2.8.3 PRAXIS - Processo para Aplicativos Extensiveis e Interativos..........................................................292.9 As principais atividades de um processo de desenvolvimento .............................................................. 30

2.9.1 Gerenciamento do processo de desenvolvimento ................................................................ ............... 302.9.2 Levantamento de requisitos ................................................................ ................................................ 312.9.3 Análise ................................................................ ........................................................................ ........ 342.9.4 Projeto.................................................................................................................................................37

2.9.5 Implementação ........................................................................ ............................................................ 382.9.6 Testes ................................................................ ........................................................................ .......... 402.9.7 Implantação.........................................................................................................................................41

3 METODES - DISCIPLINAS................................................................ ........................................................... 43

3.1 Apresentação da METODES...................................................................................................................433.1.1 Perspectivas da METODES ................................................................ ................................................ 44

3.1.1.1 Perspectiva de disciplinas..............................................................................................................................443.1.1.2 Perspectiva de blocos ..................... ............................ ..................... ...................... ........................... .............453.1.1.3 Perspectiva de papéis.....................................................................................................................................46

3.2 Concepção..................................................................................................................................................483.2.1 Definição.............................................................................................................................................483.2.2 Atividades ........................................................................ ................................................................... 49

3.2.2.1 Contextualização do problema ........................ ......................... ..................... ......................... .......................503.2.2.1.1 Descrição do cliente..............................................................................................................................503.2.2.1.2 Descrição do negócio ..................... ....................... .......................... ..................... ........................ .........503.2.2.1.3 Descrição do problema..........................................................................................................................51

3.2.2.2 Levantamento de requisitos...........................................................................................................................523.2.2.3 Solução do problema.....................................................................................................................................55

3.2.3 Resultados da disciplina........................................................................ .............................................. 563.3 Gestão do projeto........ ........................................................................ ...................................................... 57

3.3.1 Definição.............................................................................................................................................573.3.2 Atividades ........................................................................ ................................................................... 58

3.3.2.1 Elaboração do plano de projeto ..................... ........................ ......................... ..................... ......................... .583.3.2.2 Solicitação de mudanças................................................................................................................................593.3.2.3 Controle de artefatos .......................... ....................... ..................... ........................... ...................... ..............603.3.2.4 Controle de requisitos....................................................................................................................................62

3.3.2.5 Controle de qualidade....................................................................................................................................623.3.3 Resultados da disciplina........................................................................ .............................................. 63

3.4 Detalhamento de requisitos........................ ........................................................................ ...................... 643.4.1 Definição.............................................................................................................................................64



3.4.2 Atividades ........................................................................ ................................................................... 673.4.2.1 Classificação e priorização dos requisitos ..................... ..................... ....................... .......................... ..........673.4.2.2 Detalhamento dos requisitos funcionais ........................... ...................... ..................... ............................ ......683.4.2.3 Prototipação...................................................................................................................................................693.4.2.4 Detalhamento dos requisitos não-funcionais ..................... ..................... ..................... ............................ ......71

3.4.2.5 Documentação dos requisitos........................................................................................................................713.4.2.6 Homologação e validação dos requisitos.......................................................................................................723.4.3 Resultados da disciplina........................................................................ .............................................. 72

3.5 Análise e projeto ................................................................ ....................................................................... 733.5.1 Definição.............................................................................................................................................733.5.2 Visões de análise.................................................................................................................................75

3.5.2.1 Visão da arquitetura.......................................................................................................................................753.5.2.2 Visão da infra-estrutura.................................................................................................................................763.5.2.3 Visão da segurança........................................................................................................................................76

3.5.3 Atividades ........................................................................ ................................................................... 763.5.3.1 Definição das visões de análise ..................... ........................ ......................... ..................... ......................... .77

3.5.3.1.1 Arquitetura de software.........................................................................................................................803.5.3.1.2 Arquitetura de comunicação..................................................................................................................803.5.3.1.3 Ativos físicos.........................................................................................................................................81

3.5.3.1.4 Softwares...............................................................................................................................................813.5.3.1.5 Classificação e proteção dos dados ..................... ............................ ..................... ...................... ...........813.5.3.1.6 Tráfego seguro das informações............................................................................................................823.5.3.1.7 Persistência e recuperação dos dados....................................................................................................823.5.3.1.8 Segurança física ..................... ........................... ...................... ...................... ........................... .............83

3.5.3.2 Detalhamento do modelo de classe................................................................................................................833.5.3.3 Projeto de interfaces gráficas.........................................................................................................................843.5.3.4 Realização de casos de usos .......................... ....................... ..................... ........................... ...................... ...853.5.3.5 Projeto de banco de dados ...................... ........................... ..................... ....................... .......................... ......863.5.3.6 Projeto de interfaces com sistemas................................................................................................................86

3.5.4 Resultados da disciplina........................................................................ .............................................. 863.6 Construção ................................................................ ........................................................................ ........ 87


3.6.2.1 Construção da interface gráfica ..................... ........................ ......................... ..................... ......................... .893.6.2.2 Codificação do elemento de software............................................................................................................903.6.2.3 Teste do elemento de software ........................ ......................... ..................... ......................... .......................903.6.2.4 Documentação do elemento de software ...................... ........................... ..................... ....................... ..........91

3.6.2.4.1 Documento de código de componente ..................... ..................... ............................ ..................... .......923.6.2.4.2 Manual do usuário.................................................................................................................................923.6.2.4.3 Manual de instalação do software ..................... ..................... .......................... ....................... ..............93

3.6.3 Resultados da disciplina........................................................................ .............................................. 933.7 Teste Funcional.........................................................................................................................................94


3.7.2.1 Elaboração do Plano de Realização do Teste Funcional................................................................................963.7.2.2 Definição de ambiente operacional para teste ..................... ........................ ......................... ..................... ....963.7.2.3 Executar Plano de Realização do Teste Funcional ..................... .......................... ....................... ..................96

3.7.2.4 Avaliação de resultados.................................................................................................................................973.7.3 Resultados da disciplina........................................................................ .............................................. 97

3.8 Implantação........................................ ........................................................................ ............................... 983.8.1 Apresentação................................................................ ....................................................................... 983.8.2 Atividades ........................................................................ ................................................................. 100

3.8.2.1 Plano de implantação...................................................................................................................................1003.8.2.2 Documentação do usuário ...................... ........................... ..................... ....................... .......................... ....1013.8.2.3 Implementação de arquitetura e segurança..................................................................................................1013.8.2.4 Implementação de infra-estrutura................................................................................................................1023.8.2.5 Instalação do software.................................................................................................................................1023.8.2.6 Treinamento do usuário...............................................................................................................................1033.8.2.7 Formalização do aceite do software ..................... .......................... ....................... ..................... .................104

3.8.3 Resultados da disciplina........................................................................ ............................................ 104

4 METODES - ARTEFATOS ................................................................ .......................................................... 106

5 METODES - PAPÉIS.....................................................................................................................................107



5.1 Descrição dos Papéis...............................................................................................................................1075.1.1 Gerente de relacionamento................... ........................................................................ ..................... 1075.1.2 Gerente de projeto........................................................................ ..................................................... 1085.1.3 Gerente de artefato............................................................................................................................1095.1.4 Gerente de mudanças ................................................................ ........................................................ 109

5.1.5 Gerente de qualidade........................... ........................................................................ ...................... 1115.1.6 Gerente de requisitos.........................................................................................................................1115.1.7 Analista de requisitos ................................................................ ........................................................ 1115.1.8 Prototipador ........................................................................ .............................................................. 1125.1.9 Projetista ........................................................................ ................................................................... 1125.1.10 Construtor ........................................................................ ............................................................... 1135.1.11 Documentador.................................................................................................................................1135.1.12 Analista de testes................................ ........................................................................ ..................... 1145.1.13 Analista de implantação..................................................................................................................114

6 METODES - FERRAMENTAS....................................................................................................................116

6.1 Recomendações da METODES.............................................................................................................1166.2 Modelagem de banco de dados ................................................................ .............................................. 116

6.2.1 Dbdesigner 4 ................................................................ ..................................................................... 1166.2.2 Mogwai ER-Designer ........................................................................ ............................................... 117

6.3 Administração de banco de dados.........................................................................................................1176.3.1 MySQL Administrator ........................................................................ .............................................. 1176.3.2 MySQL Query Browser ........................................................................ ............................................ 1186.3.3 PgAdmin ........................................................................ ................................................................... 1186.3.4 SQL Lite ........................................................................ ................................................................... 118

6.4 IDE (Integrated Development Environment) e Linguagens ............................................................... 1196.4.1 Eclipse................................ ........................................................................ ....................................... 1196.4.2 NetBeans...........................................................................................................................................1196.4.3 PHP 5 ................................................................ ........................................................................ ........ 1196.4.4 J2SE ........................................................................ ........................................................................ .. 1206.4.5 J2EE..................................................................................................................................................120

6.5 Servidores Web.......................................................................................................................................1216.5.1 Apache ................................................................ ........................................................................ ...... 1216.5.2 Tomcat ................................................................ ........................................................................ ...... 1216.5.3 IIS - Internet Information Services ................................................................ ................................... 121

6.6 Controle de Versão ........................................................................ ......................................................... 1226.6.1 CVS............................................ ........................................................................ ............................... 122

6.7 Gestão de projeto....................................................................................................................................1226.7.1 DotProject ........................................................................ ................................................................. 122

6.8 Modelagem visual (UML) ........................................................................ .............................................. 1226.8.1 Jude Community ........................................................................ ....................................................... 122

6.9 SGBD - Sistema gerenciador de banco de dados ........................................................................ ......... 1236.9.1 Mysql 5 ................................................................ ........................................................................ ..... 1236.9.2 Oracle Express Edition 10g................................................................... ............................................ 1236.9.3 PostgreeSQL ................................................................ ..................................................................... 1236.9.4 SQL Server 2005 Express Edition ................................................................ .................................... 124

6.10 Documentação.......................................................................................................................................1246.10.1 BrOffice ........................................................................ .................................................................. 124

7 GUIA WEB METODES ........................................................................ ........................................................ 125

8 CONSIDERAÇÕES FINAIS.........................................................................................................................129

9 REFERÊNCIAS ........................................................................ ..................................................................... 131

10 GLOSSÁRIO ................................................................ ........................................................................ ........ 132

11 APÊNDICE A – DVE – DOCUMENTO DE VISÃO E ESCOPO ........................................................... 134

12 APÊNDICE B - PRP - PLANILHA DE RESULTADOS DE PROJETO................................................137



13 APÊNDICE C - PCR - PLANILHA I DE CONTROLE DE REQUISITOS...........................................138

14 APÊNDICE D - PCR - PLANILHA II DE CONTROLE DE REQUISITOS.........................................139

15 APÊNDICE E - PCR – PLANILHA III DE CONTROLE DE REQUISITOS.......................................140

16 APÊNDICE F - PCR - PLANILHA IV DE CONTROLE DE REQUISITOS........................................ 141

17 APÊNDICE G - CUF – CASO DE USO FUNCIONAL............................................................................142

18 ANEXO A – TEXTO SOBRE ANÁLISE DE PONTO DE FUNÇÃO.....................................................143

19 ANEXO B – METODES ORIGINAL ........................................................................ ................................ 156



LISTA DE FIGURAS

2.1 CICLO DE VIDA CASCATA......................................................................................................................17

3.1 PERSPECTIVAS DE DISCIPLINAS DA METODES..............................................................................45

3.2 DIAGRAMA DE BLOCOS DA METODES........................................................................ ....................... 46

3.3 PERSPECTIVAS DE PAPÉIS – ESQUEMA DE INTERAÇÃO DOS PAPÉIS DA METODES ......... 47

3.4 FLUXO DE ATIVIDADES DA DISCIPLINA CONCEPÇÃO.................................................................49

3.5 FLUXO DE ATIVIDADES DA DISCIPLINA GESTÃO DE PROJETO................................................58

3.6 FLUXO DE ATIVIDADES DA DISCIPLINA DETALHAMENTO DE REQUISITOS........................ 66

3.7 FLUXO DE ATIVIDADES DA DISCIPLINA ANÁLISE E PROJETO ................................................. 77

3.8 FLUXO DE ATIVIDADES DA DISCIPLINA CONSTRUÇÃO .............................................................. 89

3.9 FLUXO DE ATIVIDADES DA DISCIPLINA TESTE FUNCIONAL.....................................................95

3.10 FLUXO DE ATIVIDADES DA DISCIPLINA IMPLANTAÇÃO..........................................................99

5.1 FLUXO DO TRATAMENTO DE SOLICITAÇÃO DE MUDANÇA....................................................110

7.1 PÁGINA INICIAL DO GUIA WEB DA METODES ................................................................ .............. 125

7.2 OPÇÃO DE MENU ‘VISÕES DA METODOLOGIA’ METODES....................................................... 126

7.3 OPÇÃO DE MENU ‘DISCIPLINAS’........................ ........................................................................ ........ 127

7.4 OPÇÃO DE MENU ‘PAPÉIS’ ........................................................................ ........................................... 128



LISTA DE TABELAS

4.1 TABELA DE ARTEFATOS.......................................................................................................................106



12

1 INTRODUÇÃO

Ao final do segundo semestre de 2005, surgiu a idéia deste trabalho - uma

metodologia de desenvolvimento de software sob o paradigma da orientação a objetos - como

tema para a realização do Trabalho de Conclusão de Curso (TCC). Naquela época, em

conversa com a nova coordenação do curso de Bacharelado em Sistemas de Informação, que

assumiria o próximo semestre, houve a sinalização de que a criação de uma metodologia de

desenvolvimento de software já figurava entre as propostas para o curso de Sistemas de

Informação. Nasce, então, a METODES, concebida a partir do esforço de um grupo de

professores da Faculdade Cenecista de Brasília (FACEB), inicialmente como um roteiro

metodológico estruturado que auxiliaria os alunos do curso de Sistemas de Informação na

realização dos projetos que envolveriam o desenvolvimento de software.

Sob essas circunstâncias, configurava-se a oportunidade de negócio que

justificaria o início do desenvolvimento da METODES. Esse desenvolvimento abordaria os

principais aspectos de uma metodologia propriamente dita, com a indicação de métodos,

técnicas e ferramentas adequadas para a realização de um projeto de software.

A METODES foi baseada em processos comerciais para desenvolvimento de

software, utilizados amplamente no mercado e fundamentada à luz dos conhecimentos da

Engenharia de Software. Além disso, a estrutura dessa metodologia foi adequada à realidadeacadêmica da FACEB e contextualizada levando em consideração as necessidades

enfrentadas pelos alunos do curso de Sistemas de Informação.

O curso de Sistemas de Informação da FACEB traz, em seu currículo, uma gama

de disciplinas voltadas para gestão e administração, que capacitam o aluno à gerência de

ambientes de TI (Tecnologias da Informação), bem como à gestão e empreendimento de



13

negócios. Oferece ainda um sólido conhecimento dos fundamentos da computação e das

tecnologias atuais de mercado.

São metas do curso de Sistemas de Informação da FACEB:

Estimular a criação e o aprimoramento da empregabilidade, à luz das demandasde mercado;

Desenvolver habilidades para aquisição e gerenciamento de serviços e recursosrelacionados à tecnologia de informação;

Capacitar para o desenvolvimento e evolução de sistemas informatizados, e infra-estrutura para uso em processos organizacionais, usando metodologias e técnicasconsagradas e de última geração.

(http://www.vqv.com.br/FACEB_j2ee14a/principal/cursos.jsp?idCurso=1&id=2)

Considerando as metas supracitadas e a oportunidade de negócio apresentada, este

trabalho aborda como tema o processo de desenvolvimento de software. O principal objetivo

é disponibilizar aos alunos da FACEB uma metodologia de desenvolvimento de software com

o intuito de facilitar o entendimento das atividades envolvidas no desenvolvimento de

projetos de software.

Os objetivos específicos deste trabalho são:

Desenvolver uma metodologia personalizada para desenvolvimento e gestão

de projetos de softwares que contemple:

modelos para documentação do produto e do projeto de software;

indicação de ferramentas para desenvolvimento do projeto.

Desenvolver o guia da metodologia em forma de páginas WEB.

A questão que propulsiona este trabalho é descobrir qual a importância da

utilização de uma metodologia de desenvolvimento aplicada à execução de um projeto de

software em ambiente acadêmico.

A justificativa dessa questão é a ênfase cada vez mais acentuada nos princípios e

técnicas da Engenharia de Software empregadas em projetos de desenvolvimento, face à

demanda por softwares de qualidade dentro de um quadro tecnológico cada vez mais

complexo e dinâmico.



14

Para alcançar os objetivos traçados por este trabalho foi feita uma pesquisa

bibliográfica com fim descritivo acerca dos conceitos envolvidos no tema deste trabalho e,

utilizou-se o curso de Sistemas de Informação da FACEB como referencial para

fundamentação do desenvolvimento da METODES.

Após a introdução, primeiro capítulo deste trabalho, apresenta-se o segundo

capítulo, a revisão da bibliografia que cerca a Engenharia de Software, incluindo as normas

que visam orientar de forma genérica, processos de desenvolvimento de produto de software.

A intenção desse capítulo é oferecer uma referência básica sobre os conceitos abordados neste

trabalho, oferecendo ao leitor conteúdo suficiente para a compreensão e análise do tema, além

de trazer também um comparativo das principais metodologias de desenvolvimento utilizadas

no mercado.

O terceiro capítulo apresenta a metodologia proposta, suas características e

particularidades. Especifica as disciplinas, atividades e tarefas que a compõe, inter-

relacionando-as dentro do seu fluxo de atividades.

O quarto capítulo mostra os artefatos, modelos de documentos gerados durante o

processo de desenvolvimento.

O quinto e o sexto capítulos são, respectivamente, a descrição dos papéis que

atuam no desenvolvimento do software e a indicação de um conjunto de ferramentas que pode

ser utilizado no projeto de software.O sexto capítulo apresenta a estrutura do guia da metodologia em forma de

páginas WEB. Além da apresentação do guia, abordam-se nesse capítulo detalhes de sua

construção, requisitos para seu funcionamento e operação.



15

2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

2.1 Definição

Um processo de desenvolvimento de software, ou simplesmente processo de

software, pode ser definido como um conjunto de disciplinas, atividades e tarefas necessárias

para a geração de um produto de software, abordando desde sua concepção até o seu estado

operacional entregue ao usuário.

Além do processo produtivo em si, um processo de desenvolvimento deve

contemplar todo o acompanhamento e controle da produção do software, abordando os

aspectos gerenciais que se fazem necessários no transcorrer do desenvolvimento. As

atividades de gerência de um projeto de software rezam pelo correto andamento das

atividades e tarefas executadas, bem como pela administração de falhas, imprevistos e

mudanças que possam ocorrer em qualquer uma das disciplinas do processo.

Pfleeger (2004) define processo como sendo “um série de etapas que envolvem

atividades, restrições e recursos para alcançar a saída desejada”. Sua abordagem sobre o

significado de processo é ampla e cita algumas características que, segundo ele, estão

presentes em todos os processos.

• O processo prescreve todas as suas principais atividades;• O processo utiliza recursos, está sujeito a um conjunto de restrições (como umcronograma) e gera produtos intermediários e finais;• O processo pode ser composto de subprocessos de algum modo relacionados. Elepode ser definido como uma hierarquia de processos, organizados de tal maneira quecada subprocesso tenha seu próprio modelo de processo;• Cada atividade do processo tem critérios de entrada e saída, de modo que seja possívelsaber quando o processo começa e quando termina;• As atividades são organizadas em uma seqüência, para que a ordem de execução deuma atividade em relação às outras seja clara;• Todo processo tem um conjunto de diretrizes que explicam os objetivos de cadaatividade. (PFLEEGER, 2004, pág. 36)



16

A forma como se encadeiam as etapas em um processo de desenvolvimento é

conhecida como modelo de processo ou modelo de ciclo de vida. Existe, porém, o ciclo de

vida do projeto de software e o ciclo de vida do produto de software. Este último estende-se

além do projeto e acompanha o produto de software da sua operação inicial, passando por

possíveis manutenções até quando o software entra em obsolescência. O ciclo de vida do

processo, por sua vez, é temporário e acaba ao final do projeto de desenvolvimento.

Há diversos modelos de ciclo de vida, no entanto, é consenso que não existe um

modelo único que atenda a todos os projetos. O ciclo de vida deve ser escolhido de acordo

com a natureza e características do projeto.

2.2 Modelos de ciclo de vida

Os modelos de ciclo de vida diferem um do outro na forma em que as diversas

etapas de processo de software se relacionam entre si.

2.2.1 Modelo cascata

Um dos modelos mais utilizados é o Cascata. Esse modelo se caracteriza por seu

encadeamento linear de suas etapas, de forma que, uma fase só tem início somente com otérmino da anterior. Eventualmente pode-se haver retro alimentação à etapa anterior, no

entanto, esse modelo mantém sua linearidade de ações do início ao fim.



17

2.1 CICLO DE VIDA CASCATA

Dentre as diversas razões que levam à crítica do modelo cascata citamos:

O modelo se aplica ao desenvolvimento de sistemas onde se têm os requisitos

bem definidos e estáveis, o que não corresponde à realidade prática de

desenvolver sistemas;

O modelo em cascata prescinde de artefatos ou produtos de uma fase anterior

para se dar início à fase posterior. Dessa forma, uma versão operacional do

software pode demorar muito. Eduardo Bezerra (2002) alerta que esse detalhe

pode ser um fator de perda de competitividade das empresas que utilizam o

modelo em cascata, pois o cliente pode não ter a “paciência” suficiente para

esperar uma primeira versão operacional do software. Além disso, pode haver

inevitáveis mudanças de requisito entre a solicitação do cliente até a primeira

versão do software, recaindo sobre o gerente de projeto uma carga de trabalho

maior.

No livro de Shari Lawrence Pfleeger (2004) diz que “o modelo impõe uma

estrutura de gerência de projeto ao desenvolvimento do sistema” (PFLEEGER

apud MCCRACKEN, JACKSON, 2004);



18

Nesse mesmo livro há referências de Curtis, Kranser, Shen e Iscoe (1987) que

dizem que “o principal defeito do modelo cascata é a falha em tratar o

desenvolvimento de software como um processo de solução de problemas”.

Pfleeger argumenta que o modelo é derivado de um processo de fabricação de

hardware onde uma vez fabricado o produto ele é reproduzido várias vezes e,

segundo o autor, o desenvolvimento de software é um processo de criação,

não de fabricação, e evolui à medida que o problema é melhor compreendido

(iterações).

Em um artigo no sítio http://www.internativa.com.br/artigo_gestao.html, Marcelo

Jacintho explica:

“O ciclo de vida a ser adotado será uma das tônicas agora, pois dependendo dascaracterísticas do projeto, do cliente e da própria equipe, alguns modelos de ciclo devida não são recomendáveis. Ainda, o famigerado e tão perseguido ciclo de vidaCascata, se estiver com grandes chances de ser escolhido, precisará sempre passar poruma crítica muito severa, haja vista que as estatísticas de desempenho da indústriamundial de T.I., largamente divulgadas pelo Standish Group, apontam para um sucessomenor que 30% no resultado dos projetos, e, pesquisas correlatas apontam que autilização de um ciclo de vida que não permite uma antecipação de riscos, nem testes deparciais do sistema em desenvolvimento, e que ignora a natureza mutável dosrequisitos, está ligada a este ciclo e a este resultado. É claro que não podemos esquecerque é possível ser bem sucedido utilizando o Cascata, porém o mercado vemsinalizando muito forte para a utilização de modelos diferentes.”

2.2.2 Modelo iterativo e incremental

O modelo iterativo e incremental é uma alternativa para solução de problemas

enfrentado no modelo cascata. Nesse modelo, considera-se o desenvolvimento do software em

ciclos iterativos onde uma pequena porção dos requisitos passa por todas as etapas de

desenvolvimento como em um modelo cascata. Ao final de cada ciclo de iteração têm-se uma

nova versão do software, a qual será incrementada a cada novo ciclo que ocorrer.

Ao final de cada ciclo de iteração pode-se ter uma versão do software. Isso reduz

a ansiedade e a expectativa do usuário em relação ao software. Além disso, o modelo



19

possibilita que o software seja desenvolvido em módulos de acordo com a necessidade e

características do projeto.

Embora pareça que o modelo imprima uma forma mais ágil de desenvolvimento,

um planejamento formal não é desprezado. A idéia das iterações desse modelo é permitir que

o sistema seja melhor compreendido e refinado a cada etapa. Dessa forma, a qualidade do

software pode ser provida gradualmente à medida que seu desenvolvimento evolui.

2.3 Software na visão do usuário

Segundo o Dicionário Aurélio Eletrônico, 1999, software “é o conjunto dos

componentes que não fazem parte do equipamento físico propriamente dito e que incluem as

instruções e programas (e os dados a eles associados) empregados durante a utilização do

sistema.”. Do ponto de vista da Engenharia de Software, “o conceito de software compreende

todo o conjunto de programas, procedimentos, dados e documentação associados a um

sistema de computador, e não somente ao programa em si.” (PFLEEGER, 2004).

Não obstante aos conceitos aqui apresentados, o software é popularmente

conhecido como os programas que utilizamos em um computador e que nos ajuda a realizar

de forma mais fácil e produtiva nosso trabalho. Acontece que o software também é visto,

muitas vezes, como empecilho à produtividade por trazer mais problemas do que solução aousuário. Geralmente, isso é fruto da má “qualidade” do software ou, simplesmente, pelo fato

de o software não estar atendendo ao usuário de forma satisfatória.

O importante em tudo isso é que a satisfação do usuário do software é um fator

crítico para o seu sucesso, além do atendimento eficaz ao propósito essencial para o qual ele

foi criado, sem isso não haveria razão para a sua existência. Neste último pensamento estamos



20

elevando o conceito de software a um nível superior, que é o de sistema, algo mais complexo

e que pode ser composto de vários softwares.

Bezerra (2002) salienta o surgimento dos chamados sistemas de informação,

adventos da crescente importância dada à informação, destacada por muitos como o bem mais

valioso da humanidade atualmente. Ele afirma que um sistema de informação é muito mais

que programas de computador, é o conjunto das pessoas, das tecnologias, dos sistemas e

dados, todos, integrados de forma intrínseca para auxiliar a inteligência das organizações nas

tomadas de decisões estratégicas. Diz ainda que, em um sistema de informação, um dos seus

componentes é o sistema de software, que “compreende os módulos funcionais

computadorizados que interagem entre si para proporcionar ao(s) usuário(s) do sistema a

automatização de diversas tarefas” (op. cit.).

Na visão da maioria dos usuários não há distinção entre sistemas de informação,

sistemas de software ou programas de computadores. Sua visão é condicionada às

experiências e resultados que obtém com a utilização do software. Pare ele é importante que o

software atenda as suas necessidades e, por conseqüência, a necessidade da organização que

tem o software ou sistema implantado. Isso é uma das premissas de qualidade de software,

que será discutida nesse capítulo mais adiante, e onde podemos contextualizar a Engenharia

de Software como fator crítico de sucesso do produto de software.

2.4 A engenharia de software e sucesso no desenvolvimento

“A engenharia de software é a criação e a utilização de sólidos princípios de

engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe

eficientemente em máquinas reais”. (PRESSMAN, 2002)



21

De acordo com Peters e Pedrycz (2001), “uma abordagem de engenharia à

engenharia de software caracteriza-se por um desenvolvimento de software prático, ordenado

e medido”. Essa afirmativa ressalta a importância que os métodos, processos, técnicas e

ferramentas da engenharia de software têm no desenvolvimento de software. A utilização de

uma sistemática consistente para conduzir esse desenvolvimento faz com que tenhamos

resultados práticos e plausíveis, do ponto de vista de custos e prazos, bastantes positivos de

projetos de software.

A importância, então, da engenharia de software para o sucesso no

desenvolvimento de sistemas está na aplicação das práticas da engenharia para garantir que

um projeto de software seja executado de acordo com alguns princípios básicos que levam à

qualidade final do produto. Pfleeger (2002) afirma que “escrever software é uma arte e uma

ciência,” ressaltando a racionalidade dos mecanismos computacionais e suas teorias e, por

outro lado, a necessidade do envolvimento de arte, originalidade e técnica para escrever

programas.

2.5 Qualidade de software

Qualidade de Software: A totalidade das características de um produto de

software, que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas(NBR 13596, 1996).

Avaliar produtos de software constitui uma atividade bastante complexa em que a

demanda está crescendo significativamente devido fatores externos como a globalização que

afeta diretamente grandes empresas e futuras empresas que pensam em crescer, sendo assim

os usuários exigem cada vez mais qualidade, eficiência, eficácia, dentre outros requisitos que

podem influenciar na aquisição de software. Por um lado, surge a oportunidade de se



22

desenvolver metodologia para avaliar a qualidade de produto de software com base em

requisitos de qualidade reconhecidos internacionalmente, dando subsídios para os clientes

(compradores de tecnologia) que adquirirem produtos com qualidade. Por outro lado, os

produtores de software têm a possibilidade de fornecer produtos de maior qualidade e

podendo crescer no mercado competitivo.

A avaliação de produto de software tem sido uma das formas empregadas por

organizações que produzem ou adquirem software para obtenção de maior qualidade nesses

produtos, sejam esses softwares completos, ou módulos a serem integrados a um sistema

computacional mais amplo.

Os benefícios de avaliação de software servem para:

o desenvolvedor utilizar os resultados da avaliação de seu produto para

identificar ações não desejadas como os bugs, com o objetivo de melhorá-lo,

ou de tomar decisões sobre a estratégia de evolução do produto podendo tomar

como parâmetros para outras áreas em que esse software poderá atuar;

o fornecedor de software demonstrar confiabilidade no seu produto, sob tudo

agregar valores em relatório de Avaliação com finalidades comerciais;

no futuro cliente poderá conhecer o nível de qualidade do software para ajudá-

lo na tomada de decisão de aquisição deste produto.

2.6 Norma NBR ISO/IEC 12207

Advindo do fato de que a qualidade do produto de software está diretamente

relacionada à qualidade do processo de software, diversos modelos e normas para a definição

e melhoria de processos de software têm sido desenvolvidos. Modelos como o CMM



23

(Capability Maturity Model for Software) são cada vez mais reconhecidos e utilizados, tanto

no Brasil como em todo o mundo, destacando-se na fabricação de software de qualidade.

As normas estabelecem o que deve ser feito e não como deve ser implementado.

Ou seja, estabelecem quais são os processos que devem estar presentes para garantir o sucesso

dos projetos, mas não oferecem orientações sobre qual modelo de ciclo de vida, ferramenta,

linguagem ou ambiente deve ser utilizado para o desenvolvimento do software.

Percebemos que na elaboração de um software a equipe desenvolvimento se

depara com diversos paradigmas, métodos e ferramentas de desenvolvimento pregando ser a

solução definitiva para os problemas dos projetos de software. No decorrer dos anos 90,

estiveram em pauta as metodologias orientadas a objetos introduzidas isoladamente por cada

um de seus autores. No final dos anos 90, três deles (Jacobson, Booch e Rumbaugh) se

reuniram para desenvolver o Unified Software Development Process (UP). Posteriormente, o

UP foi instanciado e especificado pela Rational Software Corporation, resultando no Rational

Unified Process (RUP).

2.7 Métricas e estimativas de software

Segundo Ian Sommerville (2003), métricas são as medições que precisam ser

coletadas para ajudar a responder as questões e para confirmar se as melhorias de processoalcançaram a meta desejada ou não.

Métricas de software referem-se a uma ampla variedade de medidas de software

de computador, ou seja, medidas do resultado do desenvolvimento de software, medidas de

tamanho do software são frequentemente utilizadas tanto na concepção de projetistas quanto

na de usuários, pois essa medida é um bom indicador de grandeza de um sistema de software,



24

envolvendo recursos como os requisitos de memória, o esforço de manutenção e o tempo de

desenvolvimento.

“O software é medido por muitas razões: (1) indicar a qualidade do produto; (2)avaliar a produtividade das pessoas que produzem o produto; (3) avaliar osbenefícios (em termo de produtividade e qualidade) derivados de novos métodos eferramentas de software; (4) formar uma linha básica para estimativas; (5) ajudar a

justificar os pedidos de novas ferramentas ou treinamento adicional” (PRESSMAN,1995, pág. 60.).

“As medidas de software são mapeamentos dos objetos nas entidades de software,

na forma de números ou símbolos, que servem para quantificar um atributo de software”

(PETERS, PEDRYCZ, 2001).

Há dois tipos de medidas que são bastante utilizadas para a realização de

estimativas de software:

Medidas relacionadas a tamanho: essas medidas são relacionadas aotamanho de alguma saída de uma atividade. Dessas, a mais comum é onúmero de linhas de código-fonte fornecidas. Outras medidas que podemser utilizadas são o número de instruções de código-objeto entregues ou onúmero de páginas de documentação do sistema;

Medidas relacionadas a funções: essas medidas são relacionadas à

funcionalidade geral do software entregue. A produtividade é expressa emtermos da funcionalidade útil produzida em um tempo determinado. Ospontos de função e os pontos de objeto são as melhores medidasconhecidas desse tipo. (SOMMERVILLE, 2003).

As estimativas de software são feitas para definir o valor total a ser gasto no

desenvolvimento de um software e para passar o orçamento ao cliente, sendo que essas

estimativas podem ser reajustadas no decorrer do desenvolvimento do software permitindo o

uso eficaz dos recursos disponibilizados.

Nenhuma estimativa é exata, no entanto elas são bastante consistentes e

combinam dados sobre o usuário, sobre o desenvolvedor e sobre o plano de desenvolvimento

do projeto a ser implantado com os dados do domínio de informação exigidos para a

contagem de pontos - por - função.

“A estimativa oferece ao planejador as informações necessárias para concluir as

atividades de planejamento do software” (PRESSMAN, 1995).



25

2.8 Processos comerciais de desenvolvimento de software

2.8.1 RUP - Rational Unified Process

O RUP é um processo de engenharia de software bem definido e bem estruturado

que define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando

fazê-las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto

RUP, articulando claramente os marcos essenciais e pontos de decisão; tornando-se uma

maneira de desenvolvimento de software que é iterativa, centrada à arquitetura e guiada por

casos de uso.

O RUP utiliza a Linguagem Unificada de Modelagem (UML) para especificar,

modelar e documentar artefatos. A UML é um padrão definido pelo OMG (Object

Management Group) e ter se tornado o padrão empresarial para a modelagem orientada a

objetos.

2.8.1.1 Características do RUP

Existem alguns princípios que podem caracterizar e diferenciar o RUP de outros

métodos iterativos:

Atacar os riscos cedo e continuamente;

Certificar-se de entregar algo de valor ao cliente;

Focar no software executável;

Acomodar mudanças cedo;

Liberar um executável da arquitetura cedo;

Construir o sistema com componentes;



26

Trabalhar junto como um time;

Fazer da qualidade um estilo de vida, não algo para depois.

2.8.1.2 Elementos do RUP

O RUP possui cinco elementos principais:

Papéis

Atividades

Artefatos

Fluxos de trabalho

Disciplinas

2.8.1.3 O ciclo de vida RUP

O ciclo de desenvolvimento no RUP possui quatro fases:

Concepção

Elaboração

Construção

Transição.

2.8.1.4 Benefícios

Com a utilização de uma metodologia de desenvolvimento de software como o

RUP, é possível obter:

Qualidade de software;



27

Produtividade no desenvolvimento, operação e manutenção de software;

Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade

desejados;

Estimativa de prazos e custos com maior precisão.

2.8.2 XP - Extreme Programming

Extreme Programming usa times integrados de programadores, clientes, e

gerentes para desenvolver software de alta qualidade em velocidade alta.

Reúne também um conjunto de práticas de desenvolvimento de software já

testadas, que estimuladas a sinergia entre elas gerarão vastas melhorias em produtividade

global e satisfação do cliente.

Cada prática tem sua função para manter o custo de mudança baixo e estão

divididas nas categorias da seguinte forma:

Programming – Simple design (projeto simples), testing (testes), refactoring

(reconstrução), coding standars (código padrão);

Team – Collective ownership (código coletivo), continuous integration

(integração continua), metaphor (metáfora), pair programming (programação

em par), small releases (versões pequenas);

Process – On-site customer (no local do cliente), testing (testes), small

releases (versões pequenas), planning game (planejamento do jogo).

2.8.2.1 Processo do XP

2.8.2.1.1 Metodologia de desenvolvimento no XP



28

Planning game - Define incrementalmente os requisitos do sistema e a produz

a criação das user stories (estorias de uso)

Client on-site – através do analista de negocio faze-se a interação junto ao

cliente

Small realeases – são realeases para avaliação e aprovação junto cliente

2.8.2.1.2 Programação

Algumas técnicas aplicadas na metodologia XP:

Pair programming – onde a codificação é efetuada em dupla

Coding standards - padronização do código se torna necessária, pois ocorre o

revezamento dos desenvolvedores do código. Ou seja, se escrito por um, esse

código deverá está claro suficiente para a perfeita compreensão dos demais

desenvolvedores. Outro ponto marcante é quando o desenvolvimento dos

scripts de testes ou testes de unidade são alterados e executados, uma nova

implementação é colocada em prática.

Simple design é a codificação apenas das funcionalidades essenciais ao

sistema, desta forma foi agregado simplicidade ao projeto do sistema,

agilidade e um maior custo/benefício, tendo como base que os esforços de

tempo necessário para o desenvolvimento e teste foram praticamente os

mesmos e que produziram um resultado final.



29

2.8.3 PRAXIS - Processo para Aplicativos Extensiveis e Interativos

O PRAXIS é um processo que foi desenvolvido por Wilson de Pádua Paula Filho

e publicado no livro Engenharia de Software: Fundamentos, Métodos e Padrões.

O PRAXIS, que já está em sua segunda versão, possui um ciclo de vida composto

por fases, dividida em iterações. Cada iteração produz um conjunto precisamente definido de

documentos, modelos e relatórios, que são os artefatos do processo:

Documentos são os artefatos produzidos por ferramentas de processamento de

texto ou hipertexto, para fins de documentação dos principais aspectos de

engenharia de um projeto, incluindo aspectos selecionados dos modelos e

aspectos não modeláveis. São, tipicamente, os artefatos entregues aos clientes;

Modelos são os artefatos de uma ferramenta técnica específica (tais como

planilhas, ferramentas de modelagem orientada a objetos e de

desenvolvimento), produzido e usado nas atividades de um dos fluxos do

processo;

Relatórios são artefatos que relatam as conclusões de determinadas atividades

do projeto;

Na construção desses artefatos, o usuário do processo é guiado por padrões e

auxiliado pelos gabaritos de documentos e por exemplos, constantes do

material de apoio.

O PRAXIS inclui um conjunto de conceitos, técnicas, fluxos de trabalho e sub-

processos que cobrem todos os aspectos dos projetos típicos de software e são baseados em

métodos de aceitação consagrados pela indústria de software.

O PRAXIS é baseado na tecnologia orientada a objetos; sua notação de análise e

desenho é a UML (Unified Modeling Language), adotada como padrão pelo consórcio OMG,



30

que reúne centenas dos principais produtores mundiais de software. Os padrões do PRAXIS

estão em conformidade com os padrões de engenharia de software do IEEE, os mais

abrangentes e respeitados da área.

2.9 As principais atividades de um processo de desenvolvimento

2.9.1 Gerenciamento do processo de desenvolvimento

O gerenciamento do processo de desenvolvimento de software é bem amplo, pois

diz respeito a toda a parte de planejamento e programação do projeto, gerenciamento de

riscos, gestão de pessoal, estimativa de custos de software e gerenciamento de qualidade de

software. Essa atividade, durante todo o desenvolvimento do software, estará em execução,

analisando e revisando os processos e as etapas desenvolvidas e comparando o tempo e o

custo do desenvolvimento real do projeto de acordo com que foi planejado.

O desenvolvedor de software deve se reunir com o cliente para a definição do

escopo do projeto para juntos chegarem a um consenso sobre o que será desenvolvido. A

partir desse escopo serão definidas diretrizes e os requisitos do projeto. Ambos podem sofrer

alteração ao longo do projeto, pois podem tornar-se inadequados ou ficarem fora de contexto

original definido.“A gerência de projetos é a primeira camada do processo de engenharia de

software, nós a chamamos camada, em vez de etapa ou atividade, porque ela abrange todo o

processo de desenvolvimento, do começo ao fim” (PRESSMAN, 1995). Para que um projeto

de software seja bem desenvolvido, torna-se necessário compreender todo o escopo do

projeto, analisando as tarefas a serem executadas, as referências a serem seguidas e os custos



31

liberados para cada etapa do projeto, destinando um tempo necessário para o desenvolvimento

do projeto.

“O gerente de projeto geralmente é o responsável pela preparação dosrelatórios sobre o projeto, tanto para a organização do cliente como para asorganizações dos fornecedores. Os gerentes de projeto devem redigirdocumentos concisos e coerentes, que resumam as informaçõesfundamentais a partir de relatórios de projeto detalhados. Eles devem sercapazes de apresentar essas informações durante as revisões de andamento.Consequentemente, a capacidade de se comunicar de modo eficaz, tantoverbalmente como por escrito, é uma habilidade essencial para o gerente deprojeto” (SOMMERVILLE, 2003).

Segundo Pfleeger (2004) é importante que a gerência do projeto desenvolva um

cronograma que descreva o ciclo de desenvolvimento de software para um projeto específico,

enumerando as etapas ou estágios, dividindo cada um deles em tarefas ou atividades a serem

realizadas. Assim o desenvolvimento e o acompanhamento das atividades ficam facilitados

para os gerentes do projeto, fornecendo diretrizes e metas para a equipe de desenvolvimento

de software, que por sua vez buscará cumprir as estimativas de custo e prazo definidos

durante o desenvolvimento do planejamento do software. Vale lembrar que é muitoimportante que os gerentes do projeto se reúnam com a equipe de desenvolvimento para

discutirem e avaliarem o do andamento geral do projeto.

2.9.2 Levantamento de requisitos

“A atividade de levantamento de requisitos corresponde à etapa de compreensão

do problema aplicada ao desenvolvimento de software” (BEZERRA, 2002). Nessa atividade é

feito o levantamento de requisitos de software a serem desenvolvidos, a equipe de

desenvolvimento de software levantara e analisara esses requisitos compreendendo as

necessidades dos clientes com a intenção de solucionar os problemas por eles descritos. Nessa

atividade é importante que tanto a equipe de desenvolvimento quanto os clientes tenham uma



32

mesma visão dos problemas constatados, pois isso ajudará bastante no desenvolvimento do

software.

“O levantamento e a análise dos requisitos envolve muito mais do que apenas

descrever e registrar os requisitos descritos pelo cliente, significa dizer que se deve identificar

requisitos, nos quais os desenvolvedores e o cliente possam concordar e nos quais possam ser

testados” (PFLEEGER, 2004).

“O fluxo de Requisitos reúne as atividades que visam a obter o enunciado

completo, claro e preciso dos requisitos de um produto de software” (PÁDUA, 2003). Isso

significa dizer que os requisitos a serem desenvolvidos devem ser os mais explícitos possíveis

e não podem ser ambíguos, além disso, precisam ser passíveis de implementação, seguros,

confiáveis, e fáceis de serem testados, tudo isso para que eles sejam requisitos de alta

qualidade para o projeto de software.

Tanto Wilson de Pádua quanto Pfleeger dão ênfase maior a solução do problema

do cliente e a implementação dos requisitos levantados, sugerindo que todos os requisitos

atendam a uma determinada funcionalidade, atentando para as reais necessidades encontradas.

É importante lembrar que é necessário fazer uma triagem entre esses requisitos, priorizando

aqueles que são importantes, pois alguns são essenciais, outros desejáveis e outros não serão

contemplados para a implementação.

Dentro da atividade de requisitos serão gerados dois documentos: o documentode definição dos requisitos, que gera uma listagem completa de tudo que o cliente espera que

o sistema proposto faça; e o documento de especificação dos requisitos, que descreve os

requisitos em uma linguagem mais técnica apropriada para o desenvolvimento do sistema.

Esses documentos representarão os desejos do cliente em relação àquilo que o software deve

possuir como funcionalidades.

Os requisitos levantados podem ser divididos basicamente em três tipos:



33

Requisitos funcionais: definem as funcionalidades do sistema, descrevendo

uma interação entre o sistema e o seu ambiente verificando o seu

funcionamento. Os requisitos funcionais descrevem detalhadamente as

funções do sistema, suas entradas, saídas, e exceções, possibilitando que eles

possam ser escritos em diferentes níveis de detalhes do sistema;

Requisitos não-funcionais: “são aqueles que declaram as características de

qualidade que o sistema deve possuir e que estão relacionadas as suas

funcionalidades.” (BEZERRA, 2002). Requisitos não-funcionais são aqueles

que não dizem respeito diretamente às funcionalidades fornecidas pelo

sistema, mas dizem respeito ao sistema como um todo, de acordo com as

necessidades do cliente e conforme as restrições de orçamento, políticas

organizacionais, ou devido a fatores externos;

Restrições: segundo Bezerra (2002) as restrições definem a adequação a

custos e prazos, a plataforma tecnológica, aspectos, licenciamento, limitações

sobre a interface com o usuário, componentes de hardware e software a serem

adquiridos.

Depois de todos os requisitos serem avaliados, analisados e tratados, eles estarão

prontos para serem utilizados ao longo do desenvolvimento do sistema, servindo como

fundamento a todas as etapas do processo de desenvolvimento. Todos os requisitosrepresentarão o entendimento entre os desenvolvedores e o cliente, sendo que esses requisitos

devem ser descritos de forma clara para que todos possam entender, tanto os desenvolvedores

quanto pessoas leigas no assunto. Sempre que houver a necessidade de alteração em algum

requisito faz-se necessário reavaliar todos os processos do sistema e verificar se a alteração é

viável ou onerosa ao sistema, tanto em serviço quanto em finanças, e se o cliente aprovará

determinadas mudanças. Em um estudo baseado em 6.700 sistemas feito e 1997, Carper Jones



34

mostrou que os custos resultantes de má realização desta etapa de entendimento podem ser

duzentas vezes maiores que o realmente necessário (BEZERRA apud JONES, 2005).

Isso mostra porque esta atividade do processo de software se torna a mais

importante, pois aqui se cria uma base solidificada estabelecendo o escopo do sistema a ser

desenvolvido. Dessa forma, em caso de mudança de escopo, tanto o cliente quanto os

desenvolvedores têm um parâmetro para decidirem o quanto de tempo e de recursos serão

utilizados.

2.9.3 Análise

Na análise de desenvolvimento de um software busca atingir uma transformação

de todo os conceitos que foram expostos para uma visão mais ampla, Wilson de Pádua de

Paula Filho (2003), ressalta-se a importância de modelar os conceitos presentes no domínio

do problema, sendo assim consegue-se verificar a qualidade dos requisitos e juntamente com

os seus respectivos fluxos e os projetistas atingem com maior exatidão o detalhamento de

cada requisito visto na fase de levantamento de requisito e sua real finalidade a que foi

proposto.

O autor cita a importância em detalhar o modelo de análise para servir como

base para a fase de projeto que é a disciplina posterior. Análise e projeto de softwarepoderiam se restringir a uma única fase, já que a diferença visível é o nível de detalhamento

que se estabelece entre as duas etapas do processo de desenvolvimento.

Pfleeger (2004) esclarece os conceitos relativos a um projeto orientado a objetos

como classes, instâncias, comportamentos, herança, polimorfismo, entre outros, estabelecendo

uma base de como é o desenvolvimento de um projeto orientado a objeto. Indiferente do ciclo

de vida utilizado requer-se etapas bem planejadas e estruturadas para cada atividade abordada,



35

como descrever os requisitos, projetar o sistema, projetar os programas, codificar e realizar

testes.

Pfleeger ressalta a possibilidade de a análise dos requisitos serem quase sempre

realizada na linguagem do usuário, no estudo de conceitos e situações do domínio do

problema. Para isso a técnica de casos de usos torna-se extremamente importante, por

descrever as funcionalidades especificas do sistema e modelar de forma apropriada para o

entendimento de ambas as partes. Os casos de uso auxiliam a comunicação entre o cliente e a

equipe de desenvolvimento de software, certificando-se que as funções desejadas pelo cliente

serão realizadas.

Os casos de usos descrevem um cenário de como os atores (usuário, dispositivos e

sistemas externos) irão interagir com o sistema, identificando cada evento de um respectivo

cenário. Por essa razão, os casos de usos têm sido adotados por grande parte da comunidade

de adeptos da orientação a objetos, como suplemento dos meios mais formais de modelagem

de objetos, durante a análise do sistema.

Ian Sommerville (2003) descreve que análise orientada a objetos se dedica a

desenvolver um modelo orientado a objetos do domínio da aplicação e os objetos

identificados refletem entidades e operações que estão associadas com o problema. Essa

abordagem visa aproveitar algumas aplicações e experiências em projetos de sistemas

desenvolvidos e os tipos de métodos utilizados, demonstrando uma forma de extrair os dadosque servirão para um projeto orientado a objetos, necessitando uma visão abrangente de como

as atividades são executadas pela equipe de projeto.

Alguns pontos importantes a observar para identificar as classes de objetos são os

seguintes:

Utilizar uma análise gramatical facilita descrição, conseguindo agir de forma

clara e natural sem dificultar o entendimento do sistema projetado onde os



36

objetos e atributos são nomes e operações de serviços são verbos

(SOMMERVILLE, 2003).

Demonstrar as entidades tangíveis que farão parte do domínio da aplicação,

como exemplo, as funções exercidas por funcionários: gerente, administrador,

encarregado; e os eventos: solicitações ou requisições. (SOMMERVILLE,

2003).

Buscar o aprimoramento do projetista para que compreenda a visão geral do

sistema, podendo assim atingir o entendimento das operações executadas pelo

sistema. Os participantes que desempenham papéis significativos são

reconhecidos como objetos (SOMMERVILLE, 2003).

Dividir os cenários em pedaços menores para proceder a análise mais apurada,

facilitando a absorção do problema. À medida que se procede a buscar a

diminuir o escopo, consegue-se estudar cada cenário e a equipe responsável

pela análise visualiza com maior facilidade os objetos, conseguindo identificar

os atributos e operações que são necessárias por esses objetos. Exemplo é o

“método de análise, chamado de cartões CRC, em que analistas e projetistas

assume o papel de objetos é eficaz no apoio a essa abordagem baseada em

cenários” (SOMMERVILLE apud BECK, CUNNINGHAM, 2003).

Um artifício bastante usado por diversos autores é a UML, principalmente em

projetos orientados a objetos. A UML é uma linguagem de modelagem unificada para a

elaboração da estrutura de projetos de software. É empregada na visualização, na

especificação, na construção e na documentação de artefatos que façam uso de sistemas

complexos de software. Entretanto a UML poder ser aplicada em outros projetos,

independente serem projetos para desenvolvimento de software.



37

2.9.4 Projeto

Segundo Wilson de Pádua Paula Filho (2003), projeto tem como objetivo definir

uma estrutura implementável para um produto de software que atenda os requisitos

especificados para ele.

Pádua descreve alguns objetivos que essa disciplina tem que obedecer como:

Os aspectos relativos à análise de um projeto e seus requisitos abordados: em

especial observa-se um destaque aos atendimentos de casos de usos, através

das classes as quais foram definidas pelos analistas, sendo que no projeto o

detalhamento é superior ao da análise, que apenas visualiza as prováveis

classes e o projeto descreve a composição das classes, facilitando para os

construtores dos códigos, onde abranger um nível mais técnico torna-se

necessário.

Os requisitos não funcionais captados e verificados: esses manterão a

exigência na qualidade para o bom desenvolvimento do projeto de software.

Definição clara e fiel das interfaces dos componentes do produto: visa

caracterizar o ambiente de implementação e um estudo da usabilidade, isso é

claro diante das ferramentas propostas para a solução.

Documentar todas as alterações efetuadas de maneira que as informaçõesfluam sem dúvidas para os responsáveis pela implementação e

manutenibilidade do produto, facilitando a continuidade do negócio quando

houver uma solicitação de mudança em uma funcionalidade do sistema ou de

um módulo específico.

Reutilização de componentes, estruturas, mecanismos e demais artefatos que

possam aumentar a produtividade e confiabilidade da equipe desenvolvedora.



38

Pfleeger (2004) define o projeto do sistema como uma abstração de alto nível do

que eventualmente será o projeto do programa, estabelece dados essenciais para a

implementação que os projetistas devem abranger:

Inserir aspectos computacionais nos modelos;

Inserir alguns detalhes da biblioteca de classes, geralmente, utilizando uma

abordagem ‘bottom-up’;

Considerar os requisitos não-funcionais, como desempenho e a segurança, e

aprimoram o projeto de maneira adequada a estes requisitos.

Pleeger utiliza amplamente a UML, fazendo uma divisão de como encaixar os

diagramas em nível de visão que são as seguintes:

Dinâmica – representada pelos os casos de usos, listas de atividades, diagrama

de interação mostrando seqüência e colaboração, e as máquinas de estado, a

fim de ilustrar os estados e suas mudanças;

Estática – é retratada pelos diagramas de classes, que mostram as relações

(associação, generalização, dependência e realização) e a extensibilidade

(restrições, valores identificados por tags e estereótipos). Além disso a visão

estática mostra os pacotes e a implementação.

As restrições e a fomalização são expressas com a OCL (Object Constraint

Language).

2.9.5 Implementação

Transformar a extração da análise e projeto do sistema em plataforma

implementável, com a estrutura de interfaces e a persistência dos dados. Para obter a visão

geral das funcionalidades a UML disponibiliza o diagrama de atividades que retrata como as



39

atividades interagem entre si, através de condições que são satisfeitas ou não, e são

executadas através de um fluxo de informações.

“O fluxo de implementação realiza um desenho em termos de diversos tipos de

componentes de código fonte e código binário conforme as tecnologias escolhidas” (PÁDUA,

2003). Admite-se critérios para a implementação, sendo assim, verifica-se as hierarquias de

implementação das unidades de acordo com o planejamento efetuado para a disciplina, com

suas definições, tarefas, de modo gerar um produto executável, analisando seus

comportamentos de acordo com as interações. Isso tudo aliado com as devidas entradas,

processamento para as funcionalidades e suas saídas respectivas, definindo, assim, os

componentes que podem ser reutilizáveis, por meio das ligações efetuadas. Paralelo a isso,

gera-se a documentação que compete ao usuário do software.

Por meio do diagrama de componentes e diagrama de implantação da UML,

consegue-se verificar as ligações e seus respectivos pacotes lógicos. Esse modelo estático

como o autor o representa uma espécie de visão para orientar onde cada pacote está

implementado.

Ressalta-se a necessidade de acompanhamento para apurar aspectos discordantes.

Wilson de Pádua Paula Filho apresenta dados significativos quanto à superioridade das

revisões e inspeções em relação aos testes na remoção de defeitos. O principal argumento é

que inspeções localizam diretamente o defeito, enquanto os testes apenas mostram sintomas; apartir desses, a identificação do defeito pode ser bastante demorada. Aplica-se uma espécie de

checklist do processo para validar o código. Entretanto, se forem bem planejados e

executados, os testes de unidade poderão detectar cerca de 70% dos defeitos que seriam

encontrados pelos usuários (PÁDUA, 2003). Para isso, estabelecem-se os testes de unidades,

citando os testes de interfaces, os quais validam as passagens de parâmetros (entradas)

garantindo a que as informações serão fidedignas, os testes de estruturas de dados que



40

verificam a integridade de dados armazenados temporariamente em instruções específicas ou

do tipo de dados que esperam uma requisição.

2.9.6 Testes

Segundo o autor Wilson de Pádua os testes são executados para detectar aqueles

defeitos que não são detectados durante as revisões e para avaliar o grau de qualidade de um

produto e de seus componentes. Assim que os desenvolvedores terminam suas atividades

começam a criar vários casos de teste com a intenção de forçar o software até aparecerem os

erros. Esses casos de teste, quando bem desenvolvidos, têm grande probabilidade de mostrar

erros ainda não descobertos, facilitando assim a correção do software, proporcionando uma

boa indicação da confiabilidade e da qualidade do software desenvolvido.

“A atividade de teste de software é um elemento crítico da garantia de qualidade

de software e representa a última revisão de especificação, projeto e codificação”

(PRESSMAN, 1995). Quando os testes são implantados eles verificam se os requisitos de

desempenho criados nas disciplinas de análise e projeto estão de acordo com o especificado,

nessa disciplina torna-se necessário fazer um bom procedimento de teste para identificar as

etapas necessárias para operar o sistema e exercitar os procedimentos dos casos de testes para

implementar o projeto de teste do software.“O teste de software determina quando um sistema de software pode ser liberado

e prevê um desempenho futuro. O teste é uma fonte importante de feedback e fornece uma

base para a interação com os participantes no projeto” (PETERS, PEDRYCZ, 2001).



41

2.9.7 Implantação

Nesta disciplina chegamos à etapa final do processo de desenvolvimento do

software, que é a sua implantação. Nessa etapa aumentará a interação entre o responsável pela

implantação e os clientes. Esse é um momento importante do desenvolvimento, onde se torna

necessário dar uma atenção maior aos clientes para que eles possam aprender corretamente a

operar o sistema e a se familiarizarem com o produto entregue, se essa implantação não for

bem sucedida poderão surgir problemas posteriores para a equipe de desenvolvimento.

“O treinamento dos usuários tem como base, principalmente, as principais funções

do sistema e a necessidade do usuário de poder acessá-las” (PFLEEGER, 2004). Cada usuário

receberá acesso às funcionalidades do software de acordo com as permissões designadas a ele,

para que assim ele tenha um completo domínio das funções do sistema aplicando as

funcionalidades desenvolvidas para desempenhar o seu trabalho.

Serão entregues nessa etapa os manuais do usuário e um guia de alto ajuda que

proporcionará uma facilidade maior ao entendimento e ao manuseio do sistema. Segundo

Pfleeger (2004), o treinamento pode ser feito de várias maneiras. Não importa por quanto

tempo o treinamento é realizado, ele deve oferecer informações para os usuários e operadores

em todos os momentos, e não apenas quando o sistema é entregue. Algumas vezes, se o

usuário se esquecer de como acessar um arquivo ou executar uma função, o treinamento deveincluir métodos para que o usuário possa encontrar e aprender essa informação. Alguns outros

documentos também podem ser entregues nessa fase do projeto, como por exemplo, os

documentos de requisitos, os documentos de projeto de programas e o documento de projeto

do software.



42

Efetuada toda essa parte de implantação do produto, com os devidos cuidados

tomados e com todos os treinamentos efetuados, encerra-se todo o desenvolvimento do

software, finalizando o projeto de software.



43

3 METODES - DISCIPLINAS

3.1 Apresentação da METODES

O princípio fundamental da METODES é sua utilização contextualizada em meio

acadêmico, embora apresente aspectos técnicos e conceituais que possibilitam sua utilização

em projetos de desenvolvimento de softwares para fins comerciais. Seu objetivo é fornecer

infra-estrutura metodológica para auxiliar a condução e execução desses projetos. Neste

trabalho o contexto utilizado como fundamento para desenvolvimento da Metodologia é o

ambiente acadêmico da FACEB.

A idéia da METODES é fornecer um meio de trabalho que propicie ao aluno saber

quando, o quê e por quem devem ser realizadas determinadas tarefas para que um software

seja desenvolvido atendendo a um conjunto de requisitos de qualidade, controle e

produtividade.

Não é propósito da METODES ensinar ao aluno como executar procedimentos

técnicos. Assume-se que o aluno utilizará o conhecimento adquirido ao longo do seu curso de

graduação para realizar as tarefas determinadas pela metodologia, embora ela indique, em

alguns casos, um conjunto de condições desejáveis para a realização dessas tarefas.

A forma com que a METODES propõe a condução de um projeto dedesenvolvimento de software faz com que ela possa ser utilizada para desenvolvimento

iterativo e incremental. Essa possibilidade se deve pela forma com que são tratados os

requisitos de software. Estes podem ser considerados individual e gradualmente, ou seja, é

possível que um único requisito seja detalhado, analisado, projetado e construído de forma

independente no projeto, fazendo com que haja releases funcionais do software antes do

término do projeto.



44

A METODES foi criada para ser utilizada, preferencialmente, em projetos de

desenvolvimento de software sob o paradigma da orientação a objeto, tendo como linguagem

de modelagem a UML. Essa recomendação foi adotada pela FACEB devido à ascensão da

utilização desse paradigma no atual mercado de software.

A divisão da METODES é feita por disciplinas, atividades e tarefas. As disciplinas

representam um conjunto de atividades inter-relacionadas a fim de alcançar um objetivo

específico, um resultado parcial do processo de desenvolvimento. As atividades contêm uma

ou mais tarefas que devem ser executadas para que o resultado da disciplina seja alcançado.

Todas as disciplinas da METODES apresentam estrutura funcional comum. Elas apresentam

pré-requisitos (insumos), processamento desses insumos e artefatos do processo.

Os artefatos da METODES são documentos específicos de cada disciplina que

contém os resultados do projeto de software. Esses artefatos podem ser, em momentos

distintos, tanto resultados como insumos para as disciplinas da metodologia.

A METODES oferece três perspectivas de funcionamento, denominadas visões da

metodologia. São elas: perspectiva de disciplinas, perspectiva de blocos e perspectiva de

papéis.

3.1.1 Perspectivas da METODES

3.1.1.1 Perspectiva de disciplinas

A Perspectiva de Disciplinas apresenta a metodologia sob o aspecto do fluxo de

atividades que são realizadas ao longo do processo de desenvolvimento. Esse fluxo de

atividade é representado com o diagrama de atividades da UML e considera os fluxos

condicionais e as ocorrências de execuções em paralelo de algumas atividades.



45

A figura 3.1 representa a visão geral de como se dá o processo de desenvolvimento

da METODES e apresenta apenas a visão dos relacionamentos entre as disciplinas da

metodologia.

3.1 PERSPECTIVAS DE DISCIPLINAS DA METODES

3.1.1.2 Perspectiva de blocos

A Perspectiva de Blocos mostra as disciplinas da METODES disponíveis como

blocos independentes do processo de desenvolvimento. Essa visão permite ao Gerente de



46

Projeto utilizar cada bloco separadamente, ao invés de utilizar toda a metodologia. Ou seja,

ele pode resolver utilizar, por exemplo, somente a disciplina Concepção da METODES e

continuar o desenvolvimento do software utilizando uma outra metodologia.

Cabe ao Gerente de Projeto optar pela utilização dessa perspectiva, dependendo das

características e particularidades do projeto de software. Cada disciplina (bloco) continuará

exigindo os mesmos insumos e produzindo os mesmos resultados. Portanto, cabe ao Gerente

de Projeto adequar os insumos (ou artefatos), provindos de outra metodologia, para o padrão

exigido pela METODES.

A figura 3.2 representa a idéia da perspectiva de blocos da METODES.

3.2 DIAGRAMA DE BLOCOS DA METODES

3.1.1.3 Perspectiva de papéis

A Perspectiva de Papéis apresenta a visão de interação dos papéis com o processo de

desenvolvimento. Dependendo da disponibilidade de recursos humanos e outras limitações

que pode haver em um projeto, pode ser interessante visualizar a metodologia sob o aspecto



47

de quem trabalha nela. Assim, uma pessoa, ao assumir determinado papel, saberá onde atuará

no projeto. Isso pode facilitar a distribuição e entendimento das responsabilidades dos

recursos humanos por todo o processo.

A figura 3.3 é uma representação da perspectiva de papéis da METODES.

3.3 PERSPECTIVAS DE PAPÉIS – ESQUEMA DE INTERAÇÃO DOS PAPÉIS DA METODES



48

3.2 Concepção

3.2.1 Definição

A disciplina Concepção da METODES foi desenvolvida para permitir o

entendimento global do projeto a que está sendo aplicada, possibilitando melhor entendimento

de pontos estratégicos para o sucesso do projeto, tais como compreensão do cliente, do

negócio do cliente e do problema a ser solucionado.

Para isso, a disciplina é o marco inicial para qualquer projeto de software. Ao

término de sua execução, ter-se-á artefatos suficientes para a avaliação da viabilidade do

projeto, tendo-se determinado seu escopo, as necessidades fundamentais do usuário e as

estimativas de prazo e custo.

As estimativas apresentadas na disciplina Concepção da METODES são extraídas

a partir da Análise de Pontos-de-Função1 (APF) do software proposto. Para essa análise,

utiliza-se o protótipo visual apresentado ao cliente. É importante que fique documentado que

ocorrerão revisões nessas estimativas. Isso porque o software será mais detalhado nas etapas

subseqüentes do processo, possibilitando a apuração com maior precisão, dos reais dispêndios

para execução do projeto do software. Neste trabalho há, em anexo, um guia de referência

sobre contagem de pontos de função e, também, uma planilha eletrônica que auxilia aimplementação dessa contagem.

O objetivo principal da disciplina é fornecer um conjunto de informações

suficientes, tanto para o cliente como para a equipe de projeto, para que possam decidir sobre

a viabilidade do desenvolvimento de determinada solução sem que seja necessário iniciar a

construção da solução. Ou seja, ao final dessa disciplina existirá um estudo contextualizado e

1 A análise de pontos de função (APF) é uma técnica empregada para medir as funções fornecidas por umsoftware ao usuário, independente da tecnologia utilizada na sua implementação.



49

uma demanda formal para o produto de software, que caracterizarão insumos fundamentais

para a criação de um projeto de software METODES.

O artefato que será produzido nessa disciplina é o Documento de Visão e Escopo

de Projeto (DVE). Nesse artefato existe um termo de aceite do projeto, o qual é a condição

necessária para o desenvolvimento da solução proposta no DVE.

Os papéis envolvidos nessa disciplina são: Analistas de Requisitos, Gerente de

Relacionamento e o Gerente de Projetos.

3.4 FLUXO DE ATIVIDADES DA DISCIPLINA CONCEPÇÃO

3.2.2 Atividades

São três as atividades básicas da disciplina Concepção da METODES, de acordo

com a figura 3.4: Contextualização do Problema, Levantamento dos Requisitos e Solução do

Problema. Cada atividade dessa disciplina fornece parte dos artefatos que comporão o

conjunto final dos artefatos da disciplina.



50

3.2.2.1 Contextualização do problema

Essa atividade está dividida em três tarefas essenciais: descrever o cliente, o

negócio do cliente e o problema que o cliente está enfrentando.

Nenhum artefato específico do processo, nessa etapa, será produzido. Ainda sim,

as informações coletadas nas tarefas subseqüentes dessa atividade produzirão parte de um

artefato.

3.2.2.1.1 Descrição do cliente

A descrição do cliente deve conter informações suficientes para suprir o projeto

de software. Isso significa dizer que não deve haver falta dessas informações que

comprometam o andamento ou a execução do projeto. No entanto, não há a necessidade de se

alongar nessa descrição. Por exemplo, no caso de uma empresa, detalhar seus sócios ou a sua

hierarquia interna pode não interessar ao projeto. O objetivo dessa descrição não é a

apresentação da empresa, mas sim, responder para a METODES quem é o cliente e o que dele

se precisa saber para não comprometer o projeto do software.

3.2.2.1.2 Descrição do negócio

O negócio do cliente precisa ser descrito sob o aspecto funcional, portanto,

descreve como acontecem as operações da empresa, suas inter-relações e suas relações

externas com parceiros e fornecedores, tudo isso para extrair informações para auxiliar a

compreensão e análise do problema.



51

Na descrição do negócio do cliente devem ser identificadas as regras de negócio

que existem nos processos da empresa, bem como o contexto onde essas regras são

identificadas, com a explicação, sempre que possível, de situações hipotéticas. Isso torna o

trabalho de análise e detalhamento de requisitos mais fácil e mais preciso.

A METODES admite que a empresa tenha seu negócio bem compreendido e

consolidado. No entanto, caso não seja essa a realidade, faz-se necessário submeter a empresa

a um trabalho profissional de modelagem de negócio. A falha ou inexistência de processos de

negócio bem definidos compromete a qualidade do produto de software a ser desenvolvido,

visto que nem sempre cliente tem clareza de suas reais necessidades.

3.2.2.1.3 Descrição do problema

Estando o cliente e o seu negócio bem definido, passa-se ao entendimento do

problema enfrentado pelo cliente.

O principal objetivo dessa tarefa é captar do cliente qual ou quais são as suas reais

necessidades. Muitas vezes o cliente pensa que um sistema de computador irá resolver todos

os seus problemas e acaba inserindo problemas muito maiores em seus processos, tornando-os

mais lentos e onerosos para empresa. Nem sempre um sistema computacional é a melhor

solução para a resolução de um problema. Em muitos casos seria suficiente um pouco deorganização e ajustes de procedimentos operacionais internos à empresa, aliados a algum

software de prateleira para se chegar a uma solução viável e satisfatória.

A disciplina Concepção da METODES pode chegar à conclusão, considerando as

características do negócio do cliente, que não é viável o desenvolvimento de um software

específico, seja por questões financeiras ou mesmo questões funcionais. A verdade é que a

filosofia da disciplina é contextualizar o cliente, o negócio e o problema dentro de um espaço



52

definido, levando em conta a disponibilidade de investimento financeiro e humano, e chegar a

uma proposta de solução para o problema que seja satisfatoriamente compreendida e aceita

pelo cliente.

3.2.2.2 Levantamento de requisitos

Nota-se que na atividade anterior ao levantamento de requisitos, a tarefa de

descrição do problema alerta para a possibilidade de o desenvolvimento de um software não

ser a melhor solução a se adotar para a resolução do problema do cliente. Portanto, não

haveria sentido em se falar de levantamento de requisitos de sistema caso a solução do

problema estivesse inclinada para esse ponto. No transcorrer de toda a disciplina Concepção

os profissionais envolvidos devem ser capazes de perceber a tendência da proposta de solução

para não incorrerem em trabalho desnecessário. Aplicando-se essa disciplina em um projeto

acadêmico, a probabilidade que essa situação ocorra é praticamente nula, mas, como a

METODES tem um propósito mais abrangente, podendo ser utilizada para a produção de

softwares para clientes comerciais, por exemplo, faz-se necessário deixar um alerta para que

os profissionais que estiverem desempenhando os papéis envolvidos nessa disciplina saibam

como atuar.

O objetivo dessa atividade é listar e entender as funcionalidades que um software

precisará fornecer como resultados a seus usuários. A maneira como o software realizará

esses resultados, será detalhado nas disciplinas de Detalhamento de Requisitos e Análise e

Projeto.

O levantamento de requisitos é de fundamental importância para todo o projeto do

software, pois seu resultado servirá de base para a definição de pontos importantes como a

delimitação de escopo, além de nortear todo o desenvolvimento através da metodologia.



53

Os requisitos levantados nessa atividade devem também sofrer uma classificação

para possibilitar maior clareza do que se pretende atingir como objetivos de projeto. Em um

projeto METODES na disciplina Concepção, classifica-se os requisitos como:

Requisitos essenciais: aqueles que compõem a parte fundamental do software

e devem ser implementados dentro das limitações e restrições do projeto;

Requisitos desejáveis: são aqueles que, dependendo do andamento do

projeto, podem ser reclassificados como requisitos essenciais e serem

implementados, mediante acordo formal entre o cliente e a equipe de projeto.

Esses são os requisitos que não inviabilizam a solução proposta ou que o

cliente considera como não-essenciais para resolver seu problema. Eles podem

agregar maior valor ao software, mas, geralmente por restrições financeiras,

deixa-se para implementações de futuro aprimoramento do software;

Não-requisitos: são os requisitos que a equipe de projeto e o cliente

acordaram para não fazerem parte do escopo do projeto. Portanto, esses

requisitos não serão implementados no software, a não ser que haja um novo

acordo para sofrerem reclassificação. A ação de reclassificar não-requisitos

deverá ser tratada como uma solicitação de mudança de escopo de projeto,

seguindo assim, os trâmites que a disciplina Gestão de Mudanças da

METODES define.

A equipe de projeto envolvida nessa atividade tem de realizar reuniões, quantas

forem necessárias, a fim de captar coma máxima precisão possível os requisitos essenciais e



54

demais requisitos para o projeto com intuito de solucionar o problema apresentado pelo

cliente. Além de captar as funcionalidades que o sistema deve atender é preciso extrair

informações sobre:

Infra-estrutura de física: verificar a disponibilidade ou necessidades de itens de

infra-estrutura física que serão importantes para o projeto, tais como

computadores e periféricos, instalações de rede de dados (cabeamento e ativos de

rede), condições de suficiência da rede elétrica e outros itens que o Gerente de

Projeto julgar importante.

Infra-estrutura de serviços: levantar necessidades de contratação de serviços de

comunicação (acesso à Internet ou links dedicados) e hospedagem de sítios WEB,

além de outros serviços necessários ao projeto.

Licenciamento de softwares: estimar o tipo e a quantidade de licenciamentos

necessários para o software, incluindo licenças de sistema operacional, de banco

de dados e de qualquer outro software que o cliente precisará para que o software

seja construído sem restrições legais.

Ainda no levantamento de requisitos, a equipe de projeto deve captar o máximo

de requisitos não-funcionais para o software, atentando para as expectativas implícitas do

cliente. Essas expectativas devem ser captadas e registradas no Documento de Visão e

Escopo, e as expectativas inviáveis ou julgadas não-importantes devem ser também

registradas como itens fora do escopo de projeto.



55

Feita a consideração dos requisitos funcionais e não-funcionais para o projeto,

recomenda-se à equipe de projeto que avalie, nesse momento, as restrições e ou limitações

que o cliente apresente e que possam influenciar na análise do projeto. Por exemplo:

O cliente pode ter em sua empresa uma infra-estrutura de rede montada e

definir que esta tem de ser mantida, nesse caso a análise do software fica

restrita a infra-estrutura existente;

Pode haver licenças de softwares já adquiridas pela empresa e isso passa a ser

fator limitante da tecnologia a ser utilizada.

Existem muitas outras hipóteses que podem ser consideradas. O importante é

entender e registrar as que podem causar impacto na concepção do projeto de software.

3.2.2.3 Solução do problema

Solucionar o problema, para a METODES, significa propor uma solução

tecnicamente viável para resolver o problema apresentado pelo cliente, considerando todo o

contexto de seu negócio e as restrições e limitações impostas.

A solução apresentada nessa atividade não representa com detalhes nenhum

modelo do que será o software a se desenvolver no projeto, mas delimita as expectativas

percebidas pelo cliente e serve como base norteadora para o trabalho de toda a equipe do

projeto.

A equipe de projeto deve consolidar nessa atividade todas as informações

extraídas do cliente nas atividades anteriores em um documento que será o primeiro artefato

do processo de desenvolvimento, o Documento de Visão e Escopo. Nesse documento devem



56

estar contidas as informações do cliente, descrição do negócio, descrição do problema,

requisitos essenciais, requisitos desejáveis, não-requisitos, limitações impostas e suas

conseqüências, e a síntese da solução. Por exemplo, uma síntese da solução, considerando

todos os itens que compõe a visão e o escopo do projeto, seria assim:

“Desenvolver um sistema de computador que funcione na atual infra-estrutura de

rede da empresa Anônimos Instrumentos Musicais LTDA, para permitir que as vendas de

balcão sejam registradas, mantidas e posteriormente verificadas para fins de consultas,

geração de relatórios de venda e estatísticas de venda, sendo estas últimas diárias, semanais,

mensais e anuais. O sistema deve fazer parte da Intranet da empresa, seguindo o mesmo

padrão de layout gráfico atual.”

O entendimento da proposta de solução depende muito dos outros itens inseridos

na visão e escopo do sistema, portanto ela não deve nunca ser apresentada fora do contexto

analisado por meio das informações que se obtêm durante toda a disciplina Concepção da

METODES.

3.2.3 Resultados da disciplina

Dois importantes artefatos de projeto são gerados nessa disciplina. Além do

Documento de Visão e Escopo, também é gerado o Aceite Formal de Projeto. Esse

documento deve ser assinado ao cliente para ratificar a solução apresentada pela equipe de

projeto, concordando, dessa forma, com todo o teor e condições contidos no documento. Os

artefatos detalhados posteriormente neste trabalho.



57

Uma boa execução da disciplina Concepção da METODES garante a

compreensão precisa da essência do projeto, tanto por parte do cliente quanto da equipe de

projeto. É importante que ambos, após o término da disciplina, não estejam preenchidos com

dúvidas ou falsas expectativas em relação a nenhum ponto do projeto, pois só assim o

resultado final do projeto pode ficar livre de surpresas, e, geralmente, em um projeto de

desenvolvimento de software as surpresas são geralmente desagradáveis.

3.3 Gestão do projeto

3.3.1 Definição

É na disciplina Gestão de Projeto que se figura um Projeto METODES. Um

projeto METODES é qualquer projeto de desenvolvimento de software que seja desenvolvido

utilizando a metodologia por completo. Dessa forma, quando é citado o termo Projeto

METODES, quer-se dizer que o projeto citado foi concebido e executado sendo fidedigno ao

que METODES define.

A gestão de projeto da METODES acompanha todo o processo de

desenvolvimento, do seu início até o momento em que o produto de software é implantado e

entregue ao cliente.Cinco atividades dividem o trabalho de gerência e controle de um Projeto

METODES, todas elas sendo apresentadas e realizadas de forma quase simultânea. Isso

porque as atividades da Gestão de Projeto podem ser requeridas a qualquer momento em

qualquer momento da metodologia, seja para o controle de um resultado ou para uma

solicitação de mudança de projeto.



58

3.5 FLUXO DE ATIVIDADES DA DISCIPLINA GESTÃO DE PROJETO

3.3.2 Atividades

As atividades da disciplina têm como objetivos acompanhar e controlar a

execução do projeto de software. Todas essas atividades se iniciam após a finalização da

disciplina Concepção da METODES, quando de fato se tem o início de um Projeto

METODES. A figura 3.5 mostra o fluxo de atividades dessa disciplina.

3.3.2.1 Elaboração do plano de projeto

Um Projeto METODES tem início a partir da assinatura do Documento de Visão

e Escopo pelo cliente do software.

Uma vez aprovado o projeto, ele precisa ser planejado e detalhado para o cliente

de forma que ele possa saber qual será o andamento almejado até o fim dos trabalhos.



59

Trata-se da elaboração do Plano de Projeto, que deverá conter informações do

cronograma de atividades, cronograma financeiro, gestão de riscos, enfim, tudo que está

envolvido em um projeto de software e que poderá influenciar os resultados daquele projeto.

A METODES fornece um artefato próprio e específico para esse fim, porém, é

necessário ressaltar que esse artefato não será a realidade para todos os projetos. É preciso que

o Gerente de Projeto esteja atento às particularidades do seu projeto e proceda com as devidas

adequações no artefato. Esse plano de projeto será identificado na metodologia como Plano de

Projeto de Software (PPS), e será descrito e detalhado em um capítulo posterior deste

trabalho.

Essa atividade de elaboração do PPS acontece logo no início do projeto do

software, porém tem seu condicionado somente ao final de todo o projeto, isso significa que o

PPS poderá, e fatalmente, sofrerá, alterações ao longo da execução do projeto. Por exemplo,

quando surgir uma solicitação do cliente que se caracterize como uma alteração de escopo,

prazos e custos do projeto poderão sofrer alterações. Em um caso desses é necessário que o

Gerente de Projeto avalie o impacto nesses cronogramas e os custos de projeto, comunique ao

Gerente de Relacionamento, para que este remeta ao cliente os ajustes necessários no projeto

e obtenha dele a aprovação formal para proceder com tais ajustes.

Sob o contexto citado, é necessária uma alteração no PPS e esta deverá ser

realizada no Controle de Artefatos, atividade responsável por esse fim.

3.3.2.2 Solicitação de mudanças

Na METODES há a figura do Gerente de Mudanças, responsável pelo

recebimento e envio de solicitações de mudanças.



60

A disciplina Gestão de Projeto recebe, basicamente, durante o processo de

desenvolvimento do software, resultados do projeto e solicitações de mudanças.

Os resultados de projeto são, na prática, os artefatos gerados em cada disciplina da

METODES. Esses artefatos serão controlados na atividade de Controle de Artefatos.

Os requisitos de software que foram definidos no Documento de Visão e Escopo

terão um controle diferenciado na atividade de Controle de Requisitos. Essa atividade não

controlara os artefatos de fato que se referem à documentação dos requisitos, mas sim a

rastreabilidade e as relações dos requisitos de software com som seus artefatos, além de outras

informações importantes para controle dos requisitos dentro do projeto do software.

As solicitações de mudanças podem ser de requisitos, de artefatos, de correção, de

revisão, enfim, qualquer coisa que remeta à alteração de um artefato da metodologia que já

tenha sido produzido ou a qualquer item do PPS e caracterizado como uma solicitação de

mudança.

Todas as solicitações de mudança serão enviadas ao Controle de Qualidade e,

após serem analisadas pelo gerente responsável, serão deferidas ou indeferidas e remetidas

novamente à disciplina da METODES que fez a solicitação.

Assim como as solicitações de mudanças, os resultados do Controle de Artefatos e

do Controle de Requisitos serão enviados, também, ao Controle de Qualidade.

3.3.2.3 Controle de artefatos

O controle dos artefatos dar-se-á por meio de um documento específico que será

identificado como Controle de Artefatos do Projeto (CAP).

Além do CAP a METODES sugere uma estrutura para guardar os arquivos

eletrônicos que representam os artefatos de projeto. Esses arquivos são documentos de texto,



61

planilhas eletrônicas, códigos do software, imagens, tudo o que representar um artefato em

forma eletrônica.

As ferramentas recomendadas para a utilização em um Projeto METODES

produzem esses arquivos e para padronização e organização desses a metodologia recomenda

que seja criada uma estrutura de pastas essas arquivos.

A estrutura de pastas proposta é independente de sistema operacional e está

representada de forma genérica, devendo ser adequada para a versão específica do sistema

operacional onde estão sendo executados os softwares que produzirão os artefatos.

<<raiz>>

|__<<nome_do_projeto>>

|__<< Artefatos>>

|__<< Gestao_Projeto>>

|__<< Concepcao>>

|__<< Det_Requisitos>>

|__<< Analise_Projeto>>

|__<< Construcao>>

|__<< Teste_Funcional>>

|__<< Implementacao>>|__<< Requisitos>>

|__<< Outros>>

Os nomes indicados que estão em negrito recomenda-se que sejam mantidos e os

outros substituídos de acordo com o projeto.

Além da estrutura de pastas sugerida, recomenda-se que os nomes dos arquivos

recebam o sufixo ‘_v.1.x’, onde ‘ x’ é um número seqüencial para cada nova release do

artefato em questão, sendo ‘0’ para a versão inicial e (1, 2, 3,... ) para cada vez que o artefato

for atualizado. Dessa forma teríamos a versão v.1.0, v.1.1, v.1.2, e assim por diante.

Caso o artefato sofra uma alteração que caracterize uma mudança grande para a

versão anterior, então haverá a necessidade de mudança de versão do artefato, passando para

v.2.0, v.2.1, v.2.2, assim seqüencialmente.



62

O aluno poderá também utilizar uma ferramenta CASE para realizar o trabalho de

controle de versões, mas mesmo nessa hipótese, recomenda-se que a planilha de Controle de

Artefatos de Projeto da METODES seja preenchida.

3.3.2.4 Controle de requisitos

A METODES começa o controle de requisitos a partir da disciplina Detalhamento

de Requisitos, onde serão especificados, detalhados e documentados. Desse ponto em diante,

toda e qualquer ação que envolva os requisitos deve passar por essa atividade de controle.

Nessa atividade há uma Planilha de Controle de Requisitos (PCR) que constitui o

artefato principal dessa atividade. Tem por objetivo documentar a vida do requisito durante a

execução do projeto de software. Portanto, informações como: data de aprovação, registros de

alteração, relacionamentos com as funcionalidades do software e outras coisas mais serão

encontradas nessa planilha.

Os resultados dessa atividade também serão acompanhados pelo Controle de

Qualidade e, portanto, devem ser encaminhados a ela.

3.3.2.5 Controle de qualidade

O Gerente de Qualidade é o papel responsável por conferir o andamento do

projeto de acordo com o que foi planejado. Além disso, é nessa atividade que são colhidos os

resultados do projeto e lançados na Planilha de Resultados de Projeto (PRP), que servirá a

futuros Projetos METODES como medida de comparação de fator de qualidade.

O objetivo do Controle de Qualidade é colher resultados e compará-los ao que era

esperado pelo cliente do software e pela equipe de projeto. Dessa forma, tem-se uma



63

perspectiva de avaliação não só do ponto de vista do produto, mas também do processo de

desenvolvimento.

A METODES define um produto de software de qualidade como aquele que

atendeu explicitamente ao que foi especificado no Documento de Visão e Escopo e que seu

desenvolvimento tenha ocorrido dentro do prazo e custo previsto no Plano de Projeto de

Software, já considerando quaisquer ajustes que tenham ocorrido independente por qual

motivo, durante a realização do projeto.

Acredita-se que a Planilha de Resultados de Software será um instrumento a ser

utilizado para Projetos METODES como fonte para estimativas de prazos e custos, além de

fonte comparativa de fator de qualidade.


O principal resultado da disciplina de Gestão de Projeto é possibilitar que o plano

de projeto possa ser cumprido como definido, isso já admitindo possíveis ajustes de prazos e

custos de projeto. Além disso, espera-se que os resultados obtidos nessa disciplina possam

contribuir para uma melhoria contínua da METODES, avaliando e comparando o resultado de

outros projetos realizados coma metodologia.

Um bom acompanhamento de um projeto de software pode trazer maior qualidadeno produto final, já que as questões que envolvem riscos no projeto podem ser melhor

dirimidas.



64

3.4 Detalhamento de requisitos

3.4.1 Definição

Na METODES a disciplina que trata do levantamento de requisitos, como já visto,

é a Concepção, entretanto, sem entrar em detalhes e pormenores de cada requisito. Acredita-

se que para os alunos de Sistema de Informação da FACEB, essa é a forma mais eficaz para

trabalhar com os requisitos, visto que as iterações com o cliente nem sempre são fáceis, por

diversos motivos, principalmente disponibilidade e choque de agenda ou tempo insuficiente.

Sendo assim, a utilização da METODES pode simplificar o trabalho dos alunos, pois o maior

contato com o cliente pode ser feito durante a execução da Concepção. Apesar disso, as

interações com o cliente não acabam na Concepção, mas com o escopo do projeto definido e

os requisitos levantados (essenciais, desejáveis e não-requisitos), torna-se mais fácil detalhar

os requisitos definidos.

Detalhar os requisitos é o objetivo principal dessa disciplina e para isso será

necessária a compreensão total dos fluxos de trabalho e também dos processos de negócio em

que estão inseridos.

Sommerville (2003) faz uma classificação de requisitos segundo seus níveis de

descrição, sendo requisitos de usuário as “declarações, em linguagem natural e também emdiagramas sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve

operar” e, requisitos de sistemas, como as descrições detalhadas das funções e restrições do

sistema. A partir dessa classificação o autor define os requisitos funcionais e não-funcionais.

Para Sommerville (2003), requisitos funcionais são “declarações de funções que o sistema

deve fornecer como o sistema deve reagir a entradas específicas e como deve se comportar em



65

determinadas situações” e os requisitos não-funcionais são as “restrições sobre os serviços ou

as funções oferecidos pelo sistema”.

Na disciplina Concepção da METODES os requisitos são classificados como

essenciais, desejáveis e não-contemplados. Esses requisitos sofrerão nova classificação na

disciplina Detalhamento de Requisitos. Agora, dentre cada conjunto anteriormente

classificado, serão classificados como requisitos funcionais e não-funcionais.

Os requisitos funcionais compreendem todas as funcionalidades que o sistema

deve apresentar, considerando aquelas funcionalidades que estão alheias à intervenção ou

interação do usuário com o software. Por exemplo, funções internas que realizam

procedimentos essenciais para o funcionamento do software, mas não foram citadas pelo

usuário.

Os requisitos não-funcionais são aqueles que se referem ao atendimento de uma

demanda não diretamente relacionada às funções do software. Por exemplo, o padrão estético

das interfaces gráficas do software, o tempo máximo de resposta de determinada requisição,

ou ainda, tipo de linguagem de programação a ser utilizado para o desenvolvimento.

A METODES especifica e documenta os requisitos funcionais definidos na

Concepção por meio do Caso de Uso de Funcional (CUF), que se configura como mais um

artefato da metodologia. Para a modelagem de um CUF deve ser utilizado o diagrama de caso

de uso da UML.Dentro do Detalhamento de Requisitos há uma outra disciplina, a Prototipação,

onde seus resultados, os protótipos de interfaces gráficas, apresentam-se como condições

precípuas para a validação dos requisitos. A prototipação de interfaces gráficas na METODES

tem como objetivo apresentar ao cliente uma idéia de como o usuário interagirá com as

diversas interfaces que o software lhe apresentará. Não é intenção dos protótipos

demonstrarem funcionalidades do sistema, ou seja, o protótipo é totalmente passivo e também



66

não representa as interfaces finais do software, pois só depois da disciplina de Análise e

Projeto é que as interfaces serão totalmente definidas.

Nessa disciplina de detalhamento de requisitos o Analista de Requisitos é o único

papel envolvido diretamente, mas como seu trabalho tem de ser feito com os usuários do

software o Gerente de Relacionamento pode ser envolvido.

3.6 FLUXO DE ATIVIDADES DA DISCIPLINA DETALHAMENTO DE REQUISITOS



67

3.4.2 Atividades

Nessa disciplina são consolidados os Casos de Uso Funcionais da METODES. A

correlação preliminar e padrão é que cada funcionalidade listada como requisito na

Concepção, e que for um requisito funcional, tornar-se-á um CUF. Dessa forma, a primeira

atividade a ser realizada é a Classificação dos Requisitos. Nessa atividade é que os requisitos

da METODES serão classificados como requisitos funcionais e não-funcionais, além disso,

ainda durante a classificação, ocorrerá também a priorização deles.

3.4.2.1 Classificação e priorização dos requisitos

A partir do conjunto de requisitos classificados na Concepção, o Analista de

Requisitos deve classificá-los como requisitos funcionais e não-funcionais. Cada requisito

funcional seguirá pela METODES como um CUF.

Um CUF é um documento que contém a descrição e o detalhamento de um

requisito funcional do software. Ele deve ser modelado utilizando o diagrama de caso de uso

da UML além das descrições textuais necessárias para tornar claro o entendimento do

requisito.

Os requisitos não-funcionais serão documentados individualmente por meio doDocumento de Requisito Não-Funcional (DRNF). Cada DRNF fornecerá uma descrição

detalhada do que é, e como aquele requisito não-funcional será atendido ou tratado,

informando, também, os objetivos e conseqüências do tratamento desse requisito.

Dependendo do requisito não-funcional, pode não haver modelos ou diagramas

específicos da UML para serem utilizados na descrição desses requisitos. Porém, a equipe de



68

projeto pode convencionar um diagrama qualquer para ser utilizado nessa descrição, levando

em consideração as características do requisito não-funcional que estiver sendo tratado.

Depois de os requisitos serem classificados, eles devem ser priorizados para as

disciplinas subseqüentes da METODES. A priorização será um tipo de ordenação dos

requisitos segundo o grau de essencialidade, ou seja, o Gerente de Projeto, com a aquiescência

do cliente do software, deverá estabelecer quais serão os primeiros requisitos a serem

desenvolvidos, aqueles fundamentais para o cumprimento das metas do projeto. Os critérios

utilizados para estabelecer as prioridades dos requisitos podem ser os mais diversos em um

projeto de software, desde questões financeiras até a escassez de pessoal, portanto, essa

priorização precisará ter o acorde formal do cliente.

Como a METODES admite o desenvolvimento de forma iterativa e incremental a

classificação dos requisitos poderá ser realizada ainda na disciplina Concepção, no entanto,

essa classificação e priorização deve ser documentada segundo as determinações da atividade

Classificação e Priorização dos Requisitos.

3.4.2.2 Detalhamento dos requisitos funcionais

Essa atividade acontecerá paralela à atividade de prototipação. Nela serão

considerados apenas os requisitos funcionais do software, ou seja, os CUF. Para a análise deum CUF deverão ser consideradas as interações com o usuário que são produzidas, as

interações com outros sistemas, pré-condições que devem existir para que o CUF se realize e

também as situações posteriores à realização dele.

Os diagramas de caso de uso da UML serão utilizados para modelar os CUF.

“Um caso de uso especifica o comportamento de um sistema ou de

parte de um sistema e é uma descrição de um conjunto de seqüênciasde ações, incluindo variantes realizadas pelo sistema para produzir um



69

resultado observável do valor de um ator”. (BOOCH, RUMBAUGH,JACOBSON, 2005).

As variantes realizadas pelo sistema são fluxos secundários ou alternativos que

podem ocorrer durante a execução de uma funcionalidade do software. Na METODES essas

variantes são tratadas como fluxos alternativos de um CUF e não há a obrigatoriedade de

serem documentadas pelo Analista de Requisitos, desde que não haja comprometimento do

entendimento do CUF pelo Projetista do sistema.

Na modelagem de um caso de uso, um ator representa qualquer elemento que

interaja com o sistema, seja um usuário, um hardware ou mesmo um outro sistema. Dessa

forma os atores precisam ser descritos e contextualizados naquele CUF. Tudo isso para tornar

mais clara a descrição do caso de uso.

3.4.2.3 Prototipação

Paralelo à atividade de detalhamento dos requisitos funcionais, um protótipo

visual do software deve ser criado para facilitar o entendimento do comportamento da

funcionalidade.

O protótipo de software tem como único e exclusivo objetivo criar uma visão

gráfica representativa do CUF, portanto, não há nenhuma função implementada. Acredita-se

que uma interface gráfica ajuda na compreensão e validação de um requisito apresentado ao

usuário, e também auxilia na transmissão do entendimento entre Analista de Requisitos e

Projetista, pois uma visão gráfica de um CUF restringe as dúvidas levadas ao Projetista.

A prototipação deve ser realizada por especialista em design gráfico. Na

METODES esse papel será do Prototipador. Os protótipos criados nessa etapa do processo de

desenvolvimento podem ou não gerar as interfaces gráficas definitivas. Para tanto, a

METODES tem como diretriz que os protótipos de software devem ser construídos



70

utilizando-se de linguagens visuais que possam ser implementadas no futuro. Por exemplo, se

há clareza na Concepção que o sistema a ser desenvolvido será em formato Web, os protótipos

devem ser feitos, portanto, em HTML. O ideal é que os protótipos sejam sempre construídos

na linguagem em que o sistema será desenvolvido. Embora a definição da linguagem de

construção a ser utilizada no projeto acontecerá formalmente na disciplina de Análise e

Projeto, geralmente essa definição se dá nas disciplinas anteriores, seja por questões de

restrição de projeto ou outra questão qualquer.

As tarefas da Prototipação são:

Definir linguagem de construção: considerar uma linguagem visual para

construção do protótipo, se possível, utilizar a mesma linguagem de construção do

projeto;

Levantar requisitos de interface do Caso de Uso Funcional: identificar

elementos gráficos necessários como botões, nome e metáforas para os elementos

gráficos, campos de texto, figuras e desenhos para afforadance objeto, tamanho

dos objetos e cores;

Requisitos de interface podem ser considerados requisitos não-funcionais de um

software, porém, para a METODES, o protótipo é algo puramente visual e nãointerfere na análise e projeto do sistema como um todo, dessa forma o projeto de

interface gráfica do sistema segue sendo tratado de forma integrada ao processo,

porém em paralelo a outras atividades da metodologia;

Construir protótipo: Construir o protótipo segundo os requisitos de interface

levantados;



71

Validar protótipo: o protótipo será um fundamento para a validação do requisito

pelo usuário, entretanto o protótipo em si deve ser validado pelo Analista de

Requisitos para corrigir não-conformidades entre o seu entendimento e o do

Prototipador.

3.4.2.4 Detalhamento dos requisitos não-funcionais

Cada requisito não-funcional na METODES é documentado como DRNF

(Documento de Requisito Não-Funcional). O DRNF é o artefato onde estarão as informações

e condições necessárias para que esses requisitos sejam atendidos. Ou seja, tudo o que precisa

ser realizado ou adquirido para que o projeto atenda aos requisitos não-funcionais

especificados para o software. Sendo assim, o DRNF deve conter a descrição do requisito

não-funcional, os objetivos desse requisito, as conseqüências de não atendimento, os CUF

relacionados e a solução proposta para o atendimento do requisito não-funcional. Caso seja

necessário, deverão ser inseridos diagramas, preferencialmente da UML, que exemplifiquem a

solução proposta para o atendimento do requisito não-funcional.

O DRNF constitui um artefato da metodologia e será descrito e detalhado com os

outros artefatos em um capítulo posterior.

3.4.2.5 Documentação dos requisitos

Documentar os requisitos significa criar os artefatos específicos para cada tipo de

requisito, funcional e não-funcional. No caso da METODES esses artefatos são o CUF e o

DRNF.



72

3.4.2.6 Homologação e validação dos requisitos

A homologação e validação dos requisitos acontecem assim que for possível

demonstrar ao usuário do software como a equipe de projeto entendeu o comportamento de

uma funcionalidade. Na METODES isso se dá quando um CUF é totalmente detalhado,

inclusive com os DRNF a que se relacionam e, também, os protótipos de interfaces gráficas

que se ligam a ele.

Os resultados do detalhamento dos requisitos são demonstrados ao usuário e,

então, para cada CUF, é gerado um Termo de Aceite de Requisito (TAR). Esse aceite é um

termo que o cliente deverá assinar, ratificando as informações nele contidas e aceitando as

condições de realização do CUF.


Espera-se que ao final dessa disciplina todos os requisitos estejam completamente

compreendidos pela equipe de projeto. Além disso, é fundamental que usuário do software

esteja de pleno acordo com o entendimento que o Analista de Requisitos teve de sua

declaração de requisitos, ou seja, não basta que o cliente assine um documento ratificando otrabalho do Analista, é essencial que usuário e o Analista entendam, ao final da disciplina, o

requisito da mesma forma.

Formalmente os resultados dessa disciplina são: CUF e o DRNF.



73

3.5 Análise e projeto

3.5.1 Definição

Como já dito, a METODES oferece a possibilidade do desenvolvimento do

software de forma iterativa e incremental. Conceitualmente, isso significa que a cada nova

iteração todas as disciplinas da metodologia seriam realizadas, entretanto, na METODES, as

iterações acontecem a partir da disciplina Detalhamento de Requisitos. Isso porque na

disciplina Concepção são realizadas as atividades que definem o escopo do projeto, portanto

só é realizada uma única vez. Desse ponto em diante as necessidades de alteração são tratadas

como solicitações de mudança de escopo de projeto.

Em Análise e Projeto, o Projetista, papel responsável por essa disciplina, realizará

as suas atividades tendo como base os requisitos definidos na Concepção. É nessa etapa da

metodologia que a solução do problema, indicada no Documento de Visão e Escopo,

começará a receber um tratamento técnico para viabilizá-la. O Projetista deve se ater a todo o

conjunto de requisitos especificados para projetar uma solução que atenda aos anseios dos

usuários do software em todos os aspectos. Isso significa que, além de prover solução às

funcionalidades que o software deve apresentar, ou seja, os requisitos funcionais, a solução

projetada deve, também, atender aos requisitos não-funcionais.É importante salientar a semântica do termo projeto para essa disciplina. Do

inglês temos project e sua tradução literal que é projeto. Nessa forma o termo significa

projeto, se referindo a um plano de realização de algo, um procedimento estruturado e

organizado com um desígnio específico. Porém, no contexto da engenharia de software, esse

termo pode estar se referindo à tradução de design, que também é traduzido do inglês como

projeto, que nesse caso se refere à forma com que o software será modelado. Normalmente



74

essa semântica aparece nas disciplinas de análise e projeto, ou análise e desenho, dos

processos comerciais de desenvolvimento.

A análise e o projeto de um software podem aparecer como disciplinas distintas

em uma metodologia por apresentarem sutis diferenças para alguns e bastantes relevantes para

outros. Pfleeger (2002) traz o conceito de projeto conceitual (análise) e projeto técnico

(projeto). O primeiro é o projeto do sistema na visão do cliente e se propõe a responder o quê

o sistema fará. O outro é o projeto técnico do sistema que responderá aos construtores do

software como o sistema fará o que propôs fazer ao cliente. Pádua (2003) diz que na análise o

foco é a modelagem dos conceitos presentes no domínio do problema, porém os detalhes

técnicos que pertençam à construção devem ser evitados.

Na METODES a análise e o projeto do sistema são realizados como uma só

disciplina para facilitar o trabalho e a compreensão do aluno na hora de projetar um sistema,

já que, na prática a análise e projeto se diferenciam no nível de detalhamento dos dois

modelos. Acredita-se que para o aluno, diante de um problema que ele precise resolver, seja

mais fácil considerar todos os aspectos que envolvem aquela solução e criar um só modelo a

ser detalhado de forma gradual na disciplina a tentar criar dois modelos iguais com

detalhamento diferenciado.

Considerar a totalidade dos aspectos envolvidos na solução pode parecer ser mais

trabalhoso, mas na verdade pode se tornar a maneira mais prática e objetiva de resolver umproblema. A revisão e o detalhamento dos aspectos considerados no projeto acontecerão à

medida que o domínio do problema é analisado pelo Projetista.

A METODES define em sua disciplina Análise e Projeto algumas linhas de ação

que o Projetista deve executar para contemplar os aspectos técnicos e não-técnicos envolvidos

na solução. Os aspectos que a metodologia sugere serem tratados são apresentados de forma

generalizada e abrangente. Isso significa que não são os únicos aspectos que devem ser



75

considerados e nem que estão apresentados da forma mais adequada para qualquer projeto de

software. Os aspectos que a metodologia propõe serem tratados são aqueles que podem

aparecer na maioria dos projetos de software, porém, não há garantias de que sejam ao menos

suficientes para contemplar essa maioria de projetos.

Os aspectos definidos pela METODES também podem ser entendidos como

visões de análise. As visões propostas para um projeto de software são três: visão de

arquitetura, visão de infra-estrutura e visão de segurança. Essas três visões abrangem os

aspectos essenciais que deverão ser tratados em um projeto de software realizado com a

METODES.

3.5.2 Visões de análise

3.5.2.1 Visão da arquitetura

Os aspectos arquiteturais que a metodologia considera têm como objetivo eleger a

arquitetura de software e arquitetura de comunicação que servirá ao sistema. É sabido que a

escolha dessas duas arquiteturas dependerá das características do software que se

desenvolverá e seu conjunto de requisitos, contudo os pontos aqui descritos servem a apenas

como orientação para a definição dessas arquiteturas.Na disciplina Concepção da METODES alguns itens podem já ter sido definidos.

Por exemplo, o cliente poderia já ter montada sua infra-estrutura de rede, portanto, cabe ao

Projetista adequar a seu projeto, tudo aquilo que tenha de ser aproveitado. Cabe aqui também

a consideração dos softwares que já estejam instalados ou adquiridos pelo cliente, então, o

projeto fica condicionado a esses itens já definidos. O trabalho do Projetista será desenvolver



76

uma solução que contemple o que já existe e que promova os resultados esperados do

software pelo cliente.

3.5.2.2 Visão da infra-estrutura

Os aspectos de infra-estrutura que devem ser tratados se referem a todos os

elementos necessários para viabilizar a implementação das arquiteturas de software e

comunicação definidas anteriormente. O recomendado a ser tratado pela METODES é a infra-

estrutura de ativos físicos e a infra-estrutura de software.

3.5.2.3 Visão da segurança

A METODES trata nessa visão as questões de segurança que permeiam o

desenvolvimento do software. Cada projeto de software pode exigir um conjunto específico

de requisitos de segurança que devem ser tratados, porém, na maioria dos casos as questões

que a METODES sugere que sejam tratadas, mostram-se relevantes e pertinentes. Os quatro

pontos essenciais que são tratados pela METODES são: Classificação e Proteção dos Dados,

Tráfego Seguro das Informações, Persistência e Recuperação dos Dados e Segurança Física.

3.5.3 Atividades

A figura 3.7 apresenta o fluxo geral de atividades que o Projetista deve excetuar

na disciplina Análise e Projeto da METODES. Logo após, têm-se as descrições das atividades

dessa disciplina.



77

3.7 FLUXO DE ATIVIDADES DA DISCIPLINA ANÁLISE E PROJETO

3.5.3.1 Definição das visões de análise

O trabalho que é realizado nessa atividade acontecerá intensamente durante toda a

disciplina de análise, pois é nessa atividade que decisões importantes sobre o projeto

precisarão ser tomadas.

Muitas dessas decisões poderão não terão um caráter definitivo logo no início do

projeto do software, a avaliação deve ser considerada ao longo do desenvolvimento de toda a

disciplina Análise e Projeto. Algumas questões como a definição da arquitetura de software a

ser utilizada, podem não sofrer grandes alterações ao longo do projeto, outras, porém, como

arquitetura de comunicação e a infra-estrutura de software podem se mostrar bastantes

dinâmicas e instáveis. No entanto, essas são apenas especulações que se faz para demonstrar a

necessidade da constante revisão do projeto e da modelagem das visões de análise, termo



78

utilizado pela METODES para definir o tratamento das questões de arquitetura, infra-

estrutura e segurança do projeto.

O Projetista deve considerar o conjunto de requisitos definidos no Documento de

Visão e Escopo para avaliar e projetar cada uma das visões de análise que a METODES

define. A partir das avaliações dessas visões de análise serão gerados artefatos específicos

para documentá-las:

Modelagem da Visão de Arquitetura de Software (MVAS): documento que

apresenta a arquitetura de software escolhida para o software, contendo a sua

descrição completa, os motivos que levaram à sua escolha, o detalhamento de

camadas, caso existam naquela arquitetura, e a todas as demais descrições

necessárias para que o apreciador desse documento entenda a arquitetura exposta.

Modelagem da Visão de Arquitetura de Comunicação (MVAC): apresentação

da topologia física e lógica de rede, demonstrando, em um nível baixo de

detalhamento técnico, as ligações dos componentes envolvidos e dos links de

comunicação. Esse documento tem por objetivo identificar o esquema de

comunicação lógico que utiliza.

Documentação da Infra-estrutura de Ativos Físicos (DIAF): simplesmente a

descrição de todos os ativos físicos utilizados. Hubs, switches, roteadores,

modems, servidores (computadores). Ou seja, todo ativo que direta ou

indiretamente tem um papel no funcionamento do software deve ser caracterizado

e descrito nesse documento. A descrição deverá ser completa e conter a

especificação técnica de cada um deles. Por exemplo, qual o processador do



79

servidor de banco de dados? Qual a quantidade de memória RAM? Qual a

capacidade de armazenamento? Que sistema de disco foi utilizado? Qual o sistema

de arquivos dos discos? Enfim, todos os detalhes que permita conhecer bem a

infra-estrutura sob o ponto de vista físico e técnico.

Documentação da Infra-estrutura de Software (DIS): muito parecido com o

DIAF, porém, trata especificamente dos softwares utilizados. Nesse caso são

descritos todos os softwares que compõe a solução, mas não o software que está

sendo desenvolvido. Por exemplo, o sistema operacional que roda no servidor de

banco de dados, a versão que foi instalada, se for um Linux qual a versão do

kernel, qual a distribuição, enfim, detalhes que explicitam bem o ambiente do

software.

Modelagem da Visão de Segurança (MVS): a visão de análise de segurança da

define quatro pontos essenciais que devem ser observados nessa visão. São eles:

Classificação e Proteção dos Dados, Tráfego Seguro das Informações, Persistência

e Recuperação dos Dados e Segurança Física. Nesse documento deverá ser feita a

consideração para cada um desses pontos, apontando a solução adotada para cada

ponto quando for o caso. Recomenda-se que as soluções sejam também

demonstradas utilizando alguma linguagem visual para facilitar o entendimento,

por exemplo, diagramas, esquemas, gráficos, enfim, qualquer elemento que se

mostre adequado para representar a solução escolhida. Caso algum diagrama da

UML possa ser utilizado dar preferência a ele.



80

O trabalho do Projetista é bastante intenso e poderá refletir diretamente na

qualidade do produto de software desenvolvido, pois ele atua como arquiteto, consultor

técnico e analista de sistemas quase que ao mesmo tempo. A seguir têm-se as especificações

de cada tópico que as visões de análise tratam para um projeto METODES.

3.5.3.1.1 Arquitetura de software

Nessa etapa da metodologia o Projetista deve considerar os padrões de projeto

(design patterns) que podem ser utilizados para, então, eleger o melhor tipo de arquitetura de

software que atenda aos requisitos do software, tanto os requisitos funcionais como os não-

funcionais.

Recomenda-se que, na avaliação da arquitetura de software, seja definida também

a plataforma de desenvolvimento, já que a decisão da arquitetura pode influenciar na escolha

da linguagem de programação, frameworks e vice-versa.

3.5.3.1.2 Arquitetura de comunicação

Mais uma vez, devem-se considerar as características do projeto de software para

a definição da arquitetura de comunicação que atenderá aos propósitos do software. Aquidevem ser tratadas as questões das tecnologias de rede, topologia física, topologia lógica,

qualidade de serviço (QoS – Quality of Service), links de comunicação, redundância desses

links, enfim, todos os aspectos necessários para atender os requisitos de comunicação entre os

diversos elementos ou componentes do sistema.



81

3.5.3.1.3 Ativos físicos

Trata-se dos componentes que darão suporte às arquiteturas definidas. Todo e

qualquer hardware necessário para promover a implantação do software de acordo com as

definições do projeto. Componentes de rede (cabeamento, switchs, routers, modems), bem

como, os computadores e periféricos (impressoras, plotters, scanners) devem ser

especificados para atender à arquitetura de comunicação definida.

3.5.3.1.4 Softwares

Todos os softwares que precisarão ser adquiridos e licenciados para suportar a

arquitetura definida. Inclui-se nesse caso a definição da plataforma de sistema operacional,

frameworks, definição do SGBD e qualquer outro componente que seja essencial para o

funcionamento do software.

3.5.3.1.5 Classificação e proteção dos dados

Caso seja necessário ao projeto, a METODES recomenda que os dados que são

manipulados pelo software estejam classificados como públicos, restritos ou privados. Cadaum desses tipos de dados requer um cuidado especial para armazenamento.

O Projetista deve considerar as questões de criptografia e demais questões de

segurança no desenho do modelo do banco de dados, não permitindo, por exemplo, que dados

restritos ou privados se apresentem acessíveis para usuários não autorizados, ou que, o acesso

a eles seja disponibilizado diretamente ao usuário. É sempre recomendado que haja uma



82

camada de software que sirva como elo entre o usuário (apresentação) e os dados

(persistência).

3.5.3.1.6 Tráfego seguro das informações

Esse aspecto deve ser tratado quando há troca de informações em um meio hostil,

como a Internet, por exemplo. Isso significa dizer que se deve ter o cuidado de não trafegar

informações sigilosas como senhas e dados pessoais pela rede, sem que estejam

criptografadas. Sempre que houver a necessidade de trafegar esse tipo de informação é

recomendado que se trafegue por canal de comunicação criptografado.

3.5.3.1.7 Persistência e recuperação dos dados

O tratamento da persistência e recuperação de dados é extremamente importante

que se tenha clareza de como, onde, e por quanto tempo os dados devem persistir para o

sistema. Além disso, é necessário estar documentado com clareza a forma com que os dados

mais antigos podem ser recuperados, para o caso de sistemas que precisem manter algum tipo

de histórico.

Na METODES o Projetista deve elaborar os processos operacionais que tratam damanutenção da persistência desses dados. Processos documentados que dizem como, quando,

onde, e quem são os responsáveis por manter a base de dados persistente pelo tempo

necessário. São esses processos que definem como são executados os procedimentos de

backup e restore dos dados do sistema. Esses procedimentos podem ser automatizados, mas

em alguns casos as infra-estruturas podem depender da intervenção humana para que se

finalizem por completo.



83

3.5.3.1.8 Segurança física

A segurança física se refere ao ambiente interno onde estão os ativos físicos da

infra-estrutura que servem ao sistema. Servidores e ativos de rede não devem ficar expostos a

qualquer usuário ou pessoas externas não autorizadas. Somente usuários que tenham

privilégios administrativos devem executar tarefas nesses equipamentos. Idealmente, a infra-

estrutura deve estar isolada o máximo possível do ambiente operacional do sistema para evitar

que ataques físicos aos equipamentos comprometam a integridade e o sigilo das informações.

O nível de segurança física aplicada a um sistema está diretamente ligado à

criticidade do sistema. Por exemplo, um sistema que tenha que estar disponível vinte e quatro

horas por dia, sete dias por semana, não pode estar a mercê de uma simples tomada de força

ou um cabo de rede que, se arrancados, põe abaixo todo o funcionamento do sistema. A

disponibilidade de um sistema é apenas um exemplo, o qual poderia ser tratado com a adoção

de mecanismos de redundância, mas vários outros aspectos podem ser comprometidos com a

falta de segurança física, roubo de informações, comprometimento da integridade dos dados e

outros aspectos que podem ser violados. Cabe ao Projetista analisar os requisitos do software

(ou sistema), a política da empresa e os riscos do produto para definir os mecanismos de

segurança física necessários.

3.5.3.2 Detalhamento do modelo de classe

Utilizar-se-á nessa atividade o diagrama de classes da UML para se realizar a

modelagem de classes do software.



84

O diagrama de classe do software integra mais um artefato da metodologia e será

identificado por Modelo de Análise de Projeto (MAP). Dependendo do tamanho do software,

diagramas de classes podem ser muito extensos, o que dificulta sua leitura e interpretação.

Assim sendo, o Gerente do Projeto pode optar por fazer um diagrama de classes para caso de

uso funcional (CUF). A METODES recomenda que seja feito um diagrama de classe para

cada CUF. Além disso, ao final da análise de todo o sistema, recomenda-se que haja, também,

um único diagrama de classe que represente todo o sistema.

O diagrama de classes oferece ao projeto de software uma abstração dos objetos,

identificando os componentes que fazem parte da classe, os atributos e métodos, criando um

modelo com uma melhor visão mais próxima do mundo real para criar programas executáveis

facilitando o entendimento do que será desenvolvido. Para isso o aluno deve, nessa tarefa,

tentar identificar as classes, os relacionamentos entre as classes e analisar o comportamento

delas, abstraindo o problema em nível de objetos. A atividade deve ocorrer quantas vezes

necessárias até termos um diagrama com detalhamento técnico suficiente para seguir para a

disciplina Construção.

O fluxo de atividades da disciplina Análise e Projeto da METODES põem um

fluxo paralelo de execução das atividades que se seguem neste texto, com o fim de promover

uma seqüência ordenada e prática de ações que precisarão ser tomadas para dar

prosseguimento a análise e projeto do software.

3.5.3.3 Projeto de interfaces gráficas

O projeto de interfaces gráficas atende principalmente ao usuário do software.

Essas interfaces precisam ser construídas de forma que qualquer pessoa, sem conhecimentos

técnicos aprofundados, consiga manusear o software.



85

Na METODES as interfaces gráficas são construídas de fato pelo Construtor, mas

essas interfaces, ou telas do sistema, são especificadas durante a análise e projeto do software.

Isso significa que o Projetista deve considerar, durante a realização dessa atividade, os

aspectos que podem refletir diretamente nas telas do software. Por exemplo, os atributos

visíveis em uma determinada tela, a exigência de um botão ou qualquer outro elemento da tela

necessário para a chamada de um método, ou elementos para a definição de parâmetros para

uma consulta, ou seja, aquilo que o Projetista perceber que esteja faltando nos protótipos

iniciais construídos.

3.5.3.4 Realização de casos de usos

A METODES adotou o diagrama de seqüência da UML para realizar os modelos

de caso de uso. Esse diagrama fará parte do Modelo de Análise e Projeto (MAP) e

representará a realização de um Caso de Uso Funcional (CUF).

Um diagrama de seqüência da UML é o aperfeiçoamento do modelo de caso de

uso. Fazendo uso das informações do modelo de classes, ele mostra a troca de mensagens

entre objetos ao longo do tempo na realização de uma operação. Não será possível realizar um

caso de uso sem as informações obtidas no diagrama de classes.

Os diagramas de seqüência na METODES integram a documentação do modelode análise de projeto (MAP). Deverá ser realizado, obrigatoriamente, um diagrama de

seqüência para cada caso de uso funcional (CUF). Os fluxos alternativos de operação podem

ser omitidos, desde que não comprometam o entendimento do Construtor para a tradução

desses diagramas para a linguagem de programação definida para o projeto.



86

3.5.3.5 Projeto de banco de dados

Após a atividade de Detalhamento do Modelo de Classe ocorrerá o Projeto de

Banco de Dados.

Essa atividade nada mais é que a tradução de um modelo de classes para a

linguagem de banco de dados definida para o projeto. Em caso de uso de uma linguagem de

banco de dados relacional, deverá ser produzido modelo entidade-relacionamento (MER),

juntamente com o modelo físico, ou seja, os scripts do banco de dados. Estes últimos também

integrarão o Modelo de Análise de Projeto (MAP).

3.5.3.6 Projeto de interfaces com sistemas

Nessa atividade deverão ser consideradas as interações do software em

desenvolvimento com outras aplicações, hardwares ou outras camadas de software. Essas

interações são consideradas interfaces externas ao sistema e são tratadas no projeto de

interfaces com sistema.

Essas interfaces externas podem ser outros sistemas ou consultas à base de dados.

Estando fora do escopo de atuação do software, em princípio pode ser considerada uma

interface externa.


Espera-se como resultados da disciplina Análise e Projeto da METODES, as

definições de projeto, arquiteturas e infra-estruturas, que possibilitarão a realização das

funcionalidades requisitadas pelo cliente do software. Além disso, é nessa disciplina que são



87

produzidos os artefatos que servirão como base para a construção dos códigos do software e

dos scripts do banco de dados.

3.6 Construção

3.6.1 Definição

A disciplina Construção da METODES tem como principal objetivo transformar

em códigos, na linguagem de programação definida na disciplina anterior, as classes de

objetos projetadas pelo Projetista. O Construtor, papel que realiza essa transformação, recebe

da disciplina Análise Projeto os Modelos de Análise de Projeto (MAP) juntamente com os

CUF relacionados para realizar sua tradução em códigos de linguagem.

O banco de dados, projetado em Análise e Projeto, também é construído nessa

disciplina, sendo o Construtor a pessoa responsável por construir os scripts de geração do

banco, bem como implementá-los. Na verdade, o Construtor é o papel que efetivará a solução

técnica proposta. Portanto, nessa fase da metodologia é mais correto se referir ao banco de

dados como Sistema Gerenciador de Banco de Dados (SGBD), pois as questões técnicas já

foram definidas, então, o banco de dados a ser utilizado, a plataforma de sistema operacional,

o hardware, enfim, toda a infra-estrutura já é conhecida.Os resultados da codificação do CUF e do MAP, incluindo as interfaces gráficas

que os atendem, são definidos na disciplina Construção da METODES como elementos de

software. O elemento de software é o conjunto de resultados produzidos por meio da

transformação, em linguagem de programação, dos CUF e MAP. Ou seja, telas do software,

classes codificadas, script do SGBD – mesmo que apenas parte desse script - e demais

componentes de software que tenham sido escritos pelo Construtor.



88

O fluxo de atividades da Construção é constituído por quatro atividades

interdependentes entre si. O fluxo de codificação de um requisito na METODES começa pela

construção da interface gráfica, seguindo adiante com a construção do elemento de software e

o teste desse elemento. Paralelo a isso é realizada a atividade Documentação, onde se inclui a

produção dos documentos dos códigos da classes, a documentação do usuário e a

documentação de instalação do software.

Devido ao grande número de documentos que devem ser gerados nessa disciplina,

outros papéis atuarão nessa atividade específica de documentação, o Documentador, que

ficará responsável pela documentação do usuário e trabalhará em conjunto com o Projetista

nessa disciplina na confecção dessa documentação. O Construtor ficará responsável pela

documentação dos códigos de unidades e pela finalização da documentação do banco de

dados, iniciada na disciplina Análise e Projeto.

Em um primeiro momento, pode parecer que há uma sobrecarga de trabalho de

documentação para os papéis envolvidos nessa etapa da METODES, contudo, considerando o

contexto acadêmico que a metodologia é aplicada, pode acontecer de um único aluno ficar

responsável por vários papéis distintos durante todo o processo de desenvolvimento. Sendo

assim, a sobrecarga de trabalho é gerada naturalmente devido a isso. Portanto, não haveria

efeitos práticos se a METODES adotasse vários papéis distintos para ficarem responsáveis

por cada tipo de documentação.



89

3.8 FLUXO DE ATIVIDADES DA DISCIPLINA CONSTRUÇÃO

3.6.2 Atividades

3.6.2.1 Construção da interface gráfica

Aqui devem ser geradas as interfaces gráficas do CUF que está sendo tratado de

acordo com a sua documentação e com as especificações do protótipo criado no detalhamento

de requisitos. A tarefa principal do Construtor nessa atividade é adequar os protótipos às

especificações técnicas e funcionais definidas na disciplina de análise, ou seja, aqui ele deve

rever os protótipos criados e verificar se a forma como foram construídos está de acordo com



90

o esperado pelo usuário do software.

Na Concepção há uma diretriz para se tentar identificar, se possível, já nas

definições de requisitos qual a provável linguagem de programação a ser utilizada para que os

protótipos iniciais sejam criados utilizando a mesma linguagem. A METODES também

define que os protótipos de interfaces devem ser construídos em uma linguagem visual

funcional para poder ser aproveitado na etapa de construção. Se essas diretrizes foram

seguidas o trabalho do Construtor restringirá à adequação das interfaces gráficas, caso

contrário ele deverá construir as interfaces gráficas seguindo os modelos apresentados ao

usuário no momento da validação dos requisitos.

3.6.2.2 Codificação do elemento de software

O Construtor recebe como insumo os artefatos produzidos na disciplina

Detalhamento de Requisitos e Análise e Projeto da METODES. Os artefatos necessários para

o trabalho de construção são os CUF e os MAP. Após a construção da interface de um CUF, o

Construtor codificará as funcionalidades envolvidas naquele CUF, seguindo as especificações

do diagrama de caso de uso que documenta o CUF e dos diagramas contidos nos MAP.

3.6.2.3 Teste do elemento de software

Testar a unidade significa simplesmente eliminar bugs e certificar-se que as

entradas de dados estão todas tratadas adequadamente. Além disso, quando for o caso,

verificar se os dados são gravados e recuperados com integridade no banco de dados.

O teste de unidade se limita às classes ou à unidade que está sendo tratada. A

tarefa de teste de conformidade com os requisitos definidos será realizada após a construção



91

de todas as classes que realizam um CUF. Por exemplo: considerando uma tela de cadastro de

fornecedores que utilize três classes distintas para que ela funcione. Quando essas três classes

estiverem construídas presume-se que todas foram testadas logo após a sua codificação, nesse

caso, esse primeiro teste realizado individualmente só foi considerado o funcionamento

daquela classe em questão. Depois disso há que se considerar se aquelas três classes estão

funcionando adequadamente para realizar o cadastro de fornecedores segundo os requisitos e

regras de negócio definidas pelo cliente.

O teste que verifica as conformidades com os requisitos e regras de negócio

definidas é denominado na METODES de Teste Funcional. É uma disciplina que ocorre logo

após a disciplina Construção. Para isso é necessário que o CUF esteja completamente

implementado, com sua interface gráfica e as possíveis interfaces com outros sistemas, além

das bases de dados implementadas e em funcionamento.

3.6.2.4 Documentação do elemento de software

Nessa atividade é gerada a documentação que a METODES considera essencial

para um projeto de software: o Manual do Usuário, o Manual de Instalação do Sistema e a

Documentação dos Códigos de Componente, além dos scripts de criação do banco de dados

que integrarão o Modelo de Análise de Projeto (MAP) de cada funcionalidade do sistema. Asinterfaces gráficas também necessitam ser documentadas, porém essa documentação ocorrerá

fatidicamente quando for gerado o Manual do Usuário, pois esse documento deve conter as

telas do software impressas para melhor compreensão do usuário.



92

3.6.2.4.1 Documento de código de componente

Esse documento se configura como mais um artefato da disciplina Construção da

METODES. Basicamente, nele deve conter a descrição da classe, a descrição dos atributos e

métodos enfatizando os argumentos de entrada e saída dos métodos, além do código da classe.

Assim como os outros, esse artefato será descrito e detalhado em um capítulo posterior.

3.6.2.4.2 Manual do usuário

Esse manual de operação do software para o usuário final. Ele deve conter as telas

que fazem a interface com o usuário com a indicação de como deve ser feita as entradas de

dados, os fatores que condicionam essa entrada, as mensagens de alerta previstas pelo

software, a descrição dos campos e demais elementos da interface, como caixas de texto e

botões.

O Manual do Usuário deve ser claro o suficiente para que o usuário compreenda

qual o propósito de cada tela do software, suas entradas e os resultados que dela ele pode

esperar.

Nessa atividade o Documentador e o Projetista trabalharão em conjunto para

produzir a documentação do usuário. O Documentador fica responsável por criar o texto ediagramar os documentos. O Projetista fica responsável por fornecer o suporte necessário ao

Documentador, por conhecer em detalhes como é realizada cada funcionalidade do sistema. O

Construtor também pode auxiliar nessa atividade, sendo o Projetista o papel mais indicado

para essa função.



93

3.6.2.4.3 Manual de instalação do software

Dependendo das características do software desenvolvido, esse manual de

instalação pode se tornar um documento bastante extenso e por demais técnico. Não se trata

da instalação de um componente do software, mas sim de toda a solução técnica empregada

para resolver um problema. Dessa forma, os procedimentos para instalação e configuração do

ambiente de banco de dados, serviços empregados na solução, como Web Server , FTP,

servidores de arquivos, enfim, todo o conjunto de serviços que são essenciais para que o

sistema funcione com todas as funcionalidades definidas no escopo do projeto.

O Construtor é o papel mais indicado para essa função. Porém, dependendo do

projeto, o Analista de Implantação pode também exercer essa função. Tudo dependerá do

nível de detalhamento técnico que a documentação exigirá.

O manual de instalação do sistema precisa estar escrito de tal forma que uma

pessoa que não tenha participado do processo de desenvolvimento, mas que tenha

conhecimentos técnicos suficientes e adequados, consiga instalar o sistema e deixá-lo em sua

forma operacional.


Ao final da disciplina Construção da METODES espera-se, como resultados, as

classes implementadas e documentadas, incluindo os manuais de operação para o usuário e os

procedimentos para a instalação do sistema.



94

3.7 Teste Funcional

3.7.1 Definição

A METODES define dois objetivos para os testes funcionais:

O primeiro é a verificação de conformidade entre requisitos definidos e caso de

uso funcional (CUF) construídos, ou seja, trata-se de uma avaliação dos resultados obtidos até

a disciplina Construção em relação ao que foi definido como requisitos essenciais e desejáveis

pelo cliente na disciplina Concepção.

O segundo objetivos é avaliação das soluções definidas para os requisitos não-

funcionais. Para cada requisito não-funcional em questão, essa avaliação deve ser realizada

em conjunto com o demandante do software, usuários e o Gerente de Relacionamento. Uma

vez obtida a satisfação do usuário, considerar-se-á os requisitos não-funcionais atendidos.

Os testes funcionais deverão ser planejados e adequados para cada tipo de

software de pelo Analista de Testes, tendo este que analisar o software de maneira imparcial,

considerando apenas o que está definido como requisito e o CUF que ele está analisando. O

Analista de Teste pode, a qualquer momento, convocar qualquer outro papel da METODES

para compor equipe irá executar o Plano de Realização do Teste Funcional.



95

3.9 FLUXO DE ATIVIDADES DA DISCIPLINA TESTE FUNCIONAL

3.7.2 Atividades

Na primeira iteração de um projeto METODES as atividades dessa disciplina

deverão ser iniciadas. Se possível algumas delas devem ser realizadas por completo visando

aperfeiçoar a realização dos testes funcionais para as demais iterações. Um exemplo é a

atividade de Elaboração do Plano de Realização do Teste Funcional e a Definição do

Ambiente Operacional para Testes, duas atividades que estar definidas já na primeira iteração

do projeto do software.



96

3.7.2.1 Elaboração do Plano de Realização do Teste Funcional

Essa atividade visa definir as ações e papéis necessários para a realização e

avaliação dos da disciplina Testes Funcionais.

O Plano de Realização do Teste Funcional é um artefato da metodologia que

define um plano de trabalho para realização das ações essenciais que devem ocorrer para que

os objetivos dos testes funcionais sejam cumpridos. Esse e os outros artefatos serão tratados

em um capítulo posterior.

3.7.2.2 Definição de ambiente operacional para teste

Definir um ambiente operacional é montar um ambiente mínimo que seja

suficiente para executar o Plano de Realização do Teste Funcional. Para os requisitos

funcionais não são necessários que todos os componentes da infra-estrutura, como servidores

de rede e topologia física da rede, sejam considerados exatamente como definidos no projeto,

sobretudo na Análise e Projeto, para os testes, desde que isso não comprometa os resultados.

Porém, para testes dos requisitos não-funcionais que dependem de alguma forma das

definições da disciplina Análise e Projeto, devem ser fidedignas em relação ao que foi

definido e projetado. Como nem sempre isso será possível, admite-se que alguns testesfuncionais possam ser realizados em paralelo à disciplina Implantação.

3.7.2.3 Executar Plano de Realização do Teste Funcional

Por em prática o que foi definido no Plano de Realização do Teste Funcional,

documentando todos os resultados para posterior avaliação.



97

O Analista de Teste convocará os papéis definidos para a execução do plano para

que executem as ações definidas e as documentem o que foi previsto pela equipe de Análise e

Projeto e o que foi observado por eles.

3.7.2.4 Avaliação de resultados

Após a execução do Plano de Realização do Teste Funcional, consegue-se extrair

as não-conformidades encontradas no desenvolvimento do software, podendo assim submetê-

las à disciplina de Gestão de Projeto para tratamento adequado.

Na Gestão de Projeto o Gerente de Mudança recebe e trata a solicitação como

uma Solicitação de Mudança de Projeto. Nessa atividade da Gestão de Projeto o Gerente de

Projeto identificará, quando possível, aonde a não-conformidade deverá ser tratada. Não

sendo possível ele encaminhará o tratamento para disciplina Detalhamento dos Requisitos,

passando subsequentemente por todas as disciplinas da METODES.

Uma vez dado seguimento ao tratamento da não-conformidade a disciplina

responsável deve analisar e corrigir a não-conformidade encontrada.

Não havendo não-conformidades nos casos de uso funcional (CUF) testados,

passa-se para a disciplina Implantação.


A disciplina Testes Funcionais da METODES prevê como resultado a detecção e,

quando possível, dentro do prazo para execução da disciplina, estabelecido na elaboração do

Plano de Realização do Teste Funcional, a correção de não-conformidades do software como

um todo do CUF desenvolvido.



98

Se as não-conformidades detectadas não puderem ser resolvidas dentro do prazo

de execução dos testes funcionais, será necessária uma avaliação do impacto que a resolução

dessas não-conformidades causará no cronograma do projeto. Assim o Gerente de

Relacionamento pode tratar como com o demandante do software os ajustes necessários nos

prazos do projeto.

Nem sempre serão necessários ajustes nos prazos do projeto devido às não-

conformidades encontradas. Elas podem, por exemplo, ser tratadas durante novas iterações do

processo de desenvolvimento. O importante é que a resolução de não-conformidades não

comprometa o prazo final do projeto.

3.8 Implantação

3.8.1 Apresentação

Implantar um sistema significa torná-lo operacional para o cliente. Portanto,

quando um sistema está pronto para ser utilizado pelo usuário, com dados e situações reais,

considera-se que ele esteja implantado.

A implantação de um sistema pode ocorrer de uma só vez, ou seja, depois dele

todo construído é que se inicia o processo de implantação. Outra opção é implantar o sistemaà medida que releases funcionais do sistema são disponibilizadas. Na METODES isso

significa desenvolver um caso de uso funcional (CUF) por completo, ou seja, após ter passado

pelo detalhamento do requisito, análise e projeto, construção e testes e chegado a uma

situação que se possa utilizar a funcionalidade que o caso de uso funcional representa.



99

Após passar por todas essas disciplinas citadas, a infra-estrutura necessária para o

software já teria sido concebida, definida e instalada, pelo menos o mínimo necessário para

fazer funcionar o primeiro release de software disponibilizado.

Preferencialmente, recomenda-se que a implantação do software na METODES

seja realizada de forma gradual para que se possa usufruir de fato das vantagens de se

desenvolver um software de forma iterativa e incremental, além de permitir nessa forma de

implantação uma avaliação mais precisa da infra-estrutura projetada.

3.10 FLUXO DE ATIVIDADES DA DISCIPLINA IMPLANTAÇÃO



100

3.8.2 Atividades

As atividades da disciplina Implantação da METODES visam colocar em prática

todos os aspetos de arquitetura, infra-estrutura e segurança que foram definidos em Análise e

Projeto.

Como esses aspectos dependem diretamente das características e particularidades

do software e também podem envolver procedimentos técnicos para serem implementados

participarão dessa disciplina o Analista de Implantação, responsável pela coordenação e

execução de um plano de implantação, o Construtor e o Projetista.

O treinamento do usuário no software também acontece nessa disciplina, portanto,

o manual de instalação, manual de operação do software fazem parte da implantação e devem

ser entregues formalmente aos usuários do sistema. Caso sejam necessários ajustes, que não

impliquem em grandes alterações de formato ou conteúdo dos manuais entregues, estes

devem ser realizados nessa mesma disciplina junto com o usuário. Porém, se os ajustes

necessários implicarem em alterações que comprometam muito a forma ou o conteúdo desses

manuais devem ser submetidos à Gestão do Projeto e ser tratado como uma solicitação de

mudança.

3.8.2.1 Plano de implantação

Elaborar e obter a aprovação do demandante do software são as principais tarefas

nessa atividade.

O plano de implantação deverá conter as ações detalhadas para tornar o software

operacional para o usuário. Para isso deve-se elaborar um cronograma de trabalho, acordado



101

com o cliente, além de definir metas e objetivos que devem ser alcançados durante o processo

de implantação.

3.8.2.2 Documentação do usuário

Nessa atividade a documentação do usuário produzida na disciplina Construção

será formalmente entregue ao cliente e validada por ele. As documentações pertinentes ao

usuário do software são: o manual de instalação e o manual de operação do software.

O manual de instalação contém os procedimentos e demais condições necessárias

para a instalação do software. Nesses procedimentos são citados somente os detalhes

procedimentais de instalação que um usuário comum possa executar, como por exemplo, a

instalação de um front-end , a configuração de um navegador Web, instalação de um setup,

enfim, procedimentos ínfimos que sejam necessários para que o usuário consiga acesso às

interfaces do software.

O manual de operação apresenta os aspectos práticos para operação do software,

com demonstrações das interfaces que os usuários interagirão e demais processos que fazem

parte das interações que a interface promove.

3.8.2.3 Implementação de arquitetura e segurança

Aqui devem ser implementados todos os aspectos de arquitetura e segurança

considerados na disciplina Análise e Projeto que ainda não tenham sido implementados nas

disciplinas anteriores.

O primeiro passo do Analista de Implantação é verificar as soluções definidas nos

documentos produzidos na disciplina Análise e Projeto e providenciar que as soluções sejam



102

implementadas. Normalmente, o que se deixa para implementar dessas soluções definidas são

aquelas que estão além dos aspectos técnicos da solução ou que dependiam de todo o sistema

construído para implementá-las, como, por exemplo, as questões de segurança física de

ambiente.

3.8.2.4 Implementação de infra-estrutura

Basicamente as mesmas considerações que faz na atividade anterior devem ser

feitas nessa também. A única diferença é o foco e os documentos analisados, pois aqui devem

ser considerados os aspectos de infra-estrutura que ainda não tenham sido implementados nas

disciplinas anteriores da METODES.

3.8.2.5 Instalação do software

Após terem sido revistos os aspectos de arquitetura, segurança e infra-estrutura,

passa-se a instalação de fato do software. Isso compreende toda e qualquer instalação

necessária para que o software funcione como projetado. Portanto, formalmente, a instalação

do SGBD, dos sistemas operacionais dos servidores, servidores Web, frameworks, enfim,

todos os softwares que dá suporte ao software, são instalados nessa atividade, considerandoque o software não esteja sendo desenvolvido no mesmo ambiente onde funcionará.

Na hipótese de o software estar sendo desenvolvido no mesmo ambiente onde

funcionará, essas instalações podem ser realizadas após a disciplina Análise e Projeto, para

que o Construtor escreva e teste os códigos do software já no ambiente operacional do

software. Considerando essa hipótese, as instalações mencionadas nessa atividade devem ser

revisadas e adequadas segundo as definições do projeto.



103

3.8.2.6 Treinamento do usuário

O foco dessa atividade é a elaboração de um treinamento que aborde os aspectos

funcionais do software, ou seja, não é necessário que o usuário qual é SGBD que está sendo

utilizado e nem por que ele foi escolhido. Deve ser transmitido ao usuário como utilizar o

sistema para que se tire o maior proveito possível e em que o software afetará em sua rotina

normal de trabalho.

A METODES sugere uma ementa básica para o treinamento. Essa ementa deve

ser apresentada, adequada e validade junto ao demandante do software. Além disso, devem

ser acordados o local e carga horária do treinamento de acordo com a disposição do cliente e

com as condições iniciais indicadas no Plano de Projeto do projeto METODES.

A ementa básica contempla os seguintes itens:

1. Apresentação do Software1.1. Público alvo

1.2. Descrição

1.3. Objetivos

1.4. Alinhamento com o negócio da empresa

2. As Funções do Software

2.1. Descrição básica da infra-estrutura

2.2. Cadastro e autenticação de usuários do software

2.3. Descrição de perfis de usuários2.4. Descrição das funcionalidades

3. Outras opções3.1. Descrição e tratamento de erros conhecidos

3.2. Procedimentos de backup e restore

3.3. Manutenção e Suporte Técnico

A ementa proposta apresenta apenas alguns tópicos que são importantes para o

treinamento de um software, porém, não significa que seja suficiente e nem mesmo adequado

para ser aplicado em um projeto de software. Cada tipo de software exige uma ementa



104

específica para treinamento que deve ser elaborada com o demandante e os usuários do

software.

3.8.2.7 Formalização do aceite do software

Ao final de todos os procedimentos o Analista de Implantação deve apresentar ao

demandante do software um documento que contenha explicitamente a conivência com a

forma e o resultado de todos os procedimentos realizados para a implantação do software,

bem como, a concordância com todas as funcionalidades do software fornecidas no estado

como se apresentarem após a completa implantação.

Esse documento deve ser apresentado somente após todas as iterações da

METODES que forem necessárias para a completa implantação do software. Isso significa

que todos os casos de uso funcional e todas as questões de arquitetura, infra-estrutura e

segurança tenham sido resolvidas.


Considerando que o desenvolvimento do software esteja sendo realizado de forma

iterativa e incremental, a implantação dele se dará, também, dessa forma. Assim sendo,espera-se que ao final de todas as iterações necessárias se tenha o software implantado por

completo.

Mais uma vez é importante ressaltar que para a METODES, um software

implantado significa que todos os requisitos funcionais e não-funcionais definidos no

Documento de Visão e Escopo foram atendidos, considerando nesse atendimento as questões

de arquitetura, infra-estrutura e segurança. Um software implantado pela METODES também



105

contempla o treinamento do usuário e, principalmente, o documento de aceite formal do

software assinado pelo demandante do software.



106

4 METODES - ARTEFATOS

Cada disciplina da METODES tem como resultado um conjunto de artefatos do

projeto, cada qual com sua finalidade e objetivo. O modelo de cada artefato produzido na

METODES está presente, sob a forma eletrônica, no guia em formato WEB da metodologia.

A tabela 4.1 é uma síntese dos artefatos produzidos na METOODES. Neste

trabalho, alguns dos artefatos foram anexados para fins de demonstração.

4.1 TABELA DE ARTEFATOS

Disciplina ArtefatoConcepção DVE - Documento de Visão e Escopo

PPS - Plano de Projeto de Software

DSM - Documento de Solicitação de MudançaCAP - Controle de Artefatos do ProjetoPRP - Planilha de Resultados de Projeto

Gestão do Projeto

PCR - Planilha de Controle de RequisitosCUF - Caso de Uso FuncionalDRNF - Documentação do Requisito Não-funcionalDetalhamento de RequisitosTAR - Termo de Aceite do RequisitoMVAS - Modelagem da Visão de Arquitetura de Software

MVAC - Modelagem da Visão de Arquitetura de ComunicaçãoDIAF - Documentação da Infra-estrutura de Ativos FísicosDIS - Documentação da Infra-estrutura de Software

MVS - Modelagem da Visão de Segurança

Análise e Projeto

MAP - Modelo de Análise de ProjetoDCC - Documentação de Código de ComponenteMOU - Manual de Operação do UsuárioConstrução

MIS – Manual de Instalação do SoftwarePRTF - Plano de Teste

Teste FuncionalPRT - Planilha de Resultados de TestesPI - Plano de ImplantaçãoPT - Plano de TreinamentoImplantaçãoTAS - Termo de Aceite do Software



107

5 METODES - PAPÉIS

Os papéis da METODES são funções a serem representada, com perfis

profissionais específicos, que interagem no processo de desenvolvimento do software. A

maioria dos papéis pode ser representada por um ou mais membros da equipe de projeto. Do

mesmo modo, um membro dessa equipe também pode representar mais de um papel durante a

realização do projeto.

Os perfis profissionais dos papéis sugeridos pelo METODES estão descritos sob

forma de recomendações, e não caracterizam uma condição sine qua non para que um

membro da equipe do projeto exerça algum papel. Além disso, alguns papéis podem não

exigir requisitos profissionais específicos. Porém, é necessário que todos os membros da

equipe de projeto tenham conhecimentos a cerca das atividades de para todos os papéis será

necessário o conhecimento geral dos fundamentos da informática.

5.1 Descrição dos Papéis

5.1.1 Gerente de relacionamento

O Gerente de Relacionamento é o papel responsável pela intermediação docontato entre a equipe de projeto e o cliente, e deverá ser representado, preferencialmente, por

uma única pessoa, para simplificar e facilitar a comunicação entre as partes. Entretanto,

dependendo do tamanho e das características do projeto, mais de uma pessoa pode assumir o

papel.

É desejável para a pessoa que exercerá esse papel ter em seu perfil profissional

requisitos como boa fluência na comunicação, noções de gestão de projetos e conhecimentos



108

dos fundamentos da computação. Não são necessários conhecimentos técnicos profundos, no

entanto, é imprescindível ter uma fundamentação técnica global para melhor compreensão e

análise do problema.

As responsabilidades do Gerente de Relacionamento são:

Agendar reuniões e entrevistas com os usuários;

Negociar ajustes de prazos, custos e escopo do projeto;

Obter aprovação formal do cliente dos documentos

Apresentar ao cliente as releases do software produzido;

Comunicar ao cliente sobre o andamento e resultados do projeto.

5.1.2 Gerente de projeto

O Gerente de Projeto é o responsável pela coordenação e controle das atividades

necessárias para o desenvolvimento do software. É ele quem elabora e põe em prática a

execução do Plano de Projeto, verificando o cronograma, ajustes de orçamento, mitigando

riscos, enfim, cumprindo o planejamento definido no início do projeto METODES.

Dentre os requisitos desejáveis para o perfil profissional que representará esse

pape estão: domínio de técnicas de gerenciamento de projeto, conhecimento de técnicas de

estimativa de prazo e custos de projeto, liderança, além dos conhecimentos técnicos gerais a

cerca das tecnologias de informática.

As responsabilidades do Gerente de Relacionamento são:

Elaborar Plano de Projeto;

Estimar prazos e custos do projeto;

Formar equipe e distribuir papéis;

Coordenar as atividades dos outros gerentes da METODES;



109

Alocar recursos ao projeto e verificar como estão sendo consumidos ao logo

do processo de desenvolvimento do software;

Avaliar qual será o impacto causado no projeto devido às solicitações de

mudança.

5.1.3 Gerente de artefato

O Gerente de Artefatos é o papel responsável por manter a atualização dos

artefatos da METODES. Isso significa que quando houver qualquer mudança que reflita em

uma alteração de artefatos, estes devem ser atualizados e suas versões antigas guardadas para

a formação de um histórico de controle de artefatos.

Basicamente, é responsabilidade do Gerente de Relacionamento manter o

histórico e controle dos artefatos da METODES, por meio da Planilha de Controle de

Artefatos.

5.1.4 Gerente de mudanças

O Gerente de Mudanças da METODES é o responsável por receber e encaminhar

as solicitações de mudança de projeto e manter atualizada a Planilha de Alteração de Escopo

de Projeto (PAEP). Ou seja, qualquer solicitação de alteração, seja por parte do cliente ou dos

analistas da equipe, no escopo do projeto ou nos resultados já produzidos (artefatos), é o

Gerente de Mudanças quem receberá essas solicitações e enviará os resultados delas a que as

solicitou.

O trabalho do gerente de mudanças pode em alguns casos se limitar a

simplesmente encaminhar as solicitações de mudanças para os responsáveis que irão tratá-las,



110

como no caso de alteração de artefatos. Quando se tratar de alteração do escopo do projeto,

estas deverão ser analisadas pelo Gerente de Projeto que irá deferir ou indeferir as mudanças

solicitadas. Então, o Gerente de Mudanças atualiza a PAEP e devolve o resultado do

julgamento do Gerente de Projeto aos que solicitaram a mudança para que, em caso de

deferimento, tomem as providências necessárias.

A figura 5.1 representa o fluxo de tratamento de solicitação de mudança. As setas

vermelhas indicam o fluxo para alteração de artefatos, onde não há a necessidade de

apreciação do Gerente de Projeto por se tratar de casos em que a solicitação partiu dos

analistas da equipe do projeto.

5.1 FLUXO DO TRATAMENTO DE SOLICITAÇÃO DE MUDANÇA

Gerente de

Relacionamento

Cliente

Gerente de

Mudanças

Gerente de

Projeto Analistas da

Equipe de Projeto

Solicitação de mudança

8. Defereimento / indeferimento

das solicitações

Gerente de

Artefato

Alteração

de artefatos

3. Encaminhamento da solicitação para

avaliação de impacto

1. Solicitação de mudança de escopo

2. Encaminhamento da solicitação

para tratamento

7. Deferimento / indeferimento da solicitação.

Informações para atualização do PAEP

4. Necessidades de ajustes de

prazos e custos do Projeto.

5. Comunicar os ajustes de prazos e custos e

obter aprovação do Cliente.6. Ajustes aprovados / reprovados pelo Cliente



111

5.1.5 Gerente de qualidade

O Gerente de Qualidade é o papel responsável por conferir o andamento do

projeto observando o que foi especificado no Plano de Projeto. O Gerente de Qualidade

mantém a Planilha de Resultado de Projeto (PRP), que servirá de instrumento para que se

possa aferir a qualidade do Software desenvolvido segundo os padrões de qualidade definidos

na METODES.

5.1.6 Gerente de requisitos

O controle de requisitos é realizado pelo Gerente de Requisitos, que atuará

constantemente durante todo o ciclo de vida do requisito. Esse ciclo de vida compreende

desde o momento em que o requisito é definido na disciplina Concepção, passando pela

disciplina de Detalhamento de Requisitos, até sua construção, considerando nesse fluxo as

possíveis revisões e alterações que podem ocorrer.

As responsabilidades do Gerente de Requisitos são:

Manter atualizada a Planilha de Controle de Requisitos;

Requisitar agendamento de reuniões com o cliente/usuários;

Coordenar as reuniões entre usuários Analistas de Requisitos;

Providenciar homologação e aprovação dos requisitos junto ao cliente.

5.1.7 Analista de requisitos

O Analista de Requisitos é o responsável por interpretar e detalhar e documentar

os requisitos apresentados pelo cliente.



112

O profissional que exercerá o papel de Analista de Requisitos deve ter o domínio

pleno do negócio, por isso ele participa da disciplina Concepção da METODES.

5.1.8 Prototipador

O Prototipador trabalhará em conjunto com o Analista de Requisitos na

construção de protótipos visuais do software que correspondam aos requisitos apresentados

pelo cliente. Esse protótipo tem o objetivo de demonstrar uma interface gráfica não-funcional

para facilitar a interpretação dos requisitos expostos pelo cliente.

Para o profissional que exercerá esse papel é bastante recomendável que tenha

conhecimentos específicos na construção de interfaces homem-máquina, conhecimentos de

designer gráfico, além dos conhecimentos gerais da análise de sistemas.

5.1.9 Projetista

O Projetista é um dos principais papéis a serem exercidos em um projeto

METODES. Esse papel é o responsável por projetar a arquitetura e a infra-estrutura que

suportarão a solução apresentada ao cliente no Documento de Visão e Escopo.

A METODES considera vários aspectos de arquitetura e infra-estrutura a seremconsiderados pelo Projetista. Cada um desses aspectos, citados na descrição da disciplina

Análise e Projeto, é responsabilidade do Projetista.

Para perfil profissional da pessoa que exercerá o papel de Projetista é

extremamente recomendado que se tenha domínio do problema, conhecimentos sólidos de

padrões de projeto e arquitetura de software e domínio da linguagem da UML. Esses são



113

apenas requisitos específicos de conhecimento, sendo, portanto, também necessários

conhecimentos dos fundamentos gerais da informática.

As principais responsabilidades do Projetista são:

Desenhar o modelo de classes dos Casos de Uso Funcionais;

Especificar e descrever os requisitos não-funcionais;

Desenvolver e realizar os Casos de Uso Funcionais;

Desenvolver o modelo entidade-relacionamento.

5.1.10 Construtor

O Construtor é o papel responsável por implementar os modelos criados pelo

Projetista. Isso significa transformar a modelagem dos requisitos em códigos de linguagem de

programação. Entre as responsabilidades do Construtor estão a instalação e configuração do

SGBD e a implementação dos scripts do banco de dados.

O perfil desejável para o profissional que exercerá o papel de Construtor na

METODES é de uma pessoa com domínio na linguagem de programação definida para o

projeto e conhecimentos sólidos no SGBD escolhido.

5.1.11 Documentador

O Documentador é papel responsável por coordenar a elaboração da

documentação do software que cabe ao usuário. Para a METODES essa documentação

compreende o Manual do Usuário (Manual de Operação do Software) e o Manual de

Instalação do Sistema.



114

O Documentador atuará em conjunto com o Projetista e o Construtor na

elaboração dos manuais citados.

Os requisitos para o perfil profissional da pessoa que exercerá esse papel são:

Possuir boa redação;

Facilidade na interpretação

Noções de diagramação de documentos.

5.1.12 Analista de testes

O Analista de Testes é o papel responsável por elaborar, coordenar e executar as

atividades dos Testes Funcionais da METODES. Esse papel tem também a responsabilidade

de providenciar a infra-estrutura de testes necessária para que estes aconteçam. Além disso, é

o Analista de Testes que avaliará os resultados dos testes e tomará as providências cabíveis

quanto aos resultados.

As responsabilidades principais do Analista de Teste são:

Elaborar Plano de Realização do Teste Funcional;

Providenciar infra-estrutura para testes;

Executar Plano de Realização do Teste Funcional;

Avaliar resultados dos testes.

5.1.13 Analista de implantação

O Analista de Implantação é o papel responsável por coordenar os trabalhos de

implantação do software desenvolvido.



115

As principais responsabilidades desse papel são as atividades descritas na

disciplina Implantação da METODES.

O profissional que exercerá esse papel poderá realizar procedimentos técnicos de

instalação e configuração de softwares nas atividades da Implantação, portanto, essa pessoa

precisa ter conhecimentos técnicos suficientes para realizar esses procedimentos.

O Analista de Implantação trabalhará em conjunto com o Gerente de

Relacionamento por haver bastante interação com cliente na disciplina Implantação.



116

6 METODES - FERRAMENTAS

6.1 Recomendações da METODES

A METODES recomenda um conjunto de softwares e ferramentas, entre elas as

do tipo CASE (Computer Aided Software Engineering), para auxiliar a realização das

atividades das disciplinas da METODES. A utilização dessas ferramentas não é arbitrária e

nem mesmo obrigatória, apresenta-se apenas como uma opção para auxílio na execução de

um Projeto METODES.

As ferramentas apresentadas são apenas algumas opções dentre as muitas

disponíveis no mercado para os mesmos fins. Outras ferramentas podem ser necessárias para

um projeto de software, ou simplesmente adotadas para maior conforto e produtividade das

pessoas que as utilizarão diretamente.

6.2 Modelagem de banco de dados

6.2.1 Dbdesigner 4

Uma ferramenta de modelagem de banco de dados desenvolvida e otimizada parautilização com o MySQL, provendo aos seus usuários uma forma simples e centralizada para

a definição dos seus modelos de dados. O código do DBDesigner 4 é OpenSource é

distribuído sob a licença GPL (General Public License) e tem compilações disponíveis para

Windows e Linux.



117

6.2.2 Mogwai ER-Designer

Mogwai ER-Designer é uma ferramenta visual de modelagem de banco de dados

parecida com o ERWin, porém com código OpenSource e licença GPL. Construído em Java é

independente de plataforma de sistema operacional, tendo como requisito apenas uma

máquina virtual Java.

Essa ferramenta trabalha com MySQL , PostgreSQL and Oracle e foi projetada

para permitir que suas funcionalidades sejam estendidas com a simples instalação de plug-ins.

O Mogwai ER-Designer tem um interessante recurso, o IVT ( Intelligent version tracking) que

mantém um histórico de mudanças do esquema do banco de dados. Ele também possibilita a

engenharia reversa de bancos de dados.

6.3 Administração de banco de dados

6.3.1 MySQL Administrator

O MySQL Administrator é um console de administração visual que o permite

facilmente administrar o ambiente MySQL, com possibilidades de verificar visualmente o

estado das bases de dados em operação. O MySQL Administrator agora integra a gerência e amanutenção da base de dados em um único ambiente, com uma interface gráfica leve e

intuitiva. Disponível também para Windows, MacOSX e Linux sob a licença GPL e licenças

comerciais.



118

6.3.2 MySQL Query Browser

Ferramenta visual utilizada para criar, otimizar e executar queries para bancos de

dados MySQL. Além disso, oferece suporte para criação e modificação de tabelas e um editor

de sentenças SQL. Está disponível para Windows, MacOSX e Linux sob a licença GPL (para

uso em sistemas não-comerciais) e também sob licenças comerciais.

6.3.3 PgAdmin

O PgAdmin III é o software de administração do PostgreSQL desenvolvido para

ajudar os usuários a construir código extremamente complexos. Trabalha com as plataformas

Windows, 2GNU/Linux e FreeBSD. Inclui uma interface administrativa gráfica, ferramentas

de SQL e editor de código.

6.3.4 SQL Lite

Trata-se de gerenciador gratuito para banco de dados SQL Server, MSDE

( Microsoft SQL Server Desktop Engine) e Microsoft Access. É possível criar, excluir e alterar

tabelas e campos, definir chaves e tipos de dados. Possui sistema de consulta com suporte a T-SQL, podendo apenas digitar comandos manualmente e executar as instruções com suporte

para Views, Procedures, Triggers, Functions, etc. Programa escrito em Visual Basic 6 e

disponível apenas para a plataforma Windows.

2 GNU é um acrônimo recursivo para “GNU Não é UNIX” e é pronunciado como “guh-noo”. Fonte:http://www.gnu.org/home.pt.html.



119

6.4 IDE (Integrated Development Environment) e Linguagens

6.4.1 Eclipse

O Eclipse é uma das IDEs mais populares, atualmente para desenvolvimento em

plataforma Java e considerado uma das ferramentas chaves em se tratando de iniciativas

OpenSource. A IDE eclipse possui facilidades para os desenvolvedores como a visualização

de todos os arquivos contidos no projeto de forma clara e ferramentas de gerenciamento de

trabalho coletivo.

6.4.2 NetBeans

Uma IDE que reúne características especificas e ferramentas de apoio ao

desenvolvimento de software, com o objetivo de agilizar este processo, permitindo que os

desenvolvedores obtenham um aproveitamento maior e desenvolvendo códigos com maior

rapidez.

6.4.3 PHP 5

É uma linguagem muito interessante, de sintaxe cômoda e similar a outras

linguagens como o C e o C++. É rápido para ser interpretado e dispõe de uma grande

biblioteca que facilita muitíssimo o desenvolvimento de suas aplicações. PHP é uma

linguagem ideal tanto para quem começa a desenvolver aplicações para a web ou para quem é

um desenvolvedor experiente.



120

6.4.4 J2SE

O J2SE ( Java 2 Standard Edition) é o ambiente de desenvolvimento mais

utilizado. Isso porque seu uso é voltado a PCs e servidores, onde há bem mais necessidade de

aplicações. Além disso, pode-se dizer que essa é a plataforma principal, já que, de uma forma

ou de outra, o J2EE e o J2ME tem sua base aqui. Pode-se dizer que esses ambientes de

desenvolvimento são versões aprimoradas do J2SE para as aplicações a que se propõem.

6.4.5 J2EE

O J2EE ( Java 2 Enterprise Edition) é a plataforma Java voltada para redes,

Internet, Intranets e afins. Assim, ela contém bibliotecas especialmente desenvolvidas para o

acesso a servidores, a sistemas de e-mail, a banco de dados, etc. Por essas características, o

J2EE foi desenvolvido para suportar uma grande quantidade de usuários simultâneos.

A plataforma J2EE contém uma série de especificações, cada uma com

funcionalidades distintas. Entre elas, tem-se:

JDBC ( Java Database Connectivity), utilizado no acesso a banco de dados;

JSP ( Java Server Pages), um tipo de servidor Web. Grossamente falando,

servidores Web são as aplicações que permitem a você acessar um sítio na

internet;

Servlets, para o desenvolvimento de aplicações Web, isto é, esse recurso

"estende" o funcionamento dos servidores Web, permitindo a geração de

conteúdo dinâmico nos sítios Internet.



121

6.5 Servidores Web

6.5.1 Apache

O servidor Apache (Apache Server) é servidor Web de código livre que roda sobre

as plataformas Windows e Linux. Oferece suporte à instalação de componentes extras para

suporte de linguagens como PHP e Pearl. Possui licença GPL e também licença para uso

comercial.

6.5.2 Tomcat

É um servidor de aplicações Java para Web que se integra ao servidor Apache.

Roda em Windows, Solaris e Linux, além de Mac OS X, HP-UX e FreeBSD. O Tomcat é

distribuído e licenciado sob as mesmas condições do servidor Apache.

6.5.3 IIS - Internet Information Services

Servidor proprietário da Microsoft que permite a utilização de sistemas Web

desenvolvidos nas linguagens, também proprietárias, da empresa: ASP (Active Server Pages)e .Net.

Sua licença está condicionada ao licenciamento da versão do sistema operacional

Windows Server 2003.



122

6.6 Controle de Versão

6.6.1 CVS

É um sistema de controle de versão que permite que se trabalhe com diversas

versões de arquivos, organizando-os em diretórios e sendo localizados local ou remotamente,

mantendo-se suas versões antigas e os logs de quem e quando manipulou esses arquivos. É

especialmente útil para se controlar versões de um software durante seu desenvolvimento, ou

para composição colaborativa de um documento.

6.7 Gestão de projeto

6.7.1 DotProject

É uma ferramenta Opensource desenvolvida em PHP para gerência de projetos de

fácil utilização, com um bom conjunto de funcionalidades e características que o tornam

interessante para utilização em ambientes de corporativos.

6.8 Modelagem visual (UML)

6.8.1 Jude Community

Uma das ferramentas gratuitas para UML mais poderosas disponíveis. Com

características que não são encontradas nas outras ferramentas grátis, como adicionar métodos

no diagrama de seqüência e a alteração se refletirem no diagrama de classes.



123

Seu desempenho impressiona principalmente tratando-se de uma ferramenta 100%

Java/Swing, desmistificado que Swing é lento.

6.9 SGBD - Sistema gerenciador de banco de dados

6.9.1 Mysql 5

O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza

a linguagem SQL(Structured Query Language) como interface. É atualmente um dos bancos

de dados mais populares, com mais de 4 milhões de instalações pelo mundo e com a versão

5.0. O MySQL incorporou mais recursos avançados ao sistema, incluindo views , triggers,

storage procedures e suporte a transações.

6.9.2 Oracle Express Edition 10g

Banco de dados Oracle, em uma versão mais leve para estudantes e

desenvolvedores. Essa versão light do Oracle é uma tentativa da Oracle de popularizar seu

banco de dados para pequenos desenvolvedores, assim como o MySQL vem fazendo há muito

tempo. Sua limitação é a utilização de apenas 1 processador, 4Gb de espaço em disco e 1Gbde memória RAM. Possui suporte para SQL, PL/SQL e linguagens como PHP, .Net e Java.

6.9.3 PostgreeSQL

O PostgreSQL é um SGBD objeto-relacional de código aberto, com mais de 15

anos de desenvolvimento. É extremamente robusto e confiável, além de ser extremamente



124

flexível e rico em recursos. Ele é considerado objeto-relacional por implementar, além das

características de um SGBD relacional, algumas características de orientação a objetos, como

herança e tipos personalizados. A equipe de desenvolvimento do PostgreSQL sempre teve

uma grande preocupação em manter a compatibilidade com os padrões SQL92/SQL99.

6.9.4 SQL Server 2005 Express Edition

Uma versão gratuita e limitada do SGBD da Microsoft SQL Server 2005. Entre as

limitações que possui está o fato de suportar apenas 1 CPU, apenas 1 GB de memória RAM

para buffer pool, que é usado para o armazenamento de páginas de dados e outras

informações e arquivos de dados até 4GB. O SQL Server 2005 Express Edition substitui o

MSDE (Microsoft SQL Desktop Engine), porém não apresenta limitações de acesso

concorrente de usuário e ainda traz consigo uma ferramenta gráfica para administração e

gerenciamento, o SQL Server Express Manager (XM).

6.10 Documentação

6.10.1 BrOffice

É um conjunto de aplicativos em Opensource disponível para plataforma

Windows e Linux que oferece opções de editor de texto, planilha eletrônica, desenho gráfico,

editor de apresentações e outros. É similar a famosa suíte de aplicativos da Microsoft, o

Office, oferecendo aos usuários quase todas as funcionalidades que o Microsoft Office

oferece.



125

7 GUIA WEB METODES

O guia Web METODES é um sítio Web que apresenta a infra-estrutura

metodológica que a metodologia propõe para auxiliar os alunos nas disciplinas e atividades da

METODES.

A figura 7.1 mostra a página inicial do guia METODES. A estrutura do guia

METODES é baseada em quadros ( frames). Há um menu único de opções que possibilita

acesso a todas as etapas do processo de desenvolvimento da metodologia.

7.1 PÁGINA INICIAL DO GUIA WEB DA METODES

A partir do menu de opções o usuário do guia pode, por exemplo, navegar sobre

as visões da metodologia. A figura 7.2 mostra a opção do item de menu ‘Visões da

Metodologia’:



126

7.2 OPÇÃO DE MENU ‘VISÕES DA METODOLOGIA’ METODES



127

A figura 7.3 mostra a opção de menu ‘Disciplinas’:

7.3 OPÇÃO DE MENU ‘DISCIPLINAS’



128

7.3 Opção do menu ‘Papéis’ da METODES:

7.4 OPÇÃO DE MENU ‘PAPÉIS’



129

8 CONSIDERAÇÕES FINAIS

Este trabalho apresentou o desenvolvimento, sob a forma descritiva, da

metodologia de desenvolvimento de software, METODES.

A METODES é uma metodologia unificada que permite desenvolvimento

iterativo e incremental baseado em casos de uso, apesar de apresentar um ciclo de vida de

projeto em cascata. O que parece ser uma contradição conceitual é na verdade uma adaptação

da metodologia às necessidades e realidade acadêmica em que ela está inserida.

A simplicidade da METODES se destaca por ter sido desenvolvida para atender

especificamente o público acadêmico da Faculdade Cenecista de Brasília (FACEB), porém,

nada impede que ela seja adotada fora desse contexto, pois apresenta aspectos técnicos e

conceituais suficientes para contemplar o desenvolvimento de projetos de software diversos,

comerciais ou acadêmicos.

Pode-se considerar que os objetivos deste trabalho foram alcançados, uma vez que

ele descreve o conjunto de disciplinas, artefatos e papéis, base da infra-estrutura metodológica

que a METODES oferece aos alunos do curso de Bacharelado em Sistemas de Informação da

FACEB, para desenvolvimento dos seus trabalhos de conclusão de curso.

A partir da análise da infra-estrutura que a METODES propõe, chega-se a

conclusão que a utilização de uma metodologia para o desenvolvimento de software, emambiente acadêmico, alerta os alunos para questões importantes que devem ser consideradas

em um projeto. Além de conferir aos alunos, maior clareza de conceitos teóricos envolvidos

no processo de desenvolvimento de software. Portanto, fica caracterizada a importância da

utilização da metodologia no contexto apresentado.

Por não haver resultados práticos de projetos reais realizados com a METODES,

as afirmações feitas no trabalho sobre s gestão do processo e qualidade do produto de



130

software, são fundamentadas apenas na perspectiva ideal de funcionamento da metodologia.

Dessa forma, faz-se necessário a ponderação das questões que devem ser tratadas no futuro.

Estabelece-se, então, lista de sugestões para futuras revisões da METODES:

Desenvolver um processo contínuo de avaliação do processo de

desenvolvimento da METODES, que aponte as falhas e sugira correções;

Desenvolver um método eficaz de análise de resultados de projetos, de forma

que essa análise sirva como parâmetro para mensurar a qualidade do produto

de software;

Detalhar em linguagem mais próxima do aluno, todos os diagramas da UML

utilizados no processo de desenvolvimento, de forma que o aluno possa ter

uma referência prática para construção desses diagramas;

Desenvolver um banco de dados de padrões de projeto utilizados por todos os

projetos METODES, possibilitando que o aluno publique, consulte e utilize

esses padrões em seu próprio projeto, imprimindo, assim, maior agilidade e

produtividade no desenvolvimento do software.

Por fim, a METODES pode ser uma opção plausível para ser adotada como

metodologia padrão de desenvolvimento de software da FACEB. Bastando para isso, que sua

implantação seja encarada como a constante revisão e adequação da infra-estrutura proposta

pela METODES, ou seja, suas disciplinas, os artefatos e papéis que compõem a

essencialidade do processo de desenvolvimento da METODES.



131

9 REFERÊNCIAS

ABNT - Associação Brasileira de Normas Técnicas. NBR 13596 - Tecnologia deinformação – avaliação de produto de software - características de qualidade e diretrizes

para o seu uso: Rio de Janeiro, 1996.

ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 12207. Tecnologia de

Informação: Processos de Ciclo de Vida de Software: Rio de Janeiro, 1998.

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML: 8. ed. Rio de

Janeiro: Elsevier, 2002.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar, Tradução de Fábio Freitas da

Silva e Cristina de Amorim Machado. UML Guia do Usuário: 2. ed. Rio de Janeiro:

Elsevier, 2005.

PÁDUA, Wilson de. Engenharia de Software: Fundamentos, Métodos e Padrões: 2. ed.

Rio de Janeiro: LTC, 2003.

PETER, James; PEDRYCZ, Witold. Engenharia de Software: Teoria e Prática: Rio de

Janeiro: Campus, 2001.

PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prática. 2. ed. São Paulo:

Prentice Hall, 2004.

PRESSMAN, Roger S. Engenharia de Software. 5. ed. Rio de Janeiro: MacGraw-Hill, 2002.

______. Engenharia de Software: São Paulo: 3. ed. São Paulo: Makron Books, 1995.

SOMMERVILLE, Ian. Engenharia de Software: 6. ed. São Paulo: Addison Wesley, 2003.

<http://www.internativa.com.br/artigo_gestao.html>. Acessado em 23/05/2006.

<www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf>. Acessado em 14/08/2006.



132

10 GLOSSÁRIO

Afforadance .......Refere-se às propriedades percebidas e as propriedades reais de um objeto,

que deveriam determinar como ele pode ser usado. Esse conceito é

aplicado na construção de interfaces dos softwares.

APF .....................Análise de Ponto de Função

CAP .....................Controle de Artefatos do Projeto

CASE ..................Computer Aided Software Engineering

CMM...................Capability Maturity Model

CUF .....................Caso de Uso Funcional

DCC ....................Documentação de Código de Componente

DIAF ...................Documentação da Infra-estrutura de Ativos Físicos

DIS ......................Documentação da Infra-estrutura de Software

DRNF ..................Documentação do Requisito Não-funcional

DSM ....................Documento de Solicitação de Mudança

DVE.....................Documento de Visão e Escopo

GNU ....................Acrônimo recursivo para “GNU Não é UNIX”

GPL .....................General Publica License

IEEE.................... Institute of Electrical and Electronics Engineers

MAP ....................Modelo de Análise de Projeto

MIS......................Manual de Instalação do Software

MOU ...................Manual de Operação do Usuário

MVAC.................Modelagem da Visão de Arquitetura de Comunicação

MVAS .................Modelagem da Visão de Arquitetura de Software

MVS ....................Modelagem da Visão de Segurança

OCL ....................Object Constraint Language



133

OMG ...................Objetct Management Group

PAEP...................Planilha de Alteração de Escopo

PCR .....................Planilha de Controle de Requisitos

PI .........................Plano de Implantação

PRTF...................Plano de Realização do Teste Funcional

PPS ......................Plano de Projeto de Software

PRAXIS ..............Processo para Aplicativos Extensíveis e Interativos, desenvolvido por

Wilson de Pádua, muito utilizado no meio acadêmico.

PRP .....................Planilha de Resultados de Projeto

PRT .....................Planilha de Resultados de Testes

PT ........................Plano de Treinamento

QoS......................Quality of service

RUP ..................... Rational Unified Process

SGBD ..................Sistema Gerenciador de Banco de Dados

SQL .....................Structured Query Language

TAR.....................Termo de Aceite do Requisito

TAS .....................Termo de Aceite do Software

TI .........................Tecnologia da informação

UML....................Unified Modeling Language

UP........................Unified Process

XP........................ Extreme Programming



134

11 APÊNDICE A – DVE – DOCUMENTO DE VISÃO E ESCOPO



135



136



137

12 APÊNDICE B - PRP - PLANILHA DE RESULTADOS DE PROJETO



138

13 APÊNDICE C - PCR - PLANILHA I DE CONTROLE DE REQUISITOS



139

14 APÊNDICE D - PCR - PLANILHA II DE CONTROLE DE REQUISITOS



140

15 APÊNDICE E - PCR – PLANILHA III DE CONTROLE DE REQUISITOS



141

16 APÊNDICE F - PCR - PLANILHA IV DE CONTROLE DE REQUISITOS



142

17 APÊNDICE G - CUF – CASO DE USO FUNCIONAL



143

18 ANEXO A – TEXTO SOBRE ANÁLISE DE PONTO DE FUNÇÃO



144



145



146



147



148



149



150



151



152



153



154



155



156

19 ANEXO B – METODES ORIGINAL

Metodologia de Desenvolvimento de Software – MetoDeS Faceb

Roteiro Metodológico Preliminar

1. Modelo de gestão de desenvolvimento do software1.1 Metodologias

[Relacionar as metodologias que serão utilizadas no trabalho.]

1.2 Contagem de pontos de função1.3 Análise da região impossível - cálculo onde1.4 Cronograma

[Descrição das tarefas com duração, data início, data fim, precedência e

responsável. Considerar o previsto e o realizado.]

1.5 Composição da equipe do projeto de software[Nome do papel e da(s) pessoa(s) que o exercerão.]

1.6 Orçamento do projeto[Considerar itens de receita, itens de custo e cronograma de desembolso.]

1.7 Necessidade de aquisições[Considerar itens a serem adquiridos, quantidade, data prevista, data realizada,

responsável e fornecedor.]

1.8 Plano de resposta aos riscos[Considerar ID do risco, risco, prioridade, ação, responsável e prazo.]

1.9 Procedimentos de comunicação[Indicar cronograma de reuniões, formas de registro das informações, meios de

comunicação das informações, receptores e emissores.]2. Modelo de Requisitos2.1 Visão e escopo da aplicação

2.1.1 Apresentação do cliente[Eempresa, suas características, área de atuação, missão, visão,

objetivos estratégicos, organograma e outras informações que forem

relevantes]

2.1.2 Descrição da situação atual[Descrever em forma textual qual a situação atual do(s) processo(s) de

negócio em que se pretende atuar, enfatizando o escopo de negócio

(domínio do problema), os recursos atuais, áreas e sistemas envolvidos

e outras informações relevantes. Quando necessário, descrever, aqui, osistema atual.]

2.1.3 Problemas diagnosticados2.1.4 Oportunidade de negócio

[Descrever a oportunidade de negócio abstraída a partir dos

problemas diagnosticados, alinhando-a a um ou mais objetivos

estratégicos]

2.1.5 Descrição da Solução Proposta2.1.5.1 Objetivos da solução proposta

[Descrever o objetivo geral, os objetivos específicos e não

objetivos]

2.1.5.2 Envolvidos



157

[Descrever quem será envolvido ou afetado com o

desenvolvimento e implantação da solução proposta,

enfatizando como serão afetados, ou envolvidos.]

2.1.5.3 Necessidades e funcionalidades

[Apontar as necessidades dos usuários e as funcionalidadesdo sistema para atendê-las, fazendo a rastreabilidade

(correlação) entre as mesmas]

2.1.5.4 Itens fora do escopo2.2 Documentação dos Requisitos

2.2.1 Diagrama de casos de uso2.2.2 Descrição dos casos de uso2.2.3 Descrição dos atores2.2.4 Lista de regras de negócio2.2.5 Lista de requisitos não-funcionais2.2.6 Dicionário de termos técnicos

2.2.7 Rastreabilidade entre requisitos[Documentar a rastreabilidade entre requisitos usando matrizes de

rastreabilidade entre funcionalidades e casos de uso e entre casos de

uso e regras de negócio]

3. Modelo de Análise3.1 Modelo de análise

3.1.1 Diagrama de Classe3.1.2 Realização de casos de uso

3.1.2.1 Diagrama de seqüência[Um para cada cenário do caso de uso, quando o sistema

for pequeno. Um para cada fluxo principal, quando osistema for grande]

3.1.2.2 Diagrama de colaboração (opcional)[Seguir a regra do diagrama de seqüência]

3.1.2.3 Rastreabilidade entre requisitos e elementos de software3.1.3 Diagrama de Atividades (opcional)3.1.4 Diagrama de Transição de Estado (opcional)

3.2 Descrição da Arquitetura da Solução3.2.1 Representação da arquitetura lógica3.2.2 Representação da arquitetura física

[Usar diagrama de implantação da UML]

3.2.3 Configuração de hardware necessário3.2.3.1 Hardware para desenvolvimento3.2.3.2 Hardware para produção do software desenvolvido

3.2.4 Descrição de software necessário3.2.4.1 Software para desenvolvimento3.2.4.2 Software para produção do software desenvolvido

4. Modelo de Projeto4.1 Diagrama de Classe

[Diagrama de classe com o formalismo de projeto, organizado conforme a

arquitetura lógica. Obrigatório apenas quando a implementação usar orientação

a objetos, podendo ser mesclado.]

4.2 Descrição dos padrões e frameworks utilizados[Obrigatório apenas quando a implementação usar tais elementos.]

4.3 Modelo físico do banco de dados



158

4.4 Projeto de interface4.4.1 Interface homem-máquina



159

4.4.2 Interface entre sistemas[Obrigatório quando houver integração entre sistemas.]

5. Modelo de Implementação5.1 Diagrama de componentes

5.2 Descrição dos componentes externos5.3 Descrição dos pacotes de implementação5.4 Unidades de implementação5.5 Interfaces da aplicação5.6 Script do banco de dados5.7 Estruturas de dados

6. Modelo de Implantação6.1 Procedimentos de instalação e configuração6.2 Manual do usuário6.3 Representação da distribuição de pacotes

[Obrigatório para sistemas distribuídos.]

tcc

Documents

Transcript of tcc