SUMRIO

INTRODUO.......................................................................................................3

OBJETIVO..............................................................................................................4

DESENVOLVIMENTO...........................................................................................5

3.1

ENGENHARIA E PROJETO DE SOFTWARE...................................................5

3.1.1

Desafio 1 Proposta de Projeto.....................................................................5

3.1.1.1 Projeto de Arquitetura.....................................................................................5

3.1.1.2 Arquitetura de Sistemas Distribudos.............................................................6
3.1.1.3 Arquitetura de Aplicaes...............................................................................6
3.1.1.4 Gerenciamento de Configuraes..................................................................7
3.1.2

Desafio 2 - Gerenciamento de Projeto com base no PMBOK.....................10

3.1.2.1 Estrutura Analtica do Projeto (EAP).............................................................11

3.1.2.2 Cronograma das Atividades..........................................................................11
3.1.2.3 Relao dos envolvidos e papeis dentro do projeto.....................................14
3.2

PROGRAMAO PARA A WEB II...................................................................16

3.2.1

Desafio 3 Projeto Web utilizando um Framework Java.............................16

3.2.1.1 Formulrios de cadastro e consulta de cliente.............................................17

3.2.1.2 Cdigo fonte da rotina de cadastro e consulta de cliente............................19
3.3

PROJETO ORIENTADO A OBJETOS.............................................................21

3.3.1

Desafio 4 - Diagramas para representar a arquitetura do sistema..............21

3.3.1.1 Diagrama de Classes...................................................................................21

3.3.1.2 Diagrama de componentes...........................................................................22
3.3.1.3 Diagrama de pacotes....................................................................................23
4

CONCLUSO......................................................................................................24

REFERNCIAS...........................................................................................................25

1 INTRODUO
A Engenharia de Software uma disciplina que est envolvida com
todos os aspectos da produo de software, desde a sua concepo at a sua
entrega, operao e manuteno
Um ponto crtico no projeto e na construo de todo o sistema de
software sua arquitetura: isto , sua organizao bruta como uma coleo de
componentes de interao.
Enquanto uma boa arquitetura pode permitir que um sistema
satisfaa s exigncias chaves em reas como: o desempenho, a confiabilidade, a
portabilidade, a escalabilidade, e a sua interoperabilidade; uma arquitetura ruim
pode ser desastrosa.
Para ajudar na tarefa de construo de uma boa arquitetura de um
sistema, a adoo de boas prticas do mercado e a utilizao de frameworks so
prticas altamente recomendveis.
No caso da documentao da arquitetura de um sistema, a utilizao
de tcnicas de engenharia de software em conjunto com diagramas da UML so
largamente utilizadas no mercado.
Com relao ao gerenciamento do projeto, a adoo de algumas
ferramentas como, por exemplo, a EAP, o cronograma de atividades e a matriz
RACI, facilitam sobremaneira o acompanhamento das atividades do projeto.
Neste trabalho teremos a oportunidade de revisar todos esses
conceitos, assim como aplic-los na prtica, conforme ser mostrado nas sees a
seguir.

2 OBJETIVO
Esta produo textual interdisciplinar individual tem como principal
objetivo trabalhar o contedo do eixo temtico que foi abordado em todas as
disciplinas do quarto semestre do Curso de Anlise e Desenvolvimento de Sistemas,
auxiliando assim na aplicao dos conceitos estudados. Para tal, ser desenvolvido
um projeto de software denominado "Financeiro" cuja implementao ser feita
utilizando os frameworks JSF e Hibernate que ter a durao de 13 semanas e
envolver diversos profissionais. Alm disso, as atividades envolvendo programao
e modelagem UML sero feitas utilizando a rotina de cadastro de clientes desse
sistema (Financeiro).

3 DESENVOLVIMENTO

3.1 ENGENHARIA E PROJETO DE SOFTWARE

Para realizar a atividade proposta neste trabalho, optamos por criar
um projeto fictcio relativo a um sistema financeiro web.
3.1.1 Desafio 1 Proposta de Projeto

