P. 1
Projeto de Software

Projeto de Software

|Views: 1.487|Likes:
Publicado pormadeira200

More info:

Published by: madeira200 on Oct 05, 2010
Direitos Autorais:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/08/2013

pdf

text

original

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,...);

Uma Visão Genérica • Software. Software Aberto • Software legado.com • http://dir. aplicáveis a todos os projetos de software.cnet. Modelagem . Ele identifica um pequeno número de atividades de arcabouço.com/story/tech/feature/2002/04/08/lehman/index. Processo 3. Foco na Qualidade 2. que sejam confiáveis e que trabalhem eficientemente em máquinas reais. Planejamento 3.html MÓDULO 1 . Referências: • http://www. à medida que o processo e conduzido. • Engenharia de Software é a criação e utilização de sólidos princípios de engenharia a fim de obter softwares econômicos. Comunicação (cliente e outros interessados) 2. • Processo de Software não é Engenharia de Software. independentemente de seu tamanho ou complexidade. • Arcabouço de Processo Genérico: 1. Ferramentas • Arcabouço de Processo estabelece o alicerce para um processo de software completo. Netsourcing (sistemas distribuídos para usando a WEB). • O desenvolvimento de software é um processo iterativo de aprendizagem e o resultado é a incorporação de conhecimentos coletados. • Processo de Desenvolvimento de Software é um arcabouço para as tarefas necessárias para a construção de softwares com qualidade.salon. Computação Ubíqua (computação distribuída).yourdon. latente e incompleto.8. tácito.org • http://www.softwarehistory. destilados e organizados. Métodos 4.O PROCESSO DE SOFTWARE 2) Processo . 10. como todo capital. é conhecimento incorporado.com • http://shareware. 9. • A Engenharia de Software é uma tecnologia em : 1. estando inicialmente disperso.

Contexto Resultante. que devem estar presentes. Estágio e Fase. Revisões Técnicas Formais. Construção 5. 6. Contexto Inicial. Pontos de Garantia de Qualidade. Intenção. como por exemplo: 1. um método consistente para descrever uma característica importante do processo de software. 4. Gestão de Configuração de Software. Solução. Gestão de Risco. Acompanhamento e Controle de Projeto de Software. • PADRÃO DE PROCESSO: gabarito. 8. Usos Conhecidos/exemplos . • Cada ação de Engenharia de Software é representada por um conjunto de tarefas. 2. 5. Padrões Relacionados. Para atingir essas capacidades a SEI estabelece que as organizações devem desenvolver modelos de processo que sigam as diretrizes CMMI. à medida que as empresas alcaçam diferentes níveis de capacidade e maturidade de processo. 8. Garantia de Qualidade de Software. 7. 3. cada um com: 1. 2. 3. A seguir é descrito um modelo para definir um padrão de processo: 1. Implantação • O arcabouço genérico da Engenharia de Software é complementado por várias atividades guarda-chuva. 2. Tarefas de Trabalho de Engenharia de Software. Medição. Gestão de Reusabilidade. 3. 6. 9. 5. Problema. Nome do Padrão. Tipo: Tarefa.4. 4. Pela combinação de processos uma equipe de projeto pode construir um processo que melhor satisfaça às necessidades de um projeto. 7. Produtos de Trabalho Relacionados. Preparação e Produção do Produto de Trabalho. Marcos de Projeto • CMMI: Metamodelo de processo baseado em um conjunto de capacidades de Engenharia de Software. e 4.

• Modelo de Ciclo de Vida • Modelo de Desenvolvimento em Cascata • Modelos Incrementais de Processo: 1. 3. • É uma adaptação em "alta velocidade" do modelo em cascata. CBA IPI.edu/ • http://pt. Modelo Incremental 2. ISO 9001:2000 para Software Referências: • http://standards.cmu.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. que são necessários para fazer Engenharia de Software com alta qualidade. Modelo RAD • Enfatiza um ciclo de desenvolvimento curto. marcos e produtos de trabalho. • O desenvolvimento rápido é conseguido c/uma abordagem de construção baseada em componentes . • Um modelo prescritvo define um conjunto distinto de atividades.sei. SCAMPI.org/wiki/CMMI • http://pt.wikipedia.org • http://www. 2. algumas propostas: 1.• Avaliação de Processo.ieee. ações tarefas.

não identificando detalhadamente requisitos de entrada. • É difícil definir com precisão a interação homem/máquina. 2) Modelo Espiral • Combina a natureza iterativa da prototipagem com aspectos consolidados e sistemáticos do modelo em cascata. . • Um protótipo é um excelente meio de coletar os requisitos de um software.• Modelos Evolucionários de Processo de Software 1) Prototipagem • O cliente normalmente identifica requisitos gerais. processamento ou saída. • Pode ser um modelo de processo independente ou embutida em outro modelo.

