ENGENHARIA DE SOFTWARE

Aula 02

Prof. Cleuber Moreira FernandesMestre em Ciência da Computação - UnB

Cleubermf@yahoo.com.brhttp://br.groups.yahoo.com/group/ES-2008

1. Engenharia de Software

1.1 Definição

Segundo Frits Bauer:

“É a criação e utilização de sólidos princípios de engenharia a fim de obter software de maneiraeconômica, que seja confiável e que trabalhe eficientemente em máquinas reais.”

• Não considera diretamente aspectos como:

a) Qualidade – satisfação do cliente e pontualidade;

b) Importância de métricas e de processo amadurecido.

• Linha básica:

a) Quais são os sólidos princípios?

b) Equilíbrio economicidade e confiabilidade;

c) Softwares eficientes em diferentes máquinas reais.

1.2 Processos, métodos e ferramentas

Engenharia está sempre apoiada na gestão de qualidade total que leva a uma cultura deprocesso contínuo de melhoria.

O fundamento da engenharia de software é a camada de PROCESSO, que define uma estruturapara um conjunto de áreas de processo – PA (Gestão Configuração, Gestão Requisitos, ...). Osprocessos estabelecem quando, onde e como os métodos são aplicados para produzir os produtos detrabalho (documentos, dados, relatórios), definem os marcos do projeto e gerenciam a qualidade.

Os métodos fornecem as técnicas para construir software, com tarefas que abrangem análise derequisitos, projeto, implementação, teste e implantação.

Ferramentas consistem no apoio automatizado ou semi-automatizado para o processo e para osmétodos. A engenharia de software apoiada por computador – CASE combina software, hardware ebase de dados (informações sobre análise, projeto, teste, ...) para criar um ambiente de engenharia.

Figura 01 – Camadas da Engenharia de Software

Foco na qualidade

Processos

Métodos

Ferramentas

1.3 Abstração de Engenharia de Software

Engenharia é a análise, projeto, construção verificação e gestão de elementos técnicos ousociais.

Independente do produto ou solução, as seguintes perguntas precisam ser respondidas:

a) Qual é o problema a ser resolvido?

b) Que características do produto/solução são usadas para resolver o problema?

c) Como os produtos serão construídos?

d) Que abordagem será usada para descobrir erros cometidos no projeto e construção doproduto?

e) Como o produto será mantido a longo prazo, quando da necessidade de correções,adaptações e aperfeiçoamentos?

O trabalho associado à engenharia de software pode ser realizado em três fases genéricas, cadaqual responde a uma ou mais das perguntas acima. Abaixo é apresentada uma combinação dasclassificações dadas por Schwartz, Pressman e Sommerville:

1. Especificação ou Definição ���� O quê

Visa identificar: informação, função, desempenho, restrições de projeto e critérios de aceitação.

• Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendoquestões extra-software;

• Análise de Requisitos: levantamento das necessidades do software a ser implementado. AAnálise tem como objetivo produzir uma especificação de requisitos, que convencionalmente éum documento;

• Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes paraverificar adequação.

2. Desenvolvimento ���� Como

Como os dados devem ser estruturados, como a função deve ser implementada dentro daarquitetura de software projetada para se alcançar o desempenho desejado, como as interfaces devemser caracterizadas, como o projeto deve ser traduzido numa linguagem de programação e como o testevai ser realizado.

2.1 Projeto

• Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto demódulos mais ou menos independentes;

• Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida

• Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos parapseudo-código.

2.2 Implementação

• Codificação: a implementação em si do sistema em uma linguagem de computador.

2.3 Validação

• Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros ecomportamento adequado a nível das funções e módulos básicos do sistema;

• Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e averificação da interação entre estes quando operando em conjunto.

3. Manutenção

Foco nas modificações associadas com a correção de erros e adaptações à medida que oambiente do software evolui e os requisitos dos clientes se modificam. Esta fase aplica novamente osconceitos das fases de Definição e Desenvolvimento, mas no contexto de software existente. Quatrotipos de modificações são realizadas:

1. Correção � manuteção corretiva – eliminação defeitos;

2. Adaptação � mudanças no ambiente computacional, regras de negócio;

3. Aperfeiçoamento � funções adicionais que aprimoram o software;

4. Prevenção � evita a ocorrência de novos defeitos.

As fases e passos na visão geral de engenharia de software são complementados por algumasatividades guarda-chuva, tais como:

• Acompanhamento e controle do projeto;

• Revisões técnicas formais;

• Garantia de qualidade;

• Gestão de Configuração;

• Medição;

• Gestão de Risco.

1.4 O Processo de Software

É uma estrutura comum de processo que define um pequeno número de atividades dessaestrutura, que são aplicáveis a todos os projetos de software, independentemente do tamanho ecomplexidade. Um conjunto de tarefas de engenharia, marcos de projeto, produtos do trabalho epontos de garantia da qualidade que permitem adaptar as atividades da estrutura às características doprojeto específico e às necessidades da equipe de projeto. Por fim, atividades guarda-chuva – garantiada qualidade, gestão de configuração e medição – cobrem o modelo de processo. Essas atividades

