PROJETO

DE
SOFTWARE

REFERÊNCIA

1. Pressman, Engenharia de Software

 SUMÁRIO

1) Software e Engenharia de Software

MÓDULO 1 - O PROCESSO DE SOFTWARE

2) Processo - Uma Visão Genérica

3) Modelos Prescritivos de Processo
4) Desenvolvimento Ágil

MÓDULO 2 - PRÁTICA DE ENGENHARIA DE SOFTWARE

5) Prática - Uma visão genérica

6) Engenharia de Sistemas
7) Engenharia de Requisitos
8) Modelagem de Análise
9) Engenharia de Projeto
10) Projeto Arquitetural
11) Projeto no nível de Componentes
12) Projeto de Interface com o usuário
13) Estratégias de Testes de Software
14) Técnicas de Teste de Software
15) Métricas de Projeto de Software

MÓDULO 3 - APLICAÇÃO DE ENGENHARIA DA WEB

16) Engenharia da Web

17) Formulação e Planejamento para Engenharia da Web
18) Modelagem de Análise para Aplicações Web
19) Modelagem de Projeto para Aplicações Web
20) Teste de Aplicações Web

MÓDULO 4 - GESTÃO DE PROJETOS DE SOFTWARE

21) Conceitos de Gestão de Projetos

22) Métricas de Processo e Projeto
23) Estimativa de Projetos de Software
24) Cronogramação de Projeto de Software
25) Gestão de Risco
26) Gestão de Qualidade
27) Gestão de Modificações

MÓDULO 5 - TÓPICOS AVANÇADOS DE ENGENHARIA DE SOFTWARE

28) Métodos Formais

29) Engenharia de Software de Sala Limpa
30) Engenharia de Software Baseada em Componentes
31) Reengenharia
32) A Estrada Adiante

1) Software e Engenharia de Software

• Década de 50 ninguém previu a importância do software, ele evoluiu de

ferramenta especializada para produto;
• Software tem duplo papel: produto e veículo de entrega do produto;
• Software é o elemento chave na evolução de sistemas e produtos baseados
em computador e uma das tecnologias mais importantes do mundo;
• A produção de software apresenta uma série de problemas, como obter
qualidade e obedecer prazos e orçamento
• Os computadores tornaram fáceis uma série de coisas, mas a maior parte
das coisas que eles facilitam não precisam ser feitas;
• Categorias do software:
1. Software de Sistemas = coleção de programas escritos para servir a outros
programas;
2. Software de Aplicação = Programas isolados que resolvem uma
necessidade específica do negócio;
3. Software Científico e de Engenharia;
4. Software Embutido;
5. Software para Linhas de Produtos (ex.: controle de estoque);
6. Aplicações da Web;
7. Software para IA = Faz uso de algoritmos não numéricos para resolver
problemas complexos que não são passíveis de computação ou Análise
direta (ex.: sistemas especialistas, redes nerais, reconhecimento de padrões,
jogos,...);
 8. Computação Ubíqua (computação distribuída);
9. Netsourcing (sistemas distribuídos para usando a WEB);
10. Software Aberto
• Software legado;
Referências:
• http://www.softwarehistory.org
• http://www.yourdon.com
• http://shareware.cnet.com
• http://dir.salon.com/story/tech/feature/2002/04/08/lehman/index.html

MÓDULO 1 - O PROCESSO DE SOFTWARE

2) Processo - Uma Visão Genérica

• Software, como todo capital, é conhecimento incorporado, estando

inicialmente disperso, tácito, latente e incompleto;
• O desenvolvimento de software é um processo iterativo de aprendizagem e
o resultado é a incorporação de conhecimentos coletados, destilados e
organizados, à medida que o processo e conduzido;
• Processo de Desenvolvimento de Software é um arcabouço para as tarefas
necessárias para a construção de softwares com qualidade;
• Processo de Software não é Engenharia de Software;
• Engenharia de Software é a criação e utilização de sólidos princípios de
engenharia a fim de obter softwares econômicos, que sejam confiáveis e que
trabalhem eficientemente em máquinas reais;
• A Engenharia de Software é uma tecnologia em :
1. Foco na Qualidade
2. Processo
3. Métodos
4. Ferramentas
• Arcabouço de Processo estabelece o alicerce para um processo de software
completo. Ele identifica um pequeno número de atividades de arcabouço,
aplicáveis a todos os projetos de software, independentemente de seu
tamanho ou complexidade;
• Arcabouço de Processo Genérico:
1. Comunicação (cliente e outros interessados)
2. Planejamento
3. Modelagem
4. Construção
5. Implantação
• O arcabouço genérico da Engenharia de Software é complementado por
várias atividades guarda-chuva, como por exemplo:
1. Acompanhamento e Controle de Projeto de Software;
2. Gestão de Risco;
3. Garantia de Qualidade de Software;
4. Revisões Técnicas Formais;
5. Medição;
6. Gestão de Configuração de Software;
7. Gestão de Reusabilidade;
8. Preparação e Produção do Produto de Trabalho;
• Cada ação de Engenharia de Software é representada por um conjunto de
tarefas, cada um com:
1. Tarefas de Trabalho de Engenharia de Software;
2. Produtos de Trabalho Relacionados;
3. Pontos de Garantia de Qualidade; e
4. Marcos de Projeto
• CMMI: Metamodelo de processo baseado em um conjunto de capacidades
de Engenharia de Software, que devem estar presentes, à medida que as
empresas alcaçam diferentes níveis de capacidade e maturidade de
processo. Para atingir essas capacidades a SEI estabelece que as
organizações devem desenvolver modelos de processo que sigam as
diretrizes CMMI;
• PADRÃO DE PROCESSO: gabarito, um método consistente para descrever
uma característica importante do processo de software. Pela combinação de
processos uma equipe de projeto pode construir um processo que melhor
satisfaça às necessidades de um projeto. A seguir é descrito um modelo
para definir um padrão de processo:
1. Nome do Padrão;
2. Intenção;
3. Tipo: Tarefa, Estágio e Fase;
4. Contexto Inicial;
5. Problema;
6. Solução;
7. Contexto Resultante;
8. Padrões Relacionados;
9. Usos Conhecidos/exemplos
 • Avaliação de Processo, algumas propostas:
1. SCAMPI;
2. CBA IPI;
3. ISO 9001:2000 para Software
Referências:
• http://standards.ieee.org
• http://www.sei.cmu.edu/
• http://pt.wikipedia.org/wiki/CMMI
• http://pt.wikipedia.org/wiki/ISO_9001#ISO_9001:2000

3)Modelos Prescritivos de Processo

• Os modelos prescritivos de processo foram originalmente propostos para