. 2) Modelo de Métodos Formais • Conjunto de atividades que levam à especificação matemática formal do programa. • Modelos Especializados de Processo 1) Desenvolvimento Baseado em Componentes • Componentes de software comercial de prateleira (COTS). • Incorpora muitas das características do modelo espiral.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.

4. . • Manifesto para Desenvolvimento Ágil de Software • Modelos Ágeis de Processo: Extreme Programming(XP) DAS DSDM SCRUM Crystal FDD (Desenvolvimento guiado por características) Modelagem Ágil • Filosofia para Desenvolvimento Ágil: 1. • O ambiente moderno que usa sistemas computacionais é apressado e sempre mutável. 7. 6. • É valorizado o cumprimento da entrega do produto e não as atividades de A&P. 5. 2. 3.3) Desenvolvimento de Software Orientado a Aspectos 4) Processo Unficado 4) Desenvolvimento Ágil • Combina filosofia e diretrizes de desenvolvimento.

com controle sobre o trabaho que executam. ◦ Pode ser representada uma solução efetiva para o problema. • O processo de desenvolvimento de software fornece um roteiro e a prática os detalhes para alcançar os objetivos. ◦ O problema pode ser representado graficamente. princípios e ferramentas que projetistas de software aplicam durante todo o processo de software. Comunicação e colaboração entre os membros da equipe e entre profissionais e seus clientes. MÓDULO 2 . • A prática de ES é exercida por engenheiros de software e gerentes. 4.PRÁTICA DE ENGENHARIA DE SOFTWARE 5) Prática . ◦ O problema pode ser compartimentalizado. 3. Ênfase na entrega rápida de softwares que satisfaçam o cliente. . Reconhecimento de que modificações representam uma oportunidade. 4. 5. ◦ Podem ser definidos subproblemas. ◦ Quais são as incógnitas. ◦ Cada componente da solução está correto. princípios e ferramentas que podem ser usadas à medida que o software vai sendo planejado e desenvolvido. 2. 2. • Essência da Prática: Entenda o problema (comunicação e análise) ◦ Quem tem interesse na solução.Uma visão genérica A prática da Engenharia de Software envolve conceitos.1) Prática da Engenharia de Software • A prática é um amplo conjunto de conceitos. Importância de equipes auto-organizadas. Execute o plano (geração de código) ◦ A solução está de acordo com o plano. Examine o resultado quanto à precisão (teste e garantia de qualidade) ◦ É possível testar cada componente da solução. 3. Planeje uma solução (modelagem e projeto de software): ◦ Existem problemas análogos.1. 1. ◦ Um problema semelhante foi resolvido.

• Alguém deve facilitar a atividade. desenhe uma figura. • Conserve-se focado. • Reconheça que o planejamento é iterativo. • Comunicação face a face e melhor. 4. • Prossiga independentemente de não concordar e se algum esclarecimento não foi prestado. produz melhores resultados. modularize sua discussão. • Se algo não está claro. W5HH . • Considere riscos à medida que um plano é definido. • Princípios centrais do Desenvolvimento de software: 1. • Seja realista (as pessoas não trabalham 100% todos os dias). • Acompanhe o plano com freqüência e faça ajustes quando necessário. Mantenha a visão. 3. • Estime com base no que é sabido.◦ A solução produz resultados de acordo com os dados. Planeje com antecedência o reuso. • Negociação não é um concurso ou jogo.3) Práticas de Planejamento: • Entenda o escopo do projeto. Porque tudo existe. funciona melhor quando ambas as partes ganham. raciocine clara e completamente antes da ação. 6. • Prepare-se antes de comunicar. características e comportamentos que são necessários. 5. Esteja aberto para o futuro. • Envolva o cliente na atividade de planejamento. • Busque colaboração. • Descreva como controlar e implementar modificações. Pense. O que você produz os outros vão consumir. • Faça anotações e documente as decisões. 7. KSS. 5. funções. 2. 5. • Defina como garantir a qualidade. • Ajuste a granularidade à medida que o plano é definido.2) Práticas de Comunicação • Escute.

lutando sempre por maior simplicidade. • A tarefa de análise deve ir da informação essencial até os detalhes de implementação. Como o trabalho será conduzido técnica e gerencialmente (How). função e comportamento devem ser particionados de modo que revelem detalhes em forma de camadas. como conseqüência de eventos externos.2) Principios da Modelagem de Projeto • O projeto deve estar relacionado ao modelo de análise. • O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final. • As funções a serem desenvolvidas no software devem ser definidas.4) Práticas de Modelagem 5. 2. • O projeto dos dados é tão importante quanto o projeto de funções de processamento. precisa ser representado. • O projeto em nível de componente deve ser funcionalmente independente. Projetar a interface do usuário. 5. • Os modelos que mostram informação. Particionar o modelo de análise em subsistemas. . • Sempre considere a arquitetura do sistema a ser construído.1) Princípios da Modelagem de Análise • O domínio da Informação de um problema precisa ser representado e entendido. • O projeto deve ser desenvolvido iterativamente.• • • • • • • Porque o sistema está sendo desenvolvido (Why). • As interfaces (tanto internas quanto externas) precisam ser projetadas com cuidado. O que será feito (What). Quanto é necessário de cada recurso (How Much) 5. 3. enfatizando no entanto a facilidade de uso. • Os componentes devem ser acoplados fracamente uns aos outros e ao ambiente externo. • O comportamento o software.4. • Conjunto genérico de tarefas para projeto: 1. Quem será o responsável por uma função (Who). Onde estão localizados na organização (Where).4. Quando será concluído (When). Usando a Análise escolher um padrão(estilo) para o projeto. • Representações de projeto devem ser facilmente compreensíveis.

