• Nenhum resultado encontrado

Acrescente dois outros mitos à lista apresentada na Seção 1.6 e declare a realidade que

1.3 Entenda o problema

44 capítulo 1 software e eNGeNHarIa De software 1.5.2 princípios gerais

1.11. Acrescente dois outros mitos à lista apresentada na Seção 1.6 e declare a realidade que

acompanha tais mitos.17

l

e i t u r a s e

f

o n t e s d e

i

n f o r m a ç ã o

C

o m P l e m e n ta r e s17

Há literalmente milhares de livros sobre o tema software. A grande maioria trata de lin- guagens de programação ou aplicações de software, porém poucos tratam do software em si. 17 A seção Leitura e fontes de informação adicionais apresentada no final de cada capítulo apresenta uma breve visão geral de publicações que podem ajudar a expandir o seu entendimento dos principais tópicos apresentados no capítulo. Há um site bem abrangente para dar suporte ao livro Engenharia de Software: uma abordagem prática no endereço www.mhhe.com/ pressman. Entre os diversos tópicos contemplados no site estão recursos de engenharia de software capítulo a capítulo e

50 capítulo 1 software e eNGeNHarIa De software

Pressman e Herron (Software Shock, Dorset House, 1991) apresentaram uma discussão preli- minar (dirigida ao grande público) sobre software e a maneira pela qual os profissionais o de- senvolvem. O best-seller de Negroponte (Being Digital, Alfred A. Knopf, Inc., 1995) dá uma visão geral da computação e seu impacto global no século XXI. DeMarco (Why Does Software Cost So Much? Dorset House, 1995) produziu um conjunto de divertidos e perspicazes ensaios sobre software e o processo pelo qual ele é desenvolvido.

Minasi (The Software Conspiracy: Why Software Companies Put out Faulty Products, How They Can Hurt You, and What You Can Do, McGraw-Hill, 2000) argumenta que o “flagelo mo- derno” dos bugs de software pode ser eliminado e sugere maneiras para concretizar isso. Compaine (Digital Divide: Facing a Crisis or Creating a Mith, MIT Press, 2001) defende que a “separação” entre aqueles que têm acesso a fontes de informação (por exemplo, a Web) e aqueles que não o têm está diminuindo, à medida que avançamos na primeira década deste século. Livros de Greenfield (Everyware: The Dawning Age of Ubiquitous Computing, New Riders Publishing, 2006) e Loke (Context-Aware Pervasive Systems: Architectures for a New Breed of Applications, Auerbach, 2006) introduzem o conceito de software “aberto” e preve- em um ambiente sem fio no qual o software deve se adaptar às exigências que surgem em tempo real.

O estado atual da engenharia de software e do processo de software pode ser mais bem determinado a partir de publicações como IEEE Software, IEEE Computer, CrossTalk e IEEE Transactions on Software Engineering. Periódicos do setor como Application Development Trends e Cutter IT Journal normalmente contêm artigos sobre tópicos da engenharia de soft- ware. A disciplina é “sintetizada” todos os anos no Proceeding of the International Conference on Software Engineering, patrocinado pelo IEEE e ACM e é discutida de forma aprofundada em periódicos como ACM Transactions on Software Engineering and Methodology, ACM Soft- ware Engineering Notes e Annals of Software Engineering. Dezenas de milhares de sites são dedicados à engenharia de software e ao processo de software.

Foram publicados vários livros sobre o processo de desenvolvimento de software e sobre a engenharia de software nos últimos anos. Alguns fornecem uma visão geral de todo o pro- cesso, ao passo que outros se aprofundam em tópicos específicos importantes em detrimen- to dos demais. Entre as ofertas mais populares (além deste livro, é claro!), temos:

Abran, A. e J. Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, IEEE, 2002. Andersson, E. et al., Software Engineering for Internet Applications, The MIT Press, 2006.

Christensen, M. e R. Thayer, A Project Manager’s Guide to Software Engineering Best Practices, IEEE- CS Press (Wiley), 2002.

Glass, R., Fact and Fallacies of Software Engineering, Addison-Wesley, 2002.

Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach, 2.ª ed., Addison- Wesley, 2008.

Jalote, P., An Integrated Approach to Software Engineering, Springer, 2006.

Pfleeger, S., Software Engineering: Theory and Practice, 3.ª ed., Prentice-Hall, 2005. Schach, S., Object-Oriented and Classical Software Engineering, 7.ª ed., McGraw-Hill, 2006. Sommerville, I., Software Engineering, 8.ª ed., Addison-Wesley, 2006.

Tsui, F. e O. Karam, Essentials of Software Engineering, Jones & Bartlett Publishers, 2006.

Foram publicados diversos padrões de engenharia de software pelo IEEE, pela ISO e suas organizações de padronização ao longo das últimas décadas. Moore (The Road Map to Soft- ware Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006) dis- ponibiliza uma pesquisa útil de padrões relevantes e como aplicá-los a projetos reais.

Uma ampla gama de fontes de informação sobre engenharia de software e processo de software se encontra à disposição na Internet. Uma lista atualizada de referências relevan- tes para o processo para o software pode ser encontrada no site www.mhhe.com/engcs/ compsci/pressman/professional/olc/ser.htm.

pa R t E

um

PrOceSSOS

de SOftwAre

N

esta seção você aprenderá sobre o processo que fornece uma metodologia para a prática da engenharia de software. As questões abaixo são tratadas nos capítulos seguintes:

O que é um processo de software?

Quais são as atividades metodológicas genéricas presentes em todos os processos

de software?

Como os processos são modelados e o que são padrões de processo?

O que são modelos de processo prescritivo e quais são seus pontos fortes e fra-

cos?

Por que agilidade é um lema no trabalho da engenharia de software moderna?

O que é desenvolvimento de software ágil e como ele difere dos modelos de proces-

sos mais tradicionais?

Respondidas tais questões, você estará mais bem preparado para compreender o con- texto no qual a prática da engenharia de software é aplicada.

52

c a p í t u l o2

O que é? Quando se trabalha na

elaboração de um produto ou sistema, é importante seguir uma série de passos previsíveis — um roteiro que ajude a criar um resultado de alta qualidade e dentro do prazo estabelecido. O roteiro é denominado “pro- cesso de software”.

Quem realiza? Os engenheiros de software e seus

gerentes adaptam o processo às suas necessida- des e então o seguem. Os solicitantes do software têm um papel a desempenhar no processo de definição, construção e teste do software.

Por que ele é importante? Porque propicia

estabilidade, controle e organização para uma ati- vidade que pode, sem controle, tornar-se bastante caótica. Entretanto, uma abordagem de engenha- ria de software moderna deve ser “ágil”. Deve demandar apenas atividades, controles e produtos de trabalho que sejam apropriados para a equipe do projeto e para o produto a ser produzido.

Quais são as etapas envolvidas? O processo

adotado depende do software a ser desenvolvido. Um determinado processo pode ser apropriado para um software do sistema “aviônico” de uma aeronave, enquanto um processo totalmente dife- rente pode ser indicado para a criação de um site.

Qual é o artefato? Do ponto de vista de um enge-

nheiro de software, os produtos de trabalho são os programas, os documentos e os dados produzidos em consequência das atividades e tarefas defini- das pelo processo.

Como garantir que o trabalho foi feito corre- tamente? Há muitos mecanismos de avaliação

dos processos de software que possibilitam às organizações determinarem o nível de “maturi- dade” de seu processo de software. Entretanto, a qualidade, o cumprimento de prazos e a viabilida- de a longo prazo do produto que se desenvolve são os melhores indicadores da eficácia do pro- cesso utilizado.

Panorama

Co n C e i t o s- - Ch a v e conjunto de tarefas . .55 desenvolvimento baseado em componentes . . . .69 modelo de métodos formais . . . .69 modelo de processo genérico . . . .53 modelos concorrentes . . . .67 modelos de processo evolucionário . . . . .62 modelos de processo incremental . . . .61 modelos de processo prescritivo . . . .58 padrões de processo . . . .55 processo de software em equipe . . . .75 processo de software pessoal . . . .74 processo unificado . . 71

E

m um livro fascinante, que nos dá a visão de um economista acerca do software e da engenharia de software, Howard Baetjer, Jr. [Bae98], comenta o processo de software:

Pelo fato de software, como todo capital, ser conhecimento incorporado, e pelo fato de esse co- nhecimento ser, inicialmente, disperso, tácito, latente e em considerável medida, incompleto, o desenvolvimento de software é um processo de aprendizado social. Esse processo é um diálogo no qual o conhecimento, que deverá tornar-se o software, é coletado, reunido e incorporado ao software. Tal processo possibilita a interação entre usuários e projetistas, entre usuários e ferra- mentas em evolução e entre projetistas e ferramentas em evolução (tecnologia). Trata-se de um processo iterativo no qual a própria ferramenta em evolução serve como meio de comunicação, com cada nova rodada do diálogo extraindo mais conhecimento útil das pessoas envolvidas. De fato, construir software é um processo de aprendizado social iterativo e o resultado, algo que Baetjer denominaria “capital de software”, é a incorporação do conhecimento coletado, filtrado e organizado conforme se desenvolve o processo.

Mas o que é exatamente um processo de software do ponto de vista técnico? No contex- to desse livro, processo de software é definido como uma metodologia para as atividades, ações e tarefas necessárias para desenvolver um software de alta qualidade. “Processo” é sinônimo de engenharia de software? A resposta é “sim e não”. Um processo de software define a abordagem adotada conforme um software é elaborado pela engenharia. Mas a engenharia de software também engloba tecnologias que fazem parte do processo — mé- todos técnicos e ferramentas automatizadas.

Mais importante, a engenharia de software é realizada por pessoas criativas e com am- plos conhecimentos e que devem adaptar um processo de software maduro, de forma que fique apropriado aos produtos desenvolvidos e às demandas de seu mercado.

Outline

Documentos relacionados