Engenharia de Software

Engenharia de Software
Objetivo
Ementa
Modelos de ciclo de vida e de processos. Definição das fases de um processo e das atividades de apoio.
Introdução a Ferramentas. Ferramentas de planejamento de projeto; de processo de software.
Objetivos
 Compreender os conceitos básicos da Engenharia de Software.
 Identificar as atividades mínimas necessárias ao desenvolvimento de software e às atividades que
apóiam o processo de desenvolvimento.
 Selecionar modelos de processos que melhor se adaptem às características do projeto a ser
desenvolvido.
Contextualização
Hoje em dia, para qualquer lado que olhemos encontraremos lá a presença do software. Ele está tão presente
em nossas vidas, que nem nos damos conta. No nosso celular, naquela televisão moderna de LCD, nos
modernos carros, em centrais de energia elétrica e nuclear, na área médica, petroquímica aeronáutica, isso
sem falar em uma das maiores invenções humanas contemporâneas: a Internet.
Marcadamente, a partir da década de 70, a indústria de software obteve um crescimento fabuloso e, ainda
hoje, continua crescendo. Com o objetivo de agregar maior qualidade e menores custos à construção de
software, esta indústria foi buscar conceitos da Engenharia convencional e buscou aplicá-la ao Software.
Especificação de requisitos, projeto, construção e testes, termos comuns em outras Engenharias, vêm sendo
sistematicamente utilizados também na construção do Software, daí o termo Engenharia de Software.
Pelo exposto, pode-se inferir, então, a Engenharia de Software como: “O uso de princípios de engenharia para
a construção de software economicamente viável e que funcione eficientemente em máquinas reais.”
Conteúdo
Aula 1 – Introdução à Engenharia de Software
 1.1 Engenharia de Software: uma tecnologia em camadas
 1.2 Quem faz Engenharia de Software?
 1.3 Membros de equipe de desenvolvimento

Aula 2 – Arcabouço de Processo
 2.1 Introdução
 2.2 Atividades de arcabouço
 2.2.1 Comunicação
 2.2.2 Planejamento
 2.2.3 Modelagem
 2.2.4 Construção
 2.2.5 Implantação
Aula 3 – Atividades Guarda-Chuva
 3.1 Acompanhamento e controle de projeto
 3.1.1 Ferramentas de apoio para acompanhamento e controle do projeto
 3.2 Gestão de risco
 3.3 Garantia da qualidade de software
 3.4 Medição
 3.5 Revisões técnicas formais
 3.6 Gestão de configuração de software
 3.6.1 Ferramentas de apoio para gestão de configuração de software
 3.7 Gestão de reusabilidade
Aula 4 – Modelos de Processos de Software (Ciclo de Vida)
 4.1 Introdução
 4.2 Codifica-remenda
 4.3 Cascata ou clássico
 4.3.1 Características
 4.3.2 Principais problemas
 4.4 Prototipação
 4.5 Espiral
 4.6 Desenvolvimento em fases (incrementos e iterações)
 4.7 RAD (Rapid Application Development)
Aula 01 - Introdução à Engenharia de Software

O que é Engenharia de Software? Quem faz Engenharia de Software?
“Mais que uma atividade ou um corpo de conhecimentos, a engenharia é um verbo, uma palavra de ação, uma
forma de abordar um problema.” Scott Whitmire (apud PRESSMAN, 2006)
Nesta aula você estudará o conceito de Engenharia de Software. Aqui, você saberá como se inicia o processo,
em que desenvolvedores, clientes e usuários de software unem-se para transformar necessidades de negócio
em software.
1.1 Engenharia de Software: Uma Tecnologia em Camadas
A Engenharia de Software é definida pelo IEEE (apud PRESSMAN, 2006) como: a aplicação de uma abordagem
sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a
aplicação da engenharia ao software.
Para Pressman (2006), a Engenharia de Software é uma tecnologia em camadas (Figura 1.1). É um processo
de software acrescido de tecnologias que constituem um processo (métodos, técnicas e ferramentas
automatizadas). Ela deve se apoiar no compromisso que a organização tem com a qualidade do software (foco
na qualidade). A camada de processo define um arcabouço e foca-se no desenvolvimento rápido e oportuno de
softwares de computador. É a base para o controle de projetos e para o estabelecimento do contexto em que
os métodos serão aplicados e para a produção dos trabalhos. Nele há o estabelecimento dos marcos, da
garantia da qualidade, assim como da gerência de mudanças no software. O processo define a abordagem que
é adotada quando o software é elaborado.
O método é um procedimento formal para produzir algum resultado (PFLEEGER, 2004). Ele fornece a técnica de
como fazer para construir softwares e abrange tarefas que incluem comunicação, análise de requisitos,
modelagem de projeto, construção, testes e manutenção (PRESSMAN, 2006).
A ferramenta é:
um instrumento ou sistema automatizado utilizado para realizar uma tarefa da melhor maneira. Essa maneira
pode significar que a ferramenta torna-nos mais precisos, eficientes e produtivos ou que melhora a qualidade
do produto resultante (PFLEEGER, 2004).
Ela oferece apoio automatizado ou semi-automatizado para os processos e para os métodos. Quando os
resultados das informações geradas por uma ferramenta passam a ser usados por outra, é estabelecido um
sistema de apoio ao desenvolvimento, chamado de Engenharia de Software Apoiada por Computador
(PRESSMAN, 2006).
A definição da Engenharia de Software como uma tecnologia em camadas é ilustrada na Figura 1.1 a seguir:
Figura 1.1 – Engenharia de Software em Camadas
Fonte: PRESSMAN, 2001.
Os procedimentos combinam as ferramentas e os métodos, para que estes produzam um determinado
resultado. Por exemplo, os planos de testes descrevem os procedimentos de testes, indicando as ferramentas
que serão utilizadas, os dados e as circunstâncias em que deverão ocorrer os testes, para saber se o software
desenvolvido atende aos requisitos do software (PFLEEGER, 2004).
Os modelos de processos de software (ou ciclos de vida), que serão estudados com mais detalhe nas aulas
seguintes, determinam uma abordagem para a construção de software. Cada ciclo de vida tem suas vantagens
e desvantagens. O mais adequado para um determinado projeto vai depender das características desse projeto.
Os métodos, técnicas, procedimentos e processos de software são utilizados para apoiar a melhoria da
qualidade dos produtos de software.
1.2 Quem faz Engenharia de Software?
Para Pfleeger (2004), a comunicação entre clientes e desenvolvedores é um elemento chave no
desenvolvimento de software. Antes de iniciar a construção do sistema, é preciso saber o que o cliente quer e
quais são as suas necessidades.
Dependendo do tamanho e da complexidade do sistema, muitas pessoas serão envolvidas no processo de
desenvolvimento. Essas pessoas têm responsabilidades e desempenham diferentes papéis ao longo do projeto.
No entanto, existem projetos em que a mesma pessoa pode vir a desempenhar diferentes papéis ao mesmo
tempo.
Segundo Pfleeger (2004), os participantes dos projetos são classificados em três categorias: cliente, usuário e
desenvolvedor. Essas categorias são descritas a seguir:
 Cliente – É a empresa, organização ou pessoa que paga para que o sistema de software seja
desenvolvido.
 Usuário – É aquele que realmente utilizará o sistema (para inserir ou ler resultados); muitas vezes,
porém, o papel do cliente e do usuário confunde-se.

 Desenvolvedor – É a empresa, organização ou pessoa que desenvolve o sistema de software para o
cliente.
A Figura 1.2, a seguir, ilustra a relação entre essas categorias de participantes do desenvolvimento de
sistemas.
Figura 1.2 – Participantes do Desenvolvimento de Software
Fonte: adaptado de PFLEEGER, 2004.
A próxima seção apresenta as subdivisões da categoria desenvolvedor, com a indicação dos papéis que atuam
em uma equipe de desenvolvimento.
1.3 Membros de uma Equipe de Desenvolvimento
Clientes, usuários e desenvolvedores têm uma importante atuação na definição e criação de sistemas. Os
desenvolvedores podem se especializar em aspectos específicos e desempenhar diferentes papéis durante o
desenvolvimento. Os papéis dos membros da equipe de desenvolvimento são listados a seguir:
Analista de Requisitos – Trabalha com o cliente, para saber o que ele quer, e documenta os requisitos. As
necessidades são divididas em componentes que possam ser melhor entendidos. Esse papel é conhecido por
diferentes nomes, alguns deles são: analista, analista de sistemas, engenheiro de sistemas, projetista de
sistemas chefe, programador/analista, entre outros. Independentemente do nome adotado pelas organizações,
as principais características desse perfil são (PRESSMAN, 1995):
 Capacidade de compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar
“soluções” baseadas em cada problema.
 Capacidade de absorver fatos pertinentes de fontes conflitantes ou confusas.

 Capacidade de entender o ambiente do usuário/cliente.
 Capacidade de aplicar elementos do sistema de hardware e/ou software aos elementos do
usuário/cliente.
 Capacidade de se comunicar bem nas formas escrita e verbal.
 Capacidade de “ver a floresta por entre as árvores”.
Projetistas – Depois de conhecidos e documentados os requisitos, os analistas trabalham com os projetistas
para gerar uma descrição, em nível do sistema, do que o sistema deve fazer.
Programadores – Os projetistas trabalham com os programadores para descrever o sistema, de modo que os
programadores possam gerar as linhas de código que implementam o que foi especificado nos requisitos.
Testadores – Ajudam a encontrar os defeitos que os programadores não identificaram. As unidades de código
são integradas em grupos funcionais. Os testadores trabalham com a equipe de implementação
(programadores) para verificar se o sistema construído, a partir da integração das partes, funciona
adequadamente ou de acordo com as especificações. As equipes de testes e cliente trabalham juntas para
verificar se o sistema completo é o que o cliente quer; eles comparam o sistema em funcionamento com o
conjunto inicial de requisitos.
Instrutores – Os instrutores treinam os usuários no uso do sistema.
Equipe de manutenção – Corrige os defeitos depois de o sistema ter sido aceito pelo cliente. Com o passar
do tempo, os requisitos do cliente podem mudar; à equipe de manutenção compete realizar tais mudanças.
Resumo
Nesta aula, você aprendeu o conceito de Engenharia de Software como uma tecnologia em camadas.
Apresentamos as diferentes camadas e a base que apóia cada uma delas. Como foi dito por Scott Whitmire, a
engenharia é uma ação, então você estudou quais são os papéis que atuam na realização das atividades da
engenharia de software e como eles se relacionam.
Na próxima aula, você estudará quais são as atividades genéricas da Engenharia de Software, ou seja, o
arcabouço de processo, que pode ser aplicado aos diferentes modelos de processo de software.
Antes de iniciar a próxima aula, aproveite para refletir e pesquisar um pouco mais sobre o assunto estudado
nesta aula a faça as atividades propostas a seguir.
ATIVIDADES
1. Pesquise os conceitos de desenvolvimento, operação e manutenção de software.

