Universidade do Minho

Escola de Engenharia

Marcelo Silva Pereira

Proposta de um sistema de apoio ao

processo de gesto de projetos de
software numa empresa de Manaus

Maro de 2013
Universidade do Minho
Escola de Engenharia

Marcelo Silva Pereira

Proposta de um sistema de apoio ao

processo de gesto de projetos de
software numa empresa de Manaus

Dissertao
Mestrado em Engenharia Industrial

Trabalho efetuado sob orientao do

Professor Rui M. Lima

Maro de 2013
 Declarao

Nome: Marcelo Silva Pereira

Endereo eletrnico: marcelo.silvapereira@gmail.com
Telefone: +5592 81130647 / +5592 92125426
Passaporte:

Ttulo dissertao de projeto:

Proposta de um sistema de apoio ao processo de gesto de projetos de software numa empresa de
Manaus.

Orientador: Professor Rui M. Lima

Ano de concluso: 2013

Mestrado em Engenharia Industrial

AUTORIZADA A REPRODUO INTEGRAL DESTA TESE/TRABALHO APENAS PARA

EFEITOS DE INVESTIGAO, MEDIANTE DECLARAO ESCRITA DO INTERESSADO, QUE A
TAL SE COMPROMETE;

Universidade do Minho, ___/___/______

Assinatura:_______________________________________________
Agradecimentos
Primeiramente a Deus, por me conceder sade e sabedoria para estar aqui nesse momento. Ao meu
pai Sr Lzaro que sempre me obrigou a tirar nota 110 na escola, querendo mostrar que eu sempre
podia ir mais alm. minha me Dona Inalda em quem eu sempre me inspirei para estudar desde
criana. Ao meu amigo Carlos Vamberto que sempre esteve disposto a me orientar nas dvidas
referente ao desenvolvimento das funcionalidades necessrias. Por fim ao professor Rui Lima pela
tima orientao ao longo destes anos de estudos. A todos muito obrigado.

i
PROPOSTA DE UM SISTEMA DE APOIO AO PROCESSO DE GESTO DE PROJETOS DE
SOFTWARE NUMA EMPRESA DE MANAUS

Resumo
Este estudo aborda as fases do desenvolvimento de sistemas desde a listagem dos requisitos do
cliente, passando por sua modelagem, desenvolvimento da arquitetura, construo do modelo de
dados, camada de persistncia, negcio, interface com o utilizador, teste e implantao, alinhada s
prticas de gesto de projetos com auxlio de uma ferramenta para gesto de projetos de software
(SGPS). Esta ferramenta de software tem como objetivo apontar prazos, custos previstos e realizados
ao longo do processo de desenvolvimento de software, o caso de uso desta anlise refere-se a um
projeto de software de uma empresa de desenvolvimento situado na cidade de Manaus - AM. Neste
trabalho apresentamos a ferramenta e anlise do caso de uso para o fim de auxiliar na tomada de
deciso do gestor de projetos quanto a mudanas no escopo em desenvolvimento.

Palavras-chave: Projecto; Gesto de Projetos; Desenvolvimento de sistemas;

ii
A SYSTEM TO SUPPORT THE PROCESS OF SOFTWARE PROJECT MANAGEMENT
DEVELOPMENT IN A BUSINESS COMPANY AT MANAUS

Abstract
This work presents a study about the phases of software development, including customer requirements
analysis, software modelling, development, building of data model, persistence layer, business
modelling, user interface, test and implementation. These phases were used to develop a tool to
support project management practice. This software tool aims to point out deadlines, anticipated and
real costs throughout the software development process. This tool was created to support software
projects from a development company located in the city of Manaus - AM. In this paper we present the
analysis tool and a specific use case from this company, showing that it allows an improved process of
decision making along the project, managing scope changes during the development phase.

Key words : Project; Project Management; System Development;

iii
ndice geral
Agradecimentos...................................................................................................................... i
Resumo ................................................................................................................................. ii
Abstract ................................................................................................................................ iii
ndice geral........................................................................................................................... iv
ndice de figuras ................................................................................................................... vi
1 INTRODUO ..............................................................................................................1
1.1 Enquadramento do Estudo ........................................................................................1
1.2 Objetivos do estudo ..................................................................................................2
1.3 Estrutura da Dissertao ...........................................................................................2
2 A GESTO DE PROCESSOS DE DESENVOLVIMENTO DE PROJETOS DE
SOFTWARE ..........................................................................................................................3
2.1 O Processo de Desenvolvimento de Software ...........................................................3
2.1.1 O mercado de desenvolvimento de software ......................................................3
2.1.2 A engenharia de software ..................................................................................5
2.1.3 Metodologias geis ............................................................................................9
2.1.4 Fases de processo de desenvolvimento de sistemas .......................................... 10
2.1.5 Anlise de Negcio e Modelao de Processos ................................................ 10
2.1.6 Anlise do sistema ........................................................................................... 12
2.1.7 Arquitetura do Sistema .................................................................................... 17
2.1.8 Desenvolvimento............................................................................................. 19
2.1.9 Teste ............................................................................................................... 21
2.1.10 Implantao ..................................................................................................... 22
2.2 A Gesto de Projetos .............................................................................................. 22
2.2.1 A Gesto de Projetos de Produo de Sistemas de Software ............................ 23
2.2.2 Fatores do projeto ............................................................................................ 24
2.2.3 Definio do mbito do projeto ....................................................................... 26
2.2.4 Estimao de prazos, recursos e custos ............................................................ 27
2.2.5 Anlise de ponto de funo .............................................................................. 28
2.2.6 Planeamento do projeto (cronograma) ............................................................. 33
2.2.7 Acompanhamento, controle e encerramento do projeto .................................... 35
2.2.8 Gesto de equipas ............................................................................................ 36
3 METODOLOGIA ......................................................................................................... 38
3.1 Contexto do Projeto de Investigao ....................................................................... 38
3.2 Caracterizao da pesquisa ..................................................................................... 39
4 ANLISE, IMPLEMENTAO E RESULTADOS DO PROJETO DE
INVESTIGAO ................................................................................................................ 42
4.1 Anlise do problema ............................................................................................... 42
4.2 Implementao ....................................................................................................... 45
4.2.1 Anlise de negcio .......................................................................................... 45
4.2.2 Anlise de sistema ........................................................................................... 46
4.2.3 Arquitetura do sistema ..................................................................................... 50
4.2.4 Desenvolvimento............................................................................................. 53
4.2.5 Testes .............................................................................................................. 55
4.2.6 Implantao e treinamentos ............................................................................. 56
4.3 Resultados .............................................................................................................. 58
5 CONCLUSO .............................................................................................................. 62
REFERNCIAS BIBLIOGRFICAS .................................................................................. 64
Anexo I Documento de viso ............................................................................................. 66

iv
Anexo II Diagrama de caso de uso ..................................................................................... 69
Anexo III Documento de especificao de Caso de Uso Manter Cliente ............................. 70
Anexo IV Documento de especificao de Caso de Uso Manter Colaboradores ................. 75
Anexo V Documento de especificao de Caso de Uso Manter Empresa ........................... 81
Anexo VI Documento de especificao de Caso de Uso Manter Projeto ............................ 86

v
ndice de figuras
Figura 1 Representao do modelo de desenvolvimento em cascata ..................................................................... 7
Figura 2 Representao do modelo de desenvolvimento iterativo e incremental (Pressman, 2009) ..................... 7
Figura 3 Representao do modelo de desenvolvimento evolucional ou prototipao (Miguel, 2010) .................. 8
Figura 4 Representao do modelo de desenvolvimento espiral (Miguel, 2010) .................................................... 9
Figura 5 Ciclo de iterao Scrum (Miguel, 2010). .................................................................................................... 10
Figura 6 Exemplo de layout de cadastro de colaborador ........................................................................................ 11
Figura 7 Modelo de diagrama entidade relacional ................................................................................................... 17
Figura 8 Arquitetura da plataforma .NET. (Miguel, 2010) ........................................................................................ 20
Figura 9 Rotinas de teste ........................................................................................................................................... 21
Figura 10 Viso geral das funcionalidades de uma aplicao segundo a anlise APF (Dias, 2012). .................. 30
Figura 11 O Procedimento de Contagem de Pontos de Funo. ........................................................................... 30
Figura 12 Grfico de Gantt para atividade de um projeto (Miguel, 2010). .............................................................. 34
Figura 13 Diagrama de rede de projeto. (Miguel, 2010) .......................................................................................... 35
Figura 14 Quadro de planeamento inicial do projeto ............................................................................................... 43
Figura 15 Quadro de organizao do ciclo do projeto ............................................................................................. 43
Figura 16 Quadro de acompanhamento do ciclo do projeto.................................................................................... 44
Figura 17 Fases do processo de desenvolvimento do sistema............................................................................... 45
Figura 18 Diagrama BPML do Processo Anlise de Negcio............................................................................... 46
Figura 19 Diagrama de caso de uso de adio de usurio ..................................................................................... 46
Figura 20 Diagrama de atividade de adio de usurio .......................................................................................... 47
Figura 21 Diagrama de classe da funo de adio de usurio ............................................................................. 48
Figura 22 Diagrama de sequencia de adio de usurio ........................................................................................ 49
Figura 23 Processo de Anlise de sistemas em BPML ........................................................................................... 50
Figura 24 Processo de Arquitetura de sistemas em BPML ..................................................................................... 50
Figura 25 Arquitetura de camadas do sistema ......................................................................................................... 51
Figura 26 Mtodos da camada DAO do sistema desenvolvido............................................................................... 52
Figura 27 Modelo de dados em diagrama entidade relacional do sistema ............................................................ 52
Figura 28 Processo de Desenvolvimento em BPML ................................................................................................ 53
Figura 29 Camada interface (Apresentao) do sistema Lista de projetos ......................................................... 53
Figura 30 Camada interface (Apresentao) do sistema Manuteno de projetos ............................................ 54
Figura 31 Camada de negcio da aplicao ............................................................................................................ 54
Figura 32 Processo de Teste em BPML ................................................................................................................... 55
Figura 33 Processo de Implantao e Treinamento em BPML ............................................................................... 56
Figura 34 Diagrama de implantao do sistema ...................................................................................................... 57
Figura 35 Lista principal de acompanhamento de projetos ..................................................................................... 58
Figura 36 Interface de cadastro de projetos ............................................................................................................. 59
Figura 37 Interface de cadastro de colaboradores................................................................................................... 59
Figura 38 Acompanhamento de projetos em desenvolvimento .............................................................................. 60

vi
1 INTRODUO

1.1 Enquadramento do Estudo

A eficincia de empresas e/ou institutos de desenvolvimento de sistemas de software medida pela
satisfao que seus produtos oferecem aos seus clientes e facilidades aos seus utilizadores. Quanto
mais um sistema informtico agrega valor ao processo de negcio de uma empresa, mais o produto de
software desenvolvido necessrio para o meio corporativo.
Para que o sucesso de um sistema informtico seja pleno, o mesmo deve atender a uma srie de
requisitos alinhados ao processo de negcio que apoia. Entre muitos requisitos do sistema pode referir-
se os seguintes: Facilidades de acesso; retornos confiveis de informaes; apoiar a tomada de
decises; controle das rotinas desenvolvidas no processo de negcio.
No entanto, atingir elevados nveis de satisfao no desenvolvimento de um sistema no uma tarefa
garantida se alguns pontos no forem cumpridos como descritos a seguir: a definio do mbito em
que o sistema informtico ser inserido, bem como seus limites de escopo e fonteiras de utilizao,
pelo engenheiro de sistemas; o conhecimento do processo padro de trabalho por parte do utilizador e
as sadas que o mesmo produz para a prxima fase do processo em questo; os dados que devem ser
mantidos por parte do utilizador no sistema informtico; e os ndices que devem ser visualizados para
apoio a tomada de deciso por parte do gestor do processo. Estes so apenas alguns dos fatores
importantes a esclarecer para o conhecimento do ambiente do processo de negcio que o sistema
deve auxiliar.
Tais fatores influenciam de forma significativa o processo de desenvolvimento do sistema, pois sem
eles o sistema no faz sentido e consequentemente no tem porque existir, porm, partir para a
especificao desse mbito requer uma atuao cuidadosa de todos que fazem parte desse processo,
para se definir os limites do que se deve e do que no se deve atender atravs do sistema.
Utilizadores, gestores, engenheiros de sistemas e arquitetos de software so figuras que compem a
equipe de definio dos limites do sistema informtico, especificando e modelando requisitos,
homologando interfaces, definindo tecnologias de desenvolvimento e por fim, os prazos e os custos
para a entrega do sistema.
Patterson and Hennessy (2000) afirmam que muitos projetos em grandes companhias foram
cancelados por terem ultrapassado o prazo inicialmente previsto para entrega do produto. Tal situao
ocorreu pelo fato do gestor das equipes de desenvolvimento no terem acesso a ferramentas com
previses aproximadas de prazos e que permitam gerir a execuo do projeto acompanhando cada
fase de seu desenvolvimento.

1
Portanto, encontrar uma alternativa dinmica que demonstre o processo de produo de sistemas de
software mais prximo da sua real situao, desde as atividades realizadas quanto disponibilidade
das equipes, necessrio para que aumente a fiabilidade da empresa de desenvolvimento e
consequentemente permitindo o crescimento da sua marca de eficincia no segmento.

1.2 Objetivos do estudo

A partir da metodologia utilizada, este estudo pretende desenvolver um mdulo de software que auxilie
o processo de produo de sistemas informticos mostrando o andamento de suas atividades, custos e
prazos apoiando a tomada de deciso para eventuais mudanas no projeto por parte do gestor.

1.3 Estrutura da Dissertao

Este trabalho de investigao se inicia com seu enquadramento e apresentao dos objetivos, seguida
da pesquisa bibliogrfica consultada. Logo depois a metodologia utilizada no projeto de investigao,
seguida pela anlise dos resultados do projeto, apresentao do produto de software desenvolvido e
finalizando com a concluso, referncias bibliogrficas e anexos.

2
2 A GESTO DE PROCESSOS DE DESENVOLVIMENTO DE PROJETOS DE
SOFTWARE

2.1 O Processo de Desenvolvimento de Software

A princpio o processo de construo de software se d a partir das fases de desenvolvimento
estabelecidas por uma organizao. Essas fases de desenvolvimento so importantes para se
conhecer os passos necessrios para a implementao de um sistema informtico desde as demandas
especficas junto ao utilizador, a metodologia de desenvolvimento a utilizar, a arquitetura que o sistema
ir utilizar, o seu desenvolvimento, modelos de testes e implantao. Para alm destes aspetos, Ainda
necessrio garantir que o acompanhamento das atividades ao longo do processo de construo do
sistema esteja alinhado com as prticas de gesto de projetos, pos atravs deste acompanhamento
que o gestor de projeto fornece informaes sobre o desenvolvimento do mesmo s partes
interessadas e visualiza os impactos de possveis mudanas no decorrer do seu andamento.

2.1.1 O mercado de desenvolvimento de software

Inicialmente h a necessidade de se organizar o modo de produo de um sistema de software. Para
isso, deve-se adotar uma metodologia de desenvolvimento que esteja mais adequada s
caractersticas de trabalho da equipa de trabalho como tambm as caractersticas do produto de
software a ser entregue ao final do projeto.
Para facilitar a organizao do processo de produo de um sistema informtico, vrias metodologias
de desenvolvimento foram criadas com o objetivo de aperfeioar as fases de construo de um
sistema. Basta apenas que o gestor de desenvolvimento, levando em considerao os recursos
disponveis, adote uma metodologia que mais se adeque realidade ou que possa ser utilizada como
propulsora das melhores prticas de desenvolvimento da sua equipe.
Essa organizao ainda se tem tornado mais necessria devido ao crescimento do mercado de
sistemas informticos direcionado a solues corporativas (Mertz, 2007), que tinha em 2007 uma
projeo de crescimento de 22,1% at 2011 ficando em torno de US $12,3 bilhes, superando os 9%
de crescimento esperado do mercado de tecnologia da informao como um todo. Contudo, o mercado
mundial de sistemas tinha a previso de atingir cerca de US $ 14,5 bilhes em 2012 e de acordo com
os relatrios trimestrais de acompanhamento da Gartner, Inc a projeo de que at 2015 esse
mercado deve atingir a receita de US $22,1 bilhes (Mertz, 2012). Este crescimento tem sido maior do
que o esperado devido ao avano das tecnologias mveis, ferramentas de desenvolvimento e
necessidade das empresas possurem sistemas de software que apoiem a gesto de seus negcios.

3
Em 2011, 63% dos produtos do mercado de sistemas informticos como servio vai suportar web
service e tecnologias de web (Mertz, 2007), promovendo uma maior operacionalizao dos negcios
da empresa a partir de qualquer parte do mundo atravs da internet. Tendendo a partir de ento que
todos os sistemas a serem construidos tenham essa arquitetura. Esta arquitetura viabiliza o acesso
direto por parte do cliente de qualquer lugar do mundo com acesso a rede mundial de computadores,
possibilitando ao utilizador acesso informao da sua empresa como se o mesmo nunca tivesse
sado dela. Mertz (2007) ainda afirma que o sistema informtico como servio via Web mais do que
uma opo hoje: um elemento que est ganhando cada vez mais importncia no mercado com o
passar do tempo, principalmente para as empresa divulgarem suas marcas mundo a fora (visibilidade)
e consequentemente atrarem novos negcios.
Porm existem obstculos para o avano dos sistemas informticos direcionados a gesto de
empresas. A maioria das empresas de desenvolvimento de sistemas est reestruturando os seus
produtos de software para a arquitetura orientada a servios, ou seja, aplicaes de software com
requisitos muito abrangentes direcionados a propsito gerais de servio onde contm muitas
funcionalidades que por sua vez no so 100% necessria aos seus utilizadores, exigindo alto valor de
investimento, extenso prazo de desenvolvimento, o que obriga seus clientes a investirem na migrao
de seus recursos tecnolgicos para essa arquitetura.
Por outro lado esses clientes tm a oportunidade de avaliar se os sistemas informticos como servios
so alternativas vlidas para outros aspetos do negcio, quer dizer, sistemas mais especficos para as
suas necessidades de negcio, e que so desenvolvidos em menos tempo e com menor custo (Mertz,
2007).
No entanto, desenvolver sistemas de software em curto perodo de tempo, direcionado a aplicaes
corporativas no fcil, devido, entre outros aspectos, considerao das necessidades reais de cada
cliente, ao grande nmero de fases que constam nos processos de negcio, e s regras de negcios
complexas e especficas de cada empresa. Cada cliente possui uma necessidade especfica de acordo
com os seus processos de negcio, o que obriga empresas de desenvolvimento de sistemas a passar
muito tempo na fase de planeamento do projeto com o objetivo de entender o funcionamento real do
processo de negcio do cliente.
Blaschek (2009) cita uma srie de fatores que contribuem para a inviabilidade do desenvolvimento da
grande maioria dos sistemas de software: vrias mudanas nos requisitos do utilizador no decorrer do
projeto; prazos de entrega e custos de investimento estimado de maneira errada; conflitos frequentes
entre colaboradores da equipe de desenvolvimento; utilizadores insatisfeitos com o produto
apresentado; equipes desmotivadas com baixo nvel de produo. Estes so alguns fatores que
frequentemente so encontrados em ambientes de desenvolvimento de projetos de software,

