Os Modelos Prescritivos

Faculdade de Tecnologia de São Paulo

Gabriel de Souza Moreira dos Santos

Matrícula: 18101086

Modelos Prescritivos

São Paulo, Novembro de 2018

Índice

1. Introdução..............................................................3
2. Artigo Científico......................................................3
3. Modelo Cascata.....................................................4
4. Modelo Incremental...............................................4
5. RAD.......................................................................5
6. Prototipação..........................................................5
7. Comentários Finais………….................................6
8. Referências…………………………………………..7

1. Introdução

Este trabalho tem como principal objetivo resumir o artigo “Managing the Development of Large Software Systems” e também com alguns modelos de processos, entre eles: Modelo Cascata, Modelo Incremental, RAD e Prototipação.

2. Managing the development of large software systems 

O artigo de Royce de 1970 é geralmente considerado o papel que definiu o modelo "cascata" do processo de software. De fato, Royce demonstrou que, embora o desenvolvimento de grandes sistemas de software exigisse uma abordagem mais completa, havia um risco inerente em uma abordagem sequencial de passagem única. Ele propôs uma abordagem iterativa e incremental e defendeu que os projetos passem pelo menos duas vezes. pode-se optar em seguir o desenvolvimento em um modelo Cascata.

Royce havia determinado que o desenvolvimento de programas de computador, independentemente do tamanho ou da complexidade, poderia ser dividido em dois estágios de desenvolvimento: Análise e Codificação. Para pequenos projetos de desenvolvimento de software, essas duas etapas eram suficientes, mas não para o desenvolvimento de sistemas de software maiores. Estes exigem muitos passos adicionais para trás e para frente, o que dá ao desenvolvimento um caráter interativo.

Para explicar de maneira mais clara este desenvolvimento iterativo, Royce propôs uma série de abordagens, embora ele nunca tenha usado o termo cascata nem o tenha defendido como uma metodologia eficaz. Ele os chamou de "etapas de implementação para desenvolver um grande programa de computador para entrega a um cliente". Royce previu uma lacuna importante nessa metodologia, que ele descreveu como: A fase de teste que ocorre no final do ciclo de desenvolvimento é o primeiro evento para o qual a temporização, o armazenamento, as transferências de entrada / saída, etc., são experimentados como distintos da análise. Esses fenômenos não são precisamente analisáveis. Eles não são as soluções para as equações diferenciais parciais padrão da física matemática, por exemplo. No entanto, se esses fenômenos não satisfazem as várias restrições externas, invariavelmente, é necessário um grande redesenho. Uma simples correção octal ou refazer um código isolado não corrigirá esse tipo de dificuldade. É provável que as mudanças necessárias no design sejam tão perturbadoras que os requisitos de software nos quais o design é baseado e que fornecem a justificativa para tudo são violados ...

De acordo com Royce, no modelo de processo, "as iterações de projeto nunca se limitam ao passo sucessivo", e para esse modelo sem iteração é "arriscado e convida à falha". Como alternativa, Royce propôs um desenvolvimento mais incremental, onde cada passo seguinte se conecta ao passo anterior

1. Modelo Cascata

O Modelo em Cascata é um modelo de desenvolvimento de software sequencial no qual o processo é visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. A origem do termo cascata é frequentemente citado como sendo um artigo publicado em 1970 por Royce; ironicamente, Royce defendia uma abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata. Royce originalmente descreve o que é hoje conhecido como o modelo em cascata como um exemplo de um método que ele argumentava ser um risco e um convite para falhas. Como já mostrado no tópico anterior

No modelo em cascata, uma ordem precisa ser seguida, sendo ela: Requerimento, Projeto, Construção, Integração, Teste e Depuração, Instalação e Manutenção de Software.

Para seguir um modelo em cascata, o progresso de uma fase para a próxima se dá de uma forma puramente sequencial. Por exemplo, inicialmente completa-se a especificação de requisitos — elaborando um conjunto rígido de requisitos do software, embora as especificações dos requisitos reais sejam mais detalhadas, em um procedimento para projeto.

Após as fases de implementação e integração estarem completas, o produto de software é testado e qualquer problema introduzido nas fases anteriores é removida aqui. Com isto o produto de software é instalado, e mais tarde mantido pela introdução de novas funcionalidades e remoção de defeitos.

Portanto o modelo em cascata move-se para a próxima fase somente quando a fase anterior está completa e perfeita. Desenvolvimento de fases no modelo em cascata são discretas, e não há pulo para frente, para trás ou sobreposição entre elas.

1. Modelo Incremental

O Desenvolvimento Iterativo e Incremental é um dos clássicos modelos de processo de desenvolvimento de software criado em resposta às fraquezas do modelo em cascata, o mais tradicional.

Desenvolvimento Incremental é uma estratégia de planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e integradas quando completas. Não implica, requer ou pressupõe desenvolvimento iterativo, interativo ou em cascata – os três são estratégias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver todo o sistema com uma integração única.

Desenvolvimento iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e melhorias de partes do sistema é pré-definido. Isto não pressupõe desenvolvimento incremental, mas funciona muito bem com ele. Uma diferença típica é que a saída de um incremento não é necessariamente assunto de um refinamento futuro, e seu teste ou retorno do usuário não é utilizado como entrada para planos de revisão ou especificações para incrementos sucessivos. Ao contrário, a saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas.