Unidade 2: O Processo Parte I: O Produto e o Processo

Apresentação em tema: "Unidade 2: O Processo Parte I: O Produto e o Processo"— Transcrição da apresentação:

1 Unidade 2: O Processo Parte I: O Produto e o Processo
Prof. Milton C. Marchi BASEADO EM: Prof. Dr. Marcelo Augusto Santos Turine DCT - UFMS

2 Engenharia de Software: Definição
Fritz Bauer “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”

3 Engenharia de Software: Definição
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”

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 (Anneliese Mayrhauser 1990)
Engenharia de Software 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)

6 Engenharia de Software
Abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Processos (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 Engenharia de Software: Tecnologia em Camadas
FERRAMENTAS MÉTODOS PROCEDIMENTOS/PROCESSOS (KPA) D FOCO NA QUALIDADE (g.q.t)

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

9 Engenharia de Software
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 Engenharia de Software
FERRAMENTAS: 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 Engenharia de Software
PROCEDIMENTOS: 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 Software
ENGENHARIA DE SOFTWARE: compreende um conjunto de etapas que envolve MÉTODOS, FERRAMENTAS e PROCEDIMENTOS. Essas etapas são citadas como CICLOS DE VIDA ou MODELOS DE PROCESSO DE SOFTWARE Uma estratégia de desenvolvimento que englobe processos, métodos e ferramentas, e as fases de desenvolvimento

13 Engenharia de Software
Desenvolvimento de software é um processo de aprendizagem social e iterativo processo - diálogo em que o conhecimento é embutido no software, interação entre usuários- projetistas, iterativo Quando se constrói um produto é importante seguir um conjunto de etapas (road map - processo de software) Uma estrutura para realizar as tarefas

14 Engenharia de Software
Engloba um PROCESSO, GERENCIAMENTO E MÉTODOS TÉCNICOS, FERRAMENTAS Engenharia é Análise, Projeto (design), Implementação, Verificação e Gerenciamento de entidades técnicas Definição - O QUÊ (What) Desenvolvimento - COMO (How) Suporte - MANUTENÇÃO (Change) - Segurança corretiva, adaptativa, melhoramento funcional, preventiva (Reengenharia)

15 PROCESSO DE CONSTRUÇÃO
Visão Profissional de Qualidade PROCESSO DE CONSTRUÇÃO requisitos PRODUTO usuário requisitos atendidos PRODUTO COM QUALIDADE

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

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 Por que Modelar????? 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 Por que Modelar????? 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 Software Estrutura comum de processo
Atividades da estrutura Conjunto de tarefas Tarefas Marcos de controle Controle de qualidade (pontos SQA) Atividades guarda-chuva

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 chaves de um processo de software eficaz. Um caminho de melhoramento evolucionário (5 níveis de maturidade) para organizações de software mudarem de um processo de software imaturo, ad hoc, para um processo maduro, disciplinado.

28 CMM - Capability Maturity Model
(Modelo de Maturidade da Competência) Maturidade da Competência : competência em controlar o Processo de Software (desenvolvimento, gerenciamento e manutenção) Maturidade da Competência Maturidade do Processo de Software

29 Maturidade de Processo de Software
A maturidade dos processos de software de uma organização influencia na sua capacidade de atingir metas de custo, qualidade e cronograma A qualidade do processo de software pode ser analisada através do nível de maturidade do processo.

30 Premissa Básica Premissa básica que está por baixo do trabalho da SEI 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 Os 5 Níveis de Maturidade do CMM
OTIMIZADO Organizações com Melhoria Contínua GERENCIADO Organizações Previsíveis DEFINIDO Organizações Padronizadas REPETITIVO Organizações Disciplinadas INICIAL Organizações Caóticas

32 CMM: Ní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. INICIAL Organizações Caóticas

33 CMM: Nível 2 de Maturidade
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. REPETÍVEL Organizações Disciplinadas

34 CMM: Nível 3 de Maturidade
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. DEFINIDO Organizações Padronizadas

35 CMM: Nível 4 de Maturidade
GERENCIADO 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. Organizações Previsíveis

36 CMM: Nível 5 de Maturidade
OTIMIZADO Organizaçõ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 PROCESSO DE CONSTRUÇÃO
Visão Profissional de Qualidade PROCESSO DE CONSTRUÇÃO requisitos PRODUTO usuário requisitosatendidos 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 Modelos de Processo Modelo Seqüencial (ciclo de vida clássico)
Modelo de Prototipação Modelo RAD (Rapid Application Development) Modelos Evolutivos Modelo Incremental e Espiral Modelo de Espiral WinWin Modelo de desenvolvimento Concorrente Modelo de Montagem de Componentes Modelo de Métodos Formais Técnicas de 4a geração Modelo do RUP

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 Ciclo de Vida Clássico 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 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 Atividades do Ciclo de Vida Clássico
2- ANÁ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 Análise de Requisitos 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

48 Atividades do Ciclo de Vida Clássico
3- 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 se concentra em 4 atributos do programa: Estrutura de Dados Arquitetura de Software Detalhes Procedimentais Caracterização de Interfaces

49 Projeto Projeto de Fluxo de Dados Projeto Orientado a Objetos

50 Atividades do Ciclo de Vida Clássico
4- CODIFICAÇÃO tradução das representações do projeto para uma linguagem artificial resultando em instruções executáveis pelo computador

51 Atividades do Ciclo de Vida Clássico
5- TESTES Concentra-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 Atividades do Ciclo de Vida Clássico
6- MANUTENÇÃO provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente Caracterizada como o “iceberg”

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

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 Vantagens do Ciclo de Vida Clássico
Visibilidade do processo Embora o Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software

57 Prototipação 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

58 Prototipação Construir/Revisar Conversar com protótipo o Cliente
Revisão e Teste pelo Cliente

59 refinamento protótipo obtenção dos requisitos
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ção
1- 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- 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 Atividades da Prototipação
3- CONSTRUÇÃO PROTÓTIPO: implementação do projeto rápido serve como o “primeiro sistema” - recomendado que se jogue fora futuramente 4- AVALIAÇÃO DO PROTÓTIPO: cliente e desenvolvedor avaliam o protótipo

62 Atividades da Prototipação
5- REFINAMENTO DOS REQUISITOS: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iteraçã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 Atividades da Prototipação
6- 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ó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 Problemas com a Prototipação
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

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 Evolutivos Modelo Espiral Modelo Incremental
Sã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 avaliação do cliente análise dos riscos
decisão de continuar ou não na direção de um sistema concluído avaliação do cliente engenharia análise dos riscos planejamento

71 Atividades do Ciclo de Vida em Espiral
1- PLANEJAMENTO: determinação dos objetivos, alternativas e restrições 2- ANÁLISE DE RISCO: análise das alternativas e identificação / resolução dos riscos 3- CONSTRUÇÃO: desenvolvimento do produto no nível seguinte 4- 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 Comentários sobre o Ciclo de Vida em Espiral
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

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

79 Não há muito o que contestar:
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: 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 Atividades das Técnicas de 4a Geração
2- 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 Atividades das Técnicas de 4a Geração
3- 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: 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: 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 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 Software uma 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ÇÃO DESENVOLVIMENTO MANUTENÇÃO

88 Engenharia de Software uma visão genérica
FASE DE DEFINIÇÃO: “o quê” será desenvolvido Aná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 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 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 Engenharia de Software uma visão genérica
FASE DE DESENVOLVIMENTO: “como” o software vai ser desenvolvido Projeto 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çã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 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 Engenharia de Software uma visão genérica
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 Engenharia de Software uma visão genérica
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çã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 Engenharia de Software uma visão genérica
Melhoramento 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 Engenharia de Software uma visão genérica
ATIVIDADES DE PROTEÇÃO as fases e etapas correlatas descritas são complementadas por uma série de atividades de proteção. Revisões: efetuadas para garantir que a qualidade seja mantida à medida que cada etapa é concluída. 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 possam ser aprovadas e acompanhadas.

94 Conclusão ENGENHARIA 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 )