4
contribuindo para a perda dos investimentos e consequentemente prejuzos para toda a empresa de
desenvolvimento.
Para contornar essa situao o uso das prticas de gerenciamento de projetos, especificamente,
propostos pela literatura, traz uma enorme contribuio para melhorar esse problema. Para torn-lo
ainda mais eficiente, necessrio alinhar essas prticas com a engenharia de software.
Tornar mais eficiente o processo de desenvolvimento de sistemas informticos, num mercado que
totalmente dinmico e imprevisvel, atravs de mtodos e tcnicas especficas de gesto de projetos
auxiliadas por metodologias de engenharia de software deve disponibilizar solues rpidas e
consistentes (produtos de software) aos clientes proporcionando a empresa de desenvolvimento maior
competitividade de mercado e consequentemente crescimento dos seus negcios.
O dinamismo das necessidades de software do cliente faz com que empresas de desenvolvimento
tentem se adequar e buscar metodologias que proporcionem respostas rpidas e baixo custo em
construo e aperfeioamento de sistemas para os mesmos, melhorando o processo de produo de
sistemas e proporcionando a empresa de desenvolvimento responder com maior agilidade e eficincia
as necessidades do mercado de sistemas junto aos seus clientes.

2.1.2 A engenharia de software

Engenharia de software uma rea do conhecimento da computao voltada para a especificao,
desenvolvimento e manuteno de sistemas de software aplicando tecnologias e prticas de gerncia
de projetos, objetivando organizao, produtividade e qualidade. o arcabouo que constitui o
processo, os conjuntos de mtodos e ferramentas necessrias (Pressman, 2009). Esta rea de
conhecimento surgiu com o objetivo de utilizar princpios de engenharia no desenvolvimento de
software para aumentar a qualidade dos produtos oferecidos, diminuindo custos e riscos relacionados e
criar processos repetveis e eficazes para serem utilizados nos ciclos de manuteno e
desenvolvimento de software, que com o passar dos anos foram se tornando modelos a serem
seguidos por outros ambientes de desenvolvimento. Por sua vez outros ambientes desenvolveram seus
prprios modelos para se adaptarem melhor sua realidade.
Uma metodologia de processo de desenvolvimento de software, ou simplesmente modelo de processo,
pode ser visto como uma representao ou abstrao dos objetos e atividades envolvidas no processo
de software (negcio inserido). Alm disso, oferece uma forma mais abrangente e fcil de representar a
gesto do processo de desenvolvimento de software e consequentemente do progresso do projeto. A
Tabela 1 apresenta as vantagens e desvantagens de alguns modelos atualmente conhecidos.

5
Tabela 1 - Relao entre modelos atuais de engenharia de software.
Modelo Caracterstica
Apresenta fases distintas de
Sequencial ou
especificao, projeto e
cascata
desenvolvimento.
O modelo iterativo e incremental
uma alternativa para soluo de
problemas enfrentados no
modelo cascata. Nesse modelo,
considera-se o desenvolvimento
do software em ciclos iterativos
onde uma pequena poro dos
Desenvolvimento
requisitos passa por todas as
interativo e
etapas de desenvolvimento como
incremental
em um modelo cascata. Ao final
de cada ciclo de iterao tem-se
uma nova verso do software, a
qual ser incrementada a cada
novo ciclo que ocorrer. Isso reduz desenvolvimento da primeira
a ansiedade do utilizador em
relao ao software.
Evolucional ou Especificao, projeto e
prototipao desenvolvimento de prottipos. Antecipa o treinamento dos
Evoluo atravs de vrios ciclos Apresenta uma abordagem
completos de especificao,
Espiral
projeto e desenvolvimento.
6
Vantagem Desvantagem
No fornece feedback entre as
Torna o processo de fases e no permite a
desenvolvimento estruturado; atualizao ou redefinio das
Tem uma ordem sequencial de fases anteriores;
fases; No suporta modificaes nos
Cada fase cai em cascata na requisitos;
prxima e cada fase deve estar No prev a manuteno;
terminada antes do incio da No permite a reutilizao;
seguinte; excessivamente
Todas as atividades sincronizado;
identificadas nas fases do Se ocorrer um atraso todo o
modelo so fundamentais e processo afetado;
esto na ordem certa; Faz aparecer o software muito
tarde;
Menor custo e menos tempo
so necessrios para se
entregar a primeira verso. Se os requisitos no so to
Riscos associados ao estveis ou completos quanto
desenvolvimento de se esperava, alguns
incrementos so menores, incrementos podem precisar
devido ao seu tamanho ser retirados de uso e
reduzido. retrabalhados ;
Nmero de mudanas nos A gesto de custo, cronograma
requisitos pode diminuir devido e configurao mais
ao curto tempo de complexo.
verso.
Melhora a qualidade da
especificao do software,
contribuindo para uma queda
O custo na maioria dos casos
nos custos de desenvolvimento
considerado muito alto.
e manuteno.
O cliente tende a confundir o
prottipo com uma verso do
utilizadores.
sistema.
Partes do prottipo podem ser
aproveitadas no
desenvolvimento do sistema.
Suporta mecanismos de
reduo de risco
Inclui interaes
Reflete as prticas reais da
engenharia atual
Avaliao dos riscos exige
sistemtica muita experincia.
Estimativas tornam-se mais O modelo relativamente novo
realsticas com o progresso do e no tem sido amplamente
trabalho, porque problemas utilizado
importantes so descobertos
mais cedo.
mais verstil para lidar com
mudanas que desenvolvim. de
software geralmente exige.
A Figura 1 representa o modelo de desenvolvimento em cascata que consiste em vrios processos
estruturados de forma linear que precisam estar totalmente concludos para o incio da prxima
atividade na sequncia. O modelo permanece restrito em uma nica sequncia do incio ao fim.

Figura 1 Representao do modelo de desenvolvimento em cascata

Na Figura 2 podemos observar que o projeto principal dividido em mdulos menores (incrementos) e
a partir de ento desenvolvido em partes. O desenvolvimento por partes semelhante ao modelo
cascata, porm partes maiores do projeto de software como estudo e projeto do mesmo, j foram
definidos anteriormente.

Figura 2 Representao do modelo de desenvolvimento iterativo e incremental (Pressman, 2009)

7
A Figura 3 sugere o sistema ser desenvolvido em parte de um esboo que documentado,
desenvolvido e validado junto ao cliente ao mesmo tempo. O risco que este modelo prope que se o
prottipo no atender aos requisitos do cliente o esforo gasto desenvolvendo o prottipo totalmente
perdido, tento ento que partir para uma nova abordagem. Por outro lado, se a prototipao atender as
necessidades do cliente, juntamente com a documentao aprovada, o sistema fica mais prximo de
sua concluso.

Figura 3 Representao do modelo de desenvolvimento evolucional ou prototipao (Miguel, 2010)

Por fim, a Figura 4 aborda a continuidade do ciclo do processo de desenvolvimento definindo seus
objetivos, analisando os ricos, desenvolvendo, testando, implantando e planejando a prxima fase do
projeto, no entanto esse modelo exige da equipe de desenvolvimento muita maturidade dos processos
de construo o que diminui devido s inmeras variveis que compem os sistemas a serem
desenvolvidos.

8
Figura 4 Representao do modelo de desenvolvimento espiral (Miguel, 2010)

2.1.3 Metodologias geis

Alinhada a engenharia de software que define a metodologia, os passos a serem seguidos, os
procedimentos a serem utilizados pela equipa de desenvolvimento, as metodologias geis propem
uma gesto das atividades objetivando a entrega mais gil do produto em desenvolvimento.
Entre inmeras metodologias geis, destaca-se atualmente a metodologia Scrum que de acordo com
Kniberg (2007) um framework de boas prticas de gesto de atividades a serem desenvolvidas, ou
seja, ele no diz como fazer, mas sim o que se deve fazer.
A principal caracterstica do Scrum o product backlog, que contm todas as necessidades dos
clientes, no entanto a equipe de desenvolvimento, de acordo com a prioridade dos desejos do cliente,
estima a quantidade de esforo necessrio para o desenvolvimento de uma funcionalidade que dever
ser entregue finalizada ao final de um sprint. A Figura 5 ilustra a realizao de um ciclo de trabalho de
uma equipe de desenvolvimento utilizando Scrum.

9
Figura 5 Ciclo de iterao Scrum (Miguel, 2010).

2.1.4 Fases de processo de desenvolvimento de sistemas

Como qualquer produto a ser produzido, todo sistema de software deve obedecer a fases de
construo que visam garantir que todos os requisitos funcionais solicitados pelo cliente sejam
desenvolvidos na aplicao e entregues com um nvel satisfatrio de aceitao.
No entanto com o dinamismo dos negcios dos clientes, novas necessidades de controlos dos
processos de negcio, atualizaes do sistema de software, faz-se necessrio o desenvolvimento de
novas funcionalidades a serem includas nas aplicaes atuais devido s correntes mudanas.
Consequentemente, desenvolver de forma rpida as novas rotinas necessrias torna-se um diferencial
para as empresas de desenvolvimento de sistemas que conseguem em um baixo custo e tempo de
resposta adequar os sistemas atuais as novas regras de negcios solicitadas e/ou impostas.
Com isso, algumas empresas acabam simplificando seus processos de desenvolvimento de sistemas
de modo a torna-los mais enxutos e menos demorados. Algumas empresas de desenvolvimento por
sua vez aderem s metodologias de desenvolvimento geis que tem o foco maior em atender e
satisfazer as necessidades do cliente, sem aderir ao processo de desenvolvimento tradicional de
sistemas. No entanto a seguir so apresentados tpicos bsicos para o desenvolvimento de um
sistema bem como suas ferramentas.

2.1.5 Anlise de Negcio e Modelao de Processos

A anlise de negcio, como a primeira fase do processo de desenvolvimento de software, consiste
exatamente em realizar a primeira abordagem junto ao cliente para entender suas reais necessidades e
avaliar se a nova funcionalidade do sistema realmente atender as expectativas do cliente para o
melhor andamento e controle dos seus processos. Muitas empresas, at as que utilizam metodologias

10
de desenvolvimento gil esto adotando essa fase em seus processos de desenvolvimento justamente
para avaliar se as funcionalidades a serem desenvolvidas realmente iro agregar o valor desejado aos
seus clientes.
Nessa fase, o analista de negcio, compe junto ao cliente o documento de viso, o modelo de
processo e as propostas de interface de utilizador que a funcionalidade deve atender.
O documento de viso descreve exatamente o funcionamento da funcionalidade desejada, suas aes,
iteraes e controles de maneira textual clara e objetiva, proporcionando a viso necessria aos
analistas de sistemas, desenvolvedores e analistas de teste sobre o funcionamento e os impactos
proporcionados pela mesma ao sistema e ao negcio do cliente.
A interface de utilizador prope um modelo de interface que atenda as necessidades do utilizador e
descreva na mesma as funcionalidades disponveis, a disposio dos dados a visualizar e a
navegabilidade do sistema de forma intuitiva para o cliente. A Figura 6 exibe um exemplo de interface
do utilizador.

Figura 6 Exemplo de layout de cadastro de colaborador

O modelo de processo apresenta atravs de diagrama de fluxo a iterao do sistema com todos os
setores interessados e colaboradores a utilizar a rotina em seu respetivo processo de negcio de forma
objetiva, inclusive suas respetivas tomadas de deciso.

11
Inmeras linguagens auxiliam na elaborao do fluxo de negcio de uma empresa. Vrias descrevem
eficientemente os complexos nveis de detalhes que compreendem o processo de negcio, porm no
disponibiliza a visibilidade necessria para que a implantao de um projeto tenha sucesso (Bortolini,
2006). O BPMI.org (Business Process Management Initiative), preocupada em gerar uma nova e
atualizada especificao para descrever processos de negcios, lanou em 2002 o BPML Business
Process Modelling Language que alm de descrever o processo de negcio, expe de maneira
objetiva a execuo de uma rotina e permite representar o processo de negcio de uma organizao
como um todo. A utilizao do BPML na modelagem do processo para a implantao de um projeto
auxilia na compreenso do processo como um todo, disponibilizando aos colaboradores o impacto que
cada fase de processo pode gerar (Hoyer, Bucherer & Schnabel, 2007).
A aplicao da linguagem BPML para descrio dos processos a serem desenvolvidos numa empresa
de desenvolvimento de software, contribui para a diminuio do tempo que o engenheiro de sistemas
necessita para estudar e abstrair cada fase do processo de negcio para o desenvolvimento do modelo
de software, relativamente descrio em ferramentas que no unificam os processos. A reduo no
tempo de modelao dos processos torna a fase de descrio dos requisitos de sistemas mais rpida e
simples, reduzindo tambm o tempo de construo do software.
A linguagem apresenta de forma to clara e genrica as fases que consistem o processo de negcio
que pode ser adotada por outras reas que necessitam da visibilidade das rotinas que antecedem uma
determinada fase do processo. Como exemplo a rea de controlo e gesto da qualidade pode utilizar o
mesmo diagrama BPML para mapear os processos de negcio da empresa e implantar polticas de
melhorias de processo em suas respetivas fases.
Uma das maiores vantagens da linguagem representar de forma simples os dados necessrios para
a execuo do processo, o funcionamento do processo principal e o resultado final do processo que
pode servir como entrada para um novo processo.

2.1.6 Anlise do sistema

Um sistema no pode ser desenvolvido antes de se saber realmente que necessidades de facto
precisa satisfazer. A anlise do sistema prope especificar os requisitos necessrios para o
funcionamento pleno e eficiente do sistema a ser desenvolvido.

O levantamento e a especificao dos requisitos

comum afirmar que a fase mais importante e de maior custo para o projeto de desenvolvimento de
software a sua fase de construo. Porm o que muitos no sabem que na fase de construo
todos os limites do projeto j esto delimitados, todo o mbito est definido, todo requisito j est

12
detalhado e homologado com o utilizador e todas as suas funcionalidades esto representadas nos
seus respetivos modelos (diagramas) de funcionamento.
Porm, a definio de todas as funcionalidades do sistema, expectativas e necessidades do utilizador
devem ser detalhadas e homologadas antes da fase de construo do sistema atravs das
especificaes de requisitos e formalizadas em documentos de especificao de requisitos.
Os requisitos do sistema so divididos em funcionais e no funcionais. O primeiro define as
funcionalidades ou aes que o sistema deve disponibilizar aos utilizadores na sua entrega final. J os
requisitos no funcionais descrevem atributos do sistema ou do ambiente do mesmo como:
extensibilidade, usabilidade, confiabilidade, desempenho, escalabilidade, reusabilidade, capacidade de
manuteno, reutilizao de cdigo, desempenho, eficincia no desenvolvimento e confiabilidade nos
dados apresentados (Engholm, 2010).
Nessa fase realizada a listagem dos requisitos ou levantamentos dos requisitos. a partir desta
atividade que se inicia o processo de descrever detalhadamente todos os objetivos e restries
envolvidas no s para o correto planeamento, viabilidade e custo, mas tambm para produzir um
sistema que atenda as necessidades e expectativas do utilizador. Logo o entendimento e controlo
desses requisitos so fundamentais para o sucesso do projeto e seus objetivos.
No entanto, um dos grandes obstculos no levantamento de requisitos quando ele deve ser realizado
em ambientes no qual as suas fontes de informao (utilizadores) no disponibilizam tempo para
reunies de levantamento/especificaes ou no disponibilizam arquivos que esclaream os objetivos
do projeto a desenvolver.
Porm, listar requisitos deve ser entendido como um processo de descoberta e entendimento do
domnio do problema a ser atendido pelo projeto de software a ser desenvolvido, alm das
necessidades de negcio a serem auxiliadas (Engholm, 2010). Essa fase executada pelo engenheiro
de sistemas e os utilizadores a serem atendidos pelo projeto.
As informaes so listadas por meio de reunies, entrevistas, anlises de documentos, anlises de
sistemas j utilizados, observaes de tarefas realizadas no dia-dia da empresa, diagramas de
workflow e so alinhados aos problemas de negcio a ser atendido pelo projeto de software e
registrado em ata todos os requisitos acordados.
Todos os procedimentos a serem adotados no processo de levantamento de requisitos devem estar
registrados no documento de especificao de requisitos, que por sua vez descreve em detalhes todos
os procedimentos a serem adotados para o desenvolvimento de determinada funcionalidade, como
listado abaixo:

13
 Descrio do documento de caso de uso: Descreve a funcionalidade principal a ser
