SlideShare uma empresa Scribd logo
1 de 6
Baixar para ler offline
DISCIPLINA DE ENGENHARIA DE SOFTWARE




                Processos Tradicionais de Software


Um processo de software é um conjunto de atividades que leva à produção de um produto
de software. Os processos de software formam a base para o controle gerencial de projetos de
software e estabelecem o contexto no qual os métodos técnicos são aplicados , os produtos de
trabalho (modelos, documentos, dados, relatórios, etc.) são produzidos, os marcos são
estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas.

Além dos processos de software, existem outros dois elementos fundamentais da engenharia
de software, os quais são métodos e ferramentas.

Os métodos fornecem a técnica de “como” fazer para construir software. As ferramentas de
engenharia de software fornecem o apoio automatizado ou semi-automatizado para o
processo e para os métodos. As ferramentas de engenharia de software auxiliada por
computador (CASE – Computer-Aided Software Engineering) que existem atualmente no
mercado ainda não automatizam todas as atividades dos processos, mas a maioria.

Não existe um processo ideal, e várias organizações desenvolveram abordagens iteiramente
diferentes para o desenvolvimento de software. A seguir são detalhados os processos de
desenvolvimento de software tradicionais mais conhecidos:




MODELO EM CASCATA
Também conhecido como modelo clássico.

A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana
nos anos 60 para permitir o desenvolvimento de software militares. No modelo em cascata, o
projeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finaliza
uma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com os
resultados da fase atual.

A Figura 1 ilustra as fases deste modelo ou processo de desenvolvimento de software.
Figura 1. Fases do Modelo em Cascata.

Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projeto
é complicado. A metodologia em cascata é extremamente formal, como seria normal de se
esperar de uma metodologia cuja concepção é militar. Pode-se afirmar que a metodologia em
cascata é baseada em documentos e com certeza possui uma enorme quantidade de
“entregáveis” e saídas que nada mais são do que documentos. Outra característica deste
modelo é o alto valor dado ao planejamento. O forte planejamento inicial reduz a necessidade
de planejamento contínuo conforme o andamento do projeto.
A Metodologia em Cascata funciona bem quando os requisitos do usuário são rígidos e podem
ser conhecidos com antecedência. O sistema de navegação do ônibus espacial, por exemplo,
pode ser um bom candidato para esta metodologia. Contudo, o foco em documentos para
descrever o que os clientes e usuários necessitam pode levar a problemas. Muito
frequentemente aparecem problemas de comunicação que resultam em um software de baixa
qualidade. Os documentos produzidos pelo processo de desenvolvimento podem ser perfeitos,
mas o produto real pode ser defeituoso ou inutilizável.
De uma forma ou de outra, muitas das metodologias de desenvolvimento são variações da
metodologia de Desenvolvimento em Cascata – apenas diferenciando-se uma das outras em
relação à velocidade, tipos de entregáveis e flexibilidade.
A metodologia de Desenvolvimento em Cascata pode funcionar bem em ambientes rígidos e
fortemente controlados, como por exemplo, os militares, mas possui sérios inconvenientes no
cenário comercial. No cenário comercial, somente recomenda-se usar este modelo para
sistemas pequenos e simples, pois se for um sistema complexo vai demorar muito tempo até
mostrar o funcionamento do sistema. Existem casos onde o contratante do desenvolvimento
do software se beneficia pela auditoria imposta pelos métodos do Desenvolvimento em
Cascata.
MODELO EM ESPIRAL
O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos
específicos. Isto significa que podemos encaixar nele as principais características dos modelos
vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às
particularidades do software a ser desenvolvido. Este modelo prevê prototipação,
desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.

Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste
metamodelo com base em análise de riscos e planejamento que é realizado durante toda a
evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o
desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto.
São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas
que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que
serão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje uma
atividade importantíssima no desenvolvimento de software devido à imaturidade da área e à
falta de conhecimento, técnicas e ferramentas adequadas.

