• Nenhum resultado encontrado

O conjunto de ferramentas proposto na Seção 3.6 oferece suporte a muitos dos aspec-

FERRAMENTAS DO SOFTWARE

capítulo 2 MODELOS DE PrOCESSO 79 a si mesmos sobre o produto de software a ser construído e sobre o processo que será usado

12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento de acordo.

3.18. O conjunto de ferramentas proposto na Seção 3.6 oferece suporte a muitos dos aspec-

tos “menos prioritários” dos métodos ágeis. Como a comunicação é tão importante, reco- mende um conjunto de ferramentas real que poderia ser usado para melhorar a comunicação entre os interessados de uma equipe ágil.

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 s

A filosofia geral e os princípios subjacentes do desenvolvimento de software ágil são con- siderados em profundidade em muitos dos livros citados neste capítulo. Além destes, livros como os de Shaw e Warden (The Art of Agile Development, O’Reilly Media, Inc., 2008), Hunt (Agile Software Building, Springer, 2005) e Carmichael e Haywood (Better Software Faster, Prentice-Hall, 2002) trazem discussões interessantes sobre o tema. Aguanno (Managing Agile Projects, Multi-Media Publications, 2005), Highsmith (Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004) e Larman (Agile and Iterative Development: A Manager’s Guide, Addison-Wesley, 2003) apresentam uma visão geral sobre gerenciamento e consideram as questões envolvidas no gerenciamento de projetos. Highsmith (Agile Soft- ware Development Ecosystems, Addison-Wesley, 2002) retrata uma pesquisa de princípios, processos e práticas ágeis. Uma discussão que vale a pena sobre o delicado equilíbrio entre agilidade e disciplina é fornecida por Booch e seus colegas (Balancing Agility and Discipline, Addison-Wesley, 2004).

Martin (Clean Code: A Handbook of Agile Software Craftsmanship, Prentice-Hall, 2009) enumera os princípios, padrões e práticas necessários para desenvolver “código limpo” em um ambiente de engenharia de software ágil. Leffingwell (Scaling Software Agility: Best Prac- tices for Large Enterprises, Addison-Wesley, 2007) discute estratégias para dar maior corpo às práticas ágeis para poderem ser usadas em grandes projetos. Lippert e Rook (Refactoring in Large Software Projects: Performing Complex Restructurings Successfully,Wiley, 2006) discu- tem o uso da refabricação quando aplicada a sistemas grandes e complexos.

104 paRtE 1 o ProCesso De software

104 paRtE 1 o ProCesso De software capítulo 3 DeseNVoLVIMeNto ÁGIL 105

Stamelos e Sfetsos (Agile Software Development Quality Assurance, IGI Global, 2007) tra- zem técnicas SQA que estão em conformidade com a filosofia ágil.

Foram escritos dezenas de livros sobre Extreme Programming ao longo da última déca- da. Beck (Extreme Programming Explained: Embrace Change, 2. ed., Addison-Wesley, 2004) ainda é o tratado de maior autoridade sobre o tema. Além desse, Jeffries e seus colegas (Extreme Programming Installed, Addison-Wesley, 2000), Succi e Marchesi (Extreme Program- ming Examined, Addison-Wesley, 2001), Newkirk e Martin (Extreme Programming in Prac- tice, Addison-Wesley, 2001), bem como Auer e seus colegas (Extreme Programming Applied: Play to Win, Addison-Wesley, 2001), fornecem uma discussão básica da XP juntamente com uma orientação sobre como melhor aplicá-la. McBreen (Questioning Extreme Programming, Addison-Wesley, 2003) adota uma visão crítica em relação à XP, definindo quando e onde ela é apropriada. Uma análise aprofundada da programação em dupla é apresentada por McBreen (Pair Programming Illuminated, Addison-Wesley, 2003).

A ASD é tratada em profundidade por Highsmith [Hig00]. Schwaber (The Enterprise and Scrum, Microsoft Press, 2007) discute o uso do Scrum para projetos que possuem um grande impacto sobre as empresas. Os detalhes práticos do Scrum são debatidos por Schwaber e Beedle (Agile Software Development with SCRUM, Prentice-Hall, 2001). Tratados úteis sobre o DSDM foram escritos pelo DSDM Consortium (DSDM: Business Focused Development, 2. ed., Pearson Education, 2003) e Stapleton (DSDM: The Method in Practice, Addison-Wesley, 1997). Cockburn (Crystal Clear, Addison-Wesley, 2005) traz uma excelente visão geral da família Crystal de processos. Palmer e Felsing [Pal02] apresentam um tratado detalhado acerca do FDD. Carmichael e Haywood (Better Software Faster, Prentice-Hall, 2002) é mais um tratado útil sobre o FDD que inclui uma jornada passo a passo através da mecânica do processo. Poppendieck e Poppendieck (Lean Development: An Agile Toolkit for Software Development Managers, Addison-Wesley, 2003) dão diretrizes para gerenciar e controlar projetos ágeis. Ambler e Jeffries (Agile Modeling, Wiley, 2002) discutem a AM com certa profundidade.