especificada pelo documento em questo. responsvel por identificar a funcionalidade que
est se detalhando.
Layout sugerido da funcionalidade: Exibe o layout de interao com o utilizador para a
utilizao da funcionalidade descrita pelo documento de caso de uso. Este layout deve ser
previamente aprovado junto ao utilizador nas reunies de especificao de requisitos.
Relacionamento com outros casos de uso: Informa se esta funcionalidade possui algum
relacionamento com outras funcionalidades descritas em outros documentos de casos de uso.
Alguns documentos especificam funcionalidades que so apenas partes de um processo, ou
processos que suas sadas so entradas para outros processos descritos em outros
documentos.
Campos adotados na pelo layout sugerido: Descreve os campos utilizados no layout sugerido,
bem como os dados que so recebidos/exibidos, seus tipos de dados e suas regras de
exibio.
Atores: Especifica os atores que podem utilizar esta funcionalidade bem como os que possuem
acesso a este layout sugerido quando o sistema estiver funcionando.
Pr condies: Define condies necessrias para que o funcionamento seja efetuado pelo
utilizador do sistema, como acesso ao sistema, ter acesso a funcionalidade, hierarquia e/ou
acessibilidade do sistema.
Ps condies: Especifica os resultados disponibilizados gerados pela funcionalidade em
questo para as prximas funcionalidades que dependem ou no deste caso de uso.
Regras de negcio: Contendo uma das informaes mais importantes para o documento de
caso de uso, a regra de negcio descreve como a funcionalidade se comporta com execues
inesperadas, tratamentos de erros e no conformidades com o processo padro de negcio
que o sistema se aplica. Aqui so retratados todos os riscos que podem ocorrer no momento
de execuo da funcionalidade bem como as rotinas de contorno desses riscos.
Fluxo principal: Descreve de forma textual o funcionamento ideal da funcionalidade descrita no
caso de uso elaborado.
Por fim, a modelagem descreve e apresenta seus respetivos diagramas de caso de uso; diagramas de
atividades; diagrama de classe; diagrama de sequncia e diagrama de estados.

14
Modelagem do sistema
Um modelo uma simplificao da realidade. Os modelos podem realizar planos detalhados, assim
como planos mais gerais com uma viso panormica do sistema. Para modelagem da maioria dos
sistemas de software utilizada a UML (Unified Modeling Language), que permite que o sistema seja
descrito sob diferentes aspetos, utilizando modelos especficos para cada caso representando os
requisitos solicitados.
Conforme (Engholm, 2010), um requisito uma condio que o sistema necessita para atingir o seu
objetivo. O objetivo de todo sistema atender a um conjunto de requisitos, as necessidades que o
sistema deve satisfazer.
Modelar os requisitos de um sistema simplifica o seu desenvolvimento, norteia um programador. A UML
no um mtodo de desenvolvimento, o que significa que ela no diz o que fazer primeiro e em
seguida ou como desenhar o sistema, mas auxilia a visualizar seu desenho e a comunicao entre
objetos. Por sua vez composta por muitos elementos de modelo que representam as diferentes
partes de um sistema de software, onde o mesmo busca levantar as necessidades e requisitos para
seu desenvolvimento e modelagem para descrev-los de forma mais intuitiva em interaes. Os
elementos UML so usados para criar diagramas, que representam uma determinada parte, ou um
ponto de vista do sistema. Abaixo esto descritos alguns modelos importantes:
Diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que ser
projetado. Podemos dizer que um caso de uso um "documento narrativo que descreve a
sequncia de eventos de um ator que usa um sistema para completar um processo". Casos de
uso so considerados como comportamentos e funcionalidades desejadas para o sistema
visveis aos utilizadores. Comportamento refere-se ao que o sistema deve fazer como resposta
a eventos gerados da interao do mesmo com seus utilizadores (Engholm, 2010).
Diagrama de atividades pode ser visualizado o incio, fim, atividades e fluxo alternativos
associados ao fluxo de eventos de um caso de uso. Na criao de um diagrama de atividade
possvel executar tarefas como de identificar atividades, identificar loops, atividades paralelas e
decises. Segundo Bezerra (2002), diagrama de atividades um tipo especial de diagrama de
estados, onde so apresentados os estados de uma atividade, em vez dos estados de um
objeto. Estes diagramas so orientados a fluxos de controlo. Engholm (2010) resume dizendo
que um diagrama de atividades permite modelar o comportamento do sistema, denotando os
caminhos lgicos que um processo pode seguir.
Diagrama de classe demonstra a estrutura esttica das classes de um sistema onde estas
representam as "coisas" que so gerenciadas pela aplicao modelada. Classes podem se
relacionar com outras atravs de diversas maneiras: associao (conectadas entre si),

15
 dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma
especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas
similares).
Diagrama de sequncia mostra a troca de mensagens entre diversos objetos, em uma situao
especfica e delimitada no tempo. Coloca nfase especial na ordem e nos momentos nos quais
mensagens para os objetos so enviadas. Os objetos so representados atravs de linhas
verticais tracejadas (denominadas como linha de existncia), com o nome do objeto no topo. O
eixo do tempo e tambm vertical, aumentando para baixo, de modo que as mensagens so
enviadas de um objeto para outro na forma de setas com a operao e os nomes dos
parmetros. Os diagramas de sequncia procuram mostrar a execuo de um processo ou
tarefa, desde sua criao at sua concluso, bem como os responsveis por cada evento e
suas respetivas trocas de mensagens.
Diagrama de implantao descreve os componentes de hardware e software e sua interao
com outros elementos de suporte ao processamento. Representa configurao e a
arquitetura de um sistema em que estaro ligados seus respetivos componentes, sendo
representado pela arquitetura fsica de hardware, processadores etc.

Modelo Entidade Relacional ER

O modelo Entidade-Relacionamento (ER, ou tambm chamado Entidade Associao) usado na
maioria dos mtodos e ferramentas de auxlio conceo de BD's (MERISE, IDA, Yourdon, ERWin). A
ideia fundamental deste modelo a de conservar como conceitos de base os conceitos genricos
(objetos, associao, propriedade) usados no processo de abstrao que vai da observao de uma
realidade sua descrio. Existem trs elementos fundamentais para a elaborao do modelo entidade
relacional: entidade, associao e os atributos. A Figura 7 apresenta um exemplo de um modelo ER.

16
Figura 7 Modelo de diagrama entidade relacional

2.1.7 Arquitetura do Sistema

Definir bem o ambiente em que se desenvolve uma deciso importante para o processo de
desenvolvimento de sistemas, pois impem ao cliente do produto adequao ao ambiente necessrio
para a execuo do sistema de software construdo. A fase de arquitetura composta pela execuo
dos requisitos no funcionais definidos pelo engenheiro de sistemas e aprimorar as ferramentas a fim
de diminuir o tempo de desenvolvimento dos requisitos funcionais definindo a linguagem de
programao junto com seu ambiente de desenvolvimento, as bibliotecas a utilizar ou a construir
(framework) e por fim, a camada onde os dados manipulados pela aplicao a ser desenvolvida ir
persistir seus dados definindo assim seu banco de dados. Abaixo esto listados alguns itens
importantes para uma arquitetura bem consolidada:
A Linguagem de programao, de acordo com Willrich (2004), tem seu conceito dividido em
linguagem de baixo nvel e linguagem de alto nvel. Mesmo com a evoluo dos ambientes de
desenvolvimento, incluindo as linguagens, a definio delas continua sendo a mesma.
As linguagens de programao, mais especificamente as de alto nvel so assim
denominadas por apresentarem uma sintaxe mais prxima da linguagem natural, fazendo
uso de palavras reservadas extradas do vocabulrio corrente (como READ, WRITE, TYPE,
etc...) e permitirem a manipulao dos dados nas mais diversas formas (nmeros inteiros,
reais, vetores, listas, etc...);

17
 Com isso, inmeras linguagens surgiram de acordo com as necessidades de plataformas de
desenvolvimento, onde as mesmas possuem pequenas diferenas de sintaxe, passagem de
parmetros, chamadas de mtodos entre outros detalhes percetveis apenas pelo
desenvolvedor do sistema. Abaixo a tabela apresenta algumas caractersticas de linguagens de
programao utilizadas atualmente.

Tabela 2 - Relao entre linguagens de programao atuais.

Linguagem Java PHP C Sharp
uma linguagem de
uma linguagem de
uma linguagem orientada programao orientada a
programao orientada a
a objetos onde ao invs do objetos. A sua sintaxe
objetos. antes de tudo
cdigo ser compilado, ele orientada a objetos foi
uma linguagem simples,
Caracterstica interpretado. O PHP uma baseada no C++, mas inclui
robusta, segura, extensvel,
linguagem livre e atualmente muitas influncias de outras
bem estruturada, distribuda,
muito utilizada para gerar linguagens de programao
multithreaded e com coletor
contedo dinmico. e Java.
de lixo.
Plataforma de
Independente de plataforma Independente de plataforma Independente de plataforma
funcionamento
Ambiente de
Web e Desktop Web Web e Desktop
funcionamento
Desenvolvido por Sun Microsystems Livre Microsoft
No possui sobrecarga de
operadores, structs, unions,
aritmtica de ponteiros,
herana mltipla, arquivos.
h, diretivas de pr-
Velocidade, robustez, Facilidade na sintaxe de
processamento e a memria
estruturao e orientao a programao, mtodos
Vantagem alocada dinamicamente
objetos, portabilidade e prontos pra rotinas, fcil
gerenciada pela prpria
tipagem dinmica. acesso a bancos de dados.
linguagem, que usa
algoritmos de coletor de lixo
para liberar regies de
memria que no esto
mais em uso.

Framewok so nada mais que bibliotecas de funcionalidades prontas que uma vez
desenvolvidas podem ser transformadas em componentes e reutilizadas por outros sistemas
atravs de chamadas de seus mtodos internos. Com o surgimento do paradigma da
orientao a objetos, a tecnologia adequada para reuso de grandes componentes tornou-se
disponvel e resultou na definio de frameworks orientados a objetos. Os principais benefcios
dos frameworks orientados a objetos decorrem da modularidade, reusabilidade, extensibilidade
e inverso de controlo que eles oferecem aos desenvolvedores, otimizando o tempo de
desenvolvimento de um determinado sistema que possui as mesmas caractersticas de outros

18
 j desenvolvidos, consequentemente aumentam modularidade atravs do encapsulamento de
detalhes volteis de implementao por trs de interfaces estveis. A modularidade dos
frameworks ajuda a aumentar a qualidade do software, concentrando o impacto das mudanas
de projeto e implementao, o que reduz o esforo necessrio para entender e manter
softwares existentes. Frameworks maduros permitem uma reduo de mais de 90% do volume
de cdigo fonte que tem que ser escrito para desenvolver uma aplicao, quando comparado
com software escrito com o suporte de uma biblioteca convencional de funes.
Banco de dados uma coleo de dados estruturados, organizados e armazenados de forma
persistente, proporcionando atualizaes automticas dos dados. Alguns dos benefcios de
utilizao de um banco de dados a centralizao dos dados, tornando seu acesso mais
rpido. A confiabilidade outro ponto importante, pois julgando os dados sejam reais
possvel obter diversas informaes referentes a uma organizao por exemplo. Alguns
modelos de construo de dados para determinadas aplicaes possibilitam a maior
disposio e velocidade de acesso s informaes tornando a aplicao mais confivel e
eficiente.

2.1.8 Desenvolvimento
Dentre as diversas maneiras de desenvolvimento de sistemas, abaixo seguem listados uma estrutura
de desenvolvimento de sistemas utilizando a tecnologia .net (exemplificada na Figura 8) com modelos
de acesso a dados utilizando Linq:
.NET uma plataforma de software que conecta informaes, sistemas, pessoas e
dispositivos. Nela conectamos uma grande variedade de tecnologias de uso pessoal, de
negcios, de telefonia celular a servidores corporativos, permitindo assim, o acesso rpido a
informaes importantes onde elas forem necessrias e imprescindveis. Desenvolvido sobre
os padres de Web Services XML, o framework .NET possibilita que sistemas e aplicativos,
novos ou j existentes, conectem seus dados e transaes independente do sistema
operacional (SO) instalado, do tipo de computador ou dispositivo mvel que seja utilizado e da
linguagem de programao que tenha sido utilizada na sua criao. O .NET oferece a
capacidade de desenvolver, implementar, gerenciar e usar solues conectadas atravs de
Web Services XML, de maneira rpida, barata e segura. Essas solues permitem uma
integrao mais gil entre os negcios e o acesso rpido a informaes a qualquer hora, em
qualquer lugar e qualquer dispositivo. Todas as aplicaes escritas para a .NET correm
dentro de uma mquina virtual chamada Common Language Runtime (CLR). O cdigo que se

19
 encontra a executar aqui dentro chama-se managed code e beneficia de vrias maneiras
como:
1. Gesto automtica de memria: o CLR dispe de um garbage collection que se
encarrega de limpar os objetos que j esto a ser utilizados palas aplicaes;
2. Segurana: o CLR possui mecanismos que permitem atribuir permisses ao cdigo,
baseadas na sua provenincia e em quem o est a executar. Existem tambm
mecanismos que permitem garantir que o cdigo a executar vlido e no ir corromper
outros programas que se encontrem a executar no CLR;
3. Traduo de cdigo intermedirio (IL) para cdigo nativo: ao compilar um programa na
plataforma .NET, tipicamente, este traduzido de uma linguagem de alto nvel para uma
linguagem intermediria chamada MSIL (Microsoft Intermediate Language). O CLR possui
um compilador just-in-time que se encarrega de traduzir o cdigo intermedirio para cdigo
nativo do processador, antes de o executar;
4. Carregamento dinmico de classe: o CLR torna possvel carregar, em tempo de
execuo, segmentos de cdigo que antes no estavam presentes na mquina virtual.

Figura 8 Arquitetura da plataforma .NET. (Miguel, 2010)

Linq (Language Integrade Query) uma linguagem integrada de consulta que permite tratar de
forma uniforme dados de diferentes origens (Como exemplo bases de dados ou arquivos XML).
Sua ideia principal resolver um dos maiores problemas de aplicaes orientada a objeto que
por um lado os objetos so excelentes para manipulao em linguagem de programao, mas
por outro lado o armazenamento de dados se faz tipicamente em base de dados relacionais ou
arquivos XML, o que aumenta a sua manipulao. O LINQ consiste em uma linguagem
declarativa, perfeitamente integrada C#, que minimiza a distncia entre o objeto e os dados.
(Marques, Pedroso & Figueira, 2009).

20
2.1.9 Teste
Vrios modelos de teste de software foram criados para antever as falhas que podem ser encontradas
pelo cliente no momento do seu pleno funcionamento em um ambiente real de trabalho. Teste de carga
e estresse, teste de caixa preta e teste de caixa branca so alguns de inmeros modelos de testes
desenvolvidos para garantir a qualidade da aplicao desenvolvida. Com esses modelos de teste, o
objetivo da equipe de teste de software garantir que mesmo nas situaes mais extremas e
dificilmente alcanadas, aplicao continue executando com a mesmo desempenho de um ambiente
ideal.
Os testes realizados em cada fase do ciclo de desenvolvimento de software permitem que um nmero
maior de erros seja descoberto antecipadamente, evitando a migrao destes para as fases seguintes.
A cultura do teste cria um ambiente favorvel para deteo de erros, e identific-los rapidamente o
objetivo dos profissionais de testes.

Testes
Implantao
Anlise de Anlise de Arquitetura de
Desenvolvimento Testes e
negcio sistemas sistemas
treinamentos

Figura 9 Rotinas de teste

Os erros ocorrem em todas as fases do processo de desenvolvimento de software. Porm, estudos

demonstram que a maior incidncia dos erros est concentrada nas fases iniciais do processo de
desenvolvimento. Muitos dos erros identificados no produto final so provenientes da m especificao
e entendimento sobre os objetivos a serem alcanados.
Se nosso objetivo reduzir, ao mximo, o nvel de erros dentro do processo de desenvolvimento de
software, devemos nos concentrar nas atividades iniciais do processo. Desta forma, estaramos
identificando prematuramente os erros impedindo que estes migrassem para outras fases.
No possvel conceber um processo de teste de software sem integr-lo com o ciclo de
desenvolvimento de software. Um bom processo de teste aquele que cria uma relao de "um-para-
um" entre as fases de desenvolvimento e testes. Esta relao bilateral promove a colaborao entre as
reas e refora a ideia do objetivo comum.

21
2.1.10 Implantao
O momento da implantao de um sistema, por incrvel que parea, vai muito alm da instalao do
sistema na mquina a ser executada. nesse momento onde os maiores cuidados com as
informaes contidas nas bases de dados devem ser tratados com maior cautela para no serem
danificadas ou at mesmo perdidas.
Alm de garantir o pleno funcionamento da aplicao no ambiente solicitado nessa fase que a
integrao com todos os sistemas necessrios deve funcionar plenamente, principalmente as
funcionalidades de segurana e acesso a dados. Isso inclui planos de implantao e at mesmo planos
de contingncia, ou seja, procedimentos a se realizar caso a aplicao implantada no funcione
corretamente ou apresente mais de 50% de erros, o que a torna ineficaz para a utilizao do cliente.
Em alguns casos de contingncia, at o retorno da verso anterior do software necessria.
Contudo tambm na fase de implantao que se contempla o treinamento dos colaboradores para a
nova aplicao. De acordo com os processos do ambiente que ser implantada a aplicao, o
treinamento para as novas funcionalidades desenvolvidas, controle das atividades e novo ambiente de
interao com o utilizador deve ser apresentado e esclarecido como tambm a opo de ajuda de fcil
entendimento.

2.2 A Gesto de Projetos

As pessoas s vezes confundem projetos com operaes, claro que ambas as entidades citadas
convergem para o alcance de um nico objetivo, porm a principal diferena entre elas que os
processos so contnuos e repetitivos, j os projetos so empreendimentos temporrios com o objetivo
de criar um produto ou servio nico com incio e fim definidos (PMI, 2008).
De acordo com Heldman (2005), gerenciamento de projetos uma metodologia que objetiva de
atender os requisitos do projeto para a satisfao do cliente por meio de planeamento, execuo,
monitorao e controle dos processos utilizando de maneira mais eficiente os recursos disponveis.
Contudo, consiste em um conjunto de regras que direcionam o acompanhamento dos processos a
serem realizados durante o seu ciclo de vida, que consiste na aplicao de conhecimentos,
habilidades, ferramentas e tcnicas adequadas s atividades do projeto, a fim de atender aos seus
requisitos. Sendo essas regras padres publicadas no Guia PMBOK do Conjunto de Conhecimentos
em Gerenciamento de Projetos (PMI, 2008).
O PMBOK (PMI, 2008) formaliza diversos conceitos em gerenciamento de projetos, como a prpria
definio de projeto e do seu ciclo de vida. Tambm identifica na comunidade de gerenciamento de
projetos um conjunto de conhecimentos amplamente reconhecido como boa prtica, aplicveis