2. Pesquise as responsabilidades das três categorias de participantes de projetos (cliente, usuário e
desenvolvedor).
3. Durante o desenvolvimento de software, várias pessoas são envolvidas e desempenham diferentes
papéis. Analise os papéis dos membros de uma equipe de desenvolvimento e descreva a importância
da interação entre cada um desses membros.
Aula 02 - Arcabouço de Processo

Na aula passada, você estudou que a Engenharia de Software é uma ação. Então, para a execução das ações
de engenharia de software quais são as atividades que precisam ser realizadas? Todos os projetos de
desenvolvimento de software executam o mesmo processo? O mesmo conjunto de atividades? Se sim, o que
acontece quando os projetos têm características diferentes? Mas, afinal, o que é um processo de software?
Nesta aula, você estudará o conceito de arcabouço de processo. Nela, apresentaremos atividades de arcabouço
que, de alguma forma, acontecem em qualquer projeto de desenvolvimento de software, independentemente
do ciclo de vida adotado, tamanho ou complexidade do software.
2.1 Introdução
Você sabe o que é um processo de software? É um arcabouço para as tarefas que são necessárias para
construir software de alta qualidade. E o que vem a ser um arcabouço de processo? Segundo Pressman (2006),
um arcabouço:
Estabelece o alicerce para um processo de software completo pela identificação de um pequeno número de
atividades de arcabouço aplicáveis a todos os processos de software, independentemente de seu tamanho ou
complexidade. Além disso, o arcabouço de processo engloba um conjunto de atividades guarda-chuva que são
aplicáveis durante todo o processo de software.
O Quadro 2.1 apresenta uma visão genérica para um processo de software.
Quadro 2.1 – Panorama da Engenharia de Software: uma Visão Genérica
O que é? Quais são os passos?
Quando você elabora um produto ou sistema, é Em nível de detalhe, o processo adotado depende do
importante percorrer uma série de passos previsíveis – software que se está construindo. Um processo poderia
um roteiro que ajuda a criar, a tempo, um resultado de ser apropriado à criação de softwares para o sistema
alta velocidade. O roteiro que você segue é chamado de aviônica de uma aeronave, enquanto um processo
de processo de software. inteiramente diferente seria indicado para a criação de

Quem faz? um site.
Os engenheiros de software e seus gerentes adaptam Qual é o produto de trabalho?
os processos às suas necessidades e depois os
seguem. Além disso, as pessoas que solicitaram o Do ponto de vista de um engenheiro de software, os
software têm um papel a desempenhar no seu produtos de trabalho são os programas, documentos e
processo de definição, construção e teste. dados produzidos em conseqüência das atividades e
tarefas definidas pelo processo.
Por que é importante?
Como tenho certeza de que fiz corretamente?
Porque fornece estabilidade, controle e organização
para uma atividade que pode, se deixada sem Existem diversos mecanismos de avaliação do processo
controle, tornar-se bastante caótica. No entanto, uma de software que permitem às organizações determinar
abordagem moderna de Engenharia de Software a “maturidade” do seu processo de software. Todavia,
precisa ser “ágil”. Precisa exigir apenas atividades, a qualidade, pontualidade e viabilidade em longo prazo
controles e documentação adequados à equipe de do produto que se constrói são os melhores
projeto e ao produto que deve ser produzido. indicadores da eficácia do processo usado.
A Figura 2.1 ilustra um arcabouço de processo de software. Cada atividade do arcabouço tem um conjunto de
ações de Engenharia de Software. Essas atividades são refletidas em termos de tarefas que geram produtos de
trabalho.
O arcabouço tem um conjunto de atividades genéricas que são aplicáveis à maioria dos processos de software
também usadas como base para os modelos de processo (PRESSMAN, 2006), que serão estudados nas
próximas aulas.
Figura 2.1 – Um Arcabouço de Processo de Software
2.2 Atividades de Arcabouço
As próximas seções descrevem cada uma das atividades do arcabouço de processo.
2.2.1 Comunicação
Envolve alta comunicação e colaboração com o cliente (e outros interessados) e abrange o levantamento de
requisitos e outras atividades relacionadas (PRESSMAN, 2006). O levantamento de requisitos tem foco na
identificação das necessidades do cliente em relação ao produto. Essas necessidades são expressas em uma
linguagem que possa ser entendida pelo cliente (PÁDUA, 2001).

O levantamento de requisitos não é uma tarefa simples, por isso deve acontecer de forma organizada. Christel
e Kang (apud PRESSMAN, 2006) identificaram alguns dos principais problemas relacionados ao levantamento
de requisitos:
 Problemas de escopo – O limite do sistema é mal definido ou o cliente especifica detalhes técnicos
desnecessários que podem confundir, ao invés de esclarecer os objetivos globais do sistema.
 Problemas de entendimento – Os clientes/usuários não estão completamente certos do que é
necessário; têm pouca compreensão das capacidades e limitações de seu ambiente computacional;
não têm pleno domínio do problema, têm dificuldade de informar as necessidades ao engenheiro de
sistemas; omitem informações que acreditam ser “óbvias”; especificam requisitos conflitantes com as
necessidades de outros clientes/usuários; ou especificam requisitos que são ambíguos ou impossíveis
de testar.
 Problemas de volatilidade – Os requisitos mudam ao longo do tempo.
Outra dificuldade é que, durante o levantamento de requisitos, embora muitas pessoas contribuam para esse
processo, cada uma tem pontos de vista diferentes e, algumas vezes, conflitantes (PFLEEGER, 2004). Uma das
habilidades necessárias ao analista de requisitos é entender cada ponto de vista e conceber requisitos que
consigam refletir as necessidades de cada um dos participantes.
Técnicas de Apoio
Existem algumas técnicas que apóiam o analista durante o levantamento de requisitos. Nesta aula,
discutiremos duas dessas técnicas que colaboram para a eficácia das atividades de levantamento e para a
qualidade dos requisitos resultantes dessas atividades (PÁDUA, 2001):
Prototipação
O protótipo (descartável) é construído com o objetivo de demonstrar aos usuários o que o analista conseguiu
captar quanto aos requisitos do produto, ou parte dele. O protótipo deve ser construído de forma rápida, em
poucas horas ou em poucos dias. Ele é indicado para estudar:
i. a alternativa de interface de usuário.
ii. os problemas de comunicação com outros produtos.
iii. a viabilidade de atendimento dos requisitos de desempenho.
Em projetos maiores, o protótipo também pode ser usado para resolver problemas de desenho e
implementação e para decidir questões importantes por meio de pequenos experimentos.

Alguns benefícios de uso de protótipos são: redução de riscos na construção; aumento de manutenibilidade;
foco em áreas menos compreendidas; e oportunidade de treinamento dos programadores menos experientes,
trabalhando como codificadores.
JAD (Joint Application Development)
É uma técnica estruturada de condução de reuniões, aplicável a diversas atividades de desenvolvimento de
software. Ela é muito útil para o levantamento e a negociação de requisitos. Nessas reuniões participam
desenvolvedores, usuários-chave e gerentes de ambos os lados. As vantagens da técnica JAD são:
 Compromete nos requisitos os usuários com poder de decisão sobre eles.
 Reduz o prazo de levantamento da especificação de requisitos.
 Elimina requisitos de valor questionável.
 Reduz diferenças de interpretação dos requisitos entre usuários e desenvolvedores.
 Produz um primeiro esboço das interfaces de usuários.
 Traz à baila, o mais cedo possível, problemas políticos que possam interferir no projeto.
Existem alguns problemas que podem comprometer a eficácia do JAD, são eles:
 A não participação das pessoas que desempenham papéis-chave nos processos de uso do produto.
 A participação das pessoas não comprometidas com o produto (observadores não devem ser
permitidos, ou devem transformar-se em participantes integrais).
 O número excessivo de participantes (o número máximo recomendado varia de 8, para grupos
iniciantes, a 15, para grupos experientes). Caso o cliente não libere o seu pessoal para participar das
reuniões com a dedicação necessária, então o JAD não é viável.
Princípios da Prática de Comunicação
Pressman (2006) propõe dez princípios da prática de comunicação que são transcritos a seguir:
Princípio 1 – Escute:
Tente se concentrar nas palavras do interlocutor, em vez de se concentrar na formulação de sua resposta a
essas palavras. Peça esclarecimento se algo estiver obscuro, mas evite interrupções constantes. Nunca torne
suas próprias palavras ou ações desagradáveis por exemplo, virar os olhos ou sacudir a cabeça quando uma
pessoa estiver falando.
Princípio 2 - Prepare-se antes de se comunicar:

Gaste tempo em entender o problema antes de se comunicar com os outros. Se necessário, pesquise para
entender o jargão dominante do negócio. Se você é responsável pela condução de uma reunião, prepare uma
agenda com antecedência.
Princípio 3 – Alguém deve facilitar a atividade:
Toda reunião de comunicação deve ter um líder (facilitador): (1) para manter a conversa, em uma direção
produtiva; (2) para mediar qualquer conflito; (3) para garantir que os outros princípios sejam seguidos.
Princípio 4 – Comunicação face a face é melhor:
Costuma funcionar melhor quando alguma outra representação da comunicação relevante é apresentada. Por
exemplo, um participante pode criar um desenho ou um documento provisório que serve como foco da
discussão.
Princípio 5 – Faça anotações e documente as decisões:
As coisas têm um modo de escorrer por entre os dedos. Alguém que participe da comunicação deve servir como
“registrador” e anotar todos os pontos e decisões importantes.
Princípio 6 – Busque a colaboração:
Colaboração e consenso ocorrem quando o conhecimento coletivo dos membros da equipe é combinado para
descrever funções ou características do produto ou do sistema. Cada pequena colaboração serve para construir
confiança entre os membros da equipe e cria um objetivo comum entre ela.
Princípio 7 – Conserve-se focado, modularize sua discussão:
Quanto mais pessoas estiverem envolvidas em uma comunicação, provavelmente, mais aquela discussão vai
ficar saltando de um tópico para outro. O facilitador deve manter a conversa modular, abandonando um tópico
apenas depois que tiver sido resolvido (no entanto, veja o princípio número 9).
Princípio 8 – Se algo não está claro, desenhe uma figura:
A comunicação verbal só vai até certo ponto. Um esboço ou um desenho pode, freqüentemente, fornecer
esclarecimento quando as palavras não conseguem fazer o serviço.

Princípio 9 – (a) Quando você não concorda com algo, prossiga; (b) Se você não pode concordar
com algo, prossiga; (c) Se uma função ou característica não está clara e não pode ser esclarecida no
momento, prossiga:
A comunicação, como qualquer outra atividade da Engenharia de Software, leva tempo. Em vez de iterar sem
fim, as pessoas que participam devem reconhecer que muitos tópicos requerem discussão (veja o princípio
número 2) e que “prosseguir” é, às vezes, o melhor modo de conseguir agilidade na comunicação.
Princípio 10 – Negociação não é um concurso ou um jogo. Funciona melhor quando ambas as partes
ganham:
Existem muitas instâncias nas quais o engenheiro de software e o cliente precisam negociar funções e
características, prioridades e datas de entrega. Se a equipe colaborar bem, todas as partes terão uma meta em
comum. Assim sendo, a negociação se dará pelo compromisso de todas as partes.
2.2.2 Planejamento
Esta atividade estabelece um plano para o trabalho de Engenharia de Software que será seguido. Descreve as
tarefas técnicas a serem conduzidas, os riscos prováveis, os recursos que serão necessários, os produtos a
serem produzidos e o cronograma de trabalho (PRESSMAN, 2006).
Para comunicar os itens planejados aos envolvidos no projeto, o gerente de projeto deve produzir um
documento chamado “plano de projeto”. Um bom plano de projeto deve incluir, pelo menos, os seguintes itens
(PFLEGEER, 2004):
 Escopo – Define os limites do sistema, explicando o que será e o que não será incluído nele e
assegurando a existência de conhecimento sobre o que o cliente espera do sistema.
 Cronograma – É expresso utilizando-se uma estrutura de divisão do trabalho, os produtos a serem
entregues e uma linha de tempo para mostrar o que acontecerá em cada momento do ciclo de vida do
projeto. Deve ser possível identificar a relação de dependência entre as atividades. Segundo Pressman
(2006), um cronograma bem planejado define as tarefas e os marcos que devem ser acompanhados e
controlados à medida que o projeto prossegue.
 Organização da equipe – Relação das pessoas da equipe de desenvolvimento e organização e de
suas atividades. Nem todo o pessoal será necessário durante todo o tempo de desenvolvimento do
projeto, por isso o plano deve prever a distribuição dos recursos-humanos e a quantidade necessária
em cada momento.
 Descrição técnica do sistema proposto – Contempla hardware e software, incluindo compiladores,
interfaces e equipamento ou software de propósito especial.

 Padrões, procedimentos, técnicas e ferramentas propostas – Devem ser listados padrões e
métodos que serão utilizados, tais como: algoritmos, ferramentas, técnicas de revisão ou inspeção,
linguagens ou representação de projeto, linguagens de programação, técnicas de teste etc.
 Plano de garantia da qualidade – Deve descrever como as revisões, as inspeções, os testes e
outras técnicas ajudarão a avaliar a qualidade e a assegurar que as necessidades do cliente serão
atendidas.
 Plano de gerência de configuração – Informa como serão controladas as mudanças nos requisitos,
no projeto, no código, no plano de teste e nos documentos gerados ao longo do projeto.
 Plano de documentação – Relaciona os documentos que serão produzidos, quem os escreverá e
quando isso ocorrerá; e, de acordo com o plano de gerência de configuração, descreve como esses
documentos serão modificados.
 Plano de gerência de dados – O plano deve explicitar como os dados serão obtidos, armazenados,
manipulados e arquivados (inclusive a documentação em papel).
 Plano de gerência de recursos – O plano deve explicar como os recursos serão utilizados. Por
exemplo, se a configuração de hardware inclui discos removíveis, então o gerenciamento de recursos,
como parte do plano de projeto, deveria explicar que dados estão em cada disco e como os disk packs
ou disquetes serão alocados e copiados em bakcup.
 Plano de testes – Descreve a abordagem de testes utilizada no projeto. Ele deve estabelecer como
serão gerados os dados de teste, como cada módulo do programa será testado; como os módulos do
programa serão integrados e testados, como o sistema inteiro será testado e quem realizará cada tipo
de teste.
 Plano de treinamento – Explica como o treinamento ocorrerá, descrevendo cada aula, software de
apoio e documentos, bem como os conhecimentos necessários a cada estudante.
 Plano de segurança – Mostra como o sistema protegerá os dados dos usuários e o hardware. Uma
vez que a segurança envolve confidencialidade, disponibilidade e integridade, o plano deverá explicar
como cada faceta da segurança afeta o desenvolvimento do sistema.
 Plano de gerência de riscos – Avalia os riscos que podem afetar o resultado do projeto ou a
qualidade do produto. Os aspectos relacionados ao gerenciamento de riscos serão tratados na
próxima aula.
 Plano de manutenção – Se a equipe do projeto será responsável pela manutenção do sistema
depois que ele for entregue ao usuário, o plano deverá estabelecer as responsabilidades pelas
alterações no código, pelo conserto do hardware e pela atualização da documentação de apoio e dos
materiais de treinamento.
Ferramentas de Apoio para Planejamento
A gerência de projetos deve ser apoiada por ferramentas. Pressman (2006) exemplifica algumas ferramentas
de apoio:
 Project Control Panel – Fornece ao gerente de projeto uma indicação direta do estado do projeto. A
ferramenta tem sensores parecidos com um painel de controle e é implementada como o Microsoft
Excel.
 Conjunto de lista de verificação (checklists) – Disponível para o gerente de projeto.
 Ittoolkit.com – Fornece uma coleção de guias de planejamento, gabaritos de processo e planilhas
inteligentes, disponíveis em CD-ROM.
Especificamente para elaboração de cronogramas, citamos como exemplo as ferramentas abaixo:
 Microsoft Project – É a ferramenta de cronogramação de projeto mais amplamente usada
(PRESSMAN, 2006).
 Viewpoint – Apóia todos os aspectos do planejamento de projeto, inclusive cronogramação.
 DotProject – Ferramenta de cronogramação de projeto (software livre).
 Planner – Ferramenta de cronogramação de projeto (software livre).
Para Saber Mais
Para quem deseja pesquisar outras ferramentas de gestão de projetos e de produtos, Pressman (2006) indica o
site www.infogoal.com/pmc/pmcswr.htm.
Princípios da Prática de Planejamento
Pressman (2006) elencou dez princípios da prática de planejamento, os quais são listados a seguir:
Princípio 1 – Entenda o escopo do projeto:
É impossível usar um roteiro se você não souber para aonde está indo. O escopo fornece à equipe de software
um destino.
Princípio 2 – Envolva o cliente na atividade de planejamento:
O cliente define prioridades e oferece restrições de projeto. Para acomodar essas realidades, os engenheiros de
software precisam, freqüentemente, negociar a ordem de entrega, os prazos e outros tópicos relacionados ao
projeto.
Princípio 3 – Reconheça que o planejamento é iterativo:
Um plano de projeto nunca é gravado em pedra. Quando um trabalho tem início, é muito provável que as
coisas modifiquem-se. Como conseqüência, o plano deve ser ajustado para acomodar essas modificações. Além
disso, modelos de processo iterativos e incrementais determinam o replanejamento (após a entrega de cada
incremento de software), com base no feedback recebido dos usuários.

Princípio 4 – Estime com base no que é sabido:
A intenção de uma estimativa é fornecer uma indicação do esforço, do custo e da duração das tarefas com base
no entendimento atual da equipe quanto ao trabalho a ser feito. Se a informação for vaga ou não confiável, as
estimativas serão igualmente não confiáveis.
Princípio 5 – Considere riscos à medida que você define o plano:
Se a equipe definir riscos que têm grande impacto e alta probabilidade, será necessário o planejamento de
contingência. Além disso, o plano do projeto, inclusive o cronograma, deve ser ajustado para acomodar a
probabilidade de um ou mais desses riscos vir a ocorrer.
Princípio 6 – Seja realista:
As pessoas não trabalham 100% a cada dia. Sempre há ruído em qualquer comunicação humana. Omissões e
ambigüidades são fatos da vida. Modificações ocorrerão. Mesmo os melhores engenheiros de software cometem
erros. Essas e outras realidades devem ser consideradas quando um plano de projeto for estabelecido.
Princípio 7 – Ajuste a granularidade à medida que você define o plano:
Granularidade refere-se ao nível de detalhe que é introduzido à medida que um plano de projeto é
desenvolvido. Um plano de “granularidade fina” fornece detalhes significativos das tarefas de trabalho que são
planejadas por incrementos de tempo relativamente curtos (de modo que o acompanhamento e o controle
ocorram freqüentemente). Um plano de “granularidade grossa” fornece tarefas de trabalho mais amplas,
planejadas por períodos de tempo mais longos. Em geral, a granularidade move-se de fina para grossa à
medida que a linha de tempo do projeto se afasta da atual.
Princípio 8 – Defina como você pretende garantir a qualidade:
O plano deve identificar como a equipe de software pretende garantir a qualidade. Se revisões técnicas formais
tiverem de ser conduzidas, elas devem estar nos cronogramas. Se a programação aos pares tiver de ser usada
durante a construção, isso deve ser explicitamente definido dentro do plano.
Princípio 9 – Descreva como você pretende acomodar as modificações:
Mesmo o melhor planejamento pode ser comprometido por modificações descontroladas. A equipe de software
deve identificar como as modificações devem ser acomodadas, à medida que o trabalho da engenharia de
software prossegue. Por exemplo, o cliente pode solicitar uma modificação a qualquer momento. Quando a
modificação for solicitada, a equipe é obrigada a implementá-la imediatamente? Como é avaliado o impacto e o
custo da modificação?
Princípio 10 – Acompanhe o plano com freqüência e faça ajustes quando necessário:
Projetos de software atrasam um dia de cada vez. Assim, faz sentido acompanhar o progresso diariamente,
procurando áreas de problema e situações em que o trabalho programado não esteja de acordo com o trabalho
real conduzido. Quando um desvio é encontrado, o plano é ajustado de acordo.
2.2.3 Modelagem
Inclui a criação de modelos que permitam ao desenvolvedor e ao cliente entender melhor os requisitos do
software e o projeto que vai satisfazer a esses requisitos (PRESSMAN, 2006). A atividade de modelagem é
composta por duas ações de engenharia: análise e projeto.
Ao longo da análise, o foco do analista está em saber o que deve ser feito, e não o como deve ser feito. Os
elementos do modelo de análise fornecem a base para a elaboração dos modelos de projeto (dados/classes,
arquitetura, interface e componentes).
Princípios da Prática de Modelagem – Análise
Pressman (2006) propõe cinco princípios da prática de Modelagem – de Análise. Eles são transcritos a seguir:
Princípio 1 – O domínio da informação de um problema precisa ser apresentado e entendido:
O domínio da informação abrange os dados que fluem para dentro do sistema (vindos dos usuários finais, de
outros sistemas ou de dispositivos externos); os dados que fluem para fora do sistema (pela interface do
usuário, por interfaces de rede, relatórios, gráficos e outros meios) e os depósitos de dados que coletam e
organizam os objetos de dados persistentes (isto é, os dados que são mantidos permanentemente).
Princípio 2 – As funções a serem desenvolvidas pelo software devem ser definidas:
As funções do software fornecem benefício direto aos usuários finais e também dão apoio interno às
características que são visíveis ao usuário. Algumas funções transformam os dados que fluem para dentro do
sistema. Em outros casos, as funções efetuam algum nível de controle sobre o processamento interno do
software ou sobre elementos externos do sistema. As funções podem ser descritas em vários níveis de
abstração diferentes, que vão desde uma declaração geral de objetivo até uma descrição detalhada dos
elementos de processamento que precisam ser invocados.

Princípio 3 – O comportamento do software (como conseqüência de eventos externos) precisa ser
representado:
O comportamento do software de computador é guiado por suas interações com o ambiente externo. Entradas
fornecidas pelos usuários finais, dados de controle fornecidos por um sistema externo ou monitoramento de
dados coletados em uma rede, todos fazem com que o software comporte-se de um modo específico.
Princípio 4 – Os modelos que mostram informação, função e comportamento devem ser
particionados de modo que revele detalhes em forma de camadas (ou hierarquias):
A modelagem de análise é o primeiro passo na solução de um problema de Engenharia de Software. Ela
permite que os profissionais entendam melhor o problema e estabelece uma base para a solução (projeto).
Problemas complexos são difíceis de serem resolvidos como um todo. Por isso, usamos uma estratégia de
dividir e conquistar. Um problema complexo, grande, é dividido em subproblemas, até que cada subproblema
seja relativamente fácil de entender. Esse conceito é chamado de particionamento e é uma estratégia-chave na
modelagem de análise.
Princípio 5 – A tarefa da análise deve ir de informação essencial até os detalhes de implementação:
A modelagem de análise começa descrevendo um problema na perspectiva do usuário final. A “essência” do
problema é descrita sem qualquer consideração de como uma solução será implementada. Por exemplo, um
videogame exige que o jogador “instrua” seu protagonista sobre em qual direção prosseguir quando entra em
um ambiente perigoso. Essa é a essência do problema. Os detalhes de implementação (normalmente descrito
como parte do modelo de projeto) indicam como a essência será implementada. No videogame, pode-se usar
uma entrada de voz. Alternativamente, um comando de teclado pode ser digitado ou um joystick (ou mouse)
pode ser apontado em uma direção específica.
Princípios da Prática de Modelagem – Projeto
Os nove princípios da prática de Modelagem - de Projeto – são listados abaixo (PRESSMAN, 2006):
Princípio 1 – O projeto deve estar relacionado ao modelo de análise:
O modelo de análise descreve o domínio de informação do problema, as funções visíveis ao usuário, o
comportamento do sistema e o conjunto de classes de análise que empacotam objetos do negócio com os
métodos que os servem. O modelo de projeto traduz essa informação em uma arquitetura: um conjunto de
subsistemas que implementam as funções principais e um conjunto de projetos, em nível de componentes,
realizado pelas classes de análise. Com exceção do projeto associado à infra-estrutura do software, os
elementos do modelo de projeto devem estar relacionados ao modelo de análise.

Princípio 2 – Sempre considere a arquitetura do sistema a ser construído:
A arquitetura do software é o esqueleto do sistema a ser construído. Ela afeta as interfaces; as estruturas de
dados, o fluxo de controle e o comportamento do programa; o modo pelo qual o teste pode ser conduzido; a
manutenibilidade do sistema resultante e muito mais. Por todas essas razões, o projeto deve começar com
considerações arquiteturais. Apenas depois de a arquitetura ser estabelecida, os tópicos em nível de
componente devem ser considerados.
Princípio 3 – O projeto dos dados é tão importante quanto o projeto de funções de processamento:
O projeto dos dados é um elemento essencial do projeto arquitetural. A maneira pela qual os objetos são
realizados no projeto não pode ser deixada ao acaso. Um projeto de dados bem estruturado ajuda a simplificar
o fluxo do programa, torna o projeto e a implementação dos componentes de software mais fáceis e deixa o
processamento global mais eficiente.
Princípio 4 – As interfaces (tanto externas quanto internas) precisam ser projetadas com cuidado: A
maneira como os dados fluem entre os componentes de um sistema tem muito a ver com a eficiência de
processamento, a propagação de erros e a simplicidade de projeto. Uma interface bem projetada torna a
integração mais fácil e ajuda o testador na validação das funções dos componentes.
Princípio 5 – O projeto de interface do usuário deve estar sintonizado com as necessidades do
usuário final. No entanto, em cada caso, ele deve enfatizar a facilidade de uso:
A interface do usuário é a manifestação visível do software. Não importa quão sofisticadas sejam suas funções
internas, quão abrangentes suas estruturas de dados, quão bem projetada a sua arquitetura, um projeto de
interface pobre conduz, muitas vezes, à percepção de que o software é ruim.
Princípio 6 – O projeto em nível de componentes deve ser funcionalmente independente:
A independência funcional é uma medida da “objetividade” de um componente de software. A funcionalidade
fornecida por um componente deve ser coesiva – isto é, deve enfocar apenas uma e apenas uma função ou
subfunção.
Princípio 7 – Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente
externo:
O acoplamento é conseguido de muitos modos: via interface de componentes, por mensagens ou por meio de
dados globais. À medida que o nível de acoplamento aumenta, a probabilidade de propagação de erros também
aumenta e a manutenibilidade global do software diminui. Assim, o acoplamento de componentes deve ser
mantido tão baixo quanto for razoável.
Princípio 8 – Representações de projeto (modelos) devem ser facilmente compreensíveis:
O objetivo do projeto é comunicar a informação para os profissionais que vão gerar código, para aqueles que
vão testar o software e para outros que podem vir a manter o software no futuro. Se o projeto for difícil de
entender, ele não servirá como um meio de comunicação efetivo.
Princípio 9 – O projeto deve ser desenvolvido iterativamente. A cada iteração, o projetista deve
lutar por maior simplicidade:
Como quase todas as atividades criativas, o projeto ocorre iterativamente. As primeiras iterações trabalham
para refinar o projeto e corrigir erros, mas as últimas iterações devem procurar tornar o projeto o mais simples
possível.
2.2.4 Construção
Combina a geração de código (manual ou automática) e os testes necessários para revelar erros no código
(PRESSMAN, 2006). As representações de projeto (modelos) são traduzidas em linguagem de programação e a
realização dos testes descobre defeitos de função, lógica e implementação (PRESSMAN, 1995).
Princípios da Prática de Construção
Pressman (2006) propõe alguns princípios da prática de Construção. Eles são listados a seguir:
Princípios de Preparação:
Antes de escrever uma linha de código, certifique-se de:
1. Entender o problema que está tentando resolver.
2. Entender os princípios e conceitos básicos do projeto.
3. Escolher uma linguagem de programação que satisfaça às necessidades do software a ser construído
e do ambiente em que ele vai operar.
4. Selecionar um ambiente de programação que forneça ferramentas para facilitar o seu trabalho.
5. Criar um conjunto de testes unitários que será aplicado tão logo o componente que você está
implementando seja completado.
Princípios de Codificação
Quando começar a escrever o código, certifique-se de:
1. Restringir seus algoritmos, seguindo a prática de programação estruturada.
2. Selecionar as estruturas de dados que atendam às necessidades do projeto.
3. Entender a arquitetura do software e criar interfaces que sejam consistentes dela.
4. Conservar a lógica condicional tão simples quanto possível.
5. Criar ciclos aninhados de modo que sejam facilmente testáveis.
6. Selecionar nomes significativos de variáveis e seguir outras normas locais de codificação.
7. Escrever código que é autodocumentado.
8. Criar uma disposição visual (por exemplo, alinhamento e linhas em branco) que auxilie o
entendimento.
Princípios de Validação
Depois de completar seu primeiro passo de codificação, certifique-se de:
1. Conduzir uma inspeção de código quando adequado.
2. Realizar testes unitários e corrigir erros descobertos.
3. Refabricar o código.
Os princípios das práticas de teste são propostas por Davis (apud PRESSMAN, 2006). Os cinco princípios são
listados a seguir:
Princípio 1 – Todos os testes devem estar relacionados aos requisitos do cliente:
O objetivo do teste de software é descobrir erros. Segue daí que os defeitos mais severos (do ponto de vista do
cliente) são aqueles que fazem com que o programa deixe de satisfazer aos seus requisitos.
Princípio 2 – Os testes devem ser planejados muito antes de serem iniciados:
O planejamento dos testes pode começar assim que o modelo de análise for completado. A definição detalhada
dos casos de teste pode começar tão logo o modelo de projeto tenha sido consolidado. Assim sendo, todos os
testes podem ser planejados e projetados antes que qualquer código tenha sido gerado.
Princípio 3 – O Princípio de Pareto aplica-se aos testes de software de processamento:
O princípio de Pareto significa que 80% de todos os erros descobertos durante o teste estarão, provavelmente,
relacionados a 20% de todos os componentes do programa. O problema, sem dúvida, é isolar esses
componentes suspeitos e testá-los rigorosamente.

Princípio 4 – O teste deve começar no “varejo” e progredir até o teste no “atacado”:
Os primeiros testes planejados e executados concentram-se geralmente nos componentes individuais. À medida
que o teste progride, o foco se desloca numa tentativa de encontrar erros em conjuntos integrados de
componentes e, finalmente, em todo o sistema.
Princípio 5 – Testes exaustivos não são possíveis:
A quantidade de permutações de caminho, mesmo para um programa de tamanho moderado, é
excepcionalmente grande. Por essa razão, é impossível executar todas as combinações de caminho durante o
teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir que todas as condições do
projeto, em nível de componente, tenham sido exercitadas.
2.2.5 Implantação
A implantação ocorre quando o software (como unidade completa ou incremento parcialmente completo) é
entregue ao cliente, que avalia o produto entregue e fornece feedback com base na avaliação (PRESSMAN,
2006). O cliente deve ser estimulado a fornecer feedback a cada entrega.
Princípios da Prática de Implantação
São propostos, por Pressman (2006), cinco princípios da prática de Implantação:
Princípio 1 – As expectativas do cliente quanto ao software devem ser geridas:
Muito freqüentemente, o cliente espera mais do que o prometido pela equipe de desenvolvimento, e, assim, o
desapontamento é imediato. Isso resulta em feedback não produtivo e arruína a moral da equipe. Em seu livro
sobre expectativas de gestão, Naomi Karten (apud PRESSMAN, 2006) afirma: “O ponto inicial da gestão de
expectativas é tornar-se mais consciente do que você comunica e de como o faz”. Ela sugere que um
engenheiro de software deva ser cuidadoso com o envio de mensagens conflitantes ao cliente (por exemplo,
prometer mais do que você pode realmente entregar na data combinada, entregar mais do que em um
incremento de software e, no seguinte, menos do que o prometido).
Princípio 2 – Um pacote completo de entrega deve ser montado e testado:
Um CD-ROM ou outra mídia contendo todo o software executável, os arquivos de dados de suporte, os
documentos de suporte e outras informações relevantes deve ser montado e rigorosamente testado por testes
beta e com usuários reais. Todos os documentos de instalação e outras características operacionais devem ser
seriamente exercitados em todas as possibilidades de configuração de computação (isto é, hardware, sistemas
operacionais, dispositivos periféricos, arranjos de redes).