colocar ordem no caos do desenvolvimento de sofware;
• Um modelo prescritvo define um conjunto distinto de atividades, ações
tarefas, marcos e produtos de trabalho, que são necessários para fazer
Engenharia de Software com alta qualidade;
• Modelo de Ciclo de Vida
• Modelo de Desenvolvimento em Cascata
• Modelos Incrementais de Processo:
1. Modelo Incremental
2. Modelo RAD
• Enfatiza um ciclo de desenvolvimento curto;
• É uma adaptação em "alta velocidade" do modelo em cascata;
• O desenvolvimento rápido é conseguido c/uma abordagem de
construção baseada em componentes
 • Modelos Evolucionários de Processo de Software
1) Prototipagem
• O cliente normalmente identifica requisitos gerais, não identificando
detalhadamente requisitos de entrada, processamento ou saída;
• É difícil definir com precisão a interação homem/máquina;
• Pode ser um modelo de processo independente ou embutida em outro
modelo;
• Um protótipo é um excelente meio de coletar os requisitos de um
software;

2) Modelo Espiral
• Combina a natureza iterativa da prototipagem com aspectos consolidados e
sistemáticos do modelo em cascata;
3) Modelo de Desenvolvimento Concorrente
• É aplicável a todos os tipos de desenvolvimento de software e fornece
uma imagem precisa do estado atual do projeto;

• Modelos Especializados de Processo

1) Desenvolvimento Baseado em Componentes
• Componentes de software comercial de prateleira (COTS);
• Incorpora muitas das características do modelo espiral;
2) Modelo de Métodos Formais
• Conjunto de atividades que levam à especificação matemática formal
do programa;
 3) Desenvolvimento de Software Orientado a Aspectos
4) Processo Unficado

4) Desenvolvimento Ágil

• Combina filosofia e diretrizes de desenvolvimento;

• É valorizado o cumprimento da entrega do produto e não as atividades de
A&P;
• O ambiente moderno que usa sistemas computacionais é apressado e
sempre mutável;
• Manifesto para Desenvolvimento Ágil de Software
• Modelos Ágeis de Processo:
1. Extreme Programming(XP)
2. DAS
3. DSDM
4. SCRUM
5. Crystal
6. FDD (Desenvolvimento guiado por características)
7. Modelagem Ágil
• Filosofia para Desenvolvimento Ágil:
 1. Importância de equipes auto-organizadas, com controle sobre o trabaho que
executam;
2. Comunicação e colaboração entre os membros da equipe e entre profissionais
e seus clientes;
3. Reconhecimento de que modificações representam uma oportunidade;
4. Ênfase na entrega rápida de softwares que satisfaçam o cliente;

MÓDULO 2 - PRÁTICA DE ENGENHARIA DE SOFTWARE

5) Prática - Uma visão genérica

A prática da Engenharia de Software envolve conceitos, princípios e ferramentas

que projetistas de software aplicam durante todo o processo de software.

5.1) Prática da Engenharia de Software

• A prática é um amplo conjunto de conceitos, princípios e ferramentas que

podem ser usadas à medida que o software vai sendo planejado e
desenvolvido;
• A prática de ES é exercida por engenheiros de software e gerentes;
• O processo de desenvolvimento de software fornece um roteiro e a prática
os detalhes para alcançar os objetivos;
• Essência da Prática:
1. Entenda o problema (comunicação e análise)
◦ Quem tem interesse na solução;
◦ Quais são as incógnitas;
◦ O problema pode ser compartimentalizado;
◦ O problema pode ser representado graficamente;
2. Planeje uma solução (modelagem e projeto de software):
◦ Existem problemas análogos;
◦ Um problema semelhante foi resolvido;
◦ Podem ser definidos subproblemas;
◦ Pode ser representada uma solução efetiva para o problema;
3. Execute o plano (geração de código)
◦ A solução está de acordo com o plano;
◦ Cada componente da solução está correto;
4. Examine o resultado quanto à precisão (teste e garantia de qualidade)
◦ É possível testar cada componente da solução;
 ◦ A solução produz resultados de acordo com os dados, funções,
características e comportamentos que são necessários;
• Princípios centrais do Desenvolvimento de software:
1. Porque tudo existe;
2. KSS;
3. Mantenha a visão;
4. O que você produz os outros vão consumir;
5. Esteja aberto para o futuro;
6. Planeje com antecedência o reuso;
7. Pense, raciocine clara e completamente antes da ação, produz
melhores resultados;
5.2) Práticas de Comunicação
• Escute;
• Prepare-se antes de comunicar;
• Alguém deve facilitar a atividade;
• Comunicação face a face e melhor;
• Faça anotações e documente as decisões;
• Busque colaboração;
• Conserve-se focado, modularize sua discussão;
• Se algo não está claro, desenhe uma figura;
• Prossiga independentemente de não concordar e se algum esclarecimento
não foi prestado;
• Negociação não é um concurso ou jogo, funciona melhor quando ambas as
partes ganham;
5.3) Práticas de Planejamento:
• Entenda o escopo do projeto;
• Envolva o cliente na atividade de planejamento;
• Reconheça que o planejamento é iterativo;
• Estime com base no que é sabido;
• Considere riscos à medida que um plano é definido;
• Seja realista (as pessoas não trabalham 100% todos os dias);
• Ajuste a granularidade à medida que o plano é definido;
• Defina como garantir a qualidade;
• Descreva como controlar e implementar modificações;
• Acompanhe o plano com freqüência e faça ajustes quando necessário;

W5HH
 • Porque o sistema está sendo desenvolvido (Why);
• O que será feito (What);
• Quando será concluído (When);
• Quem será o responsável por uma função (Who);
• Onde estão localizados na organização (Where);
• Como o trabalho será conduzido técnica e gerencialmente (How);
• Quanto é necessário de cada recurso (How Much)

5.4) Práticas de Modelagem

5.4.1) Princípios da Modelagem de Análise
• O domínio da Informação de um problema precisa ser representado e
entendido;
• As funções a serem desenvolvidas no software devem ser definidas;
• O comportamento o software, como conseqüência de eventos externos,
precisa ser representado;
• Os modelos que mostram informação, função e comportamento devem ser
particionados de modo que revelem detalhes em forma de camadas;
• A tarefa de análise deve ir da informação essencial até os detalhes de
implementação;
5.4.2) Principios da Modelagem de Projeto
• O projeto deve estar relacionado ao modelo de análise;
• Sempre considere a arquitetura do sistema a ser construído;
• O projeto dos dados é tão importante quanto o projeto de funções de
processamento;
• As interfaces (tanto internas quanto externas) precisam ser projetadas com
cuidado;
• O projeto de interface do usuário deve estar sintonizado com as
necessidades do usuário final, enfatizando no entanto a facilidade de uso;
• O projeto em nível de componente deve ser funcionalmente independente;
• Os componentes devem ser acoplados fracamente uns aos outros e ao
ambiente externo;
• Representações de projeto devem ser facilmente compreensíveis;
• O projeto deve ser desenvolvido iterativamente, lutando sempre por maior
simplicidade;
• Conjunto genérico de tarefas para projeto:
1. Usando a Análise escolher um padrão(estilo) para o projeto;
2. Particionar o modelo de análise em subsistemas;
3. Projetar a interface do usuário;
 4. Conduzir o projeto em nível de componentes;
