A Engenharia de Software

[pic 1]

Objetivos

• Descrever suas atividades e interdependências. [pic 2]
• Técnicas de elicitação e análise.
• Técnicas de validação e revisão.
• Gerência de requisitos.

Tópicos

• Estudo de viabilidade. [pic 3]
• Elicitação e análise.
• Validação.
• Gerenciamento.

  ---

Processos

• Processos apresentam grande variação, dependente de:

• domínio;
• pessoas envolvidas e
• cultura e política organizacional. [pic 4]

• Atividades genéricas comuns a todos os processos:

• elicitação;
• análise;
• validação e – gerenciamento.

[pic 5]

Engenharia de Requisitos [pic 6]

[pic 7]

Viabilidade

• Decidir se a proposta (software ou sistema) é viável  -  aspectos técnicos, financeiros e temporais. [pic 8]
• Estudo focado em analisar:

• contribuição aos objetivos organizacionais;
• integração com sistemas atualmente em uso; – orçamento x  necessidades financeiras e – disponibilidade x necessidades técnicas.

Viabilidade

• Implementação, baseada em:

• avaliação de informação disponível

(necessidades); – coleta de informação e – relatórios. [pic 9]

• Questionamentos típicos:

• pro’s e con’s da implementação? – problemas do processo atual?
• necessário novas tecnologias / habilidades?
• problemas de integração?

Requisitos

• Os requisitos são normalmente classificados em:

• funcionais => funcionalidade do software que atende a uma necessidade de automação  -  “o quê” se espera seja feito; [pic 10]
• não-funcionais => qualidades e restrições globais do sistema. 

• Opções de classificação:

• funcionais
• operacionais – características de processamento (ex.: disponibilidade, performance, etc) [pic 11]
• contingência – alternativas para o não funcionamento ou indisponibilidade.
• técnicos – premissas e restrições (arquitetura, padrões, linguagens, etc).

• Pressman - fatores de qualidade de software medidos de forma indireta, ou  características implícitas esperadas:

1. Reusabilidade - capacidade de reutilização de módulos do sistema em outras aplicações. Requisito relacionado a outros fatores:

• Modularidade: independência funcional dos componentes; [pic 12]
• Generalidade: amplitude do potencial de aplicação; • Encapsulação e
• Abstração.

1. Portabilidade - esforço exigido para transferir um sistema de um ambiente de hardware e/ou software para outro. Diretamente relacionado à reusabilidade e às linguagens de programação e ferramentas utilizadas.
2. Manutenibilidade - esforço exigido para localizar, reparar ou modificar um sistema. Requisito está relacionado a outros fatores: [pic 13]

• boa documentação;
• legibilidade;
• reusabilidade e portabilidade.

1. Multimodalidade - uso de diferentes mecanismos para representação, apresentação e interação. Relacionado ao uso de diversos canais de comunicação (visual, tátil, auditiva e motora).
2. Eficiência e desempenho -  [pic 14]

• eficiência: quantidade de recursos exigida para que o programa execute a sua função.
• desempenho: avaliado pela  a velocidade de processamento, tempo de resposta, consumo de recursos, throughput e eficiência.

1. Usabilidade - grau de facilidade de aprendizado. Conceito relativo à qualidade da interação do sistema com os usuários. Alguns destes fatores são:

• facilidade de aprendizado;
• facilidade de uso;
• satisfação do usuário; [pic 15]
• flexibilidade e nível de parametrização;
• produtividade;
• consistência de interface; •        cuidado com a navegabilidade;
• tolerância a erros.

1. Rastreabilidade - capacidade de manutenção de histórico e de ações dos usuários.
2. Extensibilidade - capacidade de ampliação do sistema (novas funcionalidades).
3. Escalabilidade - capacidade do sistema de manter seu desempenho mediante aumento de requisições simultâneas. Requisito relacionado a: [pic 16]

• pool de conexões;
• operações de I/O.

10.Configurabilidade - capacidade de organizar e controlar elementos da configuração do sistema. Requisito relacionado a:

• habilitação / omissão de conteúdo / serviço;
• parametrização;
• personalização e customização do sistema (contexto ou perfil). [pic 17]