3.1.1.1 Projeto de Arquitetura

Optamos

por

desenvolver

um

projeto

de

arquitetura

cujos

componentes possuem alta coeso e baixo acoplamento e, ao mesmo tempo, so

independente de tecnologias de soluo existentes no mercado, como, por exemplo,
IBM, Microsoft ou SAP.
Para tal, a adoo de uma soluo baseada na plataforma Java EE
e em um banco de dados open source se tornou a escolha mais apropriada.
Elementos pertencentes arquitetura:

Banco de dados: no caso da arquitetura proposta, temos uma

camada apenas de banco de dados ou camada de persistncia
baseada nas tecnologias abaixo:
o MySQL (SGBD)
o Hibernate (ORM)

Cadastros: as principais funcionalidades que todo cadastro deve

controlar so: insero, excluso, alterao e consulta.

Controlador: responsvel pela execuo de um ou mais fluxos

de execuo que so modeladas em um caso de uso, ou seja,
podemos dizer que o controlador em si a implementao da
regra de negcio.
Um exemplo de controlador criado neste projeto o arquivo

CadastroClienteBean.java.

Web
o Container Web - Tomcat
o Framework MVC - Java Server Faces
Requisitos bsicos

A arquitetura deve seguir o padro J2EE/J2SE.

Windows 7 como sistema operacional do ambiente de produo.

Tomcat como servidor WEB (continer WEB).

3.1.1.2 Arquitetura de Sistemas Distribudos

Definimos o Java RMI como sendo a estrutura do sistema que ser
utilizada para acessar os objetos distribudos uma vez que o mesmo faz parte da
especificao do Java EE, o que o torna uma escolha natural. Outro motivo o fato
do Java ser uma linguagem de desenvolvimento aberta. Nesse caso, no teria muito
sentido utilizar uma arquitetura de sistema distribuda proprietria, como, por
exemplo, o CORBA.
3.1.1.3 Arquitetura de Aplicaes
Definimos a estrutura de aplicao que ser usada como sendo o
modelo baseado em quatro camadas.
Este modelo alm de transferir a camada de negcios do lado do
cliente para o servidor de aplicaes, ele tambm retira a apresentao dos clientes
e as centraliza em um determinado ponto, o qual na maioria dos casos um servidor
Web.
Segundo Macdo (2012), alguns motivos para a adoo do modelo
baseado em trs camadas so:

Respostas mais rpida nas requisies;

Excelente performance tanto em sistemas que rodam na Internet

ou em intranet.

Melhor controle no crescimento do sistema.

Alm disso, com o deslocamento da camada de apresentao para

um Servidor Web, resolvemos o problema de termos que atualizar a aplicao, em
centenas ou milhares de computadores, cada vez que a interface for alterada. Neste
ponto a atualizao das aplicaes uma tarefa mais gerencivel, muito diferente
do que acontecia no caso do modelo em duas camadas.
3.1.1.4 Gerenciamento de Configuraes
De acordo com Mendona e Santos (2015), o plano de
gerenciamento de configurao (GC) deve descrever todas as atividades do
gerenciamento de controle de configurao e as mudanas que sero executadas
durante o ciclo de vida do produto.
Alm disso, algumas das atividades do GC envolvem identificar a
configurao do software, manter sua integridade durante o projeto e controlar
sistematicamente as mudanas.
Sendo assim, para um correto planejamento das atividades,
fundamental que as funes de cada uma das pessoas envolvidas estejam
claramente definidas.
Quadro 1 Papis na gerncia de configurao
Papis

Gerente de
Configurao

Comit de Controle
de Mudanas (CCM)

Equipe

Responsabilidade

Abimael Souza
Sena

Estabelecer Polticas de GC
Escrever Plano de GC
Configurar Ambiente de GC
Criar Espaos de Trabalho de Integrao
Criar Baselines
Promover Baselines

Adinan de
Figueiredo
Andrade

