|
|
| (Uma revisão intermediária por um outro usuário não está sendo mostrada) |
| Linha 1: |
Linha 1: |
| Esta pesquisa deve fornecer um conteúdo atualizado sobre o tema acima. Não esqueça de incluir as
| |
| referëncias (fontes) no último item, reforçando que não deve ser um Copy/Paste e sim uma síntese
| |
| das pesquisas que fizer.
| |
| <br>
| |
|
| |
|
| = Conceito =
| |
| <br>
| |
|
| |
| Quando se deseja projetar um sistema, é de suma importância que o desenvolvedor siga um roteiro, uma série de passos que permitam que seu projeto seja o mais dinâmico possível. Por dinâmico, entende-se a capacidade de projetar e incorporar de forma mais clara possível, utilizar recursos de forma inteligente, e tentar tornar seu sistema atemporal para que ele seja reaproveitado tantas vezes quanto for possível.
| |
|
| |
| O Processo de Software diz respeito ao gerenciamento da criação do software desde seu planejamento a ideia inicial até a sua distribuição comercial.
| |
|
| |
|
| |
|
| |
| Contém geralmente as seguintes etapas:
| |
|
| |
| - Análise
| |
| - Design
| |
| - Desenvolvimento do código / algoritmo
| |
| - Testes e Manutenção
| |
|
| |
| = Modelo Cascata =
| |
| <br>
| |
|
| |
| O '''Modelo Cascata''' também conhecido como '''Paradigma Clássico de Vida Útil''' (The Classic ''life-cycle'' paradigm) se originou nos anos 60 (sendo o mais antigo) pela demanda das indústrias de defesa, aeroespaciais nos Estados Unidos e também para aplicações comerciais, por softwares de larga escala. A formalização do termo é atribuída ao Cientista da Computação '''Winston W. Royce''' que escreveu um artigo em 1970 sobre o modelo. (Que no caso era uma crítica à essa forma de desenvolvimento, pois Royce era adepto da '''abordagem iterativa'''.)
| |
| Tal processo de desenvolvimento idealiza as etapas de forma linear ou sistemáticas fases sequenciais colocando os desenvolvedores inicialmente no patamar de '''requisitos de alto nível''', passando pelos '''testes''', chegando assim na fase final que é a '''distribuição''', e a manutenção contínua do mesmo.
| |
| Nas últimas três décadas, o modelo tem sido amplamente criticado, inclusive até seus maiores defensores levantavam questionamentos sobre a eficácia pois embora teoricamente o modelo siga uma linha de raciocínio bem elaborada e permita um desenvolvimento bem sólido e planejado, sua aplicação prática não funciona bem assim pois projetos reais muito dificilmente vão seguir à risca as etapas que o modelo propôs, o modelo em cascata embora tenha a iteração, ela acontece de forma indireta e qualquer mudança que ocorra no desenrolar do processo pode acabar gerando confusões. De início também é difícil para o cliente explicitar claramente todas suas necessidades, que é um requisito do modelo, além disso a versão operacional do projeto não estará disponível até as últimas etapas do processo, o que pode tornar pequenos erros se não detectados, um desastre total e comprometer todo o projeto. Portanto, para se utilizar o Modelo Cascata de forma inteligente, seria interessante que tivéssemos todos os requisitos bem definidos e estáveis.
| |
|
| |
| [[Arquivo:WF.png]]
| |
|
| |
| = Modelo Prototipação =
| |
| <br>
| |
|
| |
| Pode ocorrer muitas vezes do cliente requisitar objetivos do software mas não detalhar especificamente os requisitos ou até mesmo do desenvolvedor apresentar uma certa insegurança quanto a compatibilidade e (ou) adaptação em um sistema e também da sua interface.
| |
| Nesses casos é altamente recomendado o uso do Modelo de Prototipação.
| |
| Pode ser usada tanto isoladamente tanto em conjunto com qualquer outro modelo de desenvolvimento. O objetivo principal do Protótipo é simplesmente ser uma forma de identificar os requisitos de software.
| |
| o Processo de Prototipação inicia-se com a etapa de Comunicação onde se reúne com a equipe para explicitar a abrangência do software, relatar os requisitos já conhecidos e identificar as áreas onde que precisam de maior atenção quanto à definição; seguidamente ocorre a etapa de Modelação onde se cria um "Projeto Rápido" que pode ser descrito como as características do Software tangíveis ao usuário final, a partir do Projeto Rápido é finalmente criado o Protótipo que será aprimorado quantas vezes for necessário a partir das conclusões e necessidade dos desenvolvedores
| |
|
| |
|
| |
| [[Arquivo:PTT.png]]
| |
|
| |
| = Modelo Espiral =
| |
| <br>
| |
|
| |
| O '''Modelo Espiral''' foi introzido pelo Cientista da Computação '''Barry Boehm''' em seu artigo ''A Spiral Model of Software Development and Enhancement'' (1988), sua ideia é a fusão da iteratividade da prototipação e a a sistemática do '''Modelo Cascata'''.
| |
| Basicamente, no '''Modelo Espiral''' nós começamos desenvolvendo o Software e a cada iteração ele se torna mais completo até se aproximar da versão final, isso significa que não teremos o software sendo desenvolvido em um única etapa, e sim como o resultado de várias micro checagens (resultante de cada iteração).
| |
| É tido como o modelo mais viável para desenvolvimento de sistemas e softwares de larga escala pois permite um consenso mais claro entre desenvolvedor e cliente sobre os riscos.
| |
| Se divide em quatro etapas cíclicas, sendo respectivamente:
| |
|
| |
| '''Planejamento''': Determinação dos Objetivos, cronograma, requisitos iniciais, finalidade do projeto com base na demanda.
| |
| '''Análise de Riscos''': Resolução de riscos e estudo de alternativas.
| |
| '''Construção ou Execução''': Desenvolvimento e checagem.
| |
| '''Verificação''': Avaliação do usuário, e em caso de finalização do projeto, distribuição e suporte
| |
|
| |
| A cada iteração existe uma verificação ente a Análise de Riscos e a Construção denominada '''''go, non-go''''', é um ponto onde se analisa a viabilidade de dar continuidade ao projeto com base nos esforços necessários para tal.
| |
|
| |
| [[Arquivo:SPR.jpg]]
| |
|
| |
| = Modelo em Componentes =
| |
| <br>
| |
|
| |
| O Modelo em Componentes ou Componentes de Software Comercial de Prateleira (COTS - Commercial off-the-shelf) é um formato de desenvolvimento de software terceirizado em larga escala onde vende-se funcionalidades pré desenvolvidas para serem acopladas em outros softwares, ou seja, não é exclusivo, isso implica que ele provavelmente será mais barato, de maior qualidade pois a concorrência é maior e mais complexos pela experiência dos que desenvolvem nesse modelo, rápida implementação. Incorpora elementos do '''Modelo Espiral'''.
| |
| Exemplos de Softwares são Pacotes Office e Antivírus.
| |
|
| |
| = Comparação entre os modelos =
| |
| <br>
| |
|
| |
| Nós já sabemos que o '''Modelo em Cascata''' é o mais velho, e também o mais difícil de ser implementado e menos usado, como explicado anteriormente, ele é baseado em certezas e linearidade, o que um projeto '''Real''' dificilmente vai apresentar principalmente por causa de prazos e a falta de um dinamismo pleno por parte da equipe que eventualmente terá problemas.
| |
| Já o Modelo em Espiral é um dos mais usados até hoje que pode ser aproveitado de várias formas, não ficando somente preso à descrição clássica (podemos usá-lo em conjunto com o '''COTS''' por exemplo), é muito mais dinâmico que o Modelo em Cascata pelo fato de ser um modelo iterativo, parte da premissa que todo projeto é suscetível a falhas por isso necessita de constantes verificações e adaptações, diferentemente do inflexível '''Modelo em Cascata'''.
| |
|
| |
| O '''COTS''' pode ser mais entendido como um modelo de gerenciamento e administração do projeto do que do seu desenvolvimento propriamente dito, isso significa que a maior parte do tempo o empreendedor não se preocupará com o desenvolvimento do software propriamente dito e sim com os riscos de mercado tal como a implantação do mesmo, como explicitado anteriormente, é derivado do '''Modelo em Espiral'''.
| |
|
| |
| O '''Modelo em Prototipagem''' é uma ferramenta, embora possa ser usado separadamente, é geralmente implantado em conjunto, também com o '''Espiral''', sua vantagem é o levantamento de requisitos e consequentemente um dinamismo na totalidade do projeto e esclarecimento do mesmo.
| |
|
| |
| = Referências bibliográficas =
| |
| <br>
| |
|
| |
| Michael A. Cusumano and Stanley Smith - MIT Sloan School of Management (1995). ''Beyond the Waterfall: Software Development at Microsoft''
| |
| Roger S. Pressman and Bruce Maxim - ''Software Engineering: A Practitioner's Approach''.
| |