ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar · Software é um programa de computador e documentação associada. ... às técnicas de teste de software (até porque o

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

1

- MÓDULO 1 - SOFTWARE E ENGENHARIA DE SOFTWARE

1. INTRODUÇÃO

No inicio da evolução dos sistemas computadorizados, por volta da década de 40, grande parte dos esforços eram concentrados no desenvolvimento do hardware, em razão das limitações e dificuldades encontradas na época. Na década de 50, a tecnologia do hardware foi sendo dominada e as preocupações se voltaram para o desenvolvimento dos sistemas operacionais, quando surgiram os primeiros destes sistemas, bem como as chamadas linguagens de programação de alto nível, como Fortran e Cobol.

A tendência na época era de poupar cada vez mais o usuário final de conhecer profundamente as questões relacionadas ao funcionamento interno da máquina, permitindo que este pudesse concentrar seus esforços na resolução dos problemas computacionais ao invés de preocupar-se com os problemas relacionados ao funcionamento do hardware.

Na década de 60, com o surgimento dos sistemas operacionais com características de multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável crescimento, o qual contribuíram também para as constantes quedas de preço do hardware.

Uma consequência deste crescimento foi a necessidade, cada vez maior, de desenvolver grandes sistemas de software em substituição aos pequenos programas aplicativos utilizados até então.

Surgiu, então, um problema nada trivial devido à falta de experiência e à não adequação dos métodos de desenvolvimento existentes para pequenos programas, o que foi caracterizado como a "Crise do Software", mas que, por outro lado, permitiu o nascimento do termo "Engenharia de Software". 1.1. A Crise do Software

A crise do software foi um termo utilizado na década de 1970, quando a Engenharia de Software era praticamente inexistente.

O termo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados. (Wikipédia, a enciclopédia livre, 2014)

As causas da crise do software estão ligadas a complexidade do processo de software e a

relativa imaturidade da engenharia de software como profissão. A crise se manifestou de várias formas:

- Projetos estourando o orçamento; - Projetos estourando o prazo; - Desenvolvimento fora de controle;


2

- Software de baixa qualidade; - Software que muitas vezes não atingiam os requisitos; - Projetos não gerenciáveis e o código difícil de manter; - Mais importante: era um problema de qualidade.


3

2. PRINCIPAIS ASPECTOS DO SOFTWARE 2.1. Software: Definições e características

Pode-se definir o software, de uma forma clássica, como sendo "um conjunto de instruções que, quando executadas, produzem a função e o desempenho desejados; estruturas de dados que possibilitam aos programas manipular informações adequadamente; e a documentação necessária para um melhor entendimento da sua operação e uso". Pode-se dizer, então que Software é um programa de computador e documentação associada.

Entretanto, no contexto da Engenharia de Software, o software deve ser visto como um produto a ser vendido. É importante dar esta ênfase, diferenciando os programas que são concebidos num contexto mais restrito, onde o usuário ou "cliente" é o próprio autor. No caso destes programas, a documentação associada é pequena ou (na maior parte das vezes) inexistente e a preocupação com a existência de erros de execução não é um fator maior, considerando que o principal usuário é o próprio autor do programa, este não terá dificuldades, em princípio, na detecção e correção de um eventual "bug". Além do aspecto da correção, outras boas características não são também objeto de preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.

Um produto de software (ou software, como vamos chamar ao longo do curso), por outro lado, é sistematicamente destinado ao uso por pessoas outras que os seus programadores. Os eventuais usuários podem, ainda, ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade) de detectar e corrigir os eventuais erros de execução.

Resumindo, um programa desenvolvido para resolver um dado problema e um produto de software destinado à resolução do mesmo problema são duas coisas totalmente diferentes. É óbvio que o esforço e o consequente custo associado ao desenvolvimento de um produto serão muito superiores.

Neste prisma, software é concebido e desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico; o software não se desgasta, ou seja, ao contrário da maioria dos produtos, o software não se caracteriza por um aumento na possibilidade de falhas à medida que o tempo passa (como acontece com a maioria dos produtos manufaturados); · a maioria dos produtos de software é concebida inteiramente sob medida, sem a utilização de componentes pré-existentes. Em função destas características diferenciais, o processo de desenvolvimento de software pode desembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto.

Desde os primórdios da computação, o desenvolvimento dos programas (ou, a programação) era visto como uma forma de arte, sem utilização de metodologias formais e sem qualquer preocupação com a documentação, entre outros fatores importantes. A experiência do programador era adquirida através de tentativa e erro. Contudo, esta tendência ainda se verifica.


4

Com o crescimento dos custos de software (em relação aos de hardware) no custo total de um sistema computacional, o processo de desenvolvimento de software tornou-se um item de fundamental importância na produção de tais sistemas.

A nível industrial, algumas questões que caracterizaram as preocupações com o processo de desenvolvimento de software foram:

- Por que o software demora tanto para ser concluído? - Por que os custos de produção têm sido tão elevados? - Por que não é possível detectar todos os erros antes que o software seja entregue ao

cliente? - Por que é tão difícil medir o progresso durante o processo de desenvolvimento de

software?

Estas são algumas das questões que a Engenharia de Software pode ajudar a resolver. Enquanto não respondemos definitivamente a estas questões, podemos levantar alguns dos problemas que as originam:

- raramente, durante o desenvolvimento de um software, é dedicado tempo para coletar dados sobre o processo de desenvolvimento em si; devido à pouca quantidade deste tipo de informação, as tentativas em estimar a duração/custo de produção de um software têm conduzido a resultados bastante insatisfatórios; além disso, a falta dessas informações impede uma avaliação eficiente das técnicas e metodologias empregadas no desenvolvimento;

- a insatisfação do cliente com o sistema "concluído" ocorre frequentemente, devido, principalmente, ao fato de que os projetos de desenvolvimento são baseados em informações vagas sobre as necessidades e desejos do cliente (problema de comunicação entre cliente e fornecedor);

- a qualidade do software é quase sempre suspeita, problema resultante da pouca atenção que foi dada, historicamente, às técnicas de teste de software (até porque o conceito de qualidade de software é algo relativamente recente);

- o software existente é normalmente muito difícil de manter em operação, o que significa que o custo do software acaba sendo incrementado significativamente devido às atividades relacionadas à manutenção; isto é um reflexo da pouca importância dada à manutenibilidade no momento da concepção dos sistemas. 2.2. Software: Componentes Executável: É o programa principal, escrito numa linguagem com uma gramática exata sem ambiguidade, com sintaxe clara e precisa, que compilada ou interpretada gera uma linguagem de comunicação com a máquina. O código fonte é uma linguagem de alto nível, que após compilada gera o código binário que é uma linguagem de baixo nível.

Figura 1 – Fases do software executável


5

Não executável: São os arquivos auxiliares, configurações, bibliotecas, módulos. 2.3. Software: Aplicações

- Básicos : Sistemas Operacionais. - Utilitários: Ferramentas de sistema, antivírus, etc. - Tempo Real : Apresenta resultados no exato momento do acontecimento, controle de

tráfego, temperatura, velocidade do cento, etc. - Científico e Engenharia: Astronômico, fadiga de componentes mecânicos, médicos,

engenharia civil, científico, CASE. - Comerciais: Folha de Pagamento, contabilidade, controle de estoque. - Pessoais: Jogos, editores de texto, planilhas eletrônicas, agendas, etc. - Embutidos: São programas embutidos em outros aparelhos, microondas, automóveis,

televisores, videocassetes, etc. - Profissionais Artísticos: Manipula figuras, imagens, fotos, desenhos, criações artísticas

tais como: Corel Draw, Adobe Photoshop, etc. - Inteligência Artificial: Por ser um Software de algoritmo não numérico, para resolver

