Engenharia de Software

RESUMO INFORMATIVO DE ENGENHARIA DE SOFTWARE

PARTE I

Referncias bibliogrficas: 1. Pressman, Roger S. Engenharia de Software MAKRON Books.

Unidade I Software e Engenharia de Software

1- Introduo.
O software ultrapassou o hardware como elemento chave de um sistema de computao. No incio, o software era agregado ao se adquirir uma mquina. A popularizao e a facilidade em se adquirir um produto de hardware de boa qualidade, fizeram com que o software fosse mais exigido. A qualidade do software passou a ser mais importante. Assim, o que era feito especificamente para uma determinada empresa por profissionais prprios ou contratados e atendia a essa empresa ou a um grupo restrito de empresas, passou a ser produzido por empresas dedicadas a determinados produtos e distribudos em larga escala, criando um mercado prprio, onde a qualidade do software o diferencial.

1.1 - A Importncia do Software. Maior Poder de Avanos da Microeletrnica Computao a Custo Baixo

Assombrosa Qualidade de Armazenamento e Processamento

O Software o Mecanismo que Possibilita Aproveitar e dar Vazo a esse Potencial 1.2 - O Papel Evolutivo do Software.

1 Era

2 Era

3 Era

4 Era SISTEMAS DE DESK-TOP PODEROSOS TECNOLOGIAS

SISTEMAS DISTRIBUDOS INTELIGNCIA ORIENTAO A BATCH TEMPO REAL DISTRIBUO LIMITADA SOFTWARE CUSTOMIZADO COMPUTADOR VALVULADO BANCO DE DADOS IMPACTO DE PRODUTOS DE SOFTWARE COMPUTADOR COMPUTADOR TRANSISTORIZADO COM CIRCUITOS IMPRESSOS CONSUMO MULTIUSURIO HARDWARE DE BAIXO CUSTO

ORIENTADAS A OBJETOS SISTEMAS ESPECIALISTAS REDES NEURAIS ARTIFICIAIS COMPUTAO PARALELA MICROCOMPUTADORES

1950

1960

1970

1980

2000

Enquanto nos caminhamos para a 5 era, os problemas relacionados ao desenvolvimento do software continuam a intensificar, tais como: A sofisticao do software ultrapassou nossa capacidade de extrair todo o

potencial oferecido pelo hardware;

Nossa capacidade de desenvolvimento no consegue acompanhar o ritmo de Quando estamos terminando um produto, novos componentes de hardware e Nossa capacidade de manter os programas existentes ameaada por

demanda de novos programas; software surgem, tornando os recursos do nosso produto quase que ultrapassados; projetos ruins e recursos inadequados. Obs.: Nosso estudo visa conhecer e diminuir os problemas do desenvolvimento, tornando-o menos penoso e atravs do uso de prticas de Engenharia. Atualmente, as empresas esto terceirizando os servios de computao, reduzindo pessoal e contratando os servios de empresas especializadas. Deste modo, esto fazendo o chamado outsorcing. Todo o desenvolvimento e a manuteno de seus sistemas passam para empresas terceirizadas, atravs de contratos de servios.

1.3 - Caractersticas e Componentes do Software.

O software desenvolvido ou projetado por engenharia, no manufaturado no A maior qualidade de software diretamente proporcional a um bom projeto; Os custos de software so concentrados em trabalho de Engenharia, no so geridos como um projeto de manufatura; O conceito de Fbrica de Software implica em conceitos diferentes dos conceitos usados na manufatura do harware. O conceito de Fbrica de Software recomenda o uso de ferramentas automatizadas para o desenvolvimento de software. O software no se desgasta. O hardware apresenta um ciclo de falhas grande no incio, at que entre em um estgio de amadurecimento. Aps esta fase, as falhas diminuem durante um certo espao de tempo, at que volte a apresentar falhas de desgaste, conforme a Figura A;

sentido clssico (no processo mecnico).

O software no sujeito a falhas de desgaste como o hardware. Como na figura B, onde a correo de erros iniciais diminui as falhas.