5. Desenvolver um modelo de implantação
5.5) Práticas de Construção
5.5.1) Princípios e conceitos de codificação
• Princípios de Preparação (antes de escrever uma linha de código):
1. Entenda o problema;
2. Entenda os princípios e conceitos básicos do projeto;
3. Escolha uma linguagem de programação que satisfaça às
necessidades do software e do ambiente em que ele vai operar;
4. Selecione um ambiente de programação que forneça ferramentas
para facilitar o trabalho;
5. Crie um conjunto de testes unitários, que possam ser aplicados, tão
logo os componentes que estão sendo codificados, estejam prontos;
• Principios de Codificação (quando começar a codificar):
1. Restringir seus algoritmos, seguindo a prática de programação
estruturada;
2. Selecione estrutura de dados que atendam às necessidades do
projeto;
3. Entenda a arquitetura do software e crie interfaces que sejam
consisentes com ela;
4. Conserve a lógica condicional, tão simples quanto possível;
5. Crie ciclos aninhados, de modo que sejam facilmente testáveis;
6. Selecione nomes significativos de variáveis e siga outras normas
locais de codificação;
7. Escreva código que é autodocumentado;
8. Crie uma disposição visual que facilite o entendimento do código;
9.
• Principios de Validação (após completar o primeiro passo de codificação):
1. Conduzir uma inspeção de código quando adequado;
2. Realizar testes unitários, corrigindo erros descobertos;
3. Refabricar o código.
5.5.2) Princípios de teste:
• Todos os testes devem estar relacionados aos requisitos do cliente;
• Os testes devem ser planejados muitos antes de serem iniciados;
• O principio de Pareto se aplica ao teste de software (80 - 20);
• Conjunto Genérico de Tarefas de Teste:
1. Projetar testes de unidade para cada componente de software
2. Desenvolver uma estratégia de integração
 3. Desenvolver uma estratégia de validação
4. Conduzir os testes de integração e validação
5. Conduzir os teste de alta prioridade
6. Coordenar os testes de aceitação com o cliente
5.6) Práticas de Implantação
• A atividade de implantação envolve 3 ações:
1. Entrega;
2. Suporte;e
3. Realimentação.
• Principios chave da Implantação:
1. As expectativas do cliente quanto ao software devem ser geridas;
2. Um pacote completo de entrega deve ser montado e testado;
3. Um regime de suporte deve ser estabelecido antes do software ser
entregue;
4. Materiais institucionais adequados devem ser fornecidos aos
usuários finais;
5. O software deve ser corrigido primeiro e depois entregue.
• Conjunto Genérico de Tarefas de Implantação:
1. Criar mídia de entrega;
2. Estabelecer suporte humano pessoal ou em grupo;
3. Estabelecer mecanismos de feed-back dos usuários;
4. Disseminar a mídia de entrega entre todos os usuários;
5. Conduzir funções de suporte permanentes;
6. Coletar feed-back dos usuários;

6) Engenharia de Sistemas

• Focaliza elementos do sistema: objetivo geral, arquitetura de hardware,

software, pessoal, base de dados, procedimentos e outros elementos do
sistema;
• O processo de Engenharia de Sistemas toma diversas formas, visando
organizar o desenvolvimento de sistemas baseado em computadores:
1. Engenharia de Processo de Negócio;
2. Engenharia de Produto;

6.1) Sistemas Baseados em Computador;

 • Principais elementos: software, hardware, pessoal, BD, documentação e
procedimentos;

6.2) A Hierarquia da Engenharia de Sistemas

• Independentemente do domínio de enfoque, a ES abrange Métodos top-

down e bottom-up para navegar na hierarquia de ES:
1. Visão de Mundo;
2. Visão do Domínio;
3. Visão do Elemento;
4. Visão Detalhada;
• Modelagem de sistemas - fatores restritivos:
1. Pressupostos;
2. Simplificações;
3. Limitações;
4. Restrições;
5. Preferências
• Simulação de Sistemas;

6.3) Engenharia de Processo de Negócio

• Define arquiteturas que permitem a um negócio usar informações de

maneira efetiva;
• 3 arquiteturas que devem ser analisadas:
1. Arquitetura de Dados;
2. Arquitetura de Aplicações;
3. Infra-Estrutura Tecnológica;

6.4) Engenharia de Produto

• Traduz o desejo do cliente de um conjunto de capacidades definidas para

um produto em funcionamento;

6.5) Modelagem de Sistemas

• Os modelos de sistemas tendem a ser em camadas (hierárquicos);

• Modelo de Hatley-Pirbhai - todo sistema baseado em computador pode ser
modelado como uma transformação usando um gabarito entrada-saída;
 • Modelagem com UML;

7) Engenharia de Requisitos

7.1) Uma ponte para o Projeto e a Construção;

7.2) Tarefas para a Engenharia de requisitos:

• Concepção;
• Levantamento;
• Elaboração;
• Negociação;
• Especificação;
• Validação;
• Gestão de Requisitos;

8) Modelagem de Análise
9) Engenharia de Projeto
10) Projeto Arquitetural
11) Projeto no nível de Componentes
12) Projeto de Interface com o usuário
13) Estratégias de Testes de Software
14) Técnicas de Teste de Software
15) Métricas de Projeto de Software

MÓDULO 3 - APLICAÇÃO DE ENGENHARIA DA WEB

16) Engenharia da Web

17) Formulação e Planejamento para Engenharia da Web
18) Modelagem de Análise para Aplicações Web
19) Modelagem de Projeto para Aplicações Web
20) Teste de Aplicações Web

MÓDULO 4 - GESTÃO DE PROJETOS DE SOFTWARE

21) Conceitos de Gestão de Projetos

22) Métricas de Processo e Projeto
23) Estimativa de Projetos de Software
24) Cronogramação de Projeto de Software
25) Gestão de Risco
26) Gestão de Qualidade
27) Gestão de Modificações

MÓDULO 5 - TÓPICOS AVANÇADOS DE ENGENHARIA DE SOFTWARE

28) Métodos Formais

29) Engenharia de Software de Sala Limpa
30) Engenharia de Software Baseada em Componentes
31) Reengenharia
32) A Estrada Adiante

TÓPICOS GERAIS

1) Processo Unificado

• O processo unificado (UP) de desenvolvimento de software é o conjunto de

