3 elementos centrais do RUP

1. desenvolvimento orientado pelo negócio

2. framework com blocos de conteúdo de método e processo reutilizáveis

3. uma linguagem para definição de método e processo

–UMA (Unified Method Architecture )

6 princípios do RUP

Como é do nosso conhecimento os americanos adoram usar acrônimos para ajudar a gravar algum tipo de informação, e aqui os seis princípios do RUP são elencados em ordem alfabética de A , B, C, D, E, F, a saber:

Adaptar o processo

O princípio do tamanho único não se aplica ao desenvolvimento de software

Benefícios

–eficiência do ciclo de vida

•o processo adequado, para um determinado tipo de projeto, para uma determinada organização

–comunicação dos riscos

•menor controle e formalidade nas fases iniciais do projeto são essenciais para uma comunicação aberta e honesta, a qual resulta na melhor identificação dos riscos do projeto

Padrões

–tamanho certo do processo

–adaptar cerimonia do processo à fase do ciclo de vida

–melhoria contínua do processo

–planejamento e estimativas orientadas pelas incertezas

Anti-pradões

–baseline de estimativas precoce

–planejamento estático

Balancear as prioridades dos envolvidos

É um dos principais desafios que deve ser gerido durante o desenvolvimento do software

Benefícios

–aumento do alinhamento com o negócio

–redução do custo do desenvolvimento

–otimização do valor ao negócio

Padrões

–definir, entender e priorizar as necessidades do negócio e dos usuários

–priorizar requisitos e casá-los com a capacidade do software

–entender quais ativos podem ser alavancados

–balancear a reutilização com as necessidades dos usuários

Anti-pradões

–documentar precisamente todos os requisitos e obrigar a aceitação pelos usuários

–definir a arquitetura de um sistema para atender as necessidades dos envolvidos mais influentes

Colaborar entre os diversos times

Com os sistemas sendo arquitetado em um lado e o código sendo desenvolvido do outro lado do mundo, a dispersão das equipes é um fato. a comunicação efetiva é um fator de sucesso

Benefícios

–aumento da produtividade

–sinergia entre necessidades do negócio, o desenvolvimento e a área de operação

Padrões

–motivar as pessoas para fazerem o seu melhor

–times auto gerenciados

–colaboração entre áreas com diferentes capacidades

–prover ambiente colaborativo

–gestão envolvendo artefatos e tarefas

–integrar os times de negócio, software e operação

Anti-pradões

–desenvolvimento heroico, com horas extras

–pessoas altamente especializadas com baixo nível de colaboração

–assumir que se cada um faz o seu trabalho, o resultado será bom

Demonstrar valor iterativamente

Para um processo de desenvolvimento orientado ao negócio, demanda que o time de projeto demonstre o retorno do investimento em uma abordagem repetitiva ao longo do projeto

Benefícios

–redução precoce do risco

–previsibilidade do projeto

–credibilidade entre os envolvidos

Padrões

–incentivar feedbacks

–assumir que haverá mudanças

–remover os riscos

–adaptar os planos

Anti-pradões

–planejar o projeto inteiro em detalhes

–dedicação em entregáveis diferentes de um código executável

Elevar o nível de abstração

Uma abordagem de sucesso para tratar com complexidade é alavancar o uso de padrões e serviços, reutilização de componentes em vez de construir o software do zero.

Benefícios

–aumento da produtividade

–redução da complexidade

Padrões

–reutilização dos ativos existentes

–utilização de padrões (patterns)

–utilização de serviços

–uso de linguagens e ferramentas de alto nível

–foco na arquitetura

Anti-pradões

–ir diretamente dos requisitos de alto nível, para o código

Focar continuamente na qualidade

A qualidade inicia quando um requisito é documentado. A qualidade do sistema é afetada pela sua arquitetura. A inspeção de código e os testes unitários garantem que o código está aderente aos padrões estabelecidos. Os testadores testam baseados nos cenários de casos de uso, ou com requisitos não funcionais. A responsabilidade de encontrar erros deve ser compartilhada entre todo o time desenvolvimento

Benefícios

–qualidade elevada

–visão antecipada dos progressos obtidos e da sua qualidade

Padrões

–assegurar que e equipe seja a dona da qualidade do produto

–testar o mais cedo possível, e continuamente, demonstrando as capacidades do software em desenvolvimento

–construir a automação de testes incrementalmente

Anti-pradões

–revisões em pares muito aprofundadas

–finalizar os testes unitários antes do teste de integração

Tenho certeza que se você é um desenvolvedor e leu os 6 princípios do RUP, conseguiu identificar mais de um anti-padrão no seu processo de desenvolvimento atual. Estou certo?

 artigo adaptado do livro : IBM Rational Unified Process Reference and Certification Guide. 
 autores: Ahmad K. Shuja; Jochen Krebs.

Iniciação

Objetivo: Desenvolver e obter a aprovação de uma declaração geral do objetivo e valor para o negócio do projeto.

Atividades:

Planejamento

Classes podem ter atributos definidos. Um atributo é um valor que pode ser associado a uma instância de uma classe. Classes também podem ter operações definidas. Uma operação é um método ou função que pode ser executada por uma instância de uma classe.

Use os seguintes passos para criar um diagrama de classes que descreve os relacionamentos entre as seguintes classes LOJA, LIVRARIA, e LIVROS. Livraria é uma versão mais específica de loja e livraria contém múltiplos livros.

1. Execute o Visual Studio. Crie um novo projeto de modelagem selecionando FILE => NEW=>PROJECT para abrir a janela de NOVO PROJETO. Selecione o template MODELING PROJECT, a partir do menu Templates. De um nome ao projeto e o local em que será salvo e clique em OK. Um novo projeto é exibido no SOLUTION EXPLORER

2. Clique com o botão direito do mouse no SOLUTION EXPLORER e selecione ADD=> New Item a partir do menu de contexto.  Selecione o template para UML Class Diagram e coloque o seu nome de Livros.classdiagram. Clique no botão Add para criar esse diagrama.

3. Um diagrama de classes em branco nomeado de livro.classdiagram é criado no projeto de modelagem e exibido numa aba do Visual Studio

4. A partir da tab Tolbox clique no elemento Class e então clique em um espaço em branco no diagrama de classes UML. Isso cria um objeto classe no diagrama. No campo properties da classe, altere o nome para Loja. Essa será uma classe genérica para loja, da qual a livraria irá ter uma relação de herança. Defina a propriedade Is Abstract da classe Loja para True, para indicar que ela é uma classe abstrata.

Observação: note que quando definimos a classe como abstrata, a fonte do título da classe muda para itálico.

5. A classe Loja tem um para de atributos genéricos que se aplicam a todas as lojas, como endereço e horário de funcionamento.  Clique com o botão direito do mouse sobre a classe Loja e selecione Add -> Attribute para criar um novo atributo. Coloque o nome do novo atributo de Endereço. Selecione o atributo Endereço, e na janela de Properties, defina a propriedade de Type para ser do tipo String. Adicione um segundo atributo denominado Horário, e define a propriedade de Type para ser do tipo String também.

6. Crie a classe Livraria. A classe livraria tem um relacionamento de herança com a classe Loja criada anteriormente, já que ela é um tipo especializado de loja. Utilizando a janela do Tolbox adicione outro objeto de classe ao diagrama, abaixo do objeto Loja, e defina o nome de Livraria para esse novo objeto. Selecione o elemento Inheritance na janela do Tolbox. Clique sobre a classe Livraria e então clique sobre a classe Loja. Uma seta sólida aparece e aponta da classe Livraria para a classe Loja, indicando que a Livraria herda da classe Loja. As operações e atributos herdados da classe Loja não são normalmente mostrados na classe Livraria. Entretanto você pode utilizar o “smart tag” na seta de herança para adicionar as operações herdadas para a classe especializada (Livraria). Simplismente clique na “smart tag” e selecione Override Operations. Então selecione quais operações devem ser mostradas na classe especializada.

7. Agora cria uma classe para livros. Adicione outro objeto classe ao diagrama abaixo da classe livraria e defina seu nome como Livro. Adicione dois atributos para a classe Livro: Preço, do tipo Integer; e Numero de Paginas, do tipo Integer. Selecione o elemento Association na janela Tolbox, clique na classe Livraria e então clique na classe Livro. Um elemento Association é usado para representar qualquer tipo de ligação entre dois elementos, independentemente de como essa ligação será realmente implementada no código propriamente dito.

8. Uma livraria pode ter diversos livros, então você deve modificar a propriedade Multiplicity da classe Livro. Selecione a ligação Association entre as classes Livraria e Livro. Na janela Properties, clique na seta próximo ao Second Role property e expanda a mesma. Mude o valor de Multiplicity para *, indicando que a Livraria pode conter diversos livros.

9. Adicione uma operação para pedido de livros para a classe Livraria. Clique com o botão direito do mouse na classe Livraria, e selecione Add -> Operation. Defina o nome da operação para PedidoLivro

10. Você deve definir os parâmetros e o tipo de retorno para essa operação selecionando a operação PedidoLivro e indo para a janela de Properties. Nessa janela defina o Return Type para Boolean. Clique a elipse no campo Parameters para abrir a janela de Operation Parameter Collection Editor. Nessa janela clique no botão Add para criar um novo parâmetro. Defina o nome do parâmetro como Item, e o tipo como Livro. Clique o botão Add novamente e crie um segundo parâmetro denominado Quantidade com um Type Integer. Clique no botão OK para fechar a janela do Operation Parameter Collection Editor.

10. A figura abaixo ilustra o resultado final desse diagrama de classes

Tolbox para Diagrama de Classes

A figura abaixo ilustra os diferentes elementos e associações disponíveis para os diagramas de classes

A tabela abaixo descreve os diferentes elementos e associações disponíveis para os diagramas de classes

*adaptado do livro Professional Application Lifecycle Management with Visual Studio 2012. Mickey Gousset, Brian Keller, Martin Woodward

Agora vamos tomar como exemplo que iremos testar um site de uma livraria virtual. Para que possamos orientar os testes a riscos precisamos fazer uma análise sobre quais funcionalidades apresentam maiores riscos para o negócio. A tabela abaixo ilustra um exemplo para essa análise:

No exemplo da tabela acima para cada funcionalidade estabelecemos um valor de 1 a 5 para o impacto da funcionalidade no negócio (onde 5 é o maior impacto) e também um valor de 1 a 5 para a probabilidade de ocorrência do impacto em questão. A partir disso chegamos a magnitude do risco dada pela multiplicação entre impacto e probabilidade.

Nessa análise estabelecemos o maior impacto (5) para as seguintes funcionalidades:

• Inclusão de itens
• Pagamento cartão de crédito
• Carrinho de compras
• Cadastro do cliente

Ainda nessa análise estabelecemos a maior probabilidade para as seguintes funcionalidades:

• Inclusão de item no cadastro
• Pagamento cartão de crédito

Carrinho de compras e cadastro de cliente tiveram probabilidades medias (3) devido a serem funcionalidades já componentizadas e com menos probabilidades de apresentarem defeitos
Assim podemos agora estabelecer uma lista em ordem decrescente de riscos das nossas funcionalidades:

Caso o resultado final não expresse o risco de cada funcionalidade, devemos reavaliar o impacto e a probabilidade de cada funcionalidade, até chegarmos a uma lista adequada sobre riscos. No nosso exemplo definimos os maiores riscos para as funcionalidades de inclusão de itens no cadastro (para que possamos garantir o funcionamento do catalogo de livros) e o pagamento por cartão de credito (por ser o tipo de pagamento mais utilizado).

A partir dessa análise podemos agora direcionar as prioridades para a elaboração dos casos de testes. Para cada funcionalidade devemos criar um conjunto de casos de testes que possuam uma boa cobertura da funcionalidade em questão. Os casos de testes devem ser classificados por prioridade: alta – casos de teste que se descobrir defeitos impedem o funcionamento do software, média – aqueles cujo defeito permite ainda o uso do software com alguma ação de contorno, e baixa – se apresentarem algum defeito será do tipo cosmético ou de melhorias no uso da funcionalidade.

Finalizado a criação dos casos de testes para cada funcionalidade, com suas respectivas categorizações de prioridade teremos insumos para direcionar a execução dos testes por riscos: em função do prazo disponível para a execução dos testes você pode estabelecer diferentes abordagens de execução. Por exemplo:

Executar 1º os casos de testes de alta prioridade das funcionalidades de alto risco, e depois os casos de testes de média prioridade. Em seguida aplicar esse mesmo procedimento para as demais funcionalidades em ordem decrescente do risco de cada uma. Por fim executar os casos de teste de prioridade baixa também em ordem decrescente do risco de cada funcionalidade.

Nessa abordagem o prazo foi gasto priorizando-se as funcionalidades de mais alto risco com os casos de testes de alta e média prioridade, deixando-se para o final (se houver tempo) os casos de testes de baixa prioridade de todas as funcionalidades. Essa abordagem pode ser interessante pois é comum ter situações onde o cronograma de execução de testes é curto e ainda assim ocorrer cortes de prazo para liberação do software para a homologação pelo cliente.

Nesses casos essa abordagem garantirá que o prazo que foi gasto até ocorrer o corte de prazo, priorizou os casos de testes de alta e média prioridade em ordem decrescente dos riscos de cada funcionalidade. Logicamente podem ser construídas outras a abordagens para execução dos testes. O importante é que agora você tem os insumos para definir a melhor abordagem para os testes orientados a riscos da sua próxima implantação de software.

Um diagrama de atividade sempre tem um nó de inicio, uma série de atividades e um nó final que indica o fim da atividade.

Os seguintes passos descrevem o processo de criar um diagrama de atividade que mostra a sequencia de atividade para o pedido de um livro na livraria virtual. Um cliente primeiro escolhe um livro. Depois disso, o cliente toma a decisão se escolhe mais livros ou confirma o pedido. Após o cliente finalizar a escolha dos livros, o cliente confirma o pedido dos livros e paga pelo pedido realizado.

1. Execute o Visual Studio. Crie um novo projeto de modelagem selecionando FILE => NEW=>PROJECT para abrir a janela de NOVO PROJETO. Selecione o template MODELING PROJECT, a partir do menu Templates. De um nome ao projeto e o local em que será salvo e clique em OK. Um novo projeto é exibido no SOLUTION EXPLORER

2. Clique com o botão direito do mouse no SOLUTION EXPLORER e selecione ADD=> New Item a partir do menu de contexto.  Selecione o template para UML Activity Diagram e coloque o seu nome de PedidoLivro.activitydiagram.

3. Clique no botão ADD para criar esse diagrama. Um diagrama de atividade em branco nomeado de PedidoLivro.activitydiagram é criado no projeto de modelagem e exibido numa aba do Visual Studio

4. A partir do Toolbox, arraste um elemento INITIAL NODE para o lado esquerdo do diagrama. Isso indica o ponto inicial para essa atividade. Todo diagrama de atividade necessita desse elemento.

5. Arraste três elementos ACTION no diagrama do lado direito (um abaixo do outro) do elemento INITIAL NODE. Usando o campo PROPERTIES NAME dos elementos defina o nome desses itens como ESCOLHER UM LIVRO, CONFIRMAR PEDIDO e PAGAR UM LIVRO. O elemento ACTION representa um passo da atividade que o sistema ou o usuário realiza.

6. A partir do TOOLBOX, arraste um MERGE NODE acima da ação ESCOLHER UM LIVRO. Esse nó é usado para mesclar múltiplos fluxos, usualmente separados por um nó de decisão. Um MERGE NODE requer duas ou mais entradas e tem uma saída única.

7. Arraste e solte um DECISION NODE entre ESCOLHER UM LIVRO e CONFIRMAR PEDIDO. Esse nó é utilizado para criar fluxos de ramificação na atividade. Para esse diagrama de atividade, após um livro ser escolhido o cliente tem a escolha de confirmar o pedido ou selecionar mais livros. Um DECISION NODE tem uma entrada única e duas ou mais saídas.

8. Arraste um ACTIVITY FINAL NODE para a direita da ação PAGAR UM LIVRO. Isso indica o fim da atividade.

A seguir você deve adicionar os conectores para mostrar o fluxo de atividade através desse diagrama de atividade. No toolbox de um duplo clique no elemento CONNECTOR para selecioná-lo. No diagrama de atividade, arraste uma linha entre o INITIAL NODE e o MERGE NODE. Continue conectando os outros elementos do diagrama conforme segue:

a. Conecte o MERGE NODE com a ação ESCOLHER UM LIVRO

b. Conecte a ação ESCOLHER UM LIVRO com o DECISION NODE

c. Conecte o DECISION NODE com a ação CONFIRMAR PEDIDO

d. Conecte o DECISION NODE com o MERGE NODE

e. Conecte a ação CONFIRMAR PEDIDO com a ação PAGAR UM LIVRO

f. Conecte a ação PAGAR UM LIVRO com o ACTIVITY FINAL NODE

7. Modifique a propriedade GUARD dos elementos CONNECTOR do DECISION NODE para especificar a razão para os diferentes fluxos. No CONNECTOR para a ação CONFIRMAR PEDIDO, adicione o GUARD Finalizar Pedido. No CONNECTOR para o MERGE NODE, adicione o GUARD Continuar Comprando.

Quando finalizado o diagrama deve ficar como o da figura abaixo:

 Fluxo concorrente no diagrama de atividade

Diagramas de atividades podem também serem usados para descrever uma sequencia de ações executadas ao mesmo tempo. Essa sequencia de ações são conhecidas como fluxo concorrente. A figura abaixo mostra um exemplo de diagrama de atividade com fluxo concorrente relacionado ao pedido de livro.

No inicio desse diagrama de atividade, um pedido é criado. Após a criação do pedido duas ramificações diferentes são iniciadas. A barra preta à qual a ação CRIAR PEDIDO LIVRO se conecta é chamada de FORK NODE e é usada para dividir um fluxo simples em um fluxo concorrente. Nesse caso um fluxo vai para a ação DESPACHAR LIVRO. O outro via para o elemento ENVIAR FATURA LIVRO

O elemento ENVIAR FATURA LIVRO não é um elemento de ação regular. Ele é um elemento SEND SIGNAL ACTION. Isso indica uma ação que envia uma mensagem para outra atividade para que algo aconteça. O RECEBER PAGAMENTO LIVRO é um elemento ACCEPT EVENT ACTION. É uma ação que aguarda por uma mensagem antes do fluxo prosseguir. Nesse caso, uma ordem de pedido de livro será enviada, provavelmente para o sistema de pagamento. O fluxo no diagrama de atividade espera até que uma resposta seja recebida, indicando que o livro foi pago. Ambas as ações DESPACHAR LIVRO e RECEBER PAGAMENTO LIVRO são então mescladas novamente em um processo único, usando um JOIN NODE. A atividade finaliza com FECHAR PEDIDO.

Nota. Você pode definir o FORK NODE e o JOIN NODE para uma orientação vertical se desejar.

Toolbox do diagrama de atividade

A figura abaixo mostra os diferentes elementos e associações disponíveis para o diagrama de atividade

A tabela abaixo descreve os diferentes elementos e associações:

*adaptado do livro Professional Application Lifecycle Management with Visual Studio 2012. Mickey Gousset, Brian Keller, Martin Woodward

Brincadeiras a parte, deixo registrado aqui os meus agradecimentos aos mais de 23.000 visitantes que passaram pelo nosso blog em 2012, e geraram mais de 48.000 visualizações de páginas, permitindo um crescimento de 30% em relação a 2011. Novamente o meu muito obrigado! Espero vocês aqui novamente em 2013.

Segue abaixo os 5 artigos publicados em 2012 e que tiveram mais acessos segundo o Google Analytics:

1. Modelo para gestão de projetos baseado em princípios ágeis

2. Modelos prescritivos para o desenvolvimento de software

3. Levantamento e análise de requisitos uma visão pragmática sobre ferramentas

4. Criando diagrama de caso de uso com visual studio ultimate 2012 passo a passo

5. Framework para desenvolvimento ágil

Segue também os 5 sites que estiveram no meu bookmark em 2012

1. Khan Academy

2. Havard Business Review

3. Computing Now

4. Scientific Research

5. Dilma Bolada (porque eu não sou de ferro, e a nossa política é uma piada!)

Feliz 2013 a todos !

Vamos rever os modelos mais comuns para o mercado de testes funcionais de software:

1) Tamanho do projeto

Nesse modelo se estabelece alguma unidade de medida do tamanho do projeto, por exemplo KLOC; quantidade de pontos de função, quantidade de funcionalidades e então se define o esforço necessário para os testes

2) Horas x homem

Nesse modelo estima-se uma quantidade de recursos necessários para os testes (geralmente com dois perfis diferentes, o do testador e o do analista de testes)  e então se calcula o esforço necessário para os testes X o período de tempo gasto para os testes

3) Por entregáveis

Nesse modelo o fornecedor será remunerado pelos artefatos que ele entregar: plano de testes, roteiros de testes, caso de testes executados

4) Por bugs encontrados

Aqui o fornecedor passa a ser remunerado a partir do total de bugs encontrados. Deve-se classificar os tipos de bugs, por exemplo : interface gráfica, erro de ortografia e erros funcionais. A partir dessa classificação se estabelece faixas de valores a serem pagos, onde um erro funcional vale mais que um erro de interface gráfica, por exemplo.

Mas fora do mundo do software, como pagamos pelos serviços que consumimos?

Energia elétrica – o serviço de energia elétrica nos é faturado da seguinte forma (exemplo para São Paulo, excluindo-se os tributos e outros serviços):

O fornecimento é medido em KWh – Quilo Watt x Hora o qual é multiplicado por um fator Tarifa de Energia (TE), e também multiplicado por um fator de Tarifa do Uso do Sistema de Distribuição (TUSD). Assim se você consumiu no mês 300 KWh, considerando-se o fator de TE = 0,14821 e TUSD = 0,14293, o valor a ser pago seria : (300 * 0,14821) + (300 * 0,14293) = 87,33

Telefonia – o serviço de telefonia nos é faturado da seguinte forma (exemplo para São Paulo, provedor NET, excluindo-se o ICMS)

Somatória de minutos gastos em ligações para celulares x  0,88

Somatória de minutos gastos em ligações para telefones fixos x 0,12

Água e Esgotos – esse serviço é faturado da seguinte forma (exemplo para São Paulo – Sabesp)

A medida de consumo é feita em M3 (metros cúbicos) e multiplicado pelos seguintes fatores:

até 10 m3 = R$ 15,94

11 a 20 m3 = R$ 2,49

21 a 30 m3 = R$ 6,22

31 a 50 m3 = R$ 6,22

Acima de 50 m3 = R$ 6,86

Assim se você consumiu 18 m3 o valor a ser pago seria:

10 m3 @ R$ 15,94

8 m3 @ R$ 2,49 = R$ 19,92

Total = R$ 35,86

Esse valor total será cobrado duas vezes: um para o consumo de água e outro para o consumo de esgoto, totalizando R$ 71,72

O que esses três modelos de faturamento nos diz ?

1) Cada um tem a sua unidade de medida de consumo: KWh para energia elétrica; minutos para telefonia, e m3 para água

2) Cada um tem seus próprios fatores de qualificação do serviço:

Tarifa de energia e Tarifa do uso do Sistema de distribuição para energia elétrica

Valor de ligação para celular e valor de ligação para telefone fixo para telefonia

Valor de consumo de água e de consume de esgoto para aguas e esgotos

Agora a partir desses três exemplos, vamos fazer uma extrapolação para o modelo de faturamento de serviços de testes funcionais:

1) Qual a unidade de medida a ser utilizada?

Dos quatro exemplos citados no início desse artigo, tamanho de projeto, horas x homem, entregáveis, e por bugs encontrados, vou ficar com o de tamanho por projeto. Além disso, vou propor utilizar a unidade de medida de pontos de função, e explico o porque: pontos de função me parece a unidade de medida mais madura para dimensionar o tamanho do sistema que será testado, é uma prática amplamente disseminada no mercado com uma boa quantidade de profissionais certificados no seu processo de contagem

Pronto: o nosso ponto de função seria equivalente ao kwh, ao minuto, ou ao m3. Mas agora precisamos qualificar o ponto de função, pois precisamos ainda responder: quanto custa testar um ponto de função?

Segundo Capers Jones, há um forte relacionamento entre ponto de função e caso de testes:

Para casos de testes de homologação: nº pontos de função x 1,2

Para casos de testes de sistemas: nº pontos função elevado 1,2

Assim para um sistema de 100 pontos de função teríamos a seguinte relação:

120 casos de testes de homologação e

251 casos de testes de sistemas

Para chegarmos à resposta final de quanto pagar pelo serviço de testes funcionais, precisamos estabelecer algumas premissas:

1. Vamos considerar a execução de 3 ciclos completos dos casos de testes

2. Vamos estabelecer as seguintes produtividades do prestador de serviços:

a) elaboração: 3 casos de testes x hora

b) execução : 4 casos de testes x hora

4) Custo por hora para projetista de casos de testes R$ 70,00

Custo por hora para executor de casos de testes R$ 45,00

Agora podemos calcular o custo final:

a) para elaboração dos casos de testes : nº pf x R$ 58,56

b) para execução dos casos de testes: nº pf x R$ 28,23

Simplificando, teríamos nº pf x 143,25 para a elaboração e execução do 3 ciclos completos de testes

Ajuste os valores de produtividade e de custo do projetista e do executor de testes do seu fornecedor de serviços e descubra o seu fator (no nosso exemplo, 143,25) que deverá ser multiplicado pela unidade de medida padrão: pontos de função para ter o valor a ser pago pelo serviço de testes funcionais.

O uso de protótipos é particularmente útil quando:

• o produto é novo e é difícil visualizar suas funcionalidades
• os envolvidos não tem experiência nem com o tipo de produto nem com a tecnologia proposta
• os envolvidos estão enfrentando problemas em articular os requisitos necessários
• o analista tem dificuldades de entender quais requisitos são necessários
• há dúvidas sobre o quanto um determinado requisito é realizável

Dado o tamanho e a complexidade de suas funcionalidades, projetos maiores deveriam explorar mais a técnica de prototipagem para descobrir funcionalidades, conforme ilustra a tabela abaixo:

O protótipo torna o produto real o suficiente para os envolvidos trazerem requisitos, que sem o protótipo não seriam capturados. Ele inspira os envolvidos a lembrar de outros requisitos, que sem o protótipo poderiam aparecer apenas quando o produto já estivesse em uso

Às vezes surgem requisitos que é defendido por apenas um envolvido, que jura ser o requisito mais importante do produto. Nesses casos o protótipo dá a oportunidade de que todos entendam e discutam o requisito e decidam sobre seus méritos de ser incluído ou não na versão final do produto

Deve-se sempre tentar técnicas de prototipagem que atendam aos artefatos e experiências que são mais familiares aos envolvidos. Isso significa ajustar o protótipo a cada situação de trabalho

Protótipos de baixa fidelidade

Permitem que os envolvidos se concentrem no assunto principal usando canetas, quadro branco, flip charts, post-it…

–prós

• não haverá confusão entre o protótipo e o produto final
• baixo investimento
• fica claro que é um desenho que pode mudar facilmente
• estimula a interação

–contras

• demanda mais esforço dos envolvidos para testá-lo
• dificuldade de abstrair alguns desenhos como sendo o futuro produto que o cliente necessita

Recomenda-se elaboração do protótipo de um caso de uso por vez. Esse tipo de protótipo produz melhores resultados quanto utilizado no início do desenvolvimento, permitindo que os envolvidos forneçam mais  feedbacks quando ainda não estão tão fixados no design ou aparências. Nesse estágio as ideias são mais fluídas e uma experimentação rápida e fácil resultará em um produto melhor.

Protótipos de alta fidelidade

Construído com a utilização de ferramentas de software permite aos envolvidos usar um visual realista do produto a ser desenvolvido, e decidir se o produto exibe os requisitos corretos.

–prós:

• interativo e estimula a sua exploração pelos envolvidos
• simula o mundo real
• eficiente para descobrir requisitos de usabilidade

–contras

• envolvidos podem se concentrar na aparência visual e esquecer as funcionalidades
• risco dos envolvidos acharem que o protótipo poderá ser a versão final do produto
• além de se considerar os feedbacks dos envolvidos, considere a contribuição de um designer, que certamente poderá agregar com suas ideias
• é um tipo de protótipo indicado para produtos destinados ao mercado em massa
• serve com o um veículo para colher feedbacks de grupos representativos dos clientes

Ciclo da prototipação

Projeto e construção

–qual o objetivo do protótipo?

• requisitos funcionais, não funcionais?
• explora um caso de uso desconhecido, ou explorará um funcionalidade conhecida apenas para validação?

–identificar envolvidos que darão feedback sobre o protótipo

–planejar como será executada cada sessão do protótipo

–procure construir o protótipo junto com os envolvidos e gaste mais tempo testando o protótipo junto com os envolvidos

Testes no ambiente do usuário

–onde os usuários e outros envolvidos usam o protótipo como uma simulação do seu trabalho, e o analista objetivamente registra os seus feedbacks

–deve haver participação dos especialistas em usabilidade nos testes

• usabilidade é parte integral do produto e não um acessório opcional que pode ser adicionada a qualquer momento

Analisar os resultados

- verificar se os envolvidos descobriram novos requisitos

- verificar se é necessário alterar o protótipo e executar mais testes

- protótipo não é uma especificação de requisitos, é uma simulação de especificação.

- os requisitos reais necessitarão ainda ser extraídos

- o ciclo do protótipo pode ser repetido várias vezes

-os objetivos e os resultados devem ser revisitados a cada ciclo

A partir disso, vamos elencar os principais problemas na elicitação de requisitos:

o ignorante perdido

