Engenharia de Software

Visualizações: 203
Classificação: (0)

Este livro apresenta uma excelente introdução aos fundamentos da engenharia de software. Com uma abordagem equilibrada dos fundamentos teóricos da engenharia de software, assim como dos aspectos mais práticos do ciclo de vida do software, o livro trata tanto das técnicas tradicionais como das técnicas orientadas a objetos. Em um estilo simples e fácil de ser compreendido pelos estudantes, conceitos complexos são apresentados de forma clara e compreensível. O livro inclui também processos ágeis de software com código-fonte aberto e também o Processo Unificado, extremamente importante no desenvolvimento de software orientado a objetos.

FORMATOS DISPONíVEIS

27 capítulos

Formato Comprar item avulso Adicionar à Pasta

Capítulo 1: O Escopo daEngenharia de Software

PDF Criptografado

Capítulo

1

O Escopo da

Engenharia de Software

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Definir o que se entende por engenharia de software.

• Descrever o modelo clássico de ciclo de vida da engenharia de software.

• Explicar por que o paradigma de orientação a objetos é agora tão amplamente aceito.

• Discutir as implicações dos vários aspectos da engenharia de software.

• Distinguir entre a visão clássica e a visão moderna da manutenção.

• Discutir a importância de fazer planejamento, testes e documentação continuamente.

• Avaliar a importância de aderir a um código de ética.

Uma história bem conhecida fala de um executivo que recebeu uma conta gerada por computador no valor de $0,00. Após uma boa gargalhada com os amigos por causa dos “computadores idiotas”, o executivo jogou a conta fora. Um mês depois, chegou outra conta similar, dessa vez informando que se passaram 30 dias do prazo. Depois, chegou a terceira conta. A quarta conta chegou um mês depois, acompanhada de uma mensagem que insinuava que haveria a possibilidade de ele ser acionado judicialmente caso a conta de $0,00 não fosse paga.

 

Capítulo 2: Modelos de Ciclo de Vida de Software

PDF Criptografado

Capítulo

2

Modelos de Ciclo de Vida de Software

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Descrever como os produtos de software são desenvolvidos na prática.

• Entender o modelo de ciclo de vida árvore de evolução.

• Avaliar o impacto negativo de mudanças em produtos de software.

• Utilizar o modelo de ciclo de vida iterativo e incremental.

• Compreender o impacto da Lei de Miller sobre a produção de software.

• Descrever os pontos fortes do modelo de ciclo de vida iterativo e incremental.

• Compreender a importância de minimizar os riscos o quanto antes.

• Descrever processos ágeis, inclusive extreme programming.

• Comparar e contrastar uma série de outros modelos de ciclo de vida.

O Capítulo 1 descreveu como os produtos de software seriam desenvolvidos em um mundo ideal. O assunto deste capítulo é o que acontece na prática. Como será explicado, há diferenças enormes entre a teoria e a prática.

 

Capítulo 3: O processo de software

PDF Criptografado

Capítulo

3

O processo de software

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Explicar por que os modelos de ciclo de vida bidimensional são importantes.

• Descrever os cinco principais fluxos de trabalho do Processo Unificado.

• Enumerar os artefatos testados no fluxo de trabalho de teste.

• Descrever as quatro fases do Processo Unificado.

• Explicar a diferença entre os fluxos de trabalho e as fases do Processo Unificado.

• Avaliar a importância do aperfeiçoamento do processo de software.

• Descrever o modelo de maturidade de capacidade (CMM).

O processo de software é a maneira pela qual produzimos software. Ele abrange a metodologia (Seção 1.11), com seu modelo de ciclo de vida de software (Capítulo 2) e técnicas subjacentes, as ferramentas usadas (Seções 5.4 a 5.10) e, acima de tudo, os indivíduos que estão criando o software.

Empresas diferentes possuem processos de software diferentes. Consideremos, por exemplo, a questão da documentação. Algumas empresas julgam que o software que produzem é autodocumentativo, isto é, o produto pode ser compreendido simplesmente ao ler seu código-fonte. Outras empresas, porém, documentam seus produtos de forma intensiva.

 

Capítulo 4: Equipes

PDF Criptografado

Capítulo

4

Equipes

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Explicar a importância de uma equipe bem organizada.

• Descrever como as equipes hierárquicas modernas são organizadas.

• Analisar os pontos fortes e fracos de uma série de organizações de equipes diferentes.

• Avaliar as questões que surgem ao se escolher uma organização de equipe apropriada.

Sem engenheiros de software competentes e bem treinados, um projeto de software está fadado ao fracasso. Entretanto, ter as pessoas certas não é o suficiente; as equipes devem ser organizadas de tal forma que os seus membros possam trabalhar de modo produtivo e em cooperação mútua. A organização de equipes é o tema deste capítulo.

4.1   Organização de Equipes

A maioria dos produtos é muito grande para ser feita por um único profissional de software dentro das limitações de tempo impostas. Conseqüentemente, o produto deve ser alocado a um grupo de profissionais de software organizados sob a forma de uma equipe. Consideremos, por exemplo, o fluxo de trabalho de análise. Para especificar o produto-alvo em dois meses seria necessário atribuir a tarefa a três especialistas em análise, organizados em uma equipe sob direção do gerente de análise. De forma similar, a tarefa de projeto poderia ser dividida entre membros da equipe de projeto.

 

Capítulo 5: As Ferramentasde Trabalho

PDF Criptografado

Capítulo

5

As Ferramentas de Trabalho

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Avaliar a importância do refinamento gradual e utilizá-lo na prática.

• Aplicar a análise de custo–benefício.

• Escolher métricas de software apropriadas.

• Discutir o escopo e a taxonomia de ferramentas CASE.

• Descrever ferramentas de controle de versões, ferramentas de controle de configurações e ferramentas de consolidação.

• Compreender a importância do CASE.

Os engenheiros de software precisam de dois tipos de ferramentas. Primeiramente, são usadas as ferramentas analíticas no desenvolvimento de software, como o refinamento gradual e a análise de custo–benefício. Em seguida, vêm as ferramentas de software, isto é, produtos que ajudam as equipes de engenheiros a desenvolverem e fazerem a manutenção do software.

Essas são, normalmente, chamadas de ferramentas CASE (CASE é um acrônimo para computer-aided software engineering, engenharia de software com o auxílio do computador). O presente capítulo é dedicado a esses dois tipos de ferramentas de trabalho, primeiramente as ferramentas teóricas e, em seguida, as ferramentas de software (CASE). Começaremos com o refinamento gradual.

 

Capítulo 6: Testes

PDF Criptografado

Capítulo

6

Testes

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Descrever questões relativas à garantia da qualidade.

• Descrever como realizar testes que não se baseiam em execução (inspeções) de artefatos.

• Descrever os princípios dos testes baseados em execução.

• Explicar o que precisa ser testado.

Os modelos de ciclo de vida de software, com uma freqüência muito grande, incluem uma fase de testes distinta após a integração e antes da manutenção pós-entrega. Nada poderia ser mais perigoso do que isso sob o ponto de vista de se tentar chegar a um software de alta qualidade. Os testes são um componente essencial do processo de software e uma atividade que deve ser realizada ao longo de todo o ciclo de vida. Durante o fluxo de trabalho de levantamento de necessidades, as necessidades precisam ser verificadas; durante o fluxo de trabalho de análise, as especificações devem ser verificadas, e o plano de gerenciamento de produção de software deve passar por exame similar. O fluxo de trabalho de projeto requer verificação meticulosa em cada um dos estágios. Durante o fluxo de trabalho de implementação, cada artefato de código, certamente, tem de ser testado, e o produto como um todo precisa de testes quando estiver totalmente integrado. Após passar pelo teste de aceitação, o produto é instalado e a manutenção pós-entrega é iniciada. E, de mãos dadas com a manutenção, acontecem repetidas verificações de versões modificadas do produto.

 

