Unidade 2: O Processo Parte I: Parte I: O Produto e o Processo Prof. Milton C. Marchi BASEADO EM:...

Unidade 2: O Processo

Parte I:Parte I:O Produto e o ProcessoO Produto e o Processo

Prof. Milton C. Marchi

BASEADO EM:Prof. Dr. Marcelo Augusto Santos Turine - 2002

DCT - [email protected]

2

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”

Engenharia de Software: Definição

3

IEEE, 1993

“A aplicação de uma abordagem sistemática, disciplinada e quantificável para o

desenvolvimento, operação e manutenção do software. 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”

Engenharia de Software: Definição

4

Engenharia de Software: Definição Arndt Von Staa, 1987

“O desenvolvimento e a aplicação de ciência, matemática, técnicas, 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”

5

Engenharia de Software

ENGENHARIA DE SOFTWAREENGENHARIA 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)

6


Abrange um conjunto de três elementos fundamentais: MétodosMétodos, , FerramentasFerramentas e e Processos Processos (Procedimentos)(Procedimentos)

Possibilitar ao gerente o controle do processo de desenvolvimento Oferecer ao profissional uma base para a construção de software

de alta qualidade

7

D

Engenharia de Software: Tecnologia em Camadas

FOCO NA QUALIDADE (g.q.t)

PROCEDIMENTOS/PROCESSOS (KPA)

MÉTODOS

FERRAMENTAS

8


MÉTODOSMÉTODOS: proporcionam os detalhes de “como fazer” para construir o software

Envolvem um amplo conjunto de tarefas ...

9


Planejamento e estimativa de projeto Análise de requisitos de software Projeto da estrutura de dados Algoritmo de processamento Codificação Teste Manutenção

10


FERRAMENTASFERRAMENTAS: fornecem suporte automatizado ou semi 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

11

PROCEDIMENTOSPROCEDIMENTOS: constituem o elo de ligação entre os métodos e ferramentas

Seqüência em que os métodos serão aplicados Produtos (deliverables) 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


12

ENGENHARIA DE SOFTWAREENGENHARIA DE SOFTWARE:: compreende um conjunto de etapasetapas que envolve MÉTODOS, FERRAMENTAS e PROCEDIMENTOS.

Essas etapas são citadas como CICLOS DE CICLOS DE VIDA ou MODELOS DE PROCESSO DE VIDA ou MODELOS DE PROCESSO DE SOFTWARESOFTWARE

Uma estratégia de desenvolvimento que Uma estratégia de desenvolvimento que englobe processos, métodos e ferramentas, e englobe processos, métodos e ferramentas, e as fases de desenvolvimentoas fases de desenvolvimento


13

Desenvolvimento de software é um processo de Desenvolvimento de software é um processo de aprendizagem social e iterativoaprendizagem social e iterativo processo - diálogo em que o conhecimento é processo - diálogo em que o conhecimento é

embutido no software, interação entre usuários-embutido no software, interação entre usuários-projetistas, iterativoprojetistas, iterativo

Quando se constrói um produto é importante Quando se constrói um produto é importante seguir um conjunto de etapas (seguir um conjunto de etapas (road maproad map - - processo de software)processo de software)

Uma estrutura para realizar as tarefasUma estrutura para realizar as tarefas


14

Engloba um PROCESSO, GERENCIAMENTO E Engloba um PROCESSO, GERENCIAMENTO E MÉTODOS TÉCNICOS, FERRAMENTASMÉTODOS TÉCNICOS, FERRAMENTAS

Engenharia é Análise, Projeto (design), Engenharia é Análise, Projeto (design), Implementação, Verificação e Gerenciamento de Implementação, Verificação e Gerenciamento de entidades técnicasentidades técnicas Definição - O QUÊ (Definição - O QUÊ (WhatWhat)) Desenvolvimento - COMO (Desenvolvimento - COMO (HowHow)) Suporte - MANUTENÇÃO (Suporte - MANUTENÇÃO (ChangeChange) - Segurança) - Segurança corretiva, adaptativa, melhoramento funcional, preventiva corretiva, adaptativa, melhoramento funcional, preventiva

