Engenharia de Software - Edição 66.pdf

(1)

(2)

(3)

(4)

Corpo Editorial

Editor

Rodrigo Oliveira Spínola

Colaboradores

Marco Antônio Pereira Araújo

Eduardo Oliveira Spínola

Nicolli Souza Rios

Consultor Técnico Consultor Técnico Daniella Costa Daniella Costa Jornalista Responsável Jornalista Responsável Kaline Dolabella - JP24185 Kaline Dolabella - JP24185 Na Web Na Web http://www.devmedia.com.br/revista-engenharia-de-software-magazine http://www.devmedia.com.br/revista-engenharia-de-software-magazine 66 ª Ed 66 ª Edição ição - 2014- 2014 Salvador - UNIFACS. Salvador - UNIFACS.

Marco Antônio Pereira Araújo

Marco Antônio Pereira Araújo [email protected]

[email protected]

Doutor e Mestre em Engenharia

Doutor e Mestre em Engenharia de Sistemas e Computação pela de Sistemas e Computação pela COPPE/UFRJ, Especialista emCOPPE/UFRJ, Especialista em

Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em

Infor-mática pela UFJF.

mática pela UFJF.

Eduardo Oliveira Spínola

Eduardo Oliveira Spínola [email protected]

[email protected]

É Colaborador das revistas Engenharia de Software Magazine

É Colaborador das revistas Engenharia de Software Magazine,,Java Magazine e SQL Magazine.Java Magazine e SQL Magazine.

É bacharel em

É bacharel em Ciência da Computação pela Ciência da Computação pela Universidade Salvador (UNIFAUniversidade Salvador (UNIFACS).CS).

Nicolli Souza Rios

Nicolli Souza Rios [email protected]

[email protected] Formanda em Ciência da Computação na

Formanda em Ciência da Computação na Universidade Salvador (UNIFUniversidade Salvador (UNIFACS),Gerente de Projetos daACS),Gerente de Projetos da

COMMIT– Empresa Júnior de Computação da

COMMIT– Empresa Júnior de Computação da UNIFACS e Estagiária de Desenvolvimento de SoftwareUNIFACS e Estagiária de Desenvolvimento de Software

na BAHIAGÁS.Faz parte do

na BAHIAGÁS.Faz parte do grupo de pesquisa em Engenharia de Software do Programa de Pós-grupo de pesquisa em Engenharia de Software do Programa de

Pós-Graduação em Sistemas e Computação da

Graduação em Sistemas e Computação da UNIFAUNIFACS.CS.

Atendimento ao Leitor

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.

Se você tiver algum problema no

Se você tiver algum problema no recebimento do seu exemplar ou precisar de algumrecebimento do seu exemplar ou precisar de algum

esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de

jornal, entre outros,

jornal, entre outros, entre em contato com:entre em contato com: www.devmedia.com.br/central www.devmedia.com.br/central (21) 3382-5038 (21) 3382-5038 Publicidade Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

contato com: publici

publicidade@[email protected] 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.

(5)

06 – Desenvolvimento Ágil: análise sobre requisitos tradicionais

[ Mauricio M. O. Matos, Nicolli Souza Rios Alves e Rodrigo Oliveira Spínola ]

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

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

40 – Desvendando o Gerenciamento de Projetos – Parte 3

[ Ary dos Santos Rocha Júnior]

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 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 ]

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

44 – Trabalhando com Engenharia de Requisitos

[ Elaine G.M de Figueiredo]

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]

Sumário

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 D ê s e u F eedb _a c k s o b r e e s t a e d i ç ã o

(6)

(7)

Rodrigo Oliveira Spínola

[email protected]

Editor Chefe – Engenharia de Software Magazine

Nicolli Souza Rios Alves

[email protected]

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

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

Fique por dentro:

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 es-pecificação de requisitos entre as metodologias ágeis e tradicionais. O estudo foi iniciado a par-tir 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árelató-rios.

Desenvolvimento Ágil: análise sobre

requisitos tradicionais

Entenda os benefícios e dificuldades das abordagens tradicionais e ágeis

A

especificação de requisitos

pode ser, em muitos casos, um problema complexo, principal-mente 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, espe-cialmente 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 ativida-des 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

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

(8)

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 de-senvolvedores para realizarem suas funções e, ao fim, respon-derem um questionário a respeito das dificuldades e benefícios encontrados no uso de cada tipo de especificação.

Metodologias de especificação de requisitos

Um processo de engenharia de requisitos é um conjunto estruturado de atividades a serem seguidas para criar, va-lidar 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 é ga-rantir 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 desenvolve-dores 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 centra-lizaram princípios baseados em diversos métodos existentes.

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.

MAs têm foco na interatividade dos envolvidos e em respos-tas rápidas como forma de atender os requisitos do usuário. A abordagem de requisitos em MAs pode permitir bons resul-tados 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, defi-nidos, 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 requi-sitos 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 naFigura 2;

•É necessário discutir sobre a estória para se esclarecer

quais-quer detalhes;

•Testes e anotações são inseridos na estória para que aux iliem

no desenvolvimento de regras e detalhes que a funciona-lidade 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.

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

Para se criar uma boa US é necessário que esta seja caracte-rizada por seis atributos:

• Independente; • Negociável;

(9)

• Estimável; • Pequena; • Testável.

Dependências entre US podem causar transtornos no mo-mento do desenvolvimo-mento 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, especificar

deta-lhes muito cedo só cria mais trabalho. A Figura 3mostra 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 interessados.

É 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 elabo-rar 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.

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 proje-to, produzindo documentações gerenciais e de especificação muito mais detalhadas e consistentes. Além de uma série de

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. NaTabela 1 tem-se um conjunto de definições que são

im-portantes em um caso de uso.

Estudo de Caso

Esse estudo tem como objetivoanalisaras metodologias de

especificação de requisitos ágil e tradicional,com o propósito

dedefinir 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 no 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 (verTabela 2): Este caso

de uso define como as operações de inclusão, alteração, exclu-são e consulta de usuários exclu-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 cancela-mento 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 re-gras de negócio foram definidas. Por fim, foi defin ido também

(10)

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 Permitir a inclusão, alteração, exclusão e consulta de usuários. Requisitos O software deve permitir o gerenciamento de usuários. Atores

Professor-Administrador Professor

Aluno Prioridade Alta 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 gerenciar usuários.

Fluxo principal

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) • 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.

Fluxo alternativo

[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 • Senha

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

• Telefone

(11)

Fluxo alternativo

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

[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

2. O ator altera os campos desejados

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

Fluxo de exceção

[FE1] Campos obrigatórios não preenchidos

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

2. O sistema retorna ao passo onde este fluxo de exceção foi chamado. Extensões [E1] Caso de uso “UC02 - Emitir Relatório de Usuários”.

Pós-condições Será realizada a manutenção dos usuários. Regras de negócio

[RN1] Apenas os professores que forem administradores terão permissão para realizar esta ação.

[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

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 funcio-nalidade 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 efe-tuadas. Observe que basicamente temos uma tela de con-sulta seguida do relatório gerado a partir das informações consultadas.

(12)

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}

Fluxo principal

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: • Nome • Login • Administrador? • Perfil • E-mail • Telefone

4. O caso de uso é encerrado.

Fluxo alternativo

[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 • Administrador? • Perfil • E-mail • Telefone

2. O caso de uso é encerrado Fluxo de exceção

[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 funcionalidade 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.

Notas

• Apenas o administrador poderá incluir e excluir um usuário • 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

(13)

• 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 de-talhes sobre cada uma delas são definidos apenas no momento de sua implementação.

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 responde-ram no questionário que é possível desenvolver as fun-cionalidades 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 docu-mento 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 desenvol-vedor e o cliente, visto que nem s empre o desenvoldesenvol-vedor é o profissional mais indicado para a função. O desenvolvedor 1 afirmou “... o desenvolvedor muitas vezes possui dificul-dades 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 u-mento 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 aborda-gem ágil, a função de especificação na entrevista fica clara e para isto é importante que seja o profissional indicado para a funçã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 consi-derando 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 tradi-cional 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 documen-tações. Outros quatro desenvolvedores serão escolhidos para apresentar seus pareceres referentes à documentação prove-niente 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 dificuldade. 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 desen-volvedor expressou alguma dificuldade de entendimento da documentação. A falta de informação os preocupou inicial-mente, mas após a conversação, todas as dúvidas foram escla-recidas. 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”.

(14)

Foi também constatado que há a necessidade de haver o contato direto entre o detentor do negócio, cliente ou ana-lista 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 imple-mentada, a documentação tradicional a partir de Casos de Uso foi considerada a mais completa pelos desenvolvedo-res. 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 efi-ciente em relação ao tempo de elaboração, e mais suscetível

Dê seu voto emwww.devmedia.com.br/esmag/feedback

Ajude-nos a manter a qualidade da revista!

Você gostou deste artigo?

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.

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.

(15)

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 diver-sas tecnologias e ramos de negócio.

Fique por dentro:

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, tam-bém considerados fatores críticos de sucesso das aplicações. Este artigo procura abordar os riscos envolvidos em não se cuidar devidamen-te dos requisitos não funcionais do software e de como o time Scrum deve estar estruturado para tratar ou evitar “surpresas” as quais po-dem levar qualquer produto ao fracasso.

Scrum backlog: requisitos não funcionais

Criando um ambiente favorável para gerenciar melhor o Backlog

A

produção de software através

de modelos ágeis de desen-volvimento, 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 desenvolvi-mento 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 neces-sário para poder alcançar um ambiente mais produtivo e seguro.

Veja os números apresentados na

Figu-ra 1 publicados no último relatório

gera-do 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.

Podemos perceber que houve uma sen-sível melhora, desde a 1ª aferição em 1994 até a última em 2012 onde, de apenas 16% de sucesso nos projetos, alcançou-se 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, torna-se um fator preocupante.

Em complemento, aTabela 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

(16)

• 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 co-nhecimento, aumentando o capital intelectual das equipes, se-guido por uma melhor visão e entendimento mais sólido sobre gerenciamento de projetos e a adoção de Processos Ágeis.

1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 31 40 ₂₈ 23 15 18 19 24 21 ₁₈ 53 33 46 49 51 53 46 44 42 ₄₃ 16 27 26 28 34 29 35 32 37 39

Chaos Manifesto 2013 - The Standish Group

Failed Challenged Successful

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 produzi-da 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 funcio-nais 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 es-trutura 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 habilida-de (multidisciplinar), mas nem sempre se observa a presenç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 pre-cisam 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, funcionali-dades 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 crip-tografia, 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 obser-var estas obser-variáveis de forma mais clara, não apenas a equipe, mas principalmente a empresa, temos uma visão e um com-prometimento 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

(17)

tempo em comunicação. Esta não é um tema a ser abordado neste momento, mas é muito importante lembrar que a Comu-nicaçã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 membros 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 desen-volvimento 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 funciona-lidade 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

funciona-lidade, informando seu objetivo central ou “para o que ela se destina”;

• Requisito Não Funcional: Nome, designação ou

identifi-cador do requisito não funcional do software. Podemos dizer

Requisito Funcional Descrição Requisito Não Funcional Descrição Cadastro de Usuário Manter dados do usuário Criptografia Criptografar a senha do cliente

Cadastro de Pedidos Manter os pedidos de Venda Workflow 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

até que seja a referência a um “item de configuração”. Sugere-se 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 hiper-links 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 requisitos não funcionais devem ser mapeados junto com os requisitos fun-cionais 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.

(18)

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 omple-xo 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

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 es-truturado são peças fundamentais.

Da mesma forma que o foi abordado no item “produto”, co-meç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”?”.

Ao adotar uma ferramenta, dê preferência àquelas que faça m o controle de versões e, além disso, que disponha 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 evolucorre-çã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 ferra-menta de repositório permitirá a execução do backup (cópia de segurança).

(19)

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 “com-pilada” 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 significativa no produto e que se permita sua avaliação, é uma boa práti-ca 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 arma-zenados nas máquinas e/ou locais determinados, e os arqui-vos de backup serão gravados (salarqui-vos) 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 ambiente. 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 es-pecífico definido.

Agora imaginemos, na prática, uma equipe de desenvolvi-mento de software, a qual adotou uma metodologia de desen-volvimento ágil (como Scrum ou XP). As ações de criação e/ou alteração do software ocorrerão durante uma Sprint. Nesta(s)

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 configu-raçã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 configuraçã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 componen-tes do sistema operacional ou do sistema de gerenciamento 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 esque-cer 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),

(20)

testar, homologar e disponibilizá-lo em produção é, infini-tamente 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 consulto-ra 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: Desenvol-vimento, Testes e Produção.

A seguir serão abordados os ambientes sugeridos e mini-mamente 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 rea-lizadas 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 es-perado, 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 ante-riormente, 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 cur-to 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 equi-pe 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 devasta-dores, 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

(21)

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 “con-siderar 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 mencio-nam 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” con-forme 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 (hardwa-re e softwa(hardwa-re). 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 desen-volvida 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 dedi-cada – geralmente a equipe de Infraestrutura da Empresa ou do próprio cliente.

O ato de criação de um software passa por muitos cami-nhos 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 que 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 garantirá o sucesso de todo o esforço investido.

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 empre-sa pode ainda não ter alcançado tudo isso e, agora, devemos operacionalizar os requisitos não funcionais. Conforme expu-semos 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 respon-sabilidade 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 é, original-mente, 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 exis-tiam 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 po-deria 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