Capítulo 7: De Módulosa Objetos

PDF Criptografado

Capítulo

7

De Módulos a Objetos

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Projetar módulos e classes com elevada coesão e baixo acoplamento.

• Compreender a necessidade de ocultamento de informações.

• Descrever as implicações referentes à engenharia de software da herança, do polimorfismo e da vinculação dinâmica.

• Fazer a distinção entre generalização, agregação e associação.

• Discutir o paradigma da orientação a objetos com mais profundidade que antes.

Algumas das revistas de computação mais sensacionalistas parecem sugerir que o paradigma da orientação a objetos foi uma descoberta nova, dramática e repentina de meados dos anos

1980, uma alternativa revolucionária para o popular paradigma clássico. Esse não é o caso.

Em vez disso, a teoria da modularidade passou por um progresso estável durante as décadas de 1970 e 1980, e os objetos eram simplesmente uma evolução dentro da teoria da modularidade (mas veja o Quadro 7.1). Este capítulo descreve os objetos no contexto da modularidade.

 

Capítulo 8: Reusabilidade e Portabilidade

PDF Criptografado

Capítulo

8

Reusabilidade e

Portabilidade

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Explicar por que a reutilização é tão importante.

• Compreender os obstáculos para a reutilização.

• Descrever as técnicas para conseguir a reutilização durante os vários fluxos de trabalho.

• Discutir o impacto da reutilização sobre a facilidade de manutenção.

• Explicar por que a portabilidade é essencial.

• Compreender os obstáculos para se conseguir a portabilidade.

• Desenvolver software portável.

Se reinventar a roda fosse um crime, muitos profissionais da área de software estariam hoje em dia apodrecendo na cadeia. Por exemplo, existem toneladas (para não dizer centenas de toneladas) de programas de folha de pagamento em COBOL, todos fazendo basicamente a mesma coisa. Certamente, o mundo precisa apenas de um programa de folha de pagamento que possa ser executado em uma grande variedade de hardware e que possa ser adaptado, se necessário, para atender às necessidades específicas de uma determinada organização. Entretanto, em vez de utilizar programas de folha de pagamento anteriormente desenvolvidos, uma miríade de empresas ao redor do mundo criou seus programas de folha de pagamento a partir da estaca zero. Neste capítulo, investigaremos por que os engenheiros de software se comprazem em continuamente reinventar a roda e o que pode ser feito para se ter software portável construído usando-se componentes reutilizáveis. Iniciaremos estabelecendo a distinção entre portabilidade e reusabilidade.

 

Capítulo 9: Planejamento e Estimativas

PDF Criptografado

Capítulo

9

Planejamento e

Estimativas

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Explicar a importância do planejamento.

• Estimar o tamanho e o custo para se criar um produto de software.

• Avaliar a importância das estimativas de atualização e de acompanhamento.

• Preparar um plano de gerenciamento de projeto que se conforme ao padrão IEEE.

Os desafios de criar um produto de software não possuem nenhuma solução fácil. Construir um produto de software grande leva tempo e consome recursos. O planejamento meticuloso no início do projeto talvez seja o único e mais importante fator que ditará seu sucesso ou fracasso. O planejamento inicial, porém, de forma alguma é o suficiente. O planejamento, assim como os testes, deve continuar ao longo do processo do desenvolvimento de software e de manutenção. Não obstante a necessidade de planejamento contínuo, essas atividades atingem um pico após as especificações terem sido formuladas, mas antes de as atividades de projeto começarem. Nesse estágio do processo, são feitas estimativas de custo e duração razoáveis, e é produzido um plano detalhado para completar o projeto.

 

Capítulo 10: Levantamento de Necessidades

PDF Criptografado

Capítulo

10

Levantamento de