O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro
estágios, como pode ser observado na Figura 2.




                                   Figura 2. Modelo Espiral

       No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições.
       No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante
este estágio podem ser construídos protótipos ou realizar-se simulações do software.
       O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design,
especificação, codificação e verificação. A principal característica é que a cada especificação
que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da
interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente.
       O estágio 4 compreende a revisão das etapas anteriores e o planejamento da próxima
fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores -
decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num
modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os
requisitos forem completamente especificados e validados pode-se optar por seguir o modelo
Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o,
avaliando novos riscos e replanejando o processo.




PROTOTIPAÇÃO
A modelo de Prototipagem Evolutiva é uma abordagem que visualiza o desenvolvimento de
concepções do sistema conforme o andamento do projeto. Esta metodologia baseia-se na
utilização de prototipagem visual ou modelos do sistema final. Estes modelos podem ser
simples desenhos, imagens gráficas e até cópias completas em HTML do sistema esperado.
Com esta abordagem visual, o cliente tem uma certeza maior do resultado final. A figura
abaixo ilustra esta metodologia.




                               Figura 3. Prototipação Evolutiva

O desenvolvimento real não inicia até que o protótipo final seja aceito. Esta metodologia é até
certo ponto bastante flexível a respeito de mudanças de requisitos; contudo, este processo
precisa de muito controle. Um ponto negativo deste modelo é que o planejamento efetivo
pode ser difícil e os projetos podem ser reduzidos a um ciclo Codifica-Corrige depois que o
desenvolvimento é iniciado.
O aspecto de planejamento pode tornar-se um desafio, pois a equipe não tem certeza sobre
quanto tempo levará o trabalho. Isto ocorre, em partes, porque o modelo é baseado em
interfaces, e não se preocupa tanto com as interdepêndencias de mais baixo nível. Os clientes
tem uma idéia de como eles querem utilizar o seu novo sistema e utilizam o protótipo como
referência. O valor do protótipo porém, não deve ser super-estimado, pois, apesar de tudo, ele
não é um software funcional. Existem riscos associados com o planejamento devido a natureza
interativa do desenvolvimento, mas eles são atenuados de certa forma através da
prototipagem e ciclos de “releases” (ou versões) menores. Após o início do desenvolvimento, o
gerente de projeto ou líder técnico deve concientizar aos desenvolvedores que existe um
prazo a cumprir e que deve evitar um ciclo infinito de atualização do protótipo.




MODELO INCREMENTAL


Modelo iterativo e incremental é uma alternativa para solução de problemas enfrentado no
modelo cascata. Nesse modelo, considera-se o desenvolvimento do software em ciclos
iterativos onde uma pequena porção dos requisitos passa por todas as etapas de
desenvolvimento como em um modelo cascata. Ao final de cada ciclo de iteração têm-se uma
nova versão do software, a qual será incrementada a cada novo ciclo que ocorrer.
Ao final de cada ciclo de iteração pode-se ter uma versão do software. Isso reduz a ansiedade
e a expectativa do usuário em relação ao software. Além disso, o modelo possibilita que o
software seja desenvolvido em módulos de acordo com a necessidade e características do
projeto.
Embora pareça que o modelo imprima uma forma mais ágil de desenvolvimento, um
planejamento formal não é desprezado. A idéia das iterações desse modelo é permitir que o
sistema seja melhor compreendido e refinado a cada etapa. Dessa forma, a qualidade do
software pode ser provida gradualmente à medida que seu desenvolvimento evolui.