(Reengenharia)(Reengenharia)


15

Visão Profissional de QualidadeVisão Profissional de Qualidade

requisitosrequisitosPROCESSO DE CONSTRUÇÃO

PRODUTO

usuário

requisitos requisitos atendidosatendidos

PRODUTO COM QUALIDADE

16

Qualidade de Software Qualidade de Software

desenvolvedor

usuário

organização

Processode

Desenvolvimento

SOFTWARE PRODUTO

SOFTWARE COM QUALIDADE

PROCESSO DE SOFTWARE

requisitosrequisitos

requisitos requisitos atendidosatendidos

17

Por que Modelar?????

Uma empresa de software bem sucedida? Fornece software de qualidade e capaz de atender

às necessidades dos usuários Desenvolver software de maneira previsível e em

determinado período, com utilização eficiente e eficaz de recursos

Empresa com um NEGÓCIO viável

18

Por que Modelar????? Produto Principal: software capaz de

satisfazer às necessidades de seus usuários e respectivos negócios O resto é SECUNDÁRIO, mas não

IRRELEVANTE (documentos bonitos, reuniões sofisticadas, ótimos slogans, linhas de código maravilhosas, interfaces ricas, ...)

MODELAGEM é a parte central de todas as atividades que levam à implantação de um bom software

19


Modelos são construídos para comunicar a estrutura e o comportamento desejado do sistema. Visualizar e controlar a arquitetura. Compreender melhor o sistema. Gerenciar os riscos...

Exemplos: Construir uma casa para seu cachorro Construir uma casa para sua família (Qualidade) Construir um prédio comercial

20

Por que Modelar????? “Muitas empresas de desenvolvimento de

software começam querendo construir prédios altos, como se estivessem fazendo uma casinha de cachorro.” Sorte ajuda Pessoas certas no momento adequado e com todas

as tecnologias em alinhamento favorável.... Desenvolvimento de software de qualidade é

uma questão de Arquitetura, Processo e Ferramentas XXXXXXXXXXXXXX

21


Modelagem é uma técnica de engenharia aprovada e bem aceita modelos de arquitetura de casas e de grandes

prédios modelos matemáticos a fim de analisar os efeitos de

ventos e tremores de terra --> causas

O que é um MODELO?

22

Definição: Modelo Um modelo é uma simplificação da realidade.

Planos de detalhes, podem ser estruturais (organização do sistema) ou comportamentais (dinâmica do sistema)

Construímos modelos para compreender melhor o sistema que estamos desenvolvendo. 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

23

Definição: Modelo Construímos modelos de sistemas complexos porque não é

possível compreendê-los em sua totalidade. 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

Os melhores modelos estão relacionados à realidade (modelos simplificam a realidade)

Nenhum modelo único é suficiente. Conjunto de modelos independentes

24

Processo de SoftwareEstrutura comum de processo

Atividades guarda-chuva

Atividades da estrutura

Conjunto de tarefas

Tarefas

Marcos de controle

Controle de qualidade (pontos SQA)

25

Processo de Software Estrutura Comum de Processo

definição das atividades de estrutura aplicáveis a todos os projetos de software

Conjuntos de Tarefa adaptação das atividades da estrutura às

características do projeto e aos requisitos da equipe Atividades guarda-chuva

apóiam o modelo de processo (garantia de qualidade, gerenciamento de configuração, produção de documentos, etc...)

26

Processo de Software Atualmente: maturidade de processo O SEI (Software Engineering Institute)

desenvolveu um modelo de maturidade da competência (CMM - Capability Maturity Model ), que define as atividades chave requeridas nos diferentes níveis de processo

Os 5 níveis de maturidade de processo do modelo CMM (KPA - key process areas ~18) Inicial, Repetitivo, Definido, Gerenciado,

Otimizado

27

O que é o CMM? Uma estrutura que descreve os elementos elementos

chaveschaves de um processoprocesso de software eficazeficaz.

Um caminho de melhoramento evolucionáriomelhoramento evolucionário (5 níveis de maturidade) para organizações de software mudaremmudarem de um processo de software imaturo, ad hocad hoc, para um processo maduro, disciplinado.disciplinado.

28

CMM - Capability Maturity Model

Capability Maturity ModelCapability Maturity Model (Modelo de Maturidade da Competência)

Maturidade da CompetênciaMaturidade da Competência : competência em controlar o Processo de Software (desenvolvimento, gerenciamento e manutenção)

Maturidade da CompetênciaMaturidade da Competência Maturidade do Processo de SoftwareMaturidade do Processo de Software

29

Maturidade de Processo de Software A maturidade dos processosmaturidade dos processos de

software de uma organização influencia na sua capacidade de atingir metas de custocusto, qualidadequalidade e cronogramacronograma

A qualidade do processo de softwarequalidade do processo de software pode ser analisada através do nível de nível de maturidade do processomaturidade do processo.

30

Premissa Básica Premissa básicaPremissa básica que está por baixo do trabalho da

SEISEI sobre maturidade de processo:

A qualidade de um produto é profundamente determinada pela qualidade do processo de

desenvolvimento e de manutenção usado para construí-lo.

31

INICIAL

Organizações Caóticas

REPETITIVO

Organizações Disciplinadas

DEFINIDO

Organizações Padronizadas

GERENCIADO

Organizações Previsíveis

OTIMIZADOOrganizações com Melhoria Contínua

Os 5 Níveis de Os 5 Níveis de Maturidade do CMMMaturidade do CMM

32

INICIAL

Organizações Caóticas

CMM: CMM: Nível 1 de MaturidadeNível 1 de Maturidade

• O processo de software é caracterizado como ad hoc, e ocasionalmente até mesmo caótico.

• Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos.

33

REPETÍVEL

Organizações Disciplinadas


• Sabe-se o que se faz

• Intuição dos gerentes

• Processos administrativos básicos são estabelecidos para acompanhar custo, cronograma e funcionalidade.

• A disciplina de processo está em repetir sucessos anteriores em projetos com aplicações similares.

34

DEFINIDO

Organizações Padronizadas

• Os processos de software, tanto para atividades administrativas quanto para de engenharia estão documentados, padronizados e integrados em um processo de software padrão para a organização.

• Todos os projetos usam uma versão aprovada do processo de software padrão da organização para desenvolvimento e manutenção de software.


35

GERENCIADO

Organizações Previsíveis

• São coletadas medidas detalhadas da qualidade do processo e do produto (métricas)

• Tanto o processo de software quanto os produtos são quantitativamente compreendidos e controlados.


36

OTIMIZADOOrganizações com Melhoria Contínua


• Contínua melhoria de processo é possível por retornos quantitativos dos processos e das idéias e tecnologias inovadoras

37

Visão Profissional de QualidadeVisão Profissional de Qualidade

requisitosrequisitos

PROCESSO DE CONSTRUÇÃO

PRODUTO

usuáriorequisitosrequisitosatendidosatendidos

PRODUTO COM QUALIDADE

38

Modelos de Processo ou Paradigmas de Engenharia de Software Uma estratégia de desenvolvimento que

englobe processos, métodos e ferramentas, e as fases de desenvolvimento...

39

1.1. Modelo Seqüencial (ciclo de vida clássico)Modelo Seqüencial (ciclo de vida clássico)

2.2. Modelo de PrototipaçãoModelo de Prototipação

3.3. Modelo RAD (Rapid Application Development)Modelo RAD (Rapid Application Development)

4.4. Modelos EvolutivosModelos Evolutivos

1.1. Modelo Incremental e EspiralModelo Incremental e Espiral

5.5. Modelo de Espiral WinWinModelo de Espiral WinWin

6.6. Modelo de desenvolvimento ConcorrenteModelo de desenvolvimento Concorrente

7.7. Modelo de Montagem de ComponentesModelo de Montagem de Componentes

8.8. Modelo de Métodos FormaisModelo de Métodos Formais

9.9. Técnicas de 4a geraçãoTécnicas de 4a geração

10.10. Modelo do RUPModelo do RUP

Modelos de Processo

40

Escolha de um Modelo 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, Clareza,

Apoio de Ferramentas, Produtividade, Qualidade, etc.

41

Modelo de 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 e seqüencial

para o desenvolvimento de software cada atividade é uma fase em separado. A

passagem entre fases é formal.

42

Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação

Teste

Manutenção

Ciclo de Vida Clássico

43

Atividades do Ciclo de Vida Clássico

1- ENGENHARIA DE SISTEMASENGENHARIA DE SISTEMAS software faz parte de um sistema amplo envolve a coleta de requisitos em nível do

sistema, com uma pequena quantidade de projeto e análise de alto nível

esta visão é essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados)

44

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 - documento que forma as bases e definição do sistema para todo o trabalho de engenharia subseqüente

45

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, quais conselhos dar

46

2- ANÁLISE DE REQUISITOS DE SOFTWAREANÁLISE DE REQUISITOS DE SOFTWARE É o primeiro passo técnico do processo de

engenharia de software o processo de coleta dos requisitos é

intensificado e concentrado especificamente no software

tarefa de descoberta, refinamento, modelagem e especificação

escopo definido inicialmente é refinado e aperfeiçoado em detalhes


47

O analista deve compreender o domínio da informação, a função, desempenho e interfaces exigidos

os requisitos (para o sistema e para o software) são documentados e revistos com o cliente

Métodos: Análise Estruturada, Análise Orientada a Objetos, Métodos Formais

PRODUTO: Especificação de Requisitos

Análise de Requisitos

48

3- PROJETOPROJETO 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

se concentra em 4 atributos do programa: Estrutura de Dados Arquitetura de Software Detalhes Procedimentais Caracterização de Interfaces


49

Projeto de Fluxo de Dados

Projeto Orientado a Objetos

Projeto

50

4- CODIFICAÇÃOCODIFICAÇÃO tradução das representações do projeto para

uma linguagem artificial resultando em instruções executáveis pelo computador


51

5- TESTESTESTESConcentra-se:

nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas

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


52

6- MANUTENÇÃOMANUTENÇÃO provavelmente o software deverá sofrer

mudanças depois que for entregue ao cliente

Caracterizada como o “iceberg”


53

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) PAROU AQUI

Manutenção

54

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. 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

55

Problemas com o Ciclo de Vida Clássico

Iterações e dificuldades para o planejamento e a supervisão

Congelamento de fases iniciais e comprometimento do atendimento aos requisitos reais do cliente

56

Visibilidade do processo Embora o Ciclo de Vida Clássico

tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

Vantagens do Ciclo de Vida Clássico

57

APROPRIADO 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

58

Prototipação

Conversar com o Cliente

Construir/Revisarprotótipo

Revisão e Testepelo Cliente

59

fim

início

construção produto

refinamento protótipo

avaliação protótipo

construção protótipo

projeto rápido

obtenção dos requisitos

60

Atividades da Prototipação1-1- OBTENÇÃO DOS REQUISITOS: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

2-2- PROJETO RÁPIDO: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)

61

3-3- CONSTRUÇÃO PROTÓTIPOCONSTRUÇÃO PROTÓTIPO::

implementação do projeto rápidoserve como o “primeiro sistema” - recomendado que se jogue fora futuramente

4-4- AVALIAÇÃO DO PROTÓTIPO:AVALIAÇÃO DO PROTÓTIPO:

cliente e desenvolvedor avaliam o protótipo

Atividades da Prototipação

62

5-5- REFINAMENTO DOS REQUISITOS:REFINAMENTO DOS REQUISITOS:cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.Ocorre neste ponto um processo de iteraçãoiteração que pode conduzir a atividade 1 até que as necessidades do cliente sejam satisfeitas e o desenvolvedor compreenda o que precisa ser feito


63

6-6- CONSTRUÇÃO PRODUTO: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


64

Prototipação processo que possibilita que o desenvolvedor crie

um modelo do software que deve ser construído idealmente, o modelo (protótipoprotótipo) serve como um

mecanismo para 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

Protótipo serve como mecanismo para identificar os requisitos do software

65

cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade a longo prazo.

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

desenvolvedor freqüentemente faz uma implementação comprometida (utilizando o que está disponível) com o objetivo de produzir rapidamente um protótipo.

Depois de um tempo ele familiariza com essas escolhas, e esquece que elas não são apropriadas para o produto final

Problemas com a Prototipação

66

ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente.

a chave é definir 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

67

RAD (Rapid Application Development)

Adaptação do sequencial Modelo de desenvolvimento de software

incremental que enfatiza um ciclo de desenvolvimento bastante curto (60 a 90 dias)

Desenvolvimento em equipe (team) e modular Fases: Modelagem do Negócio, Modelagem dos

Dados, Modelagem do Processo, Geração da Aplicação, Teste e Turnover

68

Modelos EvolutivosSão iterativos ( REPETIDO, REITERADO )Desenvolvendo novas versões ...

Modelo Espiral acopla a natureza iterativa do modelo de prototipação com os

aspectos controlados e sistemáticos do modelo sequencial

Modelo Incremental combina elementos do modelo sequencial com a filosofia iterativa do

modelo de prototipação, liberação por incrementos

69

Ciclo de Vida em Espiral Engloba as melhores características do ciclo de vida Clássico como o da Prototipação, adicionando um novo elemento: a ANÁLISE DOS RISCOS

Segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico incorporando-os numa estrutura iterativa, repetitiva, que reflete mais realisticamente o mundo real

Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de redução de riscos AQUI

70

decisão de continuar ou não

na direção de um sistema concluído

avaliação do cliente

engenharia

análise dos riscosplanejamento

71

Atividades do Ciclo de Vida em Espiral

1-1- PLANEJAMENTO:PLANEJAMENTO: determinação dos objetivos, alternativas e restrições

2-2- ANÁLISE DE RISCO: ANÁLISE DE RISCO: análise das alternativas e identificação / resolução dos riscos

3-3- CONSTRUÇÃO: CONSTRUÇÃO: desenvolvimento do produto no nível seguinte

4-4- AVALIAÇÃO DO CLIENTE: AVALIAÇÃO DO CLIENTE: avaliação do produto e planejamento das novas fases

72

Comentários sobre o Ciclo de Vida em Espiral

É uma abordagem 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.

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

73

A cada iteração ao redor da espiral, versões progressivamente mais completas do software são construídas

o modelo é relativamente novo e não tem sido amplamente usado

Comentários sobre o Ciclo de Vida em Espiral

74

Modelo Incremental Cada seqüência linear produz 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

75

DBC - Desenvolvimento Baseado em Componentes

Evolução da Tecnologia OO Adaptação do modelo espiral para o

desenvolvimento de software Modelo de Componentes: CORBA (Common

Object Request Broker Architecture), COM (Component Object Model - Microsoft), UML

Componentes são construídos/empacotados para serem reutilizados em diferentes aplicações (Reuso)

76

Modelo de desenvolvimento Concorrente

Engenharia concorrente (1994) - aplicações cliente/servidor

Representado esquematicamente como uma série de atividades técnicas, tarefas e os estados associados a elas

Atividades concorrentemente em diferentes estados

Ex: Atividade de Engenharia do ModeloEspiral tarefas: prototipação, análise, especificação de

requisitos e projeto

77

Modelo de Métodos Formais Atividades que conduzem a uma

especificação matemática formal Notação matemática rigorosa: especificar,

desenvolver e verificar/analisar Eliminar ambiguidade, inconsistência,

incompletitude Abordagem: engenharia de software

Cleanroom (sala limpa) Consomem tempo e custo

78

Técnicas de 4a GeraçãoConcentra-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 sistema seja especificado em uma linguagem de alto nívelalto nível e

o código fonte seja gerado automaticamentecódigo fonte seja gerado automaticamente a partir dessas especificações

79

Técnicas de 4a Geração

Não há muito o que contestar:

Quanto mais alto o nível em que o software pode ser especificado a uma máquina, mais rapidamente o programa pode ser construído

80

Ferramentas do ambiente de desenvolvimento de software de 4a Geração

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

81

Obtenção dos Requisitos

Estratégia de “Projeto”

Implementação usando 4GL

Testes

82

Atividades das Técnicas de 4a Geração

1- OBTENÇÃO DOS REQUISITOS:OBTENÇÃO DOS REQUISITOS: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional

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"