atividades necessárias para transformar requisitos do usuário em um
sistema de software, usando o paradigma OO;
• É baseado em componentes que realizam interfaces;
• Utiliza UML;
• É dirigido por "use-cases";
• 4 P: Pessoal, Produto, Projeto e Processo;
• É iterativo e incremental;
• O Processo Unificado organiza suas iterações em quatro fases principais:
1. Concepção: o objetivo desta fase é levantar, de forma genérica e
pouco precisa, o escopo do projeto. Não deve existir aqui a
pretensão de especificar de forma detalhada requisitos, a idéia é ter
uma visão inicial do problema, estimar de forma vaga esforço e
prazos e determinar se o projeto é viável e merece uma análise mais
profunda.
2. Elaboração: na fase de elaboração todos (ou a grande maioria dos
requisitos) são levantadosem detalhes. Numa primeira iteração um
ou dois requisitos, os de maior risco e valor arquitetural, são
especificados em detalhes. Estes são implementados e servem como
base de avaliação junto ao usuário e desenvolvedores para o
planejamento da próxima iteração. Em cada nova iteração na fase de
elaboração pode haver um seminário de requisitos, onde requisitos
 antigos são melhor esclarecidos e novos são detalhados. Ao fim da
fase, 90% dos requisitos foram levantados em detalhes, o núcleo do
sistema foi implementado com alta qualidade, os principais riscos
foram tratados e pode-se então fazer estimativas mais realistas.
3. Construção: implementação iterativa dos elementos restantes de
menor risco e mais fáceis e preparação para a implantação.
4. Transição: testes finais e implantação.
• O PU utiliza modelos que descrevem o sistema a ser desenvolvido sob um
certo ponto de vista e seu ambiente. São os seguintes os modelos:
1. Requisitos (funcionais e não funcionais);
2. Análises (classes e responsabilidade);
3. Projeto (classes de projeto, subsistemas, interfaces);
4. Distribuição (nós físicos e os componentes em cada nó);
5. Implementação ;
6. Testes;

2) Engenharia de Requisitos

• É um processo que engloba todas as atividades que contribuem para a

produção de um documento de requisitos e sua manutenção ao longo do
tempo;
• Este processo deve ser precedido de estudos de viabilidade que, a partir das
restrições do projeto, determinam se este é ou não viável e se deve
prosseguir para a identificação dos requisitos.
O processo de engenharia de requisitos é composto por quatro atividades de
alto nível:
1. Identificação.
2. Análise e negociação.
3. Especificação e documentação.
4. Validação.

LISTA 01

1) O que é e quais os motivos de criação da UML?

2) Para que serve o diagrama de caso de uso da UML?
3) Quais foram as metodologias de A&P usadas usadas ao longo do tempo?
4) O que é Análise Essencial?
5) Descreva o Modelo Ambiental da Análise Essencial.
6) Descreva o Modelo Comportamental da Análise Essencial.
7) Cite 3 características do ciclo de vida espiral.
8) Cite 3 características do ciclo de vida em cascata.
9) Por que um bom levantamento de requisitos é importante?
10) Cite e descreva os tipos de manutenção de software.
11) O que é um processo de desenvolvimento de software?
12) Apresente as principais atividades de um processo de des. de sw genérico.
13) Onde é aplicada a TIC na cadeia de trabalho?
14) Porque o paradigma OO auxilia no projeto de sistemas complexos?
15) Cite duas ferramentas utilizadas para gerenciamento de projetos.
16) O que é e para que serve o Diagrama de Contexto?
17) Quais são as etapas de um processo genérico?
18) Defina requisitos funcionais e não funcionais.
19) O que é um processo de produção de software?
20) O que é ciclo de vida?
21) O que é levantamento de requisitos?
22) Para que serve um Modelo de Caso de Uso.
23) Quais as etapas principais de um levantamento de requisitos?

LISTA 02

1) Que importância era dada ao software na década de 50?

2) Qual o duplo papel atriuído ao software?
3) Quais são as 10 categorias de software?
4) Para que servem:
a) Software de Sistemas;
b) Software de Aplicação;
5) O que é desenvolvimento de sofware?
6) O que é processo de desenvolvimento de software?
7) O que é Engenharia de Software?
8) Quais as camadas de Engenharia de Software?
9) O que é um arcabouço de processo de desenvolvimento de software?
10) Enumere os elementos integrantes de um arcabouço de processo de
desenvolvimento de software genérico.
11) O que são atividades guarda-chuva?
12) Cite 3 atividades guarda-chuva?
13) Como se representa uma ação em Engenharia de Software?
14) Para que serve o modelo CMMI?
15) O que é um padrão de processo?
16) Cite 3 elementos integrantes de um padrão de processo.
17) Para que servem os modelos prescritivos de processo.
18) Cite 3 exemolos de modelos incrementais de processo.
19) Descreva o modelo RAD.
20) Cite 2 modelos evolucionários de processo de software.
21) O que são componentes COTS?
22) Em que consiste o modelo que emprega métodos formais?
23) Quais as fases do processo unificado?
24) O que é valorizado no desenvolvimento ágil?
25) Cite dois modelos ágeis de processo de desenvolvimento de software.
26) Quais os 4 principios da filosofia de Desenvolvimento Ágil?
27) Descreva os passos envolvidos na prototipagem.
28) Descreva o modelo de desenvolvimento em cascata.
29) Qual a diferença do desenvolvimento em cascata para os modelos
incrementais?
30) Porque é importante o uso de técnicas e ferramentas de Engenharia de
Software?

LISTA 03

01) No processo unificado, cinco workflows acompanham o conjunto das fases de

desenvolvimento de software. Cada workflow é um conjunto de atividades
executadas por vários membros do projeto. Considerando o desenvolvimento de um
sistema integrado de gestão (ERP), o empacotamento em componentes de
software dos elementos do modelo de projeto — tais como arquivo de código-fonte,
biblioteca de ligação dinâmica e componentes executáveis — é descrito pelo
workflow de _______________________
(ENADE 2005)

02) No processo de desenvolvimento de um sistema de controle de materiais

(matérias-primas) para uma metalúrgica, a equipe de projeto, responsável pelo
mapeamento dos requisitos, desenvolveu seus trabalhos seguindo os quatro
subprocessos da engenharia de requisitos. Inicialmente, foram feitas a análise e a
avaliação para se verificar se o sistema seria útil ao negócio. Em um segundo
momento, os requisitos foram identificados e analisados e, logo em seguida, foram
documentados. Finalmente, foi verificado se os requisitos identificados atendiam às
demandas dos usuários. Tendo sido executado esse procedimento, uma empresa
independente de auditoria, após análise, identificou dois problemas no processo: a
documentação dos requisitos (formulários e padrões utilizados) estava inadequada
e não possibilitava o entendimento correto dos requisitos; o processo de checagem
entre as demandas dos usuários e as especificações relatadas não foi bem
conduzido e seus resultados eram insatisfatórios. Considerando o relatório da
auditoria independente, quais foram as duas fases do processo de engenharia de
requisitos que apresentaram problemas?

03) A orientação a objetos é uma forma abstrata de pensar um problema

utilizando-se conceitos do mundo real e não, apenas, conceitos computacionais.
Nessa perspectiva, a adoção do paradigma orientado a objetos implica
necessariamente que:

A) os usuários utilizem as aplicações de forma mais simples.

B) os sistemas sejam encapsulados por outros sistemas.
C) os programadores de aplicações sejam mais especializados.
D) os objetos sejam implementados de maneira eficiente e simples.
E) a computação seja acionada por troca de mensagens entre objetos.

04) Na etapa de projeto orientado a objetos, no contexto de um processo de

desenvolvimento de software, são desenvolvidas as atividades de:
A) definição da arquitetura do sistema e conversão das bases de dados do sistema.
B) identificação dos objetos do sistema e definição da arquitetura do sistema.
C) conversão das bases de dados do sistema e teste de integração do sistema.
D) teste de integração do sistema e análise de requisitos do sistema.
E) análise de requisitos do sistema e definição da arquitetura do sistema.

05)O desenvolvimento global de software GSD — global software development —

tem-se firmado como uma das grandes tendências na área de sistemas de
informação nas organizações. Considere que uma organização da área de varejo e
distribuição sediada na Europa tenha implantado três unidades de desenvolvimento
de software espalhadas no mundo: uma no Brasil, uma na Índia e outra na
China. Considere ainda que nenhuma dessas unidades possua qualquer tipo de
certificação e que o principal problema da organização esteja relacionado ao
desenvolvimento de sistemas que atendam às necessidades da organização e que
reflitam as expectativas dos clientes globais.
Nessa situação, o nível do modelo SW-CMM e a KPA (área chave de processo)
mais adequados para a situação apresentada são,respectivamente,
A) nível 2, KPA RM – gestão de requisitos.
B) nível 2, KPA SPP – planejamento.
C) nível 2, KPA SPTO – acompanhamento de projeto.
D) nível 3, KPA OPD – definição do processo da organização.
E) nível 3, KPA SPE – engenharia de produtos de software.

06) O modelo de gerenciamento de projetos do PMI (Project Management Institute),

descrito no PMBOK, envolve um conjunto de nove áreas de conhecimento a serem
consideradas com vistas a melhorar o processo de gestão de um projeto,
ampliando-se, conseqüentemente, suas chances de sucesso. Considere que, no
desenvolvimento de um sistema de vendas de uma empresa que atua no segmento
industrial, o orçamento inicial tenha sido extrapolado em 120% e que a equipe da
área de sistemas tenha concluído o sistema com mais de quatro meses de atraso.
Nas reuniões com os usuários para a entrega do sistema, foi constatado que este
não atendia às especificações esperadas pelos usuários. Nessa situação,
evidenciam-se áreas de conhecimento que compõem a chamada tripla restrição,
que são as áreas de gerenciamento de:

A) escopo, contratação e custo.

B) tempo, contratação e risco.
C) custo, tempo e escopo.
D) contratação, custo e tempo.
E) risco, tempo e escopo.

07) O planejamento estratégico de sistemas de informação pode ser entendido

como o processo de identificação de um porta-fólio computadorizado de aplicações
que dá suporte ao plano de negócios das organizações e auxilia na
concretização dos objetivos organizacionais. Os principais objetivos do processo de
planejamento estratégico de sistemas de informação não incluem:

A) o alinhamento das estratégias da área de SI com as estratégias do negócio.

B) o comprometimento da alta administração, pela alocação dos recursos e
resultados intermediários e incrementais.
C) a melhoria do desempenho da área de SI, seja pela alocação mais eficaz de
recursos, seja pelo aumento de produtividade dos profissionais.
D) a antecipação de tendências, envolvendo inovação tecnológica contínua.
E) a identificação, a avaliação e a validação dos controles
relacionados aos sistemas de informação existentes, do ponto
de vista de sua eficiência e eficácia.

08)Julgue os seguintes itens referentes a teste de software.

I- A técnica de teste funcional, que estabelece os requisitos de teste com base em
determinada implementação, permite verificar se são atendidos os detalhes do
código e solicita a execução de partes ou de componentes elementares do
programa; a técnica de teste estrutural aborda o software de um ponto de vista
macroscópico e estabelece os requisitos de teste, com base em determinada
implementação.
II- Na fase de teste de unidade, o objetivo é explorar-se a menor unidade de projeto,
procurando-se identificar erros de lógica e de implementação de cada módulo; na
fase de teste de integração, o objetivo é descobrir erros associados às interfaces
entre os módulos quando esses são integrados, para se construir a estrutura do
software, estabelecida na fase de projeto.
III- Critérios com base na complexidade, em fluxo de controle e em fluxo de dados,
são utilizados pela técnica estrutural de teste.
Assinale a opção correta.

A) Apenas um item está certo.

B )Apenas os itens I e II estão certos.
C) Apenas os itens I e III estão certos.
D) Apenas os itens II e III estão certos.
E) Todos os itens estão certos.

09) O gerente de desenvolvimento de uma empresa de TI examinou a seguinte

planilha sobre andamento de projetos.

projeto | percentual completado (em %) | percentual do orçamento

já despendido (em %)
P1 50 70
P2 80 65

Com base nessa planilha e com relação aos conceitos de dado, informação e
conhecimento, julgue os itens que se seguem.

I - O número 65, na célula inferior direita, é um dado.

II - Associar o número 80 (célula inferior central) ao percentual completado (em %)
e a P2, e concluir que o projeto P2 está 80% completado é um conhecimento.
III - Dizer que P1 está adiantado ou atrasado é uma informação.
IV - Dizer o quanto P1 vai precisar a mais do que foi inicialmente previsto no
orçamento é um conhecimento. Estão certos apenas os itens:

A - I e II.
B - I e IV.
C - II e III.
D - II e IV.
E - III e IV.

10) O objetivo da Teoria Geral dos Sistemas (TGS) é a formulação dos princípios
válidos para os sistemas em geral, qualquer que seja a natureza dos elementos que
os compõem e as relações ou forças existentes entre eles. Na área de sistemas de
informação, diversos problemas requerem abordagem multidisciplinar para serem
resolvidos. Por exemplo, na área de desenvolvimento de software, a especificação
de requisitos apresenta vários desafios desse tipo, tais como aspectos de
relacionamento interpessoal, conhecimento do negócio, resolução de conflitos,
diferenças culturais etc. Os propósitos da TGS que podem contribuir para a
resolução desses problemas incluem
I- o incentivo à especialização total das áreas do conhecimento.
II- o desenvolvimento dos princípios unificadores quetranscendem o universo das
ciências individuais.
III- a integração de contribuições de várias ciências na busca de solução dos
problemas.
IV - o desenvolvimento de princípios únicos para cada área do conhecimento.
V - o desenvolvimento de estudos que visem à ampliação da separação entre as
ciências naturais e sociais. Estão certos apenas os itens:

A) I e II.
B) I e V.
C) II e III.
D) III e IV.
E) IV e V

11) Qual a importância do gerenciamento de versões em um processo de

desenvolvimento de software e como gerenciamento de configuração pode ajudar
neste processo?

12) Para que serve um sistema de controle de versão?

13)Como funciona o controle de versão?

14) Quais as semelhanças e diferenças entre o controle de versão

centralizado e o distribuído?

15) Cite duas ferramentas de controle de versão e exemplifique seu uso.

16) Como o Controle de versão apóia o desenvolvimento de software?

R.:
• Histórico. Registra toda a evolução do projeto, cada alteração sobre
cada arquivo. Com essas informações sabe-se quem fez o que, quando
e onde. Além disso, permite reconstruir uma revisão específica do
arquivo sempre que desejado;
• Colaboração. O controle de versão possibilita que vários
desenvolvedores trabalhem em paralelo sobre os mesmo arquivos sem
que um sobrescreva o código de outro, o que traria reaparecimento de
defeitos e perda de funcionalidades;
• Variações no Projeto. Mantém linhas diferentes de evolução do mesmo
projeto. Por exemplo, mantendo uma versão 1.0 enquanto a equipe
prepara uma versão 2.0.

17) Como funciona o controle de versão?

R.:
O controle de versão é composto de duas partes: o repositório e a área de
trabalho. Orepositório armazena todo o histórico de evolução do projeto,
registrando toda e qualquer alteração feita em cada item versionado.
O desenvolvedor não trabalha diretamente nos arquivos do repositório.
Ao invés disso, usa uma área/cópia de trabalho que contém a cópia dos
arquivos do projeto e que é monitorada para identificar as mudanças
realizadas. Essa área é individual e isolada das demais áreas de trabalho.
A sincronização entre a área de trabalho e o repositório é feita através
dos comandos decommit e update.
O commit envia um pacote contendo uma ou mais modificações feitas na
área de trabalho (origem) ao repositório (destino). O update faz o
inverso, isto é, envia as modificações contidas no repositório (origem)
para a área de trabalho (destino).
Cada commit gera uma nova revisão no repositório, contendo as
modificações feitas, data e autor. Uma revisão funciona como uma "foto"
de todos os arquivos e diretórios em um determinado momento da
evolução do projeto. As "fotos" antigas são mantidas e podem ser
recuperadas e analisadas sempre que desejado. O conjunto dessas
revisões é justamente o histórico do projeto.
Tanto o controle de versão centralizado quanto o distribuído possuem
repositórios e áreas de trabalho. A diferença está em como cada uma
dessas partes está arranjada.

18) O que é qualidade de software?

R.:A qualidade de software é uma área de conhecimento da engenharia de

software que objetiva garantir a qualidade do software através da definição e
normatização de processos de desenvolvimento. Apesar dos modelos aplicados na
garantia da qualidade de software atuarem principalmente no processo, o principal
objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro
daquilo que foi acordado inicialmente.

19)O que é qualidade de software segundo a norma ISO 9000

R.: Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um
conjunto de características inerentes a um produto, processo ou sistema cumpre os
requisitos inicialmente estipulados para estes.

20) O que é GQS (Garantia da Qualidade de Software)?

R.: Garantia da Qualidade de Software (GQS) é a área-chave de processo

do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada
visibilidade dos projetos, dos processos de desenvolvimento e dos produtos
gerados. A GQS atua como "guardiã", fornecendo um retrato do uso do Processo e
não é responsável por executar testes de software ou inspeção em artefatos.

21) O que é o modelo CMM

R.: O "CMM - Capability Maturity Model for Software /SEI" é uma

estrutura-"framework", que descreve os principais elementos de um processo de
desenvolvimento de software efetivo. O CMM descreve os estágios de maturidade
através dos quais Organizações de software evoluem o seu ciclo de
desenvolvimento de software através de sua avaliação contínua, identificação e
ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho
de melhoria é definido por cinco níveis de maturidade: inicial, repetitivo, definido,
gerenciado e otimizado.

22) O que é CMMI?

R.:
O CMMI (Capability Maturity Model Integration) é um modelo de referência que
contém práticas (Genéricas ou Específicas) necessárias à maturidade em
disciplinas específicas (Systems Engineering (SE), Software Engineering (SW),
Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).
Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie
Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único
para o processo de melhoria corporativo, integrando diferentes modelos e
disciplinas.
A versão atual do CMMI (versão 1.2) apresenta três modelos:
▪ CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao
processo de desenvolvimento de produtos e serviços.
 ▪ CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se
aos processos de aquisição e terceirização de bens e serviços.
▪ CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. Dirige-se aos
processos de empresas prestadoras de serviços.

23) Quais os tipos de representação do CMMI?

R.: Contínua e por estágios.

24) Para que serve a representação contínua?

R.:
Possibilita à organização utilizar a ordem de melhoria que melhor atende os
objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade
(Capability Levels):
▪ Nível 0: Incompleto (Ad-hoc)
▪ Nível 1: Executado (Definido)
▪ Nível 2: Gerenciado / Gerido
▪ Nível 3: Definido
▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
▪ Nível 5: Em otimização (ou Optimizado)

25) Para que serve a representação por estágios?

R.:
Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios
que não deve ser desconsiderada, pois cada estágio serve de base para o próximo.
É caracterizado por Níveis de Maturidade (Maturity Levels):
▪ Nível 1: Inicial (Ad-hoc)
▪ Nível 2: Gerenciado / Gerido
▪ Nível 3: Definido
▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
▪ Nível 5: Em otimização
26) Em que consiste a Engenharia de Requisitos?

R.:
é um processo que engloba todas as atividades que contribuem para a produção de
um documento de requisitos e sua manutenção ao longo do tempo.
Este processo deve ser precedido de estudos de viabilidade que, a partir das
restrições do projeto, determinam se este é ou não viável e se deve prosseguir para
a identificação dos requisitos.

27) Quais as 4 atividades de alto nível da engenharia de Requisitos?

R.:
O processo de engenharia de requisitos é composto por quatro atividades de alto
nível (Soares, 2005):
1. Identificação.
2. Análise e negociação.
3. Especificação e documentação.
4. Validação.
Uma outra atividade que se pode considerar que faz também parte deste processo,
se incluirmos a fase posterior à produção do documento (isto é, a sua
"manutenção"), é a gestão dos requisitos (change management, sendo que as
alterações podem ser causadas pelos mais diversos fatores desde inovações
tecnológicas a mudanças na natureza do negócio (e consequentemente nos
requisitos), entre outras).

28) Em que consiste um estudo de viabilidade?

R.:
Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto,
deve ser feito um estudo de viabilidade.
Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de
vista tecnológico e organizacional, o projeto é viável.
Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com
"as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou
entrevistas, por exemplo), a resposta às seguintes questões:
▪ Será que o sistema contribui para os objetivos da organização?
▪ Dadas as restrições tecnológicas, organizacionais (econômicas, políticas,
ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o
sistema pode ser implementado?
▪ Caso haja necessidade de integração entre diferentes sistemas, será que esta é
possível?
29) Em que consiste um estudo etnográfico?
R.:
Os Estudos Etnográficos são uma análise da componente social das tarefas
desempenhadas numa dada organização. Quando um dado conjunto de tarefas se
torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular
todos os passos que segue ou todas as pessoas com as quais interage para as
levar a cabo. Através de uma observação direta das atividades realizadas durante
um período de trabalho de um funcionário é possível encontrar requisitos que não
seriam observáveis usando técnicas convencionais. Esta observação pode ser
acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia
visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica
assume-se que o representante do cliente observado desempenha as suas funções
"corretamente", pelo que convém ter algum cuidado na escolha do mesmo.

30) Em que consiste a gestão da configuração de software?

R.:
Segundo Babich [BABICH86] gestão de configuração de software é:
“A arte de coordenar o desenvolvimento de software para minimizar a confusão é
chamada de
gestão de configuração. A gestão de configuração é a arte de identificar, organizar
e controlar
modificações de software que está sendo construído por uma equipe de
programação. O objetivo é
maximizar a produtividade pela minimização dos erros.”

Segundo Sommerville [SOMMERVILLE03] o gerenciamento de configuração

(configuration
management – CM) é o desenvolvimento e aplicação de padrões e procedimentos
para gerenciar um
produto de sistema em desenvolvimento. É necessário gerenciar os sistemas em
desenvolvimento
porque, à medida que eles se desenvolvem, são criadas muitas versões diferentes
de software. Essas
versões incorporam propostas de mudanças, correções de defeitos e adaptações
para diferentes
hardwares e sistemas operacionais. É possível que haja várias versões em
desenvolvimento e em uso
ao mesmo tempo. É necessário manter o controle das mudanças que foram
implementadas e de
como essas mudanças foram incluídas no software.

31) Em que consiste a ES baseada em componentes (ESBC)?

R.:
Engenharia de Software Baseada em componentes é um ramo de Engenharia de
Software, com ênfase na decomposição dos sistemas, em componentes funcionais
e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios
componentes. Componentes são considerados como estando num nível
de abstração mais alto que do que Objetos e, como tal, não compartilham estado e
comunicam-se por troca de mensagens contendo dados.

32) O que é um componente de software?

R.:
Brown e Wallnau[3] descrevem um componente como "uma não-trivial, quase
independente, e substituível parte de um sistema que cumpre uma função clara no
contexto de uma arquitetura bem definida". Em muitos sentidos, esta descrição é
similar a de um objeto em POO. Componentes possuem uma interface. Eles
empregam regras de herança.
Já para Szyperski [4], o componente não é necessariamente uma tecnologia
implementada especificamente e nem a aplicação, mas sim um dispositivo de
software que possua uma interface bem definida.
Mas para Krutchen [5], o componente é um elemento independente, que pode ser
substituído, contudo, ele é significativo, pois tem uma função clara no contexto em
que foi definido.
Mas a definição é levada ainda além. Componentes são definidos para oferecer um
certo nível de serviço. No caso dos componentes "comerciais de prateleira" ( ou
commercial off-the-shelf - COTS), o engenheiro de software sabe pouco ou nada
sobre o funcionamento interno de um componente. Ao invés disso, ao engenheiro
de software é dada apenas uma interface externa bem-definida a partir da qual ele
deve trabalhar. O nível de serviço é portanto crucial e precisa ser acurado se quiser
que a integração do componente ao sistema de software seja bem sucedida. Brown
e Wallnau descrevem um componente de software como “uma unidade de
composição contratualmente especificada e somente com dependências contextuais
explícitas”. Ao contrário de objetos em POO, os componentes são usualmente
construídos a partir de muitos “objetos” de software (embora a construção não seja
confinada a POO) e fornecem uma unidade de funcionalidade coerente. Os assim
chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em
um dado nível de serviço. Componentes podem ser caracterizados com base em
seu uso no processo de ESBC: Como mencionado acima temos os COTS. São
componentes que podem ser comprados, pré-fabricados, com a desvantagem de
que, no geral, não há código fonte disponível, e sendo assim, a definição do uso do
componente dada pelo fabricante(desenvolvedor), e os serviços que este oferece,
precisam ser confiavelmente testadas, como podem ou não ser acuradas. A
desvantagem, entretanto, é que estes tipos de componentes deveriam(em teoria)
ser mais robustos e adaptáveis, pois foram usados e testados( e reusados e re-
testados) e muitas diferentes aplicações. Adicionalmente aos COTS, a ESBC
almeja:
▪ Componentes qualificados [6]
▪ Componentes adaptados
▪ Componentes aglutinados
▪ Componentes atualizados
33) Quais os 2 processos que correm em paralelo na ESBC?

R.:
a) Engenharia de Domínio
Objetiva identificar, construir, catalogar e disseminar um conjunto de componentes
de software que tenham aplicabilidade para software existentes e futuros, dentro de
um domínio de aplicação específico. Um domínio de aplicação é como uma família
de produtos - aplicações com funcionalidade(ou intenção de funcionalidade) similar.
O objetivo é estabelecer um mecanismo em que engenheiros de software possam
partilhar estes componentes usando-os em sistemas futuros.
b) Desenvolvimento Baseado em Componentes
O Desenvolvimento Baseado em Componentes (DBC) aborda a criação de sistemas
de software que envolva a composição de componentes permitindo a adição,
adaptação, remoção e substituição de partes do sistema sem a necessidade de sua
completa substituição. Isso auxilia na manutenção dos sistemas uma vez que,
permite a integração de novos componentes e/ou a atualização dos já existentes. A
abordagem é criar ou adaptar os componentes para que sejam utilizados em
diversos sistemas. Essa idéia vem ao encontro da reutilização que busca flexibilizar
o desenvolvimento.

34) Quais os principais modelos de componentes existentes?

R.:
▪ CMM (CORBA Component Model) do OMG (Object Management Group);
▪ DCOM (Distributed Component Obejct) e COM/COM+ (Component Object
Model) da Microsoft; e
▪ JavaBeans e Entreprise JavaBeans (EJB) da Sun.

35) Qual o objetivo da gestão de riscos?