RATIONAL UNIFIED PROCESS (RUP)
A metodologia RUP (Rational Unified Process) é um processo que fornece uma metodologia
disciplinada de desenvolvimento utilizando um conjunto de ferramentas, modelos e
entregáveis. A RUP se diferencia das demais metodologias por ser proprietária de uma
empresa, no caso a IBM Rational.
A metodologia padronizada pode ser atrativa para grandes organizações que necessitem de
uma linguagem comum e ferramentas padronizadas para toda a organização. A metodologia
RUP utiliza UML (Unified Modeling Language) para comunicar os requisitos, arquiteturas e
modelagens. A UML foi originalmente criada pela Rational Software (adquirida pela IBM) é
atualmente é mantida pelo OMG (Object Management Group –http://www.omg.org/).

Nesse modelo, considera-se o desenvolvimento do software em ciclos iterativos onde uma
pequena porção dos requisitos passa por todas as etapas de desenvolvimento como em um
modelo cascata. Ao final de cada ciclo de iteração têm-se uma nova versão do software, a qual
será incrementada a cada novo ciclo que ocorrer.
O RUP é estruturado ema duas dimensões, como pode ser observado na Figura 4:
            Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os
               aspectos do ciclo de vida do processo à medida que se desenvolve.
            Eixo Y - Componentes de processo: produção de um conjunto específico de
               artefatos (produtos) com atividades bem definidas.




                          Figura 4. Rational Unified Process (RUP)

As fases são seqüenciais, cada uma concluída por um marco principal. Cada fase é basicamente
um intervalo de tempo entre dois marcos principais.

Mais conteúdo relacionado

Mais procurados

Prototipagem
PrototipagemPrototipagem
Prototipagemjwainer
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppCloves da Rocha
 
Estrutura de Programas
Estrutura de ProgramasEstrutura de Programas
Estrutura de ProgramasSidney Roberto
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixCris Fidelix
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareBruno Bitencourt Luiz
 
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)Leinylson Fontinele
 
Documentação de Arquitetura de Software Aplicando o C4 Model
Documentação de Arquitetura  de Software Aplicando o C4 ModelDocumentação de Arquitetura  de Software Aplicando o C4 Model
Documentação de Arquitetura de Software Aplicando o C4 ModelDouglas Alonso
 
Aula - Interfaces e Estilos de Interação
Aula - Interfaces e Estilos de InteraçãoAula - Interfaces e Estilos de Interação
Aula - Interfaces e Estilos de InteraçãoFabio Moura Pereira
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IJoão Lourenço
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareCloves da Rocha
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Softwareeros.viggiano
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de softwareRondinelli Mesquita
 

Mais procurados (20)

Prototipagem
PrototipagemPrototipagem
Prototipagem
 
Fundamentos do java
Fundamentos do javaFundamentos do java
Fundamentos do java
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
 
Modelo cascata
Modelo cascataModelo cascata
Modelo cascata
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Estrutura de Programas
Estrutura de ProgramasEstrutura de Programas
Estrutura de Programas
 
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 1 - Prof.ª Cristiane Fidelix
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de Software
 
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)
Banco de Dados I - Aula 10 - Banco de Dados Relacional (Modelo Físico)
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Trabalho es prototipagem
Trabalho es   prototipagemTrabalho es   prototipagem
Trabalho es prototipagem
 
Documentação de Arquitetura de Software Aplicando o C4 Model
Documentação de Arquitetura  de Software Aplicando o C4 ModelDocumentação de Arquitetura  de Software Aplicando o C4 Model
Documentação de Arquitetura de Software Aplicando o C4 Model
 
Aula - Interfaces e Estilos de Interação
Aula - Interfaces e Estilos de InteraçãoAula - Interfaces e Estilos de Interação
Aula - Interfaces e Estilos de Interação
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Metodología de desarrollo
Metodología de desarrolloMetodología de desarrollo
Metodología de desarrollo
 

Destaque

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Annelise Gripp
 
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)Notícia explicativa da Carta Geológica de Vila do Bispo (1979)
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)arqueomike
 
CUENTO DEL PRINCIPITO
CUENTO DEL PRINCIPITOCUENTO DEL PRINCIPITO
CUENTO DEL PRINCIPITOdanielvare
 
Charlotte Stough - Sexto Empírico
Charlotte Stough - Sexto EmpíricoCharlotte Stough - Sexto Empírico
Charlotte Stough - Sexto EmpíricoJaimir Conte
 
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilva
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilvaAtiv 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilva
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilvajones_moreira
 