O software no se desgasta, mas, se deteriora em funo da manuteno que recebe durante sua vida. Durante o processo de manuteno, novos defeitos so introduzidos criando os picos no grfico. A figura C, mostra a realidade das falhas do software.

Quando um determinado componente de hardware se desgasta, este facilmente substitudo por uma nova peca, mas, no caso do software o temos um problema bem mais complexo.

A maioria dos sistemas feita sob medida em vez de ser montado de componentes existentes. No caso do hardware, um projetista cria o circuito e depois recorre a um catlogo onde ir especificar os componentes e ento o hardware pode ser encomendado. Infelizmente no caso do software, no podemos nos aproveitar deste luxo. Com pouqussimas excees, no existem catlogos de partes de software para escolhermos os componentes. Ao encomendarmos um software no podemos fazer pedidos de componentes para montarmos posteriormente. Apesar de tentarmos a reutilizao de partes de programas, poucas so as funes hoje em dia que podemos reutilizar. Este processo de componentes ainda necessita de maturidade e de um bom projeto para que possamos ter compatibilidade. Atualmente, o custo de hardware muito menor que o custo do hardware. O software passou a ser o item particular de maior custo. As prticas de Engenharia de Software tentam minimizar as dificuldades de se responder a perguntas como: Por que demora tanto tempo para que os programas sejam concludos? Por que os custos so to elevados?

Por que no descobrimos todos os erros antes de entregarmos o software aos Por que temos dificuldade em medir o progresso enquanto o software est

nossos clientes? sendo desenvolvido?

1.3.1 - Componentes do software.

Os Componentes de software so criados por uma srie de converses que mapeiam as exigncias do cliente para um sistema de computador na forma de um cdigo executvel (cdigo de mquina), capaz de atender s necessidades do cliente. A reusabilidade uma caracterstica importante dos componentes de software de alta qualidade. A reusabilidade um componente de software que deve ser bem projetado e muito bem implementado, de forma que sua reutilizao seja fcil em vrios sistemas diferentes. Antigamente levvamos em conta apenas reutilizao atravs de bibliotecas de funes (apenas o algoritmo). Atualmente, alm do algoritmo, devemos nos preocupar com os dados em um nico pacote. Assim, em vez de termos funes como antigamente passamos a ter classes e objetos que podem ser reutilizados.

So criados por meio de uma srie de converses que mapeiam as exigncias do cliente para cdigo executvel em mquina. O MODELO DAS EXIGNCIAS

PROJETO

CODIFICAO EM UMA DETERMINADA LINGUAGEM

As Linguagens Atualmente em Uso So: Linguagens de Mquina Assembly (especficas para cada famlia de processadores). Linguagens de Alto Nvel: Pascal, C, ADA, C++, Object Pascal, Eiffel, LISP, PROLOG, Delphi, Visual Basic, Java, etc... No Procedimentais: Linguagens de Banco de Dados.

1.3.2 - Aplicaes do Software.

Desenvolver categorias genricas para as aplicaes de software uma tarefa difcil, medida que a complexidade do software aumenta. Mas, podemos relacionar a maioria dos softwares, de acordo com as categorias a seguir: SOFTWARE BSICO. Tem como

uma coleo de programas escritos para dar apoio a outros programas. caracterstica maior interao como hardware. Exemplos: Compiladores, Editores de Textos, Sistemas Operacionais, etc. SOFTWARE DE TEMPO REAL.

um software que monitora / analisa / controla eventos do mundo real. Responde dentro de restries de tempo estritas. Normalmente obtm informaes por sensores ou controlados, interpreta e formata uma sada, s vezes suas sadas podem ser atravs de alertas e alarmes. Exemplos: Sistemas de controle de vo e de sinalizao de trnsito. SOFTWARE COMERCIAL.