Princípio 3 – Um regime de suporte deve ser estabelecido antes de o software ser entregue:
Um usuário final espera receptividade e informação segura quando uma questão ou um problema surge. Se o
suporte é ad hoc, ou pior, inexistente, o cliente ficará insatisfeito imediatamente. O suporte deve ser planejado,
o material de suporte preparado e os mecanismos adequados de registros devem ser estabelecidos, de modo
que a equipe de software possa conduzir uma avaliação categórica das espécies de suporte necessárias.
Princípio 4 – Os materiais institucionais adequados devem ser fornecidos aos usuários finais:
A equipe de software entrega mais do que o software em si. Ajuda de treinamento adequado (se necessária)
deve ser desenvolvida, diretrizes de apuração devem ser fornecidas e uma descrição de “o-que-é-diferente-
nesse-incremento-de-software” deve ser publicada.
Princípio 5 – Software defeituoso deve ser corrigido primeiro e, depois, entregue:
Pressionadas pelo tempo, algumas organizações de software entregam incrementos de baixa qualidade com um
aviso ao cliente de que os defeitos “serão consertados na versão seguinte”. Isso é um erro. Há um ditado no
negócio de software que diz: “Os clientes esquecerão que você entregou um produto de alta qualidade alguns
dias depois, mas eles nunca esquecerão os problemas que um produto de baixa qualidade causou-lhes. O
software os lembra a cada dia”.
Além das atividades de arcabouço de processo de software que você acaba de estudar, existem também as
atividades guarda-chuva. Atividades guarda-chuva são aquelas que podem ser executadas ao longo de todo o
ciclo de vida do software. Essas atividades serão estudadas na próxima aula.
Resumo
Existem algumas atividades que são imprescindíveis na Engenharia de Software. Elas são chamadas de
atividades de arcabouço e geralmente são executadas para qualquer projeto de software, podendo ser inseridas
em qualquer modelo de processo de software.
Na próxima aula, você estudará como as atividades guarda-chuva complementam e apóiam as atividades de
arcabouço. Mais adiante, estudará também as características dos modelos de processo de software e perceberá
a existência das atividades de arcabouço nesses modelos.
ATIVIDADES
1. Associe as atividades de arcabouço de processo com os papéis dos membros da equipe de
desenvolvimento que foram estudados na aula anterior.

2. Existe algum caso em que as atividades de arcabouço de processo de software não se aplicam? Em
caso afirmativo, descreva-o.
3. Selecione um modelo de processo e descreva como esse modelo lida com uma mudança significativa
em requisitos.
Aula 03 - Atividades Guarda-Chuva
Na aula anterior você estudou as atividades de arcabouço de processo da
Engenharia de Software. Agora vamos ler um pouco mais sobre as atividades guarda-chuva, que são aquelas
que complementam as atividades de arcabouço de processo e são aplicadas ao longo de todo processo de
desenvolvimento.
Nesta aula, serão estudadas as características de algumas atividades típicas dessa categoria.
3.1 Acompanhamento e Controle de Projeto de Software
O acompanhamento e controle de projeto permitem à equipe de software avaliar o processo com base no plano
de projeto e tomar a ação necessária para manter o cronograma (PRESSMAN, 2006). No PMBOK (2004):
O grupo de processo de monitoramento e controle mede e monitora regularmente o progresso para identificar
variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações
corretivas, quando necessário, para atender aos objetivos do projeto.
Algumas formas de realizar o acompanhamento do projeto são (PRESSMAN, 2006):
 Conduzir reuniões periódicas sobre o estado do projeto em que cada membro da equipe relate o
progresso e os problemas.
 Avaliar os resultados de todas as revisões conduzidas ao longo do processo de engenharia de
software.
 Determinar se os marcos de referência formais do projeto foram atingidos na data prevista.
 Comparar a data de início real com a data de início planejada para cada tarefa do projeto
(cronograma).
 Reunir informalmente os profissionais para obter sua avaliação subjetiva do progresso alcançado e
dos problemas que estão aparecendo.
 Usar a análise de valor agregado para avaliar quantitativamente o progresso.
Todos os itens que compõem o plano de projeto devem ser monitorados durante o andamento do projeto. As
ações corretivas provenientes de monitoração devem ser gerenciadas até a sua conclusão. John Reel (apud
PRESSMAN, 2006) define dez sinais que indicam quando um projeto está comprometido:
 O pessoal de software não entende as necessidades de seus clientes.
 O escopo do produto está mal definido.
 As modificações são mal gerenciadas.
 A tecnologia escolhida sofre modificações.
 As necessidades do negócio modificam-se (ou estão mal definidas).
 Os prazos são irreais.
 Os usuários são resistentes.
 O patrocínio é perdido (ou nunca foi obtido adequadamente).
 A equipe do projeto não tem pessoal com as aptidões adequadas.
 Gerentes (e profissionais) evitam as melhores práticas e as lições adquiridas.
3.1.1 Ferramentas de Apoio para Acompanhamento e Controle do Projeto
Exemplos de ferramentas que podem ser utilizadas para apoiar as atividades de planejamento e
acompanhamento de projeto foram discutidas na aula 2, no item 2.2.2 referente a Planejamento de Projeto.
3.2 Gestão de Risco
Segundo Kim Heldman (2006), os riscos associados a um projeto, normalmente, dizem respeito aos objetivos
do projeto e podem interferir em tempo, custo, escopo, qualidade (ou qualquer combinação desses quatro
itens). Para Pressman (2006), a gestão de risco avalia os riscos que podem afetar o resultado do projeto ou a
qualidade do produto. Os riscos devem ser monitorados ao longo do projeto e podem ou não impactar o projeto
negativamente. A estimativa dos riscos compreende as seguintes atividades (PÁDUA, 2001):
 Identificação dos riscos possíveis em relação ao projeto.
 Análise desses riscos, avaliando a probabilidade e o impacto de riscos.
 Priorização dos riscos, organizando-os de acordo com a probabilidade e o impacto.
Segue abaixo uma lista parcial que aborda possibilidades de riscos em um projeto (PRESSMAN, 2006):
 Orçamento/fundos de reserva
 Cronogramas
 Mudanças no escopo ou nos requisitos
 Plano do projeto
 Processo de gerenciamento do projeto
 Problemas técnicos
 Problemas com pessoal
 Hardware
 Contratos
 Problemas políticos
 Riscos empresariais
 Risco legal
 Risco ambiental
Essa lista não é exaustiva, portanto cabe ao gerente de projeto identificar e documentar todos os riscos do
projeto. O plano de gerenciamento de riscos deve especificar como os riscos serão definidos, monitorados e
controlados ao longo do projeto, esse plano faz parte do plano de projeto (HELDMAN, 2006).
Heldman (2006) sugere que uma das ferramentas para planejamento e gerenciamento dos riscos são as
reuniões com os envolvidos no projeto (cliente, equipe, gerente etc.) para discutir e documentar os principais
planos para gerenciar os riscos. Alguns dos resultados dessas reuniões são:
 Desenvolvimento dos elementos de custo de riscos para inclusão no orçamento.
 Desenvolvimento das atividades para inclusão no cronograma.
 Atribuição de responsabilidades de riscos.
 Definição ou modificação dos modelos de categorias de riscos do projeto.
 Desenvolvimento e documentação da definição de termos (probabilidade, impacto, tipos de riscos,
níveis de riscos etc.).
 Definição ou modificação da matriz de probabilidade e impacto para projeto atual.
3.3 Garantia da Qualidade de Software
A garantia da qualidade define e conduz as atividades necessárias para garantir a qualidade do software
(PRESSMAN, 2006). Sua meta é garantir à gerência informações sobre a qualidade do produto, ou seja, indicar
se a qualidade do produto está ou não satisfazendo as suas metas. No caso da identificação de problemas, cabe
à gerência do projeto fornecer os recursos necessários para que eles sejam resolvidos.
Pressman (2006) declara que existem pelo menos dois papéis envolvidos nas atividades de garantia da
qualidade. O primeiro é o dos engenheiros de software (membros da equipe de projeto), que buscam a
qualidade do projeto por meio da aplicação de métodos e medidas técnicas sólidas, da condução de revisões
técnicas formais e da execução de testes de software bem planejados. O segundo é o do grupo de garantia da
qualidade, que deve ajudar a equipe de engenheiros a obter um produto de software de qualidade com
planejamento, supervisão, registro, análises e relatos de garantia da qualidade. O detalhamento macro das
atividades desse segundo grupo é descrito abaixo:

 Preparar um plano de garantia da qualidade para o projeto:
 O plano deve ser elaborado durante o planejamento do projeto e revisado por todos os
interessados. São registradas no plano tanto as atividades do grupo de garantia da qualidade,
quanto as atividades dos membros da equipe.
 Algumas das informações registradas no plano são: (a) as avaliações, auditorias e as revisões a
serem realizadas; (b) as normas que são aplicáveis ao projeto; (c) os procedimentos para
relato e acompanhamento de não-conformidades; e (d) a documentação a ser produzida pelo
grupo de garantia da qualidade.
 Participação no desenvolvimento da descrição do processo de software do projeto:
 A equipe do projeto seleciona o processo de trabalho a ser realizado. O grupo de garantia da
qualidade revisa a descrição do processo para garantir que este atenda as políticas
organizacionais e os padrões definidos (sejam eles internos ou externos).
 Revisão das atividades de engenharia de software para verificar a satisfação do processo
de software definido:
 Documentação e acompanhamento dos desvios do processo e verificação das correções desses
desvios.
 Auditar os produtos de trabalho de software encomendados para verificar a satisfação do
que foi definido como parte do processo de software:
 Revisão dos produtos de trabalho que foram selecionados para revisão, identificação,
documentação e acompanhamento de desvios, verificação das correções. Os resultados obtidos
devem ser relatados ao gerente de projeto.
 Garantir que os desvios do processo de software e dos produtos de trabalho sejam
documentados e manipulados de acordo com o procedimento documentado:
 Os desvios podem ser encontrados no plano de projeto, na descrição do processo, nas normas
aplicáveis ou nos produtos de trabalho técnico.
 Registrar qualquer eventual não-conformidade e relatar à gerência superior:
 Os itens que não atendem ao padrão são acompanhados até que sejam resolvidos.
3.4 Medição
Para Pressman (2006), a medição:
define e reúne medidas de processo, projeto e produto que ajudam a equipe a entender um software que
satisfaça às necessidades do usuário; pode ser usada conjugada com todas as outras atividades de arcabouço e
guarda-chuva.
Segundo Kan (2003), métricas de software podem ser classificadas em três categorias: métricas de processo,
métricas de projeto e métricas de produto.
Métricas de Processo
Podem ser usadas para melhorar um processo de desenvolvimento ou de manutenção de software. Exemplos
dessas métricas podem ser a efetividade de remoção de defeitos durante o desenvolvimento; o tempo de
resposta para corrigir um problema etc. No que se refere à manutenção, pode-se citar o percentual de
problemas resolvidos durante um mês, o tempo de entrega de acertos, entre outros.
Métricas de Projeto
Descrevem as características do projeto e de sua execução, como por exemplo, número de desenvolvedores,
custo, cronograma e produtividade.
Métricas de Produto
Descrevem as características do produto, como tamanho, complexidade, características de projeto e níveis de
qualidade. A norma ISO/IEC 9126 (2001) propõe um conjunto de métricas para avaliar a qualidade de um
produto de software.
As métricas são poderosos instrumentos para a melhoria de processo. Contudo, é preciso ter muito cuidado
para que elas não sejam mal utilizadas e gerem mais problemas que benefícios à organização. Grady (apud
PRESSMAN, 2006) sugere uma “etiqueta de métricas de software”. Segundo esta etiqueta, quando um
programa de métricas é institucionalizado, deve-se:
 Usar de bom senso e sensibilidade empresarial ao interpretar dados de métricas.
 Fornecer, regularmente, realimentação aos indivíduos e equipes que coletam medidas e métricas.
 Não usar métricas para avaliar indivíduos.
 Trabalhar com profissionais e equipes, estabelecendo metas claras e métricas que deverão ser usadas
para alcançá-las.
 Nunca usar métricas para ameaçar indivíduos ou pessoas.
 Não considerar negativos os dados de métricas que indicam uma área problemática; esses dados são
meramente um indicador para melhoria do processo.
 Não ficar obcecado por uma única métrica em detrimento de outras importantes.
3.5 Revisões Técnicas Formais
A revisão técnica formal é uma atividade de garantia da qualidade. Segundo Pressman (2006), ela avalia os
produtos de trabalho da Engenharia de Software, num esforço para descobrir e remover erros, antes que eles
sejam propagados para a próxima ação ou atividade. Os objetivos das revisões são:
 Descobrir erros na função, na lógica ou na implementação, para qualquer representação do software.
 Verificar se o software sob revisão satisfaz seus requisitos.
 Garantir que o software seja representado de acordo com os padrões pré-definidos.

 Conseguir software que seja desenvolvido de forma uniforme.
 Tornar os projetos mais administráveis.
Para Pressman (2006), as revisões podem também ser usadas como forma de treinamento, pois pessoas mais
jovens têm a oportunidade de observar abordagens diferentes para realização de análise, projeto e
implementação. Sem contar que outras pessoas ficam familiarizadas com o software, o que, de alguma forma,
garante a continuidade dele. A revisão técnica formal deve gerar um relatório que responda, no mínimo, às
seguintes questões:
 O que foi revisado?
 Quem fez a revisão?
 Quais foram as descobertas e as conclusões?
3.6 Gestão de Configuração de Software
A gestão de configuração é definida por Pressman (2006) como a gerência dos efeitos das modificações ao
longo de todo o processo de software. A modificação pode ocorrer em qualquer época, por qualquer motivo.
Existem quatro fontes fundamentais de modificação:
1. As novas condições do negócio ou do mercado ditam modificações nos requisitos do produto ou nas
regras de negócio.
2. As novas necessidades do cliente exigem modificação dos dados produzidos por sistemas de
informação, da funcionalidade incorporada a produtos ou serviços realizados por um sistema baseado
em computador.
3. As reorganização ou crescimento/diminuição dos negócios causa modificações nas prioridades do
projeto ou na estrutura da equipe de engenharia de software.
4. As restrições de orçamento ou cronograma causam redefinição do sistema ou produto.
A gestão de configuração define um conjunto de atividades com o objetivo de gerenciar as mudanças ao longo
do ciclo de vida do software. As atividades do processo de gestão de configuração de software têm quatro
objetivos principais:
1. Identificar todos os itens que definem coletivamente a configuração de software (itens de
configuração).
2. Gerir modificações em um ou mais desses itens.
3. Facilitar a construção de diferentes versões de uma aplicação.
4. Garantir que a qualidade do software seja mantida à medida que a configuração evolui ao longo do
tempo.
De acordo com Pressman (2006), para que um processo atinja esses quatro objetivos é preciso que ele seja
caracterizado de forma que a equipe consiga ter respostas para um conjunto de questões complexas. São elas:
 Como uma equipe de software identifica os elementos discretos de uma configuração de software?
 Como uma organização gera várias versões existentes de um programa (e sua documentação) para
possibilitar que as modificações sejam acomodadas eficientemente?
 Como uma organização controla modificações antes e depois de o software ser entregue a um cliente?
 Quem tem responsabilidade pela aprovação e classificação das modificações?
 Como podemos garantir que as modificações foram feitas adequadamente?
 Qual o mecanismo usado para comunicar a terceiros as modificações feitas?
3.6.1 Ferramentas de Apoio para Gestão de Configuração de Software
É fundamental o uso de uma ferramenta para apoiar as atividades de gestão de configuração. Pressman (2006)
exemplifica uma lista de ferramentas que podem ser utilizadas com este objetivo:
 CVS (Concurrent Versions System) – Ferramenta usada para controle de versão. Disponível para
download em: www.cvshome.org.
 CCC/Harvest – Ferramenta usada para controle de mudança – Disponível para download em:
www.ca.com.
 ClearCase – Ferramenta que fornece uma família de funções de sistema de controle de mudança –
Disponível para download em: www.rational.com.
 PVCS – Ferramenta que fornece um conjunto completo de ferramentas de sistema de controle de
mudança – Disponível para download em: www.merant.com.
Para Saber Mais
Para conhecer mais sobre as ferramentas de gestão de configuração, consulte:
www.cmcrossroads.com/directory.html.
3.7 Gestão de Reusabilidade
A gestão da reusabilidade define os critérios para a reutilização dos produtos de trabalho (inclusive
componentes de software) e estabelece mecanismos para obter componentes reusáveis. O desenvolvimento
baseado em componentes leva à reusabilidade, e estudos comprovam: (a) redução de 70% do prazo do ciclo
de desenvolvimento e; (b) redução de 84% no custo do projeto (PRESSMAN, 2006).
A comunidade de engenheiros de software tem demonstrado poucas dúvidas no que diz respeito ao
reconhecimento das vantagens do desenvolvimento baseado em componentes (PRESSMAN, 2006). As
vantagens do reuso são refletidas não apenas no reuso de componentes, mas também dos demais produtos de
trabalho.
Além das atividades guarda-chuva apresentadas nesta aula, ainda existem outras que podem apoiar as
atividades de arcabouço de processo. Os modelos de qualidade CMMI (SEI, 2006), MPS.BR – Melhoria do
Processo de Software Brasileiro - (MPS.BR, 2007) e a norma ISO/IEC 12207 (NBR ISO/IEC 12207, 1998)
oferecem uma lista mais abrangente de processos e maiores detalhes sobre o que vem a ser cada uma dessas
atividades, inclusive aquelas que foram estudadas nesta aula.
Resumo
Essa aula ilustrou a importância das atividades guarda-chuva no arcabouço de processo da Engenharia de
Software. Na próxima aula estudaremos as características dos modelos de processo de software.
ATIVIDADES
1. Liste pelo menos três métricas que podem ser usadas para apoiar a atividade de acompanhamento e
controle do projeto.
2. Pesquise quais são os itens que compõem o planejamento de projeto e como deve acontecer seu
acompanhamento e controle.
3. Pesquise o conceito de análise de valor agregado e identifique como ela pode ser usada para
acompanhamento do projeto.
Aula 04 - Modelos de Processos de Software (Ciclo de Vida)

Nas aulas anteriores você estudou o que é a Engenharia de Software, as atividades de arcabouço de processo e
as atividades guarda-chuva. Agora é preciso saber como essas atividades são refletidas nos modelos de
processo de software. Ou seja, como é planejado o ciclo de vida do software.
Uma pergunta que precisa ser respondida: Qual o modelo de processo que a organização deve adotar para um
determinado projeto?
Para isso, é preciso conhecer quais são as características e os principais problemas encontrados nos modelos de
processos de software. Essas características e problemas serão estudados nesta aula.
4.1 Introdução
Os requisitos são entradas para um processo de software, e a saída é o fornecimento do produto (PFLEEGER,
2004). Em um processo de desenvolvimento de software, a escolha do ciclo de vida é o ponto de partida para a
arquitetura de um processo (PÁDUA, 2001).
É possível associar as atividades do arcabouço de processo da Engenharia de Software a cada um dos modelos
de processo de software que você estudará nesta aula. O que muda em cada um desses processos é a ênfase
que se dá às atividades do arcabouço e à definição do fluxo de trabalho que envolve essas atividades
(PRESSMAN, 2006).
O ciclo de vida de um processo de desenvolvimento é também conhecido como modelo de processo de
software. A seguir, veremos alguns exemplos desses modelos de processos.
4.2 Codifica-Remenda
Segundo Pádua (2001), um ciclo de vida caótico é chamado Codifica-Remenda, em que, partindo-se da
especificação (ou nem isso), os desenvolvedores começam a codificar. Quando um erro aparece, o código é
remendado para resolver o problema. Nenhum processo é seguido, ou muitas vezes, ele nem mesmo é
definido. Sendo assim, o modelo torna-se interessante para muitos desenvolvedores, pois não exige
formalismos técnicos ou gerenciais. Esse modelo gera dois tipos de problemas:
 Não é possível gerenciar o processo de desenvolvimento.
 É um modelo de alto risco e não permite assumir compromissos confiáveis.
A Figura 4.1 representa o modelo do ciclo de vida Codifica-Remenda.
Figura 4.1 – Modelo de Ciclo de Vida Codifica-Remenda
Fonte: PÁDUA, 2001.
4.3 Cascata ou Clássico
O ciclo de vida cascata ou clássico também conhecido como “linear seqüencial” foi um dos primeiros modelos
propostos e é . Sua característica principal é que os estágios são executados sequencialmente. As atividades
genéricas da Engenharia de Software podem ser facilmente acomodadas nesse modelo de processo (Figura
4.2).
A seguir, listamos as principais características e problemas do ciclo de vida cascata ou clássico segundo os
autores Pfleeger (2005), Pádua (2001) e Pressman (2006):

4.3.1 Características
 Os estágios são executados em seqüência e assim, é possível demarcá-los como ponto de controle
bem definido.
 O desenvolvimento de um estágio deve terminar antes de iniciar o próximo.
 É útil para ajudar os desenvolvedores a descrever o que eles precisam fazer.
 Sua simplicidade o torna fácil de explicar aos clientes não familiarizados com o desenvolvimento de
software.
 Explicita os produtos intermediários necessários para começar o próximo estágio de desenvolvimento.
 Outros modelos mais complexos são variações do modelo cascata, incorporando loops de feedback e
atividades extras.
Figura 4.2 – Modelo Cascata
Fonte: Pressman, 2006.
4.3.2 Principais Problemas
 Pode ser considerado um processo rígido e burocrático, pois as atividades de requisitos, análise e
projeto devem ser bem dominadas.
 Dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos.
 Projetos reais raramente seguem o fluxo seqüencial proposto pelo modelo. O software é resultado de
um processo de criação, não de fabricação.
 Não reflete a forma como o código é desenvolvido.
 Não há detalhes de como cada fase transforma um artefato em outro.
 Não fornece para os gerentes e desenvolvedores a orientação de como tratar as mudanças nos
produtos e atividades que provavelmente ocorrerão durante o desenvolvimento.
 Oferece baixa visibilidade para o cliente, que só recebe o resultado no final do projeto.
4.4 Prototipação
Segundo Pfleeger (2004), o objetivo geral desse modelo de processo é reduzir os riscos e a incerteza do
desenvolvimento. Ele inicia com a definição dos objetivos gerais do software (comunicação) e, a partir daí, as
necessidades conhecidas indicam as áreas que necessitam de mais definições. É feito um planejamento rápido
e, em seguida, a modelagem, que leva à construção e implantação. O protótipo é avaliado pelo cliente, e o
feedback é usado para refinamento dos requisitos do software. Uma nova iteração ocorre para satisfazer as
necessidades do cliente.
A seguir, apresentamos algumas características e problemas encontrados nesse ciclo de vida (PFLEEGER, 2004,
PÁDUA, 2001 e PRESSMAN, 2006):
 Pode ser usada como uma técnica de levantamento de requisitos dentro do contexto dos outros
modelos de processos de software.
 Ajuda a equipe de desenvolvimento a entender melhor o que deve ser desenvolvido quando os
requisitos não estão muito claros.
 Apóia o desenvolvedor e o cliente a chegar a um consenso sobre as necessidades e o que é proposto
no protótipo.
 Apresenta flexibilidade e visibilidade para os clientes.
 Partes do protótipo podem ser usadas para gerar programas executáveis rapidamente.
 A prototipagem agrada clientes e desenvolvedores, pois o cliente tem a sensação de receber um
sistema real, e os desenvolvedores constroem sistemas rapidamente.
A Figura 4.3 ilustra o ciclo de vida de Prototipação:
Figura 4.3 – Modelo de Processo Prototipação
Fonte: adaptado de PRESSMAN, 2006.

 Durante o desenvolvimento do protótipo, não é considerada a sua qualidade global ou
manutenbilidade em longo prazo.
 Um sistema operacional ou uma linguagem de programação inapropriada podem ser usados pelo fato
de estarem disponíveis ou serem conhecidos.
 Um algoritmo ineficiente pode ser implementado para demonstrar a sua capacidade.
 Com o passar do tempo, o desenvolvedor pode se habituar com as escolhas de conveniência, que
passam a fazer parte integral do sistema.
 É um mecanismo importante para o levantamento de requisitos, mas tanto o cliente quanto o
desenvolvedor devem estar cientes de que o protótipo será descartado, ou pelo menos boa parte dele,
pois o produto deve ser submetido aos processos de engenharia de software.
 Requer planejamento sofisticado.
4.5 Espiral
A principal preocupação do modelo espiral, ilustrado na Figura 4.4, está focada na análise e controle dos riscos,
em que são combinadas as atividades genéricas da Engenharia de Software com o gerenciamento de riscos. Em
cada iteração, a análise de riscos avalia as alternativas em relação aos requisitos e restrições da iteração em
questão (PFLEEGER, 2004).
Os problemas e características desse ciclo são listados a seguir (PFLEEGER, 2004, PÁDUA, 2001 e PREESMAN,
2006):
 É um modelo iterativo que combina a natureza iterativa com prototipagem.
 Cada nova iteração corresponde a uma volta no espiral (em sentido horário) e as últimas iterações
produzem versões cada vez mais completas do sistema.
 Cada passagem pela região de planejamento gera ajustes no plano de projeto.
 Combina atividades de desenvolvimento com gerenciamento de riscos, para minimizar e controlar os
riscos.
 Insere no processo de desenvolvimento uma etapa para avaliar riscos e protótipos alternativos.
 A prototipação avalia viabilidade e adequação antes que se decida por alguma alternativa.
 Quando identificam-se riscos, a gestão de projetos decide como eliminar ou minimizar cada risco.
 O modelo espiral permanece operacional desde a definição do software até que ele seja descontinuado
(retirado de operação).
Figura 4.4 – Modelo de Processo Espiral
 Pode ser difícil convencer o cliente de que a abordagem evolucionária pode ser controlada.
 A gestão do projeto deve ser sofisticada para ser previsível e confiável. O gerente de projetos deve
planejar a quantidade de iterações para completar o software.
 Exige muita competência do gerente de projeto na avaliação de riscos e depende dessa competência
para ter sucesso.
 Se riscos importantes não forem identificados e gerenciados, certamente ocasionarão problemas.
4.6 Desenvolvimento em Fases (Incrementos e Iterações)
Os modelos de processos mais recentes têm como objetivo diminuir o tempo de desenvolvimento e evitar que
os usuários tenham que esperar indefinidamente até a entrega do sistema. O desenvolvimento em fases, como
mostra a Figura 4.5, permite que um grupo de funcionalidades seja entregue enquanto as demais
funcionalidades estão em desenvolvimento.

Figura 4.5 – O Modelo de Desenvolvimento em Fases
Fonte: PFLEEGER, 2004.
Nesse modelo de processo, o planejamento das atividades para construção das versões do sistema pode ser
feito de diferentes formas, mas as duas abordagens mais comuns, segundo Pfleeger (2004), são: o
desenvolvimento incremental (Figura 4.6) e o desenvolvimento iterativo (Figura 4.7).
No desenvolvimento incremental, o sistema, como especificado na documentação dos requisitos, é dividido em
subsistemas por funcionalidades. As versões são definidas, começando por um pequeno subsistema funcional e,
então, adicionando mais funcionalidades a cada versão.
Figura 4.6 – Desenvolvimento Incremental
O desenvolvimento iterativo entrega um sistema completo desde o começo e, então, muda a funcionalidade de
cada subsistema a cada nova versão. A Figura 4.7 ilustra três versões de um desenvolvimento iterativo.
Figura 4.7 – Desenvolvimento Iterativo
A Figura 4.8 representa o modelo de processo incremental.
Figura 4.8 – Modelo de Processo Incremental
 Combina elementos do modelo em cascata aplicado de maneira iterativa.
 Cada seqüência produz incrementos de software possíveis de serem entregues. Cada incremento deve
ser operacional para o usuário.
 Os primeiros incrementos são versões simplificadas do produto final, mas são operacionais para o
usuário.
 O fluxo de processo para qualquer incremento pode incorporar o paradigma da prototipagem (modelo
de processo Prototipação).
 O primeiro incremento normalmente é chamado de “núcleo do produto”. Esse núcleo é usado pelo
cliente (ou passa por revisão detalhada).
 Um plano é desenvolvido para o próximo incremento, como resultado do uso e/ou avaliação. O plano
visa à modificação do núcleo do produto para melhor satisfazer às necessidades do cliente e à
elaboração de características e funcionalidades adicionais. Esse processo é repetido após a realização
de cada incremento, até que o produto completo seja produzido.
 É útil quando não há mão-de-obra disponível para uma implementação completa dentro do prazo
comercial de entrega estabelecido para o projeto. Os primeiros incrementos podem ser
implementados com menos pessoal.
 Os incrementos podem ser planejados para gerir os riscos técnicos.
4.7 RAD (Rapid Application Development)
Este modelo de processo trabalha com uma abordagem incremental com foco em ciclos de desenvolvimento
curtos. É uma adaptação do modelo cascata (PRESSMAN, 2006), em que o ciclo de desenvolvimento deve ser
rápido com uma variação de 60 a 90 dias. A capacidade de desenvolvimento rápido se baseia na construção e
reutilização de componentes.
A Figura 4.9 apresenta o ciclo de vida RAD.

Figura 4.9 – O Modelo RAD
De acordo com Pressman (2006), as principais características e problemas do RAD são:
 Encaixa-se nas atividades genéricas do desenvolvimento de software.
 A comunicação tem como objetivo entender os problemas do cliente e os requisitos do software.
 O planejamento é essencial para o RAD, pois várias equipes trabalham em paralelo. Cada função pode
ser tratada por uma equipe RAD distinta, e depois integrada para formar um todo.
 A modelagem estabelece as representações de projeto, que servem como base para as atividades de
construção.
 A construção foca no uso de componentes existentes e na geração automática de código.
 A implantação é a base para as novas iterações, quando necessário.
 O desenvolvimento deve ser acomodado em um prazo não superior a três meses.

 Exige recursos humanos suficientes para criar um número adequado de equipes RAD.
 Os desenvolvedores e clientes devem estar comprometidos com as atividades continuamente rápidas,
necessárias para completar o sistema em um curto espaço de tempo, ou os projetos RAD falharão.
 Se o sistema não puder ser adequadamente modularizado, a construção dos componentes necessários
ao RAD será problemática.
 Se for necessário um alto desempenho, e esse desempenho tiver de ser conseguido ajustando as
interfaces dos componentes do sistema, a abordagem RAD pode não funcionar.
 Pode não ser adequado quando os riscos técnicos são altos (por exemplo: quando uma nova aplicação
faz bastante uso de nova tecnologia).
Além dos ciclos de vida apresentados acima, a literatura discute outros modelos de processo de software que
não foram tratados nesta aula, alguns exemplos são: Técnicas de Quarta Geração; Modelo em V; Modelo
Baseado em Componentes; Métodos Formais; Método Orientado a Aspectos; Especificação Operacional e
Modelo Transformacional. Existem ainda os ciclos que são adaptados por meio da combinação de dois ou mais
modelos.
Segundo Pressman (2006), todos os modelos de processo de software se enquadram nas atividades do
arcabouço de processo da Engenharia de Software. No entanto, esses modelos devem ser selecionados e
adaptados de acordo com as características de cada projeto (problema, equipe e cultura organizacional). Os
modelos de processo se diferenciam nos seguintes aspectos:
 No fluxo geral de atividades e tarefas e interdependências entre elas.
 No grau em que as tarefas de trabalho são definidas dentro de cada atividade do arcabouço.
 No grau em que os produtos de trabalho são identificados e solicitados.
 Na maneira como as atividades de garantia da qualidade são aplicadas.
 No modo como o monitoramento de projeto e as atividades de controle são aplicados.
 No grau geral de detalhes e rigor em que o processo é descrito.
 No grau em que clientes e outros interessados estão envolvidos no projeto.
 No nível de autonomia da equipe de projeto de software.
 No grau em que a organização da equipe e os papéis são prescritos.
