Engenharia de Software: Processos, Requisitos e Modelos

Processos de Desenvolvimento de Software

Brainstorming: Várias pessoas pensam em várias ideias e não podem criticá-las, apesar de gerar o máximo possível para resolver o problema.

Se é um processo, sai um produto, o software. A Engenharia de Software basicamente estuda esse processo devido à sua complexidade e necessidade de julgamento humano.

• Especificação de Software: Funcionalidades e restrições.
• Projeto e Implementação: Atender à especificação.
• Validação de Software: Válido para garantir que faz o que o cliente quer.
• Evolução de Software: Deve evoluir para atender necessidades mutáveis do cliente.

Por exemplo: Termina Requisitos, sai o documento de especificação de requisitos. Esse documento é um produto intermediário; há vários produtos em várias atividades.

Processo precisa de requisitos: Um deles é atender aos requisitos da lei.

Modelo de Código: O programador conserta os erros. Isso falha no modelo Cascata, pois ele descobre mais requisitos.

Modelo Cascata

No Cascata, um passo depende do outro e não se volta atrás. É bom para projetos:

• Adequado para projetos complexos, grandes e críticos.
• Bom para requisitos bem compreendidos e já assinados pelo cliente.

A reunião é terminada quando se fecha o documento "SRS" (Especificação de Requisitos de Software).

Modelos Ágeis

Os Modelos Ágeis são o oposto do Cascata. Ágil não precisa de um documento por etapa.

• O objetivo é colocar o software para funcionar, não gerar documentos.
• Prioriza o software; o Cascata prioriza o documento.

Desenvolvimento Evolucionário

Faz uma implementação inicial e refina com base em comentários. Os dois tipos fundamentais são:

• Exploratório: Trabalhar com o cliente para explorar os requisitos e entregar um sistema final.
• Prototipagem Descartável (Throwaway): Compreender os requisitos do cliente e melhorar as definições do sistema.

É adequado para um sistema que atenda às necessidades imediatas do cliente, de pequeno e médio porte. Já para os de grande porte, pensa-se em um processo que use as melhores características do Cascata e do Evolucionário.

Engenharia Baseada em Componentes

É reutilizar um programa, tendo três estágios:

1. Analisar os Componentes: Dada uma especificação, é feita uma busca pelos componentes para implementá-la.
2. Modificação de Requisitos: Os requisitos são analisados.

Projeto de Sistemas com Reuso: Um *framework* é projetado ou reutilizado.

A vantagem é a redução da quantidade de software a ser desenvolvido, reduzindo custo e risco, e levando a uma entrega mais rápida.

Mas se o programa não atende à maioria dos requisitos do cliente, é adequado começar tudo de novo.

Classificação CASE

CASE são ferramentas que apoiam o processo de software.

Tipos: ferramenta de planejamento, edição, prototipagem, etc.

Requisitos

Requisitos: Descrições dos serviços fornecidos pelo sistema e restrições operacionais.

Engenharia de Requisitos: Processo de descobrir, analisar, documentar e verificar esses serviços e restrições.

• Requisitos de Usuário: Declaração em linguagem natural com diagramas, dos serviços e restrições do sistema.
• Requisitos de Sistema: Descrição detalhada do serviço e restrições do sistema (parte do programador, ex: como ele vai fazer tal parte).

Tipos de Requisitos

• Requisitos Funcionais: Declarações de serviços que o sistema deve oferecer (relaciona a função, ex: tela azul).
• Requisitos Não Funcionais: Restrições sobre os serviços oferecidos pelo sistema. Fazem parte do funcionamento, mas não são o principal; relacionam-se à performance, sinônimo de qualidade.
• Requisitos de Domínio: Refletem a característica e restrições do domínio (específico da área).

Conflitos e Especificação

Requisitos Conflitantes: Performance e segurança.

Exemplo: Recuperar a senha na sua conta via e-mail. Performance: já estará no e-mail. Segurança: o cliente até desiste pela demora.

Um sistema grande e complexo é difícil pegar todos os requisitos.

A relação ideal é: Cliente > Requisitos > Desenvolve. Às vezes, o cliente sabe o que quer, o programador faz, e o cliente começa a colocar mais requisitos, invadindo a liberdade do programador. Resumindo: é especificar o que o cliente quer e dar liberdade para o programador; não pode especificar tanto nem deixar vago.

Classificar um requisito não pode excluir outro.

Prioridades de Requisitos

• Requisitos de Produto: Facilidade de uso > Eficiência > Confiabilidade > Portabilidade.
• Requisitos Organizacionais: Entrega > Implementação > Padrões.
• Requisitos Externos: Interoperabilidade > Legais.

Métricas para Especificar Requisitos Não Funcionais

Velocidade > Tamanho > Uso > Confiabilidade.

Problemas com a Linguagem Natural

Ambiguidade > Flexibilidade.

Como resolver: Padronização, utilizar *templates* > Gráficos > Facilidade de expressão.

Classificação ISO/IEC 9126

Segundo a ISO/IEC 9126:

• Funcionalidade: Qual será a função do produto.
• Usabilidade: Se o produto necessita de mais ou menos treino.
• Confiabilidade: Capacidade do software ser entregue e executado sem falhas.
• Eficiência: Desempenho do sistema em realizar suas funções do modo mais eficaz possível.
• Manutenibilidade: Abertura para novas modificações.
• Portabilidade: Ser executado em qualquer plataforma.

Casos de Uso: O modelo é uma forma ágil para capturar requisitos de software.