11.Variabilidade - associada à variação de componentes de uma arquitetura. Exemplos:

• funcionalidade;
• dados;
• tecnologia. 

12.Segurança - premissas e restrições de controle e segurança do ambiente. Requisito relacionado a fatores como:

• criptografia;
• autenticação e controle de acesso;
• manipulação de recursos; [pic 18]
• autorização / permissão
• integridade dos dados e confiabilidade;
• privacidade e confidencialidade.

13.Tolerância a Falhas - capacidade do sistema de manter seu funcionamento normal dada a ocorrência de uma falha. Relacionado a:

• disponibilidade;
• confiabilidade;
• freqüência e gravidade das falhas; [pic 19]
• acurácia dos resultados; •        capacidade de recuperação e
• redundância .

• Norma ISO /; IEC 9126 (não-funcionais):

• Funcionalidade - finalidade do produto;
• Usabilidade - esforço para utilizar, aprender o produto;
• Confiabilidade - freqüência de falhas, recuperabilidade;
• Eficiência - característica relacionada ao desempenho; – Manutenibilidade - esforço necessário a modificações; [pic 20]
• Portabilidade - capacidade de transferir o produto para outros ambientes.

Elicitação e Análise

• Também conhecida por “Elicitação de Requisitos” ou “Descobrimento de Requisitos”.
• Time técnico trabalhando com clientes para descobrir: [pic 21]

• domínio da aplicação; – serviços requeridos e – vínculos e limitações.

• envolvimento de todos os “stakeholders”.
• Problemas típicos:

• “stakeholders” não tem claro as necessidades;
• conflito de terminologia e linguagem (técnicos x negócio);
• conflito de requisitos; [pic 22]
• impactos organizacionais / políticos;
• processo dinâmico: eliminação / alteração / surgimento de requisitos ou “stakeholders” e – alteração do ambiente.

[pic 23]

[pic 24]

• Identificação: interação com “stakeholders” para descobrir requisitos. Aspectos de domínio também avaliados nesta etapa.
• Classificação e organização: correlação e organização de requisitos em grupos. [pic 25]
• Priorização e negociação: priorização, negociação com “stakeholders” e solução de conflitos.
• Documentação: requisitos identificados são validados e documentados. 
• Identificação: processo de reunir informação sobre o sistema proposto e similares já existentes, filtrando, a partir dela, os requisitos de usuários e sistema. [pic 26]
• Fontes de informação incluem:

• documentação;
• “stakeholders” e
• especificação de sistemas similares.

• Técnicas:

• tradicionais – questionários, entrevistas, análise da documentação;
• cenários – tarefas atualmente executadas x as que desejam executar; [pic 27]
• grupais – dinâmica de grupo (ex.: brainstorm);
• prototipação – alto grau de incerteza + urgência.
• cognitivas – baseada em conhecimento;
• contextuais – etnografia e análise social. 

Visões / Pontos de Vista

• Visões são maneiras de estruturar os requisitos e representar as diferentes perspectivas dos diferentes “stakeholders”. • “Stakeholders” podem ser classificados sob várias visões. [pic 28]
• A análise sob várias perspectivas é fundamental, já que não existe uma maneira única correta de analisar os requisitos.

Visões / Pontos de Vista (cont.)

• Interação: pessoas e outros sistemas de interação direta com o novo sistema. • Indireta: “stakeholders” sem uso direto do sistema, mas com poder de influência nas decisões. [pic 29]
• Domínio: características, vínculos e restrições que influenciam os requisitos. 

Visões / Pontos de Vista (cont.)

• Identifique visões via:

• provedores e receptores dos novos serviços;
• sistemas de interação direta com o novo sistema; [pic 30]
• regulamentações e padronizações;
• fontes de requisitos de negócio e nãofuncionais;
• desenvolvedores e equipe de manutenção;
• segurança;
• marketing e outras áreas de “back office”.

Entrevista

• Questionário (formal ou informal) feito aos “stakeholders” sobre o(s) processo(s) atual (ais) e sobre necessidades.
• Levantamento sobre aspectos do sistema a ser desenvolvido. [pic 31]
• Dois tipos básicos:

• fechadas => questionário pré-definido;
• abertas => sem agenda pré-definida, exploração de aspectos (problemas).

• Usualmente utiliza-se um mix de entrevistas abertas e fechadas.
• Excelente método para entender processos e interação com usuários.
• Pouco útil em entender requisitos de domínio: [pic 32]

• dificuldade de engenheiros de requisitos em entender a terminologia específica (domínio); – dificuldade de “stakeholders” em articular ou perceber a relevância do requisito.

• Entrevistadores devem manter sua mente aberta, escutar e evitar idéias préconcebidas.
• Estruturar a entrevista, preparar perguntas e propostas. Evitar o básico como: [pic 33]

• o que você quer?;
• o que você precisa?

• Limitações:

• influência do entrevistador: evitar induzir o entrevistado, permitir a exposição de idéias;
• relação pesoal: evitar grupos com dependência hierárquica e estimular a discussão; [pic 34]
• predisposição: avaliar a confiabilidade e veracidade da informação prestada;
• disponibilidade: comprometimento do entrevistado com as respostas dadas (superficialidade e tempo). 

Cenários

• Exemplos de utilização da vida real. Forma de imaginar o comportamento do sistema.
• Abordagem informal, prática e aplicável a qualquer tipo de sistema. [pic 35]
• Descrições em linguagem natural ou modelos mais complexos contendo informação comportamental(ações,eventos e atividades) e objetos(entidade,atributos).

Cenários (cont.)

• Devem incluir:

• descrição da situação inicial; [pic 36]
• descrição do fluxo normal de eventos;
• descrição do que pode ocorrer de errado (RM); – outras atividades simultâneas; – descrição da situação final.

Caso de Uso

• Baseado em cenários e UML, identifica atores da interação e a descreve.
• Conjunto de Casos de Uso devem descrever todas as possíveis interações com o sistema. [pic 37]
• Pode-se utilizar diagramas seqüenciais para acrescentar detalhes de processamento.

• Benefícios:

• facilmente adicionado / removido do projeto;
• base para estimar, escalonar e validar esforços;
• fáceis de entender por pessoas da área de negócio. [pic 38]

• Problemas:

• pouco efetivo na captura de requisitos nãofuncionais;
• descrição comportamental, não técnica.

• Principais componentes do modelo:

• Caso de Uso: especifica funcionalidade completa do sistema. Sempre iniciado por um ator (direta ou indiretamente ordena ao sistema a execução de um caso de uso);  [pic 39]
• Ator: entidade externa que interage com os casos de uso;  
• Sistema: conjunto de casos de uso.

[pic 40]

[pic 41]

Fatores Organizacionais e Sociais

• Sistemas utilizados em contextos sociais e organizacionais. Esses aspectos podem influenciar ou mesmo dominar os requisitos. [pic 42]
• Fatores influenciados por todas as visões.
• Um bom analista deve ser sensível a estes fatores, mas não há metodologia / sistema definido de abordagem.

Etnografia

• Cientistas sociais gastam bastante tempo observando, analisando e avaliando como as pessoas realmente trabalham.
• Não é necessário explicar ou detalhar o trabalho executado. [pic 43]
• Fatores organizacionais e sociais relevantes podem ser observados.
• Estudos demonstram que o trabalho é, usualmente, mais rico e complexo do que sugerido por modelos.

Etnografia Focada

• Originalmente desenvolvida em um projeto de estudo do processo de controle de tráfego aéreo.
• Combinação de Etnografia com Prototipação. [pic 44]
• Etnografia foca em aspectos não abordados pela Prototipação.
• Problema: Etnografia se baseia em aspectos históricos que podem não mais ser relevantes.

Etnografia: Escopo

• Requisitos derivados da maneira como realmente as pessoas trabalham e não baseada em processos. [pic 45]
• Requisitos derivados da cooperação e conscientização das atividades de outras pessoas.

Validação

• Requerimentos definem o sistema solicitado.
• Erros de requisitos apresentam alto custo, ressaltando a importância do processo de validação. [pic 46]
• Correção de erros pós entrega podem apresentar um custo 100 vezes superior ao de sua correção na fase de validação.

