Métodos ágeis: Uma análise geral sobre a documentação aplicada ao desenvolvimento de software

7/25/2019 Métodos ágeis: Uma análise geral sobre a documentação aplicada ao desenvolvimento de software

http://slidepdf.com/reader/full/metodos-ageis-uma-analise-geral-sobre-a-documentacao-aplicada-ao-desenvolvimento 1/22

MÉTODOS ÁGEIS: UMA ANÁLISE GERAL SOBRE A

DOCUMENTAÇÃO APLICADA AO DESENVOLVIMENTO DE

SOFTWARE1

Alan Jovane Vilaça2

Professor Orientador: Edivaldo Mendes Moraes3

MBA em Arquitetura de Software

RESUMO

A documentação é parte importante de um software, seja para auxiliar a

comunicação da equipe, seja para facilitar o seu entendimento. No contexto das metodologias ágeis, a documentação de um software é frequentemente algo controverso, uma vez que nelas se prioriza a agilidade no desenvolvimento em detrimento de uma documentação abrangente. Essa priorização visa eliminar a geração excessiva de documentos, o que consome tempo e muitas vezes produz artefatos pouco, ou mesmo nunca, utilizados. Nesse contexto, este trabalho analisa a adoção da documentação em metodologias ágeis. Essa análise é feita através de pesquisa bibliográfica juntamente a um estudo de caso de um processo de documentação em um ambiente ágil. Através do referido estudo de caso pode-se ter, entre outras, a conclusão de que a adoção de práticas ágeis não impede a adoção de documentação. Ao contrário, as práticas ágeis incentivam uma mudança no papel da documentação no processo de desenvolvimento de software. Mostra-se a interação entre os membros da equipe atuando na construção da documentação e, sobretudo, contribuindo para a sua qualidade, como parte integrante de todo o software.

Palavras-Chave: Metodologias ágeis. Documentação de software. Desenvolvimentode software. Manutenção de software.

ABSTRACT

Documentation is an important part of a software. It can help the team communication and favor the software’s understanding. In the context of agile methodologies, software documentation is often something controversial, since is prioritized the agility of software development over the existence of a comprehensive documentation. This priority aims to eliminate the excessive generation of documents, which spends time and often produces some artifacts rarely used. In this context, this paper analyzes the adoption of documentation on agile methodologies. This analysis is made through a bibliographic review and a case study of a

1Trabalho apresentado como requisito parcial para obtenção do título de Especialista em Arquitetura de

Software do IGTI.2 Pós-graduando do MBA EM ARQUITETURA DE SOFTWARE, [email protected] 3 Orientador do trabalho. Professor do curso de pós-graduação do IGTI, Especialista em Administração de Banco de Dados, [email protected]

mailto:[email protected]

mailto:[email protected]



documentation process in an agile environment. A conclusion of this case study, among others, is that the adoption of agile methodologies does not inhibit the existence of documentation. Instead, the agile practices encourage chaging the role of documentation in the software development process. It is demonstrated that the

interaction of team members operates in favor of the documentation’s construction and, mainly, contributing to its quality, as part of the entire software.

Keywords: Agile Methodologies. Software Documentation. Software Development.Software Maintenance.

1 INTRODUÇÃO

Atualmente, os softwares desempenham papéis cada vez mais importantes

em diversos segmentos e contextos da sociedade. Com essa crescente importância, fatores como produtividade, flexibilidade, inovação e qualidade fazem parte do

contexto de um projeto de desenvolvimento de software, e muitas vezes podem

determinar o seu sucesso ou falha.

Kent Beck (2004) afirma que falhas no desenvolvimento de software têm

enormes impactos, econômicos e humanos. Assim, o aprimoramento do processo

de desenvolvimento de software, e consequentemente de seu produto final, é objeto

de constantes estudos, surgindo a ideia da aplicação das metodologias de

desenvolvimento de software, conforme dizem Ludvig e Reinert (2007).

Segundo Sommerville (2006), metodologias de desenvolvimento são

conjuntos de práticas recomendadas para o desenvolvimento de software. Dennis e

Wixon (2011) dizem que uma metodologia de desenvolvimento tem a função de

formalizar a ordem de desenvolver um software, organizar a fase do ciclo de vida do

mesmo e ter o equilíbrio entre os processos e os dados.

Existem vários tipos de metodologias, que podem ser adaptadas ou até

mesmo criadas de acordo com a necessidade e realidade do contexto em que são

aplicadas. Neste artigo, serão abordadas as chamadas metodologias ágeis de

desenvolvimento de software, surgidas como parte do esforço para melhoria do

processo de desenvolvimento de software.

As características das metodologias ágeis serão destacadas no decorrer do

artigo. Porém, a característica mais importante dessas metodologias para este artigo



é a valorização do “software em funcionamento mais que documentação

abrangente” (Beck et al, 2001).

As metodologias ágeis trazem em seus princípios uma maior valorização da

interação entre os membros da equipe em relação à existência de uma

documentação abrangente. Isso pode levar, erroneamente, à ideia de que a

documentação tem uma baixa importância no contexto do processo de

