domingo, 27 de maio de 2007

Usando cenários para descobrir requisitos

Os cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir.

Os cenários têm como foco as atividades que as pessoas realizam nas organizações possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido, explicando porque ele é necessário.

Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar discussões e estimular novos questionamentos. Eles permitem também documentar o levantamento de informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos.

Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os clientes e usuários envolvidos (muitas vezes de formação bastante heterogênea) que podem avaliar, criticar e fazer sugestões, proporcionando a reorganização de componentes e tarefas do domínio. Cenários oferecem um "meio-intermediário" entre a realidade e os modelos possibilitando que clientes, usuários e desenvolvedores participem do levantamento das informações e especificação dos requisitos. Em resumo, os cenários permitem compreensão dos problemas atuais pelos analistas e antecipação da situação futura pelo clientes e desenvolvedores.

Antes de descrever os cenários, os analistas devem entrevistar clientes para entender os problemas e requisitos iniciais. A entrevista com usuários permite que cada um descreva as suas tarefas e os problemas associados a cada uma delas. A observação direta in loco é fundamental para que os analistas possam descrever a situação de uso como ela realmente vem ocorrendo na prática.

Após a elaboração dos cenários, clientes, usuários e analistas podem participar de reuniões conjuntas para que possam discutir cada um destes cenários. Eles podem ser afixados em quadros na parede onde os participantes possa analisá-los e fazer comentários, possivelmente afixando pequenos pedaços de papel a cada uma das cenas.

Uma técnica que está bastante relacionada com cenários, por permitir descrever situações de uso, é o storyboarding. Essa técnica envolve a descrição através de quadros com imagens que ilustram as situações do domínio. Cada quadro deve apresentar a cena que descreve a situação, os atores e as ações que cada um deve desempenhar. Abaixo de cada quadro devem estar descritas as ações que os atores desempenham. Os storyboards são bastante utilizados em cinemas como forma de comunicação entre roteiristas, diretores, atores e técnicos.

Exemplos de cenários

Como exemplo vamos considerar o domínio de uma locadora de fitas de vídeo.

Cena 1: Cliente procura uma fita com uma certa atriz
Agentes: Cliente, Atendente, Balconista
Ações:

Cliente entra na loja e dirige-se até a atendente.
Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum específico?
Cliente: - Não, mas que não seja policial ou ação.
Atendente: Você sabe o nome dela?
Cliente: Não.
A atendente pergunta à balconista.
Atendente: - Você sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. É um nome bem complicado. Só sei que começa com G e o sobrenome é algo parecido com Paltrow.
Cliente: É isto mesmo.
A atendente então procura no fichário de atrizes as que começam com G. Não encontra nenhum nome parecido com o que a balconista falou. Ela então lembra-se de consultar uma revista especializada com os ganhadores do Oscar 99 e lá descobre o nome correto da atriz. Entretanto, não existe realmente ficha alguma com os filmes estrelados por esta atriz. O fichário está desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que não gosta do gênero destes filmes e pergunta pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda não saiu em vídeo.


Cena 2: O cliente procura por filmes de um certo gênero
Agentes: Cliente, Atendente, Balconista
Ações:
Cliente: - Eu gostaria de comprar um filme de ação.
Atendente: - Nós apenas alugamos.
Cliente: - Tudo bem. Então, por favor, me dê algumas dicas de filmes de ação.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dúvida se já assistiu outros três. Ele também pergunta à atendente se os outros dois filmes são bons. Após conversar durante alguns minutos com a atendente que entende muito do gênero, decide ficar com seis fitas. A atendente encaminha o cliente à balconista para calcular o valor da locação e o prazo de devolução. Após consultar as tabelas de preços e prazos, a balconista apresenta três planos de pagamento.
Balconista: - Se você devolver em um dia, paga apenas R$ 6,00. Se devolver em seis dias paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Após este prazo paga mais R$ 2,00 por fita, por dia.

Cena 3: Cliente procura por filme usando o sistema de consulta
Agentes: Cliente e Sistema de Consulta
Ações:
João gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e, chegando lá, utiliza um sistema de consulta. Ele não lembra o título nem o diretor, mas sabe que se passava na guerra do Vietnã e lembra bastante da trilha sonora. Utilizando o sistema ele solicita as opções de filmes de guerra. Os sistema oferece a ele as possibilidades de escolher os filmes por local da guerra ou por época. João escolhe a sua opção (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam. Ele pode organizar esta lista, por diretor, atores e título. Na tela do sistema aparecem a ilustração com o cartaz de divulgação do filme e uma opção para ele visualizar o trailler. O sistema, entretanto, não possibilita ele ouvir a trilha sonora.
Após analisar algumas opções ele finalmente encontra o filme desejado, mas uma informação na tela do sistema indica que o filme está alugado. João quer saber quando o filme será devolvido, mas esta informação não consta no sistema. Ele entretanto pode reservar e o sistema enviará para ele um e-mail avisando quando o filme estiver disponível. Ele sai da loja pensando "Que tempo perdido. Seria melhor que eu pudesse consultar o sistema de casa".

sexta-feira, 18 de maio de 2007

Engenharia de Requisitos

Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples é a decisão de requisitos de segurança mais restritos que podem ir de encontro ao requisito de melhor desempenho.

A importância e complexidade de todas as atividades relacionadas aos requisitos levaram, no início dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.

Os objetivos da Engenharia de Requisitos podem ser categorizados em três grupos principais [Zave]:

  • Investigação de objetivos, funções e restrições de uma aplicação de software
    • Ultrapassar as barreiras de comunicação
    • Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
    • Compreender prioridades e graus de satisfação
    • Associar requisitos com os vários agentes do domínio
    • Estimar custos, riscos e cronogramas
    • Assegurar completude
  • Especificação do software
    • Integrar representações e visões múltiplas
    • Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
    • Obter uma especificação completa, consistente e não ambígua
    • Validar a especificação - verificar que ela satisfaz aos requisitos
    • Obter especificações que sejam apropriadas para as atividades de design e implementação
  • Gerenciamento da evolução e das famílias do software
    • Reutilização de requisitos durante o processo de evolução
    • Reutilização de requisitos no desenvolvimento de software similares
    • Reconstrução de requisitos

A engenharia de requisitos é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de observações do mundo real através de notações apropriadas.

Os benefícios da Engenharia de Requisitos são:

  • Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e quais os critérios de aceitação do sistema.
  • Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos)
  • Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
  • Atingir os objetivos com o mínimo de desperdício

Uma boa especificação de requisitos deve ser:

  • Clara e não-ambígua
  • Completa
  • Correta
  • Compreensível
  • Consistente
  • Concisa
  • Confiável

(Veja mais em Dorfman, Merlin - Requirements Engineering)

Técnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os clientes e usuários e os analistas para que os requisitos possam capturados e modelados corretamente.

Dentre as técnicas mais importantes para a comunicação podemos citar três:

  • Entrevistas
  • Observação in loco
  • Encontros

Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas.

Na observação in loco os analistas devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários.

Os encontros são reuniões envolvendo analistas, clientes e usuários que têm por objetivo exclusivamente realizar o levantamento de informações, a descrição dos problemas atuais e indicar metas futuras e requisitos do sistema. Os encontros devem ser realizados em um local neutro (fora da organização), coordenados por um moderador que também não deve pertencer ao grupo dos envolvidos (stakeholders) e normalmente duram de 1 a 3 dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em painéis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.

Modelos de documentos de especificação de requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção deve ser apresentado aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.

Vamos apresentar, a seguir, dois modelos de documentos encontrados na literatura. Estes modelos descrevem não apenas a especificação dos requisitos, mas os resultados do estudo de viabilidade e o processo de desenvolvimento.

Pressman apresenta o seguinte documento de especificação de requisitos de software:


I. Introdução

1. Referências do Sistema
2. Descrição Geral
3. Restrições de projeto do software

II. Descrição da Informação

1. Representação do fluxo de informação

a. Fluxo de Dados
b. Fluxo de Controle

2. Representação do conteúdo de informação
3. Descrição da interface com o sistema

III Descrição Funcional

1. Divisão funcional em partições
2. Descrição funcional

a. Narativas
b. Restrições/limitações
c. Exigências de desempenho
d. Restrições de projeto
e. Diagramas de apoio

3. Descrição do controle

a. Especificação do controle
b. Restrições de projeto

IV. Descrição Comportamental

1. Estados do Sistema
2. Eventos e ações

V. Critérios de Validação

1. Limites de desempenho
2. Classes de testes
3. Reação esperada do software
4. Considerações especiais