5. tão logo os componentes que estão sendo codificados. Realizar testes unitários. • Os testes devem ser planejados muitos antes de serem iniciados. 5. 3. Projetar testes de unidade para cada componente de software 2. Selecione estrutura de dados que atendam às necessidades do projeto.5. 4. corrigindo erros descobertos.20). Crie ciclos aninhados. 3. Selecione um ambiente de programação que forneça ferramentas para facilitar o trabalho. • O principio de Pareto se aplica ao teste de software (80 . Desenvolver uma estratégia de integração . de modo que sejam facilmente testáveis. • Principios de Validação (após completar o primeiro passo de codificação): 1. seguindo a prática de programação estruturada. 2.1) Princípios e conceitos de codificação • Princípios de Preparação (antes de escrever uma linha de código): 1. 2. 5. 6. 5.4. Escreva código que é autodocumentado. Restringir seus algoritmos. 4. Escolha uma linguagem de programação que satisfaça às necessidades do software e do ambiente em que ele vai operar. • Conjunto Genérico de Tarefas de Teste: 1. Conserve a lógica condicional. • Principios de Codificação (quando começar a codificar): 1. Refabricar o código. Desenvolver um modelo de implantação 5. Crie uma disposição visual que facilite o entendimento do código. Crie um conjunto de testes unitários. que possam ser aplicados. tão simples quanto possível. Entenda a arquitetura do software e crie interfaces que sejam consisentes com ela.2) Princípios de teste: • Todos os testes devem estar relacionados aos requisitos do cliente. 3. Selecione nomes significativos de variáveis e siga outras normas locais de codificação. 9. estejam prontos. 2. 8.5) Práticas de Construção 5. Conduzir uma inspeção de código quando adequado. Conduzir o projeto em nível de componentes. 5. Entenda os princípios e conceitos básicos do projeto. Entenda o problema. 7.

5. Realimentação. Suporte. Criar mídia de entrega. Conduzir os teste de alta prioridade 6. 5. . Desenvolver uma estratégia de validação 4.3. 6. 2. 3.1) Sistemas Baseados em Computador. 3. procedimentos e outros elementos do sistema. Coletar feed-back dos usuários. Disseminar a mídia de entrega entre todos os usuários. Engenharia de Processo de Negócio. software. As expectativas do cliente quanto ao software devem ser geridas. Conduzir funções de suporte permanentes. Estabelecer mecanismos de feed-back dos usuários. 2. 2. • Conjunto Genérico de Tarefas de Implantação: 1. 4. O software deve ser corrigido primeiro e depois entregue. arquitetura de hardware. Conduzir os testes de integração e validação 5. base de dados. Um pacote completo de entrega deve ser montado e testado. visando organizar o desenvolvimento de sistemas baseado em computadores: 1. Estabelecer suporte humano pessoal ou em grupo. 6) Engenharia de Sistemas • Focaliza elementos do sistema: objetivo geral. 2. • Principios chave da Implantação: 1. 6. Engenharia de Produto.6) Práticas de Implantação • A atividade de implantação envolve 3 ações: 1. Materiais institucionais adequados devem ser fornecidos aos usuários finais. pessoal. Entrega. 4. • O processo de Engenharia de Sistemas toma diversas formas. Coordenar os testes de aceitação com o cliente 5.e 3. Um regime de suporte deve ser estabelecido antes do software ser entregue.

hardware. BD. • 3 arquiteturas que devem ser analisadas: 1. Visão do Elemento. Arquitetura de Aplicações. 1.fatores restritivos: Pressupostos. 4. 4. Visão do Domínio.4) Engenharia de Produto • Traduz o desejo do cliente de um conjunto de capacidades definidas para um produto em funcionamento. Preferências • Simulação de Sistemas. 6. 2. a ES abrange Métodos topdown e bottom-up para navegar na hierarquia de ES: Visão de Mundo. Restrições. Limitações. 6.3) Engenharia de Processo de Negócio • Define arquiteturas que permitem a um negócio usar informações de maneira efetiva. documentação e procedimentos. 6. • Modelagem de sistemas .• Principais elementos: software. Visão Detalhada. 1. • Modelo de Hatley-Pirbhai . 3. 6.2) A Hierarquia da Engenharia de Sistemas • Independentemente do domínio de enfoque. 5. 3. Infra-Estrutura Tecnológica. 2.5) Modelagem de Sistemas • Os modelos de sistemas tendem a ser em camadas (hierárquicos).todo sistema baseado em computador pode ser modelado como uma transformação usando um gabarito entrada-saída. pessoal. Arquitetura de Dados. 2. Simplificações. . 3.

