ENGENHARIA DE SOFTWARE

FACULDADE CENECISTA DE VARGINHA

FACECA

Apostila 1
2008

Prof. Paulo Roberto Rodrigues de Souza

 ENGENHARIA DE SOFTWARE

INTRODUÇÃO

Em se tratando de disciplina técnica e de formação, a Engenharia de Software no curso tem

o desafio de desmistificar esta difícil tarefa do profissional de tecnologia que é a complexa atividade de
desenvolvimento e manutenção de softwares. Por natureza de formação e/ou por praticidade, este
profissional tem o hábito de partir para a codificação de um software com poucos indícios das
necessidades do cliente, isso tem levado à falta de credibilidade e ao insucesso por parte de vários
profissionais.
É isso basicamente nosso objeto de estudo e desafio, identificar as necessidades dos clientes e
trabalhá-las de modo que possamos estar atendendo suas necessidades com o menor tempo
possível, mantendo-se a qualidade esperada com o menor esforço e é claro, utilizando-se das
técnicas e recursos da Engenharia de Software. Com certeza iremos sair modificados desta
discussão.
Bom trabalho à todos!!!

Prof. Paulo Roberto R. de Souza

Pg. 2
 ENGENHARIA DE SOFTWARE
CONCEITOS BÁSICOS

Software: É o produto que os profissionais de software(programadores, engenheiros, analistas e

outros) desenvolvem e mantêm ao longo do tempo. Abrange os programas de computador, a
documentação e os dados usados na execução correta destes programas. Existem vários tipos de
software que podem fazer as mais variadas tarefas.
Sistema: É um grupo de componentes que trabalham em conjunto tentando alcançar um objetivo
comum, esta definição é bem abrangente e pode ser usada para qualquer tipo de sistema. Existem
outros tipos de sistema como o biológico do corpo humano, sistema solar, sistema de informação e
outros. Um sistema de informação, que é o que importa pra nós, é um conjunto de programas de
computador, equipamentos, pessoas, procedimentos e outros componentes que são usados para
gerar informação. Um software faz parte de um sistema, mas ele sozinho nem sempre é um sistema.
Programa de computador: Um programa de computador é um conjunto de instruções que
descrevem uma tarefa a ser realizada por um computador. O termo pode ser uma referência ao código
fonte, escrito em alguma linguagem de programação, ou ao arquivo que contém a forma executável
deste código fonte. Um programa na realidade é um software sem sua especificação, documentação,
manual e outros componentes.

Usuário: São pessoas que usam algum tipo de serviço, neste caso, serviços de informação. Os
usuários em sistemas de informação são aqueles que usam a tecnologia para fazer algum trabalho.

Engenharia: É a atividade onde os conhecimentos científicos e técnicos e a experiência prática são

usados para explorar os recursos naturais, para o projeto, construção e operação de objetos úteis.
Engenharia de Software. É uma disciplina que se ocupa com todos os aspectos envolvidos na
produção de software, desde os estágios iniciais, onde se busca conhecer o que o sistema precisa
fazer(especificação), passando por sua construção até a manutenção deste sistema em
funcionamento.
Conceito
Engenharia de software é uma área da informática voltada para a especificação, desenvolvimento e
manutenção de sistemas de software usando tecnologias e práticas de sistemas de informação,
gerência de projetos e outras disciplinas, buscando a organização, produtividade e qualidade, usando
disciplina e métodos bem definidos.

Algumas Características do Software

- Desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico.

Ex: Uma cadeira ou uma mesa são exemplos de manufatura no sentido clássico, ou seja, junta-
se partes para se “fabricar uma cadeira ou mesa”, um software é algo bem mais complexo, cada
software é diferente do outro, ainda há aspectos como local de funcionamento do software, público
atendido, hardware e estrutura de comunicação e rede disponível, etc...

- O software não se desgasta mas se deteriora.

- A maioria é feita sob medida em vez de ser montada a partir de componentes existentes.

Evolução do Software
(1950 - 1965) hardware: contínuas mudanças; software: arte "secundária"; hardware de propósito
geral; software específico para cada aplicação; não havia documentação
(1965 - 1975) Multiprogramação e sistemas multiusuários; técnicas interativas; sistemas de tempo
real; 1a geração de SGBD’s; produto de software; bibliotecas de Software; cresce no de sistemas
baseados em computador; manutenção quase impossível crise de software
(1975 - hoje) Sistemas distribuídos; Redes locais e globais; uso generalizado de microprocessadores -
produtos inteligentes; hardware de baixo custo; impacto de consumo CRISE DE SOFTWARE
(aflição crônica???)

