Universidade Estadual de Goiás

Unidade Universitária de Santa Helena de Goiás

Apostila de Engenharia de Software

Profª Dilça Cabral de Jessus

Material elaborado a partir dos livros Sommerville (2007) e Presman

(1995)
 1. ENGENHARIA DE SOFTWARE

1.1 Introdução
Hoje, praticamente todos os países, dependem de softwares ou algum tipo de sistema
baseados em computadores.
Exemplos:
A manufatura e a distribuição industrial estão completamente automatizados, assim como os
sistemas financeiros.
Dessa forma, produzir e manter softwares de qualidade dentro de custos adequados tornou-
se essencial para o funcionamento da economia mundial.
Software é abstrato e intangível, o que facilita para a Engenharia de Software, pois não
existe limites físicos para o seu desenvolvimento. Contudo, essa falta de restrições significa que o
software pode tornar-se complexo e difícil de ser compreendido.
E com o surgimento da necessidade de desenvolver softwares mais complexos e de grande
porte, verificou-se que a construção de software de maneira informal não era suficiente e adequada .
Projetos importantes apresentavam, algumas vezes anos de atraso. Estimativas de prazos e
custos frequentemente imprecisos, ira difícil manter o software e seu desempenho era insatisfatório,
constatou-se que o “desenvolvimento de software estava em crise”.
O conceito da Engenharia de Software foi proposto em 1968, em uma conferência para
discutir a então chamada crise do software.
O termo crise do software, refere-se a um conjunto de fatores que afetavam o
desenvolvimento de software. E esses problemas não se limitam ao software que não funciona
adequadamente, mas abrange também problemas associados a forma de desenvolvimento destes
softwares, a forma como é efetuada a manutenção destes softwares, como atender a demanda por
novos softwares e como desenvolver novos softwares cada vez mais rapidamente. JÚNIOR (s/d)
Alguns mitos também contribuíram na dificuldade de desenvolvimento de software, tais
como:
• Temos as ferramentas de última geração para o desenvolvimento do software – precisa-se
mais do que tecnologia atua para se desenvolver um software de qualidade.
• Caso o projeto de desenvolvimento de software esteja atrasado, acrescente mais
programadores – adicionar pessoas em um projeto atrasado, pode atrasá-lo ainda mais, pois
essas pessoas estão habilitadas para trabalhar neste projeto.
Alguns desses mitos contribuíram ainda mais para o fortalecimento da dificuldade das
organizações em desenvolvimento de software.
 Os custos de software aumentavam, enquanto o hardware diminuíam consideravelmente.
Dessa forma, tornava-se necessário criar novas técnicas e métodos para acompanhar a
complexidade inerente aos grandes sistemas de software.
Essas técnicas tornam-se parte da Engenharia de Software e são amplamente usadas hoje em
dia. No entanto, assim como aumentou a habilidade de produzir software, aumentou também a
necessidade de criar sistemas de software mais complexos.
Novas tecnologias resultantes da convergência de computadores e sistemas de comunicação,
e as complexas interfaces com o usuário, impuseram novos desafios aos engenheiros de software.
Ainda hoje, muitas empresas não aplicam as técnicas de engenharia de software, e
desenvolvem software com baixa qualidade, atrasam e os custos vão além do orçamento previsto.
Verifica-se que houve grandes avanços na maneira de construir softwares, pois entende-se
melhor as atividades envolvidas no processo de desenvolvimento. Novas notações e ferramentas
reduzem o esforço para a produção de sistemas mais complexos e de grande porte.

1.2. Software
O que é software?
Muitos ainda associam o termo aos programas de computadores. No entanto, software não é
apenas o programa em si, mas todos os dados de documentação e configuração associados,
necessários para que o programa opere corretamente.
Um sistema de software consiste, geralmente de programas separados, mas necessário para a
operação do sistema:
1. Arquivos de configuração: usados para configurar esses programas;
2. Documentação do sistema: tem a finalidade de descrever toda a estrutura do sistema;
3. Documentação do usuário: explica como utilizar o sistema;
4. Sites-web: por meio dos quais o usuário pode obter informações recentes sobre o produto.

Os engenheiros de softwares estão envolvidos com o desenvolvimento de

produtos de software, isto é, software que pode ser vendido para um cliente. Neste contexto,
existem dois tipos de sistemas de software:
1. Produtos genéricos: sistemas do tipo stand-alone, produzidos por uma organização e
vendidos para qualquer cliente que esteja disposto a comprá-lo.
Exemplos:
• Banco de dados;
• Processadores de texto;
• Pacotes gráficos;
 • Ferramentas para gerenciamento de projetos, etc.
2. Produtos sob encomenda (personalizados): são os sistemas encomendados por um
determinado cliente. O software é desenvolvido para aquele cliente por uma empresa de
software.
Exemplos:
• Sistemas de controle de dispositivos eletrônicos;
• Sistemas de apoio a um determinado processo de negócio;
• Sistemas de controle de tráfego aéreo;
• Sistemas de controle de estoque, etc.

Um diferença importante entre esses tipos de softwares é que: os produtos genéricos a

organização que desenvolve o software controla sua especificação. Enquanto, nos produtos
personalizados, a especificação é desenvolvida e controlada paela empresa que adquire o software.
No entanto, verifica-se que a linha entre esses tipos de produto esta cada vez mais tênue,
pois, muitas empresas desenvolvem produtos genéricos e modificam-na de acordo com a
necessidade de um cliente especifico.
Exemplos
• Sistemas de Planejamento de Recursos Empresariais (ERP);
• SAP.

1.3. O que é Engenharia de Software?

A Engenharia de Software é uma disciplina da engenharia relacionada com todos os
aspectos da produção de software, desde os estágios iniciais até sua manutenção, depois que o
sistema entra em operação. Neste conceito há dois aspectos importantes:
1. Disciplina de engenharia: as engenharias aplicam teorias, métodos e ferramentas onde for
apropriado. E devem trabalharem sob as restrições organizacionais e financeiras existentes.
2. Todos os aspectos da produção de software: a Engenharia de Software não está relacionada
apenas com os processos técnicos da produção de software, mas também com atividades
como gerenciamento de projeto de software e o desenvolvimento de ferramentas, métodos e
teorias que apoiem a sua produção.