22
maioria dos projetos na maior parte do tempo. Estes conhecimentos esto categorizados em nove
reas e os processos relacionados so organizados em cinco grupos ao longo do ciclo de vida do
projeto.
Dentre as reas de conhecimento que caracterizam os principais aspetos envolvidos em um projeto e
no seu gerenciamento Escopo, Tempo, Custos e Qualidade so os principais determinantes para o
objetivo de um projeto: entregar um resultado de acordo com o escopo, no prazo e no custo definidos,
com qualidade adequada; em outras palavras, o que, quando, quanto e como. Recursos Humanos e
Aquisies so os insumos para produzir o trabalho do projeto. Comunicaes e Riscos devem ser
continuamente abordados para manter as expectativas e as incertezas sob controlo, assim como o
projeto no rumo certo. A Integrao abrange a orquestrao de todos estes aspetos.
A aplicao dos conhecimentos requer a adoo eficaz de processos apropriados. Cada rea de
conhecimento abrange diversos processos na gesto de projetos.
De acordo com Miguel (2010) um processo um conjunto de aes e atividades inter-relacionadas
que so executadas para alcanar um objetivo. Cada processo caracterizado por suas entradas, as
ferramentas e as tcnicas que podem ser aplicadas, e as sadas resultantes.
Os cinco grupos de processos de gerenciamento de projetos, Iniciao, Planeamento, Execuo,
Monitoramento e Controle e por fim Encerramento tm grande correspondncia com o conceito do
Ciclo PDCA (Plan - Do - Check - Act): Planejar - Fazer - Verificar - Agir (corrigir e melhorar). O grupo de
Planeamento corresponde ao Planejar; Execuo, ao Fazer; e Monitoramento e controle englobam
Verificar e Agir. E como a natureza dos projetos finita, o PMBOK ainda caracteriza os grupos de
processos que iniciam (Iniciao) e finalizam (Encerramento) um projeto.

2.2.1 A Gesto de Projetos de Produo de Sistemas de Software

A atividade mais importante para o sucesso da execuo de qualquer projeto o seu gerenciamento,
no entanto, uma gesto mal sucedida na maioria das vezes responsvel pela inviabilidade de um
projeto de software a ser desenvolvido. Frame (1994) afirma que projetos falham por duas causas:
Falha de estimao e falha na implementao. Essas falhas se desdobram em um conjunto bem maior:
Estimativas de prazo e custo no so revisadas aps a insero de novas informaes no
mbito do projeto.
Os gestores de projetos no possuem a formao necessria para direcionar e acompanhar
execuo do projeto.
A metodologia de gesto de projetos no posta em prtica de forma correta.
Mudanas constantes no mbito do projeto.
Metodologia de engenharia de software inadequada para a equipe de desenvolvimento.

23
 Os requisitos no so bem definidos ou sofrem constantes alteraes.
Os testes realizados no atingem um nvel de qualidade satisfatrio.

Tais falhas bem como seu conjunto de erros agregados contribuem de fato para o insucesso do
desenvolvimento do projeto de software. Encontrar e aprimorar solues para reparar as falhas em
cada uma das fases do processo de desenvolvimento (planeamento, levantamento e especificao dos
requisitos, implementao, teste e implantao) diminuiria o nmero de falhas no decorrer do processo
de desenvolvimento, porm no se teria o acompanhamento e controle do processo como um todo e
correria o risco de cada fase do processo ter caractersticas de metodologias de desenvolvimento
distintas.
Miguel (2010) afirma que para ser eficaz, a gesto do projeto tem de se conectar em quatro fatores
cruciais: pessoas, produto, processo e projeto. Esses fatores correspondem ao que de fato, se bem
gerido, necessrio para o sucesso no planeamento, desenvolvimento e implantao de um projeto.
Cada fator tem sua importncia que interfere diretamente no mbito do projeto, planeamento, controle,
definio dos requisitos, custos, prazos, desenvolvimento e qualidade do produto.

2.2.2 Fatores do projeto

Para a eficcia do projeto de software, cabe ao gestor de projeto gerenciar quatro fatores cruciais de
forma que todo o esforo a ser aplicado encaminhe o projeto para a sua construo com sucesso.
Pessoas ou recursos humanos para o projeto, trs itens devem ser analisados com muita
ateno pelo gestor de projetos: utilizadores insatisfeitos, conflitos frequentes entre
colaboradores da equipe de desenvolvimento e equipes desmotivadas com baixo nvel de
produo. H muito tempo se fala em motivar as pessoas que trabalham com sistemas
informticos. O fator pessoa para o desenvolvimento de uma aplicao to importante que
existe metodologias voltadas para a melhoria da eficincia organizacional de empresas de
software, auxiliando as encontrar, desenvolver, estimular e reter bons colaboradores para
tornar eficiente as suas capacidades de desenvolvimento de sistemas (Curtis, Hefley & Miller,
2001). Cabe ento ao gestor de projetos, alm de ter competncias de acompanhamento,
controle e gesto do projeto, a competncia de gesto em recursos humanos para a que esses
fatores no interfiram no ndice de produtividade e maturidade da equipe e principalmente
acompanhar se a expectativa do cliente ser atendida.
O Produto ou objeto de desejo do cliente antes de ser planejado deve-se estabelecer os
objetivos e as necessidades que se deseja atingir (definir seu mbito). Este fator importante
por proporcionar a visibilidade necessria do projeto, consequentemente estimar custos

24
 necessrios, avaliar os riscos, verificar de fato as atividades necessrias para realizao e por
fim se ter o cronograma estimativo com a data a ser entregue o produto. Esta fase se inicia
com o engenheiro de sistemas definindo com o cliente/utilizador quais as necessidades reais
que o projeto deve atender. Com estas informaes, para alm de se especificar o objetivo
principal do projeto, tambm se definem os limites do mesmo, de acordo com os requisitos
apontados pelo utilizador.
O Processo de desenvolvimento de software assim como em qualquer processo produtivo
(seja automobilstico, txtil ou manufaturas em geral) independente da metodologia a ser
utilizada, consiste de atividades que so comuns e devem ser realizadas no decorrer do
processo de desenvolvimento do sistema. Conhecer o processo de produo definindo a
estrutura do mesmo independente da complexidade, dimenso do software e a metodologia
utilizada, acrescenta maior fiabilidade no sistema informtico, pois so nos processos que so
definidos nveis de qualidade que se desejam atingir durante sua execuo.
O Projeto o artefacto que engloba todos os fatores descritos anteriormente o projeto rene
todas as metodologias a serem executadas no decorrer do desenvolvimento do sistema, porm
essas prticas utilizadas no garantem a eficincia do processo de gesto do projeto. The
Standish Group (2008) afirma que 20% dos projetos de software fracassam completamente e
que 44% enfrentam grandes problemas de custo e prazo no seu processo de desenvolvimento.
Mesmo que essas taxas tenham melhorado atravs da aplicao de novas metodologias, a
escassez de sistemas de especificao de projetos de software ainda muito grande
comparado a projetos de engenharia de outros segmentos de produo. Keil (1995).
Para que as falhas sejam evitadas, cabe ao gestor de projeto desenvolver juntamente com a equipe
prticas preventivas de riscos nos projetos e tomar conhecimento de fatores que podem vir a influenciar
no processo de desenvolvimento de sistemas, como segue abaixo:
Estabelecer um canal de fcil comunicao entre a equipe;
Evitar acmulo de sinais de riscos;
Compreender fatores crticos que contribuem para a uma boa gesto de projetos.
Desenvolver metodologias coerentes para o planeamento, controle e implantao do projeto.
No decorrer deste trabalho, analisaremos os resultados da implantao de um sistema que realiza o
planeamento do desenvolvimento de um projeto de software bem como o acompanhamento das
atividades desenvolvidas (planeamento e engenharia de software, o levantamento e a especificao
dos requisitos, o desenvolvimento de uma aplicao, o teste de qualidade de software e a implantao

25
e manuteno do sistema) no decorrer de sua construo, realizada no ambiente de uma empresa de
desenvolvimento de sistemas.

2.2.3 Definio do mbito do projeto

A definio do mbito do projeto ou especificao das necessidades do cliente realizada com o
objetivo de recolher informaes necessrias para o desenvolvimento do produto de software. nesse
momento que o gestor de projeto de software juntamente com o analista de negcio devero empregar
as tcnicas mais adequadas para garantir que os requisitos recolhidos correspondem as necessidades
e expectativas dos stakeholders (clientes), e so precisos e completos.
Diversas tcnicas so aplicadas para este processo:
Entrevistas;
Reunies de brainstorming;
Questionrios e inquritos;
Elaborao de prottipos;
Entre outros.
A documentao final aps estes processos devem descrever como os requisitos especificados
satisfazem o processo de negcio que o cliente solicitou. Geralmente se inicia com o nvel baixo de
detalhe e torna-se cada vez mais detalhado a medida que se conhece mais o projeto. Os requisitos
devem cumprir um conjunto importante de critrios, antes de serem submetidos a desenvolvimento.
Mensurveis;
Auditveis;
Completos;
Consistentes;
Aceitveis;
O documento que define o mbito do projeto de software a ser desenvolvido por este projeto
apresentado no item Anlise de Negcio e Modelao de Processos que define as atribuies que
contemplam esta fase do processo de desenvolvimento de software.
A descrio do mbito do projeto um documento dinmico, que comea a ser elaborado na fase
inicial do projeto e vai sendo modificado medida que os detalhes do projeto so conhecidos. Apenas
no final da fase de planeamento, quando se conhecem todas as condies e limitaes do projeto
possvel ter um documento completo.
Os objetivos principais da descrio do mbito do projeto comunicar a todos os interessados:
Os objetivos do projeto;
O que ele deve produzir e entregar;

26
 Os utilizadores envolvidos;
Os prazos e os custos;
E por fim como o projeto ser gerenciado.
O nvel de detalhe do projeto a ser desenvolvido define o grau de prioridade para incio de construo,
fornecendo ao gestor do projeto bases para controlar o mbito geral do trabalho. Este procedimento
importante, pois determina a eficincia da equipe de desenvolvimento para o planeamento do projeto.

2.2.4 Estimao de prazos, recursos e custos

A estimao eficaz do esforo (recursos e prazos) e custo do software constitui uma das atividades
simultaneamente mais difceis e mais importantes do desenvolvimento de sistemas de software.
(Miguel, 2010).
O desafio maior em estimar os indicadores de produo de software so compreender o domnio do
software (suas regras de negcio) e a capacidade da equipe em fornecer solues de software para as
necessidades especificadas pelo cliente em um determinado ambiente. S ento possvel prever a
quantidade de esforo necessrio para o desenvolvimento do produto.
Porm, em qualquer rea de desenvolvimento (seja civil, industrial, eltrico, sistemas, entre outras) o
processo de estimao se baseia num conjunto de tcnicas e procedimentos que a organizao se
baseia para enfim chegar ao valor estimado. A estimativa no e nunca ser uma cincia exata, em
virtude de existirem demasiadas variveis a interferir diretamente no esforo necessrio para o
desenvolvimento do projeto de software e consequentemente os seus respetivos custos tcnicas de
desenvolvimento, polticas organizacionais, polticas e humanas.
De acordo com a definio de estimar a melhor viso do futuro, baseada no conhecimento e
informaes disponveis hoje no se espera que se acerte sempre, o que se espera acertar de uma
maneira geral.
Podemos listar diversas dificuldades encontradas para estimar os esforos e custos do projeto de
software, entre elas esto:
Para se realizar corretamente, a estimativa exige um volume significativo de esforo;
A estimao frequentemente feita de uma forma apressada, sem uma adequada avaliao
dos esforos exigidos;
Para se desenvolver estimativas necessrio possuir experincias anteriores, em especial
para grandes projetos;
O ser humano est sujeito a enviesamento, ou seja, quem estima tende a considerar a durao
estimada de uma certa poro do trabalho e depois extrapola simplesmente esta estimativa
para o restante do sistema, ignorando os aspetos lineares do desenvolvimento sistema.

27
No entanto, a estimativa do projeto de software pode ser transformada em uma numa srie de passos
sistemticos que forneam nveis aceitveis de riscos. Para isso algumas regras simples esto
dispostas:
Basear-se nas estimativas de projetos concludos anteriormente;
Usar tcnicas de decomposio relativamente simples;
Usar um ou mais modelos de estimao;
Uma prtica em crescente utilizao para estimativa do esforo e dimensionamento das
funcionalidades desejadas em um sistema a anlise de ponto de funo.

2.2.5 Anlise de ponto de funo

Ainda na fase de anlise de negcio, aps o entendimento de todas as necessidades do cliente,
necessrio se medir o tamanho da aplicao a ser construda. Para isso alguns mtodos so
disponibilizados ao analista. Uma desses mtodos a estimativa por experincia, onde uma equipe de
desenvolvimento que j construiu funcionalidades semelhantes s solicitadas atribui o tempo
necessrio para a construo da aplicao. No entanto, algumas funcionalidades podem ficar
superestimadas, comprometendo custo e prazo de entrega.
Outra opo a utilizao da anlise de ponto de funo (APF) que mede o tamanho das
funcionalidades solicitadas pelo ponto de vista dos utilizadores que esto propostas nos modelos de
layouts aprovados junto ao cliente. Suas dimenses so calculadas junto a uma tabela de
complexidade onde a mesma disponibiliza a estimativa do esforo necessrio para desenvolver a
funcionalidade desejada.
A APF foi concluso de estudos realizados na dcada de 70 por Allan Albrecht, da IBM, diante da
necessidade de se ter uma abordagem para quantificar o esforo de desenvolvimento de
funcionalidade de sistema computacional independente da linguagem que se est utilizando (IFPUG,
2004).
Ponto de funo a medida do tamanho da aplicao computacional, que por sua vez, medido de
um ponto de vista funcional do utilizador. independente de qualquer caracterstica de
dessenvolvimento (da linguagem computacional, da metodologia de desenvolvimento, da tecnologia ou
da capacidade do grupo de desenvolvimento de desenvolver a aplicao). O fato do ponto de funo
ser usado originalmente para predizer esforo, isso nada mais que uma consequncia do fato de que
tamanho geralmente um indicador associado ao esforo do desenvolvimento.
importante salientar o que os pontos de funo no so medidas perfeitas de esforo para
desenvolver uma aplicao ou seu valor de negcio, uma vez que por mais que o sistema tenha suas
funcionalidades definidas, a sua construo depende de desenvolvedor para desenvolvedor (IFPUG,

28
2004). Isso facilmente ilustrado com uma analogia s medidas em construes, onde em uma casa
de cem metros quadrados quase sempre mais barata do que uma casa de duzentos metros
quadrados. Porm, muitos requisitos como os materiais utilizados podem fazer a casa menor mais
cara. Outros fatores como nmero de casas de banho e localizao podem fazer a casa de menor
dimenso ter um custo mais elevado. Abaixo seguem algumas razes pelas quais a abordagem de
APF deve ser utilizada para a estimativa de desenvolvimento de sistemas de software:
Medir produtividade.
Estimativa de desenvolvimento e suporte.
Monitorizar alteraes de origem externa.
Normalizao das formas de medida.
Sua contagem se inicia primeiramente classificando os componentes presentes na proposta de
interface homologada. Aps a identificao dos componentes, o mesmo multiplicado pela sua faixa
de esforo a realizar e por fim, multiplicado pelo custo por ponto de funo para calculo de custo e/ou
pelo tempo por ponto de funo para calculo de prazo de entrega. Os pontos de funes classificam os
componentes nas seguintes funcionalidades:
Entrada Externa (EE) um processo em que os dados atravessam a camada de fronteira da
aplicao de fora para dentro. Tais dados podem vir de uma tela de entrada de dados, por via
eletrnica ou atravs de outro aplicativo podendo ser informaes de controle ou informaes
do negcio. No caso dos dados serem informaes do negcio, ser utilizado para armazenar
um ou mais arquivos (ALI). Se os dados forem informaes de controle, no ser necessrio
que armazenem arquivos.
Sadas Externas (SE) um processo em que os dados passam atravs da camada de
fronteira, de dentro para fora traduzidos em relatrios ou arquivos de sada, que so enviados
a outros aplicativos. Esses relatrios ou arquivos so originados a partir de um ou mais
arquivos lgicos internos e/ou arquivos de interface externa.
Por sua vez, dados derivados so informaes cujo processamento vai alm da recuperao e
edio direta de registros (consulta e/ou cadastro) de arquivos lgicos internos ou arquivos de
interface externa. o resultado de um eventual processamento ou execuo de funcionalidade
de negcio, que ocorrem quando um ou mais elementos so combinados com uma frmula, de
modo a gerar ou derivar um ou mais elementos de dados adicionais.
Consulta Externa (CE) um processo entrada e sada, que resulta na recuperao de dados
(consulta) de um ou mais arquivos lgicos internos e/ou arquivos de interface externa que por
sua vez enviada para fora da camada de fronteira da aplicao.

29
 Arquivo Lgico Interno (ALI) um conjunto de dados relacionados (entidades), identificvel
pelo utilizador, que reside inteiramente dentro da camada de banco de dados da aplicao
mantido atravs de Entradas Externas.
Arquivo de Interface Externa (AIE) um conjunto de dados relacionados (entidades),
identificvel pelo utilizador, que utilizado apenas para referncia, pois residem inteiramente
fora da aplicao e so mantidos por outras aplicaes. O AIE um Arquivo Lgico Interno
para outra aplicao.
A Figura 10 apresenta uma viso geral dos tipos de funo que so considerados na anlise de ponto
de funo.

Figura 10 Viso geral das funcionalidades de uma aplicao segundo a anlise APF (Dias, 2012).
Na Figura 11 podemos observar o fluxo dos passos necessrios para a realizao da contagem dos
pontos de funo da aplicao.

Figura 11 O Procedimento de Contagem de Pontos de Funo, adaptado (Dias, 2012).