Prof. Paulo Roberto R. de Souza

Pg. 3
 ENGENHARIA DE SOFTWARE

(Quarta era do software: atualidade) Tecnologias orientadas a objetos; Sistemas especialistas e

software de inteligência artificial usados na prática; Computação Paralela; Internet

Aplicações emergentes (2000  ...)

 Tecnologias orientadas o objetos

 Sistemas especialistas e software de inteligência artificial usados na prática
 Software de rede neural artificial
 Computação Paralela
 Internet

Crise de Software – Alguns problemas encontrados e causas da dificuldade do desenvolvimento

de software:

1) Estimativas de prazo e de custo freqüentemente são imprecisas

“Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software”. “Sem
nenhuma indicação sólida de produtividade, não podemos avaliar a eficácia de novas ferramentas,
métodos ou padrões”.

2) A produtividade das pessoas da área de software não tem acompanhado a demanda por seus
serviços
“Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago
indício das exigências do cliente”

3) A qualidade de software às vezes é menos que adequada. Só recentemente começam a surgir

conceitos quantitativos sólidos de garantia de qualidade de software

4) O software existente é muito difícil de manter

Manutenção devora o orçamento destinado ao software. A facilidade de manutenção não foi
enfatizada como um critério importante

5) Próprio caráter do Software - software é um elemento de sistema lógico e não físico.

Conseqüentemente, o sucesso é medido pela qualidade de uma única entidade e não pela qualidade
de muitas entidades manufaturadas. O software não se desgasta, mas se deteriora!!!

6) Falhas das pessoas responsáveis pelo desenvolvimento de Software

7) Gerentes sem nenhum background (experiência) em desenvolvimento de software. Os

profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o
desenvolvimento de software. Resistência a mudanças.

Alguns mitos do desenvolvimento de Software que causam problemas:

 Administrativos
Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso não
oferecerá ao meu pessoal tudo o que eles precisam saber?
Realidade:
Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal lhes
 Seráos
compramos que o manual
mais é usado?
novos computadores.
 Os profissionais sabem que ele existe?
Realidade:
 Ele reflete a prática moderna de desenvolvimento de software?
 É Elepreciso muitoÉ mais
é completo? do que os mais recentes computadores para se fazer um
atualizado?
Prof. Paulo
desenvolvimento de software de altaRoberto R. de Souza
qualidade.
Pg. 4
 ENGENHARIA DE SOFTWARE

Se nós estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso.

Realidade:
 O desenvolvimento de software não é um processo mecânico igual à manufatura.
 Acrescentar pessoas em um projeto torna-o ainda mais atrasado. Pessoas podem ser
acrescentadas, mas somente de uma forma planejada.

 Do Cliente
Uma declaração geral dos objetivos é suficiente para se começar a escrever programas - podemos
preencher os detalhes mais tarde.

Realidade:
 Uma definição inicial ruim é a principal causa de fracassos no desenvolvimento de
software.
 É fundamental uma descrição formal e detalhada do domínio da informação, função,
desempenho, interfaces, restrições de projeto e critérios de validação.

Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente

acomodadas, porque o software é flexível.

Realidade:
 Mudanças no projeto tardiamente podem provocar graves problemas no
desenvolvimento, assim como, o não cumprimento dos prazos estabelecidos;
 Há um momento chamado “ponto de congelamento” onde após este momento,
alterações no projeto devem ser maximamente evitadas, exceto em casos de estrema
necessidade;
 Quanto mais tarde as alterações forem solicitadas, maiores serão os prejuízos para o
desenvolvimento.

Custos X Magnitude das mudanças / alterações

FASE DA MUDANÇA OU ALTERAÇÕES CUSTO DE MANUTENÇÃO

Definição 1X
Desenvolvimento 1.5 a 6X
Manutenção 60 a 100X

Ou seja, de acordo com a tabela acima, pudemos perceber que quanto mais tarde a alteração, maior
será seu custo para o projeto total.

 Do Profissional
Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará
completo.

Realidade:
 Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa
serão despendidos depois que ele for entregue pela primeira vez ao cliente.
Prof. Paulo Roberto R. de Souza
Pg. 5
 ENGENHARIA DE SOFTWARE