Estabelecer Processo de Controle de Mudanas

Revisar Solicitao de Mudana

Leandro Carlos
Pereira de
Santana
Desenvolvedor

Daniel
Lima

Pereira Seguir os padres e procedimentos definidos no

Plano de Gerncia de Configurao

Alpio da Silva
Matias
Todos os Papis
Willian
Alves

Arajo

Enviar Solicitao de Mudana

Atualizar Solicitao de Mudana

9
Fonte: Mendona e Santos (2015)

Observaes:

O comit de Controle de Mudanas (CCM) formado por

Analista de sistemas e Gerente de Projetos.

As ferramentas a serem utilizadas para a gerncia de

configurao so as seguintes:

Quadro 2 As ferramentas a serem utilizadas para a GC

Ferramenta

Tipo

Descrio

Verso

Subversion

Controle de
Verso.

Sistema de controle de verso.

1.4.6

TortoiseSVN

Acesso ao
repositrio
Fonte: Mendona e Santos (2015)

Cliente para o Subversion integrado

1.4.8.121
ao Windows.

Com relao ao controle de alteraes e mudanas, comum que

as solicitaes de mudanas sigam um modelo de fluxo de aprovao conforme o
modelo mostrado abaixo:

Figura 1 Fluxo de aprovao de alteraes

Fonte: Mendona e Santos (2015)

10

Onde, obrigatoriamente, o fluxo de aprovao de uma solicitao de

alterao deve ser composto por todas as atividades listadas no quadro abaixo.
Quadro 3 Atividades do fluxo de aprovao de uma solicitao
Atividade

Descrio

Responsabilidade

Aberto

Criao da solicitao.

Todos

Em anlise

Anlise da solicitao

Analista de sistemas

Analisado

Aguardando desenvolvimento

Analista de sistemas

Em desenvolvimento

Solicitao sendo desenvolvida

Desenvolvedor

Desenvolvido

Aguardando teste

Desenvolvedor

Em testes

Solicitao em teste

Testador

Testado com erro

Aguardando desenvolvimento

Testador

Testado sem erro

Solicitao esperando finalizao

Testador
pelo analista

Finalizado

Solicitao finalizada

Fonte: Mendona e Santos (2015)

Analista de sistemas

11

3.1.2 Desafio 2 - Gerenciamento de Projeto com base no PMBOK

Na viso de Gordon e Gordon (2006), a melhor abordagem para um
determinado projeto depende, em grande parte, da natureza do projeto e da
natureza da organizao.
No caso deste trabalho, optamos pelo modelo espiral de
desenvolvimento de software porque o mesmo apresenta melhores resultados para
projetos mais simples, permitindo construir produtos em prazos curtos, com novas
caractersticas e recursos que so agregados medida que surgem novas
necessidades.
Alm disso, o modelo espiral abrange as melhores caractersticas
tanto do ciclo de vida em cascata como da prototipagem, acrescentando, ao mesmo
tempo, um novo elemento: a anlise de riscos. (PRESMAN, 1985, p.34).
Figura 2 Modelo em espiral do processo de software de Boehm

Fonte: IEEE (1998)

12

3.1.2.1 Estrutura Analtica do Projeto (EAP)

A estrutura analtica de projeto uma ferramenta essencial para o
gerenciamento de projetos uma vez que permite ao gerente do projeto uma viso
completa, organizada e estruturada de todas as atividades que compem o projeto.
Figura 3 EAP do projeto do sistema financeiro

Fonte: Proposta do Grupo

3.1.2.2 Cronograma das Atividades

O tempo total planejado para execuo de todas as atividades do
projeto ser de 120 horas e envolver seis profissionais durante quatorze semanas:

Id

Nome da tarefa

1
Planejamento
1.1
Comunicao com o cliente
1.1.1
Documentao dos requisitos.
1.1.2
Formalizao dos requisitos.
1.2.
Anlise de risco
1.3.
Engenharia
1.3.1
Prototipao das telas
1.3.2
Modelagem de dados
1.4.
Construo e liberao
1.4.1
Implementao
1.4.2
Documentao
1.4.3
Testes
1.5.
Avaliao do cliente.
Fonte: Proposta do grupo