guarda-chuva são independentes de qualquer atividade de estrutura e ocorrem ao longo de todo oprocesso.

Figura 02 – Estrutura comum de Processo

Há algum tempo tem havido ênfase significativa na “maturidade do processo”. O SoftwareEngineering Institute – SEI desenvolveu um modelo abrangente, baseado num conjunto decapacidades de engenharia de software que devem estar presentes à medida que as empresas alcançamdiferentes níveis de maturidade de processo, o Capability Maturity Model, atualmente reestruturado edesignado Capability Maturity Model Integration – CMMI.

1.5 Capability Maturity Modelo Integration

- Um conjunto de disciplinas integradas:

Software Engineering

Systems Engineering

Integrated Product and Process Development

Suplier Sourcing

People CMM

- Formas de representação

Contínua � Capacidade de cada área de processo

Por Estágios � Maturidade da organização

Estrutura comum de Processo

Atividades guarda-chuva

Atividades de estrutura

Conjuntos de tarefas

Tarefas

Marcos, produtos finais ou intermediários

Pontos de garantia de qualidade

- Áreas de Processo - PA’s

Conjunto de práticas relacionadas, que quando executadas conjuntamente, satisfazem umconjunto de metas consideradas importantes para promover melhoria naquela área. As PA’s são asmesmas nas duas representações.

Ex.: Planejamento de projeto, Gerenciamento de riscos, Gerenciamento de requisitos.

- Principais itens das PA’s

1. Metas Específicas: CARACTERÍSTICA que precisa ser implementado para satisfazer aPA.

2. Práticas Específicas: ATIVIDADE importante para implementar a característica anterior.

3. Metas Genéricas: Descreve a INSTITUCIONALIZAÇÃO que a organização precisaalcançar para cada NÍVEL DE MATURIDADE.

4. Práticas Genéricas: Promove a institucionalização, garantindo que o processo seráEFETIVO, REPETÍVEL E DURADOURO.

- Modelo de Maturidade – Por Estágio

- Modelo de Capacidade - Contínuo

- Organização das Áreas de Processo

1.5 Paradigmas de Engenharia de Software

Um modelo de processo ou paradigma é escolhido com base na natureza da aplicação, nosmétodos e ferramentas a serem usados, e nos controles e produtos intermediários e finais requeridos.

O desenvolvimento de software pode ser caracterizado como um ciclo de solução de problema(Figura 03), no qual a “Situação Atual” representa o estado atual das coisas, a “Definição doProblema” identifica o problema a ser resolvido, o “Desenvolvimento Técnico” resolve o problemapor meio de alguma tecnologia e a “Integração da Solução” entrega os resultados (documentos,programas, dados).

Esse ciclo aplica-se ao trabalho de engenharia de software em muitos diferentes níveis deresolução: em nível macro, quando a aplicação e considerada, em nível intermediário, quando oscomponentes de programa esta sendo construídos e mesmo no nível de linha de código, como umarepresentação FRACTAL (Figura 04).

Figura 03 – Fases do Ciclo de Solução de Problema

Figura 04 – Fractal

1.6 Modelo Cascata

Conhecido como abordagem ‘top-down’, tem como principal característica a sequência deatividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para umanova fase.

Figura 05 - Descrição Visual do Modelo

SituaçãoAtual

DefiniçãoProblema

Desenvolv.Técnico

IntegraçãoSolução

SituaçãoAtual

Situação Atual

Definição Problema

Desenvolv.Técnico

Integração Solução

Situação Atual

Definição Problema

Desenvolv.Técnico

Integração Solução

Situação Atual

Definição Problema

Desenvolv.Técnico

Integração Solução

DefiniçãoRequisitos

ProjetoSistema

Implementação

TesteSistema

Manutenção

Documentação

A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem umasequência, ou seja, a saída da primeira etapa "fluí" para a segunda etapa e a saída da segunda etapa"fluí" para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadassequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Umadas vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita osprodutos finais da tarefa atual.

O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o quequer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vezque se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefasanteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas. Numa tentativa deresolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata,designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidadede a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplaralterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maiorconhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de umprocesso de gestão do projeto e de controle das alterações bem definido, podemos passar o tempo numciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema.

As desvantagens deste modelo são:

• Dificuldade em acomodar mudanças depois que o processo está sendo executado;

• Partição inflexível do projeto em estágios distintos;

• Dificuldade em responder a mudanças dos requisitos;

• É mais apropriado quando os requisitos são bem compreendidos;

• É difícil capturar os requisitos de uma só vez;

• Cliente tem de pacientemente esperar o resultado final;

• Os programadores são frequentemente atrasados sem necessidade;

• Alto custo de correção das especificações quando nas fases de Teste e Implantação.

1.7 Modelo de Prototipagem

O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitaçõesdo modelo cascata. A idéia básica deste modelo é que ao invés de manter inalterado os requisitosdurante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dosrequisitos. Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destasfases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor osrequisitos do sistema.

Figura 06 – Representação gráfica do modelo

