Sunteți pe pagina 1din 38

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:

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

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;

Avaliação de Processo, algumas propostas:

  • 1. SCAMPI;

  • 2. CBA IPI;

  • 3. ISO 9001:2000 para Software

Referências:

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 Desenvolvimento em Cascata • Modelos Incrementais de Processo:

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

• Avaliação de Processo, algumas propostas: 1. SCAMPI; 2. CBA IPI; 3. ISO 9001:2000 para Softwarehttp://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 • " id="pdf-obj-5-55" src="pdf-obj-5-55.jpg">

• 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;

• Modelos Evolucionários de Processo de Software 1) Prototipagem • O cliente normalmente identifica requisitos gerais,2) Modelo Espiral • Combina a natureza iterativa da prototipagem com aspectos consolidados e sistemáticos do modelo em cascata; " id="pdf-obj-6-8" src="pdf-obj-6-8.jpg">

• Combina a natureza iterativa da prototipagem com aspectos consolidados e

sistemáticos do modelo em cascata;

<a href=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; " id="pdf-obj-7-2" src="pdf-obj-7-2.jpg">

• É aplicável a todos os tipos de desenvolvimento de software e fornece

uma imagem precisa do estado atual do projeto;

<a href=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; " id="pdf-obj-7-10" src="pdf-obj-7-10.jpg">

• Modelos Especializados de Processo

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;

<a href=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: " id="pdf-obj-8-5" src="pdf-obj-8-5.jpg">

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;

• Modelos Ágeis de Processo:

• 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;

◦ 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;

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
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
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
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

|

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, 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 centralizado e o distribuído?

e diferenças

entre

o controle

de versão

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 decommitengenharia 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 " id="pdf-obj-25-2" src="pdf-obj-25-2.jpg">

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

  • de Projeto

  • de Negócio

  • 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
riscos

antes que eles se tornem problemas reais

Analisar

Transformar os dados dos

  • em informações para tomada de decisão

Planejar

Traduzir e implementar as informações dos

riscos
riscos

em ações de decisão e

resolução de

riscos
riscos

Monitorar

Monitorar indicadores dos

  • e seus planos de resolução

Controlar Corrigir os desvios para os planos de resolução dos

riscos
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 v 1 , v 2 , …, v n conectados por arestas (v 1 ,

v

2 ),

(v 2 ,

v 3 ),

(v n - 1 ,

v n ).

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 : d 1 d 2 … d n Comandos

Nome é o nome de um arquivo que depende dos arquivos d 1 d 2 … d n . Make lê este texto e executa Comandos se a data de última atualização de algum arquivo d i for mais nova que de Nome. Ou seja, se algum d i 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

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
Exercícios

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