30
O processo de contagem de pontos de funo de acordo com (Dias, 2012) se d atravs de dois
passos:
1. O primeiro consiste em identificar arquivos lgicos internos (ALIs) e arquivos de interface
externa (AIEs) que deve ser classificada em dois conceitos: registros lgicos e itens de dados.
Registros Lgicos so subconjuntos de dados dentro de um ALI/AIE, que foram
reconhecidos pelo utilizador.
Um Item de Dados, por sua vez, um campo reconhecido pelo utilizador como nico e no
repetido. Vale destacar que s devem ser contados os itens de dados utilizados pela
aplicao em contagem.
Uma vez identificando-se os registros lgicos e os itens de dados de um ALI/AIE, pode-se verificar sua
complexidade relacionando a quantidade de registros com a quandidade de dados manipulados,
utilizando como referncia a classificao apresentada na Tabela 3.

Tabela 3 - Identificao da Complexidade das Funes de Dados (Dias, 2012).

Nmero de registros Nmero de itens de dados

lgicos De 1 a 19 De 20 a 50 51 ou mais

Apenas 1 Simples Simples Mdia

De 2 a 5 Simples Mdia Complexa

6 ou mais Mdia Complexa Complexa

2. O segundo passo envolve a contagem de funes que atravessam as camadas do sistema

(entradas externas, sadas externas e consultas externas) e sua classificao se d de acordo
com a complexidade funcional (simples, mdia ou complexa) baseada no nmero de arquivos
referenciados e dos itens de dados manipulados pela funo, utilizando a Tabela 4 para
entradas externas e a Tabela 5 para sadas e consultas externas.
Nessas tabelas um arquivo referenciado pode ser um ALI/AIE lido ou um ALI mantido pela funo. J o
nmero de dados considerado apenas os dados efetivamente referenciados pelas funes nos
arquivos em queto.

31
Tabela 4 - Identificao da Complexidade de Entradas Externas (Dias, 2012).

Nmero de arquivos Nmero de itens de dados referenciados

referenciados De 1 a 4 De 5 a 15 16 ou mais

0 ou 1 Simples Simples Mdia

2 Simples Mdia Complexa

3 ou mais Mdia Complexa Complexa

Uma vez quantificadas s funes, possvel calcular os PFs de uma aplicao. Esse clculo feito a
partir dos totais de pontos de funo (NPFi) e do total de pontos de funo no ajustados.
Para cada um dos cinco tipos de funo (ALI, AIE, EE, SE e CE), so computados os totais de pontos
de funo (NPFi), segundo a seguinte expresso de contagem de acordo (Dias, 2012):

onde NCi,j = nmero funes do tipo i (i variando de 1 a 5, segundo os tipos de funo existentes: ALI,
AIE, EE, SE e CE) que foram classificados na complexidade j (j variando de 1 a 3, segundo os valores
de complexidade: simples, mdia e complexa).
Ci,j = valor da contribuio da complexidade j no clculo dos pontos da funo i, dado pela Tabela 5.

Tabela 5 - Identificao da Complexidade de Sadas e Consultas Externas (Dias, 2012).

Nmero de arquivos Nmero de itens de dados referenciados

referenciados De 1 a 5 De 6 a 19 20 ou mais

0 ou 1 Simples Simples Mdia

2 ou 3 Simples Mdia Complexa

4 ou mais Mdia Complexa Complexa

O total de pontos de funo no ajustados (PFNA) dado pelo somatrio dos pontos das tabelas de
funo de contagem de acordo (Dias, 2012):

32
sendo que i varia de 1 a 5, segundo os tipos de funo existentes (AIL, AIE, EE, SE e CE).
Por no influenciar em mais de 10% as mtricas de estimativas, a contagem de pontos de funo no
ajustados no uma abordagem muito utilizada atualmente.

Tabela 6 - Contribuio das Funes na Contagem de PFs No Ajustados (Dias, 2012).

Complexidade
Funo
Simples Mdia Complexa

ALI 7 10 15

AIE 5 7 10

EE 3 4 6

SE 4 5 7

CE 3 4 6

2.2.6 Planeamento do projeto (cronograma)

Aps definir o mbito do projeto, funcionalidades, estimar prazos, recursos e tempo, chega a hora de
planejar as atividades necessrias para o desenvolvimento do sistema. Seu objetivo determinar a
ordem em que as atividades inerentes ao sistema sejam executadas. H duas formas de apresentar o
cronograma de execuo do projeto:
Grfico de Gantt
Diagrama de rede
O grfico de Gantt eficaz para projetos simples e de curta durao. atribuda, pelo gestor, uma
barra retangular para cada atividade que em seguida so dispostas horizontalmente ao longo de uma
linha do tempo na ordem em que as mesmas devem ser executadas, podendo algumas atividades ser
colocadas na linha do tempo de forma concorrente com outras. A sequncia muitas vezes ditada pela
disponibilidade dos recursos que por qualquer outra considerao. (Miguel, 2010).

33
Figura 12 Grfico de Gantt das atividades de um projeto (Miguel, 2010).

No entanto, o grfico de Gantt apresenta duas limitaes:

Primeiro que pela sua simplicidade no apresenta informaes detalhadas da atividade,
apenas reflete a ordem das atividades a serem desenvolvidas.
Segundo, o grfico de Gantt no informa se o cronograma de que resulta o grfico conclui o
projeto no prazo mais curto possvel, nem se os recursos so utilizados de forma mais eficaz.
Embora o grfico de Gantt seja de simples de criar e no exija o uso de ferramentas informatizadas,
recomenda-se o uso de diagramas de redes, pois:
Possibilita uma imagem da sequncia em que flui o trabalho do projeto.
Inclui informaes detalhadas.
Serve como ferramenta de analtica para calendarizao do projeto e para problemas de
gesto de recursos, medida que surgem durante a vida do projeto.
Possibilita o clculo do prazo mais curto para a finalizao do projeto.
As atividades com suas respetivas duraes so de fato informaes de suma importncia para o
gestor de projetos de software principalmente para a construo da sua imagem grfica, que
proporciona a viso de duas informaes adicionais a cerca do projeto:
O primeiro momento em que pode ser iniciado o trabalho em cada atividade.
A primeira data de concluso que expectvel para o projeto.
Um diagrama de rede do projeto uma representao figurativa da sequncia em que podem ser
executadas as vrias atividades que compe o projeto. H um conjunto reduzido de regras simples que
necessrio seguir para construir esse diagrama, dentre elas a precedncia das atividades, o tempo

34
de cada uma e uma anlise de caminho crtico para acompanhar o tempo mais curto e mais longo de
realizao das atividades.

Figura 13 Diagrama de rede de projeto. (Miguel, 2010)

Para este projeto, utilizaremos o grfico de Gantt, porm iremos disponibilizar no mesmo as
informaes necessrias de acompanhamento das atividades por parte do gestor. Prazos e recursos
so definidos pela quantidade de ponto de funo definida pela mtrica do tamanho do software.

2.2.7 Acompanhamento, controle e encerramento do projeto

At este ponto, a descrio do esforo despendido na gesto do projeto de software est relacionado
com a anlise de listagem dos requisitos (na gesto do mbito do projeto), estimao dos recursos,
prazos, custos do projeto e o planeamento das atividades a serem realizadas no prazo estabelecido
para o desenvolvimento do sistema.
Cabe agora ao gestor do projeto garantir que todas as atividades planeadas sejam desenvolvidas sem
impedimentos atravs de acompanhamento contnuo, controlando os possveis impedimentos e
desenvolvimento das atividades at a finalizao do projeto (desde a aceitao do cliente at a
implantao do sistema). Com o apoio do grfico de Gantt, este trabalho apresenta em seu
desenvolvimento prtico uma ferramenta que dispe de um sistema de software direcionado gesto
de projetos de software que lista todas as atividades referentes ao projeto e principalmente o estado de
cada uma dela, consequentemente a comparao entre o nvel de desenvolvimento previsto e o nvel
de desenvolvimento real.
Essa ferramenta de controle de atividades de projeto garante ao gestor visibilidade das atividades
inerentes ao projeto, o acompanhamento das atividades realizadas, em execuo e a serem
executadas, possibilitando verificao de fases de processo que precisam de adequaes objetivando
o desenvolvimento pleno da produo de software. Com a identificao das atividades que
comprometem o prazo de desenvolvimento sistema, torna mais visvel ao gestor de projeto realizar
aes que contornem as situaes que comprometem os indicadores j definidos para a construo do

35
sistema. nessa fase que se aplica a gesto de risco no desenvolvimento do projeto. Ao gestor cabe
buscar solues aos problemas encontrados para que nos prximos projetos a serem desenvolvidos,
mesmo encontrando as mesmas dificuldades, tal problema j apresente uma proposta de soluo.
A partir do acompanhamento e controle de sistema, o seu encerramento pode ser planejado,
desenvolvendo workshops de apresentaes do software construdo j identificando as limitaes
encontradas nas fases de desenvolvimento do sistema, o que posteriormente facilitaria o
desenvolvimento de novas atualizaes e principalmente nas novas necessidades de negcio do
cliente para o sistema de software.

2.2.8 Gesto de equipas

A equipa de desenvolvimento de projetos de software compreende todos os recursos disponveis para
o gestor. Claro, o ambiente de desenvolvimento da empresa importante, a arquitetura de
desenvolvimento, a linguagem a ser utilizada, os modelos de documentao e registro dos requisitos
do cliente, as tcnicas de teste de software, so componentes importantssimos para o
desenvolvimento de sistemas de software, mas que s sero eficientes se realizados por equipas
eficientes.
No entanto, gerir equipas a parte da gesto de projetos de sistemas que necessita de maior ateno
do gestor, pois duas situaes podem frequentemente acontecer em ambientes de desenvolvimento de
sistemas:
Conflitos frequentes entre colaboradores da equipe de desenvolvimento;
Equipes desmotivadas com baixo nvel de produo;
comum em empresas de desenvolvimento de software haver competies entre equipas para
entrega de seus produtos antes da outra, o que por um lado saudvel, pois aumenta o nvel de
produo, mas por outro faz com que os conflitos, originados geralmente por falhas executadas por um
colaborador em uma das fases de processo de desenvolvimento, afetem o ambiente de
desenvolvimento ou at mesmo o ambiente de toda a organizao. Solucionar essa situao logo no
incio uma funo muito importante do gestor e de preferncia com uma soluo que objetive o bem-
estar tanto do projeto quando da equipe.
Porm, mais difcil quando se tem equipes desmotivadas. sinal que o nvel de produo do
desenvolvimento de sistemas j diminuiu significativamente. Solucionar esse empasse j no
simplesmente um desentendimento. Dependendo do mbito da desmotivao (um membro da equipe
ou toda a equipe) as solues podem ir de uma simples meta at as mudanas nas fases dos
processos de desenvolvimento.

36
Estabelecer solues prontas (dependendo de cada organizao) j esperando essas situaes a
melhor alternativa que o gestor de projetos pode encontrar para resolver tais problemas. No entanto,
muita ateno nos recursos e acompanhar continuamente o processo de desenvolvimento consistem
na melhor alternativa para contornar os possveis conflitos.

37
3 METODOLOGIA

3.1 Contexto do Projeto de Investigao

Manaus um municpio brasileiro, capital do estado do Amazonas e o principal centro financeiro,
corporativo e econmico da Regio norte do Brasil. uma cidade histrica e porturia, localizada no
centro da maior floresta tropical do mundo. Situa-se na confluncia dos rios Negro e Solimes. a
cidade mais populosa da Amaznia, de acordo com o IBGE, sendo uma das cidades brasileiras mais
conhecidas mundialmente, principalmente pelo seu potencial turstico e pelo ecoturismo, sendo o
dcimo maior destino de turistas no Brasil. Est localizada no extremo norte do pas, a 3.490
quilmetros da capital federal, Braslia.
Com a implantao da Zona Franca de Manaus na dcada de 1960, a cidade ocupou lugar de
destaque entre as mais ricas do Brasil e da Amrica Latina. Ao lado de Cuiab, capital de Mato Grosso,
a capital que mais cresceu economicamente nos ltimos quarenta anos, fato explicado principalmente
pela implantao e desenvolvimento da Zona Franca de Manaus, que tambm atraiu milhares de
migrantes que ocuparam de forma desordenada a periferia da cidade.
A Zona Franca de Manaus (ZFM), tambm conhecida como Polo Industrial de Manaus, um centro
financeiro (o principal da regio norte do Brasil) implantado pelo governo brasileiro objetivando
viabilizar uma base econmica na Amaznia Ocidental, promover a melhor integrao produtiva e
social dessa regio ao pas, garantindo a soberania nacional sobre suas fronteiras. um dos mais
modernos da Amrica Latina. A mais bem-sucedida estratgia de desenvolvimento regional, o modelo
leva regio de sua abrangncia (estados da Amaznia Ocidental: Acre, Amazonas, Rondnia e
Roraima e as cidades de Macap e Santana, no Amap) desenvolvimento econmico aliado proteo
ambiental, proporcionando melhor qualidade de vida s suas populaes.
Com esse cenrio, muitas empresas que se instalaram no polo industrial de Manaus necessitaram de
sistemas que potencializassem e apoiassem seus negcios de maneira mais eficiente o que necessitou
e abriu mercado para empresas de desenvolvimento de sistemas, que por sua vez diante da grande
demanda no conseguem atender s necessidades de mercado. Muitas dessas dificuldades
relacionadas falta de suporte aos seus processos de produo.
Este projeto de investigao compreendeu uma empresa de desenvolvimento de sistemas localizada
na cidade de Manaus composta por: um gerente de desenvolvimento de sistemas, dois arquitetos de
software, um analista de sistemas, um designer grfico, um desenvolvedor e um analista de teste
totalizando uma equipe com sete membros e um projeto de sistema de software em produo.

38
3.2 Caracterizao da pesquisa
Uma pesquisa se desenvolve diante a associao de conhecimentos disponveis (sejam bibliogrficos
entre outros) em conjunto com metodologias, mtodos, tcnicas e entre outros recursos cientficos. No
entanto a pesquisa s se torna satisfatria quando a mesma atende a cada uma das fases de seu
planeamento, desde a identificao e formulao do seu problema at a apresentao dos resultados
obtidos.
Por sua vez, as pesquisas so classificadas e distribudas em trs grandes grupos: descritivas,
explicativas e exploratrias. Nesse caso, apresenta-se um estudo exploratrio que, conforme Seltiz et
al. (1967, p. 63):
Tm o objetivo de proporcionar maior familiaridade com o problema, tendo em vista torna-lo
mais explcito ou a construir hipteses. Pode-se dizer que estas pesquisas tm como objetivo
principal o aprimoramento de ideias ou a descoberta de intuies. Na maioria dos casos,
essas pesquisas envolvem: levantamento bibliogrfico e/ou documental; entrevistas com
pessoas que tiveram experincias prticas com o problema pesquisado; e anlise de
exemplos que estimulem a compreenso.

Em linhas gerais, as pesquisas com esse carter visam desvendar o que est acontecendo, de forma a
questionar o que j est escrito, buscando um aperfeioamento de ideias atravs de uma nova tica e
propondo uma nova ferramenta que auxilie no apoio a tomada de deciso do problema apresentado.
As diversas abordagens representam vises tericas da realidade e defendem posturas um tanto
diferenciadas.
Portanto, quanto a sua natureza essa pesquisa qualitativa, pois na organizao dos dados coletados
sobre a gesto de projetos de software, trabalhar-se- com dados qualitativos e quantitativos uma vez
que, com ambas as informaes se procura compreender e analisar o foco da pesquisa a partir da
realidade de projetos de software desenvolvido utilizando o modelo de software para o
acompanhamento das atividades pois esses tipos de pesquisa no so opostos, mas sim
complementares pois a realidade abrangida por eles interage dinamicamente, excluindo qualquer
dicotomia (Minayo, 1994, p.22).
Enquanto instrumentos metodolgicos, a pesquisa tomar como ponto de partida a pesquisa
bibliogrfica, depois a anlise dos artefactos documentais referentes arquitetura do projeto de
software e por fim a anlise dos dados resultantes referentes ao desenvolvimento de software por uma
determinada empresa.
A pesquisa bibliogrfica estar voltada para a compreenso do contexto das necessidades da gesto
de projetos de software em suas respetivas fases de construo destacando as influncias no campo

39
desenvolvimento. Visa tambm relacionar tendncias de gesto de projetos de software propostos
pelos mercados de desenvolvimento de software e os mais usuais modelos de desenvolvimento de
sistemas.
O desenvolvimento dos artefactos documentais referentes arquitetura do projeto de software ser
realizado junto a referncias bibliogrfica tcnicas direcionadas a rea de gesto de projetos de
software a fim de levantar informaes sobre os processos gesto mais utilizados e eficientes neste
cenrio. A anlise desses artefactos de extrema relevncia nesta pesquisa, pois possibilitam a
consulta a informaes tcnicas, normas, regulamentos, artigos cientficos tecnolgicos e outros.
Documentos so fontes de informaes que ainda no receberam organizao, tratamento analtico e
publicao. A pesquisa documental a que se serve dessas fontes. (Santos, 1999, p. 29.).
A anlise dos dados referentes ao desenvolvimento de software permite observar o levantamento das
informaes sobre as necessidades de melhorias nas fases de gesto de projeto de software, levantar
requisitos estabelecendo documentos que serviro como base para a construo do sistema, o tempo
previsto de desenvolvimento de acordo com os recursos atuais disponveis, bem como os testes
especficos alinhados s necessidades do cliente e por fim o tempo real de desenvolvimento com seus
devidos custos.
O artefacto documental inicial do projeto de software definido como documento de viso ser
estabelecido pelos membros da equipe de desenvolvimento observada 1 gestor de desenvolvimento
de sistemas, 1 analista de sistemas, 1 designer grfico, 2 arquitetos de software, 2 desenvolvedores de
sistemas e 1 analista de teste. O uso deste instrumento tem como objetivo levantar os requisitos
necessrios que possibilite compreender aspetos das diferentes fases do processo de construo do
sistema de software que caracterizem o perfil do modelo de gesto de projeto de software da
organizao como um todo desde o levantamento dos requisitos com os clientes, a modelagem e
documentao do sistema, sua arquitetura funcional, seu desenvolvimento, seus teste com nveis de
qualidade e treinamentos e implantaes.
O Documento de Viso possibilita uma viso geral do objeto pesquisado e permite um maior
entendimento dos dados levantados. O referido instrumento, segundo Richardson, (1999, p.191) tem as
seguintes caractersticas:
(...) um dos artefactos da Anlise Estruturada para projetos de sistemas informticos. Ele facilita uma
anlise preambular deste, sendo de grande relevncia durante as primeiras fases, permitindo a captura
de todas as perspetivas que o sistema pode abranger. Pretende-se que sirva como ferramenta de
auxlio, a evitar alguns dos problemas mais custosos com que as pessoas envolvidas no projeto
podero ter que se confrontar. Esta ajuda proporcionada atravs da divulgao do contedo deste a
todos aqueles que estejam integrados no sistema.