Durao
Hora(s) Semana(s)
120
12
9
3
3
33
6
27
63
36
18
9
9

13
2
1
1
1
4
1
3
7
7
7
7
1

Tarefa
Predecessora

1.1.1
1.1.2
1.1.1
1.1.1
1.1.1, 1.1.2 e 1.3.1
1.3.1 e 1.3.2
1.4.1
1.4.1 e 1.4.2
1.4

13

A descrio de quais atividades que esto previstas para serem

executadas a cada semana so as seguintes:
Semana quatorze Comunicao com o cliente
Tarefa 1.1.1 Documentao dos requisitos
No perodo de 01/04 a 03/04/15, semana 14, dois analistas de
sistemas e um programador sero envolvidos em atividades relacionadas com a
documentao dos requisitos.
Esforo: 3 homens x 3 h/homem => 9 horas
Semana quinze - Formalizao dos requisitos
Tarefa 1.4.1 Prototipao das telas
No perodo de 06/04 a 10/04/15, semana 15, dois programadores
devero desempenhar atividades relacionadas com a prototipao das telas
relacionadas aos requisitos documentados na tarefa 1.1.1 (Documentao dos
requisitos). Esses prottipos devem cobrir apenas os requisitos ainda no
elucidados junto aos usurios.
Esforo: 2 homens x 3 h/homem => 6 horas
Tarefa 1.1.2 Formalizao dos requisitos
Paralelamente s atividades dos dois programadores, um dos
analistas de sistemas dever, concluir todas as atividades relacionadas com a
comunicao com o cliente junto as partes envolvidas. O objetivo desta atividade
obter junto a cada parte envolvida a aprovao de cada requisito documentado
assim como o apoio e a assinatura dos mesmos.
Esforo: 1 homem x 3 h/homem => 3 horas

14

Semanas dezesseis a dezoito - Engenharia

Tarefa 1.3.2 - Modelagem de dados
No perodo de 13/04 a 30/04/15, semanas dezesseis a dezoito, um
analista de sistemas e dois programadores devero estar envolvidos em atividades
relacionadas com a modelagem de dados. Durante este perodo, dever ser
elaborado o modelo conceitual, o diagrama entidade-relacionamento, o modelo de
dados assim como todos os diagramas da UML que forem imprescindveis para o
sucesso do projeto.
Esforo: 3 homens x 9 h/homem => 9 horas
Semanas dezenove a vinte cinco - Construo e liberao
Tarefas 1.4.1/1.4.3 Implementao/Testes
No perodo de 05/05 a 19/06/15, semanas dezenove a vinte cinco,
dois programadores devero utilizar todas as trs horas de dedicao exclusiva, de
cada um, em cada uma das sete semanas, com atividades relacionadas a
programao e testes das funcionalidades. Alm disso, devero, tambm, realizar os
testes de unidade e de integrao dos componentes.
Esforo: 42h/homem 2 homens 21 horas
Tarefa 1.4.2 Documentao
No perodo de 05/05 a 19/06/15, semanas dezenove a vinte cinco,
um analista de sistemas dever utilizar suas trs horas de dedicao exclusiva, em
cada uma das sete semanas, com atividades relacionadas a documentao das
funcionalidades implementadas pelos programadores, confeco de manuais, testes
das rotinas, alm de ser o elo de ligao entre os programadores e as demais partes
envolvidas no projeto com relao ao esclarecimento de dvidas e apresentao de
prottipos e funcionalidades.

15

Semanas vinte cinco e vinte e seis - Implementao e testes

Tarefa 1.5 Avaliao do cliente

