SISTEMA DE ENSINO PRESENCIAL CONECTADO

CURSO SUPERIOR DE TECNOLOGIA EM

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

MARCEL CERQUEIRA
NOME DO ALUNO 2
NOME DO ALUNO 3
NOME DO ALUNO 4
NOME DO ALUNO 5
NOME DO ALUNO 6
NOME DO ALUNO 7

PRODUÇÃO TEXTUAL EM GRUPO:

Gestão do Processo de Desenvolvimento I

Feira de Santana - BA
2015
 MARCEL CERQUEIRA
NOME DO ALUNO 2
NOME DO ALUNO 3
NOME DO ALUNO 4
NOME DO ALUNO 5
NOME DO ALUNO 6
NOME DO ALUNO 7

PRODUÇÃO TEXTUAL EM GRUPO:

Gestão do Processo de Desenvolvimento I

Trabalho de portfólio apresentado à Universidade Norte

do Paraná - UNOPAR, como requisito parcial para a
obtenção de média bimestral nas disciplinas de:

Projeto Orientado a Objetos;

Engenharia e Projeto de Software;
Programação para Web II.

Orientadores:
Prof. Márcio Roberto Chiaveli
Prof. Luis Claudio Perini
Prof. Marco Ikuro Hisatomi
Prof.ª Veronice de Freitas

Feira de Santana - BA
2015
 SUMÁRIO

1 INTRODUÇÃO.......................................................................................................3
2 OBJETIVO..............................................................................................................4
3 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 Distribuídos.............................................................6
3.1.1.3 Arquitetura de Aplicações...............................................................................6
3.1.1.4 Gerenciamento de Configurações..................................................................7
3.1.2 Desafio 2 - Gerenciamento de Projeto com base no PMBOK.....................10
3.1.2.1 Estrutura Analítica do Projeto (EAP)............................................................11
3.1.2.2 Cronograma das Atividades.........................................................................11
3.1.2.3 Relação dos envolvidos e papeis dentro do projeto.....................................14
3.2 PROGRAMAÇÃO PARA A WEB II..................................................................16
3.2.1 Desafio 3 – Projeto Web utilizando um Framework Java............................16
3.2.1.1 Formulários de cadastro e consulta de cliente.............................................17
3.2.1.2 Código 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 CONCLUSÃO......................................................................................................24
REFERÊNCIAS...........................................................................................................25
 3

1 INTRODUÇÃO

A Engenharia de Software é uma disciplina que está envolvida com

todos os aspectos da produção de software, desde a sua concepção até a sua
entrega, operação e manutenção
Um ponto crítico no projeto e na construção de todo o sistema de
software é sua arquitetura: isto é, sua organização bruta como uma coleção de
componentes de interação.
Enquanto uma boa arquitetura pode permitir que um sistema
satisfaça às exigências 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 construção de uma boa arquitetura de um
sistema, a adoção de boas práticas do mercado e a utilização de frameworks são
práticas altamente recomendáveis.
No caso da documentação da arquitetura de um sistema, a utilização
de técnicas de engenharia de software em conjunto com diagramas da UML são
largamente utilizadas no mercado.
Com relação ao gerenciamento do projeto, a adoção 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 prática, conforme será mostrado nas seções a
seguir.
 4

2 OBJETIVO

Esta produção textual interdisciplinar individual tem como principal

objetivo trabalhar o conteúdo do eixo temático que foi abordado em todas as
disciplinas do quinto semestre do Curso de Análise e Desenvolvimento de Sistemas,
auxiliando assim na aplicação dos conceitos estudados. Para tal, será desenvolvido
um projeto de software denominado "Financeiro" cuja implementação será feita
utilizando os frameworks JSF e Hibernate que terá a duração de 13 semanas e
envolverá diversos profissionais. Além disso, as atividades envolvendo programação
e modelagem UML serão feitas utilizando a rotina de cadastro de clientes desse
sistema (Financeiro).
 5

3 DESENVOLVIMENTO

3.1 ENGENHARIA E PROJETO DE SOFTWARE

Para realizar a atividade proposta neste trabalho, optamos por criar