40
No final dos processos de desenvolvimento do sistema a anlise dos dados ser direcionada ao
modelo de gesto de projeto de software de uma determinada empresa da cidade de Manaus AM
mostrando sua realidade, analisando seu andamento e mostrando o impacto de possiveis mudanas
que possam ocorrer durante a sua execuo. A nfase do trabalho final ser desenvolver um mdulo
de software que auxilie o processo de produo de sistemas informticos mostrando o andamento de
suas atividades, custos e prazos apoiando a tomada de deciso para eventuais mudanas no projeto
por parte do gestor.

41
4 ANLISE, IMPLEMENTAO E RESULTADOS DO PROJETO DE
INVESTIGAO

4.1 Anlise do problema

Um dos principais problemas da gesto de projetos, alm da definio do escopo do projeto, est na
gesto das atividades inerentes ao projeto e principalmente o acompanhamento da execuo das
mesmas. Tal informao de grande importncia para: medir o nvel de execuo total do projeto,
acompanhar os custos aplicados at o momento, comparar o andamento do projeto com os prazos
acordados no incio do mesmo, acompanhar os nveis de produtividade entre outros ndices que a partir
do acompanhamento das atividades podem ser medidos.
No desenvolvimento de projetos de software, a gesto das atividades realizadas importante para os
gestores de projeto, pois so atravs destes acompanhamentos, desde a fase de concepo at a fase
de testes, que o gestor pode apresentar resultados fsicos sobre o andamento do projeto junto aos
seus clientes, utilizadores e interessados.
Inmeras metodologias de gesto surgiram com a ideia de propor um acompanhamento mais simples e
intuitivo das atividades referentes ao projeto, mesmo que os processos da empresa possussem
processos bem definidos, esses processos eram quebrados em atividades para o acompanhamento.
Contudo, por mais que as metodologias tivessem um propsito bem definido o acompanhamento do
projeto poderia no funcionar da forma esperada por dificuldade das empresas na adaptao a uma
nova cultura que a metodologia exigia.
A Figura 14 apresenta o planeamento das atividades realizadas inicialmente pela equipa de
desenvolvimento da empresa que foi objeto deste estudo utilizando os passos da metodologia Scrum
para estimar esforo para a realizao das atividades e o desenvolvimento de um mdulo de sistema.
Inicialmente as atividades so especificadas e realiza-se a atribuio do seu respetivo tempo de
desenvolvimento atravs das experincias de implementao de cada colaborador responsvel.

42
Figura 14 Quadro de planeamento inicial do projeto
Aps a definio das atividades, as mesmas so distribudas no quadro de acompanhamento de
atividades, divididas em estrias do usurio, tarefas a fazer, tarefas em andamento e tarefas
finalizadas. As estrias definem o que o usurio de fato deseja em ordem de prioridade, j as tarefas se
referem s estrias que refletem o andamento da mesma. Essas por sua vez so divididas em sprints
(prioridades de desenvolvimento dentro de um ciclo) que deve ser entregue no final de um determinado
perodo de tempo.

Figura 15 Quadro de organizao do ciclo do projeto

43
Porm ao longo do desenvolvimento do projeto fatores como a falta de cultura da empresa em atualizar
o quadro de atividades, mudana nos requisitos, alterao de prioridades das atividades a serem
desenvolvidas influenciam em muito o acompanhamento das atividades do projeto. A Figura 16
demonstra um exemplo do resultado de como excesso de mudanas em um projeto pode impactar no
acompanhamento das atividades realizadas.

Figura 16 Quadro de acompanhamento do ciclo do projeto

Devido a esses fatores, aumenta a dificuldade no acompanhamento das atividades a serem

desenvolvidas, dificulta a forma de medida, compromete o planeamento elaborado, perdendo assim
todas as referncias de feedback entre o gestor do projeto e os clientes.
Outro problema da gesto de projetos de software est em estimar os prazos e os custos para o
projeto. Algumas tcnicas auxiliam o gestor do projeto a fornecer valores aproximados de custo e prazo
da execuo de um projeto de software ao longo do tempo, mas contabiliz-lo no meio de sua
execuo uma atividade que requer bom domnio das prticas de gesto do projeto e principalmente
que as atividades especificadas para a execuo do projeto estejam sendo atualizadas pelos
colaboradores. No entanto isso fica mais complicado quando ocorrem mudanas dos requisitos no
meio do projeto em execuo, impactando diretamente nos prazos e custos planeados inicialmente.
Ao longo deste estudo inmeras mudanas foram solicitadas para o desenvolvimento deste projeto.
Tais mudanas tinham uma enorme influncia no planeamento desenvolvido para as atividades
definidas anteriormente, comprometendo diretamente os prazos e custos estimados at ento.

44
Diante da necessidade de se avaliar os impactos de mudanas solicitadas em meio ao
desenvolvimento do projeto e o acompanhamento de atividades realizadas, a construo de uma
ferramenta de software que mostre o andamento das atividades realizadas e aponte os impactos de
mudanas no mbito do projeto atual auxiliando na tomada de deciso para as novas aes de gesto
de projetos tornam-se necessrias. Os prximos itens desta seo apresentam a criao deste
sistema.

4.2 Implementao
Diante da necessidade de se obter informaes rpidas sobre custos, prazos e o controle das
atividades, tanto para mudanas de requisitos quanto para novos projetos, o desenvolvimento da
soluo de software necessitou de uma rpida construo e implantao para que pudesse sanar as
imediatas necessidades de controlo dos projetos a serem gerenciados.
Inicialmente foi adotada a metodologia interativa e incremental para a engenharia de software do
sistema, pois medida que os requisitos principais iam sendo finalizados, os mesmos iam sendo
disponibilizados aos utilizadores para a gesto de projetos. Com o auxlio da linguagem BPML, pode-se
traar o perfil do processo de negcio quanto ao desenvolvimento de sistema quanto s fases
subsequentes do processo. E por fim, para cada requisito solicitado, o mesmo era desenvolvido
obedecendo s fases de desenvolvimento de software como apresentado na figura.

Anlise de Arquitetura
negcio do sistema Testes

Anlise de Desenvolvimento Implantao e

sistema treinamentos

Figura 17 Fases do processo de desenvolvimento do sistema

Cada uma das fases apresentaram caractersticas importantes para o desenvolvimento do modelo de
software proposto. Abaixo segue cada uma das caractersticas importantes para as fases de
desenvolvimento apresentadas.

4.2.1 Anlise de negcio

A primeira fase do processo de desenvolvimento de sistemas estabelece os requisitos de negcio para
que seja alinhado com o sistema a ser desenvolvido. Foi nesta fase que todas as necessidades foram

45
tratadas junto ao cliente e analisadas as que de fato iriam agregar valor para a empresa. A Figura 18
representa o processo de Anlise de negcio em BPML, sendo possvel verificar que deste processo
resulta o documento de viso apresentados no anexo I.

Figura 18 Diagrama BPML do Processo Anlise de Negcio

Com base nessas informaes pde-se estabelecer um direcionamento para o projeto solicitado pelo
cliente, incluindo a princpio os custos e prazos estimados para se ter a visibilidade da viabilidade do
projeto. Essas informaes estabelecidas podem sofrer ajustes ao longo do projeto, no entanto no
aceitam mudanas que impactem no escopo da aplicao, ou seja, a listagem do requisitos definidos
nessa fase so levados at fim do projeto.

4.2.2 Anlise de sistema

Aps a definio do documento de viso na anlise de negcio, a anlise de sistemas define os
modelos de desenvolvimento do sistema quanto s especificaes dos requisitos funcionais, como nos
anexos III, IV V e VI, diagramas de classe, sequncia, atividades, caso de uso e estados. A Figura 19
apresenta do diagrama de caso para adio de usurio na aplicao no decorrer do funcionamento da
aplicao.

Figura 19 Diagrama de caso de uso de adio de usurio

46
A Figura 20 exibe as iteraes do caso de uso entre o utilizador e o sistema quanto adio de um
novo utilizador cadastrado a uma nova funcionalidade de sistema. Este diagrama representa de forma
simblica o fluxo principal descrito de forma textual no documento de especificao de requisitos (Ver
anexo III). O diagrama tambm informa as tomadas de decises e alguns tratamentos de excees.

Figura 20 Diagrama de atividade de adio de usurio

A Figura 21 apresenta as iteraes dos objetos instanciados na aplicao desenvolvida e as

informaes das entidades que persistem na base de dados. Esse diagrama reflete as entidades a

47
serem desenvolvidas no banco de dados, no entanto os mtodos que a mesma apresenta ficam
disponveis apenas na camada de aplicao e executadas medida que o utilizador manipula
informaes no sistema.

Figura 21 Diagrama de classe da funo de adio de usurio

A Figura 22 exibe a iterao dos mtodos inseridos nas camadas de aplicao do sistema medida
que os mesmos so executados (manipulada informaes pelo utilizador) no sistema. O diagrama
exibe as camadas de procedimentos medida que as iteraes entre as classes so chamadas na
aplicao.
Nesta fase tambm foram definidas as regras de negcio quando ao comportamento do sistema,
utilizadores, pr e ps-condies quanto utilizao do sistema homologado em um documento
elaborado junto ao cliente. Os diagramas de caso de uso e os documentos de especificao de caso
de uso encontram-se nos anexos III e IV deste documento respetivamente.

48
Figura 22 Diagrama de sequencia de adio de usurio

Por fim a Figura 23 representa o processo de Anlise de sistemas em BPML, sendo possvel verificar
que deste processo resulta o diagrama de caso de uso, modelo entidade relacional e documento de
especificao de requisitos.

49
Figura 23 Processo de Anlise de sistemas em BPML

4.2.3 Arquitetura do sistema

Na fase de arquitetura de sistemas contempla o desenvolvimento da estrutura do sistema quanto a
tecnologia a ser utilizada, a definio das bibliotecas de desenvolvimento e a construo do modelo de
dados da aplicao. A Figura 24 representa o processo de Arquitetura de sistemas em BPML, sendo
possvel verificar no final deste processo a estrutura do cdigo fonte da aplicao e o modelo de dados
implementado.

Figura 24 Processo de Arquitetura de sistemas em BPML

O sistema de gesto projetos de software teve sua estrutura de camadas de acesso a dados, criao
do bando de dados e definio das linguagens de programao nesta fase. A Figura 25 apresenta a
diviso do sistema desenvolvido em suas respetivas camadas para cada uma das funcionalidades

50
solicitadas e descritas nos requisitos e com a camada DAO (Data Access Object) sendo a referncia de
acesso e controle a dados. As mesmas utilizam as tecnologias disponveis no framework Net 4.0.

Interface

Negcio

DAO

BD

Figura 25 Arquitetura de camadas do sistema

Da parte externa para a interna, o sistema se inicia pela camada de interface que a iterao do
utilizador com o sistema. atravs dessa camada que as requisies de utilizador, aes e eventos
externos do sistema so solicitadas. Em seguida, a camada de negcio responsvel pelas validaes
necessrias do sistema junto aos eventos e solicitaes requeridos atravs da camada de interface.
esta camada especificamente que muda de uma aplicao de rotinas financeiras para uma aplicao
de rotinas contbeis por exemplo. diretamente na camada de negcio que os requisitos definidos
junto ao cliente devem ser implementados juntamente com as regras de negcio. A camada DAO
responsvel pelos mtodos de acesso, consultas e demais manipulaes de dados. Todas as rotinas
requeridas pela camada de interface que foram devidamente validas na camada de negcio ao
chegarem na camada DAO identificam os respetivos mtodos requeridos para retornar uma resposta
ao utilizador solicitante. Por fim na camada de BD (Data Base) responsvel pelo armazenamento das
informaes inseridas e/ou manipuladas pelos processos de negcio do sistema.
A Figura 26 apresenta a camada DAO, em modo de projeto, com seus respetivos mtodos de acesso a
dados retratados na classe pblica BLL (Business Logic Layer) que responsvel pelas operaes
bsicas em uma base de dados, consulta, insere, altera e exclui.

51
Figura 26 Mtodos da camada DAO do sistema desenvolvido
Cada um dos mtodos apresentados na camada DAO solicitado nas respetivas camadas de negcio
do sistema, medida que o mesmo solicitado pela aplicao.
A seguir verifica-se o modelo de banco de dados desenvolvido para esta aplicao, bem como seus
relacionamentos com as entidades construdas a partir das necessidades do sistema definidos no
documento de especificao de requisitos utilizando o sistema de gerenciamento de banco de dado
SQL Server 2008 R2. A Figura 27 apresenta uma vista parcial do modelo de entidade-relacionamento
implementado neste sistema.

Figura 27 Modelo de dados em diagrama entidade relacional do sistema

52
4.2.4 Desenvolvimento
Aps definida e construda a estrutura do sistema, o processo parte para a fase de desenvolvimento de
acordo com os itens especificados nas documentaes resultantes da fase de anlise de sistemas. A
Figura 28 representa o processo de Desenvolvimento em BPML.

Figura 28 Processo de Desenvolvimento em BPML

Aps toda a arquitetura do sistema definida e os requisitos do sistema totalmente documentados e
homologados junto ao cliente, o sistema teve a sua conceo dividida em duas partes. Na primeira o
desenvolvimento do designe da interface do utilizador com o sistema, tanto nas consultas de dados
quanto na manuteno dos mesmos como mostra a Figura 29.

Figura 29 Camada interface (Apresentao) do sistema Lista de projetos

53
Na Figura 30 possvel realizar o desenvolvimento de interfaces que viabilizam a manuteno dos
dados listados na figura anterior. Com o vasto poder de desenvolvimento promovido no ambiente de
interface, a navegabilidade do sistema bem definida.

Figura 30 Camada interface (Apresentao) do sistema Manuteno de projetos

Por fim, a camada de negcio do sistema que efetua as validaes necessrias e comunica a interface
ao acesso a dados como mostrado na Figura 31.

Figura 31 Camada de negcio da aplicao

54
Toda a conceo da aplicao desenvolvida foi realizada utilizando a linguagem C Sharp, que
juntamente com o framework Dot Net 4.0 facilitou as atividades de desenvolvimento e construo das
funcionalidades solicitadas.
Aps o desenvolvimento de cada um dos mdulos e suas respetivas funcionalidades (Interfaces e
Camadas de Negcio), o desenvolvedor realiza a integrao das funcionalidades desenvolvidas com a
arquitetura proposta, realizando assim, por parte da aplicao, os respetivos acessos a dados de
acordo com a funcionalidade desenvolvida.
medida que novos mdulos forem sendo desenvolvidos, novas integraes sero necessrias para
que as funcionalidades executem todas as rotinas requeridas.

4.2.5 Testes
Aps o desenvolvimento da aplicao, a mesma enviada a fase de teste para validao dos
requisitos estabeleciodos pelo cliente, podendo esta fase reportar erros a fase de desenvolvimento ou
encaminhar a aplicao desenvolvida para a fase de implantao. A Figura 32 apresenta o processo
de Teste em BPML.

Figura 32 Processo de Teste em BPML

A cada funcionalidade desenvolvida, a mesma era disponibilizada para a fase de teste, que tinha o
principal objetivo de garantir que as necessidades exigidas para o sistema fossem de fato
desenvolvidas de acordo com as especificaes dos requisitos do documento. Os testes simulavam o

55
ambiente de gerenciamento de projetos de software, bem como a gesto das atividades solicitadas, a
consulta de valores previstos para os custos e prazos tanto para novos projetos quanto para mudanas
solicitadas para os projetos em andamento. Alguns bugs (no conformidades) foram detetados e
resolvidos pelos programadores logo que identificados.

4.2.6 Implantao e treinamentos

Por fim a fase de implantao homologa junto ao cliente as entregas realizadas de acordo com o seus
relatrios de implantao e realizao de treinamentos. A Figura 33 apresenta o processo de
implantao e treinamento em BPML.

Figura 33 Processo de Implantao e Treinamento em BPML

No diagrama de implantao da Figura 34 exibe as iteraes entre as camadas de aplicaes

desenvolvidas, as aplicaes que executam no servidor e por fim as entidades dispostas no banco de
dados do sistema.

56
Figura 34 Diagrama de implantao do sistema

Aps a finalizao do sistema, o mesmo requereu apenas instrues bsicas aos colaboradores do
projeto para terem acesso s suas atividades, visualiz-las, inici-las e finaliz-las. Finalizada essas
atividades, a parte de acompanhamento de custos e prazos com previstos e realizados fica a critrio do
gestor de projetos da equipe, bem como analisar o andamento das atividades planeadas quanto
organizar projetos futuros. O acompanhamento das atividades realizadas realizado de forma grfica e
por relatrios gerados pelo sistema.
Logos aps o desenvolvimento do sistema, os projetos passaram a ter mais visibilidade quanto ao seu
acompanhamento de uma maneira muito mais rpida e confivel, permitindo ao gestor de projetos
juntamente com o cliente verificarem se poderia ser vivel a aplicao de uma mudana nos projetos
em andamento ou se compensava elaborar e planejar um novo projeto a se realizar sem comprometer
os recursos empregados nos projetos atuais.
O sistema tambm proporcionou mais dinamismo ao acompanhamento das atividades possibilitando,
atravs de uma plataforma web, a realizao das atividades de forma descentralizada da empresa,
onde alguns colaboradores selecionados tinham suas atividades a realizar, porm os mesmo a
iniciavam e/ou a finalizavam de qualquer ponto de acesso a internet, fazendo com que o
acompanhamento projeto tenha mais fiabilidade nas informaes.