Necessidades

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Executar o fluxo de trabalho de levantamento de necessidades.

• Elaborar o modelo de negócio.

• Estabelecer as necessidades.

• Construir um protótipo rápido.

As chances de um produto ser desenvolvido dentro do prazo e do orçamento estabelecidos são um tanto escassas, a menos que os membros da equipe de desenvolvimento de software concordem com aquilo que o produto de software fará. A primeira etapa para se alcançar essa unanimidade é analisar a situação atual do cliente da forma mais precisa possível. Por exemplo, é inadequado dizer: “O cliente precisa de um sistema de projeto com o auxílio de um computador, pois ele alega que seu sistema de projeto manual é péssimo”. A menos que a equipe de desenvolvimento saiba exatamente o que está errado com o sistema manual atual, existe uma grande probabilidade de que aspectos do novo sistema computadorizado sejam igualmente “péssimos”. De forma semelhante, se um fabricante de computadores pessoais está considerando a possibilidade de desenvolver um novo sistema operacional, o primeiro passo é avaliar o sistema operacional atual e analisar de forma cuidadosa exatamente por que ele é insatisfatório. Para dar um exemplo extremo, é vital saber se o problema existe apenas na mente do gerente de vendas que amaldiçoa o sistema operacional pelas fracas vendas ou se os usuários do sistema operacional estão completamente desencantados com sua funcionalidade e confiabilidade. Apenas depois de ter uma clara idéia da situação atual a equipe poderá tentar responder à questão crítica: “O que o novo produto tem de ser capaz de fazer?”. O processo de responder a essa pergunta é o principal objetivo do fluxo de trabalho de levantamento de necessidades.

 

Capítulo 11: Análise Clássica

PDF Criptografado

Capítulo

11

Análise Clássica

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Realizar análise de sistemas estruturada.

• Elaborar especificações formais usando máquinas de estados finitos, redes de Petri e Z.

• Comparar e contrastar métodos de análise clássica.

Um documento de especificação deve satisfazer a duas exigências mutuamente contraditórias.De um lado, esse documento deve ser claro e inteligível para o cliente que, provavelmente, não é um especialista em informática. Afinal, o cliente está pagando pelo produto e, a menos que ele acredite que está realmente entendendo como será esse novo produto, há grandes chances de decidir por não autorizar o seu desenvolvimento ou então de procurar outra empresa para fazê-lo.

De outro lado, o documento de especificação deve ser completo e detalhado, pois é praticamente a única fonte de informações disponível para elaborar o projeto. Mesmo que o cliente concorde que todas as necessidades foram determinadas de forma acurada durante o levantamento de necessidades, se o documento de especificações contiver falhas como omissões, contradições ou ambigüidades, o resultado inevitável será a ocorrência de imperfeições no projeto, que serão transmitidas para a implementação. Conseqüentemente, são necessárias técnicas para representar o produto desejado em um formato suficientemente não técnico, para ser inteligível para o cliente, mas, ao mesmo tempo, preciso o bastante para resultar em um produto isento de imperfeições ao ser entregue ao cliente, no final do ciclo de desenvolvimento. Essas técnicas de análise (especificações) são o tema deste capítulo e do Capítulo 12.

 

Capítulo 12: Análise Orientada a Objetos

PDF Criptografado

Capítulo

12

Análise Orientada a Objetos

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Executar a análise de fluxo de trabalho.

• Extrair as classes de contorno, de controle e de entidades.

• Realizar modelagem funcional.

• Realizar modelagem de classes.

• Realizar modelagem dinâmica.

• Executar a realização de casos de uso.

No Capítulo 11, examinamos vários tipos de técnicas clássicas de análise. Este capítulo corresponde ao Capítulo 11 em termos de orientação a objetos.

A OOA (Object-Oriented Analysis, em inglês, análise orientada a objetos) é uma técnica de análise semiformal para o paradigma de orientação a objetos. No Capítulo 11, mencionamos várias técnicas diferentes usadas para a análise de sistemas estruturados, todas basicamente equivalentes. De forma similar, foram concebidas bem mais de 60 técnicas diferentes para a OOA. Repetindo, todas as técnicas são em grande parte equivalentes. A seção

 

Capítulo 13: Projeto

PDF Criptografado

Capítulo

13

Projeto

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Elaborar o fluxo de trabalho de projeto.

• Executar projetos orientados a objetos.

• Realizar análise de fluxo de dados e análise de transações.

Ao longo dos últimos 40 anos, foram propostas centenas de técnicas de projeto. Algumas delas são variações de técnicas existentes; outras são radicalmente diferentes de qualquer proposta anterior. Poucas técnicas de projeto têm sido usadas por milhares de engenheiros de software; muitas têm sido usadas apenas pelos seus autores. Algumas estratégias de projeto, particularmente aquelas desenvolvidas no âmbito acadêmico, possuem uma sólida base teórica. Outras, dentre as quais várias elaboradas por pesquisadores no âmbito acadêmico, são de natureza mais pragmática; elas foram apresentadas porque seus autores constataram que elas funcionavam bem na prática. A maioria das técnicas de projeto é manual, porém, a automatização tem sido um aspecto cada vez mais importante no projeto, no mínimo, por auxiliar no gerenciamento da documentação.

 

Capítulo 14: Implementação

PDF Criptografado

Capítulo

14

Implementação

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Realizar o fluxo de trabalho de implementação.

• Realizar testes de unidades nas modalidades caixa preta, caixa transparente e aqueles que não se baseiam em execução.

• Realizar testes de integração, de produto e de aceitação.

• Avaliar a necessidade de práticas de programação e de padrões de programação adequados.

Implementação é o processo de converter o projeto detalhado em código. Quando isso é feito por um único indivíduo, o processo é relativamente bem compreendido. Porém, hoje em dia, a maioria dos produtos são muito grandes para ser implementados por apenas um programador dentro das restrições de tempo. Em vez disso, o produto é implementado por uma equipe, com todos trabalhando ao mesmo tempo em diferentes componentes do produto; isso

é denominado programação-feita-por-vários. Problemas associados à programação feita por vários são examinados neste capítulo.

 

Capíutlo 15: Manutenção Pós-entrega

PDF Criptografado

Capítulo

15

Manutenção

Pós-entrega

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Realizar manutenção pós-entrega.

• Avaliar a importância da manutenção pós-entrega.

• Descrever os desafios da manutenção pós-entrega.

• Descrever as implicações da manutenção no paradigma de orientação a objetos.

• Descrever as habilidades necessárias para a manutenção.

Um dos principais temas deste livro é a importância vital da manutenção pós-entrega.

Portanto, causa certa surpresa o fato de este ser um capítulo relativamente curto. A razão para isso é que a facilidade de manutenção tem de ser incorporada em um produto desde o princípio, e não deve ser comprometida em nenhum momento durante o processo de desenvolvimento. Na verdade, todos os capítulos anteriores foram dedicados ao assunto manutenção pós-entrega. O que é descrito neste capítulo é como garantir que a facilidade de manutenção não seja comprometida durante a própria manutenção pós-entrega.

 

Capítulo 16: Mais sobre a UML

PDF Criptografado

Capítulo

16

Mais sobre a UML

Objetivos de Aprendizagem

Após estudar este capítulo, você deverá ser capaz de:

• Modelar software usando casos de uso da UML, diagramas de classes, notas, diagramas de casos de uso, diagramas de interação, diagramas de estados, diagramas de atividades, pacotes, diagramas de componentes e diagramas de entrega.

• Perceber que a UML é uma linguagem, e não uma metodologia.