7. • Validação.• Modelagem com UML. • Negociação.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 .1) Uma ponte para o Projeto e a Construção.2) Tarefas para a Engenharia de requisitos: • Concepção. • Elaboração. • Levantamento. 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 .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 . 7) Engenharia de Requisitos 7. • Gestão de Requisitos. • Especificação.

Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos. Produto. • Utiliza UML. Concepção: o objetivo desta fase é levantar. Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são levantadosem detalhes. • É dirigido por "use-cases". de forma genérica e pouco precisa. • O Processo Unificado organiza suas iterações em quatro fases principais: 1. os de maior risco e valor arquitetural. estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda. • 4 P: Pessoal. onde requisitos .25) Gestão de Risco 26) Gestão de Qualidade 27) Gestão de Modificações MÓDULO 5 . Numa primeira iteração um ou dois requisitos. 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. a idéia é ter uma visão inicial do problema. 2. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos.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. o escopo do projeto. Projeto e Processo. são especificados em detalhes. usando o paradigma OO. • É baseado em componentes que realizam interfaces. • É iterativo e incremental.

Especificação e documentação. 4. Projeto (classes de projeto. Testes. Ao fim da fase. • O PU utiliza modelos que descrevem o sistema a ser desenvolvido sob um certo ponto de vista e seu ambiente. Análises (classes e responsabilidade). Análise e negociação.antigos são melhor esclarecidos e novos são detalhados. 2. 90% dos requisitos foram levantados em detalhes. Identificação. Implementação . 6. Distribuição (nós físicos e os componentes em cada nó). O processo de engenharia de requisitos é composto por quatro atividades de alto nível: 1. 4. 2. interfaces). Validação. os principais riscos foram tratados e pode-se então fazer estimativas mais realistas. 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. São os seguintes os modelos: 1. 3. 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? . o núcleo do sistema foi implementado com alta qualidade. Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação. 3. determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. subsistemas. Requisitos (funcionais e não funcionais). Transição: testes finais e implantação. a partir das restrições do projeto. 3. • Este processo deve ser precedido de estudos de viabilidade que. 5. 4.

de sw genérico. 7) Cite 3 características do ciclo de vida espiral. 9) Por que um bom levantamento de requisitos é importante? 10) Cite e descreva os tipos de manutenção de software. 8) Cite 3 características do ciclo de vida em cascata. 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. b) Software de Aplicação. 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? .5) Descreva o Modelo Ambiental da Análise Essencial. 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. 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. 6) Descreva o Modelo Comportamental da Análise Essencial. 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. 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. 11) O que é um processo de desenvolvimento de software? 12) Apresente as principais atividades de um processo de des.

20) Cite 2 modelos evolucionários de processo de software. Em um segundo momento. 19) Descreva o modelo RAD. Considerando o desenvolvimento de um sistema integrado de gestão (ERP). 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. desenvolveu seus trabalhos seguindo os quatro subprocessos da engenharia de requisitos. foi verificado se os requisitos identificados atendiam às . 26) Quais os 4 principios da filosofia de Desenvolvimento Ágil? 27) Descreva os passos envolvidos na prototipagem. Finalmente. a equipe de projeto. logo em seguida. Cada workflow é um conjunto de atividades executadas por vários membros do projeto. 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. 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. o empacotamento em componentes de software dos elementos do modelo de projeto — tais como arquivo de código-fonte. 28) Descreva o modelo de desenvolvimento em cascata. responsável pelo mapeamento dos requisitos. Inicialmente. 18) Cite 3 exemolos de modelos incrementais de processo. 17) Para que servem os modelos prescritivos de processo. foram feitas a análise e a avaliação para se verificar se o sistema seria útil ao negócio. cinco workflows acompanham o conjunto das fases de desenvolvimento de software. foram documentados. os requisitos foram identificados e analisados e.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.