Resumo
Nessa aula você estudou os modelos de processo de software (ou ciclos de vida). A seleção de um ciclo de vida
é o ponto de partida para dar início a um projeto de desenvolvimento de software. O ciclo de vida deve ser
selecionado de acordo com as características de cada projeto.
Existem outros modelos de processo de software além daqueles apresentados aqui. Antes de ir para a próxima
aula, aproveite para pesquisar um pouco mais sobre esses ou outros modelos que você considere interessantes.
ATIVIDADES
1. Esboce, graficamente, um processo de software que tenha a combinação de pelo menos dois dos
ciclos de vida estudados anteriormente. Faça uma descrição do ciclo de vida que você criou.
2. Selecione um modelo de processo e descreva como as atividades de arcabouço podem ser
enquadradas nesse modelo.
3. Selecione um modelo de processo e explique como as atividades guarda-chuva podem ser
enquadradas nesse modelo.
Sistematização
Chegamos ao final da disciplina. Agora é hora de colocar em prática o aprendizado adquirido durante as aulas.
Sendo assim, no contexto de desenvolvimento de software, responda às questões abaixo:
1. As atividades guarda-chuva ocorrem ao longo do processo de desenvolvimento de software. Você
acha que elas são aplicadas uniformemente em todo o processo ou são mais concentradas em uma ou
mais atividades de arcabouço? Justifique sua resposta.
2. Dentre os processos de software estudados em aula, qual deles lhe dá mais flexibilidade para mudar
em relação aos requisitos?
3. Uma organização de desenvolvimento de software deveria adotar um único modelo de processo para
todo o desenvolvimento de software que ela realiza? Justifique.
4. Proponha um template para elaboração de um plano de projeto.
5. Descreva como a atividade guarda-chuva de garantia da qualidade pode apoiar cada uma das
atividades de arcabouço de processo de software.
6. Defina um processo de desenvolvimento de software com atividades e tarefas que contemplem as
atividades de arcabouço e as atividades guarda-chuva.
(*) Algumas questões foram baseadas nos livros de Pressman (2006) e Pfleeger (2004).
Referências
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207:1998. Tecnologia da Informação –
Processos de ciclo de vida do software. Rio de Janeiro: ABNT, 1998.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de
Avaliação, versão 1.2, junho 2007. Disponível em: www.softex.br Acesso em: 20 fev. 2008.
HELDMAN, Kim. Gerência de projetos. 3. ed. Campus, 2006.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND INTERNATIONAL ELECTROTECHNICAL
COMMISSION. ISO/IEC 9126 Software engineering – Product quality – Part 1, 2001.
KAN, M. Stephen. Metrics and models in software quality engineering. 2nd ed., Addison-Wesley, 2003.
PÁDUA, Wilson de Paula. Engenharia de software: fundamentos, métodos e padrões. 1. ed. LTC, 2001.
PFLEEGER, S. Lawrence. Engenharia de software: teoria e prática. 2. ed. Pearson, 2004.
PMBOK (PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of
Knowledge – PMBOK™, Syba: PMI Publishing Division, 2004.
PRESSMAN, Roger. Engenharia de software. 3. ed. Makron Books, 1995.
______. Engenharia de software. 5. ed. Makron Books, 2001.
______. Engenharia de software. 6. ed. Makron Books, 2006.
SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.2, Technical report
CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2006.
Glossário
Ação corretiva – Ato ou ação utilizados para remediar uma situação, remover um erro ou ajustar uma
condição.
Análise de valor agregado – É uma medida de progresso. Ela permite avaliar a “porcentagem de execução”
de um projeto, usando a análise quantitativa, em vez de confiar em um sentimento.
Arcabouço – Armação de uma construção.
Arcabouço de processo – Estabelece o alicerce para um processo de software completo pela identificação de
um pequeno número de atividades de arcabouço aplicáveis a todos os processos de software,
independentemente de seu tamanho ou complexidade. Além disso, o arcabouço de processo engloba um
conjunto de atividades guarda-chuva que são aplicáveis durante todo o processo de software.
Atividade guarda-chuva – Atividades que são aplicadas durante todo o processo de software.
CMMI (Capability Matury Model Integration) – Metamodelo de processo, desenvolvido pelo SEI (Software
Engineering Institute), baseado em um conjunto de capacidades de engenharia de software que devem estar
presentes à medida que as empresas alcançam diferentes níveis de capacidade e maturidade de processo.
D
Desenvolvedor – É a empresa, organização ou pessoa que está construindo o sistema de software para o
cliente. Pessoa responsável pelo desenvolvimento da funcionalidade necessária do software, de acordo com os
procedimentos e os padrões adotados no projeto. Isto inclui a realização de atividades em qualquer uma das
fases: requisitos, análise e design, implementação e teste.
Ferramenta – É um instrumento ou sistema automatizado utilizado para realizar uma tarefa. Fornece apoio
automatizado para os processos e para os métodos.
Impacto (de riscos) – É a quantidade de danos (ou ganhos) que um evento de risco representa para um
projeto.
Item de configuração de software – É a informação criada como parte do processo de engenharia de
software.
Joint Application Develpment (JAD) – É uma técnica estruturada de condução de reuniões, aplicável a
diversas atividades de0 desenvolvimento de software.
Marco de projeto – Um ponto ou evento significativo no projeto.
Método – É um procedimento formal para produzir algum resultado.
Modelo de processo – É um modelo de processo de software (veja processo de software).
Política organizacional – Um princípio de direcionamento normalmente estabelecido pela gerência sênior,
que é adotado por uma organização para influenciar e determinar decisões.
Probabilidade (de riscos) – É a chance de um evento ocorrer.
Procedimentos – Combinam as ferramentas e os métodos para que eles produzam um determinado resultado.
Processo de software – Uma série de passos previsíveis – um roteiro que ajuda criar, a tempo, um resultado
de alta velocidade para a construção de um determinado produto.
Produto de trabalho – Artefato produzido por um processo.
Riscos – Ameaças ou oportunidades no projeto.
Software – É o produto que os profissionais de software constroem e, depois, mantêm ao longo do tempo.
São: (1) instruções (programas de computadores) que quando executadas fornecem características, funções e
desempenhos desejados; (2) estruturas de dados que permitem aos programas manipular adequadamente a
informação; (3) documentos que descrevem a operação e o uso dos programas.
Técnica – É como fazer para construir softwares; abrange tarefas que incluem comunicação, análise de
requisitos, modelagem de projeto, construção, testes e manutenção.

Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Introdução a Ferramentas. Ferramentas de planejamento de projeto; de processo de software.

 Compreender os conceitos básicos da Engenharia de Software.

 Identificar as atividades mínimas necessárias ao desenvolvimento de software e às atividades que

apóiam o processo de desenvolvimento.

 Selecionar modelos de processos que melhor se adaptem às características do projeto a ser

sem falar em uma das maiores invenções humanas contemporâneas: a Internet.

sistematicamente utilizados também na construção do Software, daí o termo Engenharia de Software.

a construção de software economicamente viável e que funcione eficientemente em máquinas reais.”

Aula 1 – Introdução à Engenharia de Software

 1.1 Engenharia de Software: uma tecnologia em camadas

 1.2 Quem faz Engenharia de Software?

 1.3 Membros de equipe de desenvolvimento

 2.2 Atividades de arcabouço

Aula 3 – Atividades Guarda-Chuva

 3.1 Acompanhamento e controle de projeto

 3.1.1 Ferramentas de apoio para acompanhamento e controle do projeto

 3.2 Gestão de risco

 3.3 Garantia da qualidade de software

 3.5 Revisões técnicas formais

 3.6 Gestão de configuração de software

 3.6.1 Ferramentas de apoio para gestão de configuração de software

 3.7 Gestão de reusabilidade

Aula 4 – Modelos de Processos de Software (Ciclo de Vida)

 4.3 Cascata ou clássico

 4.3.2 Principais problemas

 4.4.2 Principais problemas

 4.5.2 Principais problemas

 4.6 Desenvolvimento em fases (incrementos e iterações)

 4.7 RAD (Rapid Application Development)

 4.7.2 Principais problemas

Aula 01 - Introdução à Engenharia de Software

forma de abordar um problema.” Scott Whitmire (apud PRESSMAN, 2006)

1.1 Engenharia de Software: Uma Tecnologia em Camadas

sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a

aplicação da engenharia ao software.

de software acrescido de tecnologias que constituem um processo (métodos, técnicas e ferramentas

na qualidade). A camada de processo define um arcabouço e foca-se no desenvolvimento rápido e oportuno de

é adotada quando o software é elaborado.

modelagem de projeto, construção, testes e manutenção (PRESSMAN, 2006).

do produto resultante (PFLEEGER, 2004).

sistema de apoio ao desenvolvimento, chamado de Engenharia de Software Apoiada por Computador

Fonte: PRESSMAN, 2001.

Os procedimentos combinam as ferramentas e os métodos, para que estes produzam um determinado

desenvolvido atende aos requisitos do software (PFLEEGER, 2004).

qualidade dos produtos de software.

1.2 Quem faz Engenharia de Software?

Para Pfleeger (2004), a comunicação entre clientes e desenvolvedores é um elemento chave no

quais são as suas necessidades.

Dependendo do tamanho e da complexidade do sistema, muitas pessoas serão envolvidas no processo de

desenvolvedor. Essas categorias são descritas a seguir:

porém, o papel do cliente e do usuário confunde-se.

Figura 1.2 – Participantes do Desenvolvimento de Software

Fonte: adaptado de PFLEEGER, 2004.

em uma equipe de desenvolvimento.

1.3 Membros de uma Equipe de Desenvolvimento

desenvolvedores podem se especializar em aspectos específicos e desempenhar diferentes papéis durante o

desenvolvimento. Os papéis dos membros da equipe de desenvolvimento são listados a seguir:

as principais características desse perfil são (PRESSMAN, 1995):

 Capacidade de compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar

“soluções” baseadas em cada problema.

 Capacidade de absorver fatos pertinentes de fontes conflitantes ou confusas.

 Capacidade de aplicar elementos do sistema de hardware e/ou software aos elementos do

 Capacidade de se comunicar bem nas formas escrita e verbal.