desenvolvimento de software. No entanto, a documentação é uma parte central de

todas as atividades que levam à implantação de um bom software, segundo Booch

et al (2006). Ela tem um papel importante no entendimento do programa, necessário

sobretudo para a sua evolução, conforme dizem Huang e Tilley (2003).

Michelazzo (2006) afirma que a documentação é extremamente necessária e

auxilia na redução de horas preciosas na correção de problemas. Logo, a ausência

ou insuficiência de documentação representa um risco ao projeto, sobretudo na sua

manutenção, corretiva ou evolutiva, que frequentemente ocorre posteriormente à

implantação do sistema e pode ser executada por uma equipe diferente daquela que

o desenvolveu inicialmente. Tendo em vista a importância da documentação em um

projeto de software e os preceitos das metodologias ágeis, um projeto de software ágil deve ter uma documentação que contribua para a qualidade e o entendimento

do software, mas com a qual não se gaste mais tempo que o necessário. Tem-se,

então, a questão de pesquisa desse artigo: como aliar os benefícios da

documentação de software aos preceitos das metodologias ágeis de

desenvolvimento?

Este trabalho tem por objetivo realizar uma análise da aplicabilidade da

documentação de software em ambientes ágeis. Pretende-se, com isso, investigar maneiras de se adotar os dois conceitos - documentação de software e

metodologias ágeis - de maneira a serem aproveitados os benefícios trazidos pelos

dois.

Na seção 2, a seguir, é apresentada a metodologia utilizada neste artigo. Nas

duas seções seguintes - 3 e 4 - é apresentada uma pesquisa bibliográfica sobre os

temas metodologias ágeis e documentação de software, respectivamente. Na seção

3, é especificamente abordada a metodologia Scrum, cuja escolha se deu por ser

apontada, segundo Steffen (2012), como o framework mais utilizado devido à sua



simplicidade, fácil adoção e adaptação. Na seção 5 é feito um estudo de caso do

processo de documentação existente em uma equipe de desenvolvimento ágil. Uma

análise do estudo de caso em relação aos conceitos trazidos na pesquisa

bibliográfica é feita na seção 6. As conclusões do trabalho e sugestões para

trabalhos futuros são apresentadas na seção 7.

2 METODOLOGIA

Para o atingimento dos objetivos do trabalho, foi feita inicialmente uma

pesquisa bibliográfica sobre os temas envolvidos na literatura existente. Essa

pesquisa foi estruturada de maneira a formar o referencial teórico do artigo.Foi realizado, também, um estudo de caso do processo de documentação

existente em um ambiente ágil de desenvolvimento de software, o qual foi analisado

com base no referencial teórico formado inicialmente; análise esta que embasa a

resposta à questão de pesquisa desse artigo.

3 OS MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE

O surgimento do termo “agilidade” foi provavelmente a mais notável mudança

na elaboração de processos de desenvolvimento de software surgida recentemente,

conforme diz Fowler (2005). Esse surgimento, como aponta Miller (2002), se deu em

meio a questionamentos das metodologias tradicionalmente utilizadas, em meados

da década de 1990. Ocorria na referida época um alto índice de projetos que

deixavam de cumprir seus cronogramas e extrapolavam seus orçamentos, segundo

Oliveira (2003).

Esse descumprimento de prazos e orçamentos fez com que se voltasse a

atenção para a inabilidade dos processos então utilizados em lidar com mudanças.

“A incerteza é inerente e inevitável nos processos de desenvolvimento de software”

(Hadar Ziv, 1996, p. 3). Essa incerteza “permeia o desenvolvimento de software,

mas raramente é capturada” (Hadar Ziv, 1996, p. 1).

Nesse contexto, surge a ideia da agilidade no desenvolvimento de software.

Highsmith (2002) define a agilidade em TI como sendo a habilidade de criar e

responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio



turbulento. Highsmith enfatiza, ainda, que a ausência de estrutura ou estabilidade

pode levar ao caos, mas que a estrutura em demasia implica em rigidez. A ideia de

agilidade no desenvolvimento vem, assim, para tornar os processos de

desenvolvimento de software mais adaptáveis às mudanças muitas vezes ocorridas

com o processo em andamento e, ainda, tornar o processo mais leve e menos

rígido.

No ano de 2001, um grupo de dezessete especialistas em desenvolvimento

de software lançou o chamado manifesto ágil, que definiu os princípios a serem

seguidos pelas metodologias ágeis, conforme dizem Beck et al (2001). Esses

princípios propõem, resumidamente, uma modificação da importância atribuída a

algumas práticas adotadas nas chamadas metodologias tradicionais. A proposta é

que outras práticas sejam mais valorizadas em um projeto de software que siga os

preceitos ágeis.

No manifesto ágil, segundo Beck et al (2001), é apresentada a proposta de se

passar a valorizar::

Os indivíduos e suas interações, mais que processos e ferramentas;

O software em funcionamento, mais que uma documentação abrangente; A colaboração com o cliente, mais que negociação de contratos;

Responder a mudanças, mais que seguir um plano.