57
4.3 Resultados
Contudo, aps o perodo de pesquisa, anlise do problema, implementao e implantao do sistema
de gesto de projeto de software, resultados relevantes foram identificados no acompanhamento de
atividades referente ao projeto e apoio a tomada de deciso por parte do gestor, como listados a
seguir:
A organizao em listagem dos projetos em desenvolvimento paralelo pela equipe a medida
que as atividades so necessrias para o desenvolvimento do mesmo. A Figura 35 exibe a
interface de lista de projetos cadastrados para serem executados ou que esto em execuo.

Figura 35 Lista principal de acompanhamento de projetos

O cadastro de projetos mediante as necessidades dos clientes, a alocao dos recursos

pessoais disponveis e a visualizao dos prazos dos custos necessrios para a realizao do
projeto antes de inici-lo. A seguir, a Figura 36 exibe os detalhes do projeto cadastrado no
sistema que permite o cadastro de um novo projeto, a descrio dos clientes do projeto, os
colaboradores disponveis juntamente com suas respetivas atividades e principalmente o
clculo de custos previsto para o desenvolvimento do projeto.

58
Figura 36 Interface de cadastro de projetos
O cadastro dos recursos pessoais de acordo com a formao, tempo de experincia e o
aperfeioamento contnuo do colaborador, definindo assim um nvel de experincia que
impacta no tempo de desenvolvimento das atividades atribudas para um determinado projeto
posteriormente alocao do mesmo no projeto. A Figura 37 demonstra a interface do
cadastro de colaborador bem como sua formao, experincia e certificaes.

Figura 37 Interface de cadastro de colaboradores

59
 O acompanhamento das atividades em desenvolvimento referentes ao projeto pelo perodo
estabelecido inicialmente no seu cadastro e suas respetivas pendencias em tempo real. A
Figura 38 demonstra o acompanhamento das atividades do projeto sol diamante (utilizado
como piloto), o status das atividades em andamento destacadas em cores e os respectivos
nomes dos recursos ao lado da mesma.

Figura 38 Acompanhamento de projetos em desenvolvimento

E por fim a anlise do impacto dos prazos e custos reais e estimados relacionados mudana
de requisitos perca ou adio de recursos e alterao dos prazos estabelecidos com relao
aos mesmos parmetros executados realmente. A mesma anlise tambm apoia na
visualizao de fases que necessitam de melhorias em seu processo de desenvolvimento.
Com essas informaes a tomada de deciso se torna mais rpida para definir se h viabilidade de
desenvolvimento de um novo projeto de software de acordo com os recursos de colaboradores
disponveis, no tempo especificado e principalmente com os custos apresentados com o objetivo de
melhorar sempre as fases do processo de desenvolvimento dos sistemas, identificando gargalos e
assim contribuir para melhorar o negcio de produo de software da empresa.
Aps as respetivas anlises (documentaes e modelagens), implementaes, testes e treinamentos, o
sistema comeou a ser utilizado na empresa em modo experimental pelos utilizadores colaboradores
(membros da equipe do projeto em desenvolvimento), para fixar a rotina de iniciar e finalizar tarefas

60
realizadas referentes ao projeto de software que estava ativo. A princpio, atividades comuns aos
projetos foram cadastradas pelo gestor do projeto bem como os tempos estimados para execuo da
atividade baseado em um nvel de servio de mercado de desenvolvimento de sistemas. As tarefas
iniciadas e finalizadas de modo experimental colaboravam para o acompanhamento do
desenvolvimento do projeto, o que depois veio proporcionar o acompanhamento de prazos e custos
previstos e reais dos sistemas em questo.
Finalizada a fase experimental, o primeiro projeto a ser gerenciado pelo sistema foi o mdulo contas a
pagar e receber do sistema Sol Diamante, que por sua vez gerou vrias tarefas a serem realizadas, a
alocao de colaboradores com suas respetivas atividades, prazos e custos estimados. Ao iniciar o
projeto, o mesmo apresentava um cronograma previsto para o prazo a ser executado e um cronograma
secundrio para as atividades realmente realizadas, este acompanhamento real era atualizado a
medida que os colaboradores do projeto iam finalizando as tarefas iniciadas.
medida que as atividades eram iniciadas e finalizadas o sistema atualizava o cronograma juntamente
com o prazo que ainda cabia ao projeto e seu respetivo custo real at o momento em que foi
desenvolvido. Por sua vez, uma mudana foi solicitada em pleno desenvolvimento do projeto, o que
possibilitou o sistema a auxiliar em um ponto fundamental, na tomada de deciso do gestor do projeto.
Verificou-se que a mudana traria impactos relativamente grandes no custo e no prazo do projeto que
j estava em desenvolvimento, o que possibilitou a concluso de que a mudana solicitada seria mais
conveniente ser desenvolvido em um segundo momento. Esse auxlio para a tomada de deciso por
parte da equipe gestora do projeto, contribui grandiosamente para a otimizao dos prazos, custos e
recursos de mo-de-obra ao longo do projeto.

61
5 CONCLUSO
Este estudo teve como objetivo desenvolver o prottipo de um sistema que apoie o acompanhamento
do processo de produo de um sistema informtico mostrando o estado atual do desenvolvimento do
sistema, relao entre custos e tempo de construo e comparao entre tempo proposto para
produo e tempo realmente utilizado que sirvam de apoio tomada de deciso para agilizar o
desenvolvimento do projeto de software.
Na execuo deste trabalho foi-se realizando o acompanhamento dos processos de negcio de uma
empresa de desenvolvimento de sistemas que era o objeto de nosso estudo e de acordo com seus
processos foi-se mapeando o processo que a mesma executava para a realizao de suas atividades.
Aps essa etapa, foi-se abordando ento junto equipa questionamentos sobre o que se poderia
melhorar no processo de desenvolvimento de sistemas e principalmente como geri-lo de maneira mais
efetiva, acompanhando e analisando seu desenvolvimento ao longo do tempo alinhado as tcnicas de
gesto de projetos.
Durante o processo de desenvolvimento dessas aes, foi possvel acompanhar a execuo de
atividades referentes ao planeamento de novos projetos de software, a execuo das atividades
referentes construo dos sistemas (camadas de negcio, camadas de acesso a dados, modelagem
de banco de dados entre outros elementos da aplicao em desenvolvimento), a realizao de testes
funcionais, a integrao/implantao dos sistemas para o ambiente de produo, o treinamento junto
aos utilizadores e por fim o acompanhamento da gesto desses projetos.
Diante das informaes observadas e analisadas foi possvel modelar, em uma linguagem de
modelagem de processo de negcio (no caso BPML), as fases do processo de desenvolvimento de
sistemas que deveriam ser adotados e com isso informaes necessrias para implementar um
sistema para apoio gesto de projetos de software.
Deve-se destacar que o resultado deste estudo no proporcionou apenas mais uma ferramenta de
gesto de projetos especfica para sistemas de software, mas sim uma ferramenta que auxilia as
tomadas de deciso de um ou mais gestores diante de necessidades de mudanas ou novos projetos a
serem desenvolvidos de acordo com os requisitos do cliente, como tambm identificar pontos de
melhoria nos processos de construo de sistemas ou at mesmo gargalos de colaboradores
responsveis por desenvolver partes do processo.
Com o passar do tempo e maior insero de dados no sistema, o mesmo poder apresentar
informaes mais fidedignas a realidade da equipe de desenvolvimento de sistemas, tanto quanto as
suas limitaes quanto ao seu tempo de resposta a execuo de uma atividade ou at mesmo uma
fase inteira do processo de desenvolvimento de sistemas. Para isso novas funcionalidades para a

62
anlise de novas informaes para a gesto de projetos de software sendo construdo em um segundo
momento deste estudo pode ampliar a pesquisa em relao informaes a se analisar, podendo ser
esse um ponto de partida para novas pesquisas relacionadas prtica de gesto e controle de
atividades referentes a projetos de software.

63
REFERNCIAS BIBLIOGRFICAS
Bezerra, Eduardo (2002) Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 4
Edio.
Blaschek, Jos Roberto (2009) Gerncia de Projetos de Software: Processos, Mtodos e Tcnicas da
Engenharia de Software.
Bortolini, Rafael (2006) Padronizando Processos: BPMN, BPML, XPDL e BPEL. Baguete Tecnologia e
informao em um s lugar. Disponvel em: www.baguete.com.br/artigosDetalhes.imprime?id.
Acessado em 17/10/2012.
Curtis, B. (2001) Hefley, W., Miller, S., People Maturity Compability Model, Version 2.0, CMU/SEI-2001-MM-01,
Software Enginnering Institute, Carnegie Mellon University, Pittsburgh, PA.
Dias, R. (2012) Anlise por Pontos de Funo: Uma Tcnica para Dimensionamento de Sistemas de
Informao, on-line. Disponvel em: www.presidentekennedy.br/resi/edicao03/artigo02.pdf. ltimo
acesso: 13.03.2012.
Heldman, Kim (2005) Gerncia de Projetos: Guia para o exame oficial do PMI, 3 edio, Editora Campus.
Hoyer, Volker; Bucherer, Eva and Schnabel, Florian (2007) Collaborative e-Business Process Modelling:
Transforming Private EPC to Public BPMN Business Process Models; SAP Research CEC St. Gallen,
Switzerland Institute for Media and Communication Management, University of St. Gallen, Switzerland.
Engholm, E (2010) Engenharia de Software na Prtica: Novatec. So Paulo.
Frame, J. (1994) The New Project Management: Tools for an Age of Rapid Change, Corporate Reengineering,
and Other Business Realities, Jossey-Bass Inc., S. Francisco, CA.
IFPUG (2004) Counting Practices Manual. Version 4.2.
Keil, M. (1995) Pulling the Plug: Software Project Management and the Problem of Project Escalation, MIS
Quarterly, Vol. 19, Nr. 4, pp. 421-448.
Kniberg, Henrik (.2007) Scrum e XP Direto das Trincheiras. IBM.
Marques, Paulo; Pedroso, Hernni, Pedroso; Figueira, Ricardo (2009) C# 3.5, Editora FCA Editora de
Informtica, Lda, Lisboa, Portugal.
Mertz, Sharon (2007) Notcias Negcios: Mercado de software como servio vai ter forte alta at 2011. Por
COMPUTERWORLD 14 de agosto de 2007 - 7h20
http://computerworld.uol.com.br/negocios/2007/08/14/idgnoticia.2007-08-14.0458792221/.
Mertz, Sharon (2012) Gartner Says Worldwide Software-as-a-Service Revenue to Reach $14.5 Billion in
2012, STAMFORD, Conn., March 27, 2012 View All Press Releases
http://www.gartner.com/newsroom/id/1963815.
Miguel, Antonio (2010) Gesto de Projectos de Software, 4 Edio, Editora FCA Editora de Informtica, Lda,
Lisboa, Portugal.
Minayo, Maria Ceclia de Souza (1994) Pesquisa Social: teoria, mtodo e criatividade. Petrpolis: Vozes.

64
Patterson, David A. & Hennessy, John L. (2000) Organizao e projetos de computadores, A interface
hardware/software, 2 edio, editora UTC.
PMI (2008) A Guide to the Project Management Body of Knowledge (PMBOK Guide). Third Edition ed. [S.l.]:
Project Management Institute (PMI). ISBN 1-930699-45-X.
Pressman, Roger S. (2009) Engenharia de Software; 6 Edio; Editora McGraw-Hill Brasil Tcnicos.
Richardson, Robert Jarryl. (1999) Pesquisa social: mtodos e tcnicas. 3. ed. So Paulo: Atlas, P. 191.
Santos, Antnio Raimundo dos (1999) Metodologia cientfica: a construo do conhecimento. Rio de Janeiro: DP
& A, p. 29.
Seltiz, C. et al. (1967) Mtodos de pesquisa nas relaes sociais. 2. ed. So Paulo: Ed.da USP.
The Standish Group (2008) Chaos Report, http://www.standishgroup.com. ltima visita: Outubro 2012.
Willrich, Roberto (2004) Sistemas Multimdia Distribudos. Florianpolis, p. 14, UFSC.

65
Anexo I Documento de viso

I. Objetivo deste Documento

Este documento apresenta as principais caractersticas e lista os requisitos de alto-nvel do sistema de

gesto de projetos de software. Estas informaes foram acordadas entre os principais patrocinadores
do projeto e assume-se que sero de conhecimento de qualquer participante do mesmo.

II. Caractersticas do Sistema

O sistema ser desenvolvido em plataforma desktop utilizando a linguagem c sharp com a biblioteca
.Net 4.0 no ambiente de desenvolvimento Visual Dekstop Development. Sua base de dados ser
gerenciada pelo sistema SQL Server 2008 R2 e seus requisitos sero estabelecidos pelo analista de
sistemas deste projeto.

II.a) Interaes e Integraes

Desktop
Camada de apresentao
SO Windows

C Sharp
Camada de negcio
Bibliote .Net

BLL - Bisiness Layers Language

Camada de persistencia
DAO - Data Access Object

Modelo de dados

II.b) Funcionalidades

RF001 Manter Colaborador Necessrio

Esta funcionalidade compreende a manuteno de colaboradores cadastrados no sistema de gesto
de projetos de software, bem como seus dados de login e senha, identificao e contatos e

66
principalmente seus dados de experincia profissional como escolaridade, cursos e treinamentos, e
experincias na funo a exercer nos prximos projetos. O sistema permitir ao gerente listar os
colaboradores cadastrados, buscar colaboradores com a opo Consultar, alterar dados de
colaboradores j cadastrados e cadastrar novos colaboradores com a opo Salvar. Esta
funcionalidade necessria, pois permitir que os colaboradores mantidos sejam includos nos projetos
a serem executados e administrados por este sistema.
RF002 Manter Projetos Necessrio
Esta funcionalidade compreende a manuteno de projetos cadastrados no sistema de gesto de
projetos de software, bem como as suas datas de cadastro, data prevista para finalizao, data de
incio, clculo dos custos e recursos alocados para seu desenvolvimento. O sistema permitir ao
gerente de projetos cadastrar todas as informaes referentes ao projeto, bem como quantidade de
pontos de funo, alocar os recursos para o seu desenvolvimento, visualizar prazos estimados para a
entrega e principalmente estimar o custo necessrio para o desenvolvimento do mesmo. Esta
funcionalidade compartilha os dados inseridos no RF001 Manter Colaborador em virtude de que as
atividades necessrias para o desenvolvimento do projeto esto associadas com os colaboradores que
iro execut-las.
RF003 Atividades do colaborador Necessrio
Esta funcionalidade compreende a manuteno das atividades a serem desenvolvidas por cada
colaborador referente aos projetos em que os mesmos esto inseridos. O sistema permite ao utilizador
visualizar os detalhes da atividade a ser desenvolvida, inici-la e posteriormente finaliz-la, listando as
mesmas na ordem de execuo e principalmente exibindo os prazos para a execuo das mesmas,
podendo as atividades ultrapassar os prazos estabelecidos, o que implica na funcionalidade de controle
de projeto, onde o gerente acompanha e ajusta os prazos do projeto em execuo.
RF004 Controle do projeto Necessrio
Esta funcionalidade utilizada para captar clientes compradores para realizarem troca ou negociao
de um novo veculo com a empresa. O gerente poder criar uma campanha atravs de consulta
base de clientes compradores ativos, por meio de filtros pr-determinados, a fim de selecionar alguns
para participarem da campanha. O sistema permitir que o gerente modifique o script desta campanha
em uma rea de Configurao exclusivamente deste trabalho. Nesta rea, o gerente tambm define
quais os colaboradores que tero acesso a esta campanha e posteriormente acompanhar os respetivos
desempenhos dos mesmos em uma rea de Desempenho por perodo. O gerente poder tambm
atribuir ou no uma data limite para esta campanha. Aps a seleo de compradores e selecionados os
colaboradores, o sistema disponibilizar os clientes em uma lista que ser acessada pelo consultor
medida que o mesmo estiver logado e acessando o sistema de campanha para compradores. Aps

67
selecionar a campanha de clientes compradores, o sistema exibir os dados do cliente e um script
padro de atendimento podendo Iniciar o atendimento aos clientes e/ou Sair desta tela. O consultor
poder registrar um histrico da ligao e atribuir um estado ligao. Aps trabalhar o cliente o
sistema exibir o prximo cliente da lista para ser trabalhado at que no haja mais nenhum cliente
atribudo ao consultor.
RF005 Controle de clientes Necessrio
Esta funcionalidade compreende a manuteno dos clientes (stackholders) solicitantes dos projetos
cadastrados para desenvolvimento. O sistema permite ao utilizador visualizar os detalhes dos
cadastros dos clientes atravs de uma listagem geral, bem como altera-lo e exclu-lo.

II.c) Restries do Produto

Este produto restrito a ambiente com sistema operacional Windows das verses XP, Vista, 7 e 8.

III. Utilizadores do Sistema

Este sistema direcionado para utilizadores gestores de projetos.

III.a) Caracterizao dos Utilizadores

Gestores de projetos de software que necessitam analisar e acompanhar as atividades inerentes aos
seus projetos e auxiliar em suas tomadas de decises

III.b) Utilizao do Sistema

Neste sistema ser abordado o acompanhamento de atividades referente ao projeto em

desenvolvimento e a disponibilidade dos recursos para novos projetos cadastrados e o custo e prazo
dos mesmos diante dos recurso inseridos.

68
Anexo II Diagrama de caso de uso

Figura - Diagrama geral de caso de uso.

69
Anexo III Documento de especificao de Caso de Uso Manter Cliente

Projeto Sistema de Gesto de Projeto de Software SGPS 001

Especificao de Caso de Uso:
UC D2012.001 Manter Cliente
Verso 1.0.0

70
 Histrico de Revises
Data Verso Descrio Autor

20/07/2012 001 Especificao de Caso de Uso Marcelo Silva

71
1 Breve Descrio
Este caso de uso responsvel por possibilitar ao utilizador a manuteno dos dados do cliente no sistema
de gesto de projetos de software.
2 Interfaces Manter cliente.
2.1 Layout Sugerido

Tela A Lista de clientes cadastrados

72
 Tela B Cadastro de ciente

2.2 Relacionamentos com outros casos de uso