Enquanto não tiver o programa "funcionando", eu não terei realmente nenhuma maneira de avaliar sua
qualidade.

Realidade:
 À cada etapa do desenvolvimento do software é possível verificar e aferir sua qualidade.
Principalmente no que se refere à conformidade com os requisitos, que é um critério de
qualidade.

Prof. Paulo Roberto R. de Souza

Pg. 6
 ENGENHARIA DE SOFTWARE
CICLOS DE VIDA

A Engenharia de Software abrange um conjunto de três elementos fundamentais:

Métodos, Ferramentas e Procedimentos

1) Métodos:
Métodos proporcionam os detalhes de como fazer para construir o software

A Engenharia de Software tem algumas etapas importantes no que se refere ao desenvolvimento de

um software:

Planejamento e estimativa de projeto

Análise de requisitos de software e de sistemas
Projeto da estrutura de dados
Algoritmo de processamento
Codificação
Teste
Manutenção
2) Ferramentas:
Ferramentas dão suporte automatizado aos métodos.
Existem atualmente ferramentas para sustentar cada um dos métodos
Quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de
software chamado CASE - Computer Aided Software Engineering
3) Procedimentos:
Procedimentos constituem o elo de ligação entre os métodos e ferramentas
Seqüência em que os métodos serão aplicados
Produtos que se exige que sejam entregues
Controles que ajudam assegurar a qualidade e coordenar as alterações
Marcos de referência que possibilitam administrar o progresso do software.

Portanto:

Engenharia de Software tem conjunto de etapas que envolvem: métodos, ferramentas,

procedimentos. Essas etapas são conhecidas como componentes de CICLO DE VIDA DE
SOFTWARE ou Processo de Software

Para a escolha de um Ciclo de Vida de Software devemos verificar:

Natureza do projeto e da aplicação;

Métodos e ferramentas a serem usados;

Controles e produtos que precisam ser entregues;

Área de negócio que deverá ser informatizada e experiência do cliente também são informações
relevantes.

Prof. Paulo Roberto R. de Souza

Pg. 7
 ENGENHARIA DE SOFTWARE
CICLOS DE VIDA
Ciclos de vida são modalidades que escolhemos para o desenvolvimento do software. Estes
ciclos podem variar dependendo do ambiente em que se irá desenvolver o software, assim como,
também podem ser escolhidos dependendo da aplicação e do cliente a ser atendido, com relação à
área de desenvolvimento e experiência deste cliente com tecnologia.

1) Ciclo de Vida Clássico (Cascata)

Modelo mais antigo e o mais amplamente usado da engenharia de software.
Modelado em função do ciclo da engenharia convencional.
Requer uma abordagem sistemática, seqüencial do desenvolvimento de software.
É um ciclo que mais se aproxima do desenvolvimento casual, sob o ponto de vista de seqüência das
ações.

Fases do Ciclo de Vida Cascata

1. ANÁLISE E ENGENHARIA DE SISTEMAS

Envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto
nível.
• Visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas
e banco de dados)
• Nesta etapa levantamos os requisitos de uma forma geral, ampla, ou seja, descrevemos aqui o
que o software deve conter, o que ele irá solucionar, qual são seus objetivos principais.

2. PROJETO

• Tradução dos requisitos do software para um conjunto de representações que podem ser
avaliadas quanto à qualidade, antes que a codificação se inicie. É o “desenho” do software,
montamos um projeto de modo que já possamos visualizar como ele será (imagine uma planta
baixa de uma casa).
• Se concentra em 4 atributos do software: Estrutura de Dados, Arquitetura de Software, Detalhes
Procedimentais e Caracterização de Interfaces
• Definimos o que será desenvolvido?
Análise do Sistema: define o papel de cada elemento num sistema baseado em computador
(hardware, software, banco de dados, procedimentos, documentação, pessoas), atribuindo em
última análise, o papel que o software desempenhará.
Planejamento do Projeto de Software: assim que o escopo do software é estabelecido, os riscos são
analisados (que situações colocam em risco o projeto em si?), os recursos são alocados (o que é
necessário? Quando, Onde? Quanto?), os custos são estimados e, tarefas e programação de
trabalho são definidas.

3. CODIFICAÇÃO

Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções
executáveis pelo computador. É a codificação propriamente dita.

4. TESTES

Os testes concentram-se:

Nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas.

Prof. Paulo Roberto R. de Souza