O manifesto ágil vem, então, definir melhor a proposta das metodologias

ágeis, conforme dizem Pereira et al (2007). Em relação a essas propostas, cabe

dizer que elas não rejeitam o uso de nenhum dos itens à direita da enumeração

anterior, mas o seu uso tem uma importância diminuída frente aos itens à esquerda,

como mostra Soares (2004).Definindo diretrizes comuns às metodologias ágeis, o manifesto não pretende

ser específico sobre o processo de desenvolvimento de software. O

desenvolvimento ágil é algo comum a diferentes metodologias, e há abordagens

mais e menos prescritivas, como demonstrado por Steffen (2012). Como exemplos

de metodologias ágeis, podemos citar “eXtreme Programming (XP), Scrum, Dynamic

System Development Method (DSDM), Adaptive Software Development (ASD),

Crystal, Feature Driven Development (FDD) e Lean Development” (Pereira et al,

2007, p. 2). Na subseção a seguir, será detalhada a metodologia Scrum. Conforme



dito anteriormente, a opção por detalhar o Scrum se deu por esta metodologia ser,

segundo Steffen (2012), mais utilizada devido à sua simplicidade, fácil adoção e

adaptação.

3.1 SCRUM

O Scrum pode ser definido como “um framework dentro do qual pessoas

podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e

criativamente entregam produtos com o mais alto valor possível”. (Schwaber e

Sutherland, 2013, p. 3).

Schwaber (2002) considera o Scrum, uma metodologia ágil voltada ao gerenciamento e desenvolvimento de projetos de software orientados a objetos.

Diferentemente de outras metodologias, que tratam o desenvolvimento através de

tarefas de programação, o Scrum é orientado para o gerenciamento de projetos,

como diz Oliveira (2003).

Por ser um framework, o Scrum se coloca como um guia de boas práticas,

que é adaptável à realidade de cada projeto. Assim, ele não pretende ser totalmente

prescritivo, ou seja, não diz o que fazer em qualquer circunstância, mas pretende facilitar a identificação e resolução de problemas ocorridos no projeto, como

mostram Pereira et al (2007).

Nas subseções a seguir, são expostas as principais características da

metodologia, não existindo, no entanto, o objetivo de esgotá-la.

3.1.1 PILARES DO SCRUM

De acordo com Schwaber e Sutherland (2013), o Scrum é fundamentado no

empirismo. “O empirismo afirma que o conhecimento vem da experiência e de

tomada de decisões com base naquilo que é conhecido”. (Schwaber e Sutherland,

2013, p. 3). Assim, a implementação do Scrum se baseia em três pilares, que são

assim resumidos por Gonzales (2015):

Transparência: devem ser visíveis todos os aspectos significativos do

processo a todos os interessados. Assim como todos devem ter definições padrões comuns. Um exemplo citado é a definição de “Pronto” que deve ser clara e comum a todos os envolvidos.



Inspeção: os artefatos do Scrum e seus progressos devem ser inspecionados por seus usuários afim de detectar variações. Não chegando ao ponto de ser excessiva causando prejuízo à execução das tarefas.

Adaptação: uma vez identificados desvios no progresso ou artefatos do

Scrum, devem ser tomadas medidas para adaptação o mais rápido possível. (GONZALES, 2015, p. 9).

3.1.2 CRITÉRIOS UTILIZADOS DENTRO DO SCRUM

Segundo Sutherland e Schwaber (2007), o Scrum foi idealizado para dar foco,

clareza e transparência ao planejamento e à implementação do projeto de software.

Considerando as características das metodologias ágeis, o Scrum tem como

base uma abordagem iterativa e incremental, com foco nas pessoas que compõem a equipe de desenvolvimento, indicado para projetos nos quais os requisitos aparecem e mudam rapidamente. Trata-se de uma implementação que objetiva aumentar a produtividade e reduzir o tempo de desenvolvimento de um software ou produto. (SILVA, 2009, p. 26).

Segundo Silva (2009), o Scrum é indicado para um cenário com equipe

pequena, composta de até sete pessoas; requisitos pouco estáveis ou mesmo

desconhecidos; e iterações curtas, com entrega de produto, ou versão deste, para o

cliente ao seu final.Uma equipe Scrum é composta de três partes, ou papeis, segundo Schwaber

e Sutherland (2013): o Product Owner, o Scrum Master e o Time de

Desenvolvimento. Cada um desses papeis tem as seguintes responsabilidades,

segundo Schwaber e Sutherland (2013):

Product Owner, ou dono do produto: é o responsável pelo produto,

aquele que define e prioriza o que será feito, com poder para aceitar ou

rejeitar o produto final.

Scrum Master: é um facilitador, líder do time. Deve garantir o

cumprimento de todo o processo, fazendo com que toda a equipe seja

produtiva.

Time de desenvolvimento: é composto por em torno de sete pessoas,

responsáveis pela análise, programação e testes do projeto.



De forma simplificada, a Figura 1 ilustra o ciclo de desenvolvimento proposto

pelo Scrum.