um projeto fictício 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 coesão e baixo acoplamento e, ao mesmo tempo, são
independente de tecnologias de solução existentes no mercado, como, por exemplo,
IBM, Microsoft ou SAP.
Para tal, a adoção de uma solução 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 persistência
baseada nas tecnologias abaixo:
o MySQL (SGBD)
o Hibernate (ORM)
 Cadastros: as principais funcionalidades que todo cadastro deve
controlar são: inserção, exclusão, alteração e consulta.
 Controlador: é responsável pela execução de um ou mais fluxos
de execução que são modeladas em um caso de uso, ou seja,
podemos dizer que o controlador é em si a implementação da
regra de negócio.
Um exemplo de controlador criado neste projeto é o arquivo
 6

“CadastroClienteBean.java”.
 Web
o Container Web - Tomcat
o Framework MVC - Java Server Faces

Requisitos básicos

 A arquitetura deve seguir o padrão J2EE/J2SE.

 Windows 7 como sistema operacional do ambiente de produção.
 Tomcat como servidor WEB (contêiner WEB).

3.1.1.2 Arquitetura de Sistemas Distribuídos

Definimos o Java RMI como sendo a estrutura do sistema que será

utilizada para acessar os objetos distribuídos uma vez que o mesmo faz parte da
especificação do Java EE, o que o torna uma escolha natural. Outro motivo é o fato
do Java ser uma linguagem de desenvolvimento aberta. Nesse caso, não teria muito
sentido utilizar uma arquitetura de sistema distribuída proprietária, como, por
exemplo, o CORBA.

3.1.1.3 Arquitetura de Aplicações

Definimos a estrutura de aplicação que será usada como sendo o

modelo baseado em quatro camadas.
Este modelo além de transferir a camada de negócios do lado do
cliente para o servidor de aplicações, ele também retira a apresentação dos clientes
e as centraliza em um determinado ponto, o qual na maioria dos casos é um servidor
Web.
Segundo Macêdo (2012), alguns motivos para a adoção do modelo
baseado em três camadas são:
 Respostas mais rápida nas requisições;
 Excelente performance tanto em sistemas que rodam na Internet
ou em intranet.
 Melhor controle no crescimento do sistema.
 7

Além disso, com o deslocamento da camada de apresentação para

um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em
centenas ou milhares de computadores, cada vez que a interface for alterada. Neste
ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente
do que acontecia no caso do modelo em duas camadas.

3.1.1.4 Gerenciamento de Configurações

De acordo com Mendonça e Santos (2015), o plano de

gerenciamento de configuração (GC) deve descrever todas as atividades do
gerenciamento de controle de configuração e as mudanças que serão executadas
durante o ciclo de vida do produto.
Além disso, algumas das atividades do GC envolvem identificar a
configuração do software, manter sua integridade durante o projeto e controlar
sistematicamente as mudanças.
Sendo assim, para um correto planejamento das atividades, é
fundamental que as funções de cada uma das pessoas envolvidas estejam
claramente definidas.

Quadro 1 – Papéis na gerencia de configuração

Papéis Equipe Responsabilidade
Estabelecer Políticas de GC
Escrever Plano de GC
Gerente de Marcel Configurar Ambiente de GC
Configuração Cerqueira Criar Espaços de Trabalho de Integração
Criar Baselines
Promover Baselines

Comitê de Controle Aluno 2 Estabelecer Processo de Controle de Mudanças

de Mudanças (CCM) Revisar Solicitação de Mudança
Aluno 3
Seguir os padrões e procedimentos definidos no
Desenvolvedor Aluno 4
Plano de Gerência de Configuração

Aluno 5 Enviar Solicitação de Mudança

Todos os Papéis
Aluno 6 Atualizar Solicitação de Mudança

Fonte: Mendonça e Santos (2015)

 8

Observações:

 O comitê de Controle de Mudanças (CCM) é formado por

Analista de sistemas e Gerente de Projetos.

 As ferramentas a serem utilizadas para a gerência de

configuração são as seguintes:

Quadro 2 – As ferramentas a serem utilizadas para a GC

Ferramenta Tipo Descrição Versão

Controle de
Subversion Sistema de controle de versão. 1.4.6
Versão.

Cliente para o Subversion integrado