1.3.1. Processo de Software

Um processo de software é um conjunto de atividades e resultados que produz um produto
de software. Destaca-se quatro atividades fundamentais desse processo:
 1. Especificação de sofrear: clientes e engenheiros definem o software a ser produzido e as
restrições para a sua operação.
2. Desenvolvimento de software: o software é projetado e programado.
3. Validação de software: verifica o software para garantir que faça o que o cliente deseja.
4. Evolução de software: o software sofre modificações para adaptar as mudanças do cliente e
do mercado.

Observações
Diferentes tipos de sistemas necessitam de diferentes processos de desenvolvimento.
Exemplo
• Um software de tempo real de uma aeronave deve ser completamente especificado antes do
início de seu desenvolvimento, enquanto, nos sistemas de comércio eletrônico a
especificação e o programa são, geralmente, desenvolvidos em conjunto.

Consequentemente, essas atividades genéricas podem ser organizadas de diferentes maneiras

e descritas em diversos níveis de detalhes para os mais variados tipos de software.

1.4. Custos da Engenharia de Software

Não existe uma resposta exata para essa pergunta, pois a distribuição do custo ao longo das
diferentes atividades no processo de software depende do processo e do tipo de software que está
sendo desenvolvido.
Por exemplo
• Software de tempo real geralmente, requer validação e teste mais extensos do que sistemas
baseados na web.

Na abordagem cascata, os custos de especificação, projeto, implementação e integração são

medidos separadamente.
Observa-se que a integração e testes são as atividades mais caras. Normalmente, requerem
cerca de 40 por cento dos custos totais de desenvolvimento, mas em alguns cados de pelo menos 50
por cento desses custos.
Se o software é desenvolvido usando uma abordagem iterativa, não existe uma linha precisa
entre especificação, projeto e desenvolvimento.
Os custos de especificação são reduzidos, pois apenas uma especificação de alto nível é
introduzida antes do seu desenvolvimento. Especificação, projeto, integração e testes são realizados
paralelamente com o desenvolvimento. No entanto, precisa-se de uma atividade de teste
independente, uma vez que a implementação inicial esteja completa.
A engenharia baseada em componente tem sido aplicada intensamente somente nos últimos
anos. Não existe valores precisos dos custos das diferentes atividades nessa abordagem. Contudo,
sabe-se que os custos de desenvolvimento são menores que os custos de integração e de testes.
Esses custos aumentam porque é necessário assegurar que os componentes utilizados
realmente satisfazem às especificações e funcionem, conforme esperado com os outros
componentes.
Além, dos custos de desenvolvimento, os custos também incorrem em alterações no
software depois da sua liberação para uso. Os custos de evolução variam muito, dependendo do tipo
de sistema.
Exemplo
• Para software de vida longa, tais como sistemas de comando e controle, esses custos
provavelmente excedem de três a quatro vezes os custos de desenvolvimento. Por outro
lado, sistemas de pequenas empresas possuem uma vida mais curta e consequentemente,
custos de evolução são reduzidos.

Essas distribuições, são válidas para software sob encomenda. Para sistemas genéricos os
custos de especificação são relativamente baixos. No entanto, como estão previstos para serem
usados em diferentes configurações, eles devem ser testados intensamente.

1.5. Métodos da Engenharia de Software

Um método de engenharia de software é uma abordagem estruturada para desenvolvimento
de software, cujo objetivo é facilitar a produção de software de alta qualidade dentro de custos
adequados.
Métodos tais como Análise Estrutura foram desenvolvidos inicialmente na década de 1970.
Esses métodos orientados a funções ainda são usados. Nas décadas de 1980 e 1990, esses métodos
foram suplementados por métodos orientados a objeto (OO). Essas diferentes abordagens foram
integradas em uma única Linguagem Unificada de Modelagem (UML).
Não existe um método ideal e diferentes métodos possuem diversas áreas onde são mais
aplicáveis.
Por exemplo: Os métodos orientados a objetos são geralmente apropriados para sitemas
interativos, mas não para sistemas com requisitos rigorosos de tempo real.
1.6. Ferramente Case
As ferramentas case abrange uma larga faixa de diferentes tipos de programas que são
usados para dar apoio às atividades do processo de software.
• Análise de requisitos;
• Modelagem de sistema;
• Depuração e testes.

1.7. Atributos de um Bom Software

Assim, como os serviços que ele fornece, os produtos de software possuem outros atributos
associados que demonstram a qualidade do software. Esses atributos não estão relacionados
diretamente com o que o software faz.
Em vez disso, refletem o comportamento do software, enquanto este está em execução, a
estrutura, a organização fonte bem como a documentação associada.
O conjunto específico de atributos de um software depende, da sua aplicação. Portanto, um
sistema bancário dever ser seguro. Um jogo interativo deve ter resposta ágil e assim por diante. Isso
pode ser generalizado em um conjunto de atributos apresentados na tabela 1.
Tabela 1 Atributos de um bom software
Característica do Produto Descrição

Facilidade de Manutenção O software deve oferecer possibilidade de evolução que modo a

atender às necessidades do cliente.

Confiança O software deve ser confiável, ou seja, não deve causar danos
físicos ou econômicos caso ocorra alguma falha.
Eficiência O software não deve fazer uso desnecessário de recursos do
sistema, como: tempo de processamento, utilização da memória,
etc.
Usabilidade O software deve ser utilizável pelos usuários para os quais ele
foi criado. Deve apresentar uma interface amigável.
Sommerville, 2007

1.8. Desafios da Engenharia de Software

A Engenharia de Software no século XXI depara principalmente com três desafios:
1. Desafio da Heterogeneidade: cada vez mais é necessário técnicas de desenvolvimento para
construção de software que podem lidar com plataformas heterogêneas e ambientes de
execução;
2. Desafio da Entrega: técnicas de desenvolvimento para conduzir a entrega mais rápida de
software;
3. Desafio da Confiança: técnicas de desenvolvimento que mostram que o software pode ter a
confiança dos s0eus usuários.

Pontos-chave
• A Engenharia de Software é uma disciplina de engenharia relacionada a todos os
aspectos de produção de software.
• Os produtos de software consistem em programas desenvolvidos e documentação
associada. Os atributos essenciais são: facilidade de manutenção, confiança, eficiência e
aceitação.
• O Processo de software incui todos as atividades envolvidas no desenvolvimento de
software.
• Os engenheiros de software têm responsabilidades com a profissão de engenharia e com
a sociedade. Não devem se preocupar apenas com questões técnicas.
2. PARADIGMAS DE DESENVOLVIMENTO DE SOFTWARE
A Engenharia de Software abrange um conjunto de elementos que possibilita o controle do
processo de desenvolvimento de software e oferece uma base para o desenvolvimento de produtos
de software de qualidade. Tais elementos serão descritos a seguir:
1. Processos: conjunto de atividades envolvidas na produção de um software.
2. Métodos: trabalha com os detalhes de “como fazer” para construir um software.
Envolve tarefas como:
a. Planejamento;
b. Estimativa de projeto
c. Análise de requisitos.
Exemplos de métodos utilizados:
• OO;
• DFD;
• UML;
• MER.
3. Ferramentas: tem como objetivo proporcionar apoio automatizado ou semi-automatizado
aos métodos.
Exemplo:
• Ferramentas Case;
• Case Studio;
• Dr. Case;
• Visio.
4. Procedimentos: tem a finalidade de construir o elo de ligação mantendo juntos os métodos
e ferramentas. Segundo Pressman (1995), os precedimentos definem a sequência em que os
métodos serão aplicados, produtos a serem entregues (relatórios, documentos, etc).
A seguir serão discutidos alguns paradigmas de desenvolvimento de software. O paradigma
deve ser aplicado (escolhido) levando em consideração o tipo de aplicação a ser desenvolvida.

2.1. Modelo Ciclo de Vida (Cascata)

O modelo Cascata requer um abordagem sistemática e sequencial no processo de construção
do software. O resultado de uma fase se constitui na entrada de outra. A figura 2 ilustra as
atividades envolvidas neste modelo.
Figura 1. Modelo Ciclo de Vida (Cascata)

Pressman, (1995)

• Engenharia de sistemas: nesta etapa estabelece os requisitos básico que envolve a

construção do software, como:
o Hardware;
o Software;
o Banco de dados;
o Recursos humanos.
Observação
Quanto mais dados coletados a nível de sistemas menor a probabilidade de ocorrer bugs.
• Análise de Requisitos: nesta fase, a coleta de requisitos é intensificada e concentrada no
software. Ou seja, definidos os serviços, restrições e objetivos. O engenheiro de software
necessita compreender o problema no qual esta trabalhando.
• Projeto: concentra-se em quatro atributos do programa:
o Estrutura de dados;
o Arquitetura de software;
o Detalhes procedimentais e
o Caracterização de interface.
O processo de projeto traduz as exigências numa representação que podem ser avaliadas quanto
à qualidade, antes que a codificação se inicie.
• Codificação: o software é desenvolvido, ou seja, trata-se da fase em que o programa é
codificado, bases de dados criadas e os módulos integrados.
• Testes: concentra-se:
o nos aspectos lógicos internos do software: garantir que as funções operem
corretamente;
 o aspectos funcionais externos: tem a finalidade de descobrir erros e garantir que a
entrada definida produza os resultados esperados.
• Manutenção: o software sofrerá modificações após ser entregue ao usuário. Mudanças
ocorrerão devido a erros encontrados ou porque o software precisa ser adaptado para atender
modificações exigidas.
Exemplo:
o Mudanças por causa de um novo sistema operacional;
o Acréscimo de funcionalidade ou de desempenho.

2.1.1. Vantagens do Modelo Cascata

O paradigma cascata é o mais antigo e amplamente usado. Permite documentar cada etapa,
o que torna o processo de desenvolvimento estruturado. Oferece ainda, a possibilidade de trabalhar
em conjunto com outros modelos.

2.1.2. Desvantagens do Modelo Cascata

Os projetos reais raramente segue o fluxo sequencial exigido pelo modelo. Geralmente,
ocorre iterações e isso traz problemas em sua aplicação. Também, é difícil para o cliente declarar
todos os requisitos e restrições do sistema.
Não é disponibilizado nenhuma versão preliminar do sistema para o usuário. Terá que
aguardar a finalização do software para uso, ou seja, o cliente precisa ter paciência para utilizar o
sistema. E um erro crasso pode ser desastroso no processo de desenvolvimento do software.

2.1.3. Aplicabilidade do Modelo Cascata

• Quando os requisitos forem bem compreendidos;
• Quando houver baixa probabilidade de mudanças radicais no desenvolvimento do sistema;
• A tecnologia utilizada é acessível e os recursos devem estarem disponíveis.

2.2 Desenvolvimento Evolucionário

O desenvolvimento evolucionário tem o objetivo de trabalhar com o desenvolvimento

(implementação) inicial, expondo os resultados aos comentários do usuário. O software deve ser
aprimorado por meio de versões, até que seja desenvolvido um sistema adequado.
As atividades de especificação, desenvolvimento e validação são intercaladas, em vez de
serem separadas, com feedback que permeia as atividades, conforme figura 2 .
 Figura 2: Desenvolvimento Evolucionário

Existem dois tipos fundamentais de desenvolvimento evolucionário:

• Desenvolvimento exploratório
• Desenvolvimento de protótipos descartáveis

2.1.4. Desenvolvimento Exploratório

Este modelo trabalha com o desenvolvimento da primeira versão do sistema o mais rápido
possível.
O modelo de desenvolvimento exploratório caracteriza-se por não terem o escopo bem
definido do sistema a ser desenvolvido. Dessa forma, a especificação é realizada de forma
intercalada ao desenvolvimento. Após a produção de cada versão é mostrado ao cliente para
comentários. Alterações são feitas até chegar a um sistema adequado. Um dos problemas desse
modelo é a ausência de sistema correto.

2.2.2.1. Aplicabilidade
Tem sido muito utilizado para o desenvolvimento de Sistemas Especialistas, no contexto da
Inteligência Artificial.
Exemplos:
• Sistemas de reconhecimento de voz;
• Sistemas de diagnóstico médico.

2.1.5. Desenvolvimento de protótipos descartáveis:

O objetivo desse modelo é entender os requisitos do sistema. Na primeira etapa desenvolve
um programa (protótipo) para o usuário experimentar. No entanto, esse protótipo deve ser
descartado e o software re-implementado, pode usar qualquer outro modelo.
 Tem sido utilizado para validar partes do sistema (Interface Gráfica e aspectos relacionados
à arquitetura – exemplo: performance, portabilidade).
No entanto, do ponto de vista da engenharia e do gerenciamento existem alguns problemas:
• Processo não é visível: sistemas rápidos, não é viável economicamente produzir
documentação a cada versão;
• Sistemas mal estruturados: mudanças constantes tende a corromper a estrutura do sistema.

2.1.5.1. Aplicabilidade
• Sistemas interativos pequeno ou médio porte;
• Para validar partes de grandes sistemas (Interface com o usuário);
• Para sistemas com pouco tempo de vida;
• Para resolver incertezas na especificação de requisitos de grandes sistemas pode usar
protótipos descartáveis.

2.2. Desenvolvimento baseado em reuso

Este modelo trabalha na sistemática do reuso de componentes existentes. A figura 3
ilustra os estágios deste modelo.

Figura 3 Desenvolvimento baseado em reuso

Pressman, 1995

Nos estágios de Análise de Componentes – a partir de uma especificação de requisitos,

faz-se uma busca pelos componentes para realizar a implementação dessa especificação.
Modificações de requisitos: neste estágio os requisitos são analisados, levando em
consideração os componentes existentes.
Projeto do sistema com reuso: neste estágio considera-se os componentes reusados,
organizando o framework para eles. As vezes é necessário que algum software seja
desenvolvido. Os estágios de especificação e validação são comparados a outros modelos.
 2.2.1. Vantagens
• Redução da quantidade de código a ser desenvolvida, consequentemente, reduz custos e
riscos;
• Entrega rápida do sistema.
Esta abordagem está se tornando uma das mais importantes, porém, ainda falta experiência.

2.4 Modelo de Transformação Formal

Este modelo trabalha através de uma definição matemática. O sistema é desenvolvido e
transformado em um programa executável conforme figura 4.
Figura 4: Modelo de Transformação Formal

Tem sido muito utilizado para o desenvolvimento de sistemas críticos, tais como sistemas no
qual o fator segurança é crítico.
Exemplo:
• Sistema para controle de tráfego aéreo.
Figura 5: A transformação formal:

Cada etapa acrescenta mais detalhes, mas ainda é matematicamente correta, até que a especi-
ficação formal seja convertida em um programa equivalente.

2.5 Modelos Iterativos

Durante o projeto de desenvolvimento de um sistema os requisitos sempre evoluem. Essa
iteração faz parte do processo de desenvolvimento. Significa que o processo de software não é de
execução única, suas atividades são repetidas à medida que o sistema precisa de sofrer alterações.
 Existem dois modelos de processo com o objetivo de apoiar nessas iterações.
1. Entrega incremental
2. Desenvolvimento espiral

2.5.1 Entrega Incremental

Esse paradigma combina as vantagens do modelo cascata e evolucionário. Na abordagem de
Entrega Incremental, em linha gerais, o cliente identifica os serviços a serem fornecidos pelo
sistema. Levando em consideração os serviços mais e menos importantes do software.
Dessa forma, define um número de incrementos a serem entregue fornecendo partes da
funcionalidade do sistema. É levando em consideração a prioridade do serviço, sendo entregue os
de maior prioridade.
A análise dos próximos requisitos para incrementos podem ser realizado em paralelo com o
desenvolvimento.
Após a entrega do primeiro incremento, o usuário terá parte da funcionalidade do sistema
para utilizar. Isso pode ajudar na definição dos incrementos posteriores.

2.5.1.1 Vantagens
• O cliente é beneficiado com partes da funcionalidade, podendo usar imediatamente;
• Esses incrementos pode servir como protótipos, e também como experiência para os
próximos requisitos;
• Menor probabilidade de riscos no projeto;
• Como trabalha com a ordem de prioridade de serviços, recebem uma atenção nos testes;
significa que há menor chance de encontrar erros nas partes mais importantes do sistema.

2.5.1.2 Desvantagens
• Os incrementos não devem ser grandes (mais ou menos 20 mil linhas de código), e cada
incremento deve entregar uma funcionalidade;
• Difícil definir os requisitos para cada incremento com tamanho adequado.

2.5.2 Desenvolvimento Espiral

Este modelo foi proposto por Boehm (1988). É representado com um espiral, onde cada fase
do processo é representado por um loop. Sendo que o loop mais interno está ligado à viabilidade do
sistema, o próximo à definição de requisitos, em seguida o desenvolvimento do sistema e assim por
diante. A figura 6 demonstra o modelo espiral.
Figura 6: Desenvolvimento Espiral

Cada loop está dividido em quatro setores:

1. Definição de requisitos: os objetivos do projeto são definidos.
• Restrições sobre o projeto e produto são definidos;
• Elaborado o plano de gerenciamento;
• Os riscos do projeto são identificados;
• Estratégias podem ser planejadas.
2. Avaliação e redução de riscos: para cada risco identificado, uma análise é feita e providências
podem ser tomadas com o objetivo de minimizar o risco.

Exemplo
• Riscos de requisitos – poderá desenvolver um protótipo do sistema.
3. Desenvolvimento e Validação: nesta parte escolhe o modelo de desenvolvimento conforme
a aplicação.
Exemplo
• Se os riscos da interface com o usuário forem dominantes – o modelo de prototipação seria o
mais adequado;
• Se os riscos de segurança constituírem a principal consideração – o ideal será o
desenvolvimento baseado em transformação;
 • Caso o principal risco encontrado for a integração de sistemas – o modelo mais apropriado
será o cascata.
4. Planejamento: esta etapa trabalha com a revisão de projeto, é verificado a possibilidade de
continuar, se a decisão for pelo prosseguimento, elabora os planos para a próxima fase do projeto.

2.5.2.1 Vantagens
• Possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do
sistema;
• Permite que o projetista e cliente possa entender e reagir aos riscos em cada etapa evolutiva.

