FUNDAMENTOS DE ENGENHARIA DE SOFTWARE

Prévia do material em texto

FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Natureza do Software
 
Hoje, o software tem um duplo papel. Ele é um produto e, ao mesmo tempo, o veículo para distribuir um produto. Como produto, fornece o potencial computacional representado pelo hardware ou, de forma mais abrangente, por uma red e de comp utadores que podem ser acessados por hardware local.
Como veículo de distribuição do produto, o software atua como a base para o controle do computador (sistemas operacionais), a comu nicação de informações (redes) e a criação e o controle de outros programas (ferramentas de software e ambientes). O software distribui o produto mais importante de nossa era – a informação.
Ele transforma dados pessoais (por ex emplo, transações financeiras de um indivíduo) de modo que possam ser mais úteis em determinado contexto; gerencia informações comerciais para aumentar a compet itividade; fornece um portal para redes mundiais d e informação (Internet) e os meios para obter informações sob todas as suas formas. Atualmente, uma enorme indústria de software tornou-se fator dominante nas economias do mundo industrializado.
A natureza mutante do Software
A natureza do software é mutante. As aplicações e os sistemas baseados na Internet passaram de simples conjuntos de conteúdo informativo para sofisticados sistemas que apresentam funcionalidade complexa e conteúdo multimídia. Embora essas WebApps possuam características e requisitos exclusivos, elas não deixam de ser um tipo de software.
Processos de Desenvolvimento
Qualquer projeto é formado por processos e estes são constituídos de atividades que, 
fazendo uso de ferramentas, técnicas e artefatos, são executados de forma organizada 
e/ou sincronizada. Um projeto é caracterizado por um tempo de vida finito e pela 
produção de um produto ou serviço. Existem produtos que são facilmente visualizados 
antes mesmo de sua construção, pois são quantificáveis, de escopo exato e incertezas 
mínimas como, por exemplo, construções prediais. Essa definição não representa o 
desenvolvimento de um software. É exatamente o contrário, pois este tipo de produto é 
intangível, de escopo com altas taxas de variações e incertezas constantes. Assim, um 
software por surgir de ideias conceituais, reajustáveis e não possuir recursos físicos, seu 
escopo pode variar, provocando mudanças sérias durante sua construção e dificultando 
sua visualização final. Esse fato de poder existir um grande número de possíveis estados 
torna o software um produto extremamente complexo, dificultando a elaboração de seu 
projeto de forma a atender todos os requisitos de qualidade e de controle total sobre os 
possíveis erros. Mas como obter um produto de software com qualidade diante de todas 
estas peculiaridades? 
Percebeu-se a necessidade de inclusão da disciplina de engenharia no 
desenvolvimento de software, pois com ela é possível que um gerente fortaleça práticas 
de gerenciamento para obtenção de um produto com alta qualidade. A Engenharia de 
Software aborda as formas de desenvolvimento e engloba três elementos fundamentais: 
métodos, ferramentas e procedimentos. Os métodos estão relacionados a um conjunto 
de tarefas que incluem planejamento, estimativas, projeto, codificação, testes e 
manutenção de sistemas. As ferramentas oferecem apoio aos envolvidos nos projeto e 
os procedimentos constituem a ligação entre os outros dois. Com isso, esses conjuntos 
de etapas são compreendidos como paradigmas da engenharia de software [Pressman 
2005]. 
Um processo geral é um conjunto de passos parcialmente ordenados, 
constituídos por atividades, métodos, práticas e transformações com o objetivo de 
atingir alguma meta, detalhando: produto, etapas, agentes, insumos e resultados. Em 
processos que envolvem desenvolvimento de software podem ser definidas as seguintes 
atividades: desenvolvimento, manutenção, aquisição e contratação de software, além 
de também poderem existir subprocessos para cada um destes. Por exemplo, um 
processo de desenvolvimento abrange determinação dos requisitos, análise, desenho, 
implementação e testes [Paula Filho 2006]. 
Dessa forma, os processos para construção de um software são como conjunto 
de passos que irão trabalhar de forma ampla definições, desenvolvimento e manutenção. 
Existem diversos destes conjuntos que formam diferentes estratégias de abordagem e 
são denominados também de Modelos de Ciclo de Vida de Software [Pressman 2005]. 
Com isso abordaremos neste contexto os ciclos de vida de Waterfall, Espiral e Ágil. 
O modelo de Waterfall também conhecido como ciclo de vida clássico ou, ainda, 
modelo cascata, prega uma filosofia de sequência onde uma fase deve ser completa 
antes do início da próxima removendo assim muitos erros o mais cedo possível. 
É esperado nesta abordagem uma extensa documentação em cada fase para que 
informações importantes não sejam perdidas, caso um membro do projeto desmembre 
a equipe. Assim como também se uma nova pessoa for adicionada ao time, então esta 
poderá rapidamente participar de forma efetiva.
 
Visão geral do modelo Waterfall [Pressman 2005].
O fluxo ilustrado pela figura 1 mostra as fases sequenciais previstas pelo modelo 
Waterfall. A longevidade do software é reconhecida pela fase de manutenção que repara 
os erros na medida em que são descobertos. Futuras versões do software são feitas 
usando as mesmas fases e consomem normalmente um prazo entre seis e dezoito meses. 
Este modelo pode funcionar bem quando usado com tarefas bem definidas como, por 
exemplo, voos espaciais da NASA, mas se torna problemático quando os clientes não 
possuem uma definição clara do que eles precisam [Fox e Patterson 2012]. 
Observou-se que esse problema é minimizado quando os clientes conseguem 
entender o que eles querem por meio da visualização de um protótipo e, ao mesmo 
tempo, os engenheiros entendem melhor como construir, uma vez que eles fizeram 
isso com a primeira interação com o cliente. Essa observação combinou protótipos de 
software com o modelo Waterfall e a ideia foi repetir uma sequência de quatro fases, 
onde cada uma resultaria em um protótipo mais aprimorado em relação à versão anterior 
[Boehm 1986 apud Fox e Patterson 2012]. Este modelo de ciclo de vida ganhou a 
denominação de Modelo Espiral. 
O Modelo Espiral é composto por quatro fases. A figura 2 ilustra como este 
ciclo de vida combina os modelos Waterfall e Prototipação. O processo se inicia no 
centro, com cada iteração ao redor da espiral executando as quatro fases e gerando 
como resultado um protótipo revisado. Isso se repete até que o produto esteja pronto 
para ser liberado ou lançado. 
Modelo Espiral [Fox e Patterson 2012].
Este modelo ao invés de produzir um documento com toda a documentação do 
projeto, constrói os documentos de requisitos, fundamentais para a evolução do projeto, 
por meio de cada iteração conforme as necessidades. Vale ressaltar que uma iteração 
envolve o cliente antes do produto ser finalizado, e isso reduz consideravelmente 
as chances de erros na concepção do sistema. Como as iterações demoram 
presumidamente entre seis e vinte e quatro meses, o cliente tem tempo hábil para pensar 
em novas ideias e isso seria um problema sério, pois os planejamentos deveriam ser 
revisados para transformar as novas sugestões em recursos do sistema.
Ambos os modelos foram elencados porque envolvem um longo período de 
tempo e um volume muito grande de documentação e planejamento, bem como, fases 
maiores ainda emergindo o termo Big Design Up Front (BDUF). O desenvolvimento 
de software coma abordagem BDUF reflete que o planejamento é completado e 
aperfeiçoado antes mesmo de iniciar a codificação, o que praticamente inviabiliza uma 
mudança brusca de escopo [Fox e Patterson 2012]. 
Um grupo de desenvolvedores de software em fevereiro de 2001, chamado de 
Agile Alliance, começou a descobrir maneiras melhores e mais leves de desenvolver 
software, valorizando principalmente, pessoas e interações ao invés de processos 
e ferramentas, softwares funcionando no lugar de documentações abrangentes, 
colaborações com clientes do que negociações de contratos e respostas à mudanças por 
planos fechados. Esses valores deram origem ao Manifesto Ágil e possui ainda doze 
princípios que regem a filosofia de criar softwares com agilidade [Beck 2001]. 
Este modelo alternativo de desenvolvimento é baseado em mudanças 
abrangentes, como por exemplo um fato da vida. O desenvolvedor deve melhorar 
continuamente um protótipo incompleto, até que o cliente fique feliz com o resultado 
e, como o cliente oferecerá feedback a cada iteração, então a possibilidade de mal 
entendidos é consideravelmente reduzida. O modelo enfatiza algumas práticas para 
reduzir erros e aumentar a produtividade, tais como: Test-Driven Development (TDD), 
User Stories e Velocity. Contrastando com os outros dois modelo citados, o ciclo de 
vida Ágil é tão rápido que novas versões são disponibilizadas ao cliente a cada duas 
semanas e novos recursos são adicionados continuamente ao mesmo protótipo até que o 
cliente esteja satisfeito [Fox e Patterson 2012].