após análise. Nessa perspectiva. E) a computação seja acionada por troca de mensagens entre objetos. a adoção do paradigma orientado a objetos implica necessariamente que: A) os usuários utilizem as aplicações de forma mais simples. 04) Na etapa de projeto orientado a objetos. 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. 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. B) os sistemas sejam encapsulados por outros sistemas. Tendo sido executado esse procedimento. uma na Índia e outra na China. apenas. C) conversão das bases de dados do sistema e teste de integração do sistema. 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.demandas dos usuários. E) análise de requisitos do sistema e definição da arquitetura do sistema. 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. são desenvolvidas as atividades de: A) definição da arquitetura do sistema e conversão das bases de dados do sistema. D) os objetos sejam implementados de maneira eficiente e simples. Considerando o relatório da auditoria independente. no contexto de um processo de desenvolvimento de software. C) os programadores de aplicações sejam mais especializados. 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. 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. . conceitos computacionais. B) identificação dos objetos do sistema e definição da arquitetura do sistema. D) teste de integração do sistema e análise de requisitos do sistema. uma empresa independente de auditoria.

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. KPA SPTO – acompanhamento de projeto. C) a melhoria do desempenho da área de SI. KPA SPE – engenharia de produtos de software. C) nível 2. . Considere que. tempo e escopo. foi constatado que este não atendia às especificações esperadas pelos usuários. D) nível 3. o nível do modelo SW-CMM e a KPA (área chave de processo) mais adequados para a situação apresentada são. ampliando-se. suas chances de sucesso. descrito no PMBOK. tempo e escopo. E) risco. B) nível 2. envolve um conjunto de nove áreas de conhecimento a serem consideradas com vistas a melhorar o processo de gestão de um projeto. seja pelo aumento de produtividade dos profissionais. 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. D) a antecipação de tendências. KPA RM – gestão de requisitos. pela alocação dos recursos e resultados intermediários e incrementais. que são as áreas de gerenciamento de: A) escopo.Nessa situação. seja pela alocação mais eficaz de recursos. conseqüentemente. B) tempo. A) nível 2. contratação e custo.respectivamente. Nessa situação. KPA SPP – planejamento. KPA OPD – definição do processo da organização. 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. E) nível 3. 06) O modelo de gerenciamento de projetos do PMI (Project Management Institute). custo e tempo. evidenciam-se áreas de conhecimento que compõem a chamada tripla restrição. B) o comprometimento da alta administração. D) contratação. C) custo. contratação e risco. envolvendo inovação tecnológica contínua. no desenvolvimento de um sistema de vendas de uma empresa que atua no segmento industrial. Nas reuniões com os usuários para a entrega do sistema.

III. E) Todos os itens estão certos. com base em determinada implementação.E) a identificação. o objetivo é explorar-se a menor unidade de projeto. Assinale a opção correta. procurando-se identificar erros de lógica e de implementação de cada módulo. I .A técnica de teste funcional. que estabelece os requisitos de teste com base em determinada implementação.Critérios com base na complexidade. 09) O gerente de desenvolvimento de uma empresa de TI examinou a seguinte planilha sobre andamento de projetos. estabelecida na fase de projeto. 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. D) Apenas os itens II e III estão certos. permite verificar se são atendidos os detalhes do código e solicita a execução de partes ou de componentes elementares do programa. na célula inferior direita. o objetivo é descobrir erros associados às interfaces entre os módulos quando esses são integrados. C) Apenas os itens I e III estão certos. . informação e conhecimento. na fase de teste de integração. julgue os itens que se seguem. para se construir a estrutura do software. projeto | P1 P2 percentual 50 80 completado (em %) | percentual do orçamento já despendido (em %) 70 65 Com base nessa planilha e com relação aos conceitos de dado. em fluxo de controle e em fluxo de dados. B )Apenas os itens I e II estão certos. I.O número 65. II. A) Apenas um item está certo. 08)Julgue os seguintes itens referentes a teste de software.Na fase de teste de unidade. são utilizados pela técnica estrutural de teste. a técnica de teste estrutural aborda o software de um ponto de vista macroscópico e estabelece os requisitos de teste. é um dado.

Associar o número 80 (célula inferior central) ao percentual completado (em %) e a P2.I e IV.o desenvolvimento de estudos que visem à ampliação da separação entre as ciências naturais e sociais.II e IV. B . II. qualquer que seja a natureza dos elementos que os compõem e as relações ou forças existentes entre eles. IV . conhecimento do negócio. D) III e IV. V . IV . Estão certos apenas os itens: A . diversos problemas requerem abordagem multidisciplinar para serem resolvidos.Dizer o quanto P1 vai precisar a mais do que foi inicialmente previsto no orçamento é um conhecimento. 10) O objetivo da Teoria Geral dos Sistemas (TGS) é a formulação dos princípios válidos para os sistemas em geral.o desenvolvimento de princípios únicos para cada área do conhecimento. III. Na área de sistemas de informação. tais como aspectos de relacionamento interpessoal.Dizer que P1 está adiantado ou atrasado é uma informação.II e III. C . 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 . resolução de conflitos. diferenças culturais etc.II . na área de desenvolvimento de software.I e II. e concluir que o projeto P2 está 80% completado é um conhecimento. C) II e III.o incentivo à especialização total das áreas do conhecimento.o desenvolvimento dos princípios unificadores quetranscendem o universo das ciências individuais. Os propósitos da TGS que podem contribuir para a resolução desses problemas incluem I. Estão certos apenas os itens: A) I e II. B) I e V. E .III e IV. Por exemplo. D . a especificação de requisitos apresenta vários desafios desse tipo.a integração de contribuições de várias ciências na busca de solução dos problemas. III .