Inauguració setmana cultural
Inauguració setmana culturalInauguració setmana cultural
Inauguració setmana cultural03000962
 
Capítulo manhumirim nº 499
Capítulo manhumirim nº 499 Capítulo manhumirim nº 499
Capítulo manhumirim nº 499 Capitulo499
 

Destaque (20)

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
 
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)Notícia explicativa da Carta Geológica de Vila do Bispo (1979)
Notícia explicativa da Carta Geológica de Vila do Bispo (1979)
 
Modulo viii primera parte
Modulo viii primera parteModulo viii primera parte
Modulo viii primera parte
 
Presentacion1
Presentacion1Presentacion1
Presentacion1
 
CUENTO DEL PRINCIPITO
CUENTO DEL PRINCIPITOCUENTO DEL PRINCIPITO
CUENTO DEL PRINCIPITO
 
Bioética
BioéticaBioética
Bioética
 
Soy la mejor
Soy la mejorSoy la mejor
Soy la mejor
 
Boletin julio
Boletin   julioBoletin   julio
Boletin julio
 
La radio
La radioLa radio
La radio
 
Princípios gerais
Princípios geraisPrincípios gerais
Princípios gerais
 
การพัฒนาบุคลากร
การพัฒนาบุคลากรการพัฒนาบุคลากร
การพัฒนาบุคลากร
 
Aula 01
Aula 01Aula 01
Aula 01
 
Sistemas operacionais aula 02
Sistemas operacionais aula 02Sistemas operacionais aula 02
Sistemas operacionais aula 02
 
Fotos
FotosFotos
Fotos
 
Charlotte Stough - Sexto Empírico
Charlotte Stough - Sexto EmpíricoCharlotte Stough - Sexto Empírico
Charlotte Stough - Sexto Empírico
 
Martín fuentes
Martín fuentesMartín fuentes
Martín fuentes
 
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilva
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilvaAtiv 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilva
Ativ 1 4-tecnologiasnaescola_jonesmoreirasuaresdasilva
 
Inauguració setmana cultural
Inauguració setmana culturalInauguració setmana cultural
Inauguració setmana cultural
 
Capítulo manhumirim nº 499
Capítulo manhumirim nº 499 Capítulo manhumirim nº 499
Capítulo manhumirim nº 499
 

Semelhante a Processos de software

T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascatawilsonguns
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentaçãoerysonsi
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentaçãoerysonsi
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentaçãoerysonsi
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de softwarediha36
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individualAdivaldo_badinho
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de softwarediha36
 
Aula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptxAula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptxALEXANDRELISBADASILV
 
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfAthena542429
 
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...Rogério Almeida
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Fernando Vargas
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De SoftwareCursoSENAC
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1Tiago Vizoto
 
A Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareA Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareRobson Silva Espig
 

Semelhante a Processos de software (20)

T1 g13.modelo cascata
T1 g13.modelo cascataT1 g13.modelo cascata
T1 g13.modelo cascata
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Modelo cascata apresentação
Modelo cascata apresentaçãoModelo cascata apresentação
Modelo cascata apresentação
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Processo de software individual
Processo de software individualProcesso de software individual
Processo de software individual
 
Ciclo de vida de software
Ciclo de vida de softwareCiclo de vida de software
Ciclo de vida de software
 
Aula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptxAula 7 - Modelos de Ciclo de Vida.pptx
Aula 7 - Modelos de Ciclo de Vida.pptx
 
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdfO_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
O_Ciclo_de_Vida_do_Desenvolvimento_de_Sistemas.pdf
 
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...
Disciplina_Análise de Projeto de Sistema I - Metodologia Cascata e Processos ...
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Aula2 processos sw
Aula2 processos swAula2 processos sw
Aula2 processos sw
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2Apresentação estrela vs cmmi nivel 2
Apresentação estrela vs cmmi nivel 2
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Analise aula2
Analise aula2Analise aula2
Analise aula2
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Aula 2 modelo de processo de software1
Aula 2   modelo de processo de software1Aula 2   modelo de processo de software1
Aula 2 modelo de processo de software1
 
A Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de SoftwareA Evolucao dos Processos de Desenvolvimento de Software
A Evolucao dos Processos de Desenvolvimento de Software
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 

Mais de Computação Depressão

Sd08 (si) sistemas de arquivos distribuídos
Sd08 (si)   sistemas de arquivos distribuídosSd08 (si)   sistemas de arquivos distribuídos
Sd08 (si) sistemas de arquivos distribuídosComputação Depressão
 
Sd02 (si) gerenciamento de entrada e saída
Sd02 (si)   gerenciamento de entrada e saídaSd02 (si)   gerenciamento de entrada e saída
Sd02 (si) gerenciamento de entrada e saídaComputação Depressão
 

Mais de Computação Depressão (20)

Sd08 (si) sistemas de arquivos distribuídos
Sd08 (si)   sistemas de arquivos distribuídosSd08 (si)   sistemas de arquivos distribuídos
Sd08 (si) sistemas de arquivos distribuídos
 
Sd06 (si) exclusão mútua
Sd06 (si)   exclusão mútuaSd06 (si)   exclusão mútua
Sd06 (si) exclusão mútua
 
Sd05 (si) relógios e sincronização
Sd05 (si)   relógios e sincronizaçãoSd05 (si)   relógios e sincronização
Sd05 (si) relógios e sincronização
 
Sd04 (si) comunicação em sd
Sd04 (si)   comunicação em sdSd04 (si)   comunicação em sd
Sd04 (si) comunicação em sd
 
Sd03 (si) conceitos básicos de sd
Sd03 (si)   conceitos básicos de sdSd03 (si)   conceitos básicos de sd
Sd03 (si) conceitos básicos de sd
 
Sd02 (si) gerenciamento de entrada e saída
Sd02 (si)   gerenciamento de entrada e saídaSd02 (si)   gerenciamento de entrada e saída
Sd02 (si) gerenciamento de entrada e saída
 
Sd01 (si) sistemas de arquivos
Sd01 (si)   sistemas de arquivosSd01 (si)   sistemas de arquivos
Sd01 (si) sistemas de arquivos
 
Sd07 (si) eleição
Sd07 (si)   eleiçãoSd07 (si)   eleição
Sd07 (si) eleição
 
Ufbamat2013
Ufbamat2013Ufbamat2013
Ufbamat2013
 
Ufbaingles2013
Ufbaingles2013Ufbaingles2013
Ufbaingles2013
 
Ufbagab mat 2013
Ufbagab mat 2013Ufbagab mat 2013
Ufbagab mat 2013
 
Ufbagab ingles2013
Ufbagab ingles2013Ufbagab ingles2013
Ufbagab ingles2013
 
Ufbagab fis 2013
Ufbagab fis 2013Ufbagab fis 2013
Ufbagab fis 2013
 
Ufbafisqui2013
Ufbafisqui2013Ufbafisqui2013
Ufbafisqui2013
 
Ufbagab qui 2013
Ufbagab qui 2013Ufbagab qui 2013
Ufbagab qui 2013
 
Questesdetecnologia ano2002
Questesdetecnologia ano2002Questesdetecnologia ano2002
Questesdetecnologia ano2002
 
Questesdematemtica ano2003
Questesdematemtica ano2003Questesdematemtica ano2003
Questesdematemtica ano2003
 
Questesdematemtica ano2002
Questesdematemtica ano2002Questesdematemtica ano2002
Questesdematemtica ano2002
 
Questesdefundamentos ano2003
Questesdefundamentos ano2003Questesdefundamentos ano2003
Questesdefundamentos ano2003
 
Questesdefundamentos ano2002
Questesdefundamentos ano2002Questesdefundamentos ano2002
Questesdefundamentos ano2002
 