Pg. 8
 ENGENHARIA DE SOFTWARE
Nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza
resultados que concordem com os esperados. (telas, interfaces, etc)

Há algumas técnicas de teste que iremos detalhar no decorrer de nossa disciplina.

5. MANUTENÇÃO

O software poderá sofrer mudanças depois que for entregue ao cliente.

A manutenção concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para
uso operacional

As manutenções podem ser:

Corretivas: mesmo com as melhores atividades de garantia de qualidade de software, é provável que
o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir
defeitos.
Adaptativas: com o passar do tempo, o ambiente original (por exemplo a CPU, o sistema operacional
e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção
adaptativa muda o software para acomodar mudanças em seu ambiente.
De Melhoramento Funcional: a medida que o software é usado, o cliente/usuário reconhecerá
funções adicionais que oferecerão benefícios.

Problemas com o Ciclo de Vida Clássico

Projetos reais raramente seguem o fluxo seqüencial que o modelo propõe

Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre
existe uma incerteza natural
O Cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa
avançada do desenvolvimento.
Há a possibilidade do projeto “sair dos trilhos” se não houver um gestor de projetos experiente e
determinado.

Comentários sobre o ciclo de vida clássico: - Embora possua fragilidades, ele é significativamente
melhor do que uma abordagem casual ao desenvolvimento de software já que possui etapas bem
definidas e propõe organização do projeto e seu processo de desenvolvimento.

2) Prototipação iníc
fim io obtenção dos
requisitos
construção projeto
produto rápido

refinamento construção
protótipo protótipo
avaliação
protótipo

Processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído.
Idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos de software.
Apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não
identificou requisitos de entrada, processamento e saída com detalhes.
Principalmente, o modelo protótipo é utilizado em áreas hostis ao desenvolvedor (que não possui
experiência ou complexas) ou quando o cliente / usuário não tem experiência com sistemas e não
consegue explicitar adequadamente os requisitos do software (necessidades).

Prof. Paulo Roberto R. de Souza

Pg. 9
 ENGENHARIA DE SOFTWARE

Atividades da Prototipação

1. OBTENÇÃO DOS REQUISITOS:

Desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos são
conhecidos e as áreas que necessitam de definições adicionais. Levanta-se os requisitos do
software, suas necessidades, o que ele deverá informatizar.

2. PROJETO RÁPIDO:
Nesta etapa, realiza-se a representação dos aspectos do software que são visíveis ao usuário
(abordagens de entrada e formatos de saída). Telas (interfaces), modelos de consulta e modelos
de relatórios. No final desta etapa, deve-se ser capaz de identificar uma visão geral dos recursos
que o software conterá em termos de projeto.

3. CONSTRUÇÃO DO PROTÓTIPO:
Implementação do projeto rápido. Normalmente, implementa-se o projeto em uma linguagem de
programação de rápido desenvolvimento ou em uma ferramenta onde seja possível o cliente
visualizar os recursos que o software conterá e o que ele irá lhe oferecer.

4. AVALIAÇÃO DO PROTÓTIPO:

Cliente e desenvolvedor avaliam o protótipo. Esta avaliação visa fornecer subsídios ao cliente e
desenvolvedor para que se possam refinar os requisitos que ainda já foram identificados e
identificar aqueles que ainda não foram.

5. REFINAMENTO DOS REQUISITOS:

Cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Propõem melhorias no

protótipo e buscam sua afinidade com as necessidades do cliente.

Ocorre um processo de iteração que pode levar novamente ao levantamento de requisitos, se

julgarem necessário, ou seja, se perceberem que o protótipo está “muito cru” e necessita ser
desenvolvido novamente. Este processo de iteração ocorre até que as necessidades do cliente sejam
satisfeitas e o desenvolvedor compreenda o que precisa ser feito.

Problemas com a Prototipação:

O Cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a
qualidade global e a manutenibilidade (facilidade de manutenção) a longo prazo.
Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do
protótipo como produto final.

Comentários sobre Prototipação:

Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente, principalmente em
áreas em que o desenvolvedor desconhece ou o cliente é muito inexperiente em sistemas de
informação para explicitar os requisitos.
A chave é definir-se as regras do jogo logo no começo. O cliente e o desenvolvedor devem ambos
concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os
requisitos.

Prototipação evolutiva

Prof. Paulo Roberto R. de Souza

Pg. 10
 ENGENHARIA DE SOFTWARE