• Colaboração. mantendo uma versão 1. Registra toda a evolução do projeto. registrando toda e qualquer alteração feita em cada item versionado. Essa área é individual e isolada das demais áreas de trabalho. permite reconstruir uma revisão específica do arquivo sempre que desejado. Mantém linhas diferentes de evolução do mesmo projeto.0 enquanto a equipe prepara uma versão 2.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. • Variações no Projeto. 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. Por exemplo.: O controle de versão é composto de duas partes: o repositório e a área de trabalho. . 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. O desenvolvedor não trabalha diretamente nos arquivos do repositório. cada alteração sobre cada arquivo. Além disso. Orepositório armazena todo o histórico de evolução do projeto. 17) Como funciona o controle de versão? R. 16) Como o Controle de versão apóia o desenvolvimento de software? R.: • Histórico. quando e onde.0. Com essas informações sabe-se quem fez o que. o que traria reaparecimento de defeitos e perda de funcionalidades. Ao invés disso.

A diferença está em como cada uma dessas partes está arranjada. 18) O que é qualidade de software? R. dentro daquilo que foi acordado inicialmente. Cada commit gera uma nova revisão no repositório. O commit envia um pacote contendo uma ou mais modificações feitas na área de trabalho (origem) ao repositório (destino). o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente. isto é. O update faz o inverso. As "fotos" antigas são mantidas e podem ser recuperadas e analisadas sempre que desejado. data e autor.A sincronização entre a área de trabalho e o repositório é feita através dos comandos decommit e update.: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. 19)O que é qualidade de software segundo a norma ISO 9000 . Uma revisão funciona como uma "foto" de todos os arquivos e diretórios em um determinado momento da evolução do projeto. envia as modificações contidas no repositório (origem) para a área de trabalho (destino). O conjunto dessas revisões é justamente o histórico do projeto. contendo as modificações feitas. Tanto o controle de versão centralizado quanto o distribuído possuem repositórios e áreas de trabalho. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo.

identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo.: O "CMM . Dirige-se ao processo de desenvolvimento de produtos e serviços. A GQS atua como "guardiã". 21) O que é o modelo CMM R. 22) O que é CMMI? R. fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.Capability Maturity Model for Software /SEI" é uma estrutura-"framework". Integrated Product and Process Development (IPPD). 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.: Segundo a norma ISO 9000 (versão 2000). dos processos de desenvolvimento e dos produtos gerados. gerenciado e otimizado. definido.2) apresenta três modelos: ▪ CMMI for Development (CMMI-DEV) publicada em agosto de 2006. 20) O que é GQS (Garantia da Qualidade de Software)? R. Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon. Este caminho de melhoria é definido por cinco níveis de maturidade: inicial. processo ou sistema cumpre os requisitos inicialmente estipulados para estes. que descreve os principais elementos de um processo de desenvolvimento de software efetivo. integrando diferentes modelos e disciplinas.R. A versão atual do CMMI (versão 1.: 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). a qualidade é o grau em que um conjunto de características inerentes a um produto. Software Engineering (SW).: 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. Supplier Sourcing (SS)). repetitivo. .

pois cada estágio serve de base para o próximo. ▪ CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009.: é 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. 23) Quais os tipos de representação do CMMI? R. Dirige-se aos processos de empresas prestadoras de serviços.: Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada.: Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É 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. É 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. Dirige-se aos processos de aquisição e terceirização de bens e serviços. 24) Para que serve a representação contínua? R.: Contínua e por estágios.▪ CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. .

Tal como o nome sugere. recursos disponíveis) e temporais associadas ao projeto. Validação. de um ponto de vista tecnológico e organizacional. por exemplo). Uma forma de avaliar a viabilidade de um projeto é obter. organizacionais (econômicas. entre outras). 2005): 1. Especificação e documentação. 27) Quais as 4 atividades de alto nível da engenharia de Requisitos? R. a sua "manutenção"). será que esta é possível? 29) Em que consiste um estudo etnográfico? . se incluirmos a fase posterior à produção do documento (isto é. Uma outra atividade que se pode considerar que faz também parte deste processo. 3. será que o sistema pode ser implementado? ▪ Caso haja necessidade de integração entre diferentes sistemas. a resposta às seguintes questões: ▪ Será que o sistema contribui para os objetivos da organização? ▪ Dadas as restrições tecnológicas. o projeto é viável. políticas. 28) Em que consiste um estudo de viabilidade? R. é a gestão dos requisitos (change management. deve ser feito um estudo de viabilidade. Identificação.Este processo deve ser precedido de estudos de viabilidade que. através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas. 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). pretende-se com este estudo avaliar se. ambientais. determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. a partir das restrições do projeto.: Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto.: O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares. 2. Análise e negociação. 4.

