Resumo aula 21

Processos de produção de software

 

 

Modelo Clássico (“Cascata”)

É o processo mais antigo e o mais conhecido.

Desenvolvedores seguem basicamente alguns passos na seguinte ordem:

1. Estudam requisitos
2. Analisam estes requisitos
3. Projetam uma solução aproximada
4. Arquitetam um framework para a solução
5. Desenvolvem o código
6. Testam
7. Colocam em uso
8. Fazem a manutenção

Embora o modelo cascata ter sido o paradigma mais utilizado na Engenharia de Software, ele é extremamente passivo e formalista, o tornando bastante burocrático, uma vez que a questão da documentação (elaboração e aprovação) “amarra” a continuidade do processo de produção.

Se por um lado esse modelo trouxe disciplina ao desenvolvimento de software, ele é mais indicado para modelos que apresentem seus requisitos bem conhecidos antecipadamente já que a rigidez do modelo dificulta mudanças de requisitos e de gerências futuras, coisas freqüentes no processo de desenvolvimento de um software.

 

Modelo Espiral

Diferencia do Modelo de Cascata por não ser linear, e sim cíclico, com um incremento nas funcionalidades do software conforme um ciclo é concluído.

Cada ciclo consiste em quatro estágios, onde:

Primeiro estágio – composto pela determinação dos objetivos do projeto

Segundo estágio – avaliação dos riscos envolvidos na escolha das alternativas para execução dos objetivos

Terceiro estágio – o desenvolvimento das atividades previstas é concretizado. A parte de dificuldade econômica para continuidade do projeto é analisada neste estágio, podendo sair de um projeto lógico para um projeto detalhado, ou ainda para uma segunda versão.

Quarto estágio – planejamento das fases seguintes e também avaliação e revisão dos avanços atingidos com definição de metas seguintes.

Modelo Extreme Programming (XP)

É um dos processos conhecidos mais ágeis atuais.

Primeiramente, escrevem-se testes automáticos para prover objetivos concretos para o desenvolvimento. Em seguida, começar a se codificar em dupla (pessoas de mesmo nível técnico). A codificação é finalizada quando todos os testes são atingidos e não se consegue imaginar nenhum outro teste a ser realizado. A parte de design e arquitetura do software vem da refatoração e somente depois da codificação. O design é feito pelas mesmas pessoas que codificaram.

Dessa maneira, o sistema ainda incompleto, mas já funcional é demonstrado para o cliente e pego seu feedback. E então, o ciclo se inicia novamente com mais testes.

Conforme falado pelo professor em aula, a jargão “O código é rei” se aplica nesse método, uma vez que utiliza-se de pouca documentação sobre definições e arquiteturas.

 

Modelo V

Modelo padrão da administração federal Alemã que descreve não só o que tem que ser feito, mas também como, quando e quem é responsável por fazer isto. Descreve as atividades e os resultados que tem que ser produzidos durante o desenvolvimento de software.

Este modelo sumariza os passos principais a serem tomados em conjunto com os correspondentes a serem entregues usando algumas vezes sistemas de validação computadorizada.

 

Rational Unified Process

Processo baseado em uma série de princípios de desenvolvimento de software, tais como interatividade no desenvolvimento de software, gerenciamento de requisitos, arquitetura baseada em componentes, visualização do modelo, controle de qualidade e controle de mudanças.

O processo foi desenhado utilizando-se as mesmas técnicas que a equipe usa para fazer o design de software: UML.

O ciclo de vida do RUP é uma implementação do modelo Espiral, contendo quatro fases, conforme pode-se analisar no gráfico abaixo:

Modelo de Prototipação

Modelo onde o principal objetivo é construir um protótipo robusto em uma estrutura e refiná-lo constantemente. O protótipo evolucionário, quando construído, forma o coração do novo sistema, e as improvisações e requisições futuras serão construídas nele.

Acredita-se que não é possível entender a todos os requisitos e constrói-se apenas aqueles que estão bem entendidos. Com isso, este técnica permite que a equipe de desenvolvedores adicionem funcionalidades ou façam modificações que não poderiam ser concebidas durante a fase de requisitos e de design.

Neste modelo, tem-se a vantagem de que os desenvolvedores podem focar no desenvolvimento de partes do sistema que eles entenderam ao invés de trabalhar no desenvolvimento do sistema inteiro.