83

2- ESTRATÉGIA DE "PROJETO":ESTRATÉGIA DE "PROJETO": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma linguagem de quarta geração

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, manutenibilidade ruim, má aceitação do cliente)


84

3- IMPLEMENTAÇÃO USANDO 4GL:IMPLEMENTAÇÃO USANDO 4GL: os resultados desejados são representados de modo que haja geração automática de código . Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL

4- TESTE:TESTE: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada

prontamente.


85

Comentários sobre as Técnicas de 4a Geração

PROPONENTES:PROPONENTES: redução dramática no tempo de desenvolvimento do software (aumento de produtividade)

OPONENTESOPONENTES: as 4GL atuais não são mais fáceis de usar do que as linguagens de programação

o código fonte produzido é ineficiente a manutenibilidade de sistemas usando técnicas

4G ainda é questionável

86

Mudança na natureza de desenvolvimento de software

métodos convencionais

aplicação de técnicas de 4a

Geração

demanda global

demanda por software

1970 1980 1990 2000

87

Engenharia de Softwareuma visão genérica

O processo de desenvolvimento de software contém 3 fases genéricas, independentes do modelo de engenharia de software escolhido:

DEFINIÇÃODEFINIÇÃO DESENVOLVIMENTODESENVOLVIMENTO MANUTENÇÃOMANUTENÇÃO

88

FASE DE DEFINIÇÃO:FASE DE DEFINIÇÃO: ““o quê”o quê” será desenvolvido Análise do SistemaAnálise do Sistema:: define o papel de cada elemento num

sistema baseado em computador, atribuindo em última análise, o papel que o software desempenhará.

Planejamento do Projeto de SoftwarePlanejamento do Projeto de Software:: assim que o escopo do software é estabelecido, os riscos são analisados, os recursos são alocados, os custos são estimados, e tarefas e programação de trabalho são definidas.

Análise de RequisitosAnálise de Requisitos:: o escopo definido para o software 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.


89

FASE DE DESENVOLVIMENTO:FASE DE DESENVOLVIMENTO: ““como”como” o software vai ser desenvolvido

Projeto de SoftwareProjeto de Software:: traduz os requisitos do software num conjunto de representações (algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura do software, os procedimentos algorítmicos e as características de interface

CodificaçãoCodificaçã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

Realização de Testes do SoftwareRealização de Testes do Software:: logo que o software é implementado numa forma executável por máquina, ele deve ser testado para que se possa descobrir defeitos de função, lógica e implementação


90

FASE DE MANUTENÇÃO:FASE DE MANUTENÇÃO: concentra-se nas “mudanças” que ocorrerão depois que o software for liberado para uso operacional

Correção Adaptação Melhoramento Funcional


91

Correção:Correção: mesmo com as melhores atividades de garantia de qualidade de software, é provável que o cliente descubra defeitos no software. A manutenção corretiva muda o software para corrigir defeitos.

AdaptaçãoAdaptaçã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.


92

Melhoramento FuncionalMelhoramento Funcional:: a medida que o software é usado, o cliente/usuário reconhecerá funções adicionais que oferecerão benefícios.

A manutenção perfectiva estende o software para além de suas exigências funcionais originais.


93

ATIVIDADES DE PROTEÇÃO ATIVIDADES DE PROTEÇÃO as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção.

RevisõesRevisões:: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída.

DocumentaçãoDocumentação:: é desenvolvida e controlada para garantir que informações completas sobre o software estejam disponíveis para uso posterior.

Controle das MudançasControle das Mudanças:: é instituído de forma que as mudanças possam ser aprovadas e acompanhadas.


94

Conclusão

ENGENHARIA DE SOFTWAREENGENHARIA DE SOFTWARE

pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos.

.....“a construção por múltiplas pessoas de um software de múltiplas versões” (Parnas 1987)

Unidade 2: O Processo Parte I: Parte I: O Produto e o Processo Prof. Milton C. Marchi BASEADO EM:...

Documents

Transcript of Unidade 2: O Processo Parte I: Parte I: O Produto e o Processo Prof. Milton C. Marchi BASEADO EM:...