• Validade: garantia de que o sistema apresenta as funcionalidades que melhor suportam as necessidades organizacionais / usuários.
• Consistência: garantia de que não há conflitos entre requisitos.
• Completeza: garantia de que todas as funcionalidades requeridas foram incluídas. [pic 47]
• Realismo: garantia de implementação no orçamento alocado e tecnologia disponível.
• Rastreabilidade: garantia de que os requisitos podem ser verificados. 
• Técnicas:

• revisão: análise sistemática dos requisitos.
• prototipação: utilização de um modelo executável do sistema para verificação dos requisitos. [pic 48]
• casos teste: desenvolvimento de casos específicos para requisitos para validação do potencial de testes. 

• Revisões:

• devem ser regulares, enquanto são formuladas as definições de requisitos;
• envolvimento de desenvolvedores e “stakeholders”; [pic 49]
• formais (documentada) e informais;
• um bom processo de comunicação evita ou resolve problemas em seu estágio inicial.

• Revisões:

• verificável: garantir testes realistas;
• compreensiva: garantia do entendimento dos requisitos;
• rastreabilidade: origem do requisito claramente estabelecida; [pic 50]
• adaptabilidade: garantia de que um requisito pode ser alterado sem grande impacto nos outros requisitos. 

• Gerenciamento:

• processo de gerência de mudança de requisitos que ocorre durante o processo de engenharia de requisitos e desenvolvimento do sistema.
• requisitos são incompletos e inconsistentes de forma inerente. [pic 51]

• novos requisitos aparecem;
• requisitos de negócio se alteram;
• alterações oriundas do melhor entendimento dos requisitos;
• diferentes visões apresentam diferentes requisitos. 
• Alterações:

• prioridades sofrem alterações durante o processo de desenvolvimento; [pic 52]
• requisitos de sistema podem conflitar com requisitos de usuários;
• mudanças de domínio / ambiente.

Requisitos

• Requisitos perenes: requisitos estáveis derivados das atividades core da organização. Podem originar-se de modelos de domínio. [pic 53]
• Requisitos voláteis: sofrem alteração durante o desenvolvimento ou após entrada em produção. 

[pic 54]

• Planejamento:

• identificação de requisitos: como são identificados individualmente;
• gerência de mudança: processo quando se analisa a mudança de requisitos; [pic 55]
• políticas de rastreabilidade: manutenção de informações sobre relações entre requisitos;
• suporte CASE: ferramenta necessária para gerenciar o processo de mudanças. 

• Rastreabilidade:

• Foco no relacionamento entre requisitos, fonte e desenho:

• fonte: conexões entre o requisito e seu

“stakeholder”; [pic 56]

• rastreabilidade: conexões de interdependência entre requisitos;
• desenho: conexões entre requisitos com o desenho. 
• Matriz de rastreabilidade: [pic 57]

• Suporte CASE:

• armazenagem: gerência de requisitos deve ser feita em um ambiente seguro e gerenciado.
• gerência de mudança: processo em fluxo cujos estágios e intercâmbio de informação pode ser parcialmente automatizado. [pic 58]
• gerência de rastreabilidade: controle e obtenção de conexões automaticamente. 

• Gerência de Mudança:

• obrigatória a toda e qualquer proposta de alteração de requisitos.
• principais etapas:

• análise do problema: discutir o problema e propor alterações; [pic 59]
• análise de mudança e custo: analisar o impacto da mudança sobre outros requisitos;
• implementação: alterar documentação 

• Processos incluídos na Engenharia de Requisitos:

• análise de viabilidade;
• elicitação e análise de requisitos; – especificação de requisitos e – gerência de requisitos.

• Elicitação e análise de requisitos é um processo interativo envolvendo entendimento do domínio, coleta de requisitos, classificação, estruturação, priorização e validação. • Sistemas possuem múltiplos “stakeholders” com diferentes requisitos. [pic 60]
• Fatores sociais e organizacionais influenciam os requisitos.
• Validação preocupa-se com verificação de validade, consistência, completeza, realismo e verificável. [pic 61]
• Alterações de negócio normalmente leva a alterações de requisitos.
• Gerência de requisitos inclui planejamento e gerência de mudança.

[pic 62]

[pic 63]

...