O protótipo é desenvolvido com uma versão inicial do documento de especificação dosrequisitos. Depois do protótipo estar pronto o cliente o utiliza e, baseado na sua avaliação, sãofornecidas as impressões do que precisa ser alterado, o que está faltando e o que não é preciso. Oprotótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótiponovamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final osrequisitos iniciais são alterados para produzir a especificação final dos requisitos.

Segundo Pressman, este modelo pode trazer os seguintes benefícios:

• O modelo é interessante para alguns sistemas de grande porte nos quais representem um certograu de dificuldade para exprimir rigorosamente os requisitos;

• É possível obter uma versão do que será o sistema com um pequeno investimento inicial;

• A experiência de produzir o protótipo pode reduzir o custo das fases posteriores;

• A construção do protótipo pode demonstrar a viabilidade do sistema.

Questões a serem consideradas quanto a utilização do modelo:

• A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente noprojeto;

• Não descuidar de uma boa análise que deve ser conduzida durante todo o processo deprototipação;

• Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamenteserá o mesmo do sistema final;

• Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitosespecificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que astécnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas naimplementação de um sistema (relaxamento de regras de negócio, manipulação de exceçõesetc)

Análise deRequisitos

Projeto

Codificação

Teste

Projeto Codificação Teste

• Durante a etapa de prototipação, documentar todos os pontos levantados e implementados noprotótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final.

1.7 Modelo Espiral

Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizandouma versão de um software executável.

O modelo em espiral foi proposto como forma de integrar os diversos modelos existentes àépoca, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvidopara abranger as melhores características tanto do ciclo de vida clássico como da prototipação,acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a essesparadigmas.

Entretanto, a integração não se dá através da simples incorporação de características dosmodelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos,cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase(ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos.

Figura 07 – Modelo Espiral

O modelo espiral considera seis tarefas ou setores da espiral, como segue:

• Comunicação com o cliente: estabelecer efetiva comunicação entre desenvolvedor ecliente;

• Planejamento: definir recursos, prazos, orçamentos e outras informações de projeto;

• Análise de Risco: avaliar e tratar riscos técnicos e gerenciais;

• Engenharia: criar um ou mais modelo do software;

• Construção e liberação: construir, testar, instalar e fornecer apoio ao usuário;

• Avaliação pelo cliente: obter realimentação do cliente com base nos modelos criados noestágio de engenharia e implementados durante a construção.

O modelo espiral é atualmente a abordagem mais realística para desenvolvimento de softwareem grande escala e usa uma abordagem que capacita a empresa que presta o serviço e o cliente aentender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerávelexperiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícilconvencer os clientes que uma abordagem evolutiva é controlável.

Vantagens deste modelo

• modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cadavez mais completas, recorrendo à prototipagem para reduzir os riscos.

• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata,mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, oprocesso de desenvolvimento.

Desvantagens

• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que aabordagem evolutiva é controlável.

• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos ebaseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderãoocorrer problemas.

•

• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. Oprotótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletirsomente alguns aspectos do sistema a ser desenvolvido.

• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes doprojeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso detécnicas específicas para estimar e sincronizar cronogramas, bem como para determinar osindicadores de custo e progresso mais adequados.

1.8 Modelo iterativo e incremental

Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.

O desenvolvimento de um produto comercial de software é uma grande tarefa que pode serestendida por vários meses, possivelmente um ano ou mais. Por isso, é mais prático dividir o trabalhoem partes menores ou iterações. Cada iteração resultará num incremento.

Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.

O princípio subjacente ao processo incremental e iterativo é que a equipe envolvida possarefinar e expandir paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.

Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar aviabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de desenho eimplementação. Numa segunda geração, deve-se concluir a análise, fazer uma parte significativa dodesenho e um pouco mais de implementação. Numa terceira iteração, deve-se concluir o desenho,fazer-se parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principalconsequência da aproximação iterativa é que os produtos finais de todo o processo vão sendoamadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto deprodutos finais.

A cada iteração são realizadas as seguintes tarefas:

• Análise (refinamento de requisitos, refinamento do modelo conceitual);

• Projeto (refinamento do projeto arquitetural, projeto de baixo nível);

• Implementação (codificação e testes);

• Transição para produto (documentação, instalação, ...).

Figura 08 – Representação do Modelo Iterativo e Incremental

Vantagens do processo incremental e iterativo:

• Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidaspara os eliminar ou controlar;

Planejamento

Análise

Desenho

Desenvolv.

Testes

1ª Versão

Análise

Desenho

Desenvolv.

Testes

2ª Versão

Manutenção

• Redução dos riscos envolvendo custos a um único incremento.Se a equipa que desenvolve osoftware precisar repetir a iteração, a organização perde somente o esforço mal direcionado deuma iteração, não o valor de um produto inteiro;

• Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento;

• Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidosde alterações futuras;

• Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação epartilha de comunicação daí resultante.

1.9 Conclusão

Não existe um processo correto ou incorreto , como não existe um modelo de desenvolvimentoque seja a panacéia universal para o problema do desenvolvimento de software.

Dependendo de sua aplicação, ambiente e objetivo, a utilização de um processo ou modeloespecífico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado eusar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo dedesenvolvimento.