Figura 1 - Dinâmica de desenvolvimento proposta pelo Scrum.Fonte: (Oliveira, 2003).

Sutherland e Schwaber (2007) definem o começo de um projeto Scrum como

o planejamento do produto pelo product owner. Após isso,o Scrum propõe a adoção

das seguintes práticas, segundo Schwaber e Beddle (2002):

Backlog do produto: nada mais é que uma lista de requisições existentes

para o produto. Estas requisições são definidas e priorizadas pelo dono do

produto, de acordo com o valor entregue por cada item ao usuário final do

sistema. O backlog é constantemente atualizado durante o projeto, conforme

as necessidades identificadas pelo dono do produto.

Sprints: são intervalos de tempo, de 2 a 4 semanas, correspondentes a uma

iteração, ou ciclo, do Scrum. No final desse período, o produto, ou uma

versão do mesmo, é entregue ao cliente.

Planejamento da sprint: procura planejar detalhadamente a sprint a ser

desenvolvida. São definidos quais itens serão entregues ao final, levando-se

em consideração uma estimativa de tempo feita pelo time de

desenvolvimento.

Reuniões diárias: durante o prazo estabelecido para a sprint, são feitas

diariamente breves reuniões de acompanhamento. Nelas, os membros

relatam o andamento de suas tarefas, informando o que foi feito desde a



última reunião, se existe algum obstáculo, e o que será feito até a próxima

reunião.

Reunião de revisão da sprint: reunião feita ao final da sprint para avaliação

dos resultados obtidos por parte dos envolvidos no projeto.

Ao final da sprint, é gerado um “entregável”, ou seja, um software em

funcionamento de acordo com o que foi solicitado nas tarefas do backlog que

compõem a sprint. Caso o projeto possua mais de uma sprint, ao final de cada uma

delas será gerada uma versão do produto final, conforme mostra Silva (2009).

4 DOCUMENTAÇÃO DE SOFTWARE

Qualquer artefato cuja finalidade seja comunicar alguma informação sobre um

sistema de software faz parte da documentação de um sistema, conforme dito por

Forward (2002). Assim, podem existir documentos referentes a diversos aspectos do

software, como os processos utilizados no seu desenvolvimento, o seu

planejamento, o seu funcionamento e muitos outros.

Segundo Michelazzo (2006), a documentação pode ser dividida, quanto à sua

finalidade, em dois grupos: a documentação técnica, voltada para os desenvolvedores e equipe de TI, e a documentação de uso, voltada para os

usuários. Na documentação técnica, ainda segundo Michelazzo (2006), incluem-se

modelos de dados, dicionários de dados, fluxogramas e o próprio código-fonte com

seus comentários. Já a documentação de uso é constituída principalmente de

manuais que dizem a finalidade do software e como ele deve ser utilizado.

Através da documentação, em suma, a evolução do software é registrada

para etapas posteriores do processo de software, que incluem treinamento,

utilização e manutenção, segundo Sanches (2001). A construção de uma boa

documentação de software mostra-se muito necessária, sobretudo quando é alta a

complexidade do software em questão, como diz Nunes (2005).

Uma documentação de qualidade propicia uma maior organização durante o desenvolvimento de um sistema, facilitando modificações e futuras manutenções no mesmo. Além disso, reduz o impacto da perda de membros da equipe, reduz o tempo de desenvolvimento de fases posteriores, reduz o

tempo de manutenção e contribui para redução de erros, aumentando assim, a qualidade do processo e do produto gerado.(NUNES, 2005, p.25).



A subseção a seguir analisará a importância da documentação técnica do

software, enfatizando a sua fase de manutenção.

4.1 MANUTENÇÃO DE SOFTWARE E DOCUMENTAÇÃO

As atividades de manutenção de um software são caracterizadas pela

modificação de um software já entregue ao cliente, visando a correção de erros,

melhoria em qualquer aspecto, ou ainda para adaptação desse software a um

ambiente que sofreu mudanças como mostrado por IEEE (1998).

Frente à ocorrência dessas mudanças, várias abordagens são possíveis,

como mostram Bennett e Rajlich (2000): descartar o software atual e construir um novo; tornar o software parte de um novo software maior; adiar a manutenção, ou

modificar o software para aumentar sua vida útil. Dentre essas alternativas,

frequentemente a opção escolhida pela empresa será a última, visto que nem

sempre as mudanças são adiáveis ou se dispõe de recursos para construir um novo

software, ainda que parte dele seja reutilizada.

Assim, quando é tomada a decisão de se modificar o software já existente,

surge a necessidade do seu entendimento e de sua estrutura, para que essas mudanças não tragam efeitos colaterais não desejados e previstos. Esse é,

conforme dito anteriormente, um dos aspectos onde a existência da documentação

do software mais auxilia.

Silva (2009) afirma que a preocupação com futuras manutenções é um dos

principais fatores que incentivam o uso de documentação em um projeto de

software. “Nos casos em que a documentação não está disponível, a manutenção

pode se tornar tão complexa quanto o desenvolvimento de um novo sistema” (Silva,

2009, p. 28). Isso é reforçado por Sommerville (2006), que aponta as seguintes