Esta sem dvida a maior rea de desenvolvimento de software. Tem como caracterstica maior, o fato de serem oferecidas diversas solues para se resolver o mesmo problema. Deste modo, faz-se necessrio avaliar cada produto para que seja feita a compra daquele que melhor lhe atender. Exemplos: Folhas de pagamento, contas a pagar e a receber, estoques, evoluindo para MIS - operaes comerciais e de apoio deciso.

SOFTWARE CIENTFICO E DE ENGENHARIA.

Caracteriza-se por softwares que processam funes matemticas complexas. So utilizados na Engenharia e em processamento Cientficos. Exemplos: Sistemas de astronomia, sistema de controle da dinmica orbital de naves espaciais, sistemas de manufatura automatizada, biologia molecular, etc... Obs.: Os sistemas de Cad, at ento uma exclusividade desta categoria comeam a adquirir caractersticas de Tempo Real e de Sistemas Operacionais. SOFTWARE EMBUTIDO.

Produtos dotados de inteligncia tm se tornado comuns no mercado industrial de consumo. Caracteriza-se por estar contido em memrias ROM (Read-Only) e usado para controlar produtos e sistemas industriais e de consumo. Normalmente se limitam a funes limitadas e particulares. Exemplos: Funes digitais em automveis (controle de combustvel, sistema de freios, controle de teclado para fornos microondas, sistemas de freios, etc). SOFTWARE DE COMPUTADOR PESSOAL.

Atualmente o mercado mais efervescente. Tem como maior caracterstica uma busca pela melhoria das interfaces entre homem / mquina, tornando os softwares desta categoria cada vez mais fceis de utilizao. Fez surgir inmeras empresas que se tornaram muito grandes e produzem um faturamento gigantesco. Exemplo: Processamento de textos, planilhas eletrnicas, gerenciador de dados, aplicaes financeiras pessoais e comerciais, etc...

SOFTWARE DE INTELIGNCIA ARTIFICIAL.

Caracteriza-se pelo uso de algoritmos no-numricos para resolver problemas complexos que no podem ser resolvidos diretamente pela computao convencional e com solues atravs de anlise direta. Conhecidos como software baseado em conhecimento. Exemplos; Sistemas de reconhecimento de padres (voz, digitais, ris, etc); Redes Neurais, para simular a inteligncia humana; Lgica Fuzzy para auxlio tomada decises.

1.3.3 - Problemas e Causas da Crise do Software.

As estimativas de prazo e de custo so freqentemente imprecisas; Produtividade das pessoas da rea de software no tem acompanhado a

demanda por servios; A produtividade das pessoas da rea de software no tem acompanhado a

demanda por servios; A qualidade de software menos que a adequado; No se dedica tempo coleta de dados ( erra-se no planejamento ); Insatisfao do cliente com o sistema pronto ( comunicao entre o cliente e o

desenvolvedor fraca); Dificuldade em manter o software existente.

ANALISTA

USURIO

No Incio tudo tranqilo e os problemas so facilmente resolvidos pelo grupo.

Depois, podemos necessitar de mediadores para resolver os problemas.

CAUSAS

Falhas

dos

profissionais

de

desenvolvimento

que

tinham

como

experincia apenas pouco mais de 40 anos; O software um elemento lgico e assim seu sucesso medido apenas

por esta qualidade, ao contrrio de um manufaturado, onde sua qualidade medida por vrios fatores distintos; Falhas podem no ser detectadas em testes e aparecerem apenas durante

o pleno uso. Neste caso devemos efetuar uma manuteno que muitas vezes acarreta correes e modificaes de projeto; Profissionais de informtica com pouco treinamento formal em tcnicas

para desenvolvimento de softwares. As pessoas de desenvolvimento tem como maior desafio natureza lgica do software. Afinal de contas nossa tarefa a de comunicao com uma inteligncia aliengena; Gerentes de nvel mdio e superior sem background em software recebem

a tarefa pelo seu desenvolvimento; Tudo deve ser feito para ontem; A ltima gerao era chamada de programadores, mas, a atual prefere ser

