Engenharia de Software: Requisitos e UML
Classificado em Computação
Escrito em em português com um tamanho de 7,95 KB.
Engenharia de Software: Organização, Produtividade e Qualidade
O processo de engenharia de software não é fabricação, o software não se deteriora, mas está em constante evolução e erros surgirão.
É fundamental compreender o problema antes de desenvolver a solução.
Os 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 poderá 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 será usado e quais funções.
- Análise de requisitos e objetos do domínio.
- Projeto:
- Solução conceitual de software ou hardware, satisfazendo os requisitos.
- O que é necessário para atender aos requisitos.
- Análise e projeto: definir caso de uso, diagrama de interação e classes.
Erros Comuns na Engenharia de Software
- 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.
- Pensar que UML é simplesmente uma notação padrão de diagramação.
- Achar que UML vai nos ajudar muito.
Importante: UML não é tão importante quanto saber identificar requisitos, projetar e pensar em termos de objetos.
IDENTIFICAR O PROBLEMA, PROPOR ELEMENTOS DA SOLUÇÃO, NEGOCIAR DIFERENTES ABORDAGENS E ESPECIFICAR UM CONJUNTO PRELIMINAR DE REQUISITOS.
Conceito de Engenharia de Requisitos
- Definir os interessados.
- O cliente nem sempre tem clareza ou bom entendimento.
É 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 é fundamental, caso contrário, o software pode não atender às necessidades.
Tipos de Requisitos
- 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.
Etapas da Engenharia de Requisitos
- Concepção: Entendimento básico do problema.
- Levantamento: Levantar o que o cliente deseja e verificar os requisitos do sistema.
- Elaboração: Expandir e refinar o que foi colhido nas fases de Concepção e Levantamento. Diversos diagramas são gerados.
- Negociação: Clientes podem pedir mais do que se pode fazer ou mesmo, pedirem coisas conflitantes.
- Especificação: Documentos que especificam o software.
- Validação: Realiza-se a validação dos requisitos (dos artefatos construídos, como os casos de uso e outros modelos).
- Gestão: Os requisitos podem mudar ao longo da vida de um sistema.
Interessados (Stakeholders)
Qualquer um que se beneficia de forma direta ou indireta do sistema. Cada pessoa tem um ponto de vista diferente, contribuindo para os requisitos.
Perguntas Iniciais
- Quem está solicitando?
- Quem irá utilizar?
- Qual o benefício econômico?
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 foram relevantes?
Levantamento de Requisitos: Como Fazer?
- A partir de uma solicitação de produto.
- Realiza-se o levantamento de requisitos.
- Os interessados irão começar a fazer solicitações e colocar os pontos que são importantes.
- Discussões sobre o que falta e tem que ser aprimorado.
Exemplo de Listas para Levantamento
- Lista de objetos: smartphone, PC.
- Lista de serviços: o que o sistema 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 uma reunião entre engenheiros e cliente para verificar se está tudo de acordo.
Debate: É necessário fazer?
Tipos de Requisitos
- 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:
- Escolher a fronteira do sistema.
- Identificar os atores principais.
- Identificar os objetivos para cada ator principal.
- 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:
- O ator pode fazer algo diferente neste ponto?
- Existe a possibilidade do ator encontrar alguma condição de erro neste ponto? (Se sim, qual seria?)
- Existe a possibilidade do ator encontrar algum outro tipo de comportamento neste ponto?
Exemplo de Caso de Uso Resumido: Procurar Livros
- Acessar o site da livraria online.
- Sistema retorna a página principal.
- Selecionar o campo de busca.
- Digitar o título do livro.
- Sistema faz a busca no banco de dados do livro.
- Sistema retorna o resultado pesquisado.
- Cliente seleciona a opção desejada.
- Sistema carrega a página com detalhes do livro selecionado.
Exemplo de Caso de Uso Informal: Realizar Chamada
Descrição: Professor abre o sistema Y, faz o login, deixa o sistema de chamada em aberto e, ao finalizar a aula, encerra o login.
- Professor abre o sistema.
- Realiza Login, sistema Y identifica usuário, aula e turma correspondente à data e horário.
- O sistema de chamada ficará em aberto no período da aula, aguardando o aluno para reconhecimento facial, confirmando sua presença.
- Professor preenche o conteúdo da aula e encerra a aula.
Cenários Alternativos para o Caso de Uso"Realizar Chamad"
- Professor precisa ser substituído de última hora: O professor substituto não terá acesso à turma. Será necessária uma notificação ao coordenador para troca de professor e autorização do mesmo.
- Problema no reconhecimento facial: O professor terá acesso manual à chamada. O aluno precisa notificar o professor.
- Professor pode intervir na chamada: Caso o aluno chegue apenas no final para confirmar sua presença.
- Sistema com problema de comunicação: A chamada será feita manualmente pelo professor. Quando o problema for solucionado, será feita a sincronização com o servidor.