Resumo Engenharia De Software

A crise do software

Foi um termo utilizado em 1970, nessa época a própria engenharia de software nem existia, o termo expressava as dificuldades do software em ser desenvolvido frente ao rápido desenvolvimento e demanda do mesmo. Falava também da complexidade dos problemas e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionasse adequadamente.

As causas da crise foram:

• Projetos estourando o orçamento

• Projetos estourando o prazo

• Software de baixa qualidade

• Softwares que não atingiam os requisitos

As soluções formuladas foram:

• Análise econômica de sistemas de informações

• O uso de melhores técnicas, métodos e ferramentas

• Interesse do governo em treinamento e educação

A crise do software não deixou de existir, e está vigente até hoje em determinados projetos que não seguem a engenharia.

Ciclo de vida

O clico de vida de um software pode ser definido como, as etapas do desenvolvimento do mesmo. Desde de seu começo até seu desaparecimento, o objetivo é permitir a validação do desenvolvimento do software. Verificar o processo de desenvolvimento, ou seja, a adequação dos métodos.

Quanto mais tarde erros são detectados em um projeto, maiores os custos, com o ciclo de vida é possível determinar os erros o mais depressa possível, com isso a qualidade do software só aumenta, como também são melhorados os custos e os prazos.

O fluxo de um processo de software pode ser dado da seguinte forma:

Comunicação >> Planejamento >> Modelagem >> Construção >> Entrega

Modelos de Ciclo de Vida:

Os modelos de ciclo de vida definem o desenvolvimento do software, suas etapas, bem como os documentos que validam cada uma das etapas, para poder se passar para a próxima.

Modelo em cascata:

Este é o modelo mais antigo, mas ainda o mais usado, ele segue uma sequência linear. Ao fim de cada fase é produzido um documento para validar a passagem para a próxima fase.

Vantagens: Oferece uma maneira de tornar o processo mais visível. Facilita o planejamento.

Desvantagens: Projetos reais raramente seguem um fluxo sequencial. Os requisitos se alteram durante o projeto.

Comunicação

Planejamento

Modelagem

Construção

Entrega

Modelo em V:

Parte do princípio que os procedimentos de verificação da conformidade do software e as especificações devem ser elaboradas logo durante as fases de concepção, início.

Modelo de prototipação:

O objetivo é entender os requisitos do usuário. Possibilita que o desenvolvedor crie um modelo do software que deve ser construído, podendo ser no papel ou executável.

Vantagens: Os protótipos constituem uma boa pratica para melhorar as especificações dos requisitos. Partes do protótipo podem vir a ser usadas no sistema final.

Desvantagens: Custo elevado. Atraso no desenvolvimento.

Modelo Espiral:

Visa obter as melhores características do modelo clássico e da prototipagem. É dividido em fases, sendo que essas fases são repetidas várias vezes.

Vantagens: Possibilidade de melhorar o sistema a cada interação. Diminui a manutenção.

Desvantagens: É um modelo complexo, requer uma atenção maior. É relativamente novo.

Modelo Incremental:

É uma combinação entre o modelo linear e a prototipação. O desenvolvimento deste modelo é dividido em etapas, chamadas de incremento. Em cada incremento é realizado todo o ciclo de desenvolvimento do software. Cada etapa produz um sistema totalmente funcional.

Vantagens: Existe um risco menor de fracasso do software. Reduz a chance de mudança de requisito.

Desvantagens: O número de interações não pode ser definido no início do processo. O fim do processo não pode ser previamente determinado.

Modelo RAD:

Enfatiza um ciclo de desenvolvimento curto. A construção é baseada em complementos. É usado principalmente para aplicações de sistema de informação.

Vantagens: Baseado em componentes. Pode ser desenvolvido em várias equipes.

Desvantagens: É necessário desenvolvedor e cliente comprometidos. Não é apropriado para qualquer aplicação.

Modelo Sincronizar e Estabilizar:

O processo é dividido em incorporações, onde cada incorporação é realizada por uma série de pequenas equipes que trabalham em paralelo. No final de cada dia as equipes sincronizam os vários componentes abordados no processo e testam o produto. A estabilização acontece ao fim de cada incorporação, qualquer falha encontrada até então, será corrigida. E depois a incorporação será “congelada”, ou seja, não serão feitas mais especificações.

A Microsoft adota emblematicamente este modelo.

Modelo de Codificar e Corrigir:

Esse modelo requer pouca experiência. Não há tempo gasto em planejamento, documentação, gestão de qualidade, etc.

Mas é um modelo perigoso, não há formas de assegurar a qualidade e identificar riscos. Se houverem falhas não percebidas imediatamente isso resultará em retrabalho.

Modelo de Software Aberto:

Pode ser dividido em duas fases.