razões para as dificuldades encontradas na fase de manutenção de software:

As várias partes do software foram desenvolvidas por equipes diferentes;

Pode ter sido utilizada uma linguagem ou tecnologia obsoleta;

A documentação existente é inadequada e/ou desatualizada;

Manutenções anteriores alteraram a estrutura do sistema, dificultando o seu

entendimento;



Os dados processados pelo software podem estar em locais distintos, com

estruturas distintas e possuindo, muitas vezes, duplicações, inconsistências e

erros.

Contudo, a existência de documentação não necessariamente atua na

diminuição dos problemas relatados. É necessário que ela esteja bem estruturada

para que venha a contribuir nesse sentido. Souza et al (2005) apontam a existência

de problemas em documentação, como falta de atualização, dificuldade de acesso,

falta de qualidade, desorganização e documentação desnecessária. A subseção a

seguir trata dos principais artefatos utilizados na manutenção de um software.

4.2 PRINCIPAIS ARTEFATOS DE DOCUMENTAÇÃO UTILIZADOS NA

MANUTENÇÃO

Demonstrada a necessidade da existência da documentação de software,

faz-se necessário saber quais são os artefatos mais utilizados nas atividades de

manutenção. Em uma pesquisa realizada por Souza (2005), procurou-se investigar

junto a profissionais que atuam na manutenção de sistemas, qual a documentação

essencial para o propósito de auxiliar o entendimento. Como resultado da pesquisa,

obtiveram-se como artefatos mais importantes:

Código fonte;

Comentários no código fonte;

Modelo lógico de dados;

Diagrama de classes;

Modelo físico de dados;

Diagrama de caso de uso;

Especificação de caso de uso;

Plano de teste de aceitação.

Uma prática também interessante é sugerida por Basili et al (2001), que é a

adoção de um banco de dados de lições aprendidas. Através dessa prática, os

desenvolvedores são estimulados a registrar em um banco de dados os incidentes

que ocorrem para fins de futuras consultas quando ocorrerem situações

semelhantes.



5 DOCUMENTAÇÃO EM EQUIPES ÁGEIS: ESTUDO DE CASO

Esta seção apresenta a exposição de um processo de documentação

utilizado em uma equipe de desenvolvimento de software de Belo Horizonte, que

adota a metodologia Scrum. Será apresentado nas subseções a seguir, de maneira

geral, o processo de desenvolvimento desde a solicitação das atividades pelo dono

do produto até o seu desenvolvimento sem, no entanto, focar em aspectos

gerenciais dessas solicitações. O objetivo é demonstrar as ferramentas e artefatos

utilizados no processo de desenvolvimento. Tal apresentação não é específica de

um projeto, ou seja, o modelo de documentação pode ser utilizado em projetos e equipes diferentes.

É pertinente que se cite que a referida equipe utiliza, na confecção dos seus

softwares, um framework de desenvolvimento, que padroniza os sistemas em

relação à sua arquitetura de um modo geral, e tem sua evolução como um projeto

separado dos demais. Esse framework não possui uma documentação nos moldes

daquela aqui exposta, o que é identificado como um ponto frágil da equipe, que

quando de alguma dúvida relativa ao uso do framework consulta um outro sistema, e não o framework propriamente dito.

Para a existência dessa documentação, o processo deveria ser adaptado,

uma vez que um framework de desenvolvimento não é propriamente um software.

Essa adaptação é apontada nas conclusões como sugestão de trabalho futuro.

5.1 SOLICITAÇÕES DO DONO DO PRODUTO

A entrada de solicitações ocorre por meio do seu cadastro pelo dono do

produto em um software chamado “Solicitações de Serviço”. Esse software

representa uma entrada unificada, por onde passam todas as solicitações, sejam

elas referentes a correções e melhorias em um sistema existente, ou à criação de

novos sistemas.

No cadastro da solicitação, o dono do produto informa dados iniciais

referentes à sua demanda, como o que será feito, eventuais observações, e a

justificativa dessa demanda. É informado também o nível de prioridade dessa



demanda, que pode ser baixo, normal, alto, urgente ou imediato. A Figura 2 mostra

a tela do software onde são feitas essas solicitações.

As solicitações cadastradas farão parte do backlog do produto, e será feito

todo o processo de gerenciamento de backlog proposto no Scrum. Para esse

trabalho, no entanto, caberá ressaltar que essa solicitação tem informações que

podem ser relevantes em fases posteriores do projeto, e constituem, portanto,

artefatos de documentação.

O sistema de solicitações se integra com o Redmine, “uma ferramenta web

flexível para o gerenciamento de projetos” (Redmine, 2016). No processo de

documentação utilizado, o Redmine é também utilizado para fins de documentação.

Essa utilização implicou em uma adaptação da ferramenta, mais especificamente de

seus formulários, para a adequação ao processo proposto.

Cada solicitação cadastrada no sistema de solicitações de serviços será

capturada no Redmine como uma tarefa, ou atividade. Depois de uma análise do