VI. Bibliografia
VII Apêndice

Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de requisitos deve possui as seguintes seções:

  • Visão geral do produto e Sumário
  • Ambientes de desenvolvimento, operação e manutenção
  • Interfaces Externas e Fluxo de Dados
  • Requisitos Funcionais
  • Requisitos de Desempenho
  • Tratamento de Exceções
  • Prioridades de Implementação
  • Antecipação de mudanças e extensões
  • Dicas e diretrizes de Design
  • Critérios de aceitação
  • Índice Remissivo
  • Glossário
Referências

Dorfman, Merlin - Requirements Engineering

Zave, Pamela - Classification of Research Efforts in Requirements Engineering - ACM Computing Surveys, vol. 29, no 4, 1997.

terça-feira, 15 de maio de 2007

Requisitos de Software

Vimos que o software é parte de um sistema computacional mais abrangente e que a Análise de Sistemas é a atividade de identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado o escopo do software, os requisitos do software devem ser definidos e especificados.

O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido.

O que são requisitos?

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários que definem as suas diversas propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.

São exemplos de requisitos funcionais:
  • "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
  • "o software deve emitir relatórios de compras a cada quinze dias"
  • "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.
A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem.

Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente quer segurança mas os usuários querem facilidade de uso) e são difíceis de validar.

São exemplos de requisitos não-funcionais:
  • "a base de dados deve ser protegida para acesso apenas de usuários autorizados".
  • "o tempo de resposta do sistema não deve ultrapassar 30 segundo".
  • "o software deve ser operacionalizado no sistema Linux"
  • "o tempo de desenvolvimento não deve ultrapassar seis meses".
A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Além disso, os requisitos exercem influência uns sobre os outros o que determina uma maior dificuldade no processo. Por exemplo, o requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos). Devido à esta complexidade, faz-se necessário que as atividades associadas aos requisitos sejam gerenciadas durante todo o ciclo de vida do sistema.

Análise e especificação de requisitos de software

A análise e a especificação de requisitos de software são atividades para determinar os objetivos de um software e as restrições associadas a ele, bem como elaborar a especificação precisa do software.

Estas atividades devem ser vistas como parte da análise de sistemas. Normalmente, elas são iniciadas juntamente com a análise do sistema, podendo se estender após a elaboração do documento de especificação do sistema, quando serão refinados os requisitos do software.

Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente. A análise é o processo de observação, classificação e modelagem dos elementos do domínio. Deve-se identificar as pessoas, as atividades, as informações do domínio para que se possa decidir o que fará parte do sistema. Pessoas e as atividades que não serão informatizadas deverão ser consideradas entidades externas ao software.

A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o problema do domínio. A especificação é também a forma de comunicação sistemática com os arquitetos, programadores e testadores do software.

Veja Slides de aula em PDF.

terça-feira, 8 de maio de 2007

Planejamento: visão geral resumida

Agora que já conhecemos o processo de estimativas e algumas das métricas utilizadas, vejamos um exemplo de como podemos realizar o planejamento.

A figura a seguir mostra uma visão geral do planejamento.

Com base no modelo de processo de software podemos definir as atividades que precisam ser realizadas. Estas atividades devem ser organizadas em uma estrutura de divisão do trabalho (WBS - Work Breakdown Structure).

Para cada uma das atividades estão definidos os artefatos resultantes e podem ser realizadas estimativas de tamanho destes resultados. Por exemplo, o número de linas de código fonte de uma atividade de codificação ou o número de elementos de diagrama em uma atividade de modelagem.

Com as atividades definidas, pode-se montar a equipe de software. Dados históricos podem indicar as estimativas de produtividade dos membros desta equipe nas atividades definidas no WBS.

As estimativas de tamanho do software podem ser utilizadas para o cálculo das estimativas de esforço para cada atividade. Este valor permite que a alocação pessoa-atividade seja mais eficiente. Por exemplo, para tarefas com maior esforço, pode-se dividir as tarefas entre vários membros da equipe de forma a encurtar o prazo de conclusão da atividade (veja mais informações no post anterior).

Com as estimativas de esforço e a alocação pessoa-atividade, podemos elaborar o cronograma e o orçamento do projeto.

O cronograma deve incluir a definição dos marcos, a análise do caminho crítico através de técnicas PERT/CPM e o diagrama de Gantt.

Os gastos com pessoal são fundamentais para o orçamento do projeto. Assim, apenas com a definição do cronograma é que se pode concluir o orçamento. Além dos custos de RH, não se pode deixar de incluir os custos com equipamentos, ferramentas, infra-estrutura e outros. Veja mais sobre custos.