Engenharia de Software - Edição 66.pdf

Rodrigo Oliveira Spínola [email protected] Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ.Realizou seu Pós-Doutorado na University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos.Atualmente é Professor Titular do Programa de Pós-Graduação em Sistemas e Computação da Universidade Salvador - UNIFACS.

Marco Antônio Pereira Araújo [email protected]  Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF.

66 ª Edição Edição - 2014

Corpo Editorial Editor Rodrigo Oliveira Spínola

Eduardo Oliveira Spínola

Colaboradores Marco Antônio Pereira Araújo Eduardo Oliveira Spínola Nicolli Souza Rios

[email protected] É Colaborador das revistas Engenharia de Software Magazine, Magazine, Java Magazine e SQL Magazine. É bacharel em Ciência da Computação pela Universidade Salvador (UNIFACS). (UNIFACS).

Consultor Técnico Daniella Costa

Nicolli Souza Rios [email protected]

Jornalista Responsável Kaline Dolabella - JP24185

Formanda em Ciência da Computação na Universidade Salvador (UNIFACS),Gerente (UNIFACS),Gerente de Projetos da COMMIT–EmpresaJúniordeComputaçãoda UNIFACSeEstagiáriadeDesenvolvimentodeSoftware na BAHIAGÁS.Faz parte do grupo de pesquisa em Engenharia de Software do Programa de PósGraduação em Sistemas e Computação da UNIFA UNIFACS. CS.

Na Web http://www.devmedia.com.br/revista-engenharia-de-software-magazine

Atendimento ao Leitor A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se você tiver algum problema no recebimento do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de  jornal, entre outros, entre em contato com: www.devmedia.com.br/central (21) 3382-5038

Publicidade Para informações sobre veiculação de anúncio na revista ou no site entre em contato com:  publicidade@de  publici dade@devmedia. vmedia.com.br  com.br 

Fale com o Editor! É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugestão! Se você estiver interessado em publicar um artigo na revista ou no site ES Magazine, entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria de publicar.

Conteúdo sobre Agilidade, Artigo no estilo Prático

06 – Desenvolvimento Ágil: análise sobre requisitos tradicionais [ Mauricio M. O. Matos, Nicolli Souza Rios Alves e Rodrigo Oliveira Spínola ]

Sumário

Conteúdo sobre Agilidade

14 – Scrum backlog: requisitos não funcionais [ Sérgio Salles Galvão Neto ]

Artigo no estilo Prático

23 – IFPUG SNAP: medindo requisitos não funcionais [ Thiago Chierici Cunha ]

Conteúdo sobre Boas práticas, Artigo no estilo Curso

29 – Use Case Point : estimativas de projeto – Parte 1 [ Anderson Pinheiro Balbo, Wilson Vendramel e Maria Beatriz Felgar de Toledo ]

Conteúdo sobre Boas práticas, Artigo no estilo Curso

40 – Desvendando o Gerenciamento de Projetos – Parte 3 [ Ary dos Santos Rocha Júnior ]   u

  e    s      ê

Conteúdo sobre Engenharia, Conteúdo sobre Boas Práticas

   F eedb ac   k  

     D

o     

s      

44 – Trabalhando com Engenharia de Requisitos [ Elaine G.M de Figueiredo ]

Conteúdo sobre Engenharia, Artigo no estilo Mentoring

49 – Especificando casos de uso eficazes [ Rodrigo Oliveira Spínola ]

Conteúdo sobre Boas práticas

52 – Gestão de Regras de Negócios [ Marco Ikuro Hisatomi, Anderson de Souza Góes e Rodolfo Mirando de Barros ]

 b    r     e   e   s   t    a

    e

  i   d    ç       o     ã

Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! www.devmedia.com.br/esmag/feedback 

Edição 05 - Engenharia de Software Magazine

5

Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Desenvolvimento Ágil: análise sobre requisitos tradicionais Entenda os benefícios e dificuldades das abordagens tradicionais e ágeis Fique por dentro: 

Mauricio M. O. Matos [email protected]

Formado em Ciência da Computação pela Universidade Salvador - UNIFACS. Já atuou na área de Testes/Qualidade e atualmente exerce a função de Analista de Requisitos na Softwell Solutions

Nicolli Souza Rios Alves [email protected]

Bacharel em Ciência da Computação na Universidade Salvador (UNIFACS), Mestranda em Sistemas e Computação no Programa de Pós-Graduação em Sistemas e Computação da UNIFACS na linha de Engenharia de Software. É editora da Engenharia de Software Magazine.

Rodrigo Oliveira Spínola [email protected]

Editor Chefe – Engenharia de Software Magazine

6

A

especificação de requisitos pode ser, em muitos casos, um problema complexo, principalmente quando o analista de requisitos não tem domínio sobre o negócio do cliente. Compreender a natureza do problema pode ser muito difícil, especialmente se o sistema for novo. Em decorrência disso, surgiu a engenharia de requisitos que pode ser definida como o termo usado para descrever as atividades relacionadas à produção e gerência de requisitos. Este artigo abordará, sob diferentes perspectivas e metodologias, as atividades do processo de produção dos requisitos com foco em especificação de requisitos. Os requisitos funcionais de um sistema descrevem as funcionalidades ou os serviços que se espera do sistema. Para registrar estes requisitos, são utilizados diferentes tipos de abordagens, sendo a

Engenharia de Software Magazine - Desenvolvimento Ágil: análise sobre requisitos tradicionais

A especificação dos requisitos é uma etapa crucial no processo de criação de um soft ware. Diferentes abordagens surgiram com o objetivo de realizar esta etapa, porém, o diferencial está nos princípios que cada uma aplica em seus processos. Este artigo apresenta a realização de um estudo de caso com objetivo de investigar na prática as vantagens e desvantagens da especificação de requisitos entre as metodologias ágeis e tradicionais. O estudo foi iniciado a partir da elaboração de dois tipos de documento de requisitos de software, um proveniente da metodologia de especificação ágil e o outro da tradicional. Os requisitos definidos estão no contexto de um sistema escolar hipotético, um cadastro de usuários e uma emissão de relatório de usuários.

tradicional realizada a partir de casos de uso, e a ágil que utiliza estórias de usuários como documento de requisitos. Tais abordagens diferem em certos aspectos na especificação. A análise destas diferenças é importante para saber quando cada abordagem é a mais indicada para solucionar o problema do cliente.

AGILIDADE

Neste artigo, serão investigadas as vantagens e desvantagens de se trabalhar com ambas as metodologias de especificação de requisitos, na perspectiva do analista de requisitos e do desenvolvedor. Para realizar esta avaliação, um estudo de caso foi planejado e foram elaboradas dois tipos de documentação: uma considerando a metodologia ágil e outra a tradicional. Após isto, estas documentações foram entregues a quat ro desenvolvedores para realizarem suas f unções e, ao fim, responderem um questionário a respeito das dificuldades e benefícios encontrados no uso de cada tipo de especificação.

Como é de característica dos MAs, o Manifesto Ágil tem um enfoque muito maior em interação com o c liente do que com o cumprimento metódico de processos. Partindo deste princípio, passaram a valorizar: Indivíduos e interações mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano.

Metodologias de especificação de requisitos

MAs têm foco na interatividade dos envolvidos e em respostas rápidas como forma de atender os requisitos do usuário. A abordagem de requisitos em MAs pode permitir bons resultados a partir de sua combinação com aspectos favoráveis do contexto. Entretanto, isto pode requerer, por exemplo, que a ER seja adaptada principalmente devido ao fato de que essas metodologias abdicam, em parte, de documentos e controle de artefatos muito presentes neste processo. Produzir, manter e rastrear documentação de requisitos exige um esforço que na visão ágil pode comprometer a entrega do software funcionando. MA precisa de processos rápidos, definidos, que sejam curtos, quando se tratando da documentação gerada não é diferente. Esta deve conter o necessário para guia r o tema da discussão entre o desenvolvedor e o cliente, de onde sairá todos os detalhes necessários para a implementação do requisito. User Stories é um dos modelos de especificação de requisitos indicados para MAs. Uma User Story (US) descreve uma funcionalidade que é valiosa para o cliente ou usuário do sistema. Este modelo de especificação é composto pelas seguintes características: A descrição da estória é usada para servir de planejamento e lembrete, como demonstrado na Figura 2; É necessário discutir sobre a estória para se esclarecer quaisquer detalhes; Testes e anotações são inseridos na estória para que aux iliem no desenvolvimento de regras e detalhes que a funcionalidade deve possuir. A estória estará concluída a partir do momento que o sistema passar por todos os testes e contenha as anotações.

Um processo de engenharia de requisitos é um conjunto estruturado de atividades a serem seguidas para criar, validar e manter um documento de requisitos [2]. O processo de produção do documento de requisitos é constituído pelas atividades de levantamento de requisitos, registro, validação e verificação como é demonstrado na Figura 1.

Figura 1. Engenharia de Requisitos [2]

• •

•

•

•

Este processo foi evoluindo utilizando-se as boas práticas de engenharia de requisitos. Porém, fatores como a rápida evolução tecnológica, pressão para o sistema entrar no mercado e mudanças cada vez mais frequentes no ambiente de negócio do cliente estão desafiando as abordagens da ER. Os métodos ágeis surgiram com o objetivo de suprir estas necessidades, onde o objetivo principal da abordagem é garantir a entrega do sistema em um menor prazo, com maior qualidade e satisfazendo as necessidades do cliente.

•

•

Metodologia ágil As exigências do mercado mudaram e com isso, a engenharia de requisitos teve que se adequar a elas. Os métodos ágeis (MAs) alteraram o processo da ER tradicional e o adaptou para seus interesses. Tradicionalmente, ER é fortemente baseada em documentação para compartilhar conhecimento, enquanto que MAs são focados em colaboração face a face entre desenvolvedores e clientes para garantir objetivos similares. Para estabelecer um modelo de boas práticas, um grupo de profissionais especialistas na área criou um padrão para as metodologias ágeis, chamado “Manifesto Ágil”, em que centralizaram princípios baseados em diversos métodos existentes.

Figura 2. Um exemplo de descrição de uma User Story

Para se criar uma boa US é necessário que esta seja caracterizada por seis atributos: • Independente; • Negociável; • Valiosa para o cliente ou usuário; Edição 66 - Engenharia de Software Magazine

7

• Estimável; • Pequena; • Testável. Dependências entre US podem causar transtornos no momento do desenvolvimento do sistema. Por exemplo, o cliente definiu que uma US é prioridade máxima, mas para iniciá-la é necessário terminar outra de prioridade inferior. As USs precisam ser negociáveis, uma vez que elas são apenas lembretes da funcionalidade desejada pelo cliente/usuário. Caso haja alguma observação muito importante que deverá ser lembrada no momento da codificação, o cliente/usuário poderá adicionar notas à US. Sempre tomando cuidado para não exagerar nos detalhes, em muitos casos, especifica r detalhes muito cedo só cria mais trabalho. A Figura 3 mostra um exemplo de US com anotação.

Figura 3. Um exemplo de anotação em uma User Story

Uma boa prática é deixar que o cliente/usuário escreva as estórias, podendo ter um aux ílio do desenvolvedor para isso. Assim, as USs sempre serão de valor para os i nteressados. É importante também que as USs sejam estimáveis. Para isso, é necessário que o desenvolvedor possua os conhecimentos técnicos, do negócio e que as USs possuam tamanhos ideais (estórias muito grandes são difíceis de estimar). Uma US não pode ser muito grande, pois não é possível elaborar um planejamento concreto baseando-se nela. Nestes casos, é necessário desagregá-las em USs menores e consistentes. Por fim, uma US precisa ser testável. Os testes servem para o desenvolvedor saber quando a implementação da estória foi concluída. Se ela passar em todos os seus testes, significa q ue foi desenvolvida com sucesso. Os testes podem ser escritos no verso do cartão como demonstrado na Figura 4.

atividades que necessitam ser cumpridas com certa ordem para que o processo como um todo funcione. Alguns dos principais objetivos da ER são: • Estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software; • Registrar e acompanhar requisitos ao longo de todo o pro cesso de desenvolvimento; • Documentar e controlar os requisitos alocados para esta  belecer uma baseline para uso gerencial e da Engenharia de Software; • Manter planos, artefatos e atividades de software consisten tes com os requisitos alocados. A especificação de requisitos comumente utilizada nesta metodologia são os Casos de Uso (UC do inglês “Use Case”). Um UC é uma sequência de interações entre o ator, alguém ou algo que interage com o sistema, e este, que acontece de forma atômica na perspectiva do ator. Por ser um documento que será entregue e validado pelo cliente, que nem sempre é da área de TI, um UC é descrito de forma que o cliente entenda a funcionalidade do sistema sem necessidade de explicar tecnicamente como ocorre à operação. Na Tabela 1 tem-se um conjunto de definições que são importantes em um caso de uso.

Estudo de Caso Esse estudo tem como objetivo analisar as metodologias de especificação de requisitos ágil e tradicional, com o propósito de definir as vantagens e desvantagens de cada abordagem, com respeito à aplicação destes conceitos no desenvolvimento de software, do ponto de vista de quatro desenvolvedores e um analista de requisitos n o contexto da elaboração da documentação e desenvolvimento das funcionalidades a partir das documentações fornecidas, específicas de cada abordagem. Além disso, para este estudo de caso foram elaborados alguns instrumentos definidos no cenário de um sistema de informação. Para isso, foram considerados dois requisitos: um de cadastro básico de usuário e outro de emissão de relatórios. Para cada um dos requisitos, foram definidos os casos de uso e estórias do usuário correspondentes: Caso de Uso do cadastro de usuários (ver Tabela 2): Este caso de uso define como as operações de inclusão, alteração, exclusão e consulta de usuários são efetuadas no sistema. Note que para isso temos um fluxo principal representando a operação de consulta. Em complemento, foram definidos seis fluxos alternativos para funcionalidades auxiliares, como cancelamento de uma operação e outros para as funcionalidades de inclusão, alteração e exclusão de usuários. Além disso, foram definidas três regras de negócio. Observe também que cada fluxo alternativo foi definido no momento em que ele pode ser utilizado durante a interação do ator com o sistema. De forma semelhante, as referências às regras de negócio foram definidas. Por fim, foi defin ido também •

Figura 4. Verso de um cartão, demonstrando os testes da US

Metodologia tradicional Ao contrário da metodologia ágil de ER, a tradicionalmente aplicada permite um controle maior do andamento do projeto, produzindo documentações gerenciais e de especificação muito mais detalhadas e consistentes. Além de uma série de

8

Engenharia de Software Magazine - Desenvolvimento Ágil: análise sobre requisitos tradicionais

AGILIDADE

Objetivo:

Contém uma breve descrição do objetivo do caso de uso.

Requisitos:

Neste campo indicamos a qual requisito funcional o caso de uso em questão está associado.

Atores:

Neste campo definimos a lista de atores associados ao caso de uso. Ator é qualquer entidade externa que interage com o sistema (neste caso, com o caso de uso em questão).

Prioridade:

Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software.

Pré-condições:

Neste campo devemos informar as condições que devem ser atendidas para que o caso de uso possa ser executado.

Frequência de uso: Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software. Criticalidade:

Informação identificada junto ao usuário que auxilia na definição dos casos de uso que serão contemplados em cada iteração do desenvolvimento do software.

Condição de Entrada:

Neste campo definimos qual ação do ator dará início à interação com o caso de uso em questão.

Fluxo Principal:

Esta é uma das seções principais do caso de uso.É onde descrevemos os passos entre o ator e o sistema.O fluxo principal é o cenário que mais acontece no caso de uso e/ou o mais importante.

Fluxo Alternativo:

Fluxo alternativo é o caminho alternativo tomado pelo caso de uso a partir do fluxo principal, ou seja, dada uma condição de negócio o caso de uso seguirá por outro cenário que não o principal caso essa condição seja verdadeira.

Extensões:

Nesta seção colocamos todos os casos de uso que estendem o caso de uso base e em quais pontos eles são chamados dentro dos fluxos de eventos.

Pós-condições:

Neste campo devemos informar o estado em que o sistema (ou entidade manipulada no caso de uso) estará depois que o caso de uso for executado.

Regras de negócio: Nesta seção descrevemos todas as regras funcionais que o caso de uso deve cumprir durante sua execução. Tabela 1. Definições importantes de um Caso de Uso

Objetivo Requisitos Atores Prioridade Pré-condições Frequência de uso Criticidade Condição de entrada

Permitir a inclusão, alteração, exclusão e consulta de usuários. O software deve permitir o gerenciamento de usuários. Professor-Administrador Professor Aluno Alta Não se aplica Eventual Média O ator seleciona a opção de gerenciar usuários. 1. O sistema apresenta o formulário no registro do usuário logado 2. O ator consulta os dados no formulário, que contém as seguintes informações e funcionalidades: • #Nome (Campo texto. Indica o nome do usuário do sistema) • #Login (Campo texto. Indica o Login para acesso ao sistema) • #Senha (Campo texto, com máscara de senha. Indica a senha de acesso ao sistema) • #Administrador? (Campo texto com domínio fechado, possíveis valores: Sim; Não. Indica se o usuário será administrador do sistema.) [RN3] • #Perfil (Campo texto com domínio fechado, possíveis valores: Professor; Aluno.Indica o perfil do usuário, será parâmetro para acesso à outras funcionalidades do sistema)

Fluxo principal

• E-mail (Campo texto. Indica o e-mail do usuário) • Telefone (Campo numérico, com máscara de telefone. Indica o telefone do usuário) • Opção de inserir um novo usuário [FA1] [RN1] • Opção de alterar um usuário [FA2] [FA3] [RN2] • Opção de excluir um usuário [FA4] [RN1] • Opção de cancelar ação [FA5] • Opção de buscar usuário [FA6] • Opção de emitir o relatório de usuários [E1] 3. O caso de uso é encerrado.

[FA1] O ator seleciona a opção de inserir 1. O sistema altera o modo do formulário para inclusão, apresentando os seguintes campos a serem preenchidos: • Nome • Login

Fluxo alternativo

• Senha • Administrador? (Valor padrão: Não) • Perfil ( Valor padrão: Aluno) • E-mail • Telefone

Tabela 2. Caso de uso de cadastro de usuários

Edição 66 - Engenharia de Software Magazine

9

um fluxo de exceção que trata o preenchimento incorreto de campos durante o cadastro do usuário. Ainda no contexto deste caso de uso, vale observar que ao final de cada fluxo é definido explicitamente para qual passo da funcionalidade o sistema será direcionado (por exemplo: o caso de uso é encerrado ou o sistema retorna ao passo X do fluxo principal).

• Caso de Uso do relatório de usuários (ver Tabela 3): Este caso de uso, mais simples que o definido na Tabela 2 , descreve como a consulta e geração do relatório são efetuadas. Observe que basicamente temos uma tela de consulta seguida do relatório gerado a partir das informações consultadas.

2. O ator preenche os campos disponibili zados 3. O ator seleciona a opção salvar [FE1] 4. O sistema retorna ao passo 2 do fluxo prin cipal.

[FA2] O ator seleciona a opção de alterar seu registro 1. O sistema altera o modo do formulário para alteração, habilitando apenas os seguintes campos para edição: • Nome • Login • Senha • E-mail • Telefone

2. O ator altera os campos desejados 3. O ator seleciona a opção salvar [FE1] 4. O sistema retorna ao passo 1 do fluxo prin cipal. [FA3] O ator seleciona a opção de alterar registro de outro usuário

1. O sistema altera o modo do formulário para alteração, habilitando os seguintes campos para edição: • Senha • Administrador? • Perfil

Fluxo alternativo

2. O ator altera os campos desejados 3. O ator seleciona a opção salvar [FE1] 4. O sistema retorna ao passo 2 do fluxo prin cipal. [FA4] O ator seleciona a opção de excluir um registro

1. O sistema solicita a confirmação da exclusão com as opções de confirmar e cancelar 2. O ator confirma a exclusão 3. O registro é removido e o sistema retorna ao passo 2 do fluxo principal. [FA5] O ator seleciona a opção de cancelar a ação

1. O sistema solicita a confirmação do cancelamento com as opções de confirmar e cancelar 2. O ator confirma o cancelamento da ação 3. O sistema fecha o formulário e o caso de uso é encerrado.

[FA6] O ator seleciona a opção de buscar usuários 1. O sistema exibe os seguintes campos para busca • Nome • Login • Administrador?

2. O ator executa a função de busca 3. O sistema exibe a relação de usuários de acordo com os filtros definidos 4. O ator seleciona o usuário desejado 5. O sistema retorna ao passo 2 do fluxo prin cipal.

[FE1] Campos obrigatórios não preenchidos

Fluxo de exceção

1. O sistema emite uma mensagem de erro informando qual campo obrigatório não foi preenchido;

Extensões Pós-condições

2. O sistema retorna ao passo onde este fluxo de exceção foi chamado. [E1] Caso de uso “UC02 - Emitir Relatório de Usuários”. Será realizada a manutenção dos usuários. [RN1] Apenas os professores que forem administradores terão permissão para realizar esta ação.

Regras de negócio

[RN2] Os professores administradores poderão alterar seus próprios regi stros por inteiro, de outros usuários apenas os campos: “Senha”,“Perfi l” e“Administrador?”. Quem não

for administrador, poderá editar o seu registro parcialmente, apenas os campos: “Nome”,“Login”,“E-mail” e “Telefone”. [RN3] Apenas professores poderão ser administradores.

Continuação: Tabela 2. Caso de uso de cadastro de usuários

10

Engenharia de Software Magazine - Desenvolvimento Ágil: análise sobre requisitos tradicionais

AGILIDADE

Objetivo

Permitir que os administradores emitam uma relação dos usuários cadastrados

Requisitos

O software deve permitir a emissão do relatório de usuários

Atores

Professor-Administrador

Prioridade

Média

Pré-condições

Não se aplica

Frequência de uso

Eventual

Criticidade

Média

Condição de entrada

O ator seleciona a opção de emitir relatório de usuários 1. O sistema apresenta os seguintes campos para filtro do relatório de usuários: • Perfil (Campo texto com domínio fechado, possíveis valores: Aluno; Professor) • Administrador? (Campo texto com domínio fechado, possíveis valores: Sim; Não)

 2. O ator executa a funcionalidade de emitir o relatório [FA1] [FE1] 3. O sistema exibe o relatório de usuários de acordo com os filtros definidos. De cada usuário serão exibidas as seguintes informações:

Fluxo principal

• Nome • Login • Administrador? • Perfil • E-mail • Telefone 4. O caso de uso é encerrado.

[FA1] O ator executa a funcionalidade de emitir o relatório sem preencher os filtros 1. O sistema exibe o relatório de usuários com todos os usuários cadastrados. De cada usuário serão exibidas as seguintes informações: • Nome • Login

Fluxo alternativo

• Administrador? • Perfil • E-mail • Telefone

Fluxo de exceção

2. O caso de uso é encerrado [FE1] O ator executa a funcionalidade de emitir o relatório, mas não há usuários a serem retornados de acordo com os filtros 1. O sistema emite uma mensagem de erro informando que a consulta não retornou usuários 2. O sistema retorna ao passo 1 do fluxo principal

Extensões

Não se aplica

Pós-condições

Será exibido o relatório de usuários

Regras de negócio

Não se aplica

Tabela 3. Caso de uso de relatório de usuários

• User Story do cadastro de usuários (ver Tabelas 4 e 5): De forma semelhante ao que foi representado na  Tabela 2 , essa US representa a funcional idade de cadastro de usuário. Oberve que ela é bastante simples em termos de in formações descritas. Por outro lado, também são definidas algumas informações que objetivam orientar a execução dos testes para a funcionalidade (informação não presente diretamente na especificação do caso de uso). Note que a US apresenta apenas uma visão geral das funcionalidades. Sendo assim, seus detalhes devem ser identificados apenas à medida que as funcionalidades sejam desenvolvidas. Isso tende a causar uma necessidade de maior aproximação entre a equipe de desenvolvimento e o cliente.

O sistema deve permitir a consulta, inclusão, exclusão e alteração de um usuár io. • Apenas o administrador poderá incluir e excluir um usuário

Notas

• Apenas o administrador poderá alterar registros além do seu. • Definir as permissões de acesso aos campos e registros

Tabela 4. User story cadastro de usuário – Frente do Cartão Testar inserção, alteração e exclusão de usuários; Testar como um aluno, a inclusão de um novo usuário;

Testar como um administrador, a alteração do próprio registro e o de outros usuários (acessibilidade aos campos). Testar inclusão ou alteração sem preencher um ou mais campos obrigatórios. Tabela 5. User story cadastro de usuário – Fundo do Cartão

Edição 66 - Engenharia de Software Magazine

11

User Story do relatório de usuários (ver Tabelas 6 e 7): De forma semelhante, pode-se obervar que a descrição da user story do relatório de usuários é bastante simples: definimos apenas as funcionalidades que estarão presentes, maiores detalhes sobre cada uma delas são definidos apenas no momento de sua implementação. •

O sistema deve permitir a emissão do relatório de usuários Notas

• Apenas o professor administrador poderá emitir os relatórios • Os relatórios poderão ser filtrados pelos campos perfil e administrador

Tabela 6. User story relatório de usuários – Frente do Cartão Testar emitir o relatório sem definir fil tros; Testar como um aluno, emitir o relatório;

Testar emitir o relatório quando não h ouverem registros a serem retornados. Tabela 7. User story relatório de usuários – Fundo do Cartão

Para realização da comparação das duas abordagens considerando o estudo de caso desenvolvido, foram definidos dois questionários: • Questionário sobre cada abordagem: os participantes apresen tam as dificuldades de entendimento do documento e sobre a quantidade de informação/detalhe contidos no documento. • Questionário comparativo das abordagens: são inform adas as vantagens e desvantagens encontradas na abordagem tradicional utilizando casos de uso e na abordagem ágil utilizando user story. Sobre a escolha dos participantes, um analista de requisitos será selecionado para especificá-los e produzir as documentações. Outros quatro desenvolvedores serão escolhidos para apresentar seus pareceres referentes à documentação proveniente das duas abordagens.

Analisando os resultados Executado o estudo de caso planejado, identificou-se que o esforço para elaboração dos artefatos foi proporcional aos seus tamanhos. As USs, por serem pequenas e possuírem poucos detalhes, apresentaram pouca dif iculdade. Em contrapartida, os UCs necessitaram de esforço consideráveis por possuírem diversas regras de implementação e detalhes dos requisitos. A partir das entrevistas com os desenvolvedores, foi possível tirar algumas conclusões a respeito dos diferentes modelos de documento de requisitos. Em relação as USs, nenhum desenvolvedor expressou alguma dificuldade de entendimento da documentação. A falta de informação os preocupou inicialmente, mas após a conversação, todas as dúvidas foram esclarecidas. O desenvolvedor 4 pontuou “O documento pode ser facilmente entendido, porém não há maiores detalha mentos e precisa ser discutido...”. Tendo esta deficiência de informações, os desenvolvedores responderam que é possível desenvolver as funcionalidades parcialmente. O desenvolver 3 pontuou “... há a necessidade de entrevistar o cliente para obter informações complementares”.

12

Ao longo das entrevistas ficou claro que a dependência maior do cliente é na util ização de US como documento de requisitos. Os desenvolvedores solicitaram inúmeras vezes esclarecimento das regras de negócio, restrições de acesso e campos. Já no UC eles encontram todas as respostas no próprio documento. Ao se tratar de Casos de Uso, os desenvolvedores, por unanimidade, ficaram satisfeitos com a quantidade de informações e detalhes das funcionalidades e responderam no questionário que é possível desenvolver as funcionalidades apenas com as informações do UC. Por ser um documento maior e detalhado, o UC gerou algumas poucas dúvidas de entendimento como sinalizado pelo desenvolvedor 2: “Alguns símbolos específicos do documento podem gerar dúvidas.”, porém, a aceitação geral foi positiva. Os desenvolvedores 1 e 3 salientaram que há um risco para o projeto caso a discussão sobre a US seja entre o desenvolvedor e o cliente, visto que nem s empre o desenvolvedor é o profissional mais indicado para a função. O desenvolvedor 1 afirmou “... o desenvolvedor muitas vezes possui dificuldades até mesmo de comunicação e relação interpessoal.”, o que aumenta os riscos de fracasso do projeto. Por ser um documento detalhado, o desenvolvedor 1 afirma que o UC “Aumenta a produtividade na etapa do desenvolvimento...”. Outro fator importante mencionado pelo desenvolvedor 4 foi a questão da validação do doc umento feita pelo cliente indicando que há um “Respaldo e segurança sobre o que foi discutido.”. As vantagens encontradas na metodologia ágil em relação a tradicional foram:  Menor custo e tempo na elaboração de documentos; • Foco no desenvolvimento; • Contato direto com o cliente para solucionar dúvidas. •

As vantagens encontradas na metodologia tradicional em relação a ágil foram: • Documento detalhado de linguagem comum entre usuário e desenvolvedor, o que facilita aceites e evitar futuras inconformidades entre o que foi desenvolvido e o que foi pedido; • Documento completo e detalhado, suficiente para im plementação da funcionalidade; • Documentação elaborada por analista de requisitos o que diminui a possibilidade de erros do levantamento de requisitos. A partir do estudo de caso realizado foi possível observar que a metodologia ágil de especificação de requisitos de fato otimiza o tempo gasto com documentação quando comparado à metodologia tradicional. O papel do analista de requisitos foi citado como essencial mesmo na abordagem ágil, a função de especificação na entrevista fica clara e para isto é importante que seja o profissional indicado para a fu nção.

Engenharia de Software Magazine - Desenvolvimento Ágil: análise sobre requisitos tradicionais

AGILIDADE

Foi também constatado que há a necessidade de haver o contato direto entre o detentor do negócio, cliente ou analista de requisitos, e o desenvolvedor, pois não há como desenvolver as funcionalidades por completo baseando-se apenas nos US. Tendo isto em vista, é aconselhável utilizar esta abordagem quando há uma disponibilidade plena do cliente para transmitir as informações. Apesar de envolver mais processos para chegar à sua versão final e demandar um tempo maior para ser implementada, a documentação tradicional a partir de Casos de Uso foi considerada a mais completa pelos desenvolvedores. O UC é um documento de linguagem comum entre usuário e desenvolvedor, deste modo, é possível garantir que certas funcionalidades foram verificadas e validadas pelo cliente. Mesmo podendo gerar algumas dúvidas na documentação, com seu nível de detalhamento, é possível entender por completo o que a funcionalidade deverá fazer e assim implementá-la sem dificuldades. Concluindo, a abordagem ágil, de fato, se mostrou mais eficiente em relação ao tempo de elaboração, e mais suscetível

a negociações. Já a abordagem tradicional exigiu mais tempo para ser executada, porém sua documentaç ão é mais completa e rica em detalhes, o que praticamente extinguiu a necessidade do cliente estar à disposição para elucidar possíveis dúvidas. Referências: 1. Beck, K.; Beedle, M.; Van, A.; Bennekum; Cockburn, A.; Cunningham, W.; Fowler, M.; James; Genning; Highsmith, J.; Hunt, A.; Jeffries, R.; Kern, J.; Marik, B.; Martin, R. C.; Mellor, S.; Schwaber, K.; Sutherland, J.; Thomas, D. (2001) Manifesto para Desenvolvimento Ágil de Software. http://agilemanifesto.org/iso/ptbr, Novembro

2. d’Amorim, F. R. S. (2008), Engenharia de Requisitos para Métodos Ágeis.

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Edição 66 - Engenharia de Software Magazine

13

Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

Scrum backlog: requisitos não funcionais Criando um ambiente favorável para gerenciar melhor o Backlog

Fique por dentro: 

A

Sérgio Salles Galvão Neto  [email protected]

Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras. Atuando na área de informática desde 1992 e, a mais de 10 anos liderando equipes em projetos de desenvolvimento e implantação de softwares. Nos últimos cinco anos, atuando como Scrum Master em projetos em diversas tecnologias e ramos de negócio.

14

produção de software através de modelos ágeis de desenvolvimento, como o Scrum, é popularmente adotada por empresas e equipes de diversos tamanhos e seguimentos. Porém, existem alguns pontos que merecem uma atenção por se tratarem de peças fundamentais no desenvolvimento de um software: os requisitos não funcionais. Estes podem levar o software do sucesso ao fracasso. A equipe de desenvolvimento também precisa possuir um ambiente favorável para lidar com tudo isso e, por vezes, pode não ter notado o que seria necessário para poder alcançar um ambiente mais produtivo e seguro. Veja os números apresentados na Figura 1 publicados no último relatório gerado pelo Standish Group em Março/2013. Este gráfico demonstra o percentual de falha, mudanças e sucesso nos projetos de desenvolvimento de software.

Engenharia de Software Magazine - Scrum backlog: requisitos não funcionais

Requisitos não funcionais nem sempre são abordados de forma clara durante a adoção ou uso das metodologias ágeis, como o Scrum. Este artigo sugere uma forma mais ampla de enxergar o tratamento destes requisitos, também considerados fatores críticos de sucesso das aplicações. Este artigo procura abordar os riscos envolvidos em não se cuidar devidamente dos requisitos não funcionais do software e de como o time Scrum deve estar estruturado para tratar ou evitar “surpresas” as quais podem levar qualquer produto ao fracasso.

Podemos perceber que houve uma sensível melhora, desde a 1ª aferição em 1994 até a última em 2012 onde, de apenas 16% de sucesso nos projetos, alcançouse os 39%. Isso significa uma melhoria de quase 100%. mas considerar que de todos os projetos, apenas 39% destes são entregues conforme o planejado, tornase um fator preocupante. Em complemento, a Tabela 1 apresenta os fatores considerados críticos para o sucesso dos projetos. De acordo com os dados deste relatório, podemos destacar os seguintes pontos:

AGILIDADE

• A conscientização, por parte das empresas, sobre a impor tância da TI como peça fundamental no sucesso. Isso fez com que a maior parte das empresas colocassem seus executivos (os patrocinadores dos projetos) à frente para auxiliar a TI, oferecendo maior suporte e acompanhamento; • Em decorrência desta conscientização gerou-se um maior envolvimento dos usuários, promovendo otimização das aplicações em pequenos projetos, com investimentos em conhecimento, aumentando o capital intelectual das equipes, seguido por uma melhor visão e entendimento mais sólido sobre gerenciamento de projetos e a adoção de Processos Ágeis. Chaos Manifesto 2013 - The Standish Group Failed

16

26

27

53

28

Challenged

34

49 51

1994

35

32

37

39

42

43

33 46

31

29

Successful

53

46

44

40 28

1996

23

1998

2000

15 2002

18

19

24

21

18

2004

2006

2008

2010

2012

Figura 1. Percentual de Falhas, Mudanças e Sucesso em projetos de TI

Fatores de sucesso

Pontos

Suporte da Gestão Executiva

20

Envolvimento dos Usuários

15

Otimização

15

Recursos Especializados

13

Experiência em Gestão de Projetos

12

Processos Ágeis

10

Objetivos Comerciais Claros

6

Maturidade Emocional

5

Execução

3

Ferramentas e Infraestrutura

1

Tabela 1. Fatores de Sucesso dos Projetos de TI

Observe que muitos desses fatores estão alinhados com as práticas ágeis de desenvolvimento.

A importância e os desafios na adoção das metodologias Ágeis É possível verificar a importâ ncia do entendimento e adoção das metodologias ágeis para garantir o sucesso nos projetos de desenvolvimento de software. Nelas o foco está em “entregar software funcionando”. Seguindo esta linha, imaginemos uma aplicação produzida com o Scrum ou outra metodologia ágil. Este software encontra-se em produção e em uso por usuários e num dado momento surgem questões como:

O relatório “X” está muito lento e está atrapalhando os usuários; O sistema “cai” quando atinge 1.000 usuários simultâneos; O sistema ficou 24 horas “fora do ar” devido a não possuir ou não terem funcionado as devidas contingências; •

• •

Esta lista de questões são puramente requisitos não funcionais não observados e/ou não atendidos. Em praticamente toda a literatura associada ao uso do Scrum, existe um assunto que não é claramente tratado mesmo sendo de extrema importância: os requisitos não funcionais. Na estrutura de trabalho do Scrum, temos os papeis bem definidos: Product Owner, Scrum Master e a equipe, que é composta sempre por membros com diversos conhecimentos e habilidade (multidisciplinar), mas nem sempre se observa a pres ença (ou a necessidade) de recursos detentores de conhecimentos específicos, como de um arquiteto, um DBA ou um especialista de infraestrutura, o qual domine a parte de arquitetura da solução implementada. As empresas as quais adotaram ou irão adotar o Scrum precisam ter em mente a questão de que se um novo requisito não funcional ou um problema grave de performance na aplicação surgir, pode comprometer o sucesso do produto. Na verdade, um requisito não funcional é tão ou mais importante que um requisito funcional.

Entendendo os requisitos funcionais e não funcionais É preciso entender o papel dos requisitos funcionais e não funcionais para poder tratá-los de forma correta: Funcionais: O que o produto deve fazer, que necessidades de negócio deve atender, os cadastros, relatórios, funcionalidades tangíveis ao usuário: estes são cadastrados no “Product Backlog” e posteriormente se transformam em “estórias”, que são priorizadas pelo Product Owner, entendidas e orçadas pela equipe e, durante o planejamento, transformam-se na meta da “Sprint”; Não Funcionais: São aqueles não tangíveis diretamente ao usuário final (Cliente), mas que determinam “como” e “onde” a aplicação (produto) deve funcionar, critérios de segurança e criptografia, escalabilidade, disponibilidade, compatibilidade, etc. •

•

Ambos são itens do backlog, são premissas e fazem part e do Escopo do Produto. Então, precisamos entendê-los e abordálos adequadamente durante o processo de desenvolvimento do software. Desenvolver software representa diversos desafios e, cuidar do produto e da equipe, sem sombra de dúvidas, é tão ou mais importante do que todo o resto. Quando aprendemos a observar estas variáveis de forma mais clara, não apenas a equipe, mas principalmente a empresa, temos uma visão e um comprometimento muito maior, pois estabelece um entendimento e uma comunicação mais transparente. É o que podemos chamar de “fazerem todos falarem a mesma língua”. Para quem não sabe, segundo o próprio Project Management Institute (PMI.org), um Gerente de Projetos usa até 90% do seu Edição 66 - Engenharia de Software Magazine

15

tempo em comunicação. Esta não é um tema a ser abordado neste momento, mas é muito importante lembrar que a Comunicação correta e clara entre todos os envolvidos é essencial para o sucesso de qualquer projeto.

Estruturando o produto e a equipe Um produto nasce para atender determinada necessidade de negócio e/ou administrativa. Para desenvolvê-lo precisamos definir o ambiente de desenvolvimento. Mas, qual a finalidade de termos esse “setup”? A equipe deve conhecer o produto no qual irá trabalhar e ser capaz de capacitar todos seus mem bros quanto ao escopo deste produto e todo o arcabouço de informações, códigos fonte, especificações, estórias, backlogs (onde ficam e como são acessadas). Ou seja, a equipe só pode cuidar de algo o qual: • Ela conheça (O que faz); • Ela entenda (Por que faz); • Ela tenha a clara visão da importância/essência de cada parte do produto. Então, para cada parte, sugere-se realizar este setup considerando estes dois pontos: Produto e Ambiente de desenvolvimento.

Sugestão do setup do produto Para se estabelecer um produto, sugere-se criar um p onto de partida, uma referência ou, ao termo mais conhecido em desenvolvimento de software que é criar uma “Baseline”. A partir da criação desta referência, será possível entender melhor, não apenas o que o produto deve fazer, mas sim “como” ele deve suportar. Para criar esta baseline, será necessário envolver todos, principalmente o Product Owner e o Sc rum Master. Criar uma lista de requisitos funcionais e não funcionais da aplicação não precisa ser uma tarefa complexa. Quanto mais clara e objetiva ela for, melhor cumprirá com seu obj etivo que é descrever sucintamente o produto. Pode-se utilizar de uma simples tabela, conforme o exemplo na Tabela 2 , a ser usada como consulta e referência. Temos quatro campos: • Requisito Funcional: Destinado a identificar o requisito pelo nome, designação ou identificador do requisito ou funcionalidade do software. Podemos dizer até que seja a referência a um “item de configuração”; • Descrição: Uma breve descrição do requisito ou funcionalidade, informando seu objetivo central ou “para o que ela se destina”; • Requisito Não Funcional: Nome, designação ou identificador do requisito não funcional do software. Podemos dizer Requisito Funcional Cadastro de Usuário

Descrição Manter dados do usuário

Cadastro de Pedidos

Manter os pedidos de Venda

até que seja a referência a um “item de configuração”. Sugerese colocá-lo na mesma “linha” do requisito funcional pois, na maioria das vezes, um requisito não funcional pode ser criado especificamente para um requisito funcional. Pode-se também serem abordados os objetos (componentes, classes,  bibliotecas). Lembrando que a maneira a ser adotada deve ser aquela que Equipe preferir ou se sentir mais confortável. Pode haver mais de um requisito “não funcional” para um mesmo requisito “funcional”. Observe o exemplo na Tabela 2 onde o requisito “Cadastro de Pedidos” possui dois requisitos “não funcionais” – Workflow e Acessos Simultâneos; • Descrição: Uma breve descrição do requisito não funcional, informando seu objetivo central ou “para o que ela se destina”. Em uma arquitetura orientada a objetos, estes podem (e devem) ser construídos de forma mais genérica permitindo seu reuso em diversos pontos do sistema. Além destas informações, pode-se incrementar com outros campos como: data de criação, data de atualização, usar hiperlinks para levar para outro documento, ou até criar um código identificador para cada requisito. Não menos importante, pode ser interessante associar as estórias criadas para atender a cada um dos requisitos. Como outras sugestões, pode-se também incluir a versão, a data de entrega de cada um destes requisitos. Devemos lembrar que um requisito não funcional pode ser definido “globalmente”, ou seja, ele está presente no software como um todo e não apenas em uma ou outra funcionalidade (requisito funcional) em específico. Mesmo assim, por uma questão de visualização e controle inicial, estes requ isitos não funcionais devem ser mapeados junto com os requisitos funcionais de forma que não sejam esquecidos durante a avaliação e o Sprint Planning.

Critérios de classificação de demandas (issues) do produto Temos agora uma lista de referência, um ponto de partida e, assim, temos condições de “classificar” as demandas que temos. Antes de se cadastrar os itens no Product Back log (lista geral de demandas do produto), deve-se ter bem claro o que será entendido como bug (erro), mudança, nova funcionalidade ou novo requisito não funcional. Ao adotar estes quatro tipos de classificação, o processo de priorização de demandas também ficará mais fácil. Um bug grave ou crítico sempre será mais prioritário do que uma mudança ou nova funcionalidade e, por vezes, ambos serão igualmente críticos ou dependentes. Existirão momentos onde não haverá escolha e, tanto o bug quanto a mudança ou a nova funcionalidade deverão ser resolvidos numa mesma Sprint.

Requisito Não Funcional Criptografia Workflow

Criptografar a senha do cliente Distribuir automaticamente os pedidos entre as linhas de produção

Acessos Simultâneos

Permitir até 1.000 acessos simultâneos

Tabela 2. Exemplo de Baseline Produto

16

Engenharia de Software Magazine - Scrum backlog: requisitos não funcionais

Descrição

AGILIDADE

Os pesos e critérios para orçar cada um destes tipos tamb ém poderão ser levados em conta. Iremos comparar, brevemente,  bugs e novos requisitos de maneira a podermos elencar os “pesos” e “critérios” com maior propriedade. Seguem: • Bug é um erro sobre algo existente então, por mais c omplexo que seja resolvê-lo, será mais fácil corrigi-lo do que algo “novo”; • Mas, o que seria “algo novo”? Uma nova funcionalidade ou um novo requisito não funcional podem “esconder” complexidades ou dependências que não foram ou não puderam ser identificadas logo no início então, a partir daí, temos um ponto de interrogação, um alerta de “risco” e, este fator de risco deve incorporar a estimativa (de forma racional e comprometida pelos membros da equipe) considerando que a estimativa pode falhar e, neste caso, tem o fator da “novidade”. Obviamente que o bom senso sempre deverá imperar: uma nova funcionalidade a qual, todos sabem ser uma cópia quase fiel de uma já existente, não pode ser considerada “nova” do ponto de vista técnico, correto? Enfim, agora temos uma visão do produto, seus requisitos funcionais, não funcionais e uma classificação para cada tipo de demanda que faz parte do backlog e, desta forma, a equipe está pronta para orçar, planejar as sprints e gerar estimativas. Por outro lado, temos um Product Owner ciente dos desafios impostos pelo backlog existente e as decisões e os caminhos para alcançar o sucesso.

Sugestão de setup para a equipe de desenvolvimento

Ao adotar uma ferramenta, dê preferência àquelas que faça m o controle de versões e, além disso, que dispon ha da facilidade de controle por “branches” (ramificações). Controlar versões significa poder controlar o que foi alterado no conteúdo do código fonte, quem o alterou e quando. E ainda, poder estabelecer qual membro da equipe pode ou não acessar partes do código ou todo ele. O recurso de “branch” permitirá que vários membros da equipe possam trabalhar em separado, cada um em sua “branch” em separado e, sem “poluir” o código estável com código em desenvolvimento durante os processos de correção e/ou evolução. Este recurso aumentará a produtividade da equipe e reduzirá o índice de falha por serem gerados “builds” com código inacabado. A parte de “Builds” será abordada mais adiante. Não devemos nos esquecer de ter um repositório, ou área dentro do repositório de código fonte, para os documentos como os backlogs de Produto e da Sprint, ou de documentos contendo as estórias implementadas e a implementar. É importante lembrar também que as políticas de acesso e permissões devem ser geridas pela equipe de infraestrutura, a fim de garantir que todos os membros da equipe possuam tudo o que precisam e também tenham seus acessos conforme sua necessidade. Em último lugar, mas não menos importante, esta ferramenta de repositório permitirá a execução do backup (cópia de segurança).

Para se estabelecer uma equipe ágil, motivada e produtiva, não bastam bons computadores e boa remuneração agregada com excelentes benefícios. Um ambiente favorável e bem estruturado são peças fundamentais. Da mesma forma que o foi abordado no item “produto”, começar minimamente com um ambiente e equipe estruturadas, as chances de se alcançar uma boa produtividade, qualidade do produto e satisfação da equipe, são muito maiores. Seguem alguns itens a serem considerados e disponibilizados à equipe de desenvolvimento: ferramentas, rotinas e, ambientes.

Ferramenta de repositório de código fonte É no código fonte que tudo começa para um sistema. É essencial saber quem e quando alterou o código fonte e qual é versão do mesmo. Para isso, se faz necessário adotar um repositório de código e não estamos dizendo em ter uma “pasta” compartilhada na rede, mas sim uma ferramenta que desempenhe este papel. Podemos citar várias como CVS, SVN, Team System, GIT, entre outras. A principal função de um repositório é a de centralizar o armazenamento do código fonte, evitando que cada membro da equipe possua uma cópia do código em sua própria estação de trabalho. Um repositório unificado significa um ganho considerável em performance e segurança geral. Com este repositório, não haverá mais preocupações como: “quem está alterando o código “x”?” ou “qual é a versão mais recente e estável do código “y”?”. Edição 66 - Engenharia de Software Magazine

17

Uma vez que o código fonte e/ou documentos encontra-se em um local centralizado, torna-se simples e eficaz fazer as cópias de segurança, obedecendo aos critérios e políticas da empresa.

Ferramenta de geração de builds Outro ponto crítico no desenvolvimento de sistemas é a cultura de se gerar as Builds ou Versões. Build, no contexto do desenvolvimento de software, significa uma versão “compilada” de um software ou parte dele que contém um conjunto de recursos que poderão integrar o produto final. Existem diversas opções, algumas até já integradas aos repositórios de código fonte. Algumas tecnologias exigem compiladores específicos. Enfim, o que importa é ter o conceito e a cultura estabelecida dentro da empresa e da equipe. Gerar builds sempre que houver uma mudança significat iva no produto e que se permita sua avaliação, é uma boa prática para dar continuidade ao processo de desenvolvimento, testes, homologação e roll out (disponibilizar o software em produção). Possuir um ambiente com o fim de se gerarem as builds aumenta a garantia da qualidade do software. Podemos dizer que este ambiente é um ou o mais importante e necessário dos ambientes para a equipe desenvolver seu trabalho.

Rotina de deploy automatizado Uma rotina pode ser entendida como “processo” repetível, ou melhor, sempre que algo de uma natureza específica tiver de ser feito, que o seja seguindo-se uma sequência de passos de execução previamente definidos, estruturados, documentados e conhecidos pelos membros da equipe. Um bom exemplo prático do termo rotina seria a “Rotina de Backup” da empresa. Dizer que existe uma Rotina de Backup seria o mesmo que dizer – sempre que uma cópia de segurança de dados for gerada, será da forma X. Esta forma X representa sua ocorrência (periodicidade), contemplará os dados armazenados nas máquinas e/ou locais determinados, e os arquivos de backup serão gravados (salvos) em um determinado dispositivo (unidade de disco, fita, disco óptico, etc.) e serão fisicamente guardados em determinado local seguro. Enfim, chamar de rotina condiz com o detalhamento da(s) ação(ões) a(s) qual(is) existem para sua execução. Chamamos de deploy a ação de “instalar” ou “entregar” o software desenvolvido e compilado (uma build) em um am biente. Esta ação pode ser feita manualmente, porém exige muita atenção e é extremamente suscetível a falhas. Aliando as definições de rotina e deploy tem-se que: sempre ao se instalar alguma atualização de um software, os passos de 1 até N deverão ser seguidos, verificados e, caso ocorra algum erro, deverá haver um procedimento de retorno específico definido. Agora imaginemos, na prática, uma equipe de desenvolvimento de software, a qual adotou uma metodologia de desenvolvimento ágil (como Scrum ou XP). As ações de criação e/ou alteração do software ocorrerão durante uma Sprint. Nesta(s)

18

Sprint(s) (corrida(s)), serão realizadas inúmeras e simultâneas alterações no código fonte, por diversas pessoas e, a todo o momento. Estas alterações serão entregues através de novas versões do software. A cada nova versão (ou Build), para ser considerado “entregue”, deverá ocorrer à instalação e configuração dos componentes do software (deploy) em um ambiente definido, de forma a disponibilizar esta nova versão do sistema para os testes e homologação necessários. É importante ressaltar que: o ato de um deploy é considerado como uma alteração no ambiente. Isso significa que sempre que um deploy ocorrer, algo novo (seja uma atualização ou um novo sistema) será instalado e afetará os itens de conf iguração atuais no(s) ambiente(s) onde forem aplicados. Desta maneira, sempre se deve preocupar em se ter um ponto de retorno, ou seja, ter uma versão estável para voltar. Dependendo do tamanho e/ou da complexidade da versão (Build) entregue, podem ser consumidas algumas horas de um ou mais profissionais para realizar o deploy (instalação) do software. O tempo ainda pode aumentar muito se houver a necessidade de se atualizar itens de configu ração da própria máquina como, por exemplo, versões de objetos, pacotes de correção (patches ou service packs), atualização de componentes do sistema operacional ou do sistema de gerencia mento do  banco de dados, enfim, tudo isso leva tempo e ainda, corre-se o risco de algo dar errado. Se algo não sair conforme o planejado, precisarmos dar o rollback e voltar à situação anterior. O processo de desfazer uma atualização (ou deploy) pode ser proporcional ou maior do que o processo normal de deploy. Pode-se dizer que se o tempo estimado para realizar um deploy for de uma hora, caso seja necessário desfazê-lo, poderá ser gasto a mesma uma hora ou até mais. Portanto, o processo de deploy precisa ser muito bem estruturado, documentado e conhecido por todos os membros da equipe envolvidos nesta atividade. Não é opção ter um processo de deploy o qual não contemple o “caminho de volta” (rollback). Vale muito a pena investir recursos (pes soas + tempo) para conceber, estruturar, documentar, treinar e estabelecer o processo de deploy na empresa. Estamos falando sobre deploy, mas não podemos nos esquecer das pessoas responsáveis por esta atividade. Por se tratar de algo tão essencial, deve existir uma equipe dedicada a esta atividade de deploy que é a equipe de infraestrutura. Esta equipe deverá possuir conhecimentos mais específicos com relação aos ambientes (máquinas – hardware e programas – software). Esta equipe de infraestrutura existe para salvaguardar o ambiente e não permitir que este seja modif icado sem o devido planejamento. Portanto, deve-se sempre manter a equipe de infraestrutura ciente do planejamento destas intervenções de maneira que tudo continue funcionando corretamente. Para entender melhor sobre a importância e a criticidade deste assunto gostaríamos de citar uma ocorrência: Certa vez, uma consultora em CMMi e MPS.Br comentou: “o maior risco nos projetos de Tecnologia é, e tão somente, a própria tecnologia. O tempo que se investe em escrever a aplicação (software),

Engenharia de Software Magazine - Scrum backlog: requisitos não funcionais

AGILIDADE

testar, homologar e disponibilizá-lo em produção é, infinitamente menor, do que a “caça” aos problemas oriundos de atualizações de versões de qualquer componente do ambiente, seja hardware ou software. Geralmente são problemas os quais exigem horas e horas de pessoas e geralmente, são resolvidos de uma maneira totalmente adversa e sem uma explicação lógica. Aqueles que não tem a menor “lógica” para acontecer porém, acontecem e são extremamente avassaladores com nossa rotina de trabalho”. Há grande sentido nesta colocação desta consultora e reforça a necessidade e importância em se ter um processo de “deploy” muito bem estruturado e documentado.

Ambientes de Infraestrutura: definição Pode-se dizer que um ambiente é composto por uma ou mais máquinas, que contêm os requisitos necessários para hospedar o software desenvolvido. Estas máquinas também deverão possuir o software básico (sistema operacional, sistema de gerenciamento de banco de dados, software de servidor de aplicação, etc.), devidamente instalado e configurado, a fim de suportar a aplicação. Podemos dizer que existem basicamente, três ambientes necessários para o desenvolvimento de software: Desenvolvimento, Testes e Produção. A seguir serão abordados os ambientes sugeridos e minimamente necessários para viabilizar e otimizar o processo de desenvolvimento de software considerando uma estrutura  baseada em metodologia ágil (Scrum).

 Ambiente de integração contínua Antes de explicarmos quanto ao ambiente tecnológico para receber a Integração contínua, é necessário contextualizar o seu conceito. Segundo Martin Fowler, Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho. Geralmente, cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente. Seguindo este conceito, para um ambiente mais produtivo de uma equipe de desenvolvimento de software, recomenda-se a adoção da Integração Contínua, pois durante uma Sprint o resultado das alterações e/ou correções no código fonte realizadas pela equipe de desenvolvimento deverão gerar novas versões (Builds) e estas builds deverão ser disponibilizadas (deploy) automaticamente em um ambiente de Integração Contínua. O objetivo do ambiente de Integração Contínua é ser um ambiente para o desenvolvedor, e os demais membros da equipe, verificar se a implementação está de acordo com o esperado, aplicando seus testes unitários e até automatizados. Se o código funcionar neste ambiente, podemos dizer que temos quase 15% (percentual de completude e não percentual de esforço) do trabalho concluído. Com o código funcionando,  basta mandar essa versão para os testes.

 Ambiente de Teste Antes de falarmos sobre o ambiente de testes, é importante relembrarmos o que são testes. Conforme comentamos anteriormente, um produto de software deve possuir um “escopo”, ou seja, estabelecer “o que” e “como” deve se comportar. A partir do escopo definido, surgem os requisitos funcionais e os não funcionais. De posse destas definições, deve-se estabelecer uma validação para verificar se o “o que” e o “como” foram atendidos. A esta validação, dá-se o nome de Testes. Testes devem ser aplicados para qualquer criação ou alteração no código fonte. Eles servem para verificar se o que foi feito; implementação, a correção ou o novo software está atendendo aos requisitos solicitados. Existe uma vasta literatura contemplando a gestão e execução de testes. Nosso objetivo agora não é explicar esta parte, mas sim de ressaltar sua importância no processo como um todo e ainda, ressaltar a necessidade de executá-los dentro de um ambiente dedicado e seguindo os critérios necessários e, acima de tudo, registrar o resultado dos testes de forma que possamos tomar decisões sobre o que deve ser feito e sua criticidade e severidade. Mas, não basta simplesmente testar, é imprescindível ser criado e seguido um roteiro, um plano de testes. Para que os testes ocupem um papel mais central, é recomendável que seja adotada uma metodologia voltada para este fim chamada TDD – desenvolvimento orientado a testes. Adotando este método TDD, todo o desenvolvimento será orientado ao teste o que minimizará os erros básicos. Segundo as definições existentes na metodologia chamada Extreme Programming ou XP, o termo TDD pode ser descrito da seguinte maneira: Test Driven Development (TDD), ou em português Desenvolvimento orientado a testes, é uma técnica de desenvolvimento de software que se baseia em um ciclo curto de repetições: primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis. Agora que já entendemos um pouco sobre os conceitos de testes e de uma sugestão de metodologia, precisamos entender mais sobre a importância e o significado dos testes. Da mesma forma que um código implementado pode ter sucesso, podem existir erros. Se durante os testes algum erro foi identificado, isso ocorreu porque houve o pleno entendimento pela equipe do “o que” e do “como” os requisitos foram definidos no escopo, estes requisitos foram traduzidos em casos de teste e estes testes aferiram corretamente a execução do código gerado. Testar e não encontrar erros, isso sim pode ser sinal de problemas. Encontrar um erro durante os testes poupa muitos problemas os quais, se ocorressem em produção, poderiam ser devastadores, desde a perda da credibilidade ou até gerar prejuízos financeiros para todos os envolvidos. Para que seja possível executar os testes se faz necessário possuir um ambiente destinado a isso. Um ambiente de teste Edição 66 - Engenharia de Software Magazine

19

servirá para execução dos testes internos pela equipe (sem intervenção ainda do cliente). Este será o ambiente o qual receberá a versão (Build) gerada no ambiente de Integração Contínua após ter sido realizado o deploy desta versão. Em termos de configuração, deverá se assemelhar ao ambiente de Homologação e/ou ao ambiente de Produção. O ideal é que o ambiente de testes seja o mais próximo possível ao ambiente de Produção.

 Ambiente de homologação É neste ambiente onde serão aplicados os testes e validações do que está sendo entregue. Quem deverá executá-los serão os usuários e/ou clientes do software. Damos também o nome de Testes de Aceitação a este processo de Homologação realizado pelo cliente. Em linhas gerais, significa que se o cliente “aceitar” ou “considerar homologado” o software entregue, o cliente endossa o produto em termos de escopo e qualidade. Não é incomum que este ambiente seja disponibilizado pelo próprio cliente. Sendo assim, os tópicos anteriores que mencionam o processo de “deploy” se fazem mais necessários do que nunca. Possuir um processo estabelecido de deploy aumenta a credibilidade sobre a empresa e o profissionalismo da equipe envolvida na construção do software contratado. É neste ambiente também que deverão ser aplicados os testes relacionados aos requisitos não funcionais. Geralmente, para execução de testes de performance/carga, será necessária a construção de “robôs” que simulem acessos simultâneos e transações para aferir se o software entregue “aguenta” conforme o que foi estabelecido. Existem ferramentas disponíveis no mercado para este fim. A configuração deste ambiente deve se assemelhar, o máximo possível, da configuração do ambiente de produção (hardware e software). Quanto mais próxima estiver do ambiente de produção, maior a garantia de sucesso nos testes.  Ambiente de produção Chama-se de Ambiente de produção aquele conjunto de hardware e software destinado a hospedar a aplicação desenvolvida e testada pela equipe, homologada e aceita pelo cliente e/ou usuário(s) que a utilizarão. Trata-se de um ambiente o qual deverá ser controlado e protegido rigorosa e cuidadosamente por uma equipe dedicada – geralmente a equipe de Infraestrutura da Empresa ou do próprio cliente. O ato de criação de um software passa por muitos caminhos até que chegue neste estágio de disponibilizá-lo em produção. Neste ponto, o processo de deploy será colocado à prova. Tenha certeza em seguir todos os passos já estabelecidos e executados nos momentos anteriores. Da mesma maneira q ue foi feito o deploy nos ambientes de testes e de homologação, o processo de deploy em produção deve seguir os mesmos moldes e, ainda, com um pouco mais de atenção. Isso garanti rá o sucesso de todo o esforço investido.

20

Trabalhando com os requisitos não funcionais Em se tratando de metodologias ágeis, temos dois grupos de pessoas: a equipe de desenvolvimento e o Product Owner. Cada grupo possui suas necessidades específicas. Para o Product Owner foi abordada a necessidade de se estabelecer o escopo do produto (Baseline) e também, uma forma melhor de se registrar e classificar o backlog do produto. A equipe já adotou e está confortável para construir soft ware de forma ágil. Mas, por outro lado, a realidade de sua empresa pode ainda não ter alcançado tudo isso e, agora, devemos operacionalizar os requisitos não funcionais. Conforme expusemos anteriormente, existem alguns problemas relacionados ao tratamento incorreto destes requisitos não funcionais. Mas, qual seria a origem desses problemas? Para cada um deles podem haver inúmeras causas: 1. Não houve modelagem do Banco de Dados? 2. A máquina que hospeda o Banco de Dados foi corretamente dimensionada? 3. Faltou adotar alguma boa prática do Banco de Dados como uso de Índices, Procedures, Queries, Views, entre outros? 4. A aplicação foi desenhada para suportar quantos usuários simultâneos? 5. O conjunto de máquinas, o DataCenter ou a infraestrutura disponibilizada para hospedar a aplicação foi dimensionada para suportar alta disponibilidade? Quem deveria ter se preocupado com isso? Olhando para “o quem” (pessoa), existem dois papéis: o ScrumMaster e o Product Owner e, objetivamente, os dois são os verdadeiros responsáveis por não terem se preocupado com a falta de definição dos requisitos não funcionais. Pode parecer estranha essa colocação em atribuir a responsabilidade destas falhas ao ScrumMaster e ao Product Owner, mas sim, estes papeis deveriam ter se preocupado com isso. Existem inúmeras justificativas para a não observação destes requisitos não funcionais como tempo, falta de foco nesta questão entre outras. mas o fato é que não foram observados estes requisitos. Planejar e tratar os requisitos não funcionais não é, originalmente, uma questão bem definida nas metodologias ágeis. Ao observarmos leituras da forma clássica de desenvolvimento de software (Cascata/Waterfall) como, por exemplo, o Unified Process (Processos Unificados), os requisitos funcionais ou não funcionais, é o centro de tudo. Ao nos remetermos à época da adoção desta forma clássica é relevante ressaltar que não existiam métodos eficazes de produzir software e, com a adoção desta metodologia, houve ganhos significativos relacionado ao sucesso dos projetos de desenvolvimento de software. Construir software de boa qualidade e de forma rápida poderia ser impensável, até o advento das metodologias Ágeis. A partir da popularização destas metodologias, conquistou-se a velocidade e o cumprimento das expectativas alcançando ótimos resultados para as partes interessadas. Na verdade, esta popularização também levou muitos a dar mais foco na agilidade, velocidade, visibilidade e deixando um

Engenharia de Software Magazine - Scrum backlog: requisitos não funcionais

AGILIDADE

pouco de lado as premissas, o escopo, enfim, os requisitos. É preciso entender o fato: problemas como os relatados anteriormente são graves e, muitas vezes, de difíc il e demorada resolução. Uma arquitetura mal definida, um banco de dados mal modelado, uma infraestrutura mal dimensionada, geram todos estes e tantos outros problemas. Por esta razão que foi mencionado a importância de se ter uma referência (baseline) do produto para que esta sirva de nivelamento de comunicação, fazendo com que todas as partes interessadas tenham acesso e absorvam integralmente os objetivos a serem alcançados pelo soft ware a ser desenvolvido.

Como podemos evitar tais problemas? O Scrum Master e o Product Owner devem conversar, alinhando seus conhecimentos. O Product Owner possui o entendimento e as necessidades comerciais e conseguirá definir os requisitos não funcionais. Com o auxílio do Scrum Master, que detém uma bagagem técnica, conseguirá entender os requisitos funcionais e não funcionais bem como seus impactos no software. O resultado desta conciliação de necessidades e conhecimentos será a definição de uma lista de requisitos funcionais e não funcionais a serem contemplados pelo software, ou melhor, o Baseline do Produto conforme mencionamos anteriormente. Uma vez que temos uma lista de requisitos (funcionais e não funcionais), o Scrum Master terá condições de verificar os conhecimentos e habilidades necessárias (skills) para transformar estes requisitos em software. Determinando essa lista de skills, o próximo passo é identif icar se os membros da equipe contemplam estas exigências. Se os membros da equ ipe já possuírem as qualificações, ótimo, caso contrário, resta apenas duas alternativas: capacitar às pessoas ou contratar novos recursos. Qualquer uma das opções exigirá investimentos da empresa e, neste momento, o Scrum Master aliado ao Product Owner, deverão levar estas demandas à alta direção da empresa e  justificá-la. Capacitar à equipe existente gera sempre um sentimento de valorização da equipe e muitas pessoas sentem-se extremamente motivadas, este seria o principal ponto positivo ao optar-se pela capacitação da equipe. Outro ponto importante seria o fato de que estas pessoas levarão para o treinamento os desafios conhecidos, possibilitando um maior aproveitamento tanto do treinamento em si quanto a aplicação dos conhecimentos adquiridos na prática. Como pontos negativos da opção de capacitar a própria equipe, destacam-se o tempo das pessoas, pois enquanto elas estiverem em treinamento, não estarão produzindo e também, as chances de rotatividade destas pessoas uma vez que estiverem mais qualificadas, serão mais cobiçadas e até assedias pelo mercado. Para lidar com estes pontos positivos e negativos, a alta direção da empresa deverá balancear estas questões. Considerando os aspectos negativos, com relação ao tempo, o Product Owner, o Scrum Master e a equipe, deverão se organizar para priorizar

os itens do backlog (as estórias) equilibrando os conhecimentos e a quantidade de pessoas disponíveis para a execução dos trabalhos durante o período em que a outra parte das p essoas estiver em treinamento. Com relação à rotatividade, o departamento de Recursos Humanos deverá atuar de forma a gerar mecanismos que incentivem a retenção das pessoas através de políticas de reconhecimento bem como acordos onde as pessoas que receberem treinamento se comprometam a permanecer na empresa. Obviamente que existem diversos outros aspectos relacionados a Recursos Humanos e políticas específicas de cada corporação, mas o fato é que se deve observar esta opção de capacitar a equipe, analisando clara e objetivamente os pontos positivos e negativos para uma correta tomada de decisão. Quanto a opção de contratar novos recursos, sejam estes efetivos ou temporários, a forma de contratação dependerá das políticas e da realidade da empresa. O ponto chave desta opção é ter em mente que as lacunas de pessoas e sk ills sejam preenchidas para atender o objetivo. Mesmo assim, os novos recursos demandarão investimentos em treinamento quanto ao projeto, o produto e a forma de trabalho da empresa e ainda, sempre haverá uma curva de aprendizado versus produtividade onde, dependendo das circunstâncias, o novo recurso estará mais alocado em treinamentos, consumindo também recursos da equipe os quais tenham condições de ensinar e ambos, não estarão produzindo neste ínterim. A produtividade plena da equipe só atingirá os patamares desejados após este período de ensino e a aprendizagem estiverem concluídos. De forma resumida, os tempos e a quantidade de pessoas disponíveis, até atingirem sua plenitude em termos de produtividade irão variar. Estes fatores deverão ser considerados tanto na opção de capacitar a equipe tanto quanto a contratação de novos recursos. Vale ressaltar que, acima de tudo, tanto a Organização (Empresa) quanto as equipes devem estar confortáveis e comprometidas com a decisão tomada. Considerando que todas as questões de organização dos  backlogs, da lista de requisitos, das equipes e de toda a infraestrutura necessárias estejam atendidas, chega o momento de organizar o trabalho e iniciar o processo de planejamento das Sprints. A execução dos processos permitirá a operacionalização de todos os tópicos explicados neste artigo conforme passaremos a explicar. A execução dos processos da metodologia Scrum inicia-se com o Planejamento das Sprints, a esta etapa dá-se o nome de Sprint Planning (Planejamento da Sprint). A atividade de Planejamento da Sprint (Sprint Planning) serve para orçar os itens priorizados pelo Product Owner e, caberá à equipe dizer se são possíveis ou não de serem tratados em uma ou mais Sprints. Percebam que estamos tratando apenas os itens priorizados e não o Backlog geral. É neste momento, durante o planejamento, que estes requisitos deverão ser revistos, atualizados, e norma lmente, serem transformados em estórias e devidamente orçados, planejados e implementados nas Sprints pela equipe. Da mesma forma que o ritual de revisão do Product Backlog ocorre. Edição 66 - Engenharia de Software Magazine

21

Ao final de cada Sprint, as metodologias ágeis, como o Scrum, indicam a necessidade de ser feita uma revisão. A esta revisão dá-se o nome de Sprint Review ou Retrospective Meeting (Retrospectiva da Sprint). Nesta ocasião, são verificados os resultados alcançados, as falhas e os pontos de melhoria. A reunião de Retrospectiva de fato não é o evento a ser utilizado para o fim de revisar os requisitos. Sugerimos que seja criado um novo evento, o qual pode ser denominado de Product Review ou Product Retrospective. Este novo evento deverá ocorrer logo após a Reunião de Retrospectiva e, obrigatoriamente, antes de ser iniciado o Planejamento da próxima Sprint. Este evento servirá para criar e atuali zar a lista de itens de escopo do Produto (Product Baseline). Seguindo esta sugestão de criar este novo evento, permitirá que a lista de requisitos, o baseline do Produto, seja criado igualmente de forma ágil e, ao longo do tempo, torne este baseline do Produto tangível, completo, atendendo as necessidades da empresa e da equipe. Estas sugestões estão baseadas no fato de que, conforme descrito nas metodologias ágeis, não existe o detalhamento ou indicação dos momentos ou eventos a serem dedicados ao estudo do produto exclusivamente. A Atividade de “orçar” o Backlog do Produto (Product Back log) é um bom exemplo disso. Ao verificar as metodologias ágeis, durante a fase de encerramento, existe o evento de Retrospectiva da Sprint. Dentro deste evento de Retrospectiva existe o ponto chamado de “Fazer a Melhoria Contínua dos processos”. Fazer a Melhoria Contínua dos processos significa rever,  junto com a equipe, tudo que foi bom e tudo o que poderia ser feito de uma melhor maneira. Todos os membros da equipe devem sugerir e eleger mudanças. Geralmente estas mudanças devem objetivar o aumento da produtividade e/ou da qualidade da própria equipe. Tais mudanças devem ser implantadas estabelecendo-se critérios de avaliação permitindo que os ganhos sejam medidos após a adoção das mudanças. Ao se criar este novo evento de Revisão do Produto houve, na verdade, uma melhoria no processo atual da empresa.

22

Esta mudança poderá ser aferida na medida em que a produtividade e a qualidade melhorem, bem como com redução do esforço. O resultado prático será percebido quando a equipe conseguirá produzir mais itens do backlog dentro de um mesmo prazo de Sprint. Para concluir, sabemos que existem inúmeros desafios no que tange o desenvolvimento de software. Para superar estes, as metodologias ágeis como o Scrum, oferecem diversos recursos que visam alcançar o sucesso de forma descomplicada e rápida, e ainda, garantindo a qualidade e satisfação do cliente. Toda e qualquer metodologia oferece um framework como forma de demonstrar diversos cuidados os quais se deve ter para garantir o sucesso em sua adoção, porém a forma de como implementá-los ficará por conta de seus praticantes, dandolhes a liberdade de adaptar o que for necessário para adequar estas metodologias à realidade das empresas e das equipes. Links: The Standish Group http://blog.standishgroup.com/

The Standish Group - Chaos Report 2013 http://versionone.com/assets/img/files/ChaosManifesto2013.pdf

Artigo de Martin Fowler sobre Integração Contínua http://martinfowler.com/articles/continuousIntegration.html

Extreme Programming – Extreme Testing http://c2.com/cgi/wiki?ExtremeProgramming

Extreme Programming - Test Driven Development (TDD) http://c2.com/cgi/wiki?TestDrivenDevelopment 

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Engenharia de Software Magazine - Scrum backlog: requisitos não funcionais

Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

IFPUG SNAP: medindo requisitos não funcionais Um framework para a medição dos requisitos não funcionais Fique por dentro: 

A Thiago Chierici Cunha [email protected]

Profissional certificado em pontos de função pelo IFPUG desde 2009. Especialista em Educação Tecnológica pela UEMG e graduado em Processamento de Dados pela Anhanguera. Atualmente leciona em alguns cursos de Pós graduação do IGTI e atua como arquiteto de software na CI&T. Nos últimos 15 anos também acumula

experiências em gestão de processos e projetos e desenvolvimento em diversas plataformas.

medição do software é tão importante quanto à de qualquer outro produto vendido por quantidade, peso ou volume. O framework SNAP apresenta uma divisão de três dimensões em que o software precisaria ser medido: os requisitos técnicos, os requisitos de qualidade e os requisitos funcionais. Para os requisitos funcionais, o mercado adota largamente a análise de pontos de função (APF – BOX 1) definida pelo IFPUG e padronizada pela ISO des de 2009, apesar da ISO também definir outras metodologias como COSMIC, FiSMA, Mark-II e NESMA. Enquanto a APF define bem como medir os requisitos funcionais, os requisitos técnicos e de qualidade não são contemplados pela mesma. Assim, medições feitas apenas com APF normalmente ignoram dimensões importantes do desenvolvimento do software, que

Neste artigo iremos entender o contexto de mercado que exigiu a criação de uma nova metodologia de metrificação não funcional. Será explicado o que são os requisitos não funcionais e suas principais categorias na visão da ISO e do IFPUG. Na sequência, veremos os principais objetivos e benefícios do SNAP e conheceremos a metodologia em si. Finalizando, veremos um exemplo simples, porém completo de uma contagem não funcional e iremos analisar as conclusões sobre o que foi exposto neste trabalho. A medição do escopo serve de base para geração da maior parte das métricas do ciclo de vida do desenvolvimento de software. A utilização do tamanho não funcional como parte do escopo medido, permitirá uma melhor adequação das estimativas, principalmente em métricas relacionadas a esforço e custo.

podem gerar distorções no planejamento e nos custos. Para tentar corrigir tais distorções, o IFPUG havia definido uma etapa da medição funcional, chamada de fator de ajuste, que consistia em um ajuste de até

Edição 66 - Engenharia de Software Magazine

23

mais ou menos trinta e cinco por cento no tamanho funcional original, ou seja, se o sistema possuía 100 pontos de função (PF), seu tamanho ajustado poderia ser um valor entre 75 PF e 135 PF de acordo com os requisitos não funcionais considerados. O uso do fator de ajuste não foi muito bem aceito pelo mercado, assim como pela ISO, que a partir de 2009, sugeriu que o mesmo não mais fizesse parte da metodologia APF. Desde lá, o fator de ajuste passou a ser descontinuado e disponi bilizado como um apêndice do guia do IFPUG. O principal motivo para a mudança seria o fato de que o requisito não funcional não deveria alterar o tamanho funcional da aplicação, mas sim ser contado de forma independente. Surgia a necessidade de uma nova metodologia para medição dos requisitos não funcionais. BOX 1. Análise de Pontos de Função A APF tem suas origens em um trabalho feito na IBM em 1979 por Allan Albrecht que foi formalizado como um guia em 1984. Já em 1988, a versão 2.0 foi publicada pela primeira vez sob a responsabilidade do International Function Point Users Group, o IFPUG. Na versão 3.0 de

1990 o IFPUG transformou o que era um conjunto de várias interpretações sobre como contar pontos de função em um guia mais organizado e coerente. A partir da versão 4.1 de 1999 o

guia começou a sofrer revisões constantes, graças ao enorme crescimento no uso da técnica e a um maior apoio da comunidade para que o processo pudesse amadurecer. No Brasil a APF teve um grande crescimento a partir da publicação da Instrução Normativa 2 de 2008, que sugere o uso de “unidade de medida que permita a mensuração dos resultados”.

Requisitos não funcionais A ISO/IEC 14143-1:2007, que trata de medição de software, especialmente a medição da parte funcional, mas que também define e trata os principais conceitos relacionados, divide os requisitos de usuário (RU) em dois grupos: • Requisitos funcionais de usuário (RFU); • Requisitos não funcionais de usuário (RNF); Sobre as normas e demais definições relacionadas aos RFUs, não iremos nos aprofundar neste artigo. Já para os RNFs, a ISO/IEC/IEEE 24765:2010 os define como “um requisito de software que descreve não o que o software irá fazer, mas como o software irá fazer”. Outra norma que trata sobre os RNFs é a ISO/IEC 25010:2011, que define características da qualidade e suas categorias, listadas a seguir: • Adequação funcional; • Eficiência de desempenho; • Compatibilidade; • Usabilidade; • Confiabilidade; • Segurança; • Manutenibilidade; • Portabilidade; As categorias utilizadas no método SNAP que serão apresentadas neste artigo não são as mesmas utilizadas pelo ISO, porém todas as categorias podem ser enquadradas em ambas as visões sem muita dificuldade.

24

Histórico Em 2007 a diretoria do IFPUG formalizou o início dos trabalhos do que c hamavam na época de Framework de Tamanho Técnico. O IFPUG buscava com este framework uma forma de medir os aspectos téc nicos de projeto de software com uma metodologia independente da APF, utilizada na medição funcional. A importância desta independência seria para manter a compatibilidade de resultados e histórico de projetos legados já medidos e métricas corporativas que já se baseavam na APF. A iniciativa foi apoiada pela diretoria e membros do IFPUG. Em Outubro de 2009 foi publicada a primeira versão do SNAP com o objetivo de permitir uma revisão do trabalho que vinha sendo feito e ajustar a direção e expectativas. Esta versão chamada 0.1 ainda não era aberta à comunidade e foi revisada apenas pela diretoria do IFPUG e comitês específicos de revisão. Como fruto desta revisão e consequentes ajustes, cerca de um ano depois foi lançada a versão 1.0 Beta do Manual de Práticas de Avaliação SNAP - APM. Esta versão foi lançada em novembro de 2010 e no início do próximo ano começaram os testes Beta executados por empresas do mundo inteiro. Ainda em 2011 foi liberada uma nova versão do guia que foi definida como 1.0, que já levavam em consideração os resultados e observações dos processos de teste Beta executados no início daquele ano. Esta primeira versão estabilizada já trazia definições de conceitos, processos e regras para a avaliação dos requisitos não funcionais. A versão vigente durante a criação deste artigo, a 2.0, foi lançada em janeiro de 2013. Esta versão trouxe mais maturidade ao guia, apresentando novos conceitos que eram utilizados, mas não eram bem explicados. Foram feitos ajustes nos processos e regras e algumas subcategorias foram reorganizadas de acordo com o retorno obtido da comunidade. O APM ainda se define como um guia vivo, ou seja, novas versões serão lançadas com certa frequência para tentar ajustar o guia à realidade e às necessidades do mercado. Como o processo possui definições e regras para cada subcategoria funcional, é esperado que novas versões fossem lançadas sempre que novas tecnologias ou necessidades surjam no mercado. Uma preocupação permanente deverá existir para que estas evoluções mantenham a compatibilidade e histórico de contagens que utilizem versões anteriores do guia.

Objetivos e benefícios do SNAP De acordo com o guia do SNAP, são dois os principais ob jetivos da metodologia: o primeiro seria medir o tamanho não funcional de determinado software que é solicitado ou recebido por um cliente, muito útil no momento da contratação de um desenvolvimento e na validação do que foi entregue e sua conformidade com a solicitação original; o segundo objetivo é medir o desenvolvimento e manutenção de requisitos não funcionais, como por exemplo, alterar a tecnologia de implementação de um determinado aplicativo ou criar um mecanismo de segurança em um software já existente.

Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos não funcionais

AGILIDADE

Ao criar o SNAP, o IFPUG também pretendia ter uma metodo logia simples o bastante para que fosse necessária a dedicação de pouco tempo para fazer as medições (BOX 2), incentivando uma maior adoção por vários projetos e empresas. BOX 2. Estimativa x Medição Muitas vezes observamos o uso destes dois termos como se tivessem o mesmo significado no contexto de métricas de software, porém temos algumas diferenças sutis, mas importantes entre os conceitos, já que podem servir de critério contratual ou de auditoria interna ou externa. As estimativas ou aproximações podem ser feitas sem termos todos os detalhes necessários para fazer uma medição completa ou mesmo em caso que temos estes detalhes, mas desejamos uma métrica com maior produtividade e não precisamos de tanta precisão.Abaixo temos a Tabela 1, adaptada do guia do SNAP, que ilustra quando normalmente podemos fazer aproximações e quando podemos fazer medições em um ciclo de desenvolvimento generalista.

Fase do ciclo de vida

PS podem ser estimados

PS podem ser medidos

Proposta

Sim

Não

Requisitos

Sim

Não

Projeto

Sim

Sim

Construção

Sim

Sim

Entrega

Sim

Sim

Manutenção (Preventiva, adaptativa ou perfectiva)

Sim

Sim

Tabela 1. Estimativas e medições de Pontos SNAP (PS)

Ao criar o SNAP, o IFPUG também pretendia ter uma metodo logia simples o bastante para que fosse necessária a dedicação de pouco tempo para fazer as medições, incentivando uma maior adoção por vários projetos e empresas. De acordo com o guia oficial as empresas podem utilizar o SNAP como: • Uma metodologia para medir o tamanho não funcional de um produto de software, para dar suporte a análises de qualidade e produtividade; • Uma metodologia para estimar custos e recursos necessários ao desenvolvimento e manutenção de software; • Um fator de normalização para a comparação de softwares; • Uma metodologia para determinar o tamanho não f uncional de um pacote de aplicativos adquirido, através da avaliação de todas as partes e categorias incluídas no pacote; • Uma metodologia para ajudar os usuários a determinar os  benefícios de um pacote de aplicativos para sua organização, através da avaliação de partes ou categorias que satisfaçam seus requisitos específicos.

O processo de avaliação não funcional Na Figura 1  temos uma visão geral do processo SNAP. O primeiro passo tem uma visão mais conceitual, mas que é importante para orientar os passos seguintes. No segundo, normalmente utilizaremos o guia como referência para conseguir escolher as categorias corretas. Os demais (passos 3 a 6) representam os passos mais práticos da contagem.

Figura 1. Os passos do processo SNAP

A primeira seção do processo SNAP equivale ao planejamento do que será medido. Neste passo iremos definir o motivo de estarmos fazendo a contagem, e deixar claro onde ela começa e onde termina. Para isso detalharemos os seguintes aspectos: • Propósito da avaliação; • Tipo da avaliação; • Escopo da avaliação; • Fronteira da aplicação; • Partições. O propósito da avaliação define de forma textual o objetivo do trabalho de medição ou aproximação que será feito. É através dele que podemos buscar o tipo e escopo da avaliação. Um possível exemplo de propósito poderia se parecer com os exemplos: • Fornecer o tamanho não funcional do projeto de desenvol vimento do software XXX, para servir de base para o cálculo de esforço e custos para elaboração de proposta técnica e comercial; • Fornecer o tamanho não funcional entregue pela mudança de tecnologia do banco de dados do sistema YYY. Assim como na contagem de pontos de função, o tipo da avaliação terá três possibilidades. Esta informação normalmente é utilizada para cálculo de outras métricas derivadas. A produtividade, por exemplo, será diferente para projetos de melhoria e de desenvolvimento, mesmo que tenham a mesma quantidade de pontos de função ou pontos SNAP: • Projeto de desenvolvimento: quando estivermos metrifican do a criação de um determinado software. • Projeto de melhoria: quando estivermos alterando um software existente. • Aplicação quando estivermos medindo uma aplicação já existente. O escopo será criado a partir do propósito da contagem e define o conjunto de requisitos não funcionais do usuário a serem incluídos na avaliação. O escopo pode incluir mais de uma aplicação e, normalmente, irá incluir um conjunto de partições, além de uma lista de categorias e subcategorias SNAP. Tanto as partições quanto as categorias serão detalhados nos próximos tópicos. A fronteira da aplicação também é um conceito comum com a APF e é a separação conceitual entre o software avaliado e seus usuários. É a fronteira que define o que é externo à Edição 66 - Engenharia de Software Magazine

25

aplicação. O IFPUG costuma dizer que a fronteira funcio na como uma membrana pela qual os dados são recebidos pela aplicação, processados e devolvidos para o usuário. A fronteira não deve considerar questões estritamente técnicas para ser definida. Uma partição define um conjunto de funções do software, dentro de uma mesma fronteira, que compartilham critérios de avaliação do SNAP e que exigem esforço para implementação que não seriam cobertos por uma métrica APF. As partições, assim como as funcionalidades medidas em APF, devem ser  baseadas na visão do usuário, não podem ter sobreposições e servirão para atender aos requisitos não funcionais do software. Na Figura 2 representamos visualmente alguns dos itens relacionados ao passo 1.

Figura 2. Visão de alguns conceitos do passo 1 do SNAP

A segunda seção do SNAP trata de como vamos relacionar cada requisito funcional a uma categoria e subcategoria SNAP. As categorias foram criadas de forma generalista para tentar agrupar necessidades não funcionais, mesmo que ainda nem foram inventadas ou definidas. A divisão contempla todos os requisitos técnicos e de qualidade conforme definidos na ISO/ IEC 9126-1 ou pela ISO/IEC 25010. As categorias SNAP estão agrupadas da seguinte forma: Operações de Dados - Validações na Entrada de Dados - Operações Lógicas e Matemáticas - Formatação de Dados - Movimentações de Dados Internos - Entregar valor agregado aos usuários por configuração de dados • Projeto de Interface - Interfaces do Usuário - Métodos de Ajuda - Múltiplos Métodos de Entrada - Múltiplos Métodos de Saída • Ambiente Técnico - Múltiplas Plataformas - Tecnologia de Banco de Dados - Processos Batch • Arquitetura - Software baseado em componentes - Múltiplas Interfaces de Entrada / Saída •

26

Como contar A terceira seção do SNAP começa a contagem dos pontos não funcionais propriamente dita, identificando as unidades de contagem SNAP (UCSs). A medição será feita nos passos seguintes para cada UCS. É importante saber que um mesmo requisito de usuário pode gerar, ao mesmo tempo, pontos de função e pontos não funcionais (pontos SNAP). O UCS pode ser uma atividade, um componente do software ou um processo que se enquadre na estrutura de categorias apresentada no tópico anterior. Na quarta seção vamos definir a complexidade de cada UCS mapeado na etapa anterior. De acordo com a categoria e subcategoria em que o UCS foi identificado, responderemos um conjunto de questões disponíveis no guia, que dirão a complexidade deste UCS. De acordo com a complexidade levantada, cada UCS receberá uma pontuação não funcional. Na quinta seção vamos calcular a quantidade de pontos SNAP (PS) totais por subcategoria. Para isso devemos somar o tamanho obtido para cada UCS no passo anterior. É importante observar que um mesmo UCS poderá gerar PSs para mais de uma subcategoria, quando este estiver relacionado a mais de uma categoria ou subcategoria.  Já no sexto e último passo, devemos somar as parciais obtidas por subcategoria para chegar aos totais por categoria. Na sequência, somaremos todos os PSs para obter o tama nho não funcional total, para nosso projeto ou aplicativo.

Exemplo de contagem Nosso exemplo será estruturado em três etapas. Na primeira parte iremos apresentar a descrição de uma determinada demanda de desenvolvimento. Na segunda, iremos seguir o processo SNAP para calcular o tamanho não funcional da demanda. Na última, iremos mostrar informações que podemos derivar das métricas iniciais, e como podemos nos beneficiar destes números ao longo do ciclo de vida do projeto e do histórico da empresa. Em alguns momentos, alguns detalhes podem ser ocultos para tornar o exemplo mais didático. A Tabela 2 representa a solicitação do nosso cliente fictício, que é a primeira parte do nosso exemplo. Nela representamos uma requisição de funcionalidades que, indiretamente exige a implementação de um conjunto de requisitos não funcionais. No escopo deste exemplo, não focaremos na medição do tamanho funcional da demanda. De acordo com a Figura 1  começaremos nossa contagem fazendo algumas definições conforme detalhamos abaixo: • Propósito da contagem: fornecer o tamanho não funcional da demanda para calcular todas as métricas que permitirão gerar os custos da demanda 0001 do sistema de Gestão Patrimonial; • Tipo da avaliação: projeto de melhoria; • Escopo da avaliação: está definido na ficha representada na Tabela 2; • Fronteira: no exemplo não temos muitos detalhes do sistema, mas neste caso não fica dúvida do que faz parte da fronteira da aplicação que está sendo contada;

Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos não funcionais

AGILIDADE

• Partições: no escopo desta contagem temos apenas uma partição. Na medição do tamanho não funcional deste exemplo iremos considerar os requisitos relacionados apenas a uma das categorias do SNAP, a “Operações de dados”. Como abordamos anteriormente, cada categoria exige um tratamento especial, e de acordo com o escopo do artigo não seria possível exemplificar todas as categorias, mas o processo para cada uma delas é o mesmo. Solicitação de implementação - 0001 Sistema: Gestão patrimonial Solicitante: Thiago Cunha Criar um cadastro de ativo que irá compor um novo módulo de gestão de ativos do sistema de gestão patrimonial. Campos: ID do ativo - Alfanumérico - Opcional Código corporativo - Numérico - Opcional Nome do ativo - Alfanumérico - Obrigatório Valor estimado - Numérico - Opcional - Maior que zero - Reais

Data aquisição - Data – Opcional - YYYY/MM/DD Depreciação - Numérico - Obrigatório - Maior que zero - Percentual Tabela 2. Solicitação feita por nosso cliente fictício

Agora vamos completar o segundo passo do SNAP (associar RNFs com categorias e subcategorias) e também definir o terceiro. Podemos observar neste exemplo a ocorrência de algumas subcategorias de Operação de dados listadas a seguir. Para cada uma contaremos um UCS, já que estamos contando apenas uma funcionalidade. Definindo a complexidade e a quantidade de pontos de cada UCS, estaremos cumprindo os passos 4 e 5 respectivamente: •

Validações na Entrada de Dados:

Pela solicitação recebida, temos que validar os campos ‘Valor estimado’ e ‘Depreciação’, pois ambos exigem valores positivos. No primeiro caso, a validação só será feita se o campo for preenchido, ou seja, se eu não digitar nenhum valor, eu não precisarei validar se ele é maior que zero. Este tipo de validação condicional é o que chamamos de nível de aninhamento.  Já cada campo validado será chamado de DER. Com estas informações já podemos entender a tabela de referência desta subcategoria, conforme a Tabela 3. Baixa 1-5 aninhamentos Critério Fórmula (PS =) 2* #DERs

Nível de complexidade Média

Alta

6-14 aninhamentos

15+ aninhamentos

3* #DERs

4* #DERs

Tabela 3. Fórmulas da categoria ‘Validações na Entrada de Dados’

Como no nosso exemplo temos apenas dois níveis de anin hamento de validações, o nível de complexidade desta subcategoria será baixo e para calcular os Pontos SNAP da mesma, vamos utilizar a primeira fórmula, ou seja, teremos 2 * #DERs.  Já que teremos dois campos validados teremos 4 PSs relativos à ‘Validações na Entrada de Dados’.

• Formatação de Dados: Nesta subcategoria também utilizaremos o termo DER, só que para denotar os campos que são formatados ou convertidos para exibição. Já para definir a complexidade desta UCS a regra é um pouco menos matemática e mais textual, conforme a Tabela 4.

Critério

Baixa Conversões de tipos de dados ou formatação simples

Fórmula (PS =) 2* #DERs

Nível de complexidade Média

Alta

Casos que não sejam Baixa ou Alta

Criptografia ou descriptografia

3* #DERs

5* #DERs

Tabela 4. Fórmula da categoria ‘Formatação de dados’

Em nosso exemplo temos três casos de formatação de valores, sendo uma formatação de data, uma de moeda e uma de percentual. Em todos os casos temos formatações simples, caracterizando que o nível de complexidade desta UCS é baixo. Desta forma utilizaremos a primeira fórmula da tabela chegando a 6 PSs relativos à ‘Formatação de dados’. De acordo com o último passo do SNAP, podemos obter o total de SPs da nossa demanda. Neste exemplo teríamos 10 SPs. É importante ressaltar que este valor representa o tamanho não funcional da demanda. O tamanho f uncional (PFs) ainda precisaria ser medido em pontos de função de forma independente. Para casos mais complexos, poderíamos ter UCS de várias categorias e subcategorias relac ionados a um mesmo requisito de usuário. Para cada subcategoria, o APM apresenta uma diferente tabela para cálculo da complexidade da UCS. Neste exemplo, apresentamos duas destas tabelas. As demais são parecidas e podem ser utilizadas facilmente com o apoio do guia. Com isso, podemos perceber que boa parte das etapas de medição tem características comuns com o processo do SNAP, o que pode facilitar o aprendizado e aceitação desta nova metodologia pelo mercado. Por outro lado, no SNAP temos diferentes parâmetros na contagem de acordo com a categoria não funcional coberta, o que torna mais importante o uso de referências durante a contagem. Após conhecer os conceitos básicos e possuir um guia de referência com as categorias e pontuações de referência, um profissional não terá grande dificuldade para fazer contagens. Este artigo fornece a visão conceitual, mas não fornece o guia de categorias e suas fórmulas que pode ser o próprio guia disponibilizado pelo IFPUG. Apesar de várias compatibilidades, de acordo com a versão atual do APM, o tamanho total da aplicação não deve ser obtido através da soma do PFs e dos SPs. Cada uma das c on tagem deve ser tratada de forma independente. O IFPUG ain da planeja novas pesquisas relacionadas à possibilidade de utilizar uma ún ica métrica como tamanho total (funcional mais não funcional) e quais seriam as implicações disso. Edição 66 - Engenharia de Software Magazine

27

Sobre o impacto de um ponto SNAP na produtividade ou esforço total, somente o uso em determinado contexto pode trazer respostas. Assim como com os pontos de função, cada combinação de equipe de desenvolvimento, cliente e processo, terão diferentes produtividades. Com relação à técnica de fator de ajuste, pudemos observar que esta foi descontinuada e não deve mais ser utilizada como forma de medir requisitos técnicos e de qualidade de projetos e aplicativos, tornando o SNAP uma excelente opção para este tipo de medição em projetos e aplicativos que utilizem ou não a APF para medir os requisitos funcionais.

Links: IFPUG http://www.ifpug.org/ 

Grupo de discussão SNAP (requer aprovação) http://www.linkedin.com/groups?home=&gid=1854919&trk=anet_ug_hm

BFPUG: Comunidade nacional sobre métricas http://www.bfpug.com.br/ 

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

28

Engenharia de Software Magazine - IFPUG SNAP: medindo requisitos não funcionais

Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

Use Case Point: Estimativas de Projeto – Parte 1 Medição de software Fique por dentro: 

Anderson Pinheiro Balbo [email protected]

Possui graduação em Informática com ênfase em Gestão de Negócios pela Faculdade de Tecnologia da Zona Leste, especialização em Engenharia de Software pelo Instituto de Computação-UNICAMP e especialização em Gestão de Projetos em TI pela Fundação Carlos Alberto Vanzolini-USP. Atualmente é supervi sor de TI na Caixa Econômica Federal.

Wilson Vendramel [email protected] 

Possui especialização em Engenharia de Software e mestrado em Ciência da Computação pelo Instituto de ComputaçãoUNICAMP, e especialização em Melhoria de Processo de Software pela Universidade Federal de Lavras. Atuou como Especialista de Sistemas na IBM Brasil.

Maria Beatriz Felgar de Toledo [email protected] 

Possui graduação e mestrado em Ciência da Computação pelo Instituto de Computação-UNICAMP e doutorado em Sistemas Distribuídos pela Universidade de Lancaster, Inglaterra. Atualmente é professora associada na Universidade Estadual de Campinas. Tem interesse nas áreas de gestão de processos de negócio, serviços Web, Web semântica e arquiteturas orientadas a

serviços.

ESTE ARTIGO FAZ PARTE DE UM CURSO

A

s empresas que concorrem no mercado de software buscam constantemente aperfeiçoar a qualidade dos seus serviços prestados, a fim de obter diferencial competitivo e fidelidade do cliente. Uma das maiores preocupações dessa indústria tem sido a previsibilidade de projetos, onde apenas 34% dos projetos de software atingem seus objetivos dentro do cronograma e orçamento planejados. Decisões que são tomadas com bases empíricas conduzem o projeto a dados de prazo e custo inconsistentes. O Standish Group destaca que 43% dos erros localizados em um projeto estão relacionados ao fator custo. Dessa forma, as consequências imediatas de um processo de software sem planejamento

Um grande desafio dos Gestores de Projetos de Software tem sido a estimativa de prazo, custo, e esforço adequados durante o ciclo de vida do software, desde o planejamento até o produto final. Este trabalho mostra como a aplicação de medidas se torna uma importante ferramenta de apoio a decisão no planejamento de projetos de soft ware, permitindo ao líder responsável a adequação dos elementos necessários para a entrega do produto ou serviço com qualidade, usando a técnica Use Case Point e consideração de seus resultados aplicados no estudo de caso de uma fábrica de software.

das estimativas são a falta de controle adequado de custo e cronograma e a inadequação dos mesmos no ciclo de vida do projeto. Diante dos problemas apresentados, é desejável que a empresa possua o conhecimento sobre as técnicas de estimativa para o projeto em questão, assim como é fundamental que haja uma base de dados a respeito de projetos anteriores e que possibilitem o seu aproveitamento,

Edição 66 - Engenharia de Software Magazine

29

pois dessa forma o gerente estará capacitado a planejar o produto a ser desenvolvido baseando-se em informações concisas e realistas. Gestores que tomam decisões com bases empíricas tendem a estimar prazos fictícios, na maior parte dos casos, a favor do cliente, uma vez que são pressionados por um mercado competitivo onde o menor custo e prazo são determinantes para a escolha do fornecedor de soft ware. Consequentemente, a ausência de tempo necessário para as etapas do ciclo de vida do projeto levam as equipes a reduzir o esforço; em alguns casos, excluem atividades consideradas menos importantes (análise e testes, em geral, são deixados de lado, e a prioridade é dada para a codificação). Dessa forma, o produto, ao passar por uma auditoria de qualidade, retorna às mãos de seus desenvolvedores, gerando o retrabalho e a necessidade de um prazo maior para entrega, não antes estipulado. Com isso, o custo também é ampliado, gerando outros problemas como a insatisfação do cliente. A adaptação do processo de software ao cronograma e custo previamente estimados reduz a possibilidade de erros no produto, considerando que ele será produzido dentro do tempo necessário para as atividades propostas. Os integrantes da equipe conhecerão as suas atribuições claramente, uma vez que trabalharão no prazo acordado para a realização das etapas de desenvolvimento. Neste contexto, o objetivo desta série de art igos é apresentar a técnica adequada para as estimativas de custo, esforço e prazo necessários em uma organização cuja finalidade seja a produção de software.

Medidas de software A medição de software pode ser considerada um fator crucial para concretizar a gestão das melhorias de processo, pois é a  base para se manter o controle do mesmo, além de ser tratado como indicador de desempenho de software. As medições que tratam de tamanho associado ao custo, prazo e esforço em processo de desenvolvimento de software são considerados fatores primordiais de sucesso em gerenciamento de projetos. As estimativas documentadas constituem a base para a ela boração de um plano do projeto de software. As estimativas de tamanho de projetos de software devem ser utilizadas para a derivação das estimativas de custo, esforço e cronograma, conforme as diretrizes do CMMI. As medições que se referem ao tamanho, prazo e esforço são denominadas operacionais, pois estão diretamente associadas às estimativas do processo; as demais estimativas recebem da operacional os recursos necessários para outras medições, conforme segue: Medições Estratégicas: são medições de comparação com os padrões de qualidade e em relação às demais empresas de tecnologia, assim como o diagnóstico do custo do software e seus componentes associados; Medições Táticas: são medições responsáveis por dar suporte à gestão do ambiente de software e analisar as tendências •

•

30

desse ambiente em relação à qualidade, custo, produtividade das pessoas e processos, além dos impactos causados pelas inovações tecnológicas. Quando se fala a respeito de medições, é importante distin guir esse termo de medida e métrica, embora ambos estejam intimamente ligados com o primeiro. A medida em engenharia de software pode ser entendida como um indicador quantitativo de um atributo, enquanto que a medição é o ato de determinar a medida, e a métrica é a quantidade de medidas individuais de um atributo ou processo de desenvolvimento. Com isso, entende-se que a medida de software possa mensurar extensão, capacidade, ou qualquer outro fator qua ntitativo que esteja relacionado a uma característica ou propriedade envolvida. Através da medição são descritas as medidas necessárias para se obter os valores e resultados. O conjunto de medidas obtido conduz às métricas, permitindo a extração de dados que, aliados a um indicador, permitem a análise conjunta do universo de pesquisa. O indicador é o valor ou o agrupamento de valores de referência que, quando comparado com as métricas, permite analisar se estas estão ou não ajustadas com o valor esperado. O processo de medição pode ser dividido em formulação, coleta, análise, interpretação e realimentação. A atividade de formulação abstrai as medidas e métricas adequadas do projeto, considerando apenas aquelas que sejam viáveis para a análise. A coleta acumula os dados abstraídos do projeto, que darão suporte à análise. A atividade de análise calcula as métricas. A interpretação analisa as métricas calculadas em  busca da representatividade das informações. A atividade de realimentação leva à equipe as orientações para o ajuste do processo, de acordo com as informações interpretadas.

Classificação das métricas de software Em geral, as métricas podem ser classificadas conforme a sua complexidade de medição, modelo de abstração utilizado no desenvolvimento do software, ou ainda com foco em um determinado fator de análise no projeto. Chiossi e Germano [3] as classificam conforme a sua aplicação, podendo ser diretas ou indiretas, tradicionais, de sistemas estruturados ou orientados a objetos, e ainda em métricas de produtividade, qualidade, técnicas, ou orientadas a pessoas. As métricas diretas são obtidas de atributos facilmente quantificáveis como tempo de duração, linhas de código, custo, entre outros; as métricas indiretas são derivadas de duas ou mais métricas simples, para gerar informações como qualidade, complexidade do produto, confiabilidade e outros. As métricas tradicionais baseiam-se nos dados que são inseridos no sistema e nas informações que são geradas pelo mesmo, ou simplesmente entrada/saída; as métricas de sistemas estruturados têm como abordagem as medições em diagra ma de fluxo de dados, enquanto as métricas orientadas a objetos concentram-se em diagramas como os de classes. As métricas de produtividade obtêm do resultado do processo a produtividade da equipe; as métricas de qualidade validam

Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto – Parte 1

PLANEJAMENTO

as funcionalidades do produto contra os requisitos do cliente; as métricas técnicas destinam-se aos atributos do software, independente do processo no qual foi desenvolvido; as métricas orientadas a pessoas concentram-se na forma como as pessoas desenvolvem o software e a sua interação com as ferramentas e métodos de desenvolvimento.

Métricas utilizadas no Projeto Para que uma métrica seja viável em um projeto, ela deve ter atributos mensuráveis, e não sofrer influência dos envolvidos no projeto; a coleta de dados também não deve prejudicar o processo de desenvolvimento [3]. Além disso, as métricas devem ser analisadas sob o ponto de vista de pessoas, processo e produto (ver Figura 1).

Figura 1. Métricas associadas ao projeto

As métricas de projeto e seus indicadores são utilizados por um gerente e sua equipe, a fim de adaptar o fluxo de trabalho e as atividades técnicas que agregam valor ao projeto, tornando essas métricas estratégicas. A partir da obtenção das medidas de esforço e tempo em projetos anteriores, são formados indicadores que podem ser usados com as atuais medições do projeto, gerando estimativas que auxiliem nas decisões do gerente. Essas decisões têm como objetivo reduzir o prazo do projeto através de correções de atrasos e problemas, e aperfeiçoar a qualidade do produto durante o seu ciclo de vida, assim como a redução de defeitos. À medida que os defeitos são minimizados, há melhoria da qualidade do produto, e a quantidade de retrabalho durante o projeto também é reduzida; isso leva à diminuição de custos no projeto. Embora cada modelo de medida possua suas próprias técnicas de cálculo, a maioria deles tem como base os pontos de função ou linhas de código, dos quais derivam as métricas de produtividade. As linhas de código (LOC) são medidas que levam em consideração a quantidade de linhas produzidas essenciais para a execução de um programa ou componente. Os pontos de função (FP), estão voltados ao domínio da informação que in terage com o software, e não às linhas de código que definem a funcionalidade do produto. Dados estatísticos obtidos por Drach [4] confirmam que em 2001 apenas 30% das empresas utilizavam métricas para medir produtividade dos processos de software, sendo que 18,2%

aplicavam a técnica de pontos de fu nção, e 10,3% baseavam-se em linhas de código. Um dos modelos mais recentes aplica o FP a caso s de uso. Esse modelo, criado em 1993, é denominado Pontos por Caso de Uso (UCP), e tem como finalidade a estimativa de tamanho e esforço que são extraídos diretamente dos requisitos do projeto.

Métricas de processo As métricas de controle, associadas ao processo, referem-se à duração, custo de esforço e número de incidentes associados ao processo. Também fornecem indicadores que podem servir como base para análise em outros projetos, possibilitando que se verifique o seu andamento, além de possíveis riscos e pro blemas, levando a melhorias nos processos de software. Entretanto, a medição do processo somente determina a qualidade do produto se associada à medição deste. Uma abordagem que auxilia na medição de processo é a Meta-Questão-Métrica (Goal-Question-Metric - GQM). Esta integra os objetivos das métricas com os modelos de processo, produto e perspectivas de qualidade de software, alinhando as suas necessidades às metas da organização e às questões associadas ao seu aperfeiçoamento. As metas são as expectativas da organização de melhoria do processo, como por exemplo, redução do tempo de desenvolvimento, melhoria de produtividade da equipe, redução do retrabalho. As questões são indagações associadas às metas de melhoria, buscando na resposta a solução pontual para o problema levantado. As medições do processo, ao compor as métricas do GQM, fornecem os resultados das ações aplicadas no processo, confirmando se as metas foram atingidas e se as questões foram solucionadas. Por envolver a qualidade do processo, a GQM pode ser situ ada no contexto da abordagem do CMMI.

Métricas de pessoas As métricas de pessoas indicam a produtividade, tamanho da equipe, quantidade de comunicação associada ao projeto e habilidades individuais, possibilitando ao gerente verificar se a equipe está alinhada com as necessidades do projeto. Uma vez convertidos em indicadores, esses dados se tornam base de análise para futuras métricas. Podemos relacionar produtividade ao esforço utilizando a equação: Produtividade = Esforço / Tamanho do soft ware. Considerando essa equação, pode-se concluir que o esforço da equipe de software é diretamente proporcional ao tamanho do software, e assim como o esforço, é obtido através de métricas como a Análise de Pontos de Função ou Pontos por Caso de Uso, por exemplo.

Métricas de Produto As métricas preditivas, associadas ao produto, avaliam o seu tamanho e complexidade da estrutura lógica, de dados e de funções combinados ou isoladamente, além da quantidade de atributos e operações em objetos, de um projeto. Edição 66 - Engenharia de Software Magazine

31

Fatores de Avaliação dos Indicadores de Produtos Correção Confiabilidade Eficiência

Determina se um programa está de acordo com a especificação e as necessidades do cliente Refere-se à precisão com que o produto atende aos requisitos do cliente Suporte dos recursos de computação necessários para que o produto desempenhe o seu papel

Integridade

Refere-se ao controle do acesso aos dados do sistema

Usabilidade

É o esforço empregado na interação com o produto

Manutenibilidade

Esforço vinculado à correção de erros

Flexibilidade

O quanto o programa é suscetível a alterações

Testabilidade

Grau de facilidade em se testar um programa contra as funções requeridas para o mesmo

Portabilidade

Esforço necessário para adequar o produto a outro ambiente operacional

Reutilização

Refere-se aos componentes (ou o programa como um todo) que possam ser utilizados por outras aplicações

Interoperabilidade

Grau de facilidade para a junção de sistemas

Tabela 1. Fatores de Avaliação dos Indicadores de Produtos

Os principais fatores avaliados pelos indicadores de produto estão apresentados na Tabela 1. As métricas de produto podem ser divididas em classes de métricas dinâmicas, coletadas por medições de um programa em execução, e estáticas, coletadas através de documentações ou dados do programa. Ao se medir um programa em execução é possível verificar a sua resposta às ações do usuário (confiabilidade) e se suas tarefas estão sendo executadas corretamente (eficiência). Quando a análise é feita a partir de documentos, ou de um programa que não esteja em execução, a documentação pode fornecer ao usuário a visão do quanto o programa é simples de se manusear (usabilidade), e ao ser comparada contra o programa, é possível verificar se os requisitos foram corretamente aplicados, não apresentando erros (manutenibilidade).

estrutura das medidas que devem atender às necessidades de informação, e o de processo, que define o processo de medição.

Medição prática de software A medição prática de software (Practical Software Management - PSM) tem o objetivo de fornecer as melhores práticas e ferramentas de medição para a análise de prazos e custos em desenvolvimento de projetos de software e sistemas. A ferramenta oficial do PSM é o PSM Insight, que automatiza os processos de medição (ver Figura 2). O PSM foi desenvolvido pelo Departamento de Defesa e o exército norte-americano como um projeto que visa estabelecer um processo adequado de medição para o gerenciamento de software e sistema, assim como fornecer a base para uma comunicação e tomada de decisão objetiva, e a base para o gerenciamento do desempenho na organização. Além desses fatores, o PSM também define os seguintes propósitos para o projeto: Desenvolver práticas efetivas de medições destinadas às necessidades de gerenciamento de informações e técnicas de software e sistemas; Passar para uso geral medidas integradas que resultem no aumento de desempenho. •

•

São apresentados dois modelos integrados para o PSM: o de informação, responsável pelo modo de especificação e a

32

Figura 2. Ferramenta oficial do PSM, o PSM Insight

Modelo de Informação O modelo de informação é composto por três diferentes n íveis de medida, como consta a Tabela 2. Detalhes da construção da medição permitem visualizar a aplicação dos três níveis de medida no modelo de informação, identificados na Figura 3. Os atributos das entidades são obtidos por métodos de medição, formando com isso as medidas básicas. As funções de medição são responsáveis por agregar duas ou mais med idas  básicas (o resultado são as medidas derivadas). Semelhante às funções de medição, o modelo também utiliza cálculos algorítmicos para gerar os indicadores que dão suporte à informação.

Modelo de Processo O modelo de processo do PSM é composto por quatro atividades principais: planejar, aplicar, e avaliar as medições, além de estabelecer e sustentar o comprometimento, atividades essas  baseadas na sequência típica Planejar-Fazer-Verificar-Agir.

Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto – Parte 1

PLANEJAMENTO

Níveis de Medida Básica

Descrição Medida adquirida diretamente dos atributos de um produto ou processo em medição, convertidos em valores;

Derivada

Medida adquirida através duas ou mais medidas;

Indicadores

Conjunto de medidas que dão suporte às necessidades de informação.

Tabela 2. Níveis de medida do modelo de informação

atividade se dispõe a identificar ações de melhoria para garantir atualização constante do processo, de modo a satisfazer as necessidades de informação. As ações de melhoria aumentam a qualidade do processo, e consequentemente do projeto de desenvolvimento do sistema, permitindo ao líder do projeto estabelecer parâmetros de controle das etapas do processo e a adequada análise dos resultados que geram diferencial competitivo à organização, em relação às organizações que não adotam os procedimentos de melhoria. Essa atividade no PSM permite que a organização, ao deter as informações geradas pelas medições, promova o seu amadurecimento constante, em relação às medições obtidas.

Estabelecimento e Sustentação do Compromisso Essa atividade assegura que as medições são suportadas tanto a nível organizacional quanto do projeto provendo a infraestrutura organizacional e os recursos necessários para implementar um programa de medição viável (ver Figura 4).

Figura 3. Construção de uma medição pelo PSM

Planejamento das Medições A atividade de Planejamento das Medições identifica as necessidades de informação no projeto e a seleção de medidas apropriadas que atendam a essas necessidades. Podemos associar o planejamento à formalização da coleta de dados, análise e divulgação dos procedimentos adotados, incluindo assuntos relacionados ao planejamento para avaliar os resultados das medições na forma de produtos de informação. O Planejamento das Medições também é caracterizado por prover a integração das medições para o gerenciamento de processos e projetos técnicos existentes. Mais do que forçar um projeto a implementar e pré-definir medidas, o PSM, através dessa integração, assegura que as medidas selecionas serão efetivas no contexto do projeto.

Aplicação das Medições A Aplicação das Medições consiste em uma das atividades núcleo que direcionam os requisitos dos usuários das medições. Trata-se da coleta e processamento dos dados de medição. Esses dados são utilizados tanto para atender às necessidades de informações individualmente como para as informações inter-relacionadas a outras questões. Ela é responsável por gerar os produtos de informaç ão para apresentar os resultados de análises, ações alternativas, e recomendações para a tomada de decisões no projeto.

Avaliação das Medições A Avaliação das Medições aplica técnicas de medição e análise a fim de avaliar o próprio processo de medição. Essa

Figura 4. Modelo de Processo de Medição do PSM

O Paradigma da Meta-Questão-Métrica O paradigma da GQM é utilizado para suportar decisões sobre que medições devem ser feitas e a forma como elas serão utilizadas. Essa abordagem surgiu a partir da dificu ldade em saber o que deve ser medido, e a necessidade de melhoria dos processos levou os seus desenvolvedores a associarem essa prática aos estágios de maturidade do CMMI. O GQM implica a construção de um modelo para medição imprescindível à obtenção dos resultados das métricas. Considerando o GQM como orientado às metas ou obje tivos, três passos fundamentais para sua elaboração são definidos: • Conceitual: define o objeto a ser medido, podendo ser um produto, processo ou recurso; • Operacional: define questões para caracterizar o objeto de estudo e o seu papel no contexto da qualidade; • Quantitativo: trata da obtenção de um conjunto de dados associados ao nível de realização conceitual e operacional, de modo que sejam respondidos com o apoio das métricas. Edição 66 - Engenharia de Software Magazine

33

Fases do GQM

Descrição

Planejamento

Relaciona a equipe que participará do GQM, seleciona a área que deve ser melhorada,define os projetos que serão analisados pelo GQM, e treina a equipe para aplicação do GQM.

Definição

Define os objetivos do GQM,adapta os modelos de software ao método, define as questões a serem solucionadas, e promove a revisão dos planos de GQM.

Coleta de Dados

Coleta os dados obtidos através das métricas.

Interpretação

Analisa os dados contra as questões, a fim de respondê-las.

Tabela 3. Fases do método GQM

Além dos níveis de realização, o GQM também prevê qua tro fases para definir as medições, conforme apresentado na Tabela 3. Durante a elaboração do GQM, são produzidos cenários que apresentam os objetivos e as questões com as métricas associadas. O mapeamento desses cenários tem como base o ponto de vista do cliente, gerente de projetos, e integra ntes da equipe. Os objetivos são compostos por propósitos, questões, objetos e ponto de vista. Cada questão pode apresentar uma ou mais métricas, de acordo com o processo em análise (ver Figura 5).

Figura 5. Objetivo Verificar Aderência ao Processo

Os resultados da implantação das métricas, obtidas através das questões de ordem operacional, possibilitam que indicadores para análises futuras ma is consistentes sejam gerados. O GQM também é recomendável por se tratar de uma abordagem objetiva dos problemas da organização quanto aos processos, que podem ser solucionados pelo levantamento das questões pontuais que envolvem esses problemas, e cujas repostas possam ser convertidas nas métricas. Os resultados são os dados estatísticos que dão suporte a tomada de ações corretivas.

34

Técnicas de estimativa A evolução tecnológica trouxe aos ambientes de desenvolvimento de software a oportun idade de trabalharem com novos paradigmas de medição no projeto, pois para cada abordagem de linguagem de programação utilizada, novos ajustes ou metodologias para obtenção das métricas eram adotados. Nenhum modelo de estimativa é adequado a todos os processos de desenvolvimento, pois para cada um deles há uma amostra limitada do projeto, passível de ajustes para que possa ser utilizado. Os modelos utilizados para estimativas, quando tratam de sistemas de grande extensão, podem dividi-los em componentes menores (subsistemas), de modo a facilitar a análise dos dados na medição. Ao iniciar a análise pelos componentes a fim de se obter as estimativas de custo, adota-se a abordagem  bottom-up. Após analisar os componentes separadamente em uma abordagem bottom-up, os custos são adicionados, totalizando o esforço total para o desenvolvimento do sistema. A análise inicial pela técnica top-down permite ao responsável pela medição conhecer as interações entre os subsistemas na formação do sistema maior, possibilitando a visão da funcionalidade do sistema. Além destas, atri buímos à estimativa top-down os custos relacionados ao sistema como um todo, além do gerenciamento do sistema e sua documentação. Ao se utilizar os modelos de medição, é possível justificar a solicitação de recursos monetários, de tempo e pessoas; avaliar a necessidade de treinamento e recrutamento de pessoas; gerar compensações de produtividade, custo e qualidade; avaliar e mitigar o impacto das mudanças; negociar o orçamento de acordo com as novas exigências de desenvolvimento. Essas razões para estimar o custo de software explicam o uso dos modelos de estimativas. A seguir serão apresentados os modelos CoCoMo 81 e sua versão atual (CoCoMo II), além do método de Delphi, o modelo de Análise de Pontos de Função, e o modelo de Pontos por Caso de Uso.

CoCoMo 81 X CoCoMo II O Modelo de Custo Construtivo (Constructive Cost Model CoCoMo) foi baseado inicialmente em uma análise de banco de dados com 63 projetos, realizada na década de 70 pelo Prof. Dr. Barry Boehm, da Universidade do Sul da Califórnia. O modelo fornece fórmulas detalhadas para determinar o cronograma do tempo de desenvolvimento, além de ser o mais completo para estimativas de esforço baseado em lin has de código.

Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto – Parte 1

PLANEJAMENTO

Ao se analisar as linhas de código como fator de cálculo no CoCoMo, é importante desconsiderar as linhas de comentários no código do programa, pois não são essenciais para a execução do mesmo; elas apenas descrevem as características ou ações que o trecho do código realizará no programa. Dessa forma, as linhas de comentários precisam ser excluídas para, a seguir, elaborar o modelo com base em três modos de desenvolvimento: • Embutido: o desenvolvimento no modo embutido é aplicável a ambientes onde há constantes inovações, com rígidas restrições e alterações mais frequentes em requisitos; • Orgânico: dedicado a ambientes estáveis, com equipe peque na e que desenvolvem sistemas relativamente simples; • Geminado: dedicado a ambientes que possuem característi cas do modo embutido e do modo orgânico. O CoCoMo 81 conta com os estágios de desenvolvimento  básico, intermediário e completo, evoluindo de um para outro à medida que seus detalhes são implementados. O modelo básico tem como foco fornecer a estimativa de forma rápida, e também mede o tamanho do programa em linhas de código para obter as estimativas de esforço e custo no projeto. No contexto do modelo básico, o modo orgânico tem uma produtividade de, por exemplo, 352 LOC por pessoa em um mês, enquanto que esse valor cai para 105 LOC no modo embutido. Chiossi e Germano [3] utilizam o tamanho em milhares de linhas de código (KLOC) para expor os métodos de cálculo do esforço (E) e do tempo em meses de desenvolvimento (Td), considerando vinte e dois dias de trabalho por mês, para os três modos de desenvolvimento (ver Tabela 4). Esforço nominal Modo

Modelo Básico

Modelo Intermediário

Tempo nominal

Orgânico

E = 2,4 S 1,05

E = 3,2 S 1,05

Td = 2,5 E 0,38

Geminado

E = 3,0 S 1,12

E = 3,0 S 1,12

Td = 2,5 E 0,35

Embutido

E = 3,6 S 1,20

E = 2,8 S 1,20

Td = 2,5 E 0,32

Tabela 4. Equações dos modelos básico e intermediário do CoCoMo

Supondo, para um projeto de software desenvolvido no modo embutido, uma estimativa de 70 KLOC para uma aplicação. Através do modelo básico, o esforço requerido e o tempo de desenvolvimento dessa aplicação podem ser calculados conforme segue: Esforço = 3,6 X 40 1,20 = 301 pessoas-mês Tempo = 2,5 X 301 0,32 = 15,5 meses Logo, o cálculo do número de pessoas necessário no projeto é: N = 301 / 15,5 = 20 pessoas

O modelo intermediário considera, além das linhas de código, 15 fatores direcionadores de custo (cost driver), com valores pré-determinados e que auxiliam o responsável pela métrica a se dedicar a uma análise apurada que associe o cost driver certo a formula, de forma a gerar informações mais precisas. De acordo com Chiossi e Germano [3], após calcular o esforço, deve-se multiplicar o resultado pelo valor fornecido na Tabela 5 , de modo a ajustar o esforço aos atributos que interagem com o projeto e que, portanto, interferem no desenvolvimento do sistema. Considerando um projeto desenvolvido no modo embutido, e utilizando o modelo intermediário para a produção de 20 KLOC, temos o seguinte esforço: Esforço = 2,8 X 20 1,20 = 102 pessoas-mês Cada um dos fatores de ajuste pode adequar o esforço de forma a se aproximar da realidade do desenvolvimento. Por exemplo, em um ambiente onde a capacidade do programador é alta e o tempo de resposta é rápido, podemos adaptar o esforço multiplicando-o por 0,86 e 1,07, respectivamente. O resultado obtido (94), ajustado aos demais atributos direcionadores de custo, compõe o trabalho para a produção do software. O modelo detalhado utiliza as mesmas equações do intermediário para obter a estimativa de esforço, entretanto duas características são determinantes para reajustar as métricas [3]: Multiplicadores fase sensitivos para esforço: nele, a análise do cost-driver se aplica a cada fase do projeto, ao invés do pro jeto como um todo, pois alguns fatores podem ser alterados no decorrer dessas fases; Hierarquia do produto em três níveis: a análise do costdriver também abrange o nível de sistema, subsistema e módulo. •

•

A abordagem do CoCoMo II propõe o desenvolvimento das estimativas de custo associado ao reuso do código. Utilizamos a seguinte fórmula, com valores representados na Tabela 6 , para calcular o reuso do código no CoCoMo II: ESLOC = ASLOC x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM) / 100

O CoCoMo II também utiliza medidas indiretas de software, como a contagem de telas, relatórios e componentes, citada como contagem de pontos por objeto por. A seguir temos a equação dos pontos de objeto para obter a produtividade, considerando o código reutilizado: Número de Pontos de Objeto =

pontos por objeto X (100 - % de reuso) 100 Produtividade = Número de Pontos de Objeto / pessoa-mês

A Tabela 7 traduz o resultado dessa equação, onde é possível concluir, através do número de pontos de objeto, se a complexidade desses objetos é simples, média ou difícil. Edição 66 - Engenharia de Software Magazine

35

Cost-Driver

Descrição

Muito Baixa

Baixa

Nominal

Alta

Muito Alta

Extra Alta

Atributos do Produto RELY

Confiabilidade necessária nos requisitos

0,75

0,88

1,00

1,15

1,40

-

DATA

Tamanho do banco de dados

-

0,94

1,00

1,08

1,16

-

CPLX

Complexidade do produto

0,70

0,85

1,00

1,15

1,30

1,65

Atributos do Computador TIME

Restrições tempo de execução

-

-

1,00

1,11

1,30

1,66

STOR

Restrição armazenamento principal

-

-

1,00

1,06

1,21

1,56

VIRT

Volatilidade da máquina virtual

-

0,87

1,00

1,15

1,30

-

TURN

Tempo de resposta

-

0,87

1,00

1,07

1,15

-

Atributos do Pessoal ACAP

Capacidade do analista

1,46

1,19

1,00

0,86

0,71

-

AEXP

Experiência na aplicação

1,29

1,13

1,00

0,91

0,82

-

PCAP

Capacidade do Programador

1,42

1,17

1,00

0,86

0,70

-

VEXP

Experiência com máquina virtual

1,21

1,10

1,00

0,90

-

-

LEXP

Experiência na linguagem de programação

1,14

1,07

1,00

0,95

-

-

Atributos do Projeto MODP

Práticas modernas de programação

1,24

1,10

1,00

0,91

0,82

-

TOOL

Utilização de ferramentas de desenvolvimento

1,24

1,10

1,00

0,91

0,83

-

SCED

Requisitos do cronograma de desenvolvimento

1,23

1,08

1,00

1,04

1,10

-

Tabela 5. Atributos (Cost drivers) considerados como previsores no CoCoMo [3]

Fator

Método de Delphi

Representação

ESLOC

linhas do novo código

ASLOC

linhas do código reutilizável

AA

custo para avaliação de viabilidade do software

SU

custo necessário para a compreensão do software pela equipe

DM

percentual do projeto modificado pelo reuso do código

CM

percentual do código modificado

IM

percentual de esforço de integração do código reutilizado

Tabela 6. Representação da fórmula de ajuste de esforço no CoCoMo II

Tipo de Objeto

Peso da complexidade Simples

Médio

Difícil

Tela

1

2

3

Relatório

2

5

8

Componente 3 GL

10

O método Delphi para obtenção de estimativas de custo tem como objetivo ajustar as métricas obtidas a fim de gerar um valor médio que torne os resultados mais precisos. O método de Delphi colabora com a coordenação das informações adquiridas e cálculo de estimativas confiáveis, através dos seguintes passos (ver Figura 6) : • A especificação do projeto e demais informações perti nentes são apresentadas aos especialistas; • A reunião para disc utir as estimativas é formalizada; • Cada especialista preenche os formulários com as suas estimativas e esforços obtidos, acrescentando o valor provável, com limite superior e limite inferior; • As estimativas do grupo e individuais são resumidas em um relatório, acessível a to dos os envolvidos; • O coordenador, responsável pelas etapas acima, convo ca uma reunião com os especialistas para discussão das estimativas geradas no relatório.

Tabela 7. Um sistema de classificação por esteira rolante

Em seguida, o número de pontos de objeto é dividido pelo número de pessoas-mês, de forma a obter a estimativa de produtividade da equipe de projeto e a maturidade / capacidade do ambiente. O nível de produtividade muito baixo tem valor 4, enquanto o valor 7 está associado a baixa maturidade do ambiente e da equipe, o valor 13 é considerado normal, o nível 25 está associada a alta produtividade, e 50 à produtividade muito alta.

36

O processo de levantamento das estimativas somente termina quando a equipe chega a um consenso quanto ao valor mais preciso. Peters e Pedrycz [6] apresentam o consenso das estimativas individuais através do seguinte cálculo: Estimativa  = (LI e + 4 X estimat iva mais provável + LS e) /

6, onde LI é o limite inferior da estimativa e LS é o limite superior da estimativa.

Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto – Parte 1

PLANEJAMENTO

Como exemplo, um projeto de sistema é apresentado a sete especialistas, de tal forma que todos são instruídos a levantarem estimativas de custo para produzir o software requerido. Cada especialista analisa o projeto e extrai dele os dados para medição, utilizando a técnica que consideram a mais adequada. Após obterem as métricas necessárias, os especialistas devem preencher formulários com questões que envolvem os resultados individuais. Nele, os especialistas incluem os desvios padrão para o valor aproximado gerado nos cálculos. O coordenador do processo reúne as sete estimativas e prepara o relatório com o consolidado das mesmas. O resumo é anônimo, facilitando a análise imparcial do relatório consolidado pelos especialistas, conforme a Tabela 8. Nela também é apresentada a variância de cada especialista, que é a média entre o limite superior e inferior da estimativa. Cada iteração também tem o propósito de reduzir a variância do grupo, pois isso pode significar o alcance do consenso dos especialistas.

Figura 6. Etapas para obtenção das estimativas

Figura 7. Visão geral do processo de contagem de pontos de função

Análise de Pontos de Função O modelo de Análise de Pontos de Função foi criado na década de 70 por Allan Albrecht, e aplicado pela IBM, levando a criação do Grupo Internacional de Usuários de Pontos de Função em 1986. A abordagem da contagem de pontos de função em uma aplicação surgiu como alternativa aos modelos baseados em linhas de código, pois consiste em medir o tamanho do produto baseado em especificação funcional, sem se preocupar com a tecnologia utilizada no processo, conforme será visto adiante. A técnica de Pontos de Função tem como foco os valores do domínio da informação, ou seja, as estimativas de entradas, saídas, consultas, arquivos e interfaces externas para software CAD. A contagem dos pontos de função, é necessário seguir alguns passos, conforme descrito na Figura 7.

Tipo de contagem Quando se planeja estimar um software, utilizando pontos de função, deve-se atentar quanto ao tipo de projeto em

Número do especialista

LI e

Estimativa mais provável

LS e

Estimativa

Variância

1

10

15

32

17

3,7

2

17

24

40

25,5

3,8

3

13

27

35

26

3,7

4

18

30

37

29,2

3,2

5

20

28

40

28,7

3,3

6

14

25

36

25

3,7

7

23

30

39

30,3

2,7

Média

16,4

25,6

37

26,0

3,4

Tabela 8. Média das estimativas e variâncias

questão. Embora haja a entrada de novos projetos para a empresa, alguns deles não requerem que a equipe o desenvolva do início; existem projetos no qual o produto vem parcial ou totalmente pronto, sendo requisitado à empresa o trabalho de melhoria do produto. Há casos tam bém em que o desenvolvimento ocorre em apenas um ou mais produtos que compõem o sistema. Drach [5] apresenta os três tipos de contagem de pontos de função, conforme a sua aplicação no projeto: Contagem de projetos de desenvolvimento: mede a funcionalidade entregue ao usuário através da primeira •

instalação, incluindo a conversão de dados necessária para essa implantação; Contagem de projetos de melhoria: mede a adição, modificação ou exclusão de funções em projetos já implantados, incluindo a conversão de dados; Contagem de uma aplicação: mede as funcionalidades de sistemas de desenvolvimento já implantados a fim de obter valores de referência (baselines) atualizáveis a cada medição dos projetos de melhoria. •

•

A definição do tipo de contagem é determinante para o cálculo dos pontos de função não ajustados.

Edição 66 - Engenharia de Software Magazine

37

Escopo da contagem e fronteira da aplicação O escopo da contagem verifica se a medição envolve o sistema completo ou apenas parte dele, se todas as funcionalidades são requeridas, apenas as utilizadas pelo usuário, ou ainda algum grupo específico, como relatórios, por exemplo. A fronteira da aplicação pode ser entendida como a interface entre o software a ser medido e qualquer usuário, sistema ou outro agente que interaja com este. O IFPUG determina que, para identificar a fronteira, esta deve ser baseada na visão do usuário, a fronteira entre aplicações deve atender às regras de negócio e não a considerações tecnológicas, e a fronteira inicial não deve ser influenciada pelo escopo de contagem. Por fronteira inicial entende-se aquela que já foi definida no início do projeto.

Funções do tipo dados Na análise das funções do tipo dados, encontra-se aquelas referentes a arquivos lógicos internos e arquivos de interface externa. Podemos defini-los, respectivamente, como agrupamentos lógicos de dados dentro das fronteiras da aplicação e mantidos por entradas externas, e agrupamentos lógicos de dados externos à aplicação e que fornece dados para a aplicação. Considerando esse ponto de vista, pode-se entender que os arquivos lógicos internos (ILFs), são grupos de dados que são produzidos e armazenados dentro da aplicação, enquanto que os arquivos de interface externa (EIFs), são grupos de dados que permanecem fora da aplicação em questão, ainda que esteja dentro de uma outra aplicação, e fornecem dados para a aplicação que está sendo medida, interferindo na contagem dos pontos de função. Uma vez definidos os ILFs e EIFs, o próximo passo é determi nar os tipos de elementos de dados (DETs) e tipos de elementos de registros (RETs). Os RETs são os grupos de dados reconhecidos pelo usuário do sistema, e os DETs são campos não recursivos de informações dinâmica, identificáveis pelo usuário. Se um DET for recursivo, apenas o levantamento da primeira informação a respeito deve ser considerado para a contagem. A contagem dos DETs e RETs permite a análise da complexidade da função através da Tabela 9.

Funções do tipo transação As funções do tipo transação descrevem as funcionalidades de processamento de dados fornecidas ao usuário pela aplicação. Seus elementos de contagem são as entradas externas (External Inputs - EIs), as saídas externas (External Outputs - EOs), e as consultas externas (External Inquiries - EQs). As entradas externas são processamentos de dados no sistema originados pelo usuário ou por outro sistema. Essas entradas de dados são usadas para atualizar os arquivos lógicos internos. As saídas externas são informações fornecidas do sistema para o usuário, como relatórios ou mensagens exibidas em tela. As consultas externas são envios de dados para o sistema com o objetivo de se obter respostas imediatas em forma de novos dados.

38

Após definir os EIs, EOs e EQs, deve-se identif icar os DETs, e os tipos de arquivos que são referenciados por uma transação (File Types Referenced - FTR). O FTR pode ser qualquer arquivo lógico interno ou de interface externa, desde que tenha sido lido ou mantido através de uma transação, conforme Tabelas 10 e 11. DET

Número de Elementos

        T         E         R

1 a 19

20 a 50

Maior que 50

1

Baixa

Baixa

Média

2a5

Baixa

Média

Alta

Maior que 5

Média

Alta

Alta

Tabela 9. Complexidade funcional dos ILFs e EIFs

DET

Número de Elementos

        R         T         F

1a4

5 a 15

Maior que 15

0a1

Baixa

Baixa

Média

2

Baixa

Média

Alta

Maior que 2

Média

Alta

Alta

Tabela 10. Complexidade funcional das Eis

DET

Número de Elementos

        R         T         F

1a6

6 a 19

Maior que 19

0a1

Baixa

Baixa

Média

2a3

Baixa

Média

Alta

Maior que 3

Média

Alta

Alta

Tabela 11. Complexidade funcional das EOs e EQs

Contagem de pontos de função não ajustados Uma vez identificadas às complexidades (baixa, média ou alta) para os dados e transações, o próximo passo é calcular os pontos de função não ajustados (UFP). Os valores para cada tipo de dado ou arquivo são pré-determinados, possibilitando dessa forma o cálculo de cada uma das funções do sistema (ver Tabela 12). UFP ILF = 7 x 3 ILF baixa + 10 x 3 ILF média + 15 x 3 ILF alta UFP EIF = 5 x 3 EIF baixa + 7 x 3 EIF média + 10 x 3 EIF alta UFP EI = 3 x 3 EI baixa + 4 x 3 EI média + 6 x 3 EI alta UFP EO = 7 x 3 EO baixa + 10 x 3 EO média + 15 x 3 EO alta UFP EQ = 7 x 3 EQ baixa + 10 x 3 EQ média + 15 x 3 EQ alta UFP = UFP ILF + UFP EIF + UFP EI + UFP EO + UFP EQ Tabela 12. Cálculo dos pontos de função não ajustados

Fator de ajuste Todo sistema sofre a influência de fatores externos, responsáveis pelo desempenho do software e a sua resposta às exigências do usuário. Dessa forma, a contagem apenas da complexidade dos dados e transações torna-se insuficiente para determinar o custo de um sistema. É necessário adaptar

Engenharia de Software Magazine - Use Case Point: Estimativas de Projeto – Parte 1

PLANEJAMENTO

Características Gerais do Sistema Comunicação de Dados Processamento Distribuído Desempenho Configuração Altamente Utilizada Volume de Transações

Refere-se à comunicação da aplicação com o processador, processador, através do envio e recebimento de dados. Nível em que a aplicação transfere dados entre os seus componentes. Refere-se ao tempo de processamento e de resposta, além das taxas de transação. Mede o nível de restrições dos recursos computacionais no desenvolvimento das aplicações. Descreve a influência das transações no projeto projeto,, desenvolvimento, desenvolvimento, instalação e suporte da aplicação.

Entrada de Dados On-line

Descreve o nível das entradas de dado realizadas pelas transações.

Eficiência do Usuário Final

São os fatores humanos como a facilidade de uso pelo usuário final.

Atualização On-line Processamento Complexo Reusabilidade

Mede o nível de atualização dos ILFs on-line. Refere-se ao nível do processament processamentoo lógico ou matemático na aplicação. O quanto o código projetado para uma aplicação pode ser reaprov reaproveitado eitado em outra.

Facilidade de Instalação

Nível de adaptação entre a aplicação e o ambiente que a recebe.

Facilidade de Operação

Autonomia da aplicação para atividades de inicialização, segurança e recuperação. recuperação.

Múltiplos Locais

Refere-se à aplicação ter sido desenvolvida para locais ou organizações diversas.

Modificação Facilitada

Nível de flexibilidade para alteração do comportamento da aplicação.

Tabela 13. Fatores para Ajustes dos Pontos de Função

o valor já obtido dos pontos de função não ajustados com as características característ icas gerais do sistema, que são os principais fatores de influência no funcionamento funciona mento do produto (ver (ver Tabela 13). Cada fator para ajuste dos pontos de função fu nção deve ser nivelado quanto a sua inf influência luência por pontuações de 0 (zero (zero)) a 5 (cinco (cinco),), sendo respectivamente nenhuma, mínima, mí nima, moderada, média, significativa ou de grande influência. As pontuações obtidas em cada c ada um dos quatorze fatores devem ser somadas, e seu valor total (V total) tota l) deve ser calculado na seguinte fórmula: Pontos Pon tos de Função Ajustados Aju stados = (V total x 0,01 + 0,65) x UFP O tamanho funcional do sistema é definido, podendo ser utilizado como variável para obtenção do custo do software. Os pontos de função, funç ão, por não depender da tecnologia empregada, possibilitam uma melhor comparação entre projetos, além da elaboração das estimativas na fase inicial do projeto.

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Links e Referências: 1. HAZAN, C.; STAA, A. Análise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software. In: VI Simpósio Internacional de Melhoria de Processos de Software. Rio de Janeiro: 2004, p.34. http://www.simpros.com.br/simpros2004/VisualizarCon http://www.simpros .com.br/simpros2004/VisualizarConteudo.aspx. teudo.aspx. 77.html 

2. FERNANDES, A.A.; TEIXEIRA, TEIXEI RA, D.S. Fábrica de Software: implantação e gestão de operações. São Paulo: Atlas, 2004. 3. CHIOSSI, T.C.S.; GERMANO, F.S.R. F.S.R. Gerenciamento de Projetos de Software. São Paulo: UNICAMP - Universidade de Campinas, Campinas, 2005. 4. DRACH, M.D. Aplicabilidade de Métricas por Pontos de Função em Sistemas Baseados em Web. São Paulo: UNICAMP - Universidade de Campinas, 2005. http://libdigi.unicamp.br/document/?code=vtls000359854

5. ANDA, B. et al. Estimating Software Development Effort Based on Use Cases - Experiences from Industry, Toronto: Departamento de Informática - Universidade do Oslo, 2001. http://www.bfpug.com.br/artigos.htm

6. VAZQUEZ, C.E.; SIMÕES, G.S.; ALBERT, R.M. Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software. S ão Paulo: Érica, 2003.

Edição 66 - Engenharia de Software Magazine

39

Planejamentoo e Gerência Planejament Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

Desvendando o gerenciamento de projetos – Parte 3 Fase de Iniciação Ini ciação Fique por dentro: 

ESTE ARTIGO FAZ PARTE DE UM CURSO

N

Ary dos Santos Rocha Júnior [email protected] 

Bacharel em Ciência da Computação pela Universidade Federal de Uberlândia, Mes tre em Ciências com Ênfase em Inteligência Artificial pela mesma Universidade. Possui mais de 15 anos de experiência profissio nal, atuando sempre na área de desenvolvimento de sistemas, liderança de equipes, gerenciamento de projetos e como CIO.

40

os dias atuais, sabemos da importância de um bom gerenciamento de projetos. Por consequência, gestão de projetos é um dos principais assuntos discutidos em  boa parte das organizações, principalmente pelos benefícios conquistados com sua adoção ou prejuízos por não se adotar gerenciamento de projetos de forma efetiva. Para que as organizações realmente colham resultados positivos na gestão de projetos, elas devem se estruturar de forma que uma metodologia de gestão possa ser aplicada. O primeiro passo para que isto ocorra é capacitar um grupo de colaboradores em específico para as funções fu nções de gerenciamento de projetos e das metodologias escolhidas para se gerir qualquer projeto da empresa.

Engenharia de Software Magazine - Desvendando o gerenciamento de projetos – Parte 3

Vamos apresentar de forma simples as principais áreas e os principais processos necessários ao gerenciamento de um projeto que estão contidos no Guia PMBOK 4ª Edição. Neste artigo, em específico, será abordada a fase de iniciação dos projetos. Assim, serão retratados conceitos úteis no gerenciamento de qualquer projeto envolvendo tecnologia da informação, desde desenvolvimento de aplicações simples até implantações complexas de ERP. Conceitos estes que qualquer gerente de projetos deve ter em mente para serem aplicados em seu dia a dia. Não serão apresentados modelos dos documentos aqui citados, porém, você pode criálos, desde que o conteúdo dos mesmos reflita a necessidade do projeto.

Desta forma, os assuntos aqui relacionados podem contribuir de forma substancial para o enriquecimento dos conceitos relacionados a gerenciamento de projetos. Ao longo deste artigo perceberemos a importância de todos os grupos de processos de gerenciamento de projetos, mas em especial o primeiro deles, que é o grupo de processos de iniciação.

PLANEJAMENTO

Grupos de Processos de Gerenciamento de Projetos O PMBOK é considerado hoje um dos principais guias de gerenciamento de projetos, sendo utilizado no mundo inteiro. E neste guia, estão descritos os cinco grupos de processos de gerenciamento de projetos. São eles: 1. Grupos de Processos de Iniciação; 2. Grupos de Processos de Planeja mento; 3. Grupos de Processos de Execução; 4. Grupos de Processos de Monitoramento e Controle; 5. Grupos de Processos de Encerramento. O objetivo principal deste artigo é focar no primeiro grupo de processos de gerenciamento de projetos, que é o grupo de processos de iniciação. Dentre os cinco grupos de processos, nenhum pode ser citado como o principal, nem o mais importante; porém, iniciar bem um projeto é o primeiro passo para que este venha a ter sucesso. Caso não se inicie bem, os problemas tendem a aumentar durante o projeto. Um projeto, por definição, é uma atividade ou grupo de atividades que tem início, meio e fim. Caso seja uma atividade que não se conclua, por exemplo, esta atividade é uma atividade rotineira, repetitiva e não pode ser considerado um projeto. Todo projeto tem sua etapa de iniciação, posteriormente é realizado o planejamento, em sequência a execução o projeto, durante todas as suas etapas, é mantido sob monitoramento e controle total do gerente de projetos. Por fim, após todas as atividades do escopo serem executadas, o projeto é encerrado. O grupo de processos de iniciação consiste nos processos realizados para que o projeto seja formalmente forma lmente iniciado, como o próprio nome já sugere. O primeiro passo é a definição do escopo do projeto e a alocação e aprovação dos recursos financeiros fina nceiros para o mesmo. Neste momento também são identificadas todas as partes interessadas no projeto e também é formalizado o nome do gerente do projeto, que conduzirá todas as etapas do mesmo. Após a nomeação do gerente do projeto, ele deve inicia r suas atividades e as principais ações a serem executadas são: Examinar Examin ar os objetivos do projeto e as restrições que impactam impacta m estes objetivos objet ivos;; Desenvolver uma estratégia de ações para alcançar os objetivos do projeto e os objetivos objet ivos dos envolvidos envolvidos e interessados, e que, ao mesmo tempo, considere as restrições; Constituir uma equipe equ ipe de projeto, identificar identificar os outros recurrecu rsos necessários e avaliar qual é a disponibilidade di sponibilidade de recursos humanos e materiais para a execução do projeto. •

•

•

Além destas atividades, o gerente de projetos deve sempre atuar de maneira manei ra bem próxima aos patrocinadores patroci nadores do projeto, deixando bem claros os principais objetivos: Objetivos Técnicos: o que será entregue tecnicamente; Objetivos de Prazo: qual o prazo estimado para se executar o projeto e para que o mesmo seja entregue com sucesso; Objetivos de Custo: qual é o custo estimado estim ado do projeto, com sua respectiva margem de erro; • •

•

•

Objetivos de escopo: o que se espera em termos de caracte-

rísticas e funcionalidades do projeto, ou seja, qual o produto ou serviço que será entregue no final do projeto. Para que um projeto tenha um bom início, ressalta-se que as principais características de um gerente de projetos são: ter atitude, ser responsável, ser honesto e cativador de sua plateia e equipe. Estas características devem ser muito bem observadas ao selecionar o gerente do projeto. Com isto, por consequência, há uma probabilidade maior de que todos os membros da equipe do projeto possam convergir para o caminho que o gerente de projetos direcionar, minimizando o risco de insucesso do projeto. Com a nomeação do gerente do projeto, este irá atuar no grupo de processos de iniciação. Para este grupo de processos podemos citar cinco pontos de grande importância, a saber: 1) Criação do Termo de Abertura do Projeto; 2) Criação de um plano de atividades para o projeto; 3) Definição dos recursos envolvidos por parte do cliente no projeto; 4) Apresentação da metodologia metodologia de gestão de projetos para os recursos do cliente; 5) Apresentação formal da abertura do projeto para os envolvidos. O primeiro ponto trata de um documento que formalmente autoriza o projeto e contém os requisitos iniciais que satisfazem satisfa zem as necessidades e expectativas das partes interessadas. O termo de abertura deve conter obrigatoriamente as necessidades do negócio, a descrição do escopo do produto ou serviço e o plane jamento estratégi estratégico co para o projeto projeto.. Este planejamen planejamento to estratégi estratégi-co do projeto deve dar suporte ao planejamento estratégico da empresa e deve ser considerado em todo e qua lquer momento do projeto, ou seja, o planejamento planeja mento estratégico do projeto deve ser desenvolvido pensando no planejamento estratégico da empresa de forma a garantir que a boa execução do projeto irá contribuirr para que o plano da empresa também seja cumprido contribui de forma eficiente. Logo, o planeja planejamento mento estratégico do projeto deve estar sempre à disposição dos stakeholders. sta keholders. Outro ponto a ser considerado é que no termo de abertura não se deve esquecer-se de fazer referência ao contrato que faz a ligação entre contratante e contratada para a execução formal do projeto. De forma mais simples, podemos pensar que para criar o termo de abertura do projeto, um dos principais documentos que darão suporte a ele é o contrato. Depois de desenvolver todas essas atividades, pensar em todos os aspectos supracitados, teremos a conclusão do termo de abertura consolidado c onsolidado em um documento contendo: Título do projeto: nome que será dado ao projeto; Missão do projeto: missão que o projeto deve cumprir; Propósito e justificativa do projeto: objetivos do projeto, qual o propósito dele para a companhia e as just ificativas para que ele seja executado; • Objetivos mensuráveis do projeto e critérios de sucesso relacionados: descrever os objetivos mensuráveis do projeto • • •

Edição 66 - Engenharia de Software Magazine

41

e quais os critérios e fatores de sucesso estão relacionados a cada um para que se possa fazer esta medida e comparação a qualquer momento; Requisitos básicos do projeto: definição de quais são os requisitos básicos para a execução do projeto; Descrição do projeto:  descrição de todos os itens que compõem o projeto; Riscos do projeto: documentação de todos os riscos do projeto, incluindo forma de combatê-los e até mesmo eliminá-los; Resumo de cronogramas e marcos do projeto:  deve-se apresentar um resumo do cronograma macro e os macros das pequenas entregas e validações que o projeto poderá sofrer; Resumo do orçamento do projeto:   descrição macro do orçamento aprovado para o projeto; •

•

•

•

•

Requisitos para aprovação do projeto e das etapas subsequentes: definição e descrição dos requisitos para aprovações •

durante todo o desenvolvimento do projeto; Gerente do projeto, responsabilidade e nível de autoridade designado: definição do gerente do projeto, suas responsabi•

lidades e nível de autoridade que foi designado a ele; Nome e autoridade do patrocinador do projeto, assim como a assinatura do mesmo no referido documento, dando início formalmente ao projeto; Identificação das partes interessadas: neste documento todas as partes interessadas e seus respectivos interesses devem estar devidamente documentados. •

•

O principal objetivo do termo de abertura do projeto é que este documento sirva como base para aprovação ou não do projeto. Sendo aprovado, o projeto torna-se oficialmente autorizado para ser iniciado. Neste momento os critérios para o sucesso do projeto também são definidos, a influência e os objetivos das partes interessadas são avaliados. Com isto, há uma definição clara se vai ser dado continuidade ao projeto, se ele vai ser interrompido ou suspenso. Logo, este documento deve estar assinado pelo gerente de projetos e também pelo patrocinador do projeto, no mínimo. No entanto, de uma forma geral, é uma boa prática envolver o cliente desde a iniciação, aumentando a probabilidade de sucesso, compartilhando melhor os riscos e objetivos do projeto. Além disso, a aceitação da entrega tende a ser mais fácil e a satisfação do cliente e das partes interessadas tende a aumentar. Tudo isto pelo simples fato deles terem participado de todo o projeto, desde o início. Durante todo o projeto, praticamente tudo relacionado a ele deve ser documentado e assinado por todas as partes interessadas. Em especial, no grupo de processos de iniciação, este cuidado deve ser ainda maior, para que o projeto seja bem iniciado e qualquer problema futuro que possa ocorrer seja resolvido com base em documentos previamente definidos. Desta forma, ao criar o termo de abertura do projeto, deve observar com clareza a descrição dos objetivos deste, inclusive os motivos que caracterizam o referido projeto como a melhor alternativa para a empresa.

42

Como parte do grupo de processos de iniciação, o gerente de projetos recebe a autoridade para aplicar recursos organizacionais às atividades subsequentes do projeto. Outra atividade inerente ao grupo de processos de iniciação é a criação do plano de atividades do projeto. Este documento nada mais é do que uma lista de todas as principais atividades que compõem o projeto. O plano de atividades deve descrever as macro at ividades, pois na próxima etapa do projeto, que engloba o grupo de processos de planejamento, será desenvolvido um documento que é o plano do projeto e nele, todo o escopo e todos os planos envolvidos no projeto estarão definidos minuciosamente. Assim, nesse documento não há necessidade de grande detalhamento e seu principal objetivo é apresentar aos stakeholders tudo o que será feito durante o projeto. Outro ponto importante é a definição dos recursos humanos envolvidos no projeto. Eles são de grande importância para que todas as atividades do projeto sejam realizadas. Podemos dizer que a identificação e nomeação das pessoas chave da empresa, que irão compor a equipe do projeto, é um dos principais fatores para que o projeto obtenha sucesso. Mas, como estas pessoas devem ser escolhidas? Elas devem ser selecionadas levando em consideração inúmeros fatores, dentre os quais podemos destacar: pró-atividade, conhecimento da área em que atua e nível de envolvimento com a empresa. No entanto, tais pré-requisitos não podem ser considerados como regra geral. Cada cliente pode definir os seu s próprios requisitos desejáveis para seleção de sua equipe, da melhor forma que lhes convier. Após a definição da equ ipe, é importante que o gerente de projetos avalie todos os integrantes e informe ao patrocinador do projeto se alguma pessoa selecionada pode gerar algum risco ao projeto. Tudo isto para que o projeto realmente tenha os melhores recursos, com a finalidade de minimizar os riscos e maximizar a possibilidade de sucesso. Para que todos os envolvidos no projeto tenham conhecimento da forma com a qual o mesmo será conduzido, deve-se fazer uma apresentação da metodologia de gestão do projeto. Assim, os stakeholders conhecerão todos os passos, além de saber a necessidade e importância da documentação, cronogramas e prazos. Durante a apresentação, o gerente do projeto pode conquistar e contagia r todas as par tes envolvidas no projeto, demonstrando toda sua competência para conduzir o projeto. Assim, o gerente do projeto pode conseguir gerar como resultado da apresentação, a garantia do controle do projeto, possuindo responsabilidade máxima sobre a condução do referido projeto, possuindo confiança dos stakeholders. A apresentação formal da abert ura do projeto também é um item que compõe o grupo de processos de iniciação. É o momento onde se apresenta todo o termo de abertu ra para os patrocinadores do projeto, ou seja, para o cl iente. Neste momento é que o termo de abertura é as sinado e o projeto tem a autorização para iniciar. Além disso, este momento é

Engenharia de Software Magazine - Desvendando o gerenciamento de projetos – Parte 3

PLANEJAMENTO

de grande importância para que qualquer desvio que possa ser diagnosticado no início do projeto seja sanado. Em suma, o grupo de processos de iniciação consiste nos processos realizados para executar as atividades inerentes ao início do projeto. Todas as atividades são de grande importância, haja vista que todo início de projeto deve ser documentado e assinado pelos stakeholders e sponsors. Em todo em qualquer projeto, podemos fazer uma comparação grosseira com a construção de uma casa. Toda construção inicialmente precisa de uma fundação, de uma base sólida, para que a construção tenha uma boa qualidade e que a casa tenha uma boa durabilidade. Se não for bem feita, no futuro a casa poderá apresentar problemas. Da mesma forma, em um projeto, o grupo de processos de iniciação não pode ser mal feito ou menosprezado. Apesar disso, vários gerentes de projeto “esquecem” este grupo de processos e já partem para o planejamento ou mesmo para a execução, o que é um erro gravíssimo. Nestes casos, a qualquer momento que se necessitar de algum documento anterior ao plano do projeto, o gerente não terá nada em mãos para recorrer. Os grupos de processos de gerenciamento de projetos geram uma série de documentos com a fina lidade de se documentar todas as atividades do projeto. O objetivo principal dos mesmos deve ser registrar todos os fatos e atividades dos projetos, unificando palavras e conceitos. Com isto, não haverá a possi bilidade de uma pessoa A imaginar uma coisa e uma pessoa B imaginar outra. Valerá o que está escrito, documentado. Além disso, não se deve esquecer em momento algum, em qualquer grupo de processos de gerenciamento de projetos, dos registros das atas das reuniões. Estes registros podem ser registrados em papel, e-mail, vídeos de apresentações, dentre outros, desde que documente quem estava presente e t ambém as aprovações, quando necessário. Para concluir, cabe reforçar que a cautela com os itens de todos os grupos de processos de gerenciamento do projeto deve ser imperativa. Mas o grupo de processos de iniciação deve receber um pouco mais de atenção, pois é o momento crucial do projeto. Portanto, atenção redobrada nas documentações.

Contratos bem elaborados, propostas comerciais claras, reuniões com as partes envolvidas, definição dos objetivos e orçamento do projeto são de g rande valia neste momento. Mesmo com toda esta atenção, não se pode esquecer também que um dos pontos principais que devem ser verificados e que afetam quase todos os projetos, principalmente neste momento de iniciação, é a falta de atitude do gerente de projetos. O gerente de projetos deve ter clareza e certeza de que quem domina o projeto é ele. Por mais que o cliente seja o suporte financeiro, quem domina o projeto é o gerente. Logo, ele deve possuir habilidades para negociar com o cliente e apresentar para ele com clareza todo e qualquer desvio logo que ele ocorrer para que impactos futuros sejam minimizados.

Links e Referências: MARTINS, J. C.C. Técnicas para Gerenciamento de Projetos de Software. 1ª. Edição – Editora Brasport, 2007. PMI. Um Guia do Conhecimento em Gerenciamento de Projetos. Guia PMBOK 4ª. Edição – EUA: Project Management Institute, 2008. VARGAS, Ricardo. Manual Prático do Plano de Projeto – Utilizando o PMBOK Guide – 4ª. Edição – Brasport, 2009. VIEIRA, Marconi. Gerenciamento de Projetos de Tecnologia da Informação – 2ª. Edição – Editora Elsevier, 2007. Site do PMI Brasil http://brasil.pmi.org/brazil/home.aspx

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Edição 66 - Engenharia de Software Magazine

43

Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Trabalhando com Engenharia de Requisitos Boas e más práticas

Fique por dentro: 

A

engenharia de requisitos é a disciplina que de fato tem a missão de ajudar a equipe de desenvolvimento a entender o software a ser elaborado. É a base sólida para se andar do projeto até a construção. Ela é constituída pelas fases apresentadas na Figura 1. São elas: Concepção:   fase inicial que define o escopo do problema de software; Elaboração:  fase em que os requisitos são refinados e modelados em cenários; Validação: a fase em que ocorre a validação dos requisitos, onde a equipe faz uma revisão dos mesmos, para que se tenha a certeza de que os requisitos foram elicitados de maneira não ambígua; Gerência de Requisitos: fase em que se controla, analisa e registra as mudanças de requisito, isto a fim de verificar os impactos das alterações no produto de software em desenvolvimento.

Este artigo é útil para que desenvolvedores de software conheçam medidas importantes que podem auxiliar todo o processo de desenvolvimento de software a partir do momento em que essas práticas ajudam na compreensão dos requisitos de software, dos solicitantes destes requisitos, da alteração dos mesmos, e dos principais problemas aos quais os requisitos de software estão sujeitos. Por fim, a maior utilidade está em prover a compressão sobre como se executar bem a fase de engenharia de requisitos.

•

•

Elaine G.M de Figueiredo [email protected]

Mestrado em Ciencias da Computanção com enfase em engenharia de software, pós graduação em gerência de projetos, oito anos de atuação na área de desenvolvimento e qualidade de software. Atualmente é gerente de projetos na multinacional espanhola Indra Company, membro colaborador do grupo de pesquisa “ASSERT – Advanced System and Software Engineering Research Technologies Lab” pela universidade federal de Pernambuco.

44

•

•

Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos

Requisitos: O necessário para entendê-los Um requisito é uma capacidade que o software deve possuir com a finalidade de resolver um problema do usuário. Os requisitos servem como especificação do que deve ser implementado no sistema. Os requisitos devem descrever uma facilidade para o usuário, uma propriedade ou uma restrição do sistema, ou ainda, uma restrição do processo de desenvolvimento do sistema.

ENGENHARIA

• Grau de impacto que a implementação de um requisito pode ter em relação à elaboração de um sistema; • O requisito pode impactar muito, pode impactar modera damente, ou ainda causar pouco impacto em um projeto de software. Este tipo de classificação é muito importante para deixar ciente toda a equipe de desenvolvimento, de quais requisitos podem trazer resultados desastrosos caso não sejam  bem gerenciados ou implementados; • Grau de prioridade que o requisito tem diante às necessi dades do cliente, um requisito pode ser altamente prioritário para o cliente, ou para o sistema, sua implementação e gestão devem ser muito bem elaboradas, caso contrário, a funcionalidade do sistema será deficitária. Um requisito também pode ter prioridade média ou baixa. Figura 1. Engenharia de Requisitos.

Os requisitos de software são de três tipos: Requisitos funcionais: são requisitos que descrevem uma ação que o software deve ser capaz de realizar; Requisitos não funcionais: são requisitos que tratam das restrições do software visando sempre a qualidade, ou seja, é uma qualidade que o software deve possuir durante a sua execução; Requisitos inversos: são requisitos que definem o que nunca deve ocorrer durante a execução do software; •

•

•

Os requisitos funcionais são de dois tipos: Requisitos estáveis: requisitos que não são alterados ou modificados com frequência, sua alteração é algo excepcional; Requisitos voláteis: são requisitos que vivem em constante modificação, eles podem ser divididos em quatro categorias: compatíveis, mutáveis, emergentes e consequentes. •

•

Este entendimento sobre a classificação dos requisitos é importante, pois ao identificar os tipos de requisitos, as equipes podem organizá-los em grupos, e conhecê-los melhor, o que torna mais fácil o controle sobre as mudanças e, como consequência, o gerenciamento. Assim, como veremos, a classificação dos requisitos é a primeira boa prática a ser seguida logo no início do projeto. O estabelecimento de tipos diferentes de requisitos em um projeto ajuda a equipe a classificar os pedidos de alterações e a se comunicar mais claramente e firmemente com os clientes, portanto, a classificação já proporciona um entendimento e planejamento mais consistente sobre o que será implementado e em qual ordem. Os requisitos de um software são sistemáticos, ou seja, é algo em que suas propriedades são conhecidas, mas que também são suscetíveis às mudanças. O Rational Software Corporation (RUP) oferece bons esclarecimentos que justificam a complexidade dos requisitos de software, estes esclarecimentos foram pontuados a seguir, os mesmos auxiliam no exercício de más práticas: Os requisitos podem vir de várias fontes e nem sempre são óbvios; • Expressar os requisitos em palavras não é tão fácil; • Existem níveis de detalhes para cada requisito; • O número de requisitos pode prejudicar a gerência de requi sitos, se não for controlado; • Cada requisito é único; • Os requisitos mudam. •

Os requisitos ainda podem ser divididos em outra categoria, se vistos pelo aspecto da implementação: Requisitos do cliente, ou requisitos de alto nível: são aqueles expostos pelo cliente em linguagem natural, ou ainda em forma de desenhos ou casos de uso, qualquer técnica que facilite o entendimento. O importante é que esses requisito se caracterizam por dizer apenas aquilo que o usuário ou cliente quer que o sistema faça, não há a preocupação de como aquela funcionalidade será implementada; Requisitos do sistema, ou requisitos de baixo nível: são requisitos mais detalhados, que relatam não só o que deve ser implementado, mas como deve ser implementado, eles fazem restrições a aspectos de implementação e arquitetura, possuem detalhes que geralmente são obscuros para o cliente, mas que certamente os desenvolvedores conhecem bem. •

•

Olhando por um aspecto mais ligado a gerência, outras duas classificações podem ser ofertadas aos requisitos, elas foram relatadas por Spence (2000), e são pontuadas a segu ir:

Após a explanação anterior, é importante exibir as má s práticas. Vale frisar que mais importante do que entender o que deve ser feito como boas práticas em um process o é entender o que não deve ser feito, bem como as armadilhas preparadas para provocar os erros.

Más práticas De forma direta e objetiva, segue o que não deve ser adotado em processos de software na fase de engenharia de requisitos: 1. Não corrigir erros e inconsistências em requisito durante sua análise, ou fase de elaboração; Edição 66 - Engenharia de Software Magazine

45

2. Não entender que os clientes e usuários finais do software costumam evoluir sua compreensão sobre o que desejam com o passar do tempo. Nem tão pouco se preparar pa ra este fato; 3. Provocar problemas técnicos e principalmente alterações  bruscas de custo ou cronograma, isto acarreta mudança nos requisitos que podem ser impactantes para o produto; 4. Não conhecer o cliente e o usuário final da aplicação; 5. Não se preparar para as mudanças no ambiente em que o software será implementado; 6. Ofertar as tarefas de requisitos para um profissional que não tem talento e principalmente apreço pela engenharia de requisitos; 7. Desconhecer o negócio e a finalidade da instituição que está propondo o software a ser desenvolvido; 8. Não fazer a modelagem de negócio (regras de negócio) antes de iniciar a engenharia de requisitos. 9. Não adotar uma linguagem familiar com os clientes e solicitantes dos requisitos; 10. Ofertar uma solução ao invés de se entender e registrar as necessidades e problemas dos solicitantes de requisitos; 11. Não controlar a quantidade de requisitos solicitados, e nem dividir esses requisitos em grupos de implementação; 12. Não relacionar os requisitos entre sim, e entre os produtos do processo de desenvolvimento de software; 13. Estimar mal a quantidade de recursos humanos necessários para controlar as mudanças nos requisitos; 14. Falta de habilidade para manter os documentos de requisitos consistentes; 15. Ouvir muitos solicitantes de requisitos sem selecionar previamente os que mais entendem do negócio; 16. Não exibir para os interessados os requisitos em prototipações gráficas.

3. Fazer o levantamento das necessidades dos envolvidos em pelo menos cinco áreas importantes para o sistema: funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade; 4. Identificar membros da equipe que serão coautores e contri buirão para a formulação de um ou mais tipos de requisitos; 5. Decidir qual rastreabilidade de requisitos será necessá ria. A rastreabilidade de requisitos é o mecanismo mais eficiente de auxílio à gerência de requisitos, ela é responsável pela manutenção das modificações nos relacionamentos entre objetos e requisitos. Tal rastreabilidade pode ser feita por meio de uma matriz. Com a rastreabilidade é possível ter visibilidade das consequências da alteração de um requisito; 6. Desenvolver uma Matriz de Rastreabilidade de Requisitos. A matriz é uma das formas mais usuais de se apresentar e estabelecer a rastreabilidade de requisitos, é ela que provê a visualização dos relacionamentos entre os objetos, ou artefatos de um projeto de software. A Matriz de Rastreabilidade é um recurso útil dentro da gerência de requisitos, seu uso é extremamente recomendado pelos programas de melhoria de desenvolvimento de software. Um modelo de matriz é representado na Tabela 1; 7. Criar relatórios de progresso e ‘status’ da matriz de rastreabilidade e dos requisitos, para que a equipe desenvolvedora entenda o impacto da alteração de um requisito;

Boas práticas

8. A equipe responsável pela engenharia de requisitos deve receber todas as solicitações de alteração nos requisitos por um formulário próprio, ou por um sistema automatizado, bem como as solicitações de adição de novos requisitos; 9. Aprovar os requisitos com o cliente, usuários e demais solicitantes, isto dará oportunidade de conhecer requisitos errôneos e corrigi-los prematuramente; 10. Efetuar revisões em planos e produtos de trabalho visando identificar e corrigir inconsistências em relação aos requisitos; 11. Deve-se eleger um gerente de requisitos que deve avaliar o impacto das modificações solicitadas nos requisitos, e em tudo que está relacionado a eles; 12. Deve ser mantido um histórico de alterações para cada requisito; 13. Toda modificação em requisito deve ser comunicada aos envolvidos, devido aos impactos em potencial; 14. Uma coleta periódica das métricas deve ser feita para melhor acompanhamento da gerência de requisitos. As métrica s darão visibilidade da quantidade de alterações feitas e de que natureza elas são. Isto contribui para que a equ ipe saiba o que esperar em projetos futuros com requisitos semelhantes.

Para se conhecer e definir quais as boas práticas a serem aplicadas na engenharia de requisitos é interessante formular uma política de engenharia de requisitos. Tal política deve explicar os objetivos dos processos definidos para engenha ria de requisitos de forma clara aos envolvidos no projeto. Além disso, deve levar em conta os padrões organizacionais, as regras de negócio da organização, e as características de cada projeto, além das aptidões de cada profissional da equipe. Por si só, tal política já se caracteriza como uma boa prática. Uma forte recomendação dentro da engenharia de requisitos é passar a ideia de que requisitos nunca podem ser congelados, e dificilmente serão em algum projeto. Sendo assim, outra boa prática é aplicar o gerenciamento de requisitos com o protocolo que deve ser seguido neste gerenciamento, pois a ta refa de se gerenciar requisitos pode ser extremamente burocrática, sem necessariamente agregar valor à engenharia de requisitos e ao processo de software. Outras boas práticas são: 1. Concordar com um vocabulário comum para o projeto; 2. Descreve de forma clara e objetiva o problema a ser resolvido pelo sistema, bem como de seus recursos principais;

46

Projeto - Matiz de Rastreabilidade Requisito

Documento Fonte

Arquitetura Componente

Caso de Teste

Tabela 1. Exemplo de Matriz de Rastreabilidade

Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos

ENGENHARIA

Em relação ao último tópico, a importância de se ter uma métrica se deve ao fato do gerente de requi sitos poder ter o percentual de requisitos alterados, incluídos ou excluídos, dentro de um determinado período de tempo. Isto poderá dar maior poder estratégico para os próximos projetos de software, onde o gerente poderá saber exatamente em que período ocorre maior modificação nos requisitos. É importante salientar que muitos dos tópicos acima estão relacionados à alteração de requisitos. Assim é relativamente fácil notar que a fase de gerência de requisitos é uma das mais importantes dentro da engenharia. Para a gerência de requisitos todas as mudanças precisam ser identificadas, avaliadas, documentadas, comunicadas e acompanhadas até sua finalização. É o que defende o CMMI. Quando uma mudança ocorre, primeiramente deve-se ana lisar o requisito que está ligado àquela mudança, verificar a prioridade dele, as quais outros artefatos o requisito está ligado, verificar o impacto sobre estes artefatos; deve-se verificar também se o requisito é próprio do cliente ou do sistema, se é volátil, ou seja, se já se esperava esta solicitação de mudança, e qual a situação atual do requisito dentro do processo, enfim, deve-se tratar esta mudança a começar do reconhecimento do requisito. Oberg (2002) escreveu que uma indústria americana formulou um estudo publicado na conferência internacional de requ isitos, este estudo apontava que 76% de um total de 500 gerentes de TI nos Estados Unidos e no Reino Unido entrevistados, já tinham tido falhas em projetos inteiros durante suas carreiras. A causa mais frequentemente apontada como falha dos projetos foi a alteração de requisitos. Atualmente, este percentual deve ter pelo menos duplicado, não só pelo aumento no número de sistemas implementados, mas também pelo aumento da complexidade nas relações e regras de negócios. A gerência de requisitos é fu ndamental para o controle de mudanças dos requisitos, pois estes seguem evoluindo com o passar do tempo, já que estão inseridos em um ambiente real que muda com o tempo. A rastreabilidade de requi sitos contribui para a previsão do impacto que as mudanças dos requisitos causarão no projeto de software, sendo assim, a gerência de requisitos pode contribuir para a garantia da qualidade do sistema. A gerência de requisitos se restringe aos seguintes aspectos: Gerenciar mudanças em requisitos existentes; Gerenciar relacionamento entre os requisitos; Gerenciar dependências entre os produtos de trabalho durante o desenvolvimento de software. • • •

Para que a gerência desenvolva seu papel de forma satisfatória, é necessário de antemão, definir novamente um conjunto de políticas. Estas políticas devem explicar os objetivos dos processos definidos de forma clara aos envolvidos no projeto. E deve levar em conta os padrões organizacionais, as regras de negócio da organização, e as características de cada projeto, além das aptidões de cada profissional da equipe.

Tudo na gerência de requisitos parte da ideia de que requisitos nunca podem ser congelados, e dificilmente serão em algum projeto. Sendo assim, para que a gerência de requisitos cumpra sua missão é necessário que ela desenvolva algumas boas práticas, como: ter um modelo para rastrear requ isitos, inclusive com a utilização de ferramentas que façam rastreabilidade. Definir um modelo de rastreabilidade de requisitos para um projeto depende de muitos fatores, o primeiro deles é o software que está sendo construído. Projetos com relativa estabilidade costumam ter os requisitos alterados na ordem de 1% ao mês. Portanto, observar as características do sistema é algo que não se pode omitir (mais uma boa prática agregada). Deste modo, fica evidente que um modelo de rastreabilidade sempre é único e distinto de qualquer outro. Um modelo de rastreabilidade inicia suas boas práticas selecionando os requisitos que devem ser rastreados. Rastrear muitos requisitos é uma tarefa burocrática e difícil, que pode agregar atrasos e erros ao analista de requisitos. Ademais, nem todo requisito, depende da sua classificação, necessita ser rastreado. Outra boa prática dentro da rastreabilidade de requisitos esta belece que é necessário verificar (selecionar) as ferramentas de rastreabilidade que apoiarão de forma mais eficaz o processo de rastreabilidade de requisitos, é necessário ainda treinar a equipe para o uso da ferramenta. É sadio ainda definir os momentos de registro e de controle da rastreabilidade, isto pode ocorrer no momento de fechamento de fases, por exemplo: efetuar rastreabilidade na finalização da etapa de análise e projeto, e na finalização da etapa de codificação. Não se pode esquecer que requisitos mudam a todo o momento e podem impactar mudanças em todos os artefatos de software. Os pontos citados nos três parágrafos acima são os mais relevantes, sendo que o primeiro é mais ainda, visto que não é todo requisito que é passível de rastrear. Deve-se fazer um catálogo, e observar através das questões a seguir, se no requisito elicitado pode-se descobrir as informações exigidas nas questões. Se o requisito atender a todas, possivelmente ele será candidato à rastreabilidade. As questões são pontuadas a seguir: • Deve-se saber quem geriu o requisito; • Saber o porquê da sua existência; • Saber quais outros requisitos estão relacionados ao requisito elicitado; • Como o requisito elicitado se relaciona com o sistema a s er implementado; • Que documentações do processo de software podem ser afetadas pela modificação do requisito. Após obter respostas a essas questões, em relação aos requisitos, devem-se saber os objetos a serem monitorados, bem como, os tipos de rastreabilidade que serão efetuadas, a lém de estabelecer corretamente o tipo de ligação que será gerenciada nesta matriz, isto dependerá exclusivamente da característica dos objetos (produtos de software), dos processos de software utilizados pela organização, e dos prazos e custos do projeto Edição 66 - Engenharia de Software Magazine

47

em questão. Executando essas ações, é mais fácil fazer da rastreabilidade, uma tarefa que demande um trabalho pouco oneroso e com garantias na finalização. Também é importante saber o grau de instabilidade dos requisitos. Ou seja, se são requisitos voláteis. Deve-se saber, ou pelo menos deduzir, com que frequência eles podem vir a se modificar. Conhecer a instabilidade dos requisitos do software a ser desenvolvido é algo que também facilita o estabelecimento de uma matriz de rastreabilidade, visto que, alguns sistemas possuem requisitos funcionais que são pouco voláteis, onde os fatores que podem ocasionar mudanças existem, mas não são constantes, não provocam muitas variações. Esses sistemas desenvolvem uma matriz relativamente simples, com poucos requisitos, ou com requisitos que não são tão voláteis. Neste caso, o gerenciamento é facilitado e pode-se usar até mesmo uma planilha eletrônica como ferramenta. Vale salientar que se faz necessário a determinação de um modelo de matriz de rastreabilidade para todo software que será construído. Aliás, todo sistema deve fazer uso da rastrea bilidade de requisitos, mesmo os mais estáveis. Os sistemas que necessitam de mais atenção na elaboração da matriz possuem o seguinte perfil: • Aplicações para Internet, onde modificações surgem a todo o momento em várias etapas; • Sistemas em que a equipe desenvolvedora geralmente possui prazos relativamente curtos para o desenvolvimento; • Aplicações que possuem seus requisitos em constante evolução. Após a definição do modelo, alguns outros aspectos, em relação ao desenvolvimento da rastreabilidade devem ser levados em consideração: • Durante o processo de desenvolvimento da rastreabilidade, os elos (relacionamento entre os requisitos e os objetos de software) devem ser monitorados, pois eles também sofrem modificações, por exemplo: um elo que antes era de satisfação passa a ser de dependência, para isso, basta que o objeto a que ele esteja ligado sofra alguma alteração; • Conscientizar a equipe da importância do processo de ras treabilidade, evidenciar que a rastreabilidade de requisitos é sim um fator de sucesso para a agilidade do processo e para o tratamento das mudanças, e isto impacta diretamente em tempo e custo; • Após o término do projeto, analisar e avaliar criticamente a eficiência e eficácia do processo de rastreabilidade, verificando os pontos positivos e os que necessitam de melhorias. O esforço da equipe, o controle sobre as informações manipuladas, e as lições aprendidas devem ser considerados.

48

Após os conceitos que já foram repassados sobre a técn ica de rastreabilidade, é possível notar que a gerência de requisitos contribui muito para o tratamento de riscos do projeto de software. 80% dos riscos em projetos de soft ware são oriundos da evolução dos requisitos. Tal gerência é um processo chave ao processo de gerência de software, pois a sua correta execução pode mostrar ao gerente de projetos os problemas que o desenvolvimento de software poderá enfrentar futuramente. Percebeu-se até agora, que a gerência de requisitos, ao contrário de outros processos que podem ser gerenciados dentro de um único grupo de negócios, pode envolver qualquer variável, ambiente, grupo de pessoas, ou processo, que possam contribuir com o seu desenvolvimento. Este gerenciamento inclui as pessoas envolvidas com a elicitação de requisitos, e também com a definição dos testes pelo qual o sistema irá passar. Gerentes de desenvolvimento, de qualidade, analistas, engenheiros, clientes, podem e devem participar do processo de gerência de requisitos. Apesar da importância discutida neste artigo, a engenharia de requisitos na prática ainda é pouco utilizada em muitos ciclos de desenvolvimento. Isto se deve ao fato de muito dos processos que compõem esta engenharia serem feitos de forma  burocratizada. Um desafio para os executores dos processos e tarefas relacionados aos requisitos é prover soluções práticas e técnicas ágeis a tais processos. Links e Referências: 1. Alves, S. R. e Alves, L. A. (2009), Engenharia de Requisitos em Métodos Ágeis. 2. Cohn, M. (2004) User Stories Applied For Agile Software Development. Addison Wesley, Kent Beck, p. 17-29 . 3. d’Amorim, F. R. S. (2008), Engenharia de Requisitos para Métodos Ágeis. Os Processos Típicos da Engenharia de Requisitos http://www.choose.com.br/infochoose/artigos

Requirements Engineering Laboratory http://www.cin.ufpe.br/~ler/index.php

Traceability Strategies for Managing Requirements With Use Cases. SPENCE, Ian; PROBASCO, Leslee. http://www.embeddedstar.com/technicalpapers/content/t/embedded818.html 

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Engenharia de Software Magazine - Trabalhando com Engenharia de Requisitos

Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Especificando casos de uso eficazes Conheça algumas boas práticas

Cenário: 

ESTE ARTIGO É DO TIPO MENTORING SAIBA MAIS: WWW.DEVMEDIA.COM.BR /MENTORING -SAIBAMAIS

U

Rodrigo Oliveira Spínola [email protected]

Editor Chefe – Engenharia de Software Magazine

m questionamento comum que muitos profissionais fazem ao iniciar os trabalhos na área de requisitos é se existe um formato de descrição de casos de uso a ser seguido. Em bora exista uma definição de estrutura  bastante difundida baseada no modelo de documento de caso de uso proposto pelo RUP (Rational Unified Process), não existe uma regra sobre como eles devem ser descritos. Na verdade, a prática da escrita de casos de uso varia de empresa para a empresa e cada cenário deve ser respeitado. Se um determinado formato funciona adequadamente para a empresa X, é por que ele contem o conjunto de

Requisitos são a base para diferentes etapas do desenvolvimento de um software. Isto faz deles um fator decisivo para o sucesso do pro jeto. Neste artigo partiremos de um exemplo comum de ser encontrado em sistemas de informação - uma consulta seguida da exclusão de itens cadastrados - e aprimoraremos a especificação realizada inicialmente, considerada equivocada, no sentido de torná-la mais completa para que outros membros da equipe de desenvolvimento possam trabalhar de forma mais eficiente.

informações necessárias para que os demais membros da equipe de desenvolvimento desempenhem de forma satisfatória suas atividades. Contudo, mesmo este formato funcionando adequadamente em uma empresa, isso não quer dizer que ele possa ser utilizado de forma satisfatória por outra organização. Maiores ou menores níveis de detalhamento na descrição podem ser necessários. Enfim, não há uma regra. Entretanto, um conjunto de boas práticas tem sido

Edição 66 - Engenharia de Software Magazine

49

percebido ao longo dos anos e que, se consideradas, podem contribuir positivamente para que a especificação do caso de uso seja realizada de forma mais satisfatória. Satisfatória neste caso significa poder ser utilizada por outros membros da equipe de desenvolvimento (testadores, projetistas e desenvolvedores, por exemplo) sem a necessidade de novas intervenções na especificação para que ela possa ser mais bem compreendida. Neste cenário, partiremos de uma especificação de caso de uso simplificada para um requisito de consulta e exclusão de itens cadastrados. Esta versão simplificada será aprimorada aos poucos considerando um conjunto de boas práticas. Ao final, teremos uma especificação bem definida e que irá considerar várias das práticas que têm sido adotadas por equipes de desenvolvimento de software.

Cenário utilizado Para ilustrar o uso de boas práticas na descrição de um caso de uso, partiremos do seguinte requisito funcional: o software deve permitir que funcionários efetuem buscas por itens cadastrados e, uma vez retornado o resultado da busca, itens possam ser excluídos. A partir deste requisito funcional,  busca-se detalhar sua descrição de forma que outros membros da equipe de desenvolvimento possam realizar suas atividades como projetar o software, planejar os testes e codificar o produto. A Tabela 1 apresenta uma possível versão simplificada (que não considera o conjunto de boas práticas descritas na próxima seção) deste caso de uso. Observe que esta versão apresenta vários problemas associados a itens que precisam estar presentes numa descrição de caso de uso como: • Campos a serem preenchidos; • Fluxos alternativos; • Fluxos de exceção; • Opções presentes na tela. Objetivo: Atores:

Permitir que itens fossem procurados e excluídos do sistema. Funcionário 1. O ator seleciona a opção Buscar Itens 2. O sistema apresenta tela de busca 3. O ator informa os dados do filtro e seleciona a opção buscar

Fluxo Principal:

4. O sistema apresenta os itens recuperados 5. O ator seleciona os itens que deseja excluir e seleciona a opção

excluir 6. O sistema exclui os itens selecionados

Fluxo Alternativo:

-

Fluxo de Exceção:

-

Regras de negócio:

[RN1] Apenas itens cujo status seja igual a “Pendentes” podem ser excluídos

utilizada pela equipe de desenvolvimento. A partir de agora veremos como corrigir os problemas presentes nesta especificação através da aplicação de um conjunto de boas práticas.

Boas práticas aplicadas ao caso de uso O conjunto de boas práticas apresentadas neste artigo está organizado em três grupos: Navegação: boas práticas que dizem respeito à definição de informações na descrição de caso de uso que permitam ao desenvolvedor entender como será a interação do usuário com o sistema; • Campos: boas práticas que dizem respeito à definição de informações que permitam o correto entendimento sobre as informações manipuladas pelo sistema, assim como suas propriedades como formatos e obrigatoriedade; • Regras de Negócio: boas práticas relacionadas a preocupa ções que devem ser consideradas quando se estiver defin indo as regras de negócio associadas ao caso de uso. •

Para o grupo navegação , as boas práticas consideradas serão: 1. Definir explicitamente os diferentes fluxos de uso do software nos casos de uso; 2. Definir explicitamente condições de entrada para cada um dos fluxos; 3. Definir explicitamente o “ponto” em que o software estará ao sair de cada fluxo; Os resultados da aplicação dessas práticas na especificação do caso de uso apresentada na Tabela 1  podem ser observados na Tabela 2. As linhas em vermelho representam as informações que foram acrescentadas à especificação inicial. Observe que acrescentamos um conjunto de informações que permitem agora, à equipe de desenvolvimento, entender como se dá a interação entre o ator e o sistema para realização da funcionalidade. Contudo, ainda não temos nenhuma informação sobre as informações manipuladas pela funcionalidade. É sobre isso que falaremos a partir de agora. Para o grupo campos , as boas práticas consideradas serão: 1. Definir explicitamente os diferentes campos que são apresentados em cada passo do caso de uso; 2. Definir explicitamente a obrigatoriedade dos campos; 3. Definir explicitamente se os campos são editáveis ou somente leitura; 4. Caso o campo contenha uma lista de opções fixa, definir explicitamente as opções disponíveis; 5. Caso o campo possua um comportamento diferenciado, definir este comportamento explicitamente através de uma regra de negócio.

Tabela 1. Caso de uso Excluir Itens Cadastrados – Versão com Problemas

Podemos afirmar que por conta do conjunto de omissões encontradas na especificação, ela está  mal elaborada , necessitando que ajustes sejam realizados de forma que ela possa ser

50

Os resultados da aplicação dessas práticas na especificação do caso de uso apresentada na Tabela 2 podem ser observados na Tabela 3. As linhas em vermelho representam as informações que foram acrescentadas. Observe que foi adicionado um

Engenharia de Software Magazine - Especificando casos de uso eficazes

ENGENHARIA

Objetivo: Atores:

Permitir que itens fossem procurados e excluídos do sistema. Funcionário

Condição de Entrada O ator seleciona a opção Buscar Itens

Objetivo:

Permitir que itens fossem procurados e excluídos do sistema.

Atores:

Funcionário

Condição de Entrada O ator seleciona a opção Buscar Itens

1. O sistema apresenta tela de busca 2. O sistema apresenta ao final as opções Buscar e Cancelar

1. O sistema apresenta tela de busca contendo as informações [RN2]

3. O ator informa os dados do filtro e seleciona a opção buscar [A01]

- Nome (campo editável) - Status (contendo as seguintes opções: Pendente, Confirmado, Todos) (campo editável) 2. O sistema apresenta ao final as opções Buscar e Cancelar

[RN3]:

4. O sistema apresenta os itens recuperados

Fluxo Principal:

Fluxo Alternativo:

Fluxo de Exceção:

5. O sistema apresenta ao final as opções Excluir e Voltar

6. O ator seleciona os itens que deseja excluir e seleciona a opção excluir [A02] [RN1] [EX01] 7. O sistema exclui os itens selecionados 8. O sistema retorna para a tela i nicial 9. O caso de uso é encerrado [A1] O ator seleciona a opção Cancelar 1. O sistema retorna para a tela i nicial 2. O caso de uso é encerrado

3. O ator informa os dados do filtro e seleciona a opção buscar [A01] 4. O sistema apresenta para cada item recuperado as seguintes

informações: - Opção de seleção (campo editável) - Nome (somente leitura) - Descrição (somente leitura) - Status (somente leitura)

Fluxo Principal:

[A2] O ator seleciona a opção Voltar

5. O sistema apresenta ao final as opções Excluir e Voltar

1. O sistema retorna ao passo 4 do fluxo principal

6. O ator seleciona os itens que deseja excluir e seleciona a opção excluir [A02] [RN1] [EX01] 7. O sistema exclui os itens selecionados 8. O sistema retorna para a tela i nicial 9. O caso de uso é encerrado [A1] O ator seleciona a opção Cancelar 1. O sistema retorna para a tela i nicial 2. O caso de uso é encerrado

[E1] Item não pode ser excluído 1. O sistema apresenta mensagem indicando quais itens não podem ser excluídos 2. O sistema apresenta ao final a opção OK 3. O ator seleciona a opção OK 4. O sistema retorna ao passo 4 do fluxo principal.

Regras de negócio:

[RN1] Apenas itens cujo status seja igual a “Pendentes” podem ser excluídos

Fluxo Alternativo:

[A2] O ator seleciona a opção Voltar 1. O sistema retorna ao passo 4 do fluxo principal

Tabela 2. Caso de uso Excluir Itens Cadastrados – Práticas do Grupo Navegação Aplicadas

conjunto de informações que permitem agora entender quais informações são manipuladas e quais as restrições de seu uso. Além disso, essa definição permitiu à equipe de desenvolvimento definir mais duas regras de negócio associadas aos campos Nome e Status da tela de busca. Neste momento já temos uma descrição de casos de uso bem definida. Apresentaremos agora o último grupo: Regras de Negócio. Para este grupo, podemos considerar as seguintes  boas práticas: 1. Caso a regra seja de difícil entendimento, complementar sua descrição através de um exemplo. Esta última boa prática não se aplica ao nosso exemplo, contudo, é importante estar atento a ela. Lembre-se, a regra será utilizada por outros membros da equipe de desenvolvimento, e não apenas pela equipe de analistas de requisitos que, por interagir diretamente com o cliente, tem um conhecimento mais completo do negócio que está sendo mapeado. Concluindo, é importante estar atento ao fato de que estas práticas podem ou não ser adequadas às necessidades de sua organização. É importante lembrar também que o conjunto apresentado não é e nem pretende ser uma lista final de  boas práticas. Outras certamente existem e quase sempre são provenientes da experiência de analistas nos projetos que participa.

Fluxo de Exceção:

[E1] Item não pode ser excluído 1. O sistema apresenta mensagem indicando quais itens não podem ser excluídos 2. O sistema apresenta ao final a opção OK 3. O ator seleciona a opção OK 4. O sistema retorna ao passo 4 do fluxo principal.

Regras de negócio:

[RN1] Apenas itens cujo status seja igual a “Pendentes” podem ser excluídos [RN2] O campo nome é opcional. [RN3] O campo Status vem com a opção Todos selecionados como

padrão. Tabela 3. Caso de uso Excluir Itens Cadastrados – Práticas do Grupo Campos Aplicadas

Referências: Alves, S. R. e Alves, L. A. (2009), Engenharia de Requisitos em Métodos Ágeis.

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Edição 66 - Engenharia de Software Magazine

51

Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros

Gestão de Regras de Negócios Marco Ikuro Hisatomi [email protected]

Possui graduação em Tecnologia em Processamento de Dados pela UEM, especialista em Desenvolvimento Gerencial e Gestão da Qualidade pela FECEA. Mais de 27 anos de vivência em desenvolvimento de software e gerenciamento de projetos, engenharia de Software, engenharia de testes, fábrica de software, em pequeno e grande porte. Professor em cursos de graduação desde 2004.

Anderson de Souza Góes

Fique por dentro:  Um desafio no desenvolvimento de software sempre foi atender às necessidades dos usuários finais, com maior precisão e rapidez em níveis operacionais e estratégicos da organização. Ainda, a complexidade tem crescido rapidamente em função das fortes demandas por sistemas que exigem integrações com outros sistemas. Os fatores que exigem maior gerenciamento no desenvolvimento de software estão nas diversas plataformas tecnológicas, multidisciplinaridade demandadas no desenvolvimento de software e

profissionais formados em diferentes universidades. Este artigo tem como finalidade a implantação de um modelo de gestão de regras de negócios paralelamente à gestão do desenvolvimento de software, ofertando uma visão transparente aos usuários finais quanto aos processos de seus negócios. Através deste modelo de gestão de requisitos, é possível efetuar a gestão das regras de negócios com foco na garantia da qualidade e integralidade das implementações destas regras no software, alinhadas aos processos de negócios da organização.

[email protected]

Graduado em Ciência da Computação pela Universidade Estadual de Londrina - UEL (2011). Atualmente é aluno regular pela mesma instituição. Tem experiência na área de Ciência da Computação com ênfase em Sistemas da Informação e Engenharia de Software.

Rodolfo Mirando de Barros [email protected] 

Rodolfo Miranda de Barros é graduado em Ciência da Computação pela Universidade Federal de São Carlos (UFSCar) e em Administração de Empresas pela Universidade Estadual de Londrina (UEL). Concluiu o mestrado em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (UFRGS) em 1997 e o doutorado em Engenharia Elétrica pela Universidade Estadual de Campinas (UNICAMP) em 2008.

52

A

gestão da informação requer uma disciplina de execução dos procedimentos bem definidos. Existem várias fontes de informações e também inúmeras formas de expressar a mesma informação [1]. E por estes motivos é que softwares nem sempre possuem as funcionalidades de acordo com as regras de negócios da organização patrocinadora do projeto de desenvolvimento. Através de um modelo de gestão das regras de negócios, desde sua formalização até a validação de aplicabilidade,

Engenharia de Software Magazine - Gestão de Regras de Negócios

a proposta está na melhoria da gestão do conhecimento. A partir de problemas evidenciados no processo de desenvolvimento de software e perda de informações, algumas análises estão sendo formalizadas, como base para demonstrar as melhorias que são possibilitadas com o uso deste modelo. Num formato mais próximo da realidade do usuário e dos procedimentos da empresa na qual a regra é aplicada, esta definição reflete exatamente os passos a serem seguidos para alcançar os resultados esperados pela empresa. A partir das

BOAS PRÁTICAS

Figura 1. Metodologia de pesquisa. Fonte: adaptada de [2]

regras de negócios consistentes às necessidades da empresa, inicia-se o processo de desenvolvimento do software, através das técnicas e metodologias escolhidas para o projeto. A diferença fundamental em ter a gestão das regras de negócios segregadas da gestão de requisitos está na possibilidade da avaliação do próprio usuário, de que suas regras foram integralmente implementadas no software desenvolvido. Neste artigo, o modelo da gestão das regras de negócios está complementado com os princípios da transdisciplinaridade entre a comunicação, a colaboração e a agilidade na gestão do conhecimento [2]. Tendo como foco a participação ativa dos envolvidos e responsáveis pela informação que deve estar atualizada; obtendo resultados muito maiores que uma simples somatória dos conhecimentos catalogados.

Metodologia seguida e outras abordagens Nesta seção, com a finalidade de estruturar o artigo e fornecer os subsídios necessários para a sua construção, será apresentada a metodologia de pesquisa utilizada para seu desenvolvimento. Para finalizar, serão apresentados os estudos mais recentes relacionados ao gerenciamento de regras de negócio no processo de desenvolvimento de software.

 Metodologia de Pesquisa O desenvolvimento do modelo da gestão de regras de negócio foi aplicado com base na organização GAIA que tem como ob jetivo o desenvolvimento de software. Baseado na metodologia

em uso para a avaliação de processos do desenvolvimento de software foi aplicado, neste trabalho, um modelo de avaliação genérico para o desenvolvimento de artigos. Foram seguidas atividades de acordo com as três etapas: Análise Teórica, Desenvolvimento e Avaliação. Em princípio, os trabalhos pesquisados foram planejados por ano de publicação e assunto relacionados à gestão do conhecimento com foco nas regras de negócios. Especificamente limitados a três anos, a partir de 2010, para os periódicos e livros de autores com histórico em Engenhar ia de Software e Qualidade no Processo de Desenvolvimento de Software. Dentre os assuntos relacionados à gestão do conhecimento, com foco no desenvolvimento de software, foram esc olhidos a gestão de regra de negócio, gestão da regra de requisitos, avaliação de requisitos implementados e avaliação das regras de negócios atendidas por aplicativos de software. Para melhor compreensão, as atividades executadas foram ilust radas pela Figura 1. Na primeira etapa, são executadas duas macro atividades, sendo a Fundamentação Teórica (1), relacionados à pesquisa em artigos publicados. Esta tem como origem a busc a em base de dados para referências e estudos desenvolvidos no segmento de desenvolvimento de software e gestão de regras de negócios. Em consequência da pesquisa, é elaborada a tabela comparativa dos principais artigos que trataram de forma explícita os assuntos. Edição 66 - Engenharia de Software Magazine

53

A etapa intermediária, de Desenvolvimento (2), que também contempla a consolidação do modelo de gestão da regra de negócios, são cumpridas com quatro macro atividades: Elaboração do modelo de gestão da regra de negócio e Consolidação do modelo de Gestão da Regra de Negócio; sendo que as atividades Estabelece critério de avaliação e Aplicação do modelo são compartilhadas com a etapa de Avaliação. Na elaboração do modelo, foram adequadas à abordagem proposta, as definições identificadas em trabal hos anteriores. Tendo como o principal diferencial, [3] a segregação das Regras de Negócios dos Requisitos de Software, para que tenha uma validação [4] de que o software estará contribuindo efetivamente aos negócios da organização. Para obter uma validação completa e conclusiva, um dos métodos de elaboração do questionário inclui a colaboração dos membros da equipe que participaram neste estudo, de modo a exatidão das informações prestadas é associada ao comprometimento dos participantes. Os critérios de avaliação e a aplicação do modelo contemplam concomitantemente nas etapas de Desenvolvimento e de Avaliação (3), mantendo a objetividade da execução e da avaliação. Na etapa 3, a macro atividade Avaliação do Resultado teve como finalidade analisar cada resposta do questionário, através da tabulação com a indicação de uso satisfatório do modelo de gestão. As respostas são obtidas através da macro atividade de Aplicação do questionário de avaliação.

Trabalhos Relacionados A linha mestre para elaborar o quadro comparativo foi transitar pelos diversos níveis da organização. Desde o nível estratégico, de responsabilidade da alta administração, até o de validação das regras no software desenvolvido. Obviamente, consultando as premissas da gestão do conhecimento, do processo de gestão das regras de negócios e do impacto no desenvolvimento de software. O ponto inicial de qualquer atividade relacionada à gestão do conhecimento está na explicitação, padronização e gerenciamento do conhecimento, enfatizado por [4]. Complementado pelo armazenamento destes conhecimentos em separado quando se trata de regras de negócios e requisitos de sistemas. Com o foco em sistemas de informações, é necessária a descrição das regras de negócios em modelos de testes. Este modelo tem grande influência na validação das regras implementadas nos softwares, aumentando a sua qualidade. Complementando a mesma linha de validação [1] defende a melhoria da qualidade dos requisitos de usuários, tendo em vista que ele recomenda a separação dos requisitos de sistemas dos requisitos de usuários. Um fator importante na gestão das regras de negócio está na dependência destas com o processo de negócios da organização. O relacionamento entre as regras e os processos de negócios proporciona mudanças rápidas das regras quando existir alterações da estratégia da organização. A alta administração tem fundamental contribuição na gestão das regras de negócios, em função do comprometimento

54

Engenharia de Software Magazine - Gestão de Regras de Negócios

com as metas da organização. Através da incorporação com a política organizacional, as regras de negócios conduzem a alcançar as metas desejadas. Na Tabela 1 é possível identificar a extensão em que a gestão das regras de negócios percorre para obter a eficiência e eficácia desta gestão nas organizações de desenvolvimento de software. E também verifica-se que os itens pesquisados refletem a realidade de organizações que possuem o conhecimento como um de seus ativos organizacionais. Na qual, com a aplicação dessas propostas percebem o benefício da utilização da gestão das regras de negócios como fonte de qualidade em soft ware e o domínio destas regras ao longo da vida da organização.

Outros trabalhos Agora, para poder validar o estudo realizado, foi constr uída uma revisão de literatura com as principais vertentes desse trabalho. Nesse processo de revisão, foram abordados os trabalhos mais recentes (últimos cinco anos), que foram publicados em bases de dados de alta qualidade e de alta confiabilidade, tais como, Scopus ,  ACM Library , IEEE Xplore , Science Direct , entre outras. Tendo como finalidade expressar o verdadeiro estado da arte das seguintes estruturas fundamentais para esse trabalho: Regra de Negócio, Levantamento de Requisitos e Gestão do Conhecimento.

Regra de Negócio Uma definição clara de regra de negócio foi descr ita por [2] cujo entendimento é ter a descrição atômica, na qua l não poderá ser subdividida em partes; e deve afirmar, ou in fluenciar ou controlar o comportamento dos negócios de uma organização. Dentre inúmeras características da regra de negócio, o mesmo autor cita algumas fundamentais: • Para tornar os processos de negócios com mais flexibilidade as regras devem ser armazenadas separadamente de fácil recuperação; • Deve prever que as regras de negócio evoluem ou se modifi cam independente do modelo de processos de negócios; • É comum que as regras de negócios se alteram com maior frequência do que os processos de negócios; • Estando armazenado em separadas, num só repositório, as regras de negócio podem ser reutilizadas em vários processos de negócio; • A descrição padronizada facilita o entendimento e reutili zação da regra de negócio em outro contexto. Em uma regra de negócio, a descrição deve ter clareza para que a implementação desta regra tenha sucesso nos resultados esperados pelo cliente [3], assegurando uma descrição e entendimento de cada regra. Também deve existir uma sequência lógica de aplicação das mesmas. Através desta sequência é que o sistema poderá ser desenvolvido com garantia de sucesso na implementação. Para cada conjunto de regras, exemplificado em um cenário de uma transportadora de mercadorias, conforme Tabela 2 , existe uma sequência lógica e ao mesmo tempo cada regra representa a sua individualidade.

BOAS PRÁTICAS

Autores / Técnicas e Métodos

Alta administração estabelece estratégia para a Gestão da Regra de Negócios Apoio à Gestão de RN é um processo da Cultura Organizacional

Autores / Técnicas e Métodos

Possui processo de Gestão da Regra de Negócio definido Procedimento para explicitação de regras de negócio Padrões de escrita da regra de negócio Tratar Regras de negócios separadas por níveis de decisões da organização e aplicações

Tosanguan, Piyanuch Suwannasart,Taratip (2012)

Gaweł, Bartłomiej (2012)

 Jr, E M Bizerra Silveira, D S Cruz, M L P M Wanderley, F J A Introdução, I (2012)

-

-

-

Faz parte da estratégia para atingir as metas da Organização

-

-

-

-

Incorporadas na política organizacional

-

Gaweł, Bartłomiej (2012)

 Jr, E M Bizerra Silveira, D S Cruz, M L P M Wanderley, F J A Introdução, I (2012)

Tosanguan, Piyanuch Suwannasart,Taratip (2012)

-

Descrição das regras de negócio Propõe padrão próprio

Separa as regras de negócio dos códigos de aplicações

Armazenar as regras de negócios separadamente dos requisitos de softwares

-

Gerenciar regras de negócios aumenta a qualidade do software

-

Validação da regra de negócio com

as regras da organização Validação da regra de negócio com a

aplicação em software

As regras demandam mudanças rápidas

-

Explicitação das regras de negócios Cita várias regras: CIM, PSM, SVBR, JSR-94

Regras descritas em modelos de testes Usando OCL - Object Constraint Language

Processos de negócios e tecnológicos descritas de forma independentes (CIM, PIM, PSM) Armazenar de acordo com o nível de negócio e de sistemas

Thi, Thanh Thoa Pham Helfert, Markus Hossain, Fakir Dinh, Thang Le (2011)

Thi, Thanh Thoa Pham Helfert, Markus Hossain, Fakir Dinh, Thang Le (2011) As regras de negócios são derivadas dos Processos de negócios Todas as regras devem estar descritas Decomposição dos processos de negócio para as regras de negócios Considera regras de negócio em níveis

-

-

-

-

Através de casos de testes com uso de ferramentas

-

-

-

-

-

-

Validar regras de negócios aos

processos da organização

Validando as regras na fase

de testes

-

Sommerville, Ian (2011)

Sommerville, Ian (2011)

-

Separa o requisito de Usuário com o requisito de Sistema Recomenda o armazenamen-to em separado A qualidade está na validação dos requisitos de usuário -

Tabela 1. Comparativo em publicações sobre a GRN

#Regra 1 2 3

Definição da regra de negócio As encomendas devem ser atendidas de acordo com a classificação dos Clientes. A prioridade é atender os clientes da classe A, conforme estabelecido em regra específica. Exemplo: os clientes da Classe A são atendidos em primeiro lugar, com os melhores veículos e motoristas disponíveis. Sequencialmente, os clientes a classe B serão atendidos posteriormente ao da classe A. Os clientes com classificação Z, por inadimplência deverão ter suas encomendas colocadas em lista de espera, sem programação para embarque, até que tenham a situação regularizada.

Tabela 2. Definição de regra de negócios (exemplos).

A linguagem descrita é estabelecida conforme entendimento dos profissionais da área operacional da organização que abrigam as regras de negócios. A partir do momento em que as regras estão entendidas, é possível iniciar o design do software, de acordo com o cronograma previsto para sua execução. Em muitas situações, estas regras podem ser reescritas de acordo com os procedimentos definidos na Gestão de Requisitos da organização. Sendo que os

textos poderão ser alterados, porém o conteúdo do ponto de vista semântico jamais poderá ser alterado. Inclusive, esse é um dos pontos críticos que podem levar ao fracasso no desenho e, consequentemente, o desenvolvimento e a entrega do software.

Levantamento de Requisitos Antes de iniciar um estudo sobre o levantamento de requisitos, para um melhor entendimento, se faz necessário um Edição 66 - Engenharia de Software Magazine

55

processo de explicitação dos seus significados iniciando com a definição de um requisito, que pode ser compreendido como uma condição necessária para a obtenção de um determinado objetivo. No entorno desse artigo, adotaremos a definição de um requisito no âmbito de um sistema de soft ware, que pode ser compreendido como a descrição das funções e restrições que o produto a ser desenvolvido deve possuir. Com esses termos bem definidos, o próximo passo é explorar os conceitos referentes ao levantamento de requisitos. Que de acordo com [5] é a fase primordial no processo de desenvolvimento de software em que ocorre uma pesquisa de mercado (junto ao cliente) para de forma simples e completa, encontrar, organizar e rastrear as diversas funcionalidades que o sistema deve obter. Continuando com [5] e acrescentando ideias de [6] o levantamento de requisitos pode ser definido como um conjunto de métodos e técnicas empregadas para levantar, detalha r, documentar e validar os requisitos de um produto para sistemas de informática. Esse processo é longo, moroso e com intensa captura, combinação e disseminação do conhecimento. É nesse processo que todos os envolvidos no projeto, devem trocar informações sobre o contexto e as atividades que serão executadas pelo software durante o seu desenvolvimento. Durante, a sua descrição, essa atividade parece um tanto quanto simplória, no entanto, realizar um bom levantamento de requisitos é um grande desafio. Durante a sua elaboração, diferentes pontos de vistas e expectativas divergentes entre, desenvolvedores, usuários e clientes, tornam essa tarefa difícil e conflituosa. Fato este que  já se inicia com o cliente, tendo em vista, que em inúmeros casos, o cliente não está completamente certo das suas reais necessidades. Portanto, tudo isso fez e faz da fase de especificação de requisitos uma atividade complexa e de alto risco para empresa, influenciando diretamente no sucesso do projeto. A maioria dos problemas encontrados nessa fase representam cerca de 55% dos empecilhos em sistemas computacionais. 82% do esforço dedicado à correção de erros está relacionada a essa fase. Com tais dados em evidência, pode-se novamente reafirmar que os requisitos são a base de todo projeto, caracterizando de forma real o que os clientes necessitam para usa r ou modificar um sistema, e como este deve funcionar. Interessante abordar também que esta constatação não se torna verídica apenas no desenvolvimento de software, não obstante também para qualquer processo que envolva a confecção de novos artefatos. Tudo isso demonstra que para chegar a requisitos que realmente contemplem o sistema pretendido, é necessário que esses sejam devidamente explicitados. Dentre as atividades que fazem parte desse contexto, podese citar o domínio da regra de negócio, captura e classificação de requisitos, estabelecimento de prioridades, resolução de conflitos, verificação de inconsistências e ambiguidade, e finalmente, a negociação dos requisitos do sistema. Para auxiliar na execução dessas atividades, alguns métodos podem ser utilizados.

56

Engenharia de Software Magazine - Gestão de Regras de Negócios

Um dos métodos mais conhecidos e utilizados para especificação de sistemas é o JAD ( Joint Application Development). A principal funcionalidade do JAD é a descrição de uma variedade de métodos para conduzir workshops entre clientes e desenvolvedores, fazendo com que esses trabalhem juntos nas fases de desenvolvimento, principalmente durante a especificação dos requisitos. Um segundo método bastante utilizado são os pontos de vistas orientados à técnica. Um exemplo bastante clássico desse método é o VORD ( Viewpoint Oriented Requirements Definition), em que são definidos e estruturados diferentes pontos de vista ficando a cargo do analista a integração dos requisitos. Por fim, todos esses métodos, técnicas e definições demonstram que o levantamento de requisitos é uma parte essencial e funcional durante o processo de desenvolvimento de software.

Gestão do Conhecimento Continuando na mesma linha de investigação e arguição dos termos cruciais para a execução desse projeto, o próximo passo é definir e esmiuçar ao máximo o significado da gestão do conhecimento, principalmente referente ao contexto da regra de negócio. Vale definir, inicialmente, o que seria a gestão, que pode ser entendida como um processo de coordenar tarefas, atividades e projetos de maneira que sejam desempenhados de forma eficaz e eficiente, sempre tendo em vista o objetivo de gerenciar o conhecimento. O conhecimento, dentro desse contexto, assume duas formas principais, o Tácito e o Explícito. O primeiro refere-se ao conhecimento que está armazenado na cabeça das pessoas, sendo pertencente somente ao indivíduo que o detém. E o segundo, explícito, refere-se ao conhecimento estruturado, inerente ao indivíduo, sendo pertence a sua organização mantedora. A principal funcionalidade da gestão do conhecimento se refere a realizar a transformação do conhecimento tácito para explícito. Processo esse, em que, o conhecimento deixa de ser um  bem apenas pertencente ao indivíduo, e se torna, de forma estrutura, um ativo a todos os métodos que desejarem utiliza-lo. Alguns autores colocam algumas definições interessantes sobre gestão do conhecimento, que é uma abordagem da empresa em busca de pontos, onde o conhecimento venha a trazer uma vantagem competitiva. Ela pode ser vista como um amplo processo de criação, uso e disseminação do conhecimento dentro de toda e qualquer organização que possua o conhecimento como um de seus ativos capitais. A gestão do conhecimento pode assumir diferentes definições e denominações, no entanto, mesmo que ora dispares, todas as formas de expressar seu significado possuem no final ao menos um aspecto de similaridade em seus sentidos. Outra definição bastante interessa nte é a que coloca a gestão do conhecimento como uma estratégia que busca transforma r  bens intelectuais da organização - informações registradas e o talento de todos os seus usuários - em uma maior produtividade. Ela procura apresentar novos valores dentro da organização e proporcionar de uma forma geral um aumento final na sua capacidade de produtividade.

BOAS PRÁTICAS

Por conseguinte, a gestão do conhecimento pode ser compreendida como uma ferramenta gerencial de administração, planejamento e controle do conhecimento modelando parte do conhecimento que existe na cabeça das pessoas em regras de negócio, tornando-as visíveis à toda organização de uma forma simples e de fácil acesso, executando assim a principal funcionalidade da gestão do conhecimento .

Modelo da Gestão de Regras de Negócios O processo de software é compreendido como sendo um ciclo de atividades que se inicia na definição dos requisitos de software até a entrega do produto desenvolvido. Sendo que neste ciclo está compreendido também o planejamento do desenvolvimento dos requisitos de software, a codificação e teste do software, implantação da aplicação com os requisitos de software. O modelo proposto por este artigo, conforme Figura 2 , além deste ciclo do processo de software, fica prevista a gestão das regras de negócios, antes da definição dos requisitos de software. Da mesma forma, esta gestão também está compreendida num ciclo de atividades que contempla inicialmente a identificação das necessidades e oportunidades de negócios, até a implantação destas regras na rotina das atividades operacionais da organização. Um conjunto de atividades fica elencado a seguir: • Identificar necessidade ou oportunidade de negócio –  basicamente, a origem de uma regra de negócio tem como

fonte novas necessidades para resolver um problema existente por falha no processo; ou por uma nova oportunidade no mercado que proporcionará divisas ou novos lucros para a organização; • Analisar regras de negócio existentes – a nova regra de negócio, também considerada como regra candidata, deve ser avaliada quanto a sua aplicação como sendo única antes de ser detalhada em definitivo; • Especificar regra de negócio candidata – a descrição da regra deve ter as características essenciais para o entendimento [4] para ter a compreensão suficiente para que seja aplicada corretamente, sem ambiguidade e ter a precisão nos resultados esperados; • Aprovar regras de negócios candidatas – quando a regra de negócio está alinhada à estratégia da organização e à estratégia de negócios, com resultados mensuráveis, deve ser aprovada; • Adequar a especificação da regra de negócio  – caso não tenha aprovação da regra, esta deve ser adequada para ter o mínimo dos quesitos necessários para ser aprovada, para tanto se necessita da adequação da especificação; • Gestão das regras de negócios – este é um processo inteiramente destinado à manutenção da regra desde a sua especificação até a desativação. Toda regra pode sofrer alterações ao longo de um período para se adequar às novas realidades em que a organização está submetida, assim requerendo uma manutenção constante;

Figura 2. Fluxo das atividades do modelo de gestão de regras de negócio

Edição 66 - Engenharia de Software Magazine

57

• Validar regra de negócio no software –

o software que atende às regras de negócio devem ter estas regras validadas pelo resultado almejado, pela fidelidade à regra aprovada para uso na organização; • Processo de Desenvolvimento de Software  – este é um processo conhecido pelas atividades de planejamento, levantamento de requisitos até a entrega efetiva do produto de software. Conforme descrito por [1], as atividades previstas no processo deve ter como objetivo a qualidade final do software. Considerando que a gestão do conhecimento é um processo único e delimitado pelo seu domínio, em função da naturez a, objetivo e responsabilidade; se torna perceptível a separação o controle das necessidades de negócios e dos requisitos de softwares. Outro fator está relacionado à evolução das necessidades de negócios que têm velocidades e amplitudes diferentes dos requisitos de softwares. Ao iniciar o desenvolvimento de software, o objetivo principal é atender às necessidades dos usuários finais através dos requisitos do sistema. Na organização, as atividades são executadas seguindo um modelo de processo que analisa os requisitos e projeta uma arquitetura do software para atender aos requisitos analisados. Efetivamente, mecanizando

Figura 3. Fluxo ilustrativo do modelo de GRN

58

Engenharia de Software Magazine - Gestão de Regras de Negócios

os processos, tratando os dados de entradas e formatando as informações resultantes, até que o processo reflita as definições das regras de negócios. De modo geral, as regras de negócio definem as condições em que um processo é realizado ou as novas condições após a conclusão de um processo. A grande vantagem em separar a regra de negócio do requisito de software está na validação do sistema com a lógica do negócio. Uma vez que a regra de negócio passa a ser um processamento, descrito por um requisito de software, esta deve validada. O principal objetivo deste artigo foi modelar um processo de gerenciamento de regras de negócios possível de ser utilizado numa organização em que estas regras são utilizadas somente como insumo para o desenvolvimento de software. Foi escolhido o GAIA para aplicar o modelo proposto neste artigo, com o objetivo de aumentar a qualidade dos produtos desenvolvidos. Este modelo será aplicado em ambiente especificamente de desenvolvimento de software, dando como foco principal o gerenciamento da regra de negócio por uma equipe que conhece o gerenciamento de requisitos de software. Com a nova visão para regra de negócio as pessoas estarão comprometidas também com os objetivos estratégicos da organização.

BOAS PRÁTICAS

Atualmente o GAIA contempla um modelo de desenvolvimento com o ciclo de vida caracterizado pelo processo de software, no qual a gestão de requisito prioriza os requisitos de sistemas. Com o novo modelo passará a executar atividades de gestão das regras de negócios que contempla maiores esforços na manutenção dos requisitos de usuários com objetivos estratégicos da organização. Cada projeto desenvolvido pelo GAIA passará por um critério mais efetivo na escolha da funcionalidade a ser desenvolvida  juntamente com as regras priorizadas pela organização. Como podemos observar na Figura 3 , as atividades de desenvolvimento de software estão representadas pelo fluxo em a marelo, enquanto que no fluxo azul ficam demonstradas as atividades da manutenção das regras de negócios. O modelo tem como objetivo aumentar a qualidade do software desenvolvido, desde a sua concepção, projeto, desenvolvimento, entrega e resultados de sua aplicabilidade. No fluxo tradicional da gestão de requisitos e sua implementação, o objetivo é atender as definições descritas nestes requisitos funcionais e não-funcionais. Enquanto que com a implementação do fluxo acrescido da gestão de regras de negócios, o comprometimento fica ampliado aos resultados que o software deve proporcionar à organização patroci nadora do projeto.

Referências: 1. I. Sommerville, Engenharia de Software. 9ª edição. Editora Pearson do Brasil, 2011. 2. Sujithra S. and Chandrashekar R., “Externalizing business rules from business processes for model based testing”, International Conference on Industrial Technology, 2012, pp. 312-318. 3. Wan-Kadir, WMN; Pericles Loucopoulos; “Relating evolving business rules to software design”, 2012, pp. 367-382. 4. P. Tosanguan, T. Suwannasart, “An Approach for Defining Rules as Functions in Rule-Based Rule-Based Software Development”, International Conference on Digital Information Management, 2012, pp. 30-34. 5. Wen B., Z. Luo, P. Liang “Distributed and Collaborative Requirements Elicitation based on Social Intelligence”, Ninth Web Information Systems and Applications Conference, 2012, pp. 127-130. 6. D. P. A. Junior and R. Campos “Definição de requisitos de software baseada numa arquitetura de modelagem de negócios”. Prod. Vol. 18 nº1, São Paulo. ISSN 0103-6513, 2008.

Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback  Ajude-nos a manter a qualidade da revista!

Edição 66 - Engenharia de Software Magazine

59

60

Engenharia de Software Magazine - Gestão de Regras de Negócios