No perodo de 23/06 a 26/06/15, semana vinte e seis, um analista de
sistemas e dois programadores devero estar envolvidos em atividades relacionadas
com o treinamento e suporte dos usurios. Durante este perodo, a documentao e
os manuais elaborados na tarefa anterior (1.4.2) sero utilizados para o treinamento
de usurios chave em cada uma das reas onde o sistema ser utilizado.
Ao trmino do treinamento os usurios chave de cada rea devero
repassar a equipe de projeto suas impresses sobre o sistema desenvolvido.
Esforo: 9h/homem 3 homens 3 horas

3.1.2.3 Relao dos envolvidos e papeis dentro do projeto

Quando pensamos em gerenciar recursos humanos alocados em um
projeto, logo nos vm mente os papis e as responsabilidades a serem definidos.
Esse um passo fundamental para o desenvolvimento das mais diversas atividades
planejadas para o projeto.

Assim, a matriz RACI surge como uma importante

ferramenta de apoio no gerenciamento dos recursos humanos e das comunicaes.

De acordo com o PMBOK, nesta matriz so definidos os seguintes
papis:

Responsible: a pessoa responsvel pela execuo da tarefa.

Podem ser uma ou mais pessoas designadas a executarem a
tarefa.

Accountable: pessoa que deve prestar contas com relao a

execuo da tarefa. Haver somente uma pessoa designada
para esse papel.

Consulted: so pessoas que devem ser consultadas por

possurem um maior know how sobre determinados assuntos,

16

sendo assim, responsveis por fornecerem informaes teis

para a concluso da tarefa. A comunicao com esse grupo ser
de duas vias.

Informed pessoas informadas sobre o progresso e status da

tarefa. A comunicao com esse grupo ser de mo nica.

No caso do projeto fictcio denominado Financeiro, as atividades

previstas e as responsabilidades de cada um dos papeis envolvidos so as
seguintes:

Atividade

Analista
1

Documentao
A/R
dos requisitos.
Formalizao
R
dos requisitos.
Anlise de risco
C
Prototipao das
C
telas
Modelagem de
R
dados
Implementao
I
Documentao
I
Testes
I
Avaliao do
A/R
cliente
Fonte: Proposta do grupo

Analista
2

Programador
1

Programador
2

Testador

Cliente/
Usurio

Gerente
de
Projeto

A/R

A/R

A/R

I
I
I

A/R
A/R
C

R
R
A/C

C
C
R

I
I
I

I
I
I

Neste caso, as pessoas que assumiro cada um dos papeis listados

so as seguintes:

Analista 1: Abimael Souza Sena

Analista 2: Willian Arajo Alves

Programador 1: Daniel Pereira Lima

Programador 2: Ariel Silva Jairi

Testador: Leandro Carlos Pereira de Santana

Gerente de projeto: Alpio da Silva Matias

17

3.2 PROGRAMAO PARA A WEB II

3.2.1 Desafio 3 Projeto Web utilizando um Framework Java

Para o desenvolvimento desta atividade foram utilizados a
implementao Mojarra do JavaServer Faces (JSF), o Hibernate, o MySQL e o
Apache Tomcat, conforme mostrado na figura 4.
Figura 4 Estrutura do Projeto

Fonte: Projeto JSF criado no Eclipse Juno SR1

18

3.2.1.1 Formulrios de cadastro e consulta de cliente

Foi implementado em JSF a rotina de cadastro de Clientes. Para
incluir um novo registro, o usurio deve preencher todos os campos e clicar no boto
"Cadastrar".
Figura 5 Tela de cadastro de cliente (1)

Fonte: Projeto JSF criado no Eclipse Juno SR1

Ser apresentada uma mensagem de sucesso.

Figura 6 Tela de cadastro de cliente (2)

Fonte: Projeto JSF criado no Eclipse Juno SR1

19

O registro cadastrado ser includo na tabela "cliente" do MySQL,

conforme mostrado na figura abaixo.
Figura 7 Registros gravados no banco de dados

Fonte: MySQL Workbench

Para consultar os clientes cadastrados, bastar clicar no boto

"Consulta". Feito isso, ser apresentado o tela mostrada abaixo.
Figura 8 Registros gravados no banco de dados

Fonte: Projeto JSF criado no Eclipse Juno SR1

Clique no boto "Novo Cliente", para retornar a tela de cadastro.

20

3.2.1.2 Cdigo fonte da rotina de cadastro e consulta de cliente

Cdigo fonte 1 Cadastro de cliente

Fonte: Projeto JSF criado no Eclipse Juno SR1

21

Cdigo fonte 2 Consulta de cliente

Fonte: Projeto JSF criado no Eclipse Juno SR1

22

3.3 PROJETO ORIENTADO A OBJETOS

3.3.1 Desafio 4 - Diagramas para representar a arquitetura do sistema

3.3.1.1 Diagrama de Classes

Figura 9 - Diagrama de classe utilizado no exemplo

Fonte: Projeto JSF criado no Eclipse Juno SR1

23

3.3.1.2 Diagrama de componentes

Figura 10 Diagrama de Componentes

Fonte: Astah Community

24

3.3.1.3 Diagrama de pacotes

Figura 11 Diagrama de pacotes

Fonte: Astah Community

25

4 CONCLUSO
Em

tempos

de

competitividade

acirrada,

conscincia

da

necessidade de processos de produo mais eficientes, que garantam o equilbrio

perfeito entre qualidade e produtividade, vem crescendo substancialmente.
Vale ressaltar que o objetivo maior da Engenharia de Software
produzir software de qualidade, dentro do prazo e no custo desejado pelo cliente.
Como o desenvolvimento de software uma atividade complexa por
natureza, a adoo de prticas de engenharia de software, gerenciamento de projeto
e utilizao de frameworks fundamental para atingirmos nossos objetivos.
Ao adotarmos estas prticas, possvel no s um melhor controle e
acompanhamento, mas tambm a garantia da adoo de boas prticas consagradas
no mercado.
Com relao ao gerenciamento de projeto, a matriz RACI, por
exemplo, uma tima forma de deixar claro na organizao quem o responsvel
pelo processo e quais so os demais envolvidos, facilitando o processo de
comunicao, controle e acompanhamento das atividades.
A utilizao de frameworks por sua vez, facilitam no s o
desenvolvimento mas tambm a adoo das melhores prticas de programao. Ao
utilizarmos o hibernate para persistncia de dados e o JSF para criao das pginas
pudemos constatar isso.

26

REFERNCIAS

CRESPO, Srgio. UML - Diagramas de componentes. Disponvel em:

<http://professor.unisinos.br/wp/crespo/files/2011/07/aula5.pdf >. Acesso em:
11/04/2014.
GORDON, Steven R.; GORDON, Judith R. Sistemas de informao uma
abordagem gerencial. Rio de Janeiro: LTC, 2006.
MACDO, Diego. Arquitetura de aplicaes em 2, 3, 4 ou N camadas. Disponvel
em:
<http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-ncamadas/>. Acesso em: 14 mar. 2015.
MENDONA, Rafael dos Santos; SANTOS, Israel Menezes. Plano de
gerenciamento de configurao. Disponvel em:
<http://sigeq.googlecode.com/svn/trunk/Documentos/SIGEQ_PGC.doc>. Acesso em:
14 mar. 2015.
MLLER, Mary Stela. Normas e padres para teses, dissertaes e
monografias. 5 ed. Londrina: Eduel, 2003.
PRESMAN, Roger S. Engenharia de Software. So Paulo: Makron Books do Brasil,
1995.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. So Paulo: Pearson AddisonWesley, 2007.
UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (Guia
PMBoK). 5 ed. EUA, Project Management Institute (PMI). Global Standard, 2013.
VASCONCELOS, Alexandre Marcos Lins de. Introduo engenharia de software e
qualidade de software. Lavras: UFLA/FAEPE, 2006. Disponvel em:
<http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia&QualidadeSoftw
are_V.28.09.06.pdf>. Acesso em: 11 abr. 2014.