2.5.2.2 Desvantagens
• Avaliação dos riscos exige muita experiência;
• O modelo é relativamente novo e não tem sido amplamente utilizado.
3. GERENCIAMENTO DE PROJETO
O gerenciamento de projeto é parte fundamental no processo da Engenharia de Software.
Um bom gerenciamento não é uma garantia que não ocorrerá problemas no desenvolvimento do
projeto. Porém, um mal gerenciamento ou a falta dele oferece alta possibilidade de resultar em
falhas: atraso no cronograma, estou no custo estimado, muitas vezes não atende aos requisitos.
O desenvolvimento de planos e cronogramas do projeto é de responsabilidade do engenheiro
de software. Tem a função de supervisionar o trabalho para assegurar que está sendo realizado
dentro dos padrões estabelecidos e monitorar o progresso quanto ao tempo, custos, etc.
O trabalho do gerente de projeto de software é assegurar o desenvolvimento do software
dentro dos padrões e que contribua para que a empresa que está desenvolvendo atinja suas metas.
Os gerentes de projeto de software realizam o mesmo trabalho que os gerentes de outras
engenharias. No entanto, uma série de fatores as diferencia. Essas distinções tornam o
gerenciamento de software particularmente difícil. Algumas diferenças são:
1. O produto é intangível: na construção de um navio, o gerente de projeto pode ver a
construção. Por exemplo: caso o cronograma atrasa, o efeito do produto é visível, ou seja,
parte da construção não esta pronta.
2. Não existem processo-padrão de software: as engenharias ao longo dos anos, consolidou
suas atividades, ou seja, o processo já é experimentado e testado.
Exemplo:
o processo de engenharia de construção de pontes, prédios já são bem definidos e
compreendidos. Enquanto
3. Projetos de software de grande porte – projetos “únicos”: os projetos de grande porte,
geralmente, são diferentes de anteriores. Dessa forma, mesmo gerentes com experiência
pode encontrar dificuldades em prever problemas. Outro fator agravante está no fato de
mudanças nas tecnologias, o que pode tornar a experiência do gerente obsoleta. Ou seja,
experiência em projetos anteriores podem não serem aproveitadas em novos projetos.

3.1 Atividades de Gerenciamento

Não há uma descrição de trabalho-padrão para o engenheiro de software. Depende da
organização e do software que está sendo desenvolvido. Porém, existem algumas atividades que são
adotadas por uma grande parte dos gerentes:
• Elaboração da proposta
• Planejamento e desenvolvimento do cronograma
• Custo do projeto
• Monitoração e revisão do projeto
 • Seleção e avaliação do pessoal
• Elaboração de relatórios e apresentação

A elaboração da proposta para obter um contrato para realizar o trabalho pode ser
considerado o primeiro estágio do projeto. A proposta deve conter os objetivos do projeto, e como
será realizado. Inclui também a estimativa de custos e cronograma, justifica porque o contrato deve
ser concedido aquela organização para realizar o trabalho.
Trata-se de uma tarefa um pouco complexa, pois muitas organizações de desenvolvimento
de software depende de um número significativo de contratos, e pode não haver diretrizes bem
definidas para realizar tal tarefa.
O planejamento do projeto tem a finalidade de identificar as atividades, marcos e produtos
gerados em um determinado projeto e a estimativa de custos está relacionada à estimativa de
recursos necessários. Enquanto, a monitoração é uma atividade contínua.
O gerente tem a responsabilidade de acompanhar o progresso do projeto e
comparar os custos reais e o que foi estimado.
Geralmente, as organizações possuam meios formais para monitorar o projeto,
trata-se de uma forma importante nesse processo de gerenciamento. Porém, é interessante também
utilizar discussões informais e verificar o que está acontecendo no desenvolvimento do projeto. A
monitoração informal pode prever potenciais problemas ou revelar dificuldades diárias, o que pode
trazer bons resultados na prevenção de problemas maiores futuramente, auxiliando assim, o gerente
na proposição de alternativas à medida que os problemas são identificados, em vez de aguardar que
um atraso significativo no cronograma seja relatado.
No desenvolvimento de um projeto, é normal que ocorra as revisões formais, pois
estão relacionadas à revisão geral do progresso e o desenvolvimento técnico do projeto, e a
verificação se as metas da organização financiadora estão alinhadas.
O resultado de uma revisão pode levar à decisão de cancelar ou não um projeto.
Exemplo: um projeto de grande porte pode levar vários anos para ser construído, e no decorrer
desse tempo os objetivos dessa organização podem sofrer modificações. Essas mudanças podem
implicar em novas metas, ou seja, o software não atende mais as necessidades da organização.
Devendo assim, decidir pela interrupção do projeto ou alterá-lo de forma que venha atender aos
atuais objetivos.
Outro fator importantes no processo de desenvolvimento de um projeto é a equipe
que irá trabalhar, dessa forma, os gerentes precisam montar as equipes para trabalhar nos projetos.
Os gerentes precisam montar essa equipe, o ideal é que haja pessoas com habilidades adequada
para trabalhar no projeto. Porém, muitas vezes os gerentes precisam montar a equipe aquém do
considerado ideal, isso ocorre por várias razões:
• O orçamento pode ser insuficiente para contratar uma equipe bem remunerada. Sendo assim,
necessário contratar uma equipe menos experiente com um custo menor;
• Pode não ter disponível interno ou externo uma equipe com experiência adequada, pois
essas pessoas podem estarem alocadas em outros projetos.
• A organização pode querer desenvolver as habilidades de seus funcionários. Ou seja, pode
designar uma equipe inexperiente para um determinado projeto a fim que possam aprender e
ganhar experiencia.

Os gerentes tem a responsabilidade dentro dessas restrições e montar a equipe para

o desenvolvimento do projeto. Tem a função ainda de preparar os relatórios e apresentações para a
organização contrante.

3.2 Planejamento de Projeto

O gerenciamento de um projeto de software depende de um planejamento
minucioso do progresso do projeto. O plano elaborado no início do projeto deve ser usado como
guia. Deve ser o mais detalhado possível diante das informações disponíveis, e com característica
dinâmica, ou seja, deverá ser constantemente atualizado à medida que informações mais precisas se
tornem disponíveis. A figura 7 demonstra alguns tipos de planos.

Figura 7: Tipos de Planos

 Enquanto o pesudocódico estabelece um processo de planejamento de projeto para