Uma grande variedade de fontes de informação sobre desenvolvimento de software ágil está disponível na Internet. Uma lista atualizada de referências na Web relevantes ao proces- so ágil pode ser encontrada no site www.mhhe.com/engcs/compsci/pressman/professional/ olc/ser.htm.

pa R t E

doiS

mOdelAgem

N

esta parte do livro Engenharia de software: uma abordagem profissional, você aprenderá os princípios, conceitos e métodos usados para criar modelos de ne- cessidades e de projeto de alta qualidade.

As seguintes questões são tratadas nos próximos capítulos:

Quais conceitos e princípios orientam a prática da engenharia de software?

O que é engenharia de necessidades e quais os conceitos subjacentes que levam a

uma análise de necessidades adequada?

Como é criado o modelo de necessidades e quais seus elementos?

Quais os elementos de um bom projeto?

Como o desenho da arquitetura estabelece uma estrutura para todas as demais

ações de projeto e quais os modelos utilizados?

Como projetar componentes de software de alta qualidade?

Que conceitos, modelos e métodos são aplicados quando é projetada uma interface

para o usuário?

O que é projeto baseado em padrões?

Que estratégias e métodos especializados são usados para projetar WebApps?

Assim que essas perguntas forem respondidas, você estará mais bem preparado para a prática da engenharia de software.

108

c a p í t u l o

c a p í t u l o

4

Co n C e i t o s- - Ch a v e princípios fundamentais . . . .109 princípios que governam a codificação . . . .120 a comunicação . . .112 a disponibilização 122 a modelagem . . .116 o planejamento . .114 o projeto . . . .118 os requisitos . . . .117 os testes . . . .121

PrincíPiOS Que

OrientAm

A PráticA

O que é? A prática da engenharia de software consiste em uma série de prin- cípios, conceitos, métodos e ferramentas que devem ser considerados ao planejar e desenvolver um software. Princípios que direcio- nem a ação estabelecem a infraestrutura a partir da qual a engenharia de software é conduzida.

Quem realiza? Praticantes (engenheiros de software) e seus coordenadores (gerentes) desenvolvem uma variedade de tarefas de engenharia de software.

Por que é importante? O processo de software

propicia a todos os envolvidos na criação de um sistema computacional ou produto para com- putador um roteiro para conseguir chegar a um destino com sucesso. A prática fornece o deta- lhamento necessário para seguir ao longo da estrada. Aponta para onde estão as pontes, os conjuntos de rodovias, as bifurcações. Auxilia a compreender os conceitos e princípios que devem ser compreendidos e seguidos para que se dirija com rapidez e segurança. Orienta quanto ao como seguir, onde diminuir e aumentar o ritmo. No contexto da engenharia de software, a prática

consiste no que se realiza diariamente, à medida que o software evolui de ideia a realidade.

Quais são as etapas envolvidas? Aplicam-se três elementos práticos, independentemente do mode- lo de processo escolhido. São eles: princípios, conceitos e métodos. Um quarto elemento de prática, ferramentas, sustenta a aplicação dos métodos.

Qual é o artefato? A prática engloba as atividades técnicas que produzem todos os artefatos definidos pelo modelo de processo de software escolhido.

Como garantir que o trabalho foi realizado corre- tamente? Primeiro, compreenda completamente os princípios aplicados ao trabalho (por exemplo, projeto) que está sendo realizado no momento. Em seguida, esteja certo de que escolheu um método apropriado, certifique-se de ter compreendido como aplicar o método, use ferramentas automati- zadas, quando estas forem apropriadas à tarefa, e seja inflexível quanto à necessidade de técnicas para se assegurar da qualidade dos produtos de trabalho produzidos.

Panorama

E

m um livro que pesquisa o cotidiano e reflexões dos engenheiros de software, Ellen Ullman [Ull 97] descreve um pouco da experiência de vida, à medida que relata os pensamentos do profissional atuante sob pressão:

Não tenho ideia de que horas são. Não há janelas neste escritório, nem relógio, somente o LED vermelho de um micro-ondas piscando 12:00, 12:00, 12:00, 12:00. Joel e eu estamos programando há dias. Temos um defeito, um demônio teimoso... Da mesma forma, o pisca vemelho não se acer- ta em temporização, como se fosse uma representação de nossos cérebros, que, de alguma forma, acabaram sincronizados com a mesma faísca temporal do LED...

Em que estamos trabalhando?... Os detalhes me escapam agora. Podemos estar auxiliando os po- bres ou sintonizando uma série de rotinas de baixo nível, a fim de verificar os bits de um protocolo de distribuição de dados. Nem me importo. Deveria me importar; em uma outra época — talvez, quando sairmos desta sala cheia de computadores —, me importarei muitíssimo com o porquê, para quem e para qual finalidade estou desenvolvendo software. Mas neste exato momento: não. Ultrapassei uma camada na qual o mundo real e seus usuários não mais importam. Sou um en- genheiro de software...

Muitos leitores estarão capacitados para lidar com esse lado sombrio da engenharia de software, com ponderação.

109 paRtE 2 MoDeLaGeM capítulo 4 PrINCÍPIos qUe orIeNtaM a PrÁtICa 109 As pessoas que criam software praticam a arte ou ofício ou disciplina1 em que consiste a engenharia de software. Mas em que consiste a “prática” de engenharia de software? De forma genérica, prática é um conjunto de conceitos, princípios, métodos e ferramentas aos quais um engenheiro de software recorre diariamente. A prática permite aos coordenadores (gerentes) administrar os projetos e aos engenheiros de software criar programas computa- cionais. A prática preenche um modelo de processo de software com recursos de como fazer para ter o trabalho realizado em termos de gerenciamento e de tecnologia. Transforma uma abordagem desfocada e confusa em algo mais organizado, mais efetivo e mais propenso a obter sucesso.

Diversos aspectos da engenharia de software serão examinados ao longo do livro.

Neste capítulo, o foco será em princípios e conceitos que norteiam a prática da engenharia de sofwtare em geral.

C

o n h e C i m e n t o da

e

n g e n h a r i a d e

s

o f t wa r e

Em um editorial publicado na IEEE Software uma década atrás, Steve McConnell [McC99] fez o seguinte comentário:

Muitos desenvolvedores (de software) veem o conhecimento da engenharia de software quase que exclusivamente como um conhecimento de tecnologias específicas: Java, Perl, html, C++, Linux, Win- dows NT etc. O conhecimento de detalhes específicos de tecnologia é necessário para desenvolver a programação de computador. Se alguém o contrata para desenvolver um programa em C++, você de- verá saber algo sobre C++ para fazer seu programa funcionar.

Frequentemente, diz-se que conhecimento sobre desenvolvimento de software tem uns três anos de vida: metade do que se precisa saber hoje estará obsoleto daqui a três anos. No que diz respeito ao conhecimento de tecnologia, essa afirmação está próxima da verdade. Mas há um outro tipo de conhe- cimento sobre desenvolvimento de software — um tipo visto como “princípios da engenharia de soft- ware” — que não possui três anos de meia-vida. Tais princípios provavelmente servirão ao programador profissional durante toda a sua carreira.

McConnell continua afirmando que a base do conhecimento em engenharia de software (por volta do ano 2000) evoluiu para uma “essência estável” que ele estimou representar cerca de “75% do conhecimento necessário para desenvolver um sistema complexo”. No entanto, no que consiste essa essência estável?

Como indica McConnell, princípios essenciais — ideias elementares que guiam engenhei- ros de software em seus trabalhos — fornecem, em nossos dias, uma infraestrutura a partir da qual os modelos de engenharia de software, métodos e ferramentas podem ser aplicados e avaliados.

P

r i n C í P i o s

f

u n da m e n ta i s

A engenharia de software é norteada por um conjunto de princípios fundamentais que au- xiliam na aplicação de um processo de software significativo e na execução de métodos de engenharia de software efetivos. No nível relativo a processo, os princípios fundamentais esta- belecem uma infraestrutura filosófica que guia uma equipe de software à medida que desenvol- ve atividades de apoio e estruturais, navega no fluxo do processo e cria um conjunto de artefatos de engenharia de software. Quanto à prática, os princípios fundamentais estabelecem um arte- fatos e regras que servem como guias conforme se analisa um problema, projeta uma solução, implementa e testa uma solução e, por fim, emprega o software na comunidade de usuários.

No Capítulo 1, identificou-se uma série de princípios fundamentais que abrange o processo e a prática da engenharia de software: (1) fornecer valor aos usuários finais, (2) simplificar, (3) 1 Certos autores argumentam que um desses termos exclui outros. Na realidade, a engenharia de software se aplica a todos

os três.

4.1

4.2

“Teoricamente, não há nenhuma diferença entre a teoria e a prática. Porém, na prática, ela existe.” Jan van de Snepscheut

110 paRtE 2 MoDeLaGeM 110 paRtE 2 MoDeLaGeM

manter a visão (do produto e do projeto), (4) reconhecer que outros usuários consomem (e de- vem entender) o que se produz, (5) manter abertura para o futuro, (6) planejar antecipadamente para o reúso, e (7) raciocinar!

Embora tais princípios gerais sejam importantes, são caracterizados em um nível tão eleva- do de abstração que, às vezes, torna-se difícil a tradução para a prática diária da engenharia de software. Nas subseções seguintes, há um maior detalhamento dos princípios essenciais que conduzem o processo e a prática.

4.2.1 princípios que orientam o processo

Na Parte 1 deste livro, discutiu-se a importância do processo de software e descreveram- -se os diferentes modelos de processos propostos para o trabalho de engenharia de software. Não importando se um modelo é linear ou iterativo, prescritivo ou ágil, pode ser caracterizado usando-se uma metodologia de processo genérica aplicável a todos os modelos de processo. O conjunto de princípios fundamentais apresentados a seguir pode ser aplicado à metodologia e, por extensão, a todos os processos de software.

Outline

Documentos relacionados