denominada Engenheiros de Software. Falta treinamento formal em novas tcnicas de Engenharia de Software. As pessoas que poderiam se beneficiar das no hardware, com um potencial cada vez maior, resistem a introdues de mudanas.

1.4 Mitos e Realidade a respeito do desenvolvimento de Software.

Mito: Se j temos manuais de padres e procedimentos, meu pessoal j possui todo o necessrio. Realidade: Esses manuais sero usados? Os profissionais tem conhecimento de sua existncia? Ele est atualizado e completo? Mito: A equipe possui ferramentas de desenvolvimento e computadores de ltima gerao. Realidade: Precisamos de mais do que apenas o ltimo modelo de computador. As ferramentas CASE so muito mais importantes do que o hardware para se obter boa qualidade e produtividade. Mito: Se temos atrasos no desenvolvimento, podemos simplesmente adicionar mais recursos para acelerar o desenvolvimento? Realidade: Software no um projeto comum de manufatura. Adio de novos recursos ocasionar mais atraso. As novas pessoas cairo de pra-quedas em projeto e precisaro de muita ajuda at que possam ter condies de produzir. Os atuais desenvolvedores tero de dedicar horas de trabalho ensinar e detalhar o projeto. Novos recursos, apenas de forma planejada e ordenada. Mito: Para iniciarmos o projeto, necessitamos apenas de comear a escrever programas e deixar os detalhes para mais tarde. Realidade: Uma definio inicial ruim catastrfica para o desenvolvimento de software. um das maiores causas do fracasso. O sucesso depende diretamente da qualidade do detalhamento.

Mito: Os requisitos do software podem mudar e as mudanas podem ser facilmente acomodadas. Realidade: Os requisitos de software realmente se modificam, mas, as mudanas ao longo do tempo ou durante o projeto do software podem ocasionar custos extras e a necessidade de novos recursos, onerando o projeto inicial.

Mitos do profissional:
Mito: Quando colocamos o software em funcionamento, este est completo. Realidade: De 50 a 70% do esforo de desenvolvimento de software feito aps a primeira entrega. Mito: S poderei avaliar a qualidade quando o sistema estiver funcionando. Realidade: A reviso tcnica formal vital para filtrar a qualidade do software. Mito: A nica coisa a ser entregue em um projeto bem sucedido, o programa funcionando. Realidade: O programa funcionando importantssimo, mas, a documentao primordial no momento da manuteno.

1.5 Paradigmas da Engenharia de Software. 1.5.1 Definio de Engenharia de Software.

O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais. Fritz Bauer

 uma disciplina que integra mtodos, ferramentas e procedimentos para o desenvolvimento de software de computador.

mtodos: envolvem um amplo conjunto de tarefas que incluem: planejamento estrutura de dados, especificao e codificao de programas, teste e manuteno. ferramentas : CASE- Computer-Aided Software Engineering

estimativa de projeto, anlise de requisitos de software e de sistemas, projeto de

procedimentos : constituem o elo de ligao que mantm juntos os mtodos e as ferramentas para desenvolvimento do software.

1.5.2 Ciclo Clssico da Engenharia de Software.

1.5.2.1 Definio da engenharia de software

Fritz Bauer Estabelecimento e uso de slidos princpios de engenharia para que se possa obter um software que seja confivel e que funcione adequadamente, e de forma econmica, em determinado hardware.

1.5.2.2 Ciclo de um sistema

E n g e n h a r ia d e S o ftw a r e A n lis e d e S is te m a s

P r o je to C o d ific a o T e s te M a n u te n o

Anlise e Engenharia de Sistemas. Como o software faz parte de um sistema mais complexo, o trabalho comea se estabelecendo os requisitos para os elementos que comporo o sistema e a atribuio de certos subconjuntos dos requisitos ao software. Essa viso importantssima, principalmente quando o sistema deve fazer interface com outros elementos, como hardware, pessoas e bases de dados. Esta etapa envolve a coleta dos requisitos em nvel do sistema, com uma pequena parte de projeto e anlise de alto nvel. Anlise de Requisitos de Software. A coleta dos requisitos mais intensa e concentra-se no software. O engenheiro de software deve compreender o domnio da informao para o software, a funo, o desempenho e as interfaces necessrias. Os requisitos so documentos e devem ser vistos e discutidos com o cliente. Projeto. um processo de mltiplos passos, concentrando-se em 4 atributos principais: Estrutura de Dados;