desenvolvimento de software. Demonstra que o planejamento é um processo iterativo, só é
concluído quando o próprio projeto for finalizado.
Figura 8: Planejamento do projeto

3.3 Plano de Projeto

O plano de projeto estabelece os recurso disponíveis para o projeto, a estrutura analítica e o
cronograma para a realização do trabalho. A seguir serão descritos algumas seções que podem ser
incluídas no plano:
1. Introdução: deve conter os objetivos do projeto e suas restrições. Exemplo: orçamento,
prazo, ou seja, o que afeta o gerenciamento do projeto.
2. Organização do projeto; descreve a organização da equipe. Exemplo: as pessoas
envolvidas e os seus papéis dentro da equipe.
3. Análise de risco: deve relatar os possíveis riscos do projeto, a probabilidade de sua
ocorrência e as propostas de redução dos mesmos.
4. Requisitos de recursos de hardware e software: especificar o hardware e software de
apoio necessário para desenvolver o projeto. Caso precise comprar – deve ser incluídos
nas estimativas de preço e prazos de entrega.
5. Estrutura analítica: estabelecer a estrutura analítica do projeto em atividades –
identificar os marcos e os produtos a serem entregues.
6. Cronograma do projeto: apresentar as dependências entre as atividades, o prazo
estimado para alcançar cada marco e a alocação de pessoas nas atividades.
7. Mecanismos de monitoração e elaboração de relatórios: definir quais relatórios de
gerenciamento deve ser produzidos e quando devem serem produzidos.
O gerente deve revisar regularmente o plano durante o projeto, pois algumas partes
mudarão como cronograma e outras permanecerão mais estáveis.
3.4 Marcos e Produtos a serem Entregues
Os gerentes precisam de informações para realizar o seu trabalho. Como falado
anteriormente o software é um produto intangível, dessa forma, as informações são fornecidas
através de relatórios e documentos que descrevem o estado em que o software se encontra.
Sem essas informações é impossível avaliar o progresso do sistema, se as estimativas de
custos e cronograma estão atualizadas e assim por diante.
Ao planejar um projeto, o gerente deve estabelecer uma série de marcos. Um marco é um
ponto final de uma determinada atividade do processo de desenvolvimento de software.
A cada marco deve ter uma saída formal, exemplo: um relatório que pode ser apresentado à
gerência. No entanto, marcos do tipo, “codificação 80% concluída”, são inúteis. Pois, não tem como
o gerente avaliar o processo de software.
Um produto é o resultado de um projeto entregue ao cliente. Geralmente, ocorre ao final de
alguma fase importante do projeto, como a especificação ou design.
Observação
Os produtos são geralmente, marcos, mas os marcos não precisam ser produtos.
Os marcos podem ser resultados internos do projeto usados pelo gerente para verificar o
progresso, embora não sejam entregues ao cliente.
A figura 9 mostra as possíveis atividades envolvidas na especificação de requisitos. Os
marcos, neste caso, correspondem à finalização das saídas de cada atividade. Os produtos do projeto
entregues ao cliente são a definição e a especificação de requisitos.

Figura 9: Marcos no processo de requisitos

3.5 Cronograma do Projeto
A elaboração do cronograma do projeto é uma das tarefas mais difíceis para um gerente de
projeto. Os gerentes devem estimar o tempo e os recursos necessários para o desenvolvimento das
atividades, deve ainda organizá-la em uma sequência coerente. É importante que o cronograma seja
constantemente atualizado à medida que novas informações sobre o projeto seja disponibilizada.
O desenvolvimento do cronograma de projeto envolve divisão do trabalho em atividades
separadas e a avaliação do tempo necessário para realizar cada atividade, conforme demostra a
figura 10.
Figura 10: Processo de desenvolvimento do cronograma do projeto

Algumas atividades podem ser realizadas simultaneamente. Dessa forma, deve coordenar as
atividades paralelas e organizar de maneira qeu a força de trabalho seja otimizada. Os gerentes
devem evitar que todo o projeto fique parado devido uma tarefa critica que ainda não foi concluída.
Sommerville (2007), destaca que as atividade de projeto devem durar pelo menos uma
semana e no máximo de 8 a 10 semanas. Caso leve mais tempo, deverá ser subdividida para o
planejamento e realização do cronograma.
Ao estimar os cronogramas, o gerente deverá levar em consideração possíveis problemas.
Exemplo:
• Pessoas que trabalham no projeto podem ficar doentes; ou podem sair do projeto;
• hardware pode apresentar defeitos;
• As tecnologias de apoio como hardware e software podem ser entregues com atraso, etc.

Uma das regras que pode ser utilizada é fazer a estimativa com se nada fosse dar errado e,
então, aumentar a estimativa para cobrir problemas não previstos.
Por exemplo:
• Adicionar 30 % a estimativa original para problemas não previstos e, em seguida, mais 20 %
para cobrir outros aspectos. Tudo deve levar em consideração o tipo de projeto que será
desenvolvido.
Os cronogramas do projeto são geralmente, representados como um conjuto de diagramas
que apresentam a estrutura analítica, as dependências de atividades e as alocações de pessoal.

3.6 Diagramas de Barras e Redes de Atividades

Os diagramas de barras e as redes de atividades são representações gráficas que podem ser
utilizadas para ilustrar o cronograma do projeto.
Os diagramas de barras tem a finalidade de mostrar quem é o responsável por cada atividade
e quando estão previstas para começarem e terminar. E as redes de atividades mostram as
dependências do projeto. A tabela 2 mostra as atividades, sua duração e as interdependências.
Tabela 2: Duração e dependências de tarefas

Ao observar a tabela 2 constata-se que a atividade T3 é dependente da T1. Significa que a

atividade T3 deverá ser iniciada somente que a tarefa T1 estiver concluída.
Observação
T1 – pode ser a preparação de um projeto de componente;
T3 – a implementação desse componente.
Antes da implementação o projeto dever estar concluído.
 Em face das dependências e das durações estimadas das atividades, um diagrama de
atividades pode ser gerado (figura 11). Observa quais atividades podem ser geradas
simultaneamente e quais devem ser executadas em sequência devido a dependência da conclusão de
atividades anteriores.
Observação
• As atividade são representadas por retângulos;
• Os marcos e produtos – retângulos de cantos arredondados;

As datas desse diagrama mostra a data de início, deve ser lido da esquerda para a direita e de
cima para baixo.
Deve-se começar o desenvolvimento de um marco somente quando todos os caminhos que
levam até ele estivem sido concluídos. Exemplo: Quando as atividades T3 e T6 forem terminadas,
assim pode iniciar a atividade T9, conforme figura 11.
O tempo mínimo necessário para terminar o projeto pode ser estimado levando em
consideração o caminho mais longo no gráfico de atividades (caminho crítico). Neste exemplo,
corresponde a 11 semanas ou 55 dias de trabalho.
Na figura 11 o caminho crítico é representado por uma sequência de retângulos com
contorno em negrito. O caminho crítico é composto pela sequência de atividades dependentes
que irá definir o tempo necessário para a realização do projeto. Atraso em qualquer atividade
do caminho crítico pode causar atraso no projeto, pois as próximas atividades só poderão serem
iniciadas quando a atividade em atraso estiver concluída.
Contudo, atrasos que ocorrem em atividades que não fazem parte do caminho crítico,
provavelmente, não causará atrasos no cronograma do projeto. Se T8 atrasar por duas semanas, não
irá afetar a data de término do projeto, pois não está no caminho crítico.
Figura 11: Processo de desenvolvimento do cronograma do projeto

A figura 12 é uma forma de representar informações de cronograma do projeto. É um

diagrama de Gant, que vem mostrar um calendário de projeto com as datas de início e fim de cada
atividade.
Observa-se que algumas atividades são seguidas por uma barra sombreada. Isso demonstra a
flexibilidade da data de término destas atividades. Caso uma atividade não seja realizada em tempo,
o caminho crítico não será afetado até o final da data indicada pela barra sombreada. Enquanto, as
atividades do caminho crítico não há margem de erro e não possuem barras sombreadas.

Figura 12: Diagrama de barras de atividades

 Além, dos cronogramas, os gerentes também devem levar em consideração a alocação de
recursos, em particular de pessoal. A figura 13 mostra essa alocação de pessoal e quando é
designado ao projeto.
Observa-se que as pessoas não precisam estar designadas a um determinado projeto o
tempo integral. Em alguns períodos podem estar trabalhando em outros projetos, passando por
cursos de treinamento, de férias, etc.
Podem também ter especialistas em um projeto, se necessário. Na figura 13, Jim e Mary
são especialistas e executa uma única tarefa no projeto. Isso pode causar uma série de problemas no
cronograma, exemplo:
• Se um projeto atrasar, enquanto o especialista esta trabalhando nele – pode afetar outros
projetos;
• Ou pode haver atrasos porque o especialista não está disponível.

Figura 13: Alocação de pessoal

3.7 Gerenciamento de Riscos

O gerenciamento de riscos pode ser considerado uma das principais atividades do gerente de
projetos. Consiste em prever os possíveis riscos que podem ocorrer e consequentemente afetar o
cronograma do projeto ou a qualidade do software, deve-se então tomar providências para evitar ou
minimizar esses riscos.
Os riscos pode vir a afetar o projeto, o software ou a organização. Existem portanto, três
categorias de riscos:
1. Riscos de projeto: relacionados aos riscos que afetam o cronograma ou os recursos de
projeto.
Exemplo:
• Perda de um projetista experiente
2. Riscos de produto: está ligado aos riscos que afetam diretamente a qualidade ou o
desempenho do software que está sendo desenvolvido.
Exemplo
• Um componente comprado pode não funcionar conforme o esperado.
3. Riscos de negócio: são aqueles riscos que podem afetar a organização que desenvolve ou
adquire o software.
Exemplo
• O lançamento de um produto pelo concorrente.

Naturalmente, esses tipos de riscos se sobrepõem. Exemplo: Se um programador experiente

deixa o projeto, pode caracterizar um risco de projeto, pois a entrega pode atrasar. Porém,
pode também ser um risco de produto, um vez que o substituto deste projetista pode ser menos
experiente e cometer erros de programação e finalmente, um risco de negócio, pois, a habilidade do
programador talvez não possa ser aproveitada em negócios futuros.
A tabela 3 ilustra alguns dos riscos mais comuns:

O gerenciamento de riscos torna-se importante devido as incertezas que rondam a maior

parte dos projetos. Os mesmos ocorrem devido a vários fatores como: requisitos mal
compreendidos, dificuldades na estimativa de prazos e recursos de apoio, dependência de
habilidades individuais e outros. Dessa forma, é necessário prever os riscos, compreender o seu
impacto e tomar providências para evitá-los. Pode ser necessário planos de contingência para tomar
providências, caso os ricos ocorram. O processo de gerenciamento de riscos está ilustrado na figura
14, envolvendo vários estágios:
1. Identificação dos riscos: os possíveis riscos de projeto, produto e negócio são
identificados.
2. Análise de riscos: são analisados a probabilidade e suas consequências.
3. Planejamento de riscos: são elaborados planos de estratégias para evitá-los ou
minimizar seus efeitos.
4. Monitoração de riscos: riscos são avaliados constantemente a medida que mais
informações se tornem disponíveis.

O processo de gerenciamento de riscos, é um processo iterativo durante o decorrer de todo o

projeto. Elaborado o plano inicial, deve ser constantemente monitorado e atualizados.

Identificação de Riscos

O primeiro estágio no gerenciamento de riscos é a identificação de riscos relacionado a

descoberta de possíveis riscos.
A identificação de riscos pode ser realizada como um processo em equipe, usando uma
abordagem de brainstorming ou simplesmente ser baseado na experiencia. Pode utilizar-se um
checklist de diferentes tipos de riscos. A seguir alguns dos riscos que podem surgir.
1. Riscos de tecnologia: derivados de tecnologia de hardware e software para o
desenvolvimento de sistemas;
2. Ricos de pessoal: associados às pessoas da equipe de desenvolvimento.
3. Riscos organizacionais: derivados da organização desenvolvedora do sistema;
4. Riscos de ferramentas: são aqueles derivados de ferramentas Case e outros softwares de
apoio;
5. Riscos de requisitos: são derivados de mudanças de requisitos e do processo de
gerenciamento dessa mudança;
6. Riscos de estimativas: derivam das estimativas de gerenciamento e recursos para construir o
sistema.
A tabela 4 apresenta alguns exemplos de possíveis riscos em cada uma dessas categorias:

Após identificar os riscos, deve-se elaborar uma lista de quais riscos podem ocorrer e quais
podem afetar o produto, o projeto e o negócio.

Análise de Riscos
No processo de análise de riscos, deverá considerar cada risco identificado e avaliar sua
probabilidade e seriedade. Essas estimativas não precisam necessariamente ser avaliações
numéricas precisas, mas devem basear-se em um número de faixas:

A probabilidade do risco deve ser avaliada como:

• muito baixa (<10%)
• baixa (10 – 25%)
• média (25 -50%)
• alta (50 – 75%)
• muito alta (>75%)
 Os efeitos do risco podem ser avaliados como:
• catastróficos
• sérios
• toleráveis
• insignificantes

Deve, portanto, computar os resultados desse processo de análise de acordo com a gravidade do
risco. A tabela 5 faz essa ilustração em relação aos riscos identificados na tabela 4. Obviamente, a
avaliação de probabilidade e seriedade é arbitrária neste caso. Na prática, para realizar esta
avaliação, precisa-se de informações detalhadas sobre o projeto.

Tabela 5: Análise de riscos

Risco Probabilidade Efeitos
Problemas financeiros da organização forçam redução no orçamento Baixa Catastróficos
do projeto
É possível recrutar pessoal com as habilidades necessárias para o Alta Catastróficos
projeto
O banco de dados usado no sistema não pode processar tantas Média Sérios
transações por segundo como esperado
O tempo necessário para desenvolver o software foi subestimado Alta Sérios
As ferramentas Case não podem ser integradas Alta Toleráveis
O treinamento necessário para o pessoal não está disponível Média Toleráveis
Os componentes de software que devem ser reusados contêm defeitos Média Sérios
que limitam sua funcionalidade

Naturalmente, tanto a probabilidade quanto a avaliação dos efeitos podem mudar, a medida
que mais informações sobre os riscos tornarem-se disponíveis. Após realizar a etapa de análise e
classificação dos riscos, deve avaliar quais os riscos mais significativos. Essa avaliação deve
depender da combinação da probabilidade da ocorrência do risco e de seus efeitos. Em geral, riscos
catastróficos devem sempre ser considerados, assim como todos os riscos sérios que tenham
probabilidade de ocorrência acima da média.
Boehm (1988), recomenta identificar e monitorar os '10 maiores' riscos, no entanto depende do
projeto. Um número muito grande de riscos exigirá que muitas informações sejam coletadas.
 Planejamento de Riscos
O processo de planejamento de riscos considera cada um dos riscos importantes
identificados e define estratégias para gerenciá-los. A tabela 6 mostra as possíveis estratégias
identificadas para os riscos principais da Tabela 5.
Essas estratégias dividem-se em três categorias:
1. Estratégias de prevenção: significa que a probabilidade de que o risco ocorrerá será
reduzido.
Um exemplo de uma estratégia de prevenção de riscos é lidar com componentes defeituosos, como
mostrado na Tabela 5.
2. Estratégias de minimização: significa que o impacto do risco será reduzido.
Um exemplo de estratégia de minimização de riscos é de doença entre o pessoal da equipe na
Tabela 5..
3. Planos de contingência: significa que a organização esta preparada para o pior e tem uma
estratégia para resolver o problema.
4. Um exemplo de plano de contingência é a estratégia para problemas financeiros apresentado
na Tabela 5.

Tabela 6: Estratégias de gerenciamento de riscos

Problema financeiros da
organização
Problemas de recrutamento
Doença do pessoal da equipe Reorganizar a equipe de maneira que haja mais superposição de
Componente com defeito
Mudanças de requisitos
Desempenho do banco de
dados
Preparar um documento de instruções para a gerência sênior, que
mostre como o projeto está contribuindo de maneira muito
importante para as metas da empresa.
Alertar o cliente sobre as dificuldades potenciais e a possibilidade
de atrasos; investigar a compra de computadores.
trabalho e, portanto, as pessoas compreendem as tarefas uns dos
outros.
Substituir os componentes potencialmente defeituosos por
componentes comprados e de confiabilidade reconhecida.
Derivar informações de rastreabilidade para avaliar o impacto das
mudanças de requisitos e maximizar o ocultamento de informações
no projeto.
Verificar a possibilidade de comprar um banco de dados com
desempenho melhor.
 Monitoração de Riscos

A monitoração de riscos envolve a avaliação constante de cada um dos riscos identificados

para decidir está se tornando possível de acontecer e se os efeitos do risco sofreu algum tipo de
mudança. Alguns fatores fornecem subsídios a respeito da probabilidade do risco e seus efeitos.
Esses fatores são obviamente dependentes do tipo de risco. A tabela 5.7 apresenta alguns exemplos
de fatores que podem ser úteis na avaliação desses tipos de riscos.

Tabela 7: Fatores de risco

Tecnologia Entrega de hardware ou software de apoio com atraso.
Pessoal Baixo moral do pessoal, relacionamentos precários entre os membros
da equipe, disponibilidade de emprego.
Organizacional Boatos na organização, falta de ação da gerência sênior
Ferramentas Relutância dos membros da equipe em usar ferramentas, reclamações
sobre ferramentas Case, demandas por estações de trabalho mais
poderosas.
Requisitos Muitas solicitações de mudanças de requisitos, reclamações do cliente.
Estimativas Falha no cumprimento do cronograma, falha em eliminar defeitos
relatados.

A monitoração de riscos deve ser um processo contínuo e, a cada revisão de progresso

realizada pela gerência, é necessário considerar e discutir cada um dos principais riscos
separadamente.

Pontos-chave
Um bom gerenciamento é essencial para sucesso do projeto.

A natureza intangível do software causa problemas para o gerenciamento.

Gerentes têm papéis diversos, mas suas atividades mais significantes são planejamento, elaboração
de estimativas e desenvolvimento de cronograma.

Planejamento e elaboração de estimativas são processos iterativos que continuam ao longo do curso
de um projeto.