A ambição do trabalho académico em questão centra-se na elaboração de um documento de Especificação de Requisitos de Software, utilizando padrões de metodologia RUP, para apoio ao desenvolvimento de software. Dadas as situações relatadas, temos o seguinte problema: Como criar um documento de especificação de requisitos de software, segundo RUP. H0 – Seria impossível criar um documento de especificação de requisitos de software, seguindo os padrões da metodologia RUP aplicados ao Restaurante Monalisa, pois não haveria melhoria no entendimento do software a ser construído e, portanto, na sua qualidade.
Software
Engenharia de Software
- Camadas da Engenharia de Software
- Processo de Software
A engenharia de software é uma tecnologia em camadas que inclui processos, métodos e ferramentas, baseada no compromisso com a qualidade, conforme ilustrado na figura 1. As ferramentas de engenharia de software fornecem suporte automatizado ou semiautomático aos processos e aos métodos" ( PRESSMAN, 2006, pág.18). Especificação de software ou engenharia de requisitos: clientes e engenheiros definem o software e as restrições para esta operação.
Requisitos
- Requisitos Funcionais
- Requisitos Não-Funcionais
- Requisitos de Domínio
Spínola (2007, p.48) afirma que “São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter”. São requisitos derivados do domínio da aplicação e descrevem as características e qualidades do sistema que refletem o domínio. Segundo Sommerville (2007, p.81) “estes são requisitos que surgem do domínio de aplicação do sistema e refletem as características e limitações desse domínio”.
Engenharia de Requisitos
- Produção de Requisitos
- Levantamento
- Registro
- Verificação
- Validação
- Gerência de Requisitos
- Controle de mudanças
- Gerência de configuração
- Rastreabilidade
- Gerência de Qualidade de Requisitos
Sommerville (2007, p.105-106) entende que a validação de requisitos tem como objetivo demonstrar se os requisitos realmente definem o sistema que o usuário deseja; A atividade de gerenciamento de requisitos, por sua vez, envolve o gerenciamento de requisitos ao longo do tempo (SPÍNOLA, 2007, p.51). Mas Sommerville (2007, p.107) também afirma que o gerenciamento de requisitos visa compreender e controlar mudanças nos requisitos do sistema.
Processo RUP
- Práticas do RUP
- Desenvolver software iterativamente
- Gerenciar os requisitos
- Usar arquiteturas baseadas em componentes
- Modelar software visualmente
- Verificar a qualidade do software continuamente
- Controlar as mudanças no software
- Características do RUP
- Estrutura do RUP
O ciclo de vida proposto pelo RUP é baseado em um modelo espiral que divide a construção do software em iterações que resultam no lançamento de uma versão executável do sistema (CINTRA, 2006, p. 35). Finalmente, a equipe pode utilizar as lições aprendidas em cada iteração para melhorar continuamente o processo de desenvolvimento (CINTRA, 2006, p. 35). As ferramentas visam aumentar a produtividade em cada atividade do processo e facilitar as práticas RUP (CINTRA, 2006, p. 38).
Banco de Dados
- Modelo de Dados
- Modelo Entidade / Relacionamento
- Arquitetura de Banco de Dados
O modelo de dados entidade/relacionamento (E-R) é baseado na percepção de um mundo real que contém uma coleção de objetos básicos, chamados entidades, e relacionamentos entre esses objetos. As entidades são descritas em um banco de dados por um conjunto de atributos (SIBERSCHATZ; KORTH; SUDARSHAN, 2006, p.11). Este modelo e suas variações são comumente usados para o projeto conceitual de aplicações de banco de dados, e muitas ferramentas de projeto de banco de dados aplicam seus conceitos.
Este modelo foi desenvolvido para facilitar o design do banco de dados, permitindo a especificação de um esquema corporativo que representa toda a estrutura lógica do banco de dados. Além de entidades e relações, o modelo ER representa certas restrições que o conteúdo do banco de dados deve cumprir. Uma limitação importante é a cardinalidade do mapeamento, que expressa o número de entidades com as quais outra entidade pode estar conectada através de um conjunto de relacionamentos (SIBERSCHATZ; KORTH; SUDARSHAN, 2006, p. 11).
Os autores explicam que um diagrama ER pode expressar graficamente toda a estrutura lógica de um banco de dados. Siberschatz, Korth e Sudarshan (2006, p. 16) argumentam que “a arquitetura de um sistema de banco de dados é fortemente influenciada pelo sistema de computação subjacente no qual o sistema de banco de dados é executado”. Em duas camadas, a aplicação é dividida em um componente localizado no computador cliente, que chama a funcionalidade do sistema de banco de dados no computador servidor por meio de instruções de linguagem.
Em uma arquitetura de três camadas, a máquina cliente serve simplesmente como front-end e não contém chamadas diretas ao banco de dados.
UML e a Engenharia de Requisitos
- Diagramas UML
- Diagrama de Caso de Uso
- Diagrama de Atividades
- Diagrama de Sequência
O Diagrama de Casos de Uso (DCU) corresponde a uma visão externa de alto nível do sistema, com o objetivo de ilustrar as funcionalidades do sistema. Um caso de uso descreve a funcionalidade específica que um sistema deve executar ou exibir, modelando o diálogo que um usuário, um sistema externo ou outra entidade terá com o sistema que está sendo desenvolvido. Segundo Siberschatz, Korth e Sudarshan (2006, p.168), “diagramas de casos de uso mostram a interação entre os usuários e o sistema, em particular, as etapas da tarefa que os usuários executam.
Uma relação de comunicação é representada por uma linha reta que conecta ator e caso de uso (BEZERRA, 2007, p.70). O diagrama de atividades mostra todas as atividades que podem ocorrer no sistema quando os valores de um objeto11 mudam” (PFLEEGER, 2004, p.221). 11“Um objeto é uma entidade que possui um estado e um conjunto definido de operações que são definidas para operar nesse estado.
Segundo Bezerra (2007, p.307) “um diagrama de atividades é um tipo especial de diagrama de estados12, que representa os estados de uma atividade, e não os estados de um objeto”. Quando condições são usadas para decidir quais atividades solicitar, o diagrama de atividades usa um nó de decisão para representar as opções. Um diagrama de sequência mostra a ordem em que as atividades ou comportamentos ocorrem” (PFLEEGER, 2004, p.229).
O diagrama de sequência mostra como os eventos causam transições de objeto para objeto, em suma, esta é uma versão abreviada do caso de uso, representa as principais classes e eventos que fazem o comportamento fluir de classe para classe (PRESSMAN, 2006, p 179).
Ferramentas de Modelagem
- Argo UML
- Visio
- MySQL Workbench
- Balsamiq Mockups
O Visio Online também tem sido uma ótima opção para usuários que desejam ampliar os recursos do Visio, podendo compartilhar e acessar diagramas em qualquer lugar. MySQL Workbench é uma ferramenta com uma variedade de recursos, desde modelagem de dados, desenvolvimento SQL até gerenciamento de usuários, backup, painel de desempenho visual, migração de banco de dados e muito mais. Como modelador de banco de dados, o MySQL Workbench permite ao usuário projetar, modelar, gerar e gerenciar bancos de dados.
Permite o design de banco de dados orientado por modelo, fornece recursos de engenharia reversa, gerenciamento de alterações de banco de dados e documentação de design de banco de dados.17. Possui uma biblioteca de interface de usuário com uma ampla variedade de elementos de criação. 14 Disponível em
RUP e a Engenharia de Requisitos
- Analisar o Problema
- Compreender as Necessidades dos Stakeholders
- Definir o Sistema
- Gerenciar o Escopo do Sistema
- Refinar a Definição do Sistema
- Gerenciar Mudanças nos Requisitos
Capture um vocabulário comum: defina um vocabulário comum que possa ser usado em todas as descrições textuais do sistema, especialmente na descrição de casos de uso. Encontre atores e casos de uso: continue procurando atores e casos de uso; refinar os modelos já criados completando e melhorando as descrições dos atores e principalmente a descrição inicial dos fluxos de execução dos casos de uso; ajustar as interações entre esses elementos, de acordo com o entendimento atual do sistema (que se torna mais elaborado a cada fase do projeto). Os principais objetivos deste subfluxo são alinhar a equipe de desenvolvimento como um todo, entender o problema, realizar uma análise de alto nível dos requisitos coletados (Visão) e seus atributos, refinar a visão do sistema e refinar o modelo do caso de uso. bem como especificar os casos de uso e por fim avaliar os resultados parciais (DIDIER, 2003, p.60).
Encontre atores e casos de uso: continue procurando atores e casos de uso; refinar os modelos já criados completando e melhorando as descrições dos atores e principalmente dos casos de uso; ajustar as interações entre esses elementos, de acordo com o entendimento atual do sistema (que se torna mais elaborado a cada fase do projeto). Priorização de casos de uso: definir os casos de uso e cenários a serem analisados em cada iteração; definir os principais casos de utilização e cenários que sejam significativos do ponto de vista das funcionalidades do sistema, do ponto de vista da arquitetura e em contextos específicos como desempenho, adaptabilidade ou outros pontos importantes em termos de restrições do sistema. Os objetivos deste subfluxo são “[..] detalhar os fluxos de eventos de casos de uso, detalhar as especificações adicionais, descrever a especificação de requisitos de software e modelar o protótipo da interface” (DIDIER, 2003, p. 72).
Detalhe um caso de uso: descreva detalhadamente um caso de uso que já foi identificado em atividades anteriores. A descrição detalhada contém uma explicação detalhada do fluxo de execução (principais etapas e iterações), condições antes e depois, fluxos de erros e fluxos alternativos e outras informações relacionadas ao caso de uso. Modelar a interface do usuário: construir um modelo de interface do usuário do sistema, considerando os atores, o fluxo de eventos do caso de uso e os requisitos de usabilidade; identificar classes de interface (classes de fronteira) entre o sistema e seus usuários; descrever a interação entre essas classes e complementar os demais modelos do sistema com base nas novas definições feitas.
Estruture o modelo de Caso de Uso: refine o modelo de Caso de Uso, extraia comportamento comum para casos de uso abstratos e defina relacionamentos de 'inclusão' ou 'estender'; procure novos atores abstratos que definam papéis compartilhados por diferentes atores.
DESENVOLVIMENTO
Criação do Documento de Especificação de Requisitos segundo o RUP
- Subfluxo: Analisar o Problema
- Subfluxo: Compreender as Necessidades dos Stakeholders
- Subfluxo: Definir o Sistema
- Subfluxo: Gerenciar o Escopo do Sistema
- Subfluxo: Refinar a Definição do Sistema
- Subfluxo: Gerenciar Requisições de Mudança
- Análise de Resultados
E para obter as informações necessárias do interessado, foram realizadas entrevistas estruturadas em funil20 para levantamento de requisitos. Todos esses requisitos foram coletados e registrados no documento Especificação de Requisitos baseado na metodologia RUP. Após a coleta dos dados, o documento de Requisitos preparado e finalizado, a verificação do cliente para aprovação final fornece o marco para iniciar o processo de codificação e concluir esta pesquisa.
Esta pesquisa apresentou os benefícios da obtenção de um documento de especificação de requisitos como um bom aliado não só do cliente, mas também do desenvolvedor na busca por software de qualidade. Considerando o problema de pesquisa, na possibilidade de criação de um documento de especificação de requisitos de software, segundo RUP, para melhorar a qualidade do software a ser desenvolvido para o Restaurante Monalisa, as hipóteses tratadas foram investigadas. H1 – A documentação de requisitos permitirá ao cliente e ao desenvolvedor analisar o futuro software, revelar dúvidas, opiniões e possíveis alterações antes do processo de codificação.
H2 - A configuração das alterações conforme Engenharia de Requisitos possibilitaria o controle de versões, a fim de evitar alterações excessivas no futuro, reduzindo assim custos. O documento de Especificação de Requisitos produzido foi promissor, atingindo assim seus objetivos, percebendo que todo o esforço na aplicação dos conceitos da Engenharia de Requisitos antes do processo de codificação traz múltiplos benefícios. É importante notar que o investimento necessário para uma boa especificação de requisitos não é proibitivo em termos de custos, mas é essencial para a qualidade, produtividade e redução de despesas gerais para software futuro.
A implementação de um processo de Engenharia de Requisitos baseado no Rational Unified Process (RUP) que atinge o nível de maturidade 3 do Capability and Maturity Model Integration (CMMI), incluindo a utilização de métodos ágeis.
Prototipação das Interfaces
Documento de Especificação de Requisitos
Isso inclui fluxogramas, organogramas, projetos, projetos, diagramas de fluxo de dados, diagramas de fluxo de processos, processos de negócios.