R.:
Gestão de risco pode ser definido como cultura, processo e estrutura
relativos a perceber oportunidades enquanto gerencia-se efeitos
adversos. Um explicação para o crescente interesse em gestão de risco é
a oportunidade de aplicar nosvas idéias e ferramentas à "nova realidade
de risco". Acreditamos que gestão de risco deveria ser parte integral de
boas práticas de negócios, tanto nos níveis estratégicos quanto
operacionais.
O principal ponto de gerenciar riscos é avaliar a incerteza do futuro de
modo a tomar a melhor decisão possível. Em geral, toda gestão de risco e
toda tomada de decisão lida com essa questão. Os benefícios são
melhores decisões, menos surpresas, melhora no planejamento, na
performance e na efetividade e ainda, melhora no relacionamento com as
partes interessadas.

36) Quais os tipos de riscos em software?

R.:
• De acordo com a Natureza
◦ Riscos de Projeto
◦ Riscos de Negócio
◦ Riscos Técnicos
• De acordo com a probabilidade do evento
◦ Conhecidos
◦ Previsíveis
◦ Imprevisíveis

37) Quais as atividades contínuas da Gestão de Riscos, segundo a SEI?

R.:
Comunicar
Identificar
Buscar e localizar os riscos antes que eles se tornem problemas reais
Analisar
Transformar os dados dos riscos em informações para tomada de decisão
Planejar
Traduzir e implementar as informações dos riscos em ações de decisão e
resolução de riscos
Monitorar
Monitorar indicadores dos riscos e seus planos de resolução
Controlar
Corrigir os desvios para os planos de resolução dos riscos

38) O que é uma ferramenta de controle de versão?

39) Qual a importância do uso de uma ferramenta de controle de versão num
projeto?
40) Em que consiste a filosofia de desenvolvimento por componentes?
41) Dê exemplo de arquiteturas de desenvolvimento por componentes.
42) Por que o estabelecimento exato dos requisitos do sistema com o cliente e sua
exata compreensão pela equipe de desenvolvimento é tão importante?
43) O que é um "milestone" na gestão de um projeto?
44) Para que serve a gestão de modificações?
45) O que é gestão de reusabilidade?
46) Descreva resumidamente para que servem as práticas da Engenharia de
Software, quais suas vantagens no desenvolvimento de sistemas?

Consideraçõe sobre a Teora dos Grafos

Um grafo G = (V, E) é composto por um conjunto V não vazio de vértices(nós) e um

conjunto (E) de arestas (arcos), onde cada aresta conecta dois vértices. Um grafo
pode ser representado de duas formas: uma baseada numa representação
visual,usando círculos fechados para vértices e retas ou curvas para arestas e outra
mais formal que usa matrizes e vetores. A segunda forma será usada nas
estruturas de dados que trabalham com grafos, em programas de computador.
A seguir á apresentado um exemplo de grafo G (V,E), onde:
V = {a, b, c, d, e, f}
E = {(a, b), (b, c), (b, e), (c, e), (c, d), (d, f)}
(a, b) é uma aresta entre vértice a e b.
Um grafo pode ser dirigido ou não dirigido. No dirigido a ordem dos vértices importa,
num não dirigido esta ordem é indiferente. Um grafo dirigido é também chamado de
dígrafo e consiste de uma tripla ordenada (N,A,g), onde:
N = Um conjunto não vazio de nós
A = Um conjunto de arcos
g = Função que associa a cada arco, um par ordenado (x,y) de nós
Na função g, x é o ponto (extremidade) inicial e y o ponto final de a. Além da
orientação podem ser impostos pesos, onde cada arco tem um valor numérico
associado.

Um caminho é uma seqüência de vértices v1, v2, …, vn conectados por arestas (v1,
v2), (v2, v3), … (vn - 1, vn). As arestas são também consideradas como parte do
caminho. O comprimento de um caminho é dado pelo número de arcos que ele
contém.
Um circuito é um caminho onde o vértice final é igual ao inicial. Um circuito será
simples se nenhum vértice aparecer mais de uma vez, exceto o primeiro e o último.
Um circuito simples é chamado de ciclo. Um grafo sem ciclos é chamado de
acíclico.

Dado um grafo, dizemos que um vértice é adjacente a outro vértice, se existe no

grafo uma aresta que une os dois. Um laço é um arco com extremidades n-n, para
algum nó n. Dois arcos com as mesmas extremidades são ditos paralelos.
Um grafo é conectado (conexo) se existe um caminho entre dois vértices quaisquer
do grafo.

O grau de um vértice é o número de arestas adjacentes a ele. Num grafo dirigido o

grau de entrada é dado pelo número de arestas que chegam ao vértice e o grau de
saída pelo número de arestas que sai.

Uma fonte é um vértice com grau de entrada 0 e grau de saída > 1. Um sumidouro é
um vértice com grau de saída 0 e grau de entrada > 1.

Um grafo G = (V, E) é usualmente representado por uma matriz de adjacências.

Programa make do Unix

O programa make do Unix toma como entrada um arquivo texto contendo comandos
da forma
Nome : d1 d2 … dn
Comandos

Nome é o nome de um arquivo que depende dos arquivos d1 d2 … dn.

Make lê este texto e executa Comandos se a data de última atualização de algum
arquivo di for mais nova que de Nome. Ou seja, se algum di for mais novo que
Nome, ele executa Comandos, que são comandos para o Unix que possivelmente
deverão atualizar arquivo Nome. Ex.:

prog : a.obj b.obj c.obj

ln -o prog a.obj b.obj c.obj
a.obj : a.c prog.h
cc -c a.c
b.obj : b.c prog.h
cc -c b.c
c.obj : c.c
cc -c c .c

ln é o linker e cc o compilador. Se, por exemplo, b.c for modificado, make irá
compilá-lo novamente (Comando "cc -c b.c"), porque ele será mais novo que
"b.obj". Então "b.obj" será mais novo que prog que será linkado por "ln -o
prog a.obj b.obj c.obj ".
As relações de dependências do make podem ser colocada em forma de um grafo.

Eliminação de Código Morto

Podemos representar um procedimento como um grafo onde as instruções são

vértices e existe aresta dirigida de v para w se w é executado após v (ou pode ser
executado, no caso de if’s e while’s). A função

void f(
{
if (i > 0)
{
j = 1;
goto L1;
 a = 10;
}
else
j = 10;
return 1;
L1;
}
seria transformada no grafo

Para descobrir o código morto, fazemos uma busca a partir da primeira instrução do
procedimento marcando todos os vértices visitados. As instruções correspondentes
aos vértices não visitados nunca serão executados e podem ser removidos pelo
compilador.
Note que com este mesmo grafo pode-se descobrir se a instrução return será
executada por todos os caminhos que ligam o vértice inicial ao vértice "fim da
função". A resposta para o grafo acima é : não.

Exercícios

Será cobrado na prova transformação de códigos em grafos e verficação de sua

utilidade.