Ao longo deste livro, foram introduzidos vários elementos da UML (Booch, Rumbaugh e Jacobson, 1999). Mais especificamente, as notações para diagramas de classes, herança, agregação e associação foram descritas no Capítulo 7. No Capítulo 10, foram introduzidos os casos de uso, os diagramas de casos de uso e as notas. No Capítulo 12, foram acrescentados os diagramas de estados, os diagramas de colaborações e os diagramas seqüenciais.

Esse subconjunto da UML é adequado para compreender o conteúdo deste livro e para fazer todos os exercícios, bem como no projeto do Apêndice A. Entretanto, os produtos de software do mundo real são, infelizmente, muito maiores e consideravelmente mais complexos do que os do estudo de caso da MSG Foundation ou do projeto do Apêndice A.

 

Bibliografia

PDF Criptografado

Bibliografia

A indicação de capítulo entre parênteses mostra o capítulo no qual se fez referência ao item.

(Abrial, 1980) ABRIAL, J.-R, The Specification Language

Z: Syntax and Semantics Oxford University Computing

Laboratory, Programming Research Group, Oxford, Reino

Unido (abr. 1980). (Capítulo 11)

(Ackerman, Buchwald e Lewski, 1989) ACKERMAN, A.

F.; BUCHWALD, L. S. e LEWSKI, F. H. Software

Inspections: An Effective Verification Process, IEEE

Software 6 (maio 1989), p. 31-36. (Capítulo 6)

(Adolph, 1996) ADOLPH, W. S. Cash Cow in the Tar Pit:

Reengineering a Legacy System, IEEE Software 13 (maio

1996), p. 41-47. (Capítulo 15)

(Albrecht, 1979) ALBRECHT, A. J. Measuring Application

Development Productivity, Proceedings of the IBM

SHARE/GUIDE Applications Development Symposium,

Monterey, CA (out. 1979), p. 83-92. (Capítulo 9)

(Alexander, 1999) ALEXANDER, C. The Origins of Pattern

Theory, IEEE Software 16 (set./out.1999), p. 71-82.

 

Apêndice A: Projeto: Osric’s OfficeAppliances and Decor

PDF Criptografado

Apêndice

A

Projeto: Osric’s Office

Appliances and Decor

Osric Ormondsey é proprietário da Osric’s Office Appliances and Decor (OOA&D). Osric

é muito bem-sucedido no ramo de reforma e decoração de escritórios de executivos de alto escalão. Ele emprega vários empregados terceirizados e técnicos, visando fornecer um serviço completo e pronto para ser utilizado, que inclui infra-estrutura de telecomunicações

(telefone, fax, conexão de alta velocidade e assim por diante). Seu sucesso se deve em grande parte à agilidade com que ele responde às solicitações dos clientes; ele é conhecido por já ter reformado completamente um grande conjunto de salas de executivos em apenas dois dias.

Os clientes da Osric’s freqüentemente comentam de modo efusivo sobre a grande capacidade de seus dois técnicos de telecomunicações, tendo em vista os vários dissabores já enfrentados por eles com técnicos da companhia telefônica local. Osric percebe que pode expandir seus negócios se acrescentar uma divisão de telecomunicações à sua empresa. Ele decidiu, então, contratar os melhores técnicos disponíveis, oferecer-lhes um salário exorbitante, mais bônus, e anunciar seus serviços aos executivos cujos escritórios ele já reformou e decorou. Os executivos sabem que é muito mais eficaz para suas empresas pagar à Osric’s um valor alto por um técnico altamente especializado, que chega em uma ou duas horas, além de resolver o problema rapidamente, do que aguardar dois ou três dias por um técnico incompetente, que torna o problema ainda pior do que o original.

 

Carregar mais


Detalhes do Produto

Livro Impresso
Book
Capítulos

Formato
PDF
Criptografado
Sim
SKU
MFPP000001718
ISBN
9788563308443
Tamanho do arquivo
4,3 MB
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
Formato
PDF
Criptografado
Sim
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
SKU
Em metadados
ISBN
Em metadados
Tamanho do arquivo
Em metadados