Atualmente, já aceita-se e utiliza-se a prototipação evolutiva, ou seja, desenvolve-se o protótipo

de modo que ele será aproveitado e evoluído para o software final. Neste caso, não deve-se
aproveitar softwares prontos de modo a demonstrar para o cliente, já que o aproveitamento deste
software pode degradar o código e provocar graves problemas de manutenibilidade à longo prazo.
Portanto, há esta possibilidade, porém, deve-se ter consciência da utilização ou não do protótipo
no início de sua concepção.

3 - Ciclo de Vida em Espiral

planejamento análise dos

riscos
decisão de continuar ou
não

direção de
avaliação
do cliente um sistema
engenharia concluído
Engloba as melhores características do ciclo de vida Clássico e da Prototipação, adicionando um
novo elemento: a Análise de Risco
Segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa
estrutura iterativa que reflete mais realisticamente o mundo real
Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de
riscos.
Um de seus pontos fortes é a constante avaliação por parte do cliente / usuário em todas as
etapas.

Atividades do Ciclo de Vida em Espiral

PLANEJAMENTO:

Determinação dos objetivos, alternativas e restrições. Planejamento das próximas etapas e do

software.

ANÁLISE DE RISCO:

Análise das alternativas e identificação / resolução dos riscos. Verificação e tratamento de todos
os fatores que podem colocar em risco o projeto. (Ex: Problemas com o servidor, problemas
com redes e comunicação de dados, fornecedores, desenvolvedores, softwares básicos, etc).

CONSTRUÇÃO:

Desenvolvimento do produto no nível seguinte. Desenvolvimento do projeto dos níveis iniciais ou

codificação, testes nas etapas seguintes. É a etapa de colocar “a mão na massa”.

AVALIAÇÃO DO CLIENTE:

Avaliação do produto e planejamento das novas fases. O cliente avalia o que foi realizado, dá
suas opiniões e o projeto prossegue.

Comentários sobre Prototipação:

Prof. Paulo Roberto R. de Souza

Pg. 11
 ENGENHARIA DE SOFTWARE
É, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala.
Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada
etapa evolutiva.
Pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável
Exige considerável experiência na determinação de riscos e depende dessa experiência para ter
sucesso
O modelo é relativamente novo e não tem sido amplamente usado

O grande problema deste ciclo de vida é que nem sempre o cliente está disponível para realizar
suas avaliações, este pode ser um grande entrave para o cumprimento dos prazos e do projeto em si.

4 - Técnicas de 4a Geração ou Desenvolvimento utilizando-se ferramentas

“case”
Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja
próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam a
geração do código automaticamente.

O sistema será especificado em uma linguagem de alto nível (de fácil utilização).
O código fonte seja gerado automaticamente a partir dessas especificações.
As ferramentas utilizadas realizarão consultas aos bancos de dados, geração de relatórios, telas de
cadastros, etc.

Etapas do ciclo das Técnicas de 4ª Geração

Obtenção dos
Requisitos
Estratégia do

“Projeto” Implementaçã
o usando 4GL

Testes

OBTENÇÃO DOS REQUISITOS:

O cliente descreve os requisitos (suas necessidades) os quais são traduzidos para um protótipo
operacional que seja possível especificar um projeto.

ESTRATÉGICA DE PROJETO:

Para pequenas aplicações é possível mover-se do passo de obtenção dos Requisitos para o passo de
Implementação usando uma Linguagem de quarta geração. (4GL).

IMPLEMENTAÇÃO USANDO LINGUAGEM DE QUARTA GERAÇÃO OU UMA FERRAMENTA

“CASE”:

Os resultados desejados são representados de modo que haja geração automática de código. Deve
existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL. Para

Prof. Paulo Roberto R. de Souza

Pg. 12
 ENGENHARIA DE SOFTWARE
implementação, os requisitos devem estar claros e sedimentados, assim como, o projeto deve estar
consolidado, discutido e aprovado.

TESTES:

O desenvolvedor deve efetuar testes e realizar uma documentação significativa. O software

desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
Eventuais problemas devem ser corrigidos. Problemas de inadequação com os requisitos devem ser
discutidos com o cliente / usuário e devem ser adaptados.

Comentários sobre o ciclo de vida de 4ª geração:

Vantagens:
Redução dramática no tempo de desenvolvimento do software (aumento de produtividade);
Extrema facilidade em se gerar códigos de programas de cadastros e relatórios;