Este caso de uso no possui relacionamentos com outros casos de uso.

2.3 Campos
N Nome Descrio Valores vlidos Formato Tipo Restries
Tela A Lista de clientes cadastrados
Exibe o nome ou Obrigatrio
Nome / Razo At 50 caracteres
1. razo social do GridView Texto No
social alfanumricos
cliente Altervel
Obrigatrio
Exibe o login de At 50 caracteres
2. Login GridView Texto No
acesso do cliente alfanumricos
Altervel
Obrigatrio
Exibe a senha de At 10 caracteres
3. Senha GridView Texto No
acesso do cliente alfanumricos
Altervel
Tela B Cadastro de ciente

Especifica o nome
Nome / Razo At 50 caracteres Obrigatrio
4. ou razo social do TextBox Texto
social alfanumricos Altervel
cliente
Especifica o login
At 50 caracteres Obrigatrio
5. Login de acesso do TextBox Texto
alfanumricos Altervel
cliente

73
 Especifica a senha
At 10 caracteres Obrigatrio
6. Senha de acesso do TextBox Texto
alfanumricos Altervel
cliente

2.4 Comandos
N Nome
1 Novo
2 Excluir
3 Salvar
4 Cancelar
Ao Restries
O sistema exibe a tela B para execuo de novo
Sempre habilitado
cadastro de cliente
Exclui o cliente selecionado na grid de cadastrado Sempre habilitado
Armazena os dados inseridos do cliente especificado Sempre habilitado
Retorna a pgina de listagem e no persiste os
Sempre habilitado
dados inserido do cliente

3 Realizao do Caso de Uso

3.1 Atores
Utilizador (Gestor de projeto de software)

3.2 Pr-condies
O utilizador deve estar CADASTRADO como administrador com o estado ATIVO, e ter acesso ao mdulo de
gerenciamento de clientes.
3.3 Ps-condies
Aps o cadastro de cliente, o mesmo pode acessar as informaes do seu projeto a ser desenvolvido.
3.4 Regra de Negcio
RN0001 Manter cliente.
o Ao visualizar as campanhas ativas, o sistema exibe os indicadores da campanha na grid.

3.5 Descrio do caso de uso

Fluxo principal Manter cliente

1. Este caso de uso inicia quando o utilizador (Gestor de projeto de software) acessa o Menu >>
Gerenciamento >> Cliente.
2. O sistema exibe a tela A listando os clientes da empresa que possuem cadastro de acesso ao sistema
de gesto de projeto de software.
3. Opcionalmente, o gestor poder os dados de acesso do cliente no sistema.
4. Caso o utilizador queira cadastrar um novo cliente, o mesmo seleciona a opo Novo.
5. O sistema exibe a tela B de cadastro de novos clientes.
6. O utilizador especifica as informaes de cadastro e seleciona a opo Salvar.
7. O sistema armazena os dados especificados e retorna para a tela A.
8. Opcionalmente o utilizador poder cancelar o cadastro iniciado selecionando a opo Cancelar.
9. Este caso de uso se encerra.

74
Anexo IV Documento de especificao de Caso de Uso Manter Colaboradores

Projeto Sistema de Gesto de Projeto de Software SGPS 001

Especificao de Caso de Uso:
UC D2012.002 Manter Colaboradores
Verso 1.0.0

75
 Histrico de Revises
Data Verso Descrio Autor

20/07/2012 001 Especificao de Caso de Uso Marcelo Silva

1 Breve Descrio
Este caso de uso responsvel por possibilitar ao utilizador a manuteno dos dados dos colaboradores
que contribuiro com os projetos a serem gerenciados no sistema de gesto de projetos de software.
2 Interfaces Manter colaboradores.
2.1 Layout Sugerido

76
 Tela A Lista de colaboradores

Tela B Cadastro de colaboradores

2.2 Relacionamentos com outros casos de uso

Este caso de uso no possui relacionamentos com outros casos de uso.

77
2.3 Campos
N Nome Descrio Valores vlidos Formato Tipo Restries
Tela A Lista de colaboradores
Exibe o nmero de Obrigatrio
At 5 caracteres
1. Matrcula matrcula do GridView Texto No
numricos
colaborador Altervel
Exibe o nome do Obrigatrio
At 50 caracteres
2. Colaborador colaborador GridView Texto No
alfanumricos
cadastrado Altervel
Exibe o nmero do Obrigatrio
10 caracteres
3. Telefone telefone de contato GridView Texto No
numricos
do cliente Altervel
Exibe a data de Obrigatrio
At 50 caracteres
4. Data cadatsro cadastro do GridView Texto No
alfanumricos
colaborador Altervel
Exibe o nvel de Obrigatrio
Nvel de At 50 caracteres
5. experincia do GridView Texto No
experiencia alfanumricos
colaborador Altervel
Exibe o login de Obrigatrio
At 50 caracteres
6. Login acesso do GridView Texto No
alfanumricos
colaborador Altervel
Obrigatrio
Exibe o cargo do At 50 caracteres
7. Cargo GridView Texto No
colaborador alfanumricos
Altervel
Exibe o nvel de Obrigatrio
De 1 a 11 anos ou
8. Experiencia experincia do GridView Texto No
mais
colaborador Altervel
Exibe a Obrigatrio
At 50 caracteres
9. Escolaridade escolaridade do GridView Texto No
alfanumricos
colaborador Altervel
Exibe o estado de Obrigatrio
- Ativo
10. Estado cadastro do GridView Texto No
- Inativo
colaborador Altervel
Tela B Cadastro de ciente

Especifica o nome
At 50 caracteres Obrigatrio
11. Nome do colaborador a TextBox Texto
alfanumricos Altervel
cadastrar
Especifica o login No
At 50 caracteres
12. Telefone de acesso do TextBox Texto Obrigatrio
alfanumricos
cliente Altervel
Lista as opes de
At 50 caracteres Obrigatrio
13. Escolaridade escolaridade do ComboBox Texto
alfanumricos Altervel
colaborador
Lista as opes de
At 50 caracteres Obrigatrio
14. Cargo cargo do ComboBox Texto
alfanumricos Altervel
colaborador
Lista as opes de
Tempo de
tempo de De 1 a 11 anos ou Obrigatrio
15. experiencia (em ComboBox Texto
experincia do mais Altervel
anos)
colaborador

78
 No
Especifica o login At 50 caracteres
16. Login TextBox Texto Obrigatrio
do colaborador alfanumricos
Altervel
No
Especifica a senha At 10 caracteres
17. Senha TextBox Texto Obrigatrio
do colaborador alfanumricos
Altervel
Lista os estado
- Ativo Obrigatrio
18. Estado possveis do ComboBox Texto
- Inativo Altervel
colaborador
Exibe o nvel de Obrigatrio
Experiencia do At 3 caracteres
19. experincia do Label Texto No
colaborador numricos
colaborador Altervel

2.4 Comandos
N Nome Ao Restries
O sistema exibe a tela B para execuo de novo
1 Novo Sempre habilitado
cadastro de colaborador.
Exclui o colaborador selecionado na grid de
2 Excluir Sempre habilitado
cadastrado
Armazena os dados inseridos do colaborador
3 Salvar Sempre habilitado
especificado
Retorna a pgina de listagem e no persistem os
4 Cancelar Sempre habilitado
dados inseridos do colaborador

3 Realizao do Caso de Uso

3.1 Atores
Utilizador (Gestor de projeto de software)

3.2 Pr-condies
O utilizador deve estar CADASTRADO como administrador com o estado ATIVO, e ter acesso ao mdulo de
gerenciamento de colaboradores.
3.3 Ps-condies
Aps o cadastro de colaborador, o mesmo fica disponvel para ser inserido em projetos e posteriormente
visualizar suas atividades a realizar.
3.4 Regra de Negcio
RN0001 Manter colaborador.
o No se aplica a esse caso de uso.
3.5 Descrio do caso de uso
Fluxo principal Manter colaborador

1. Este caso de uso inicia quando o utilizador (Gestor de projeto de software) acessa o Menu >>
Gerenciamento >> Colaborador.
2. O sistema exibe a tela A listando os colaboradores que possuem cadastro no sistema de gesto de
projeto de software.

79
3. Opcionalmente, o gestor poder alterar os dados de cadastro do colaborador no sistema.
4. Caso o utilizador queira cadastrar um novo colaborador, o mesmo seleciona a opo Novo.
5. O sistema exibe a tela B de cadastro de novos colaboradores.
6. O utilizador especifica as informaes de cadastro e seleciona a opo Salvar.
7. O sistema armazena os dados especificados e retorna para a tela A.
8. Opcionalmente o utilizador poder cancelar o cadastro iniciado selecionando a opo Cancelar.
9. Este caso de uso se encerra.

80
Anexo V Documento de especificao de Caso de Uso Manter Empresa

Projeto Sistema de Gesto de Projeto de Software SGPS 001

Especificao de Caso de Uso:
UC D2012.003 Manter Empresa
Verso 1.0.0

81
 Histrico de Revises
Data Verso Descrio Autor

20/07/2012 001 Especificao de Caso de Uso Marcelo Silva

1 Breve Descrio
Este caso de uso responsvel por possibilitar ao utilizador a manuteno dos dados da empresa que ir
administrar o sistema e gerenciar o projeto de software a ser gerenciado no sistema de gesto de projetos
de software.
2 Interfaces Manter empresa.
2.1 Layout Sugerido

82
 Tela A Lista de empresas

Tela B Cadastro de empresas

2.2 Relacionamentos com outros casos de uso

Este caso de uso no possui relacionamentos com outros casos de uso.

83
2.3 Campos
N Nome Descrio Valores vlidos Formato Tipo Restries
Tela A Lista de colaboradores
Exibe a razo Obrigatrio
At 50 caracteres
1. Razo social social da empresa GridView Texto No
alfanumricos
cadastrada Altervel
No
Exibe o CNPJ da
At 50 caracteres Obrigatrio
2. CNPJ empresa GridView Texto
alfanumricos No
cadastrada
Altervel
10 caracteres No
Exibe a data de
alfanumricos no Obrigatrio
3. Data abertura abertura da GridView Texto
formato No
empresa
00/00/0000 Altervel
Exibe o nome do Obrigatrio
Colaborador At 50 caracteres
4. colaborador GridView Texto No
responsvel alfanumricos
responsvel Altervel
Tela B Cadastro de empresas

Especifica o nome
At 50 caracteres Obrigatrio
5. Razo social da empresa TextBox Texto
alfanumricos Altervel
responsvel
Especifica o CNPJ No
At 50 caracteres
6. CNPJ da empresa TextBox Texto Obrigatrio
alfanumricos
responsvel Altervel
Especifica a data 10 caracteres
No
de abertura da alfanumricos no
7. Data abertura TextBox Texto Obrigatrio
empresa formato
Altervel
responsvel 00/00/0000
Especifica o nome
Colaborador do colaborador At 50 caracteres Obrigatrio
8. TextBox Texto
responsvel responsvel pela alfanumricos Altervel
empresa
Especifica o login
At 50 caracteres Obrigatrio
9. Login admin de administrador TextBox Texto
alfanumricos Altervel
do sistema
Especifica a senha
de acesso do At 50 caracteres Obrigatrio
10. Senha TextBox Texto
responsvel alfanumricos Altervel
empresa

2.4 Comandos
N Nome Ao Restries
O sistema exibe a tela B para execuo de novo
1 Novo Sempre habilitado
cadastro de empresa.
2 Excluir Exclui a empresa selecionada na grid de cadastrado Sempre habilitado
Armazena os dados inseridos da empresa
3 Salvar Sempre habilitado
especificada
Retorna a pgina de listagem e no persistem os
4 Cancelar Sempre habilitado
dados inseridos da empresa

84
3 Realizao do Caso de Uso
3.1 Atores
Utilizador (Gestor de projeto de software)

3.2 Pr-condies
O utilizador deve estar CADASTRADO como administrador com o estado ATIVO, e ter acesso ao mdulo de
gerenciamento de empresas.
3.3 Ps-condies
Aps o cadastro de empresas, o mesmo fica disponvel para cadastrar seus colaboradores e clientes,
consequentemente projetos a serem desenvolvidos.
3.4 Regra de Negcio
RN0001 Manter empresa.
o No se aplica a esse caso de uso.
3.5 Descrio do caso de uso
Fluxo principal Manter empresa

1. Este caso de uso inicia quando o utilizador (Gestor de projeto de software) acessa o Menu >>
Gerenciamento >> Empresa.
2. O sistema exibe a tela A listando as empresas que possuem cadastro no sistema de gesto de projeto
de software.
3. Opcionalmente, o gestor poder alterar os dados de cadastro da empresa no sistema.
4. Caso o utilizador queira cadastrar uma nova empresa, o mesmo seleciona a opo Novo.
5. O sistema exibe a tela B de cadastro de novas empresas.
6. O utilizador especifica as informaes de cadastro e seleciona a opo Salvar.
7. O sistema armazena os dados especificados e retorna para a tela A.
8. Opcionalmente o utilizador poder cancelar o cadastro iniciado selecionando a opo Cancelar.
9. Este caso de uso se encerra.

85
Anexo VI Documento de especificao de Caso de Uso Manter Projeto

Projeto Sistema de Gesto de Projeto de Software SGPS 001

Especificao de Caso de Uso:
UC D2012.004 Manter Projeto
Verso 1.0.0

86
 Histrico de Revises
Data Verso Descrio Autor

01/08/2012 001 Especificao de Caso de Uso Marcelo Silva

1 Breve Descrio
Este caso de uso responsvel por possibilitar ao utilizador a manuteno dos dados a serem
desenvolvidos pela empresa no sistema de gesto de projetos de software.
2 Interfaces Manter projeto.
2.1 Layout sugerido

87
 Tela A Lista de projetos

Tela B Cadastro de projetos

2.2 Relacionamentos com outros casos de uso

88
Este caso de uso possui relacionamentos com o caso de uso UC-D2012.001 Manter Cliente, UC-D2012.002
Manter Colaborador e UC-D2012.005 Manter Atividade.

2.3 Campos
N Nome Descrio Valores vlidos Formato Tipo Restries
Tela A Lista de projetos
Exibe o nome da
Obrigatrio
empresa At 50 caracteres
1. Stackholder GridView Texto No
solicitante do alfanumricos
Altervel
projeto
Exibe o nome do Obrigatrio
At 50 caracteres
2. Nome projeto projeto a ser GridView Texto No
alfanumricos
desenvolvido Altervel
No
Exibe o valor a ser At 10 caracteres
Obrigatrio
3. Valor HH cobrado pela hora alfanumricos no GridView Texto
No
ao projeto formato 000.000,00
Altervel
Exibe a
No
quantidade de
Obrigatrio
4. Qtd. Horas horas que ser GridView Texto
No
desprendida ao
Altervel
projeto
No
Obrigatrio
5. Valor ponto funo GridView Texto
No
Altervel
No
Obrigatrio
6. Qtd. ponto funo GridView Texto
No
Altervel
Exibe o nome do Obrigatrio
Custo previsto At 50 caracteres
7. colaborador GridView Texto No
projeto alfanumricos
responsvel Altervel
Obrigatrio
Tempo previsto
8. GridView Texto No
projeto
Altervel
Obrigatrio
9. Custo real projeto GridView Texto No
Altervel
Obrigatrio
10. Tempo real projeto GridView Texto No
Altervel
Obrigatrio
11. Estado projeto GridView Texto No
Altervel
Tela B Cadastro de empresas

Especifica o nome
At 50 caracteres Obrigatrio
12. Razo social da empresa TextBox Texto
alfanumricos Altervel
responsvel

89
 Especifica o CNPJ No
At 50 caracteres
13. CNPJ da empresa TextBox Texto Obrigatrio
alfanumricos
responsvel Altervel
Especifica a data 10 caracteres
No
de abertura da alfanumricos no
14. Data abertura TextBox Texto Obrigatrio
empresa formato
Altervel
responsvel 00/00/0000
Especifica o nome
Colaborador do colaborador At 50 caracteres Obrigatrio
15. TextBox Texto
responsvel responsvel pela alfanumricos Altervel
empresa
Especifica o login
At 50 caracteres Obrigatrio
16. Login admin de administrador TextBox Texto
alfanumricos Altervel
do sistema
Especifica a senha
de acesso do At 50 caracteres Obrigatrio
17. Senha TextBox Texto
responsvel alfanumricos Altervel
empresa

2.4 Comandos
N Nome Ao Restries
O sistema exibe a tela B para execuo de novo
5 Novo Sempre habilitado
cadastro de empresa.
6 Excluir Exclui a empresa selecionada na grid de cadastrado Sempre habilitado
Armazena os dados inseridos da empresa
7 Salvar Sempre habilitado
especificada
Retorna a pgina de listagem e no persistem os
8 Cancelar Sempre habilitado
dados inseridos da empresa

3 Realizao do Caso de Uso

3.6 Atores
Utilizador (Gestor de projeto de software)

3.7 Pr-condies
O utilizador deve estar CADASTRADO como administrador com o estado ATIVO, e ter acesso ao mdulo de
gerenciamento de empresas.
3.8 Ps-condies
Aps o cadastro de empresas, o mesmo fica disponvel para cadastrar seus colaboradores e clientes,
consequentemente projetos a serem desenvolvidos.
3.9 Regra de Negcio
RN0001 Manter empresa.
o No se aplica a esse caso de uso.
3.10 Descrio do caso de uso
Fluxo principal Manter empresa

90
10. Este caso de uso inicia quando o utilizador (Gestor de projeto de software) acessa o Menu >>
Gerenciamento >> Empresa.
11. O sistema exibe a tela A listando as empresas que possuem cadastro no sistema de gesto de projeto
de software.
12. Opcionalmente, o gestor poder alterar os dados de cadastro da empresa no sistema.
13. Caso o utilizador queira cadastrar uma nova empresa, o mesmo seleciona a opo Novo.
14. O sistema exibe a tela B de cadastro de novas empresas.
15. O utilizador especifica as informaes de cadastro e seleciona a opo Salvar.
16. O sistema armazena os dados especificados e retorna para a tela A.
17. Opcionalmente o utilizador poder cancelar o cadastro iniciado selecionando a opo Cancelar.
18. Este caso de uso se encerra.

91
92