TortoiseSVN Acesso ao 1.4.8.121
ao Windows.
repositório
Fonte: Mendonça e Santos (2015)

Com relação ao controle de alterações e mudanças, é comum que

as solicitações de mudanças sigam um modelo de fluxo de aprovação conforme o
modelo mostrado abaixo:

Figura 1 – Fluxo de aprovação de alterações

Fonte: Mendonça e Santos (2015)

 9

Onde, obrigatoriamente, o fluxo de aprovação de uma solicitação de

alteração deve ser composto por todas as atividades listadas no quadro abaixo.

Quadro 3 – Atividades do fluxo de aprovação de uma solicitação

Atividade Descrição Responsabilidade

Aberto Criação da solicitação. Todos

Em análise Analista de sistemas

Análise da solicitação

Analisado Aguardando desenvolvimento Analista de sistemas

Em desenvolvimento Solicitação sendo desenvolvida Desenvolvedor

Desenvolvido Aguardando teste Desenvolvedor

Em testes Solicitação em teste Testador

Testado com erro Aguardando desenvolvimento Testador

Solicitação esperando finalização

Testado sem erro Testador
pelo analista

Finalizado Solicitação finalizada Analista de sistemas

Fonte: Mendonça e Santos (2015)

 10

3.1.2 Desafio 2 - Gerenciamento de Projeto com base no PMBOK

Na visão de Gordon e Gordon (2006), a melhor abordagem para um

determinado projeto depende, em grande parte, da natureza do projeto e da
natureza da organização.
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
características e recursos que são agregados à medida que surgem novas
necessidades.
Além disso, o modelo espiral abrange as melhores características
tanto do ciclo de vida em cascata como da prototipagem, acrescentando, ao mesmo
tempo, um novo elemento: a análise de riscos. (PRESMAN, 1985, p.34).

Figura 2 – Modelo em espiral do processo de software de Boehm

Fonte: IEEE (1998)

 11

3.1.2.1 Estrutura Analítica do Projeto (EAP)

A estrutura analítica de projeto é uma ferramenta essencial para o

gerenciamento de projetos uma vez que permite ao gerente do projeto uma visão
completa, organizada e estruturada de todas as atividades que compõem 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 execução de todas as atividades do

projeto será de 120 horas e envolverá seis profissionais durante quatorze semanas:

Duração
Id Nome da tarefa Hora(s) Semana(s) Tarefa
Predecessora
1 Planejamento 120 13
1.1 Comunicação com o cliente 12 2
1.1.1 Documentação dos requisitos. 9 1
1.1.2 Formalização dos requisitos. 3 1 1.1.1
1.2. Análise de risco 3 1 1.1.2
1.3. Engenharia 33 4 1.1.1
1.3.1 Prototipação das telas 6 1 1.1.1
1.3.2 Modelagem de dados 27 3 1.1.1, 1.1.2 e 1.3.1
1.4. Construção e liberação 63 7 1.3.1 e 1.3.2
1.4.1 Implementação 36 7
1.4.2 Documentação 18 7 1.4.1
1.4.3 Testes 9 7 1.4.1 e 1.4.2
1.5. Avaliação do cliente. 9 1 1.4
Fonte: Proposta do grupo
 12

A descrição de quais atividades que estão previstas para serem

executadas a cada semana são as seguintes:

Semana quatorze – Comunicação com o cliente

Tarefa 1.1.1 – Documentação dos requisitos

No período de 01/04 a 03/04/15, semana 14, dois analistas de

sistemas e um programador serão envolvidos em atividades relacionadas com a
documentação dos requisitos.
Esforço: 3 homens x 3 h/homem => 9 horas

Semana quinze - Formalização dos requisitos

Tarefa 1.4.1 – Prototipação das telas

No período de 06/04 a 10/04/15, semana 15, dois programadores

deverão desempenhar atividades relacionadas com a prototipação das telas
relacionadas aos requisitos documentados na tarefa 1.1.1 (Documentação dos
requisitos). Esses protótipos devem cobrir apenas os requisitos ainda não
elucidados junto aos usuários.
Esforço: 2 homens x 3 h/homem => 6 horas

Tarefa 1.1.2 – Formalização dos requisitos