Processos de software

  • 1. DISCIPLINA DE ENGENHARIA DE SOFTWARE Processos Tradicionais de Software Um processo de software é um conjunto de atividades que leva à produção de um produto de software. Os processos de software formam a base para o controle gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são aplicados , os produtos de trabalho (modelos, documentos, dados, relatórios, etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas. Além dos processos de software, existem outros dois elementos fundamentais da engenharia de software, os quais são métodos e ferramentas. Os métodos fornecem a técnica de “como” fazer para construir software. As ferramentas de engenharia de software fornecem o apoio automatizado ou semi-automatizado para o processo e para os métodos. As ferramentas de engenharia de software auxiliada por computador (CASE – Computer-Aided Software Engineering) que existem atualmente no mercado ainda não automatizam todas as atividades dos processos, mas a maioria. Não existe um processo ideal, e várias organizações desenvolveram abordagens iteiramente diferentes para o desenvolvimento de software. A seguir são detalhados os processos de desenvolvimento de software tradicionais mais conhecidos: MODELO EM CASCATA Também conhecido como modelo clássico. A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americana nos anos 60 para permitir o desenvolvimento de software militares. No modelo em cascata, o projeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finaliza uma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com os resultados da fase atual. A Figura 1 ilustra as fases deste modelo ou processo de desenvolvimento de software.
  • 2. Figura 1. Fases do Modelo em Cascata. Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projeto é complicado. A metodologia em cascata é extremamente formal, como seria normal de se esperar de uma metodologia cuja concepção é militar. Pode-se afirmar que a metodologia em cascata é baseada em documentos e com certeza possui uma enorme quantidade de “entregáveis” e saídas que nada mais são do que documentos. Outra característica deste modelo é o alto valor dado ao planejamento. O forte planejamento inicial reduz a necessidade de planejamento contínuo conforme o andamento do projeto. A Metodologia em Cascata funciona bem quando os requisitos do usuário são rígidos e podem ser conhecidos com antecedência. O sistema de navegação do ônibus espacial, por exemplo, pode ser um bom candidato para esta metodologia. Contudo, o foco em documentos para descrever o que os clientes e usuários necessitam pode levar a problemas. Muito frequentemente aparecem problemas de comunicação que resultam em um software de baixa qualidade. Os documentos produzidos pelo processo de desenvolvimento podem ser perfeitos, mas o produto real pode ser defeituoso ou inutilizável. De uma forma ou de outra, muitas das metodologias de desenvolvimento são variações da metodologia de Desenvolvimento em Cascata – apenas diferenciando-se uma das outras em relação à velocidade, tipos de entregáveis e flexibilidade. A metodologia de Desenvolvimento em Cascata pode funcionar bem em ambientes rígidos e fortemente controlados, como por exemplo, os militares, mas possui sérios inconvenientes no cenário comercial. No cenário comercial, somente recomenda-se usar este modelo para sistemas pequenos e simples, pois se for um sistema complexo vai demorar muito tempo até mostrar o funcionamento do sistema. Existem casos onde o contratante do desenvolvimento do software se beneficia pela auditoria imposta pelos métodos do Desenvolvimento em Cascata.
  • 3. MODELO EM ESPIRAL O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata. Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje uma atividade importantíssima no desenvolvimento de software devido à imaturidade da área e à falta de conhecimento, técnicas e ferramentas adequadas. O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro estágios, como pode ser observado na Figura 2. Figura 2. Modelo Espiral  No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições.  No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou realizar-se simulações do software.  O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação
  • 4. que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente.  O estágio 4 compreende a revisão das etapas anteriores e o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo. PROTOTIPAÇÃO A modelo de Prototipagem Evolutiva é uma abordagem que visualiza o desenvolvimento de concepções do sistema conforme o andamento do projeto. Esta metodologia baseia-se na utilização de prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples desenhos, imagens gráficas e até cópias completas em HTML do sistema esperado. Com esta abordagem visual, o cliente tem uma certeza maior do resultado final. A figura abaixo ilustra esta metodologia. Figura 3. Prototipação Evolutiva O desenvolvimento real não inicia até que o protótipo final seja aceito. Esta metodologia é até certo ponto bastante flexível a respeito de mudanças de requisitos; contudo, este processo precisa de muito controle. Um ponto negativo deste modelo é que o planejamento efetivo pode ser difícil e os projetos podem ser reduzidos a um ciclo Codifica-Corrige depois que o desenvolvimento é iniciado.
  • 5. O aspecto de planejamento pode tornar-se um desafio, pois a equipe não tem certeza sobre quanto tempo levará o trabalho. Isto ocorre, em partes, porque o modelo é baseado em interfaces, e não se preocupa tanto com as interdepêndencias de mais baixo nível. Os clientes tem uma idéia de como eles querem utilizar o seu novo sistema e utilizam o protótipo como referência. O valor do protótipo porém, não deve ser super-estimado, pois, apesar de tudo, ele não é um software funcional. Existem riscos associados com o planejamento devido a natureza interativa do desenvolvimento, mas eles são atenuados de certa forma através da prototipagem e ciclos de “releases” (ou versões) menores. Após o início do desenvolvimento, o gerente de projeto ou líder técnico deve concientizar aos desenvolvedores que existe um prazo a cumprir e que deve evitar um ciclo infinito de atualização do protótipo. MODELO INCREMENTAL Modelo iterativo e incremental é uma alternativa para solução de problemas enfrentado no modelo cascata. Nesse modelo, considera-se o desenvolvimento do software em ciclos iterativos onde uma pequena porção dos requisitos passa por todas as etapas de desenvolvimento como em um modelo cascata. Ao final de cada ciclo de iteração têm-se uma nova versão do software, a qual será incrementada a cada novo ciclo que ocorrer. Ao final de cada ciclo de iteração pode-se ter uma versão do software. Isso reduz a ansiedade e a expectativa do usuário em relação ao software. Além disso, o modelo possibilita que o software seja desenvolvido em módulos de acordo com a necessidade e características do projeto. Embora pareça que o modelo imprima uma forma mais ágil de desenvolvimento, um planejamento formal não é desprezado. A idéia das iterações desse modelo é permitir que o sistema seja melhor compreendido e refinado a cada etapa. Dessa forma, a qualidade do software pode ser provida gradualmente à medida que seu desenvolvimento evolui. RATIONAL UNIFIED PROCESS (RUP) A metodologia RUP (Rational Unified Process) é um processo que fornece uma metodologia disciplinada de desenvolvimento utilizando um conjunto de ferramentas, modelos e entregáveis. A RUP se diferencia das demais metodologias por ser proprietária de uma empresa, no caso a IBM Rational. A metodologia padronizada pode ser atrativa para grandes organizações que necessitem de uma linguagem comum e ferramentas padronizadas para toda a organização. A metodologia RUP utiliza UML (Unified Modeling Language) para comunicar os requisitos, arquiteturas e modelagens. A UML foi originalmente criada pela Rational Software (adquirida pela IBM) é atualmente é mantida pelo OMG (Object Management Group –http://www.omg.org/). Nesse modelo, considera-se o desenvolvimento do software em ciclos iterativos onde uma pequena porção dos requisitos passa por todas as etapas de desenvolvimento como em um modelo cascata. Ao final de cada ciclo de iteração têm-se uma nova versão do software, a qual será incrementada a cada novo ciclo que ocorrer.
  • 6. O RUP é estruturado ema duas dimensões, como pode ser observado na Figura 4:  Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.  Eixo Y - Componentes de processo: produção de um conjunto específico de artefatos (produtos) com atividades bem definidas. Figura 4. Rational Unified Process (RUP) As fases são seqüenciais, cada uma concluída por um marco principal. Cada fase é basicamente um intervalo de tempo entre dois marcos principais.