Engenharia de Software: Processos e Requisitos

Engenharia de Software: Organização, Produtividade e Qualidade

O processo de engenharia de software não é uma fabricação, mas sim um processo de desenvolvimento. O software não se desgasta, mas está em constante evolução e, por isso, novos erros surgirão.

É fundamental compreender o problema antes de iniciar o desenvolvimento.

Processos de software seguem passos previsíveis, um roteiro que ajuda a criar um resultado de alta qualidade dentro do prazo determinado.

UML: Linguagem de Modelagem Unificada

UML é uma linguagem padrão para a elaboração da estrutura de projetos de software. Ela pode ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software.

Orientação a Objetos

• Classes
• Objetos
• Atributos
• Métodos
• Herança

Análise

• Investigar o problema e os requisitos.
• Como o software será usado e quais as suas funções?
• Análise de requisitos e objetos do domínio.

Projeto

• Solução conceitual, seja de software ou hardware, que satisfaça os requisitos.
• O que é necessário para atender aos requisitos?

Análise e Projeto: Definir casos de uso, diagrama de interação e classes.

Três Tipos de Diagramas UML

• Diagramas de Estrutura: Diagrama de Classes, de Objetos, de Componentes, de Estrutura Composta, de Pacotes e de Implementação.
• Diagramas de Comportamento: Diagrama de Casos de Uso (usado por algumas metodologias durante a coleta de requisitos), Diagrama de Atividade e Diagrama de Máquina de Estado.
• Diagramas de Interação: Diagrama de Sequência, de Comunicação, de Tempo e de Visão Geral de Interação. (Todos derivados do Diagrama de Comportamento).

Erros Comuns

• Acreditar que existe alguma ferramenta ou técnica específica em software que fará uma diferença significativa em produtividade, redução de defeitos, confiabilidade ou simplicidade.
• UML é apenas uma notação padrão de diagramação.
• Achar que UML vai ajudar muito, mas não é tão importante quanto saber identificar requisitos, projetar e pensar em termos de objetos.

Levantamento de Requisitos: Como Fazer?

1. A partir de uma solicitação de produto, realiza-se o levantamento de requisitos.
2. Os interessados irão começar a fazer solicitações e colocar os pontos que são importantes.
3. Discussões sobre o que falta e tem que ser aprimorado.

• Lista de Objetos: Smartphone, PC.
• Lista de Serviços: O que o software vai fazer?
• Lista de Restrições: Aplicativo amigável, sistema deve reconhecer quando não está funcionando. O que o sistema não consegue fazer?
• Miniespecificação: Precisa de Android, iOS, internet, notificações.

É importante realizar uma reunião entre engenheiros e cliente para verificar se o projeto está de acordo com as expectativas.

Debate: É necessário fazer.

• Requisitos Normais: Objetivos e metas para um produto, obtidos durante as reuniões.
• Requisitos Esperados: Implícitos no produto, por serem fundamentais.
• Requisitos Fascinantes: Além da expectativa dos clientes.

Caso de Uso

• Identificar uma interação que irá ocorrer no sistema.
• Identificar os atores dessa interação.
• Suplementar com informações adicionais que descrevem a interação.

O processo pode e deve ser incremental.

1. Escolher a fronteira do sistema.
2. Identificar os atores principais.
3. Identificar os objetivos para cada ator principal.
4. Definir casos de uso que satisfaçam os objetivos dos usuários.

Refinando os Casos de Uso

Para cada etapa, faça as seguintes perguntas:

1. O ator pode fazer algo diferente neste ponto?
2. Existe a possibilidade de o ator encontrar alguma condição de erro neste ponto? (Se sim, qual seria?)
3. Existe a possibilidade de o ator encontrar algum outro tipo de comportamento neste ponto? (Se sim, qual seria?)

Conceito de Engenharia de Requisitos

• Definir os interessados.
• O cliente nem sempre tem clareza ou bom entendimento do que é necessário.

É uma ação de engenharia de software que se inicia durante a atividade de comunicação e continua na modelagem. É uma base sólida para o projeto e para a construção. Caso contrário, o software pode não atender às necessidades.

• Requisitos de Usuário: Declarações dos serviços que o sistema deverá fornecer aos usuários e as restrições existentes.
• Requisitos de Sistema: Descrições mais detalhadas. Funções, serviços e restrições operacionais do sistema. Definir o que vai ser implementado.

Concepção

Concepção = entendimento básico do problema, as pessoas interessadas, a natureza da solução e a eficácia da comunicação e da colaboração preliminares entre os interessados e a equipe.

Levantamento

• Levantar o que o cliente deseja.
• Verificar os requisitos do sistema.

Elaboração

• Expandir e refinar o que foi colhido nas fases de Concepção e Levantamento.
• Gerar alguns dos modelos do UML aqui.
• Definir as classes, as interações, os atributos, entre outros.
• Diversos diagramas são gerados.

Negociação

• Clientes podem pedir mais do que se pode fazer, ou mesmo, pedir coisas conflitantes.
• Devemos conciliar esses conflitos com a negociação.
• Uma forma é fazer iterações que priorizem os requisitos, avaliem os custos e os riscos e tratem dos conflitos internos, atingindo um nível de satisfação.

Especificação

• Documentos que especificam o software.
• Pode ser de diversas formas: documento escrito, modelos gráficos, modelo matemático, conjunto de cenários de uso, um protótipo, etc.
• Existe um modelo padrão (Software Requirements Specification - SRS).
• Mas pode ser diferente para cada caso:
  • Sistemas Grandes: Documento escrito, com linguagem natural e modelos gráficos.
  • Sistemas Pequenos: Talvez apenas cenários de uso.

Validação

• Realizar a validação dos requisitos (dos artefatos construídos, como os casos de uso e outros modelos).
• Verificar se todos os requisitos do software foram declarados de forma não ambígua.
• Uma forma é a Revisão Técnica: uma equipe valida os requisitos, encontrando possíveis erros, problemas de interpretação, inconsistências, conflitos, entre outros.

Gestão

• Os requisitos podem mudar ao longo da vida de um sistema.
• Atividades para ajudar a equipe de projeto a identificar, controlar e acompanhar as necessidades e suas mudanças a qualquer momento.

Interessados

Qualquer um que se beneficia de forma direta ou indireta do sistema. Cada pessoa tem um ponto de vista diferente, o que contribui para os requisitos.

Perguntas Iniciais: Quem está solicitando? Quem irá utilizar? Qual o benefício?

Perguntas Secundárias: Quais problemas esta solução irá tratar? Descrever o ambiente de negócios.

Perguntas Finais: É a pessoa certa? A resposta é oficial? As perguntas são relevantes?