é 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. O objetivo é maximizar a produtividade pela minimização dos erros. 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. 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. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa. correções de defeitos e adaptações para diferentes hardwares e sistemas operacionais. Essas versões incorporam propostas de mudanças. são criadas muitas versões diferentes de software. porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Esta observação pode ser acompanhada de registros áudio/vídeo. É possível que haja várias versões em desenvolvimento e em uso . pelo que convém ter algum cuidado na escolha do mesmo.R. É necessário gerenciar os sistemas em desenvolvimento porque. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente". à medida que eles se desenvolvem.: Os Estudos Etnográficos são uma análise da componente social das tarefas desempenhadas numa dada organização. organizar e controlar modificações de software que está sendo construído por uma equipe de programação. A gestão de configuração é a arte de identificar.” 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.

como tal. que pode ser substituído. o componente é um elemento independente. Já para Szyperski [4]. com ênfase na decomposição dos sistemas. os componentes são usualmente construídos a partir de muitos “objetos” de software (embora a construção não seja . mas sim um dispositivo de software que possua uma interface bem definida.: Engenharia de Software Baseada em componentes é um ramo de Engenharia de Software. 32) O que é um componente de software? R. quase independente. 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. Em muitos sentidos. Componentes possuem uma interface. No caso dos componentes "comerciais de prateleira" ( ou commercial off-the-shelf . Ao contrário de objetos em POO.ao mesmo tempo.COTS). e substituível parte de um sistema que cumpre uma função clara no contexto de uma arquitetura bem definida". Mas para Krutchen [5]. o componente não é necessariamente uma tecnologia implementada especificamente e nem a aplicação. Componentes são definidos para oferecer um certo nível de serviço. ao engenheiro de software é dada apenas uma interface externa bem-definida a partir da qual ele deve trabalhar. não compartilham estado e comunicam-se por troca de mensagens contendo dados. usadas para comunicação entre os próprios componentes.: Brown e Wallnau[3] descrevem um componente como "uma não-trivial. Mas a definição é levada ainda além. Eles empregam regras de herança. É necessário manter o controle das mudanças que foram implementadas e de como essas mudanças foram incluídas no software. esta descrição é similar a de um objeto em POO. pois tem uma função clara no contexto em que foi definido. contudo. em componentes funcionais e lógicos com interfaces bem definidas. o engenheiro de software sabe pouco ou nada sobre o funcionamento interno de um componente. Componentes são considerados como estando num nível de abstração mais alto que do que Objetos e. Ao invés disso. 31) Em que consiste a ES baseada em componentes (ESBC)? R. ele é significativo. Brown e Wallnau descrevem um componente de software como “uma unidade de composição contratualmente especificada e somente com dependências contextuais explícitas”.

A abordagem é criar ou adaptar os componentes para que sejam utilizados em diversos sistemas. pois foram usados e testados( e reusados e retestados) e muitas diferentes aplicações. pré-fabricados. O objetivo é estabelecer um mecanismo em que engenheiros de software possam partilhar estes componentes usando-os em sistemas futuros. Os assim chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em um dado nível de serviço.aplicações com funcionalidade(ou intenção de funcionalidade) similar. Isso auxilia na manutenção dos sistemas uma vez que. com a desvantagem de que. precisam ser confiavelmente testadas. adaptação.confinada a POO) e fornecem uma unidade de funcionalidade coerente. a ESBC almeja: ▪ Componentes qualificados [6] ▪ Componentes adaptados ▪ Componentes aglutinados ▪ Componentes atualizados 33) Quais os 2 processos que correm em paralelo na ESBC? R. Essa idéia vem ao encontro da reutilização que busca flexibilizar o desenvolvimento. remoção e substituição de partes do sistema sem a necessidade de sua completa substituição. 34) Quais os principais modelos de componentes existentes? . A desvantagem.: a) Engenharia de Domínio Objetiva identificar. dentro de um domínio de aplicação específico. como podem ou não ser acuradas. não há código fonte disponível. 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. Componentes podem ser caracterizados com base em seu uso no processo de ESBC: Como mencionado acima temos os COTS. construir. no geral. entretanto. e sendo assim. e os serviços que este oferece. catalogar e disseminar um conjunto de componentes de software que tenham aplicabilidade para software existentes e futuros. Um domínio de aplicação é como uma família de produtos . Adicionalmente aos COTS. é que estes tipos de componentes deveriam(em teoria) ser mais robustos e adaptáveis. São componentes que podem ser comprados. permite a integração de novos componentes e/ou a atualização dos já existentes. a definição do uso do componente dada pelo fabricante(desenvolvedor).

35) Qual o objetivo da gestão de riscos? R. segundo a SEI? R. processo e estrutura relativos a perceber oportunidades enquanto gerencia-se efeitos adversos. melhora no planejamento.: • 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. toda gestão de risco e toda tomada de decisão lida com essa questão. Os benefícios são melhores decisões. O principal ponto de gerenciar riscos é avaliar a incerteza do futuro de modo a tomar a melhor decisão possível. Em geral. menos surpresas. ▪ DCOM (Distributed Component Obejct) e COM/COM+ (Component Object Model) da Microsoft. tanto nos níveis estratégicos quanto operacionais.: Gestão de risco pode ser definido como cultura.R. e ▪ JavaBeans e Entreprise JavaBeans (EJB) da Sun.: ▪ CMM (CORBA Component Model) do OMG (Object Management Group). 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".: . melhora no relacionamento com as partes interessadas. Acreditamos que gestão de risco deveria ser parte integral de boas práticas de negócios. 36) Quais os tipos de riscos em software? R. na performance e na efetividade e ainda.

b) é uma aresta entre vértice a e b. Um grafo pode ser representado de duas formas: uma baseada numa representação visual. em programas de computador. (c. e.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. d. .usando círculos fechados para vértices e retas ou curvas para arestas e outra mais formal que usa matrizes e vetores. (b. d). E) é composto por um conjunto V não vazio de vértices(nós) e um conjunto (E) de arestas (arcos). (b. e). c. onde: V = {a. b). onde cada aresta conecta dois vértices. (c. quais suas vantagens no desenvolvimento de sistemas? Consideraçõe sobre a Teora dos Grafos Um grafo G = (V. c). f)} (a. f} E = {(a.E). b. (d. A segunda forma será usada nas estruturas de dados que trabalham com grafos. A seguir á apresentado um exemplo de grafo G (V. 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. e).

vn). As arestas são também consideradas como parte do caminho.A. Um laço é um arco com extremidades n-n. Além da orientação podem ser impostos pesos. Um circuito simples é chamado de ciclo. Um grafo é conectado (conexo) se existe um caminho entre dois vértices quaisquer do grafo. Programa make do Unix O programa make do Unix toma como entrada um arquivo texto contendo comandos da forma . … (vn . Um caminho é uma seqüência de vértices v1.Um grafo pode ser dirigido ou não dirigido. para algum nó n. Um grafo sem ciclos é chamado de acíclico. x é o ponto (extremidade) inicial e y o ponto final de a. dizemos que um vértice é adjacente a outro vértice. vn conectados por arestas (v1. Um circuito é um caminho onde o vértice final é igual ao inicial. No dirigido a ordem dos vértices importa. O comprimento de um caminho é dado pelo número de arcos que ele contém.1. onde: N = Um conjunto não vazio de nós A = Um conjunto de arcos g = Função que associa a cada arco. Um grafo dirigido é também chamado de dígrafo e consiste de uma tripla ordenada (N. (v2. E) é usualmente representado por uma matriz de adjacências.y) de nós Na função g. v3). 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. v2). Um circuito será simples se nenhum vértice aparecer mais de uma vez. Um sumidouro é um vértice com grau de saída 0 e grau de entrada > 1. v2. onde cada arco tem um valor numérico associado. Dado um grafo. se existe no grafo uma aresta que une os dois. um par ordenado (x. Dois arcos com as mesmas extremidades são ditos paralelos. Um grafo G = (V. …. num não dirigido esta ordem é indiferente. O grau de um vértice é o número de arestas adjacentes a ele.g). exceto o primeiro e o último. Uma fonte é um vértice com grau de entrada 0 e grau de saída > 1.

h b. 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. A função void f( { if (i > 0) { j = 1.c a.obj b.c cc -c c.obj b.c prog prog. no caso de if’s e while’s).c"). que são comandos para o Unix que possivelmente deverão atualizar arquivo Nome. make irá compilá-lo novamente (Comando "cc -c b.obj b. goto L1. b. Ex.obj c.obj : b.obj".obj ".obj : a.Nome : d1 d2 … dn Comandos Nome é o nome de um arquivo que depende dos arquivos d1 d2 … dn.obj" será mais novo que prog que será linkado por "ln -o prog a.obj c. por exemplo.obj c.obj a.c for modificado.: prog : ln -o a.c cc -c b.c cc -c c . Make lê este texto e executa Comandos se a data de última atualização de algum arquivo di for mais nova que de Nome.h a. ele executa Comandos.obj : c. . Se. se algum di for mais novo que Nome. Então "b. porque ele será mais novo que "b.c prog. As relações de dependências do make podem ser colocada em forma de um grafo.obj ln é o linker e cc o compilador. Ou seja.

L1. return 1. Exercícios Será cobrado na prova transformação de códigos em grafos e verficação de sua utilidade. } else j = 10.a = 10. 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. } seria transformada no grafo Para descobrir o código morto. . A resposta para o grafo acima é : não. 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".

You're Reading a Free Preview

Descarregar
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->