dono do produto, em conjunto com o Scrum Master e o time de desenvolvimento,

essa solicitação se tornará uma atividade, ou tarefa, de desenvolvimento a ser feita

e gerenciada pelo Redmine, a depender do resultado dessa análise, que pode, também, concluir pela rejeição dessa solicitação.



Figura 2 - Tela de cadastro utilizada para a criação de solicitações.Fonte: (Próprio autor, 2016).

5.2 TAREFAS DE DESENVOLVIMENTO

Depois de atividades relativas ao planejamento propostas pelo Scrum, como

estimativa de prazo e custos, as quais não serão abordadas nesse trabalho, a

solicitação será uma tarefa de desenvolvimento gerenciada no Redmine. Tal tarefa

será atribuída para execução por um membro do time dentro de uma sprint.

Conforme dito anteriormente, o Redmine é utilizado nesse caso para, além de

apoiar o gerenciamento de projetos, servir de apoio á documentação. Assim, junto

ao projeto do sistema em questão, está um subprojeto referente apenas a atividades

da sua documentação. Portanto, junto à tarefa de desenvolvimento, estarão as

subtarefas de documentação, que fazem parte do progresso da tarefa de

desenvolvimento, ou seja, esta última só será concluída quando as subtarefas de

documentação também o forem.



Há, então, uma subtarefa referente à documentação propriamente dita, e

outra que descreve o seu teste. Um detalhamento dessas subtarefas é feito nas

subseções a seguir. Cabe ressaltar que a criação dessas atividades (documentação

e teste) será feita apenas quando da criação de um novo caso de uso do sistema.

Caso a atividade de desenvolvimento se refira a uma modificação, as atividades de

documentação e testes serão atualizadas, e não criadas.

É importante ressaltar, ainda, que o preenchimento dessas atividades se

baseará em uma especificação previamente feita por um analista de requisitos. Para

essa especificação, o processo de documentação não define um artefato específico.

5.2.1 SUBTAREFA DE DOCUMENTAÇÃO

Nessa atividade, são registradas informações técnicas referentes ao

desenvolvimento. O preenchimento dessas informações é feito pelo próprio

desenvolvedor. São elas:

Descrição: o que é feito através do caso de uso.

Estrutura do banco de dados: tabelas do banco de dados utilizadas no caso

de uso, bem como seus relacionamentos. Regras de negócio: descrição de regras de negócio utilizadas no código fonte

para o desenvolvimento do caso de uso.

Casos de uso relacionados: enumeração de outros casos de uso que estejam

relacionados ao atual.

A Figura 3 mostra um exemplo de tarefa de documentação.



Figura 3 - Exemplo de subtarefa de documentação existente no Redmine.Fonte: (Próprio autor, 2016).

5.2.2 SUBTAREFA DE TESTENessa atividade, são descritos os possíveis casos de teste para a validação

do caso de uso. A definição dos casos de teste não é feita pelo desenvolvedor, que

apenas irá registrar, para a conclusão dessa subtarefa, a realização dos testes com

sucesso. Essa definição é feita conjuntamente pelo responsável pela análise do

projeto e o responsável pelos testes.

Portanto, se um caso de uso realiza a inclusão, alteração e exclusão de uma

determinada entidade no banco de dados, os casos de teste contemplarão esses



três casos, respeitando as regras de negócio existentes. A Figura 4 apresenta um

exemplo de subtarefa de teste.

Figura 4 - Exemplo de subtarefa de teste existente no Redmine.Fonte: (Próprio autor, 2016).

5.3 WIKI DO PROJETO

No projeto existente no Redmine, existe uma seção destinada à confecção de

uma wiki do projeto, um repositório de documentos colaborativo, nos moldes

existentes na web. Essa wiki faz parte da documentação do sistema, e se destina a

armazenar informações gerais do sistema, e pode ser alimentada por todos os

membros da equipe, sempre que houver alguma informação útil aos demais

membros.

5.4 CÓDIGO FONTE E DIAGRAMAS

Além dos itens já mencionados, há no repositório de controle de versão, juntamente ao código fonte do sistema, um diretório de documentação, que terá o

diagrama de classes da aplicação, o diagrama de casos de uso, e eventuais

documentos que se julgue importantes, como por exemplo atas de reuniões.

6 RESULTADOS

O processo de desenvolvimento estudado utiliza os principais conceitos e

critérios aconselhados pelo Scrum. Nele são percebidos claramente os papéis e

conceitos trazidos por essa metodologia. Destaca-se a maneira com que é



controlado o backlog, através de um sistema próprio da empresa, utilizado para o

cadastro de requisições. Essa ferramenta facilita o gerenciamento das requisições

do usuário, uma vez, que é diretamente integrado à ferramenta de gerenciamento - o

Redmine. A adoção do processo de documentação estudado se deu utilizando uma

das características dessa ferramenta: a adaptabilidade.

Através de uma adaptação, o Redmine passou a apoiar, além do

gerenciamento de projetos, a documentação do software desenvolvido.

Comparando-se os artefatos utilizados no estudo de caso com aqueles apontados

na revisão bibliográfica como sendo os mais importantes para a manutenção de

software, percebe-se a adequação do processo exposto nessa diretriz, de

entendimento do sistema para realização de modificações posteriores.

Outra verificação feita foi a de que a documentação, nesse caso, não diz o

que fazer, mas diz o que foi feito. Essa mudança é, essencialmente, aquela proposta

pelas metodologias ágeis em relação à documentação: deve-se priorizar a resposta

a mudanças em vez de se seguir um plano rígido.

No processo de documentação estudado, é também verificado que todos os

membros da equipe são responsáveis, assim como pelo software, pela sua documentação, que auxiliará a equipe em momentos posteriores, especialmente na

manutenção.

Por fim, tem-se nesse processo uma maneira encontrada para conciliar os

preceitos ágeis também na documentação do software. A sua utilização não é

universal, ou seja, a depender da realidade de cada equipe ou empresa, deverá ser

utilizada a documentação de maneira diferente. No entanto, essa diferença dirá

respeito apenas a especificidades, como por exemplo ferramentas utilizadas, mas não no objetivo geral da documentação dentro do processo de desenvolvimento de

software.

7 CONCLUSÕES

As metodologias ágeis trouxeram uma nova proposta para o desenvolvimento

de software. Através delas, passou-se a valorizar mais que outras coisas o

funcionamento correto do software, que é o que gera valor ao cliente, usuário do

software. Uma diferença substancial da proposta ágil é a maneira como se trata a



documentação do software. A proposta ágil é a de documentação estritamente útil,

mas não de documentação inexistente.

Foi demonstrado, através de revisão bibliográfica, que a ausência total de

documentação é prejudicial a um projeto de software, sobretudo na fase de

manutenção, onde os custos de mudança e entendimento são altos. Assim, deve-se

ter como artefatos estritamente aquilo que será utilizado.

Um artefato importante levantado pelas pesquisas citadas nesse trabalho é o

próprio código fonte da aplicação. Desta forma, é importante que o mesmo adote

boas práticas de padronização e legibilidade, pois assim é minimizado o esforço de

se documentar externamente a ele.

Através do estudo de caso apresentado nesse artigo, pode-se concluir que a

adoção de práticas ágeis não impede a adoção de documentação. Ao contrário, as

práticas ágeis incentivam a uma mudança no papel da documentação no processo

de desenvolvimento de software. O desenvolvimento ágil não se prende àquilo que

está escrito, mas se preocupa em estar preparado para as mudanças, e deve

documentá-las para que posteriores fases do projeto não sejam prejudicadas pela

falta de conhecimento e/ou entendimento.Outra perspectiva alterada pela agilidade em relação à manutenção é a

colaboração entre os membros para se atingir um objetivo. Todos os membros

contribuem para a existência de um software de qualidade e, como parte do

software, uma documentação de qualidade. Na medida em que todos entendem a

importância da documentação, especialmente para fases futuras, todos estarão

empenhados na sua constante atualização e melhoria.

Por fim, atingindo os objetivos inicialmente propostos e respondendo à questão de pesquisa, verificou-se ser possível a adoção das duas abordagens -

documentação de software e metodologias ágeis - através de uma mudança no

papel desempenhado pela documentação. Uma documentação ágil torna-se parte

do desenvolvimento, e não uma atividade externa que determina rigidamente aquilo

que deve ser feito. Mostra-se, portanto, a interação entre os membros da equipe

atuando na construção de uma documentação, e, sobretudo, contribuindo para a sua

qualidade.



Como trabalho futuro, sugere-se a verificação da usabilidade da ferramenta

utilizada para a documentação - Redmine - e uma possível sugestão de melhoria

nessa usabilidade. Sugere-se, também a verificação da efetividade desse processo

na manutenção de algum sistema que o utilize, através de métricas a serem

definidas. Pode-se citar, ainda, como sugestão de trabalho futuro, a definição de um

processo de documentação para o framework de desenvolvimento, que pode ser

uma adaptação daquele exposto nesse trabalho.

8 REFERÊNCIAS BIBLIOGRÁFICAS

BASILI, Victor; COSTA, Patricia; LINDVALL, Mikael; MENDONÇA, Manoel;SEAMAN, Carolyn; TESORIERO, Rosanne; ZELKOWITZ, Marvin. An ExperienceManagement System for a Software Engeneering Research Organization. 26th

Annual NASA Goddard Software Engineering Workshop. Greenbelt, Maryland, USA.2001.

BECK, Kent; ANDRES, Cynthia. Extreme programming explained: embracechange. 2nd edition. Massachussets, USA. Pearson Education. 2004.

BECK, Kent. et al. Manifesto for Agile Software Development. Disponível em<http://agilemanifesto.org >. Acesso em: 04 de janeiro de 2016.

BENNETT, Heith; RAJLICH, Vaclav. Software Maintenance and Evolution: aRoadmap. Conference on the future of software engineering. Limerick, Ireland.2000.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. Rio deJaneiro. Elsevier. 2006.

DENNIS, A.; WIXON, H. B.. Análise e projeto de sistemas. 2. ed. Rio de Janeiro.LTC. 2011.

FORWARD, Andrew. Software Documentation - Building and MaintainingArtefacts of Communication. Universidade de Ottawa. Toronto, Canadá. 2002.

FOWLER, Martin. The New Methodology. 2005. Disponível em:<http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: 11 de abrilde 2016.

GONZALES, Thalisa Silva de Sotomayor. Metodologia Ágil com Scrum: Estudodo Processo de Implantação em uma Software House de Pequeno Porte.Universidade Estadual de Goiás. 2015.

HIGHSMITH, Jim. Agile Software Development Ecosystems. Addison-Wesley.Massachussets, USA. 2002.

http://www.martinfowler.com/articles/newMethodology.html



HUANG, Shihong; TILLEY, Scott. Towards a Documentation Maturity Model. Proceedings of the 21st annual international conference on Documentation. NewYork, USA. 2003.

IEEE. Std 1219 - IEEE Standard for Software Maintenance. Institute of Electricaland Eletronic Engineers. New York, USA. 1998.

LUDVIG, Diogo; REINERT, Jonatas Davson. Estudo do uso de MetodologiasÁgeis no Desenvolvimento de uma Aplicação de Governo Eletrônico. UFSC.Florianópolis. 2007. Disponível em:<https://projetos.inf.ufsc.br/arquivos_projetos/projeto_589/Artigo_Diogo_Jonatas.pdf >. Acesso em: 11 de abril de 2016.

MICHELAZZO, Paulino. Dicas para Documentação de Softwares. 2006.

Disponível em<http://www.michelazzo.com.br/pt-br/dicas-para-documentacao-de-softwares/>. Acesso em: 11 de abril de 2016.

MILLER, David. Slaying the Dragons: an Agile Approach to SoftwareDevelopment – A Management Overview. Disponível em<http://www.cirrustech.com.au/downloads/slayingdragons.pdf>. Acesso em: 11 deabril de 2016.NUNES, VANESSA BATTESTIN. Integrando Gerência de Configuração deSoftware, Documentação e Gerência de Conhecimento em um Ambiente deDesenvolvimento de Software. UFES. Vitória, ES. 2005.

OLIVEIRA, Ebenezer Silva de. Uso de Metodologias Ágeis no Desenvolvimentode Software. UFMG. Belo Horizonte. 2003.

PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrumpara Gerenciar Projetos de Forma Ágil. 2007. Disponível em:<http://siq.com.br/model/arquivos/downloads/EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf>. Acesso em: 11 de abril de 2016.

PRIKLADNICKI, Rafael; WILLI, Renato; MILANI, Fabiano. Métodos Ágeis para

desenvolvimento de software. Bookman. Porto Alegre. 2014.

REDMINE. 2016. Disponível em <http://www.redmine.org>. Acessado em: 11 de abrilde 2016.

SANCHES, Rosely. Qualidade de Software: Teoria e Prática. Prentice Hall. SãoPaulo. 2001.

SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum.Prentice Hall. Pennsylvania, USA. 2002.

http://www.redmine.org/

http://siq.com.br/model/arquivos/downloads/EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf

http://siq.com.br/model/arquivos/downloads/EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf

http://www.cirrustech.com.au/downloads/slayingdragons.pdf

http://www.michelazzo.com.br/pt-br/dicas-para-documentacao-de-softwares/

https://projetos.inf.ufsc.br/arquivos_projetos/projeto_589/Artigo_Diogo_Jonatas.pdf



SCHWABER, Ken; SUTHERLAND, Jeff. Guia do scrum. Scrum Alliance, 2013.Disponível em:<http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf> Acesso em:11 de abril de 2016.

SILVA, Fernando Selleri. Uso de Representação de Conhecimento paraDocumentação em Metodologias Ágeis. PUC RS. Porto Alegre. 2009.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis eTradicionais para o Desenvolvimento de Software. Unipac. Conselheiro Lafaiete.2004.SOMMERVILLE, Ian. Software Engineering. 8th edition. Addison-Wesley.Massachussets, USA. 2006.

SOUZA, Sergio Cozzetti; ANQUETIL, Nicolas; OLIVEIRA, Kathia M. Study of theDocumentation Essential to Software Maintenance. 23rd Annual InternationalConference on Design of Communication: Documenting and Designing for PervasiveInformation. Coventry, UK. 2005.

STEFFEN, Juliana Berossa. O que São Essas Tais Metodologias Ágeis? IBM,2012. Disponível em :<https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en> Acesso em: 11de abril de 2016.

SUTHERLAND, Jeff; SCHWABER, Ken. The Scrum Papers: Nuts, Bolts, andOrigins of an Agile Process. Jeff Sutherland. Massachussets, USA. 2007.

ZIV, Hadar et al. The Uncertainty Principle in Software Engineering. 19thInternational Conference on Software Engineering. University of California.California, USA. 1996.

https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en

https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en

http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Documents

Métodos ágeis: Uma análise geral sobre a documentação aplicada ao desenvolvimento de software