Engenharia de Software

Ana Paula Fukuda Ana02569@upis.br

Conhecimentos Chave
‡ O que é Engenharia de Software? ‡ Processos ± Como identificar qual o melhor a ser utilizado?

Questionamentos 
   

Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso do desenvolvimento de um software?

úteis e oportunos Arndt Von Staa.O que são Software ‡ São. código e procedimentos ‡ São desenvolvidos com o objetivo de instruir máquinas e pessoas no sentido da realização de um conjunto bem definido de tarefas de processamento de dados ‡ São instrumentos para alcançar um fim específico: transformar dados em resultados confiáveis. 1987 . componentes de sistemas automatizados ‡ São compostos por documentação. usualmente. dados.

Software Software é tanto um PRODUTO como um veículo para desenvolver um produto Software é desenvolvido por engenharia e não manufaturado Software não se desgasta. mas deteriora Atualmente. muitos softwares estão ainda em construção .Resumo .

CRISE DE SOFTWARE (aflição crônica???) .. O. ‡Sistemas Especialistas ‡Redes Neurais ‡Computação Paralela ‡Tecnologia Web ‡Segurança Os primeiros anos ‡Orientação batch ‡Distribuição limitada ‡Software customizado ‡1950 ‡1960 ‡1970 ‡1980 ‡1990 ‡2000 .. menor tamanho e custo A segunda era ‡Multiusuário ‡Tempo real ‡Banco de Dados ‡Software Houses A terceira era ‡Sistemas Distribuídos ‡³Inteligência´ embutida ‡Hardware de baixo custo ‡(PCs) ‡workstation ‡Impacto de consumo A quarta era ‡Tecnologia O.Evolução do Software Hardware: maior desempenho...

etapa ou evento decisivo ou crucial. momento. que continua indefinitivamente. Nos acompanha a mais de 30 anos. . Aflição Crônica Aflição ± Algo que causa dor ou sofrimento Crônica ± que dura um longo tempo ou retorna frequentemente.Crise de Software Crise ± um ponto decisivo no curso de algo.

não podemos avaliar com precisão a eficácia de novas ferramentas. métodos ou padrões´ . com resultados ruins´ ³Os prazos arrastam-se por meses´ ³Causa insatisfação para o cliente e falta de confiança´ ³Sem nenhuma indicação sólida de produtividade.Crise de Software Refere-se a um conjunto de problemas encontrados no desenvolvimento de software:(problemas não se limitam a softwares que não funcionam adequadamente) (1) As estimativas de prazo e de custo freqüentemente são imprecisas ³Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software´ ³Estimativas são feitas a olho.

Crise de Software (2) A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços ³Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente´ ³A comunicação entre o cliente e o desenvolvedor de software é muito fraca´ .

Crise de Software (3) A qualidade de software às vezes é menos que adequada Não uso de técnicas de teste sistemáticas e completas Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software (4) O software existente é muito difícil de manter A tarefa de manutenção devora o orçamento destinado ao software A facilidade de manutenção não foi enfatizada como um critério importante .

Crise de Software estimativas de prazo e de custo o produtividade das pessoas q qualidade de software q software difícil de manter o .

Conseqüentemente. próprio caráter do Software O software é um elemento de sistema lógico e não físico. o sucesso é medido pela qualidade de uma única entidade e não pela qualidade de muitas entidades manufaturadas O software não se desgasta. mas se deteriora!!! .Causas dos problemas associados à Crise de Software 1.

falhas das pessoas responsáveis pelo desenvolvimento de Software Gerentes sem nenhum background em software Os profissionais da área de software têm recebido pouco treinamento formal em novas técnicas para o desenvolvimento de software Resistência a mudanças. .Causas dos problemas associados à Crise de Software 2.

Causas dos problemas associados à Crise de Software 3. mitos do Software propagaram desinformação e confusão administrativos cliente profissional .

Isso não oferecerá ao meu pessoal tudo o que eles precisam saber? Realidade: Será que o manual é usado? Os profissionais sabem que ele existe? Ele reflete a prática moderna de desenvolvimento de software? Ele é completo? .Mitos do Software (administrativos) Já temos um manual repleto de padrões e procedimentos para a construção de software.

Realidade: É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade.Mitos do Software (administrativos) Meu pessoal tem ferramentas de desenvolvimento de software de última geração. As ferramentas CASE são mais importantes que computadores para se conseguir boa produtividade e qualidade. contudo a maioria dos desenvolvedores de SW ainda não as utiliza. . afinal lhes compramos os mais novos computadores.

Realidade: O desenvolvimento de software não é um processo mecânico igual à manufatura. . Pessoas podem ser acrescentadas. mas somente de uma forma planejada e bem coordenada. podemos adicionar mais programadores e tirar o atraso. Acrescentar pessoas em um projeto torna-o ainda mais atrasado.Mitos do Software (administrativos) Se nós estamos atrasados nos prazos.

interfaces. Realidade: Uma definição inicial ruim é a principal causa de fracassos dos esforços de desenvolvimento de software. restrições de projeto e critérios de validação. É fundamental uma descrição formal e detalhada do domínio da informação. função. desempenho. .podemos preencher os detalhes mais tarde.Mitos do Software (cliente) Uma declaração geral dos objetivos é suficiente para se começar a escrever programas .

mas as mudanças podem ser facilmente acomodadas. .Mitos do Software (cliente) Os requisitos de projeto modificam-se continuamente. porque o software é flexível. quando solicitada tardiamente num projeto. pode ser mais do que uma ordem de magnitude mais dispendiosa do que a mesma mudança solicitada nas fases iniciais. Realidade: Uma mudança.

100x .6x 60 .5 .Magnitude das mudanças FASES CUSTO DE MANUTENÇÃO DEFINIÇÃO DESENVOLVIMENTO MANUTENÇÃO 1x 1.

. Realidade: Os dados da indústria indicam que entre 50 e 70% de todo esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente.Mitos do Software (profissional) Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo.

eu não terei realmente nenhuma maneira de avaliar sua qualidade. Realidade: Um programa funcionando é somente uma parte de uma Configuração de Software que inclui todos os itens de informação produzidos durante a construção e manutenção do software.Mitos do Software (profissional) Enquanto não tiver o programa "funcionando". .

Questionamentos      Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso do desenvolvimento de um software? .

Qual é a Solução? Reconhecer os problemas e suas causas e desmascarar os mitos do software são os primeiros passos Métodos e Técnicas para disciplinar o processo de desenvolvimento do software .

Engenharia de Software: Definição Fritz Bauer .1969 ³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´ .

O estudo de abordagens e princípios a fim de obter economicamente softwares confiáveis e que executem de forma eficiente nas máquinas reais´ . disciplinada e quantificável para o desenvolvimento.Engenharia de Software: Definição IEEE. 1993 ³A aplicação de uma abordagem sistemática. operação e manutenção do software.

1987 ³O desenvolvimento e a aplicação de ciência. matemática. métodos e ferramentas para o desenvolvimento e a manutenção econômica de sotfware de qualidade preditível e controlável. operando de modo econômico em máquinas e ambientes reais´ .Engenharia de Software: Definição Arndt Von Staa. técnicas.

Engenharia de Software Uma disciplina da Ciência da Computação que oferece Métodos. Técnicas e Ferramentas para desenvolver e manter softwares com alta qualidade para a resolução de problemas (Anneliese Mayrhauser 1990) .

Ferramentas e Procedimentos Possibilitar ao gerente o controle do processo de desenvolvimento Oferecer ao profissional uma base para a construção de software de alta qualidade .abrange um conjunto de três elementos fundamentais: Métodos.

. ..Engenharia de Software MÉTODOS: MÉTODOS proporcionam os detalhes de ³como fazer´ para construir o software Envolvem um amplo conjunto de tarefas .

Engenharia de Software ferramentas: ferramentas dão suporte automatizado aos métodos. existem atualmente ferramentas para sustentar cada um dos métodos quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE .Computer Aided Software Engineering .

Engenharia de Software procedimentos: procedimentos constituem o elo de ligação entre os métodos e ferramentas seqüência em que os métodos serão aplicados produtos que se exige que sejam entregues controles que ajudam assegurar a qualidade e coordenar as alterações marcos de referência que possibilitam administrar o progresso do software. .

Engenharia de Software conjunto de etapas que envolve métodos ferramentas procedimentos Essas etapas são conhecidas como componentes de CICLO DE VIDA DE SOFTWARE ou Processo de Software .

treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos Procedimentos e métodos que definem o relacionamento de tarefas.Processo de Software Pessoas com habilidades. B A C D .

Visão Genérica PROCESSO DE CONSTRUÇÃO requisitos usuário requisitos atendidos PRODUTO PRODUTO COM QUALIDADE .Processo de Software .

Processo de Software PROCESSO DE SOFTWARE requisitos de usuário software produto desenvolvedor organização requisitos atendidos Processo de Desenvolvimento SOFTWARE PRODUTO SOFTWARE COM QUALIDADE .

Definição: Modelo Um modelo é uma simplificação da realidade. Planos de detalhes. ajudam a visualizar o sistema como desejamos que seja especificar a estrutura e comportamento guia para construção do sistema documentam as decisões tomadas . podem ser estruturais (organização do sistema) ou comportamentais (dinâmica do sistema) Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.

Conjunto de modelos independentes .Definição: Modelo Os melhores modelos estão relacionados à realidade (modelos simplificam a realidade) Nenhum modelo único é suficiente.

Modelo de desenvolvimento Concorrente Modelo de Montagem de Componentes Modelo de Métodos Formais Técnicas de 4a geração PSP« . 3. 9.State of the Art: 1. 6. 7. 8. Modelo de Prototipação odelos de Processo Modelo Seqüencial (ciclo de vida clássico) Modelo RAD (Rapid Application Development) Modelos Evolutivos Modelo Incremental e Espiral 5. 2. 4.

Escolha de um odelo de Processo: Qual o processo de desenvolvimento será adotado? Adequação do modelo de processo à aplicação Métodos e ferramentas a serem utilizados Controles e produtos que precisam ser entregues Características dos processos: Visibilidade. Qualidade. Apoio de Ferramentas. etc. Clareza. Produtividade. .

Para escolha de um Ciclo de Vida de Software: natureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues .

A passagem entre fases é formal. seqüencial ao desenvolvimento de software cada atividade é uma fase em separado. .Ciclo de Vida Clássico (Cascata) modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática.

Cascata Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção .

Atividades do Ciclo de Vida Clássico ENGENHARIA DE SISTEMAS Engenharia de Sistemas Análise de Requisitos  software faz parte de um sistema amplo Projeto Codificação Testes  envolve a coleta de requisitos em nível do sistema. pessoas e banco de dados) . pequena quantidade de projeto e análise de alto nível  Manutenção visão essencial quando o software deve fazer interface com outros elementos (hardware.

documento que forma as bases e definição do sistema para todo o trabalho de engenharia subseqüente .Engenharia de Sistemas Análise de Sistemas engloba as tarefas da engenharia de sistemas: Identificar as necessidades dos usuários executar a análise econômica e técnica estabelecer as restrições de prazo e custo um modelo arquitetônico do sistema é produzido e representações de cada subsistema importante são desenvolvidas PRODUTO: Especificação do Sistema .

quais conselhos dar .Engenharia de Sistemas Exige uma intensa comunicação entre o cliente e o analista O cliente deve ser capaz de entender as metas do sistema e ser capaz de especificar para o analista O analista deve saber quais perguntas fazer.

Métodos Formais PRODUTO: Especificação de Requisitos . desempenho e interfaces exigidos  tarefa de descoberta. a função. modelagem e especificação  os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Engenharia de Sistemas Análise de RequisitosProjeto Codificação Testes Métodos: Análise Estruturada. refinamento. Análise Orientada a Objetos.Atividades do Ciclo de Vida Clássico ANÁLISE DE REQUISITOS DE SOFTWARE  É o primeiro passo técnico do processo de Engenharia de Software  processo de coleta dos requisitos é intensificado e concentrado especificamente no software  deve-se compreender o domínio da Manutenção informação.

Atividades do Ciclo de Vida Clássico PROJETO  tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade. antes que a codificação se inicie Engenharia de Sistemas Análise de Requisitos  se concentra em 4 atributos do programa: Estrutura de Dados. Detalhes Procedimentais e Caracterização de Interfaces . Projeto Codificação Testes Manutenção Arquitetura de Software.

Atividades do Ciclo de Vida Clássico CODIFICAÇÃO  tradução das representações do Engenharia de Sistemas Análise de Requisitos projeto para uma linguagem ³artificial´ resultando em instruções executáveis pelo computador Projeto Codificação Testes Manutenção .

Atividades do Ciclo de Vida Clássico
TESTES
Concentram-se: 

nos aspectos lógicos internos do Engenharia de Sistemas Análise de Requisitos
software, garantindo que todas as instruções tenham sido testadas

Projeto Codificação Testes 

nos aspectos funcionais externos, para descobrir erros e
garantir que a entrada definida produza resultados que concordem com os esperados.

Manutenção

Atividades do Ciclo de Vida Clássico
MANUTENÇÃO 
o software deverá sofrer mudanças depois que for entregue ao cliente

Engenharia de Sistemas Análise de Requisitos

Projeto Codificação Testes 

causas das mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho

Manutenção

Manutenção
Tipos de Manutenção 

Manutenção Corretiva: diagnóstico e correção de erros Manutenção Adaptativa: adaptação do software para acomodar mudanças em seu ambiente externo (Hardware / Software) Manutenção Perfectiva: exigência do cliente para acréscimos funcionais e de desempenho Manutenção Preventiva: melhorar a confiabiliade e manutenibilidade futura (técnicas de engenharia reversa e reengenharia)

No começo dos projetos sempre existe uma incerteza natural o cliente deve ter paciência. Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimento Iterações e dificuldades para o planejamento e a supervisão Congelamento de fases iniciais e comprometimento do atendimento aos requisitos reais do cliente .Problemas com o Ciclo de Vida Clássico projetos reais raramente seguem o fluxo seqüencial que o modelo propõe logo no início é difícil estabelecer explicitamente todos os requisitos.

Clássico (comentários)
Visibilidade do processo Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

Prototipação
processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. idealmente, o modelo (protótipo serve como um mecanismo para protótipo) identificar os requisitos de software.
protótipo em papel ou sistema que retrata a interação com o usuário protótipo que implemente algumas funções exigidas

apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes. desenvolvedor não tem certeza da eficiência de um algoritmo, forma da interação homem/máquina

Prototipação
início fim
obtenção dos requisitos projeto rápido

construção produto

refinamento Requisitos avaliação protótipo

construção protótipo

Atividades da Prototipação início fim construção produto obtenção dos requisitos projeto rápido Obtenção dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software. identificam quais requisitos são conhecidos e as áreas que necessitam de definições adicionais refinamento Requisitos avaliação protótipo construção protótipo Projeto Rápido: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída) .

Atividades da Prototipação início fim construção produto Construção Protótipo: implementação obtenção dos requisitos do projeto rápido projeto rápido Avaliação do Protótipo: cliente e desenvolvedor avaliam o protótipo refinamento Requisitos avaliação protótipo construção protótipo .

projeto rápido refinamento Requisitos avaliação protótipo construção protótipo Ocorre neste ponto um processo de iteração que pode conduzir a 1a. atividade até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito.Atividades da Prototipação início fim construção produto obtenção dos requisitos Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. .

refinamento Requisitos avaliação protótipo construção protótipo .Atividades da Prototipação início fim construção produto obtenção dos requisitos projeto rápido Construção Produto: identificados os requisitos. o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

. Não aceita bem a idéia que a versão final do software vai ser construída e "força" a utilização do protótipo como produto final. a qualidade global e a manutenibilidade a longo prazo. durante o desenvolvimento.Problemas com a Prototipação cliente não sabe que o software que ele vê não considerou.

. e esquece que elas não são apropriadas para o produto final. Depois de um tempo ele familiariza com essas escolhas.Problemas com a Prototipação Desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo.

Prototipação (comentários) Ainda que possam ocorrer problemas. a prototipação é um ciclo de vida eficiente   A chave é definir-se as regras do jogo logo no começo O cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos  .

Modelo Espiral acopla a natureza iterativa do modelo de prototipação com os aspectos controlados e sistemáticos do modelo seqüencial Modelo Incremental combina elementos do modelo seqüencial com a filosofia iterativa do modelo de prototipação. liberação por incrementos ...Modelos Evolutivos São iterativos Desenvolvendo novas versões .

como mecanismo de redução de riscos . segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa que reflete mais realisticamente o mundo real usa a Prototipação em qualquer etapa da evolução do produto. Prototipação.Ciclo de Vida em Espiral engloba as melhores características do ciclo de vida Clássico e da Prototipação adicionando um novo elemento: a Análise de Risco Prototipação.

Espiral planejamento análise dos riscos decisão de continuar ou não direção de um sistema engenharia concluído avaliação do cliente .

Atividades do Ciclo de Vida em Espiral Planejamento: determinação dos objetivos. alternativas e restrições Análise de Risco: análise das alternativas e identificação / resolução dos riscos Construção: desenvolvimento do produto no nível seguinte Avaliação do Cliente: avaliação do produto e planejamento das novas fases avaliaçã o do cliente planejamento análise dos riscos engenharia .

pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso . a abordagem mais realística para o desenvolvimento de software em grande escala. usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva.Espiral (comentários) é. atualmente.

Espiral (comentários) o modelo é relativamente novo e não tem sido amplamente usado Demorará muitos anos até que a eficácia desse modelo possa ser determinada com certeza absoluta. .

Modelo Incremental Cada seqüência linear produz uma liberação por incremento do software Exemplo: Processador de Texto Primeiro incremento: núcleo do produto Em cada incremento: entrega de um produto operacional .

Técnicas de 4a Geração Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural. Engloba um conjunto de ferramentas de software que possibilitam que: o sistema seja especificado em uma linguagem de alto nível e o código fonte seja gerado automaticamente a partir dessas especificações .

Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do ³Projeto´ Implementação usando 4GL Testes .

Ferramentas do ambiente de desenvolvimento de software de 4GL O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4a geração inclui as ferramentas:        linguagens não procedimentais para consulta de banco de dados geração de relatórios manipulação de dados interação e definição de telas geração de códigos capacidade gráfica de alto nível capacidade de planilhas eletrônicas .

Atividades das Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do ³Projeto´ Implementação usando 4GL 1. obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional Testes o cliente pode estar inseguro quanto aos requisitos o cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural" .

Atividades das Técnicas de 4a Geração 2. estratégia de "Projeto": para Obtenção dos Requisitos Estratégia do ³Projeto´ Implementação usando 4GL pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G Testes para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade) .

Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL Testes .Atividades das Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do ³Projeto´ Implementação usando 4GL 3. implementação usando 4GL: os resultados desejados são representados de modo que haja geração automática de código .

teste: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. Testes .Atividades das Técnicas de 4a Geração Obtenção dos Requisitos Estratégia do ³Projeto´ Implementação usando 4GL 4. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.

Técnicas de 4a Geração (comentários) PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de produtividade) OPONENTES as 4GL atuais não são mais fáceis de usar OPONENTES: do que as linguagens de programação o código fonte produzido é ineficiente a manutenibilidade de sistemas usando técnicas 4G ainda é questionável .

Mudança na natureza de desenvolvimento de software demanda global demanda por software aplicação de técnicas de 4a Geração métodos convencionais 1970 1980 1990 2000 .

interação técnicas 4G modelo espiral no. interação testes sistema completo manutenção .Combinação dos Métodos de obtenção dos requisitos Ciclo de Vida preliminares análise dos requisitos projeto protomodelagem técnicas 4G modelo espiral protomodelagem no. interação codificação protomodelagem no.

Engenharia de Software uma visão genérica O processo de desenvolvimento de software contém 3 fases genéricas. DESENVOLVIMENTO MANUTENÇÃO. 3. 2. independentes do modelo de engenharia de software escolhido: 1. e . DEFINIÇÃO.

Projeto de Software 2. Análise de Sistema 2. Teste 1. Planejamento do Projeto 3. Enten er 2. Codificaç o 3. Revalidar Ativi a es e Apoio 1. Doc ent ç o 3.Engenharia de Software uma visão genérica Co str ção Defi ição ³o que´ Operação Ma OF TW ARE PRO DUTO Dese volvime to ³como´ te ção 1. Análise de Requisitos ³mudanças´ 1. Mo ificar 3. Revisões 2. Controle e Mu anças .

Planejamento do Projeto de Software: assim que o escopo do Software: software é estabelecido. os riscos são analisados. os custos são estimados e.Engenharia de Software uma visão genérica DEFINIÇÃO : ³o que´ será desenvolvido. o papel que o software desempenhará. . os recursos são alocados. atribuindo em última análise. Análise do Sistema: define o papel de cada elemento num Sistema: sistema baseado em computador. tarefas e programação de trabalho definidas.

Engenharia de Software uma visão genérica proporciona uma direção. mas uma definição detalhada do domínio da informação e da função do software é necessária antes que o trabalho inicie. Análise de Requisitos: o escopo definido para o software .

Projeto de Software: traduz os requisitos do software num Software: conjunto de representações (algumas gráficas. outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados. .Engenharia de Software uma visão genérica DESENVOLVIMENTO: DESENVOLVIMENTO ³como´ o software vai ser desenvolvido. a arquitetura do software. os procedimentos algorítmicos e as características de interface.

Engenharia de Software uma visão genérica Codificação: Codificação: as representações do projeto devem ser convertidas numa linguagem artificial (a linguagem pode ser uma linguagem de programação convencional ou uma linguagem não procedimental) que resulte em instruções que possam ser executadas pelo computador. . ele deve ser testado para que se possa descobrir defeitos de função. Realização de Testes do Software: logo que o software é implementado Software: numa forma executável por máquina. lógica e implementação.

Engenharia de Software uma visão genérica MANUTENÇÃO: concentra-se nas ³mudanças´ que MANUTENÇÃO: ocorrerão depois que o software for liberado para uso operacional Correção Adaptação Melhoramento Funcional .

. é provável que o cliente descubra defeitos no software.Engenharia de Software uma visão genérica Correção: Correção: mesmo com as melhores atividades de garantia de qualidade de software. A manutenção corretiva muda o software para corrigir defeitos. Adaptação: Adaptação: com o passar do tempo. o ambiente original (por exemplo a CPU. o sistema operacional e periféricos) para o qual o software foi desenvolvido provavelmente mudará. A manutenção adaptativa muda o software para acomodar mudanças em seu ambiente.

A manutenção perfectiva estende o software para além de suas exigências funcionais originais. .Engenharia de Software uma visão genérica Melhoramento Funcional: a medida que o software é usado. o Funcional: cliente/usuário reconhecerá funções adicionais que oferecerão benefícios.

Revisões: Revisões: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída. Documentação: Documentação: é desenvolvida e controlada para garantir que informações completas sobre o software estejam disponíveis para uso posterior. Controle das Mudanças: é instituído de forma que as mudanças Mudanças: possam ser aprovadas e acompanhadas. .Engenharia de Software uma visão genérica Atividades de Apoio: as fases e etapas correlatas descritas são Apoio: complementadas por uma série de atividades de Apoio.

³a construção por múltiplas pessoas de um software de múltiplas versões´ [Parnas 1987] ..Conclusão ENGENHARIA DE SOFTWARE pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos.... .

Sign up to vote on this title
UsefulNot useful