Fases de desenvolvimento de software

Agenda A evolução do software Crise do software Mitos no processo de desenvolvimento Engenharia de soft Ciclo de vida

Um caso comum !! - O sistema que queremos deve fazer isto,

isto, ..., e nesse caso também isto...; - Sim, Sim, estou anotando... - Conversei com os usuários e basicamente

este é o sistema que teremos que desenvolver;

- Sim chefe; - Ótimo, começaremos a especificar os

requisitos imediatamente.

MOTIVAÇÃO...Quatro meses depois ...

- Senhores usuários, após o emprego das mais modernas técnicas de especificação, produzimos este documento que descreve minuciosamente o Sistema;

- Ótimo! Bom! Hum! ... É um documento com 300 páginas e todos estes gráficos, tabelas. Enfim, vamos analisá-los e voltamos a falar;

MOTIVAÇÃO

... Mais um mês e meio ... - Sr. Analista, nosso pessoal analisou com

cuidado o documento. Tivemos muitas dificuldades em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!!

- Como não? Tudo que está aí foi fruto de nosso entendimento pessoal. REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!

Fases da Engenharia de Requisitos

MODELAGEM

ANÁLISEVALIDAÇÃO

ELICITAÇÃO

Aquisição Especificação

Informações elicitadas

Estudo de

viabilidade

Informações

Representações

Especificação

de requisitos

Objetivos – engenharia de requisitos buscar as primeiras informações sobre o

sistema a ser desenvolvido descobrir se vale a pena fazer a análise,

mas sem fazer a análise propriamente dita

Importância Quanto mais tarde um erro é identificado

maior o custo e o tempo de correção Muitos erros não são detectados cedo, mas

poderiam Não atendimento das necessidades dos

usuários – desentendimentos entre usuários e desenvolvedores

Atividades

Estudo de viabilidade Levantar requisitos (elicitação) Organizar requisitos

(modelagem/análise) Validar requisitos junto ao cliente

(validação)

Realização do Estudo de Viabilidade Baseado na avaliação da informação (o que é

requisitado), coleção de informações e escrita de relatório

Perguntas para pessoas da organização O que ocorre se o sistema não for implementado? Quais são os problemas com o processo atual? Como o sistema proposto ajudará? Quais são os problemas de integração? Será necessária tecnologia nova? Quais as habilidades

necessárias para dominá-la? Que facilidades devem ser suportadas?

Elicitação de Requisitos

ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão;

identificar os fatos que compõem os requisitos do Sistema a fim de prover o mais correto e mais completo entendimento do que é demandado daquele software.

Elicitação de requisitos: dificuldades Usuários podem não ter uma idéia precisa do

sistema por eles requerido; Usuários têm dificuldades para descreverem seu

conhecimento sobre o domínio do problema; Usuários e analistas têm diferentes pontos de

vista do problema (por terem formações diferentes)

Usuários podem antipatizar com o novo sistema e se negar a participar da elicitação (ou mesmo fornecer informações errôneas).

Atividades da Elicitação1. Entendimento do negócio

Você deve entender como os sistemas interagem e contribuem de forma geral com os objetivos do negócio

2. Entendimento do domínio da aplicação O conhecimento do domínio da aplicação é o

conhecimento geral onde o sistema será aplicado

3. Entendimento do problema Os detalhes específicos do problema do cliente onde

o sistema será aplicado deve ser entendido

Tipos de requisitos

requisitos funcionais correspondem à listagem de todas as coisas que o sistema deve fazer

requisitos não funcionais são restrições que se coloca sobre como o sistema deve realizar seus requisitos funcionais

Requisitos Funcionais

requisitos funcionais evidentes são efetuados com conhecimento do usuário

requisitos funcionais ocultos são efetuados pelo sistema sem o conhecimento explícito do usuário

Requisitos Não Funcionais

Obrigatórios Desejáveis

Requisitos Não Funcionais

de interface de implementação de eficiência de tolerância a falhas etc.

Requisitos Não Funcionais

Associados a requisitos funcionais Suplementares

Requisitos Não Funcionais

Permanentes Transitórios

Tabela de Requisitos Funcionais Código do requisito funcional (Ex.: F1, F2,

F3, ...). Nome do requisito funcional

(especificação curta). Descrição (especificação longa e

detalhamento do requisito). Categoria funcional: evidente ou oculto.

Tabela de Requisitos Não Funcionais Código do requisito não funcional (Ex.: NF1.1,

NF1.2, ... NF2.1, NF2.2, ...). Nome do requisito não funcional (especificação

curta). Restrição: especificação (longa) do requisito não

funcional. Categoria: tipo de restrição: segurança, performance,

compatibilidade, etc. Obrigatoriedade: se o requisito é desejável ou

obrigatório. Permanência: se o requisito é permanente ou

transitório.

Requisitos Funcionais e Não Funcionais Associados

F1 Registrar empréstimos Oculto ( ) Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do empréstimo e valor previsto para pagamento na devolução. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF1.1 Controle de Acesso

A função só pode ser acessada por usuário com perfil de operador ou superior.

Segurança ( ) (x)

NF1.2 Identificação de Fitas

As fitas devem ser identificadas por um código de barras

Interface ( ) (x)

NF1.3 Identificação do cliente

O cliente deverá ser identificado a partir de seu nome Interface ( ) ( )

NF1.4 Tempo de registro

O tempo para registro de cada fita deve ser inferior a um segundo.

Performance (x) ( )

NF1.5 Janela única Todas as funções relacionadas a empréstimos devem ser efetuadas em uma única janela

Interface (x) (x)

... ... ... ... ...

F2 Calcular descontos Oculto ( x ) Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa. Requisitos Não Funcionais Nome Restrição Categoria Desejável Permanente NF2.1 Desconto de fim de semana

Nos fins de semana, usuários que levam 4 fitas pagam apenas 3.

Especificação ( ) ( )

... ... ... ... ...

Requisitos Suplementares

Nome Restrição Categoria Desejável Permanente

S1 Tipo de Interface As interfaces do sistema devem ser implementadas como formulários acessíveis em um browser html.

Interface ( ) ( )

S2 Armazenamento de dados

A camada de persistência deve ser implementada de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro

Persistência ( ) ( x )

S3 Perfis de usuário Os perfis de usuário para acesso ao sistema são: 3. Administrador - pode efetuar todas as operações. 2. Operador - pode efetuar as operações de empréstimo, devolução, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos próprios dados (cliente).

Segurança ( ) ( )

... ... ... ... ...

Trabalho em grupo

Selecione um sistema utilizado em sua empresa e identifique 5 requisitos funcionais e seus respectivos não-funcionais (pode ser vários).

Entregar em aulaNome, Descrição do SistemaVisão geral do softwareFs, NFs, Ss

Técnicas de Elicitação

Técnicas especiais que podem ser usadas para coletar conhecimento sobre os requisitos dos usuários

Este conhecimento deve ser estruturado Problemas da elicitação

TempoEngenheiros de softwarestakeholders

Técnicas de Elicitação Entrevistas Leitura de documentos Questionários Análise de protocolos Participação ativa dos usuários Cenários Observações e análise sociais Prototipação

Escolhendo a técnica Deve-se selecionar as técnicas a serem

utilizadas e estabelecer a maneira como elas serão integradas

A escolha das técnicas e seu esquema de integração dependerá do problema e da equipe participante

É interessante conhecê-las e saber identificar onde uma técnica se aplica melhor que outra

Técnicas específicas de elicitação

Entrevistas

O Engenheiro de requisitos ou analista discute o sistema com diferentes stakeholders e obtêm um entendimento dos requisitos

Vantagens: contato direto com o usuário e validação imediata

Desvantagens: conhecimento tácito e diferenças de cultura

Entrevistas - tipos Entrevistas fechadas: o analista busca

respostas a um conjunto de questões pré-definidas

Entrevistas abertas: Não há uma agenda pré-definida e o engenheiro de requisitos discute de forma aberta, o que o stakeholder quer do sistema

Tutorial: o cliente dá uma aula explicando seu trabalho

Entrevistas: dicas - planejamento

Identificar candidatos Preparação da entrevista : agendar e

preparar questionário (se for o caso) O analista não deve ir para a

entrevistas com noções pré-concebidas

Entrevistas: condução Informar aos stakeholders o ponto inicial da

discussão. Isto pode ser uma questão, uma proposta de requisitos ou um sistema existente

Esperar por respostas incompletas Repetir frases do entrevistado com suas

próprias palavras Entrevistadores devem estar cientes da política

organizacional - muitos requisitos reais podem não ser discutidos devido a implicações políticas

Entrevistas: Finalização

Tempo para rever respostas de todas as perguntas - consolidar informações

Agradecimentos Gerar documento que deve ser assinado

pelo entrevistado

Leitura de Documentos

Vantagens: facilidade de acesso e volume de informações

Desvantagens: dispersão das informações e volume de trabalho

Questionários Quando existe conhecimento sobre o problema

e grande número de clientes Quando dados estatísticos são importantes Dão idéia definida sobre como certos aspectos

do universo de informação são percebidos Vantagens: padronização das perguntas e

tratamento estatístico das respostas Desvantagens: limitação do universo de

respostas e pouca iteração

Cenários

Cenários são exemplos de interação que descrevem como o usuário interage com o sistema

A descoberta de cenários expõe interações possíveis do sistema e revela as facilidades que o sistema pode precisar

Cenários Cenários são partes inerentes de alguns métodos de desenvolvimento OO São estórias que explicam como um sistema poderá ser utilizado. Devem incluir:

descrição do estado do sistema antes de começar o cenário o fluxo normal de eventos do cenário exceções ao fluxo normal de eventos informações sobre atividades concorrentes uma descrição do estado do sistema no final do cenário

Análise de protocolos Analisar o trabalho de determinada pessoa

através da verbalização Objetivo: estabelecer a racionalidade utilizada

na execução de tarefas Vantagens: possibilidade de elicitar fatos não

facilmente observáveis e permitir melhor entendimento dos fatos

Desvantagens: desempenho do entrevistado e “o que se diz é diferentes do que se faz”

Participação ativa dos usuários Incorporação dos usuários ao grupo de ER Os usuários precisam aprender a linguagem de

modelagem utilizadas para ler as descrições e criticá-las

Integração dos usuários na modelagem do sistema

Vantagens: envolvimento dos clientes/usuários Desvantagens: Tempo em treinamento dos

usuários e falsas expectativas no usuário

Observação e análise social Difícil descrever os processos, interessante

observar Processos reais diferem dos processos

formais escritos nos manuais Vantagens: visão mais completa e

perfeitamente ajustada ao contexto Desvantagens: custo com tempo e pessoal

gasto e pouca sistematização do processo

Prototipação

Uma versão inicial de um sistema que poderá ser usado para experimentação

Protótipos são úteis para elicitar requisitos porque o usuário poderá “experimentar” o sistema e mostrar os pontos fortes e fracos

Concreto

Tipos de prototipagem

DescartávelProtótipo serve para requisitos e é descartado

um outro sistema é implementado depois; Evolucionária

usado no ciclo espiralOs requisitos vão aparecendo conforme o

usuário está utilizando o “sistema”

Prototipagem - Vantagens O protótipo permite que os usuários experimentem e

descubram o que eles realmente necessitam para suportar o trabalho deles

Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados

Interface Pode ser usado para teste do sistema e

desenvolvimento da documentação Força estudo detalhado dos requisitos que revela

inconsistências e omissões

Prototipagem - Desvantagens

Custos de treinamento: pode se optar por ferramentas específicas para prototipação

Incompletude

Organização dos Requisitos (Modelagem) Visa a representação dos requisitos em

modelos conceituais que descrevem as necessidades encontradas na elicitação.Diagramas/modelos“Manutenção” de ConceitosConsultas/Relatórios

Análise de Requisitos

Analisar o modelo gerado buscando encontrar inconsistências e omissões nos requisitos elicitados

Intercalar com elicitação pois problemas são descobertos quando os requisitos são elicitados

Validação

Com a ajuda dos clientes/usuários, busca-se validar ou seja, confirmar o conhecimento adquirido.

Documentação Gerada

O documento de requisitos de software - também chamado de SRS software requirements specification - é o resultado da engenharia de requisitos.

Deve incluir requisitos do usuário, requisitos do sistema

Requisitos do usuário

São declarações em linguagem natural e também em diagramas sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar.

Requisitos do sistema

Estabelecem detalhadamente as funções e as restrições de sistema.

Algumas vezes chamado de ESPECIFICAÇÃO FUNCIONAL

Pode servir como contato entre o comprador e o desenvolvedor do software.

Padrão IEEE/ANSI 830-1998

1. Introdução 1.1 Propósito 1.2 Convenções 1.3 Público Alvo e Orientações para Leitura 1.4 Escopo do Produto 1.5 Referências

2. Descrição Geral 2.1 Perspectiva do Produto 2.2 Funções do Produto 2.3 Classes de Usuários e Características 2.4 Ambiente Operacional 2.5 Restrições de Projeto e Implementação 2.6 Premissas e Dependências

3. Requisitos de Interface Externa 3.1 Interfaces do Usuário 3.2 Interfaces de Hardware 3.3 Interfaces com outros Sistemas 3.4 Interfaces de Comunicação

4. Funcionalidades do Sistema 4.x Funcionalidade X 4.x.1 Descrição e Prioridade 4.x.2 Seqüências de Estímulos e Respostas 4.x.3 Requisitos Funcionais

5. Requisitos não Funcionais

5.1 Requisitos de Performance 5.2 Requisitos de Uso com Segurança 5.3 Requisitos de Segurança 5.4 Atributos de Qualidade 5.5 Regras de Negócio 5.6 Documentação do Usuário

6. Outros Requisitos

Apêndice A: Glossário

Apêndice B: Modelos de Análise

Apêndice C: Lista de Pendências

JadJoint Application Design (JAD), criada pela IBM no final dos anos 70, é uma proposta para a identificação de requisitos de sistema que procura integrar as pessoas da área de negócio (usuários) e profissionais da área técnica por meio de seminários altamente focados.

JadA técnica JAD procura assegurar que a informação seja levantada a partir de todas as áreas afetadas e que os requisitos identificados sejam aprovados por todos os participantes, não cabendo esta decisão apenas aos analistas de sistema responsáveis pela coleta dos requisitos.

Jad - Definição de papéisPatrocinador executivo – responsável do

sistema que está sendo debatido. Deve resolver conflitos entre participantes (quando um impasse estiver estabelecido, cabe a ele, a decisão final). Ele auxilia também na preparação (homework) da JAD, introduzindo o problema para o grupo, no início da sessão.

PAULO - MPB

Jad - Definição de papéisMembros da equipe de desenvolvimento – a

equipe é formada, principalmente, por analistas de sistemas. EQUIPE WEBPACK

Usuários de negócio – pessoas que possuem o conhecimento e a experiência no domínio do problema (visão de negócio). Durante uma sessão JAD, os usuários contribuem com suas visões sobre os processos atuais e naquilo que precisa ser modificado. EQUIPE MPB

Jad - Definição de papéis

Secretário – pessoa que registra toda a informação discutida e as decisões tomadas durante a sessão. EDUARDO – WEBPACK

Facilitador – pessoa que coordena o processo de levantamento de requisitos. O objetivo do facilitador é direcionar e sustentar a discussão, garantindo que as metas da sessão sejam alcançadas. DOUGLAS - WEBPACK