Desvantagens:
As Linguagens de quarta geração, assim como, as ferramentas case atuais não são mais fáceis de
usar do que as linguagens de programação;
O código fonte produzido é truncado e ineficiente;
Programas gerados são de difícil manutenção;
Há dificuldade de se gerar códigos utilizando-se ferramentas case em programas de cálculos e
encerramentos onde há grande quantidade de laços condicionais e particularidades;

ASPECTOS COMUNS A TODOS CICLOS DE VIDA

Mudanças na natureza de desenvolvimento de software

O Processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de

engenharia de software escolhido:

DEFINIÇÃO;
DESENVOLVIMENTO;
MANUTENÇÃO;

1) DEFINIÇÃO : “o que” será desenvolvido.

Análise do Sistema: define o papel de cada elemento num sistema baseado em computador,
atribuindo em última análise, o papel que o software desempenhará.
Planejamento do Projeto de Software: assim que o escopo do software é estabelecido, os riscos são
analisados, os recursos são alocados, os custos são estimados e, tarefas e programação de
trabalho definidas.

2) DESENVOLVIMENTO: “como” o software vai ser desenvolvido.

Projeto de Software: traduz os requisitos do software num conjunto de representações (algumas
gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a
arquitetura do software, os procedimentos algorítmicos e as características de interface.

3) MANUTENÇÃO:

Prof. Paulo Roberto R. de Souza

Pg. 13
 ENGENHARIA DE SOFTWARE

Concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para uso
operacional. Como vimos especificamente no ciclo de vida clássico, as manutenções podem ser:

Corretivas: mesmo com as melhores atividades de garantia de qualidade de software, é provável que
o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir
defeitos.
Adaptativas: com o passar do tempo, o ambiente original (por exemplo a CPU, o sistema operacional
e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção
adaptativa muda o software para acomodar mudanças em seu ambiente.
Melhoramento Funcional: À medida que o software é usado, o cliente/usuário reconhecerá
funções adicionais que oferecerão benefícios, ou o desenvolvedor observa que o software está
funcionando, porém, algumas pequenas modificações trarão maior qualidade ao software.

ATIVIDADES DE PROTEÇÃO:

As fases e etapas correlatas descritas são complementadas por uma série de atividades de
proteção:

a) Revisões: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é
concluída.

b) Documentação: desenvolvida e controlada para garantir que informações completas sobre o

software estejam disponíveis para uso posterior.

c) Controle das Mudanças: é instituído de forma que as mudanças possam ser aprovadas e
acompanhadas.

e) Revisões técnicas: São revisões ou paradas realizadas durante o desenvolvimento para se

verificar e aferir se o software está sendo desenvolvido de acordo com o projeto inicial e,
principalmente, de acordo com os requisitos solicitados pelo cliente / usuário.

Prof. Paulo Roberto R. de Souza

Pg. 14
 ENGENHARIA DE SOFTWARE

BIBLIOGRAFIA

1. PRESSMAN, Roger S., Engenharia de Software. 3ª Ed. São Paulo: Editora Makron Books., 1995.

2. WEBER, Kival Chaves. Qualidade e Produtividade em Software

São Paulo: Editora Makron Books, 1997.

3. CARVALHO, A. M. B. Introdução à Engenharia de Software São Paulo: Editora Unicamp, 2001

1. SOUZA, Paulo Roberto Rodrigues. Como investir em tecnologia com segurança: critérios
importantes para se adquirir e desenvolver software. Florianópolis, 2000. Dissertação – Mestrado
– UFSC, 2000.

2. CORDEIRO, Marco Aurélio. Métricas de Software, GPS, www.supervirtual.com.br/acervo,

acessado em 29/07/2005.

6. ALDABÓ, Ricardo. Gerenciamento de Projetos - Procedimento Básico e Etapas Essencias. São

Paulo: Artliber Editora Ltda, 2001

7. PRADO, Darci Santos do. Gerência de Projetos em Tecnologia da Informação. Belo Horizonte:
Editora de Desenvolvimento Gerencial, 1999

8. AZANHA, José da Silva. Gestão de Projetos. Monografia, 2001 PMI - Project Management Institute

9. PMBOK – Project Management Body of Knowledge www.pmig.org.br Acessado em : 13/10/2001

Prof. Paulo Roberto R. de Souza

Pg. 15