Arquitetura de Software; Detalhes Procedimentais; Caracterizao das Interfaces.

O processo de construo do projeto traduz as exigncias em representaes que podem ser avaliadas quanto qualidade, mesmo antes da iniciada a codificao. A documentao gerada faz parte da configurao do software. Codificao. O projeto deve ento ser traduzido para a mquina, atravs da criao dos programas. Quanto mais detalhado for o projeto, mais fcil torna-se a codificao, tornando-a mecanizada. Testes. O processo de testes concentra-se nos aspectos lgicos internos do software, tentando garantir que todas as instrues tenham sido testadas. Tambm so testadas as funcionalidades externas do software, para garantir que as entradas do sistema gerem sadas reais e corretas. Manuteno. Uma certeza temos, a de que o software sofrer mudanas. A nica exceo est nos softwares embutidos. Ocorrero mudanas pelas correes de erros, porque o software precisa de alguma adaptao a mudanas, por exigncia de novas funcionalidades feitas pelo cliente ou ainda em funo do desempenho. A manuteno de software implica na aplicao de todas as etapas do ciclo de vida novamente.

Paradigmas do Ciclo de Vida Clssico. Os projetos reais raramente seguem este fluxo seqencial. muito difcil que o cliente declare todas as exigncias explicitamente. Uma verso do software no estar disponvel at um ponto tardio do

cronograma, assim, um grave erro no pode ser detectado at uma reviso pelo cliente.

1.5.3 Prototipao
PROCESSO QUE CAPACITA O DESENVOLVEDOR A CRIAR UM MODELO DO SOFTWARE QUE SER IMPLEMENTADO.

Geralmente, o cliente define um conjunto de objetivos gerais para o software, mas, ainda no identificou os requisitos de entrada, processamento e sada devidamente detalhados. Em outros casos, difcil para o desenvolvedor ter certeza da eficincia de um algoritmo, da adaptao do software a um determinado Sistema Operacional ou at mesmo da integrao homem-mquina com o usurio. Nestes casos, uma abordagem de prototipao Engenharia de Software pode representar a melhor abordagem. Modelos de Prototipao: Um prottipo em papel ou um modelo baseado em mquina, retratando a Um prottipo de trabalho que implemente um subconjunto ou parte de uma Um programa j existente que implemente parte ou todas as requisies interao homem-mquina para facilitar o entendimento do usurio. funo exigida pelo software. exigidas, para que melhorias e novas caractersticas sejam implementadas.

Seqncia de eventos para o paradigma de prototipao.

Fim

Incio

Coleta e refinamento dos requisitos

Projeto Rpido

Engenharia do Produto Construo do Prottipo Refinamento do Produto Avaliao do Prottipo pelo Cliente

Como todas as abordagens, iniciamos pela coleta dos requisitos; O desenvolvedor e o cliente renem-se para definir os objetivos globais,

identificam as exigncias conhecidas e esboam as reas onde definies adicionais so necessrias, ocorrendo assim definio do projeto rpido. fina; O prottipo pode servir como o primeiro sistema. Este projeto leva a construo de um prottipo para ser avaliado pelo cliente e O software ento avaliado pelo cliente e o usurio; Aps a avaliao, o software ento refinado, ou feita chamada sintonia o usurio;

1.5.4 Modelo Espiral.

Direo

de

um

Software terminado.

Este modelo tenta abranger melhor as caractersticas tanto do ciclo de vida clssico, como o da prototipao. So quatro as principais atividades definidas nos quadrantes da figura: Planejamento, onde definimos os objetivos, alternativas e restries. Anlise de Riscos, responsvel pela anlise de alternativas e identificao e Engenharia, onde temos o desenvolvimento do produto em um segundo nvel.