A elicitação deve ser conduzida pelas pessoas seniores da equipe, adequadamente treinadas. Uma mistura de pessoas mais e menos experientes é desejável para o desenvolvimento do time. É aconselhável ter também alguém que não possua conhecimento do domínio do problema: aqueles que não têm medo de perguntar:  o que isso significa? Além disso, ele ajudará na coleta suficiente de informações e para evitar que seja usado diferentes termos para o mesmo significado

envolvidos errados

envolvidos ou especialistas no assunto podem não responder por toda a organização. é importante identificar os seus relacionamentos com o projeto:

- ele está falando por toda a organização?

- existem opiniões diferentes sobre funcionalidades ou demandas não resolvidas?

- os envolvidos são conhecedores sobre o domínio em discussão?

analistas não treinados

O papel do analista é capturar as necessidades da organização, do projeto ou do produto, e não se enveredar em ilusões com decisões de soluções. Pessoas não treinadas terão dificuldades em separar necessidades da solução do problema:

analista de banco de dados: “devemos ter uma tabela para armazenamento dos nomes dos clientes e seus endereços” em vez de: “o novo sistema deverá armazenar os nomes e endereço dos clientes”.

programador: “o nome do cliente deve utilizar cache para garantir uma recuperação rápida” em vez de: “o novo sistema deverá ser capaz de recuperar o nome e endereço do cliente em menos de 1 s”.

falha na identificação precisa dos envolvidos

Imagine uma situação com uma reunião com 15 representantes de hospitais, onde um representante sugere uma funcionalidade x e outro representante sugere uma funcionalidade y. Durante a reunião de priorização é determinado que ambas solicitações (x, y) não podem ser atendidas na 1ª versão do sistema de agendamento do hospital.

Infelizmente os nomes e a representatividade de cada solicitante das funcionalidades x, y não foram registradas na reunião:

– funcionalidade x e y oriundas de um representante de uma rede de hospitais com 10.000 e 100 leitos respectivamente.

Dessa forma a informação necessária para a priorização foi perdida.

falha em coletar informações suficientes

É importante coletar a maior quantidade de informações durante as sessões de elicitação de requisitos. Uma forma de fazer isso é garantir a participação de representantes da análise, do projeto e do time de testes, onde poderão endereçar suas necessidades quanto aos requisitos.

Alguns envolvidos ou especialistas no domínio do problema possuem pouca disponibilidade para se reunir com o analista de requisitos. Após a finalização da fase de elicitação pode ser ainda mais difícil endereçar questões abertas com os envolvidos ou especialistas.

volatilidade dos requisitos

Se as necessidades estão mudando rapidamente, definir um conjunto estável de requisitos pode não ser possível. É necessário esperar até se obter algum nivel de estabilidade antes de se finalizar um baseline de requisitos para um produto de software.

entendimento incompleto das necessidades do produto

Ocorre quando os envolvidos estão indecisos quanto as suas necessidades e quanto aos objetivos de seu negócio. Existem várias técnicas, como a prototipagem para ajudar nesse ponto. Criar uma breve especificação do produto também pode ajudar

- é isso que o cliente quer e precisa?

- é factível de construção, com a tecnologia, tempo e orçamento disponível?

- as funcionalidades do produto estão descritas adequadamente?

- está claro porque o cliente iria comprar esse produto de software?

o engenheiro de requisitos tem um profundo conhecimento do dominio

Quando isso ocorre, existe uma tendência de minimizar a comunicação com os envolvidos. A falha na comunicação com os envolvidos pode ser perigosa num domínio onde a tecnologia está mudando rapidamente (telefones celulares, por exemplo)

envolvidos falam idiomas diferentes

Nesse caso a comunicação pode ser ainda mais difícil e os problemas podem aparecerem em diferentes áreas:

- realização de sessões de elicitação sem problemas

- entendimento de necessidades complexas, processos ou algorítmos

- garantir uma boa qualidade na revisão dos requisitos

Dado essas dificuldades, o uso de técnicas visuais como modelos, diagramas e tabelas para a comunicação de conceitos importantes podem ajudar na comunicação.

envolvidos tem visões conflitantes

Quando isso ocorre uma discussão acalorada pode acontecer. O conflito deve ser resolvido fora da sessão de elicitação de requisitos, a menos que gaste um ou dois minutos. Deve-se evitar discussões complexas e longas na sessão de elicitação visando não perder a produtividade.

A elaboração de bons diagramas de caso de uso é sempre um bom início para um projeto de desenvolvimento de software. O Visual Studio 2012 permite a elaboração de diagrama de casos de uso integrados a IDE de desenvolvimento, permitindo assim uma visão integrada do código e dos diagramas de análise e arquitetura do software.

Veja a seguir o passo a passo para a criação de diagramas de caso de uso com o Visual Studio 2012.

1. Execute o Visual Studio. Crie um novo projeto de modelagem selecionando FILE => NEW=>PROJECT para abrir a janela de NOVO PROJETO. Selecione o template MODELING PROJECT, de um nome ao projeto e o local em que será salvo e clique em OK. Um novo projeto é exibido no SOLUTION EXPLORER

2. Clique com o botão direito sobre o nome do projeto no SOLUTION EXPLORER e selecione ADD=>NEW ITEM no menu de contexto.

3. Selecione o template UML USE CASE DIAGRAM e coloque o nome OrderBook.usecasediagram.

Clique no botão ADD para criar esse diagrama. Um diagrama em branco nomeado de OrderBook.usecasediagram é criado no projeto de modelagem e aberto em uma aba no Visual Studio

4. A partir da TOOLBOX do lado esquerdo do Visual Studio, arraste um elemento de SUBSYSTEM BOUNDARY no diagrama de caso de uso.

5. Na janela uc OrderBook no elemento SUBSYSTEM mude o nome para OnlineBookstore. Esse subsistema pode ser usado para representar tanto um sistema quanto os seus principais componentes. Qualquer caso de uso que o sistema suporta é desenhado dentro de um subsistema

6. Adicione atores para o diagrama de caso de uso.

Os atores representam classes de usuários, organizações, e sistemas externos que interagem com o sistema que se está construindo. Por padrão o objeto ator é representado como o ícone de uma pessoa. Coloque dois atores no diagrama de caso de uso, um de cada lado do subsistema OnlineBookstore.

7. Na janela de PROPERTIES nomeie o ator da esquerda de customer e o ator da direita de bookstore.

Obs.: Para adicionar múltiplos objetos do mesmo tipo da Toolbox, de um duplo clique no objeto na Tollbox. Então, clique múltiplas vezes no diagrama para adicionar os objetos. Ao finalizar, pressione ESC para retornar o cursor a sua funcionalidade regular.

8. Quando os atores estão no lugar, coloque os casos de uso apropriados no diagrama. Os casos de uso representam as atividades que os atores podem realizar, e são exibidos como elipses no diagrama. Coloque dois casos de uso dentro do subsistema OnlineBookstore, e os renomeie para Provide Book List e Order Book. Adicione um caso de uso do lado de fora e abaixo do subistema e nomeie ele como Deliver Book. Os casos de uso Provide Book List e Order Book são parte da aplicação OnlineBookstore, então eles são desenhados dentro do subsistema. O caso de uso Deliver Book está fora do escopo da aplicação, então ele é desenhado externamente ao subistema.

9. Finalmente para finalizar, use o objeto ASSOCIATION para mostrar como cada ator se relaciona com cada caso de uso. Uma associação indica que um ator pode participar em um caso de uso particular. Por exemplo o ator Customer pode visualizar uma lista de livro no site da livraria virtual. De um duplo clique no objeto ASSOCIATION no Toolbox para selecioná-lo. Clique e segure o ator Customer e arraste uma linha para o caso de uso Provide Book List. Uma associação é criada entre o ator e o caso de uso. Faça o mesmo para os casos de uso Order Book e Deliver Book. Crie associações da mesma forma entre o ator Bookstore e os casos de uso Provide Book List e Deliver Book.

Embora esse seja um diagrama de caso de uso muito simples, ele é muito informativo. Você pode ter diagramas de caso de uso mais complexos, com múltiplos subsistemas, atores e casos de uso. Uma boa prática é começar descrever o sistema com os seus principais diagramas de caos de uso. Cada um desses diagramas devem definir um objetivo principal do sistema. Após esses objetivos terem sido definidos, você inicia um detalhamento dos casos de uso utilizando outros objetos disponíveis na toolbox de diagrama de casos de uso.

Vamos então detalhar o caso de uso Order Book. A figura abaixo mostra um diagrama de caso de uso que faz isso usando o relacionamento de INCLUDE

Esse relacionamento mostra que um caso de uso usa todo o comportamento do caso de uso incluído. Para diferenciá-lo de uma associação regular, o relacionamento INCLUDE é representado por uma linha pontilhada com uma seta no final (segundo a especificação da UML 2.1.2, a seta deve sempre aponta para o caso de uso mais detalhado. O relacionamento include é também rotulado com a palavra-chave <<include>>. Cada um dos casos de uso incluídos é um passo que o ator deve realizar para completar o caso de uso principal. Nesse exemplo, para que o cliente efetue o pedido de um livro na livraria virtual, o cliente deve escolher um livro e então efetuar o pagamento do livro.

Um diagrama de caso de uso não especifica em que ordem um caso de uso particular deve ocorrer, ou quando um caso de uso em particular é necessário. Para ter essa informação de forma mais clara, anexe um objeto ARTIFACT para o caso de uso principal, arrastando o objeto ARTIFACT para o diagrama de caso de uso e então estabeleça um relacionamento de dependência entre o objeto ARTIFACT e o caso de uso principal. Um objeto ARTIFACT permite anexar um documento separado ao caso de uso (por exemplo, um arquivo texto que descreva os passos necessários) ou referenciar outro diagrama.

Toolbox do diagrama de caso de uso

A figura abaixo mostra os diferentes elementos e associações disponíveis para o diagrama de casos de uso

A tabela abaixo descreve os diferentes elementos e associações

* adaptado do livro Professional Application Lifecycle Management with Visual Studio 2012. Mickey Gousset, Brian Keller, Martin Woodward