Paralelamente às atividades dos dois programadores, um dos

analistas de sistemas deverá, concluir todas as atividades relacionadas com a
“comunicação com o cliente” junto as partes envolvidas. O objetivo desta atividade é
obter junto a cada parte envolvida a aprovação de cada requisito documentado
assim como o apoio e a assinatura dos mesmos.
Esforço: 1 homem x 3 h/homem => 3 horas
 13

Semanas dezesseis a dezoito - Engenharia

Tarefa 1.3.2 - Modelagem de dados

No período de 13/04 a 30/04/15, semanas dezesseis a dezoito, um

analista de sistemas e dois programadores deverão estar envolvidos em atividades
relacionadas com a modelagem de dados. Durante este período, deverá ser
elaborado o modelo conceitual, o diagrama entidade-relacionamento, o modelo de
dados assim como todos os diagramas da UML que forem imprescindíveis para o
sucesso do projeto.
Esforço: 3 homens x 9 h/homem => 9 horas

Semanas dezenove a vinte cinco - Construção e liberação

Tarefas 1.4.1/1.4.3 – Implementação/Testes

No período de 05/05 a 19/06/15, semanas dezenove a vinte cinco,

dois programadores deverão utilizar todas as três horas de dedicação exclusiva, de
cada um, em cada uma das sete semanas, com atividades relacionadas a
programação e testes das funcionalidades. Além disso, deverão, também, realizar os
testes de unidade e de integração dos componentes.

Esforço: 42h/homem – 2 homens – 21 horas

Tarefa 1.4.2 – Documentação

No período de 05/05 a 19/06/15, semanas dezenove a vinte cinco,

um analista de sistemas deverá utilizar suas três horas de dedicação exclusiva, em
cada uma das sete semanas, com atividades relacionadas a documentação das
funcionalidades implementadas pelos programadores, confecção de manuais, testes
das rotinas, além de ser o elo de ligação entre os programadores e as demais partes
envolvidas no projeto com relação ao esclarecimento de dúvidas e apresentação de
protótipos e funcionalidades.
 14

Semanas vinte cinco e vinte e seis - Implementação e testes

Tarefa 1.5 – Avaliação do cliente

No período de 23/06 a 26/06/15, semana vinte e seis, um analista de

sistemas e dois programadores deverão estar envolvidos em atividades relacionadas
com o treinamento e suporte dos usuários. Durante este período, a documentação e
os manuais elaborados na tarefa anterior (1.4.2) serão utilizados para o treinamento
de usuários chave em cada uma das áreas onde o sistema será utilizado.
Ao término do treinamento os usuários chave de cada área deverão
repassar a equipe de projeto suas impressões sobre o sistema desenvolvido.
Esforço: 9h/homem – 3 homens – 3 horas

3.1.2.3 Relação dos envolvidos e papeis dentro do projeto

Quando pensamos em gerenciar recursos humanos alocados em um

projeto, logo nos vêm à mente os papéis 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 comunicações.

De acordo com o PMBOK, nesta matriz são definidos os seguintes

papéis:

 Responsible: é a pessoa “responsável” pela execução da tarefa.

Podem ser uma ou mais pessoas designadas a executarem a
tarefa.
 Accountable: é pessoa que deve “prestar contas” com relação a
execução da tarefa. Haverá somente uma pessoa designada
para esse papel.
 Consulted: são pessoas que devem ser consultadas por
possuírem um maior “know how” sobre determinados assuntos,
 15

sendo assim, responsáveis por fornecerem informações úteis

para a conclusão da tarefa. A comunicação com esse grupo será
de duas vias.
 Informed – pessoas informadas sobre o progresso e status da
tarefa. A comunicação com esse grupo será de mão única.

No caso do projeto fictício denominado “Financeiro”, as atividades

previstas e as responsabilidades de cada um dos papeis envolvidos são as
seguintes:

Gerente
Analista Analista Programador Programador Cliente/
Atividade Testador de
1 2 1 2 Usuário
Projeto
Documentação
A/R R I I - C C
dos requisitos.
Formalização
R R I I - C C
dos requisitos.
Análise de risco C C C - - C A/R
Prototipação das
C C A/R R I I I
telas
Modelagem de
R A/R C C - I I
dados
Implementação I I A/R R C I I
Documentação I I A/R R C I I
Testes I I C A/C R I I
Avaliação do
A/R C I I I C I
cliente
Fonte: Proposta do grupo