problemas complexos, esses softwares processam conhecimentos. Simula uma rede neural cumulativa - AI (Artificial Inteligency), é muito usado para o reconhecimento de voz, imagens, reconhece padrões complexos, imita o raciocínio biológico do cérebro humano, muito usado em jogo de xadrez. 2.4. Software: Mitos e Realidade Alguns dos problemas relacionados ao software e ao seu desenvolvimento podem ser explicados por alguns aspectos:

- a falta de experiência dos profissionais na condução de projetos de software; - a falta de treinamento no que diz respeito ao uso de técnicas e métodos formais para o

desenvolvimento de software; - a “cultura de programação” que ainda é difundida e facilmente aceita por estudantes e

profissionais de Ciências da Computação; - a incrível "resistência" às mudanças (particularmente, no que diz respeito ao uso de

novas técnicas de desenvolvimento de software) que os profissionais normalmente apresentam.

Neste prisma alguns mitos e realidades explicam alguns dos problemas de desenvolvimento: 2.4.1. MITOS DE GERENCIAMENTO

- Mito 1: "Se a equipe dispõe de um manual repleto de padrões e procedimentos de desenvolvimento de software, então a equipe está apta a encaminhar bem o desenvolvimento."


6

- Realidade 1: Isto verdadeiramente não é o suficiente. É preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual... é necessário que o que conste no dado manual reflita a moderna prática de desenvolvimento de software e que este seja exaustivo com relação a todos os problemas de desenvolvimento que poderão aparecer no percurso.

- Mito 2: "A equipe tem ferramentas de desenvolvimento de software de última geração, uma vez que eles dispõem de computadores de última geração."

- Realidade 2: Ter à sua disposição o último modelo de computador (seja ele um mainframe, estação de trabalho ou PC) pode ser bastante confortável para o desenvolvedor do software, mas não oferece nenhuma garantia quanto à qualidade do software desenvolvido. Mais importante do que ter um hardware de última geração é ter ferramentas para a automatização do desenvolvimento de software (as ferramentas CASE).

- Mito 3: "Se o desenvolvimento do software estiver atrasado, basta aumentar a equipe para honrar o prazo de desenvolvimento."

- Realidade 3: Isto também dificilmente vai ocorrer na realidade. Alguém disse um dia que "acrescentar pessoas em um projeto atrasado vai torná-lo ainda mais atrasado." De fato, a introdução de novos profissionais numa equipe em fase de condução de um projeto vai requerer uma etapa de treinamento dos novos elementos da equipe; para isto, serão utilizados elementos que estão envolvidos diretamente no desenvolvimento, o que vai, consequentemente, implicar em maiores atrasos no cronograma. 2.4.2. MITOS DO CLIENTE

- Mito 1: "Uma descrição breve e geral dos requisitos do software é o suficiente para iniciar o seu projeto. Maiores detalhes podem ser definidos posteriormente."

- Realidade 1: Este é um dos problemas que podem conduzir um projeto ao fracasso, o cliente deve procurar definir o mais precisamente possível todos os requisitos importantes para o software: funções, desempenho, interfaces, restrições de projeto e critérios de validação são alguns dos pontos determinantes do sucesso de um projeto.

- Mito 2: "Os requisitos de projeto mudam continuamente durante o seu desenvolvimento,

mas isto não representa um problema, uma vez que o software é flexível e poderá suportar facilmente as alterações."

- Realidade 2: É verdade que o software é flexível (pelo menos mais flexível do que a maioria dos produtos manufaturados). Entretanto, não existe software, por mais flexível que suporte alterações de requisitos significativas com adicional zero em relação ao custo de desenvolvimento. O fator de multiplicação nos custos de desenvolvimento do software devido a alterações nos requisitos cresce em função do estágio de evolução do projeto, como mostra a figura 2.


7

Figura 2 – Influência das alterações de requisitos no curto de um sistema

2.4.3. MITOS DO PROFISSIONAL

- Mito 1: "Após a edição do programa e a sua colocação em funcionamento, o trabalho está terminado."

- Realidade 1: O que ocorre na realidade é completamente diferente disto. Segundo dados obtidos a partir de experiências anteriores, 50 a 70% do esforço de desenvolvimento de um software é despendido após a sua entrega ao cliente (manutenção).

- Mito 2: "Enquanto o programa não entrar em funcionamento, é impossível avaliar a sua qualidade."

- Realidade 2: Na realidade, a preocupação com a garantia do software deve fazer parte de todas as etapas do desenvolvimento, sendo que, ao fim de cada uma destas etapas, os documentos de projeto devem ser revisados observando critérios de qualidade.

- Mito 3: "O produto a ser entregue no final do projeto é o programa funcionando." - Realidade 3: Um programa funcionando é apenas uma parte de uma configuração de

software que inclui: requisitos, projeto, estrutura de dados, etc. A documentação é a base do desenvolvimento e guia indispensável para manutenção.


8

3. ENGENHARIA DE SOFTWARE

Os problemas apontados na Crise do Software não foram resolvidos de forma trivial. O primeiro passo em direção a solução foi reconhecer os problemas existentes à época, defini-los da forma mais precisa e eficaz e definir uma combinação de métodos que sejam abrangentes a todas as etapas do desenvolvimento de um software.

Além disto, é importante que estes métodos sejam suportados por um conjunto de ferramentas que permita automatizar as etapas, juntamente com uma definição clara de critérios de qualidade e produtividade de software. São estes aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de Software.

Diante disso, em 1969, Fritz Bauer fez uma primeira abordagem sobre tema definindo-o como “o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais”.

Mesmo que tantas outras definições tenham surgido ao longo do tempo, todas elas reforçam a existência da disciplina da engenharia no desenvolvimento do software:

Além disso, outros três aspectos são também importantes: métodos (como fazer), ferramentas (apoio no fazer) e procedimentos (união dos métodos e ferramentas). Estes aspectos aliados à disciplina, possibilitam ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma imensa base para a construção de software de alta qualidade, de forma produtiva.

Na literatura, pode-se encontrar diversas definições da Engenharia de Software, como se vê nas citações abaixo:

"O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais." [NAU 69].

“A aplicação prática do conhecimento científico para o projeto e a construção de

programas computacionais e a documentação necessária à sua operação e manutenção.” [BOEHM, 76]

“Abordagem sistemática para o desenvolvimento, a operação e a manutenção de software” [AFNOR, 83]

“Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de

qualidade para todas as etapas do ciclo de vida do produto.” [KRAKOWIAK, 85] A Engenharia de Software pode ser definida como sendo a aplicação da ciência e da

matemática através das quais os equipamentos computacionais são colocados à disposição do homem por meio de programas, procedimentos e documentação associada.

Os objetivos, então, da Engenharia de Software são: - Obter software de qualidade;


9

- Com produtividade no seu desenvolvimento, operação e manutenção; - Dentro de custos, prazos e níveis de qualidade controlados; - Com o melhor custo-benefício entre Qualidade e Produtividade;

A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial,

apesar dos esforços desenvolvidos nesta direção. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados.

Pressman informa, ainda, que a Engenharia de Software é uma tecnologia em camadas, como se vê na figura 3.

Figura 3 - Camadas da Engenharia de Software

Qualquer abordagem de engenharia deve estar comprometida com a qualidade, pois

promovem o aperfeiçoamento contínuo dos processos, o que leva ao desenvolvimento de abordagens cada vez mais efetivas na engenharia de software.

Um software de qualidade deve satisfazer os requisitos solicitados pelo usuário. Deve ser fácil de manter, ter boa performance, ser confiável e fácil de usar. Alguns atributos de qualidade:

- Manutenibilidade: O software deve evoluir para atender os requisitos que mudam. - Eficiência: O software não deve desperdiçar os recursos do sistema. - Usabilidade: O software deve ser fácil de usar pelos usuários para os quais ele foi

projetado. A base da Engenharia de Software é a camada de processos. Os processos possibilitam

o desenvolvimento de forma racional e dentro do prazo, de forma a definir uma metodologia que deve ser estabelecida para a entrega efetiva. Constitui ainda a base para o controle do gerenciamento de projetos estabelecendo o contexto no qual são aplicados métodos técnicos.

Os métodos da Engenharia de Software as informações técnicas para desenvolver software. Os métodos envolvem uma ampla gama de tarefas, que incluem: comunicação, análise de requisitos, modelagem do projeto, construção do programa, testes e suporte. Para tanto, baseiam-se em um conjunto de princípios que governam cada área da tecnologia e inclui atividades de modelagem e outras técnicas descritivas.

As ferramentas fornecem suporte automatizado para os processos e para os métodos.

Diante disso é coerente a definição de Engenharia de Software dada por Pressman(1995):


10

Engenharia de Software é o estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais, abrangendo um conjunto de três elementos fundamentais (métodos, ferramentas e procedimentos). Pressman(1995)

Mesmo com essa definição clara sobre Engenharia de Software é imprescindível não

confundir este termo com a Engenharia de Sistemas. Esta é algo maior e preocupa-se com todos os aspectos de sistemas baseados em computador, como software, hardware, processos, pessoas e outros sistemas, enquanto a Engenharia de Software é apenas parte do processo. 3.1. Princípios da Engenharia de Software

Todo engenheiro de software deve desenvolver com: - Rigor e formalidade - Separação de interesses - Modularidade - Abstração - Antecipação de mudanças - Generalidade - Possibilidades de evolução

3.2. Processos de Software Processo de software é definido como uma metodologia para as atividades, ações e tarefas necessárias para desenvolver um software de alta qualidade. O processo de software vai definir a abordagem adotada conforme um software é elaborado pela engenharia.

Para transformar as necessidades dos clientes em software, antes é preciso: - Entender as necessidades do cliente; - Planejar uma solução; - Implementar e testar a solução; - Entregar a solução.

De modo geral, tais atividades são executadas de forma desordenada e informal e por

apenas uma pessoa. O conjunto de atividades de desenvolvimento, sua ordem temporal e a atribuição de

responsabilidades (papéis de desenvolvedores) definem um processo de desenvolvimento de software.

Um processo de software é a especificação do processo de transformar necessidades em software. Um ciclo de Vida de um Processo determina as fases do processo e define atividades importantes e opcionais para cada fase.


11

3.3. Modelos de Software

Modelos descrevem um determinado sistema, muitas vezes de forma simplificada. O modelo de um processo de desenvolvimento. É a especificação (documentada) de um processo de desenvolvimento de software que servirá de parâmetro para uso/especificação de um processo para uma equipe/projeto.

Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também há uma gradação de complexidade, necessitando de um planejamento inicial.

Um modelo pode ser visto como uma representação idealizada de um sistema que se planeja construir. Maquetes de edifícios e de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos.

Em princípio, podemos ver a construção de modelos como uma atividade que atrasa o desenvolvimento do software propriamente dito. Esta atividade propicia:

- O gerenciamento da complexidade inerente ao desenvolvimento de software. - A comunicação entre as pessoas envolvidas. - A redução dos custos no desenvolvimento. - A predição do comportamento futuro do sistema.

Entretanto, note o fator complexidade como condicionante dessas vantagens.

3.4. Diagramas e Documentação No contexto de desenvolvimento de software, os diagramas correspondem a desenhos gráficos que seguem algum padrão lógico. Também é possível afirmar que um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido.

Diagramas normalmente são construídos de acordo com regras de notação bem definidas. Ou seja, cada forma gráfica utilizada em um diagrama de modelagem tem um significado específico. Estes permitem a construção de uma representação concisa de um sistema a ser construído. Vale o ditado: “uma figura vale por mil palavras”.

No entanto, modelos também são compostos de informações textuais. Dado um modelo de uma das perspectivas de um sistema, diz-se que o seu diagrama, juntamente com a informação textual associada, formam a documentação deste modelo.


12

4. PARADIGMAS DA ENGENHARIA DE SOFTWARE

Um paradigma é uma forma de abordar um problema. No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual esse sistema é entendido, projetado e construído.

Outra definição, dada por Pressman, é que os paradigmas são “os modelos de processos que possibilitam:

- ao gerente: o controle do processo de desenvolvimento de software; - ao desenvolvedor: obter a base para produzir, de maneira eficiente, software que

satisfaça os requisitos preestabelecidos.” Os paradigmas especificam algumas atividades que devem ser executadas, assim como a

ordem em que devem ser executadas. A função dos paradigmas é diminuir os problemas encontrados no processo de desenvolvimento do software, e deve ser escolhido de acordo com a natureza do projeto e do produto a ser desenvolvido, dos métodos e ferramentas a serem utilizadas e dos controles e produtos intermediários desejados. 4.1. Ciclo de vida clássico ou cascata Este modelo teve origem na indústria de manufatura e construção. Sua estrutura é composta por várias etapas que são executadas de forma sistemática e sequencial. Na falta de uma abordagem estruturada, foi a primeira tentativa de formalizar uma metodologia de desenvolvimento de software.

São utilizados conceitos de Engenharia de Software, a qual prevê atividade de verificação (estamos fazendo o produto de forma correta?), validação (estamos fazendo o produto certo?) e de controle de qualidade. É um paradigma que utiliza um método sistemático e sequencial em que o resultado de uma fase se constitui na entrada de outra, como se vê na figura 4.

Figura 4 – Ciclo de vida clássico (Cascata)

Este paradigma abrange as seguintes atividades (ou ciclos): - Engenharia de Software: quanto mais dados forem coletados em nível de sistema,

menor será a probabilidade de haver "bugs" no sistema, consequentemente diminuirá os futuros


13

reparos no mesmo. Também conhecido como estudo de viabilidade. - Análise e Especificação de Requisitos de software: é importante saber o que o cliente quer que o software tenha, com relação à recursos. Os requisitos devem ser documentados e revistos como cliente antes de começar a execução do projeto. - Projeto: envolve muitos passos que se concentram em 4 atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface. O processo de feitura do projeto traduz quanto à qualidade antes de iniciar a codificação. - Codificação: o projeto deve ser transformado em programa, usando uma linguagem de programação, isto é, traduzido numa linguagem de máquina. - Testes e Integração do sistema: deve-se testar todas os programas a procura de erros. A Integração consiste das junções das várias unidades e programas desenvolvidos. O resultado real deve concordar com o projeto ou resultado exigido. Depois de testado, o software é entregue ao usuário. - Manutenção e Operação: o sistema é instalado e colocado em uso, indubitavelmente o software sofrerá mudanças depois que foi entregue ao cliente, e, mesmo software embutido sofre upgrade de tempos em tempos. A manutenção ocorre básica mente com a correção de erros não detectados (manutenção corretiva), com a adaptação da aplicação às mudanças do ambiente (manutenção adaptativa) e na adição de novas características e qualidades do software (manutenção evolutiva).

O ciclo de vida clássico é o paradigma mais antigo e o mais amplamente usado em Engenharia de Software, contudo apresenta alguns problemas:

- Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe. - O cliente não saberá declarar todas as suas exigências.

- O cliente deve ter paciência, pois qualquer erro detectado após a revisão do programa de trabalho pode ser desastroso.

Os problemas são reais, mas, mesmo assim o ciclo de vida clássico continua sendo o mais

usado no desenvolvimento de software. Este modelo é apropriado para sistemas transacionais, onde as rotinas e procedimentos a serem automatizados são altamente estruturados. A principal desvantagem desta abordagem é o alto custo de correção das especificações quando nas fases de Teste e Implantação.

Em suma, este modelo minimiza o planejamento, organiza as atividades em uma sequência com entregas bem definidas. Funciona bem para requisitos estáveis e bem compreendidos. O modelo pressupõe que os requisitos ficarão estáveis ao longo do projeto. É facilmente aplicável em equipes inexperientes, porém, atrasa a redução de riscos como se observa na figura 5.


14

Figura 5 – Cronograma de um projeto

Por fim, convém exemplificar a visão de dois autores renomados, Sommerville e

Pressman, acerca do modelo em questão (Figura 6):

Figura 6 – Visão acerca do Modelo Clássico ou em Cascata

4.2. Prototipação Prototipação é uma abordagem baseada em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Envolve a produção de versões iniciais - protótipos (análogo a maquetes para a arquitetura) - de um sistema futuro com o qual é possível realizar verificações e experimentos, com o intuito de avaliar algumas de suas características antes que o sistema venha realmente a ser construído, de forma definitiva.

O objetivo é trabalhar junto aos clientes para evoluir o sistema a partir de uma especificação inicial resumida com o intuito de entregar resultado o mais rápido possível.

Deve-se começar pelos requisitos mais bem compreendidos e novas funcionalidades são adicionadas à medida que o cliente as propõem.


15

É aplicável em sistemas pequenos ou médios com curto tempo de vida. Algumas vezes um protótipo é usado apenas para definir a aparência externa do sistema.

As etapas do modelo são: - Obtenção dos Requisitos: o desenvolvedor e cliente definem os objetivos gerais do

software, identificando quais os requisitos são conhecidos inicialmente. - Projeto Rápido: é entregue ao cliente uma versão compacta do projeto, este poderia ser

um layout. Nessa etapa o cliente vai ter uma ideia de como o software funcionará quando pronto. - Construção do Protótipo: após a etapa do projeto rápido e concluídas as modificações

necessárias no projeto passa-se para a construção rápida do protótipo que poderá ser a versão final do produto.

- Avaliação do Protótipo pelo Cliente: entrega-se o produto ao cliente e aqui o mesmo determina se realmente era isso que precisava.

- Refinamento do Protótipo: aplicação das melhorias necessárias para a conclusão do projeto juntamente com as modificações que o cliente pedirá. Importante para que as necessidades do cliente sejam satisfeitas.

- Construção do Produto: identificados os requisitos o protótipo pode ser descartado e a versão de produção deve ser construída (podendo ser baseada no protótipo) considerando os critérios de qualidade.

Figura 7 – Etapas da Prototipação

Segundo Pfleeger(2004), o desenvolvimento do sistema pode começar como um conjunto

simples de requisitos fornecidos pelos cliente e usuários. Então, as alternativas são exploradas. Examinam-se as telas, tabelas, relatórios e outras saídas do sistema, diretamente utilizadas pelos clientes e usuários. Assim que os usuários e clientes decidem o que realmente querem, os requisitos são revisados. Uma vez que haja consenso de como deveriam ser os requisitos, o desenvolvedor se volta para as atividades de requisitos, a fim de reconsiderar e alterar a especificação. Finalmente, o sistema é codificado, e as alternativas, discutidas, de novo com uma possível iteração entre requisitos e projeto.


16

4.2.1. PROTOTIPAÇÃO EVOLUCIONÁRIA Um protótipo inicial é produzido e refinado através de inúmeras etapas de avaliação e re-

design até tornar-se um produto final.

4.2.2. PROTOTIPAÇÃO DESCARTÁVEL Utilizado na descoberta e avaliação dos requisitos e depois descartado. O resultado é a

especificação dos requisitos.

4.2.3. VANTAGENS - Redução de incerteza; - Menor custo com alteração, visto que o modelo permite a alteração durante o

desenvolvimento; - Os requisitos incompletos podem ser encontrados no momento do desenvolvimento; - Melhoria na qualidade do projeto; - Maior aproximação do software com as necessidades do cliente; - Melhoria na manutenção; - Menor esforço de desenvolvimento.

4.2.4. DESVANTAGENS

- Se não houver uma definição cuidadosa de quando parar a prototipação pode se

estender por tendo indeterminado. - Falta de visibilidade no processo de desenvolvimento. - Má estruturação na construção de sistemas. - Por pressão dos clientes os protótipos podem acabar tornando-se produto final.

4.3. Modelos Iterativos

No Modelo Iterativo os requisitos de sistema sempre evoluem durante o projeto. A ideia central do modelo é “dividir para conquistar”. Consiste de duas abordagens:

- Desenvolvimento Incremental; - Desenvolvimento Espiral.

4.3.1. DESENVOLVIMENTO INCREMENTAL A ideia é de desenvolver e entregar o software em incrementos, com cada incremento


17

entregando parte da funcionalidade requerida. Os requisitos são definidos antes do desenvolvimento do incremento, sendo os mais críticos priorizados. Um “mini projeto em cascata” é executado em cada iteração, progredindo até a entrega final do produto, como se vê no exemplo da figura 8.

Figura 8 – Etapas do Desenvolvimento Incremental

O Modelo Incremental combina elementos do modelo sequencial linear com a filosofia

iterativa da prototipagem, além de aplicar sequências lineares de uma forma racional à medida que o tempo passa.

São múltiplos ciclos de desenvolvimento, chamados de incremento, nos quais o cliente revisa funcionalidades e acrescenta novas. A cada incremento o modelo procura a elaboração de um produto operacional.

Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos. As vantagens do desenvolvimento incremental são:

- Entregas parciais facilitam a identificação e correção de erros entre os componentes do software. - Necessidades não especificadas nas fases iniciais podem ser desenvolvidas nos incrementos. - Cada iteração produz um conjunto de itens utilizáveis. - Os feedbacks de iterações anteriores podem ser usados nos próximos incrementos. - Os incrementos podem ser desenvolvidos por menos profissionais. - Entrega dos incrementos permite o cumprimento do prazo especificado. - Facilita a manutenção dos módulos. - O risco geral do projeto fracassar diminui.


18

Porém, como tudo, apresenta algumas desvantagens: - Número de iterações não pode ser definido no início do processo.

- O fim do processo não pode ser previamente definido. - Gerenciamento e manutenção do sistema completo podem se tornar complexos. - Gerenciamento do custo é mais complexo devido ao número de iterações (verba pode

acabar). 4.3.2. DESENVOLVIMENTO EM ESPIRAL

O Modelo Espiral, segundo Pressman (1995), abrange as melhores características do Ciclo

de Vida Clássico e da Prototipação, acrescentando um novo elemento: a análise dos riscos, inexistentes nos outros dois modelos.

Esse modelo corrige (ao menos em parte) o fato do desenvolvimento de sistema ter ciclos, onde as tarefas são repetidas. Não corrige o fato de que em algumas fases apliquemos simultaneamente (ainda que em menor proporção), habilidades de outras fases, porém isso é uma limitação própria do modelo.

Um fator muito importante no modelo Espiral é que cada ciclo é completado com uma revisão, na presença de pessoas chave para o produto em desenvolvimento. Esta revisão mostra tudo o que foi desenvolvido durante o ciclo previsto, incluindo os planos para a próxima etapa a ser realizada.

Na visão de Boehm, o modelo em espiral é representado por um plano dividido em 4 quadrantes (figura 9), onde cada um deles contém uma fase cíclica do trabalho de desenvolvimento. Esse plano é percorrido por uma linha espiral, que nasce no centro do plano (momento zero do trabalho de desenvolvimento), e que tem prosseguimento caminhando do centro para as bordas, sempre passando pelas 4 fases cíclicas, de tal forma que um ciclo se repete após o outro, até que o trabalho seja dado como concluído. Define quatro atividades principais:

- Planejamento: é a determinação dos objetivos, alternativas e restrições do projeto. - Análise dos Riscos: é a análise das alternativas e a resolução dos riscos. - Execução: desenvolvimento do produto. - Verificação feita pelo Cliente: é a avaliação dos resultados obtidos nas atividades da

engenharia.


19

Figura 9 – Desenvolvimento em Espiral [Boehm]

Analisando a figura, observa-se que a cada iteração ao redor da espiral, iniciando-se ao

centro e avançando para fora, versões mais completas do sistema são construídas. Durante o primeiro giro ao redor da espiral são definidos os objetivos, alternativas e restrições. Também são identificados e analisados os riscos. Se a análise dos riscos detectar incertezas nos requisitos, deve-se fazer uso da prototipação no quadrante Execução, para auxiliar tanto o desenvolvedor como o usuário. Para definir ainda mais o problema e refinar os requisitos, o desenvolvedor pode utilizar simulações e outros modelos.

No quadrante de Verificação, o cliente avalia o trabalho de Execução e apresenta suas sugestões para modificações. A partir dessas sugestões ocorre a fase de Planejamento e Análise dos Riscos. A conclusão da Análise dos Riscos resulta em uma decisão de prosseguir ou não o projeto. Caso os riscos sejam muito grandes, o projeto pode até ser encerrado.

A medida que componentes são desenvolvidos: - Os componentes são avaliados; - O desenvolvimento futuro é reavaliado; - Riscos são avaliados; - O ciclo termina com o produto pronto. Na visão de Pressman, o modelo divide-se em regiões de tarefas. Cada região é formada

por um conjunto de tarefas. As regiões de tarefas estão ilustradas na figura 10 e são:


20

Figura 10 – Desenvolvimento em Espiral [Pressman]

- Comunicação com o cliente: define as tarefas necessárias para estabelecer a

comunicação entre o desenvolvedor e o cliente. - Planejamento: define recursos, prazos e outras informações relacionadas ao projeto. - Análise de risco: avalia os riscos, tanto técnicos quanto gerenciais. - Engenharia: define tarefas necessárias para construção de uma ou mais representações

da aplicação. - Construção e liberação: define tarefas necessárias para construir, testar, instalar e

fornecer apoio ao usuário. - Avaliação pelo cliente: são as tarefas necessárias para validar o sistema com o cliente.

Baseia-se na avaliação das representações do software criadas durante o estágio de engenharia e implementadas durante o estágio de instalação.

Em resumo, o processo é representado como uma espiral em vez de uma sequência de atividades. Cada volta na espiral representa uma fase no processo. Não há fases fixas, como Especificação, Projeto, etc. Os loops na espiral são escolhidos dependendo do que for necessário. 4.4. Técnicas de quarta geração (4GT)

O termo “Técnicas da Quarta Geração” (4GT) abrange um amplo conjunto de ferramentas de software que têm uma coisa em comum: cada uma delas possibilita que o desenvolvedor de software especifique alguma característica do software num nível elevado. O paradigma (4GT) da engenharia de software concentra-se na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa.

Atualmente, o ambiente de desenvolvimento de software que sustenta o paradigma 4GT inclui algumas, ou todas, das seguintes ferramentas: linguagens não-procedimentais para consulta de banco de dados, geração de códigos, capacidade gráfica de alto nível e capacidade de planilhas eletrônicas.


21

O paradigma 4GT da engenharia de software é representado pela figura a seguir:

Figura 11 – Técnica de Quarta Geração

O 4GT inicia-se com uma etapa de coleta de requisitos. Idealmente, o cliente descreveria

os requisitos, e estes seriam diretamente traduzidos num protótipo operacional. Porém, as atuais ferramentas 4GT não são sofisticadas o bastante para acomodar verdadeiramente “linguagem natural”, e não o serão por algum tempo. No momento, o diálogo cliente-desenvolvedor continua sendo uma parte essencial da abordagem 4GT. O uso da 4GT sem planejamento (para grandes projetos) causará as mesmas dificuldades (má qualidade, manutenibilidade ruim e má aceitação do cliente) que temos encontrado quando desenvolvemos software usando abordagens convencionais.

Para transformar a implementação de uma 4GT num produto, o desenvolvedor deve realizar testes cuidadosos, desenvolver uma documentação significativa e executar todas as demais atividades de “transição” que também são exigidas em outros paradigmas de engenharia de software. Além disso, o software desenvolvido por 4GT deve ser construído de um modo que possibilite rápida manutenção.

Por fim, os métodos convencionais provavelmente contribuíram cada vez menos para o desenvolvimento de software.


22

5. REENGENHARIA DE SOFTWARE A reengenharia de Software é uma das estratégias de evolução de software e se ocupa em

reimplementar sistemas legados, para que sua manutenção seja fácil. De modo geral, as funcionalidades do software não são modificadas e, normalmente, a arquitetura do sistema permanece a mesma.

Nesta tarefa pode envolver: - Redocumentar; - Organizar e reestruturar o sistema; - Traduzir o sistema para uma linguagem de programação mais moderna; - Modificar e atualizar a estrutura e os valores dos dados do sistema. A manutenção de sistemas legados é cada vez mais dispendiosa, e a reengenharia torna

isso menos custoso e prolonga seu tempo de vida útil. Pode se dizer ainda que a reengenharia melhora a estrutura do sistema, criando uma nova documentação relacionada e faz com que ela seja de mais fácil compreensão.

Vale ressaltar que a reengenharia é eficaz em termos de custo quando ele tem alto valor de negócios, mas é dispendioso manter.

A reengenharia de software tem duas vantagens principais: a) Riscos reduzidos: Isto porque, durante o redesenvolvimento de um software podem ser

inseridos erros na especificação, no desenvolvimento, etc. b) Custos reduzidos: O custo da reengenharia é significativamente menor do que os

custos de desenvolvimento.

Figura 12 – Distinção entre o desenvolvimento de um novo sistema (a) e reengenharia (b).

Fonte: SOMMERVILLE

5.1. Processo de Reengenharia de Software

Um processo de reengenharia tem como entrada um programa legado e a saída é uma versão estruturada e modularizada do mesmo programa, conforme exemplifica a figura 13. Ao

Especificação do Sistema

Projeto e implementação Novo Sistema

Software já existente Compreensão

e transformação

Sistema “reengenheirado”


23

mesmo tempo que ocorre a reengenharia do programa, os dados do sistema também podem passar por reengenharia.

Figura 13 – Processo de reengenharia

Fonte: SOMMERVILLE

5.2. Atividades do Processo de Reengenharia de Software No processo de reengenharia algumas atividades são seguidas, a saber:

- Tradução do código fonte: O programa é convertido de uma linguagem de programação antiga para uma versão mais moderna da mesma linguagem ou para um linguagem diferente.

- Engenharia reversa: O programa é analisado e as informações são extraídas dele, a fim de ajudar a documentar sua organização e funcionalidade.

- Melhoria na estrutura do programa: A estrutura de controle do programa é analisada e modificada, a fim de torná-la mais fácil de ser lida e compreendida.

- Modularização do programa: As partes relacionadas do programa são agrupadas e, quando for apropriado, a redundância é removida.

- Reengenharia de dados: Os dados processados pelo programa são modificados, a fim de refletir as mudanças feitas nele.

A reengenharia pode não exigir necessariamente todas as etapas apresentadas anteriormente, por exemplo a tradução de código fonte pode não ser necessária se a linguagem ainda for aceita pelo fornecedor do compilador. 5.3. Custos da Reengenharia de Software

Os custos da reengenharia dependem da extensão do trabalho que é realizado, como se observa na figura 14.


24

Figura 14 – Custos da reengenharia

5.3.1. FATORES DE CUSTOS DA REENGENHARIA Alguns aspectos estão envolvidos para estimar os custos para a reengenharia do software. São eles:

- A qualidade do software que deve passar pela reengenharia; - O apoio às ferramentas disponíveis para a reengenharia; - A extensão da conversão de dados requerida; - A disponibilidade de pessoal habilitado.

Um caso a se analisar é na tradução de código fonte: Converter um código de uma linguagem (ou versão) para outra, por exemplo FORTRAN para C. Pode ser necessária pelas seguintes razões:

- Atualização da plataforma de hardware; - Escassez de pessoal habilitado; - Mudanças na política organizacional; - Falta de suporte ao software. Contudo, é importante salientar que no caso em específico a tarefa se torna realista se um

tradutor automático estiver disponível.

5.4. Engenharia Reversa

É o processo de analisar o software com o objetivo de recuperar seu projeto e sua especificação.

A engenharia reversa pode fazer parte do processo de reengenharia, mas não é o mesmo que a reengenharia. Seu objetivo da engenharia reversa é derivar o projeto ou a especificação de um sistema a partir de seu código-fonte; um novo sistema, com manutenção mais fácil.

O processo inicia com uma fase de análise, utilizando-se de ferramentas automatizadas, a fim de descobrir sua estrutura.

As ferramentas para a compreensão do programa (browsers de armazenamento de informações, geradores de referência cruzada, etc.) podem ser utilizadas para apoiar o processo.


25

A Engenharia reversa é utilizada durante o processo de reengenharia, mas não precisa ser sempre seguida da reengenharia.

O projeto e a especificação de um sistema existente podem passar por engenharia reversa, de modo que possam servir como uma entrada à especificação de requisitos, para a substituição desse programa.

Como alternativa, o projeto e a especificação podem passar por engenharia reversa, de modo que estejam disponíveis para ajudar na manutenção do programa.

5.5. Melhoria de Estrutura de Programa

A estrutura de controle dos sistemas legados é complexa, com muitas ramificações incondicionais e a lógica de controle não é intuitiva. Essa estrutura pode ser afetada por manutenções regulares, tornando alguns códigos inatingíveis.

O programa pode ser reestruturado automaticamente para eliminar declarações incondicionais. Condições complexas também podem ser simplificadas, como parte do processo de reestruturação de programa. 5.6. Modularização de Programa

Outra possibilidade é a de modularização do software. Este é o processo de reorganizar

um programa, de modo que as partes relacionadas sejam coletadas e consideradas um único módulo.

A modularização em geral é realizada manualmente, com a inspeção e a edição do código. 5.6.1. TIPOS DE MÓDULOS

- Abstração de dados: São os tipos de dados abstratos, criados a partir da associação de dados com componentes de processamento.

- Módulos de hardware: Esses módulos estão estreitamente relacionados com as abstrações de dados e agrupam todas as funções utilizadas para controlar um determinado dispositivo de hardware.

- Módulos funcionais: São os módulos de programa que agrupam as funções que realizam tarefas semelhantes ou estreitamente relacionadas.

- Módulos de apoio ao processo: São os módulos nos quais são agrupados todas as funções e todos os itens específicos de dados requeridos para apoiar um processo de negócios específicos. 5.7. Reengenharia de dados

Processo de análise e reorganização de estruturas de dados e, algumas vezes, os valores dos dados em um sistema, para torná-lo mais compreensível. Em princípio, a reengenharia de


26

dados não deverá ser necessária, se a funcionalidade do sistema permanecer inalterada. Na prática, há uma série de razões pelas quais é preciso modificar os dados, como

também os programas, em um sistema legado. São elas: - Degradação dos dados: Com o passar do tempo, a qualidade dos dados tende a

diminuir. As modificações nos dados introduzem erros, valores duplicados podem ter sido criados e as mudanças no ambiente externo podem não estar refletidas nos dados.

- Limites inerentes inseridos no sistema: Quando os programas foram originalmente projetados foram incluídas restrições quanto à quantidade de dados, contudo é necessário que os programas processem muito mais dados que o volume originalmente imaginado.

- Evolução de arquitetura: Se um sistema centralizado migrar para uma arquitetura distribuída, é essencial que o núcleo dessa arquitetura seja um sistema de gerenciamento de dados, que pode ser acessado a partir de clientes remotos. 5.7.1. ABORDAGENS DA REENGENHARIA DE DADOS

- Abordagens da reengenharia de dados: Os registros e valores de dados são analisados, a fim de melhorar sua qualidade. As duplicações são removidas, as informações redundantes são excluídas e um formato consistente é aplicado a todos os registros. Normalmente, isso não deve requerer quaisquer mudanças nos programas associados.

- Extensão de dados: Nessa caso, os dados e programas associados passam pelo processo de reengenharia, a fim de eliminar os limites no processamento de dados. Isso pode exigir mudanças nos programas para aumentar a extensão de campos, modificar limites superiores nas tabelas e assim por diante. Os dados em si podem precisar ser reescritos e limpos, para que reflitam as mudanças no programa.

- Migração de dados: Nesse caso, ocorre a migração dos dados para o controle de um moderno sistema de gerenciamento de banco de dados. Os dados podem ser armazenados em arquivos separados ou ser gerenciados por um tipo de sistema de gerenciamento de banco de dados mais antigos, como na figura seguinte:


27

Figura 15 – Migração de dados

5.7.2. PROBLEMAS COM DADOS

- Problemas com a denominação dos dados: Os nomes podem ser obscuros e de difícil

compreensão. O mesmo nome pode ser usado em diferentes programas com significados Diferentes.

- Problemas com e extensão de campos: Para o mesmo item podem ser designadas diferentes extensões, em diferentes programas.

- Problemas com a organização de registros: Os registros que representam a mesma entidade podem ser organizados diferentemente, em diferentes programas l Código com baixa legibilidade.

- Nenhum dicionário de dados.


28

6. METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

O termo metodologia, apesar de ser amplamente utilizado, não possui uma definição amplamente aceita. A nível geral, entende-se como metodologia uma série recomendada de passos e procedimentos que devem ser seguidos para obter-se o desenvolvimento de um sistema de informação (Yourdon, 1995, p. 97).

De acordo com Avison e Fitzgerald (1997, p.10), é o conjunto formado por procedimentos, técnicas, ferramentas e documentação que auxiliará os responsáveis pelo desenvolvimento de sistemas em seus esforços na implementação de um novo sistema de informação. Uma metodologia consistirá de fases, cada uma consistindo de sub-fases, que orientarão estes responsáveis na escolha das técnicas que deverão ser mais apropriadas a cada estágio do projeto e também auxiliá-los a planejar, gerenciar, controlar e avaliar o projeto do sistema de informação.

Maddison apud Avison e Fitzgerald (1997, p.418) define metodologia como sendo um

conjunto recomendado de filosofias, fases, procedimentos, técnicas, regras, ferramentas, documentação, gerenciamento e treinamento para o desenvolvimentos de um sistema de informação. Verifica-se neste conceito a inclusão, entre outros, de filosofias que são as teorias e crenças que norteiam os objetivos e procedimentos de uma metodologia. 6.1. Técnicas e Ferramentas

Técnicas e ferramentas caracterizam as metodologias. Uma técnica é um modo de fazer uma atividade particular no processo de desenvolvimento de sistemas de informação e que podem vir a ser utilizadas por várias metodologias. Cada técnica pode envolver o uso de uma ou mais ferramentas que representam alguns dos artefatos usados no desenvolvimento de sistemas de informação.

Ferramentas geralmente são automatizadas, isto é, são recursos computacionais - softwares que auxiliam neste desenvolvimento (McDermid, 1990).

Verifica-se que muitas técnicas são usadas em várias metodologias apesar deste fato não significar que elas sejam adequadas a todas as metodologias existentes. Geralmente são utilizadas em determinadas metodologias voltando-se para diferentes partes do processo de desenvolvimento, diferentes propósitos ou a diferentes objetos. 6.2. Componentes de uma Metodologia Pode-se dizer que uma metodologia desenvolve alguns pontos chave: - Um conjunto de conceitos de modelagem;

- Um conjunto de visões e notações que permite que os conceitos sejam apresentados e consequentemente avaliados e modificados;

- Um processo iterativo para a construção dos modelos; e - Um conjunto de dicas para o desenvolvimento do projeto.


29

A modelagem delimita modelos que são representações formais dos sistemas em um nível de abstração. Por exemplo, um método de Orientação a Objetos utiliza-se os conceitos de classes, objetos, herança, etc.

A Notação representa a visualização gráfica dos conceitos de modelagem do método. O mesmo conceito pode ser apresentado de diferentes formas. A notação para classes: – na OMT era retângulos, Booch(nuvem), Coad-Yourdon (retângulos com cantos arredondados); Atualmente a notação padrão para representar modelos orientados a objeto é a Unified Modeling Language (UML - Linguagem de Modelagem Unificada).

Um processo é o “caminho” que deve ser seguido para o efetivo desenvolvimento do software. O processo descreve a estrutura para o desenvolvimento do software, descrevendo os artefatos a serem produzidos e os passos que devem ser seguidos para produzi-los.

De forma resumida uma metodologia de desenvolvimento de software possui uma série de componentes que se completam para permitir o efetivo desenvolvimento de software;

- Conceitos; - Notação; - Processo; - Dicas;

6.3. Vantagens do uso de uma Metodologia É importante ressaltar que se não houver vantagens não há motivos para se utilizar uma metodologia. Abaixo alguns argumentos a favor do uso de uma metodologia de desenvolvimento de sistemas:

- Ganho de Produtividade: É eficaz em definir o problema a ser resolvido, esclarecendo

para toda equipe através da documentação gerada, todo o escopo da solução e seus aspectos relevantes.

- Documentação: Registra a memória do trabalho que está sendo desenvolvido, servindo para futuras revisões e implementações.

- Padronização: Ao utilizar os padrões citados, elimina-se os projetos em que só o fulano sabe como funciona. O conhecimento registrado é entendido por qualquer outro técnico habilitado da Empresa.

- Organização: Seguir a metodologia substitui o processo artesanal e empírico de construção de sistemas. 6.4. Metodologias

O principal representante do grupo das metodologias rigorosas é o UDP – Unified Development Process (Processo de Desenvolvimento Unificado), descrito nos primeiros livros dos três amigos (Jacobson, Booch, Rumbaugh), na década de 90. Um Processo Unificado traz todas as atividades relacionadas a construção de um software.

Uma das versões comerciais é conhecida como RUP, um Processo Unificado construído


30

pela Rational e vendido como um produto. O OpenUP também é um Processo Unificado, porém open source. Em ambos os casos, grande parte da documentação utiliza a notação UML (Unified

Modeling Language). 6.5. RUP (Rational Unified Process)

Desenvolvida na década de 70 e aperfeiçoada desde então, o RUP é a metodologia da companhia norte-americana Rational (adquirida pela IBM em 2002), chamada Rational Unified Process (RUP®).

O RUP é um processo de desenvolvimento de software que possui um conjunto completo de atividades que define quem faz o que, quando e como. Usa uma abordagem de orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML para ilustrar os processos em ação.

O objetivo do RUP é assegurar uma produção de alta qualidade de software, que realiza a necessidade do usuário seguindo prazos e orçamento.

Uma de suas principais características é o fato de ser Iterativo e Incremental1. Isto significa que ele utiliza pequenos ciclos de projeto (mini-projetos) que correspondem à uma iteração e que resultam em um incremento no software.

Representado graficamente, o RUP possui duas dimensões, que representam as fases e as disciplinas, conforme figura 16.

Figura 16 – Arquitetura do RUP

O eixo horizontal (fases) representa o tempo, o aspecto dinâmico do processo e é

expressa em termos de fases, iterações e marcos. Uma iteração é descrita como uma passagem por todas as disciplinas. A partir da fase de elaboração, cada iteração deve produzir um módulo do sistema. O projeto é concluído quando todos os módulos forem produzidos e interconectados

1 Iterações referem-se a passos e incrementos à evolução do produto.


31

como peças (componentes) de um quebra cabeça (sistema). É assim que funciona o “processo iterativo e incremental” do RUP.

A cada iteração deve ser obtido um release executável, o qual é testado e aprovado pelo usuário. Dessa forma, o risco é minimizado, pois eventuais falhas são identificadas já nas fases iniciais do projeto.

O eixo vertical representa as disciplinas, o aspecto estático do processo, e é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.

Para compreender a figura, observa-se que a disciplina de requisitos, por exemplo, requer mais trabalho nas fases iniciais (iniciação e elaboração), enquanto a de implantação praticamente não existe antes das fases finais (construção e transição).

O ciclo de vida de software do RUP é dividido em quatro fases sequenciais: Iniciação (ou Concepção), Elaboração, Construção e Transição – cada uma concluída por um marco principal.

Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

a) Fase de Iniciação: A meta da fase de iniciação é atingir o consenso entre todos os

envolvidos sobre os objetivos do ciclo de vida do projeto. Nesse sentido, as atividades básicas envolvem:

- Formular o escopo do projeto: Capturar o contexto, bem como os requisitos e as restrições mais importantes, para que seja possível elaborar critérios de aceitação para o produto final.

- Preparar o ambiente para o projeto, avaliar o projeto e a organização, selecionar ferramentas e decidir quais partes do processo devem ser melhoradas.

b) Fase de Elaboração: A meta da Fase de Elaboração é criar a linha básica (baseline)

para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da Fase de Construção. Deve-se decidir basicamente sobre a organização do sistema, a seleção dos elementos e seu comportamento.

c) Fase de Construção: A meta da Fase de Construção é esclarecer os requisitos

restantes e concluir o desenvolvimento do sistema com base na arquitetura definida. d) Fase de Transição: O RUP possui ainda a fase de Transição, que consiste de várias

atividades com o objetivo de implantar o sistema no ambiente do usuário.

A parte estática (disciplinas) do RUP, é descrita através dos conceitos de papéis, atividades, artefatos e fluxos de trabalho:

- Papeis: define o comportamento e as responsabilidades assumidas por uma pessoa ou um conjunto de pessoas trabalhando em equipe. Exemplo: Analista de sistema, projetista, programador.

- Atividades: tarefa que um indivíduo executa quando está exercendo um determinado


32

papel e produz um resultado importante para o contexto do projeto. Exemplo: Planejar uma iteração, definir caso de uso e atores, rever o projeto, executar teste de performance.

- Artefatos: pedaço de informação que é produzido, modificado ou utilizado em um processo. Exemplo: Modelo de caso de uso, código fonte, documentos, executáveis.

- Fluxo de Trabalho: sequências de atividades que são executadas para a produção de um resultado valioso para o projeto. Exemplo: Diagrama de Sequência, diagrama de colaboração.

Figura 17 – Papeis e atividades

As disciplinas são a divisão dos conteúdos do método por especificidades de ações e tarefas dentro da Engenharia de Software:

- Modelagem de Negócios: Traz um entendimento comum sobre o Processo atual da Organização. Permite projetar novos processos para auxiliarem o novo processo criado com a implantação do seu sistema e documenta o modelo de atuação da organização para auxiliar na construção do sistema.

- Gerência de Requisitos: Estabelece uma concordância entre fornecedor e cliente sobre o sistema a ser desenvolvido, além de definir o escopo do sistema. Provê detalhes do que deve ser produzido ao time e definir as interfaces do sistema.

- Análise e Design: Etapa em que os requisitos são transformados em uma linguagem mais detalhada do sistema ser produzido. Desenvolve a arquitetura do sistema e permite adaptar o design produzido a linguagem e ambiente do sistema;

- Implementação: Realiza-se a organização da codificação em camadas. Implementa-se classes e objetos que expressam os requisitos. Nesta fase é preciso testar os componentes desenvolvidos como unidades (teste unitários).

- Implantação: Descreve as atividades a serem desenvolvidas para a implantação do novo sistema no ambiente da organização-alvo (cliente). Desenvolve manuais de apoio aos usuários do novo sistema. - Gerência de Configuração e Mudança: Mantém a integridade do sistema fornecendo um ambiente estável para o desenvolvimento e utilização do produto. Avalia e restringe solicitações de mudança fora das políticas do Projeto, assim como avalia o impacto das mudanças. - Gerenciamento do Projeto: Fornece um framework para gerenciar projetos de software, fornecendo as melhores práticas para planejar, executar, monitorar e encerrar projetos, bem como


33

fornece um framework de práticas para gerenciar riscos. - Ambiente: Fornece um ambiente de apoio a equipe de desenvolvimento de software, com padrões de processos, ferramentas e melhores práticas. Fornece ainda um ambiente de apoio para todas as demais disciplinas.

Com a utilização de uma metodologia de desenvolvimento de software como o RUP, é possível obter:

- Qualidade de software; - Produtividade no desenvolvimento, operação e manutenção de software;

- Controle sobre desenvolvimento dentro de custos, prazos e níveis de qualidade desejados;

- Estimativa de prazos e custos com maior precisão. Com o intuito de enriquecer o conteúdo deste capítulo recomenda-se uma pesquisa sobre a adoção de Metodologias de Desenvolvimento de Sistemas, como o único instrumento de formalização do desenvolvimento. Sugestões: - http://governanca.trt11.jus.br/wp-content/uploads/Doc20100921141640.pdf - http://mds.ancine.gov.br - http://www.susep.gov.br/menu/download/tisusep/MGDS_SUSEP_v1.0.pdf - http://www.tjdft.jus.br/transparencia/desenvolvimento-de-software/Metodologia%20SUDES - http://www.sisp.gov.br/pswsisp/wiki/download/file/guiaPsw


34

7. FERRAMENTAS CASE (Front-end-Case, Back-end-Case e I-Case)

As Ferramentas CASE (Computer-Aided Software Engineering) constituem uma categoria de software que tem por finalidade auxiliar as atividades de engenharia de software, o que envolve recursos para gerência, análise de requisitos, modelagem, programação, testes e manutenção de software.

As vantagens em se utilizar uma Ferramenta CASE é o aumento da produtividade, melhor qualidade, diminuição dos custos, melhor gerenciamento e a grande facilidade de manutenção. Por outro lado, deve analisar como desvantagens a incompatibilidade entre ferramentas e a necessidade de treinamento para sua utilização, visto que não basta conhecer a linguagem de programação.

Cada ferramenta tem propósitos diferentes, fornece serviços diferentes, mas possuem algumas características em comum.

É importante ressaltar que as ferramentas CASE são usadas em conjunto com um modelo de processo adotado. Se for escolhida uma ferramenta completa, pode passar por quase todos os passos do desenvolvimento de software. Sendo assim, são usadas como complemento às boas práticas de Engenharia de Software. Contudo, elas não substituem uma metodologia de desenvolvimento de software sólida. 7.1. Classificação das Ferramentas CASE

- Front End ou Upper CASE: apoiam as etapas iniciais de criação dos sistemas: as fases de planejamento, análise e projeto do programa ou aplicação.

- Back End ou Lower CASE: dão apoio à parte física, isto é, a codificação testes e manutenção da aplicação.

- I-CASE ou Integrated CASE: classifica os produtos que cobrem todo o ciclo de vida do software, desde os requisitos do sistema até o controle final da qualidade.

Outras classificação adotada, divide as ferramentas em: - Horizontais: São utilizados durante todo o processo de desenvolvimento de software. - Verticais: São específicas para uma disciplina de software.

As Ferramentas CASE podem ainda ser agrupadas por funções, como define Pressman:

- Processos de negócio - Planejamento de projeto - Análise de Riscos - Rastreamento de Requisitos - IDE’s - Gerenciamento de BD’s - Análise Estática - Análise Dinâmica


35

Um dos componentes indispensáveis de uma ferramenta CASE é a modelagem visual, ou

seja, a possibilidade de representar, através de modelos gráficos. As ferramentas CASE automatizam uma grande variedade de tarefas: Geração de

documentação, Testes, Geração de código, Geração de Relatórios para acompanhamento do trabalho entre outras atividades. Um exemplo é o DBDesigner, uma ferramenta CASE de código livre que serve para a modelagem de dados, mais especificamente para a elaboração de diagramas MER (Modelo Entidade Relacionamento). Dentre as suas principais vantagens podemos citar a fácil geração de código SQL do modelo criado, a separação dos modelos Físico e Lógico, a sua simples interface gráfica e a sua portabilidade.

Os Ambientes de Desenvolvimento Integrado (IDE’s) têm maior destaque e suportam: - Editor - Compilador - Debug - Geração de código - Ferramentas de Modelagem - Deploy - Testes automatizados - Refatoração

7.2. Norma ISO/IEC 14102 – Avaliação e Seleção de Ferramentas CASE O objetivo desta norma é tratar a avaliação e seleção de ferramentas CASE, cobrindo parcial ou completamente o ciclo de vida da engenharia de software. Estabelece processos e atividades a serem aplicadas na avaliação de ferramentas e na seleção da ferramenta mais apropriada entre várias candidatas. Estes processos são genéricos e as organizações devem adaptá-los de acordo com suas necessidades. Os processos de avaliação e seleção de ferramentas CASE devem ser inseridos no amplo contexto do processo de adoção de tecnologia da organização. A ISO/IEC 14102 lista as funções e características das ferramentas CASE. As ferramentas CASE possuem diversas funções e características que determinam a sua atuação no processo de software e na melhor adaptação de acordo com as características da organização.

Devido à atuação das ferramentas CASE em diversas fases do ciclo de vida de desenvolvimento de software, as funções foram agrupadas para facilitar a sua classificação e avaliação.

- Funções e características relacionadas ao processo de ciclo de vida: Conjunto de atributos que evidenciam a existência de um conjunto de funções e suas propriedades especificadas para apoiar o uso de ferramentas CASE, relacionado ao processo e atividades do ciclo de vida de software;

- Funções e características relacionadas ao uso da ferramenta CASE: Conjunto de atributos que relacionam as funções e características da ferramenta ao seu ambiente e aos projetos que irão apoiar, como por exemplo, ambiente operacional que a ferramenta opera,


36

limitações quanto à integração com outras ferramentas, linguagens de desenvolvimento apoiadas pela ferramenta;

- Funções e características gerais de qualidade: Conjunto de atributos que são relacionados às funções e características voltadas à qualidade, descritas no padrão ISO/IEC 9126, norma que está sendo descontinuada. São elas: Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade;

- Funções e características gerais não relacionadas à qualidade: Conjunto de atributos genéricos que tratam de aspectos relacionados à própria ferramenta e ao desenvolvedor/fornecedor, como por exemplo, custos de licenças, suportes, certificações do produto, etc. 8. BIBIOGRAFIA BÁSICA PRESSMAN, R. S. Engenharia de Software. São Paulo. Makron Books, 2006. SOMMERVILLE, Ian. Engenharia de Software - Ed. Prentice Hall, 2007. RUP. Disponível em http://www.wthreex.com/rup/portugues/index.htm Norma ISO/IEC 14102

Documents

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar · Software é um programa de computador e documentação associada. ... às técnicas de teste de software (até porque o