resoluo dos riscos.

Avaliao do Cliente, caracterizando a avaliao dos resultados da

engenharia. - Durante o primeiro giro pelo espiral os objetivos, as alternativas e as restries so definidas e os riscos so identificados e analisados. Caso incertezas sejam encontradas, a prototipao pode ser usada no quadrante da engenharia para ajudar ao desenvolvedor e ao cliente. - A cada iterao ao redor do espiral, novas verses do software so geradas cada vez mais completas. - No quadrante de avaliao do cliente, so apresentadas sugestes para modificaes. Neste momento devemos verificar os riscos e decidir se devemos prosseguir ou no prosseguir caso estes riscos sejam muito grandes. - O modelo espiral atualmente a abordagem mais realista para o desenvolvimento de softwares em grande escala. - Este modelo usa a prototipao em qualquer etapa da evoluo do produto, sendo utilizado como um mecanismo de reduo de riscos. - um modelo mais recente e menos utilizado que o modelo clssico ou a prototipao.

1.5.5 Tcnicas de Quarta Gerao 4GT

C o le ta d e r e q u is ito s E s tr a t g ia d e p r o je to Im p le m e n ta o usan do 4 G L T e s te s

Permitem que o desenvolvedor especifique alguma caracterstica do software A ferramenta (CASE) gera automaticamente o cdigo-fonte, de acordo com as O paradigma de 4Gt da engenharia de software se concentra na capacidade de

em um nvel mais elevado; especificaes do desenvolvedor; se especificar o software em um nvel mais alto, prximo linguagem humana e esta seja especificada mquina sem maiores intervenes; Atualmente se concentram em: linguagens no-procedurais para consultas a bases de dados, interao e definio de telas, gerao de cdigos, capacidades grficas de alto nvel e de planilhas eletrnicas; Ainda so ferramentas feitas para domnios de aplicao muito especficas;

Em pequenas aplicaes, podemos passar da etapa de coleta das exigncias para a implementao, usando as 4GLs. Em projetos maiores necessrio utilizar uma estratgia de projeto para o sistema, mesmo em se tratando de uma 4GL. Evitando

assim, as mesmas dificuldades, tais como: m qualidade, m manuteno e m aceitao pelo cliente. Apesar das facilidades de gerao de um produto pelas 4GLs, testes cuidadosos devem ser executados, gerar a documentao adequada e efetuar as demais atividades da engenharia de software. Situao atual das 4GLs. Na maioria dos casos, o domnio de aplicao limita-se a aplicaes de

sistemas de informao comerciais. Especificamente para anlise de informaes e gerao de relatrios utilizando informaes de grandes bases de dados. Algumas novas ferramentas podem gerar esqueletos de sistemas. O esforo para se gerar software pequeno indica uma significativa

reduo de tempo. Em grandes sistemas, a nica reduo realmente obtida com a

economia de tempo pela eliminao das atividades de codificao.

1.5.6 Combinando Paradigmas.

Os paradigmas podem ser combinados de formas retirarmos a maior potencialidade de cada um deles em um mesmo projeto. Qualquer um dos paradigmas pode construir uma base onde os outros sero empregados.
OBTENO PRELIMINAR DOS REQUISITOS

ANLISE DE REQUISITOS

PROTOTIPAO

4GT

MODELO ESPIRAL

PROJETO PROTOTIPAO ENSIMA ITERAO CODIFICAO 4GT REALIZAO DE TESTES SISTEMA OPERACIONAL

4GT

MODELO ESPIRAL ENSIMA ITERAO

MANUTENO

A partir da obteno preliminar dos requisitos, qualquer dos caminhos indicados na figura acima pode ser tomado. As etapas do ciclo de vida clssico podem ser seguidas caso o sistema seja totalmente especificado no incio. Se os requisitos forem incertos, podemos utilizar um prottipo para definirmos mais completamente. Pode acontecer de o prottipo evoluir na direo do sistema de produo com um retorno ao ciclo de vida clssico para