Neste caso, as pessoas que assumirão cada um dos papeis listados

são as seguintes:

 Analista 1: Marcel Cerqueira

 Analista 2: Aluno 2
 Programador 1: Aluno 3
 Programador 2: Aluno 4
 Testador: Aluno 5
 Gerente de projeto: Aluno 6
 16

3.2 PROGRAMAÇÃO PARA A WEB II

3.2.1 Desafio 3 – Projeto Web utilizando um Framework Java

Para o desenvolvimento desta atividade foram utilizados a

implementação 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

 17

3.2.1.1 Formulários de cadastro e consulta de cliente

Foi implementado em JSF a rotina de cadastro de Clientes. Para

incluir um novo registro, o usuário deve preencher todos os campos e clicar no botão
"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

O registro cadastrado será incluído na tabela "cliente" do MySQL,
 18

conforme mostrado na figura abaixo.

Figura 7 – Registros gravados no banco de dados

Fonte: MySQL Workbench

Para consultar os clientes cadastrados, bastar clicar no botão

"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 botão "Novo Cliente", para retornar a tela de cadastro.

 19

3.2.1.2 Código fonte da rotina de cadastro e consulta de cliente

Código fonte 1 – Cadastro de cliente

Fonte: Projeto JSF criado no Eclipse Juno SR1

 20

Código fonte 2 – Consulta de cliente

Fonte: Projeto JSF criado no Eclipse Juno SR1

 21

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

 22

3.3.1.2 Diagrama de componentes

Figura 10 – Diagrama de Componentes

Fonte: Astah Community

 23

3.3.1.3 Diagrama de pacotes

Figura 11 – Diagrama de pacotes

Fonte: Astah Community

 24

4 CONCLUSÃO

Em tempos de competitividade acirrada, a consciência da

necessidade de processos de produção mais eficientes, que garantam o equilíbrio
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 adoção de práticas de engenharia de software, gerenciamento de projeto
e utilização de frameworks é fundamental para atingirmos nossos objetivos.
Ao adotarmos estas práticas, é possível não só um melhor controle e
acompanhamento, mas também a garantia da adoção de boas práticas consagradas
no mercado.
Com relação ao gerenciamento de projeto, a matriz RACI, por
exemplo, é uma ótima forma de deixar claro na organização quem é o responsável
pelo processo e quais são os demais envolvidos, facilitando o processo de
comunicação, controle e acompanhamento das atividades.
A utilização de frameworks por sua vez, facilitam não só o
desenvolvimento mas também a adoção das melhores práticas de programação. Ao
utilizarmos o hibernate para persistência de dados e o JSF para criação das páginas
pudemos constatar isso.
 25

REFERÊNCIAS

CRESPO, Sérgio. UML - Diagramas de componentes. Disponível 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 informação uma

abordagem gerencial. Rio de Janeiro: LTC, 2006.

MACÊDO, Diego. Arquitetura de aplicações em 2, 3, 4 ou N camadas. Disponível

em:
<http://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-
camadas/>. Acesso em: 14 mar. 2015.

MENDONÇA, Rafael dos Santos; SANTOS, Israel Menezes. Plano de

gerenciamento de configuração. Disponível em:
<http://sigeq.googlecode.com/svn/trunk/Documentos/SIGEQ_PGC.doc>. Acesso em:
14 mar. 2015.

MÜLLER, Mary Stela. Normas e padrões para teses, dissertações e

monografias. 5ª ed. Londrina: Eduel, 2003.

PRESMAN, Roger S. Engenharia de Software. São Paulo: Makron Books do Brasil,

1995.

VASCONCELOS, Alexandre Marcos Lins de. Introdução à engenharia de software e

à qualidade de software. Lavras: UFLA/FAEPE, 2006. Disponível em:
<http://www.cin.ufpe.br/~if720/downloads/Mod.01.MPS_Engenharia&QualidadeSoftw
are_V.28.09.06.pdf>. Acesso em: 11 abr. 2014.