teste. Podemos utilizar as tcnicas de quarta gerao tanto para implementar o prottipo ou implementar o sistema de produo durante a etapa de codificao. As tcnicas de quarta gerao podem ser usadas junto com o modelo espiral tanto para as etapas de prototipao quanto para a etapa de codificao.

1.5.7 Viso genrica da engenharia de software.

O processo de desenvolvimento possui trs fases: 1- Definio - Focaliza o qu. Tenta identificar as informaes a serem processadas, a funo, o desempenho desejado, as interfaces, as restries e os critrios exigidos pelo sistema. dividido em trs etapas: Anlise do Sistema: Atribui o papel que o software desempenhar. Planejamento do projeto de Software: Estabelece o escopo, analisa os riscos, os recursos alocados, os custos estimados e a programao de tarefas e trabalhos. Anlise de Requisitos: Definio mais detalhada do domnio da informao e da funo do software antes de se iniciar o trabalho.

FUNCES DO SISTEMA

PLANEJAMENTO DO PROJETO DE SOFTWARE

REVISO

ANLISE DE REQUISITOS OU PROTOTIPAO

REVISO

2- Fase de Desenvolvimento - Focaliza o Como O desenvolvedor deve definir o projeto da estrutura de dados e arquitetura do software, bem como os detalhes procedimentais, como o projeto ser traduzido para uma linguagem de programao e como os testes devem ser realizados. Trs passos especficos devem ocorrer: Projeto de Software: Traduz os requisitos do software de representaes grficas e/ou tabulares e/ou baseados em linguagens, que descrevem a estrutura de dados, a arquitetura, os procedimentos algortmicos e as caractersticas das interfaces. Codificao: As representaes devem ser convertidas em uma linguagem de programao convencional ou atravs de uma tcnica de quarta gerao, resultando nos cdigos a serem executados pelo computador. Realizao de teste no software: Logo que gerado o cdigo a ser executado pela mquina, devemos test-los para descobrir defeitos de funo, lgica e implementao.

PROJETO DE ARQUITETURA

REVISO

PROJETO PROCEDIMENTAL

REVISO

CODIFICAO

REVISO

3- Fase de Manuteno Focaliza as Mudanas Esto associadas correo de erros, adaptaes e novas ampliaes. Esta fase reaplica as fases de definio e desenvolvimento. So trs os tipos de mudanas: Correo: A manuteno corretiva corrige defeitos. Adaptao: Ao longo do tempo o ambiente de execuo de software pode sofrer mudanas e melhorias, seja atravs de upgrade de CPU e de perifricos ou pela mudana do sistema operacional. A manuteno adaptativa efetua modificaes no software para acomodar mudanas de ambiente.

Melhoramento Funcional:

Durante a utilizao de software muitas vezes o cliente ou

usurio vero a necessidade e se adicionar funes que traro novos benefcios. A manuteno perfectiva estende as exigncias funcionais originais.
TESTES DE UNIDADES, DE INTEGRAO E VALIDAO DEPURAO LIBERAO E DISTRIBUIO REVISO MANUTENO

Ferramentas Adequadas a cada Abordagem para o Desenvolvimento de Software

TCNICAS ANLISE TRADICIONAL ANLISE ESTRUTURADA ABORDAGENS FUNCIONAL FUNCIONAL DADOS FERRAMENTAS TEXTOS; FLUXOGRAMAS. DIAGRAMA DE FLUXO DE DADOS; DIAGRAMA DE ESTRUTURA DE DADOS; NORMALIZAO; ANALISE ESSENCIAL FUNCIONAL DADOS CONTROLE DICIONRIO DE DADOS. TABELAS; DIAGRAMA DADOS; DIAGRAMA DE ENTIDADERELACIONAMENTO; DIAGRAMA DE TRANSIO DE ESTADOS; E FLUXO DE