FACULDADE FORTIUM
LEANDRO MEDEIROS DA SILVA DE LIMA
COMPARATIVO ENTRE AS METODOLOGIAS ÁGEIS E
AS TRADICIONAIS NO DESENVOLVIMENTO DE
SOFTWARE NA ADMINISTRAÇÃO PÚBLICA
BRASÍLIA­DF
2015
LEANDRO MEDEIROS DA SILVA DE LIMA
Comparativo Entre as Metodologias Ágeis e as Tradicionais no
Desenvolvimento de Software na Administração Pública
Trabalho
de
Conclusão
de
Curso
apresentado ao curso de Pós­Graduação em
Gestão e Desenvolvimento de Sistemas de
Informação da Faculdade Fortium, como
requisito parcial para obtenção do título de
Especialista em Gestão e Desenvolvimento de
Sistemas de Informação.
Orientador: MSc. César Augusto Borges de
Andrade.
BRASÍLIA­DF
2015
LEANDRO MEDEIROS DA SILVA DE LIMA
Comparativo Entre as Metodologias Ágeis e as Tradicionais no
Desenvolvimento de Software na Administração Pública
Trabalho
de
Conclusão
de
Curso
apresentado ao curso de Pós­Graduação em
Gestão e Desenvolvimento de Sistemas de
Informação da Faculdade Fortium, como
requisito parcial para obtenção do título de
Especialista em Gestão e Desenvolvimento de
Sistemas de Informação.
Aprovado em _____/_____/______.
Banca Examinadora
_______________________________________________________________
Presidente: Prof. MSc. César Augusto Borges de Andrade - Faculdade Fortium
(Orientador)
____________________________________________________________________
Membro Titular: Prof. Dr. Marcio de Carvalho Victorino - Universidade de Brasília
_______________________________________________________________
Membro Titular: Prof. MSc. Rômulo Ferreira dos Santos - Faculdade Fortium
_______________________________________________________________
Membro Suplente: Prof. MSc. Gleyson Azevedo da Silva - Faculdade Fortium
BRASÍLIA­DF
2015
Comparativo Entre as Metodologias Ágeis e as Tradicionais
no Desenvolvimento de Software na Administração Pública
Leandro Medeiros da S. de Lima
Faculdade FORTIUM
Especialização em Gestão e Desenvolvimento de Sistemas de Informação
SGAS Quadra 616 Módulo 114, Asa Sul ­ Brasília/DF ­ CEP 70.200­760
Abstract. This article deals with the use of agile methodologies by the Federal
Public Administration (APF) in software development, considering the
characteristics inherent to this sector which differs profoundly from the
private sector. The study addresses the concepts of traditional and agile
development methodologies and shows a comparison between them. Finally, it
should be noted that under the APF was found that to use an agile
development methodology, it should be compatible with the current Brazilian
legislation, since there is no distortion or loss of the essence of the
methodology.
Keywords: software process; agile development; tradicional development;
public administration
Resumo. O presente artigo trata da utilização das metodologias ágeis pela
Administração Pública Federal (APF) no desenvolvimento de software,
levando em consideração as características inerentes à este setor que diverge
profundamente do setor privado. O estudo aborda os conceitos sobre
metodologias tradicionais e ágeis de desenvolvimento e faz um comparativo
entre elas. Por fim, cumpre ressaltar que no âmbito da APF constatou­se que
para se utilizar uma metodologia de desenvolvimento ágil, esta deverá se
compatibilizar com a legislação pátria vigente, desde que não haja
descaracterização ou perda da essência da metodologia.
Palavras­chave:
processo
de
software;
desenvolvimento
desenvolvimento tradicional; administração pública.
ágil;
1. Introdução
Em um mercado competitivo, os softwares devem responder de forma rápida às
mudanças requeridas por seus usuários, de modo que elas acrescentem valor ao negócio
da organização, gerando um diferencial sobre a concorrência. No setor público
brasileiro a realidade difere profundamente, haja vista que nesse setor os sistemas
devem ser construídos visando ao atendimento do interesse público, levando em
consideração os programas e as metas governamentais, o orçamento público e a
legislação pátria existentes.
Nestes termos, o próprio contexto em que a Administração Pública1 está inserida
eleva bastante as restrições impostas à construção de software. Sendo assim, é
fundamental um processo de desenvolvimento que aborde necessariamente as boas
práticas de mercado, para que os sistemas consigam atender plenamente às expectativas
de seus usuários, no prazo, custo e qualidade definidos.
Atualmente, existem duas correntes principais para o desenvolvimento de
software conhecidas como metodologias tradicionais e metodologias ágeis. A primeira
tem por objetivo a construção do software seguindo um modelo de processo definido
previamente em etapas, ou seja, a cada estágio do desenvolvimento gera­se um
entregável que serve de insumo para o próximo estágio do processo; o software
operacional é disponibilizado após a conclusão de todos estes estágios. A segunda visa a
construção do software iterativamente, de modo que a cada iteração um produto
operacional seja disponibilizado para seus usuários.
Neste cenário, ocorre a indagação: qual destas metodologias é a melhor? Como
resposta, vários autores apontam que a melhor abordagem para se desenvolver software
depende de sua natureza, do contexto no qual ele será desenvolvido e das características
da organização como maturidade da equipe, requisitos externos e formas de contrato.
Ainda alguns ressaltam, como Sommerville (2011) e Pressman (2011), que a melhor
abordagem seria a adoção das melhores características existentes em ambas as
metodologias.
Considerando a Administração Pública Federal (APF), a aplicação dos métodos
ágeis na esfera pública vem sendo, recorrentemente, objeto de estudo do Tribunal de
Contas da União (TCU). Nos estudos levantados pelo próprio Tribunal, constatou­se
que é viável a aplicação dos métodos ágeis na APF desde que não se deixem de
observar os fundamentos legais vigentes.
O papel do referido tribunal na APF acerca do tema é fundamental, uma vez que
este órgão vem realizando fiscalizações e auditorias em alguns de seus jurisdicionados
com o objetivo de estudar a aplicação dessas metodologias na esfera pública federal,
como está registrado no relatório TC 010.663/2013­4, com destaque para o Banco
Central do Brasil (Bacen) que possui expertise na adoção dessas metodologias.
Impende ressaltar que nos termos constitucionais, o TCU é o responsável por
realizar o controle externo técnico de modo a fiscalizar nos aspectos contábeis,
operacionais, fiscais, organizacionais e patrimoniais o erário público. Ele ainda é
responsável por verificar se os recursos públicos estão sendo bem aplicados e da forma
mais eficiente possível. Depreende­se daí que, no tocante às metodologias ágeis, esse
tribunal estude a forma mais viável e eficiente para a aplicação destas metodologias no
âmbito público.
De toda forma, o artigo propõe que a utilização destas metodologias são viáveis
e importantes na APF para a obtenção da eficiência, da economicidade e da qualidade
1 Segundo Pietro (2011), divide­se em dois sentidos: em sentido objetivo, material ou funcional, a
Administração Pública pode ser definida como a atividade concreta e imediata que o Estado
desenvolve, sob regime jurídico de direito público, para a consecução dos interesses coletivos. Em
sentido subjetivo, formal ou orgânico, pode­se definir Administração Pública, como sendo o conjunto
de órgãos e de pessoas jurídicas aos quais a lei atribui o exercício da função administrativa do Estado.
dos softwares produzidos para o setor público e no setor público.
Neste ínterim, o presente estudo está organizado da seguinte forma: após a
introdução, a Seção 2 tem o intuito de esclarecer ao leitor sobre as definições de
processo de software e modelo de processo de software. Ainda nesta seção, o artigo
aborda os principais modelos de processo utilizados até então, tais como: o modelo
sequencial linear, os modelos incrementais, os modelos evolucionários e os modelos
especializados, cujas contribuições e dificuldades são apresentadas no decorrer do
estudo. Já na Seção 3, é feita uma análise do desenvolvimento ágil abordando a
programação extrema e o Scrum, ambos bastante em voga na atualidade. Por fim, segue
a Seção de Conclusão na qual trata do desenvolvimento de software na Administração
Pública realizando, assim, as considerações finais sobre o estudo.
2. Processos de Software
Conforme Pressman (2011), processo é um conjunto de atividades, ações e
tarefas realizadas na criação de algum produto de trabalho. De forma análoga, o
processo de software é um conjunto de atividades associadas que levam à construção de
um produto de software. Esse processo não é uma prescrição rígida, mas é algo
adaptável que possibilita a equipe de desenvolvimento selecionar as ações e tarefas mais
adequadas para a entrega do software dentro do custo, prazo e qualidade acordados.
As atividades dos processos podem variar em quantidade e em nomenclatura a
depender do autor que as mencione, porém de forma geral os processos de software
possuem quatro atividades fundamentais que são: (1) Especificação de Software –
define as necessidades e restrições do sistema, (2) Projeto e Implementação de Software
– analisa as necessidades e as restrições do sistema e o constrói baseado nas suas
especificações, (3) Validação de Software – garante que o sistema atende ao solicitado
pelo cliente e (4) Evolução de Software – estipula que o software deverá estar apto às
necessidades de mudança do cliente.
Não obstante, os processos de softwares são complexos em si mesmos pois são
frutos do intelecto humano e depende das pessoas para tomar decisões e fazer
julgamentos. Um processo será mais bem empregado em relação à outro dependendo
das características do sistema a ser desenvolvido, portanto não há um processo de
software ideal e sim o mais apropriado ou adequado. Por exemplo, sistemas críticos
necessitam de um processo de desenvolvimento mais formal, enquanto os sistemas
negóciais cujos requisitos são alterados com maior frequência se encaixam melhor
numa abordagem menos formal e mais flexível.
Importantes autores, como Sommerville (2011) e Pressman (2011), destacam
dois tipos de processos de software mais comuns: os processos dirigidos a planos,
também conhecidos como processos prescritivos ou processos preceptivos, e os
processos ágeis. Os primeiros definem um fluxo de processo previamente acertadas que
têm suas atividades definidas com antecedência cujo progresso é avaliado comparando
seu andamento atual com o planejamento inicial. Os segundos, são mais flexíveis de
modo a facilitar a alteração do processo para atender às necessidades prioritárias dos
usuários. Vale lembrar o que menciona Boehm (1988) em que cada abordagem é
apropriada para diferentes tipos de software. Geralmente, é necessário encontrar um
equilíbrio entre os processos dirigidos a planos e os processos ágeis.
Por fim, as organizações buscam adaptá­los à suas realidades e padronizá­los na
medida do possível. Isso faz com que seus esforços sejam dispendidos com a melhoria
do processo introduzindo novos métodos e técnicas.
2.1. Modelos de Processos de Software
Um modelo é uma abstração dos aspectos relevantes de uma realidade. No
desenvolvimento de software, existem vários modelos que expressam de forma
simplificada o meio pelo qual o software será elaborado de modo que suas atividades
pormenorizadas não são destacadas, mas somente o aspecto estrutural do modelo. O
presente estudo abordará os modelos tradicionais, também conhecidos como sequencial
ou cascata, os incrementais, os evolucionários, os especializados e os ágeis.
Os modelos supracitados, embora enfatizem determinados aspectos no
desenvolvimento de software não são exclusivos, visto que resultados surpreendentes
podem ser obtidos combinado­os em suas melhores características. Por exemplo,
suponha que para a construção do software X, um sistema de grande porte com vários
subsistemas, seja utilizado o modelo tradicional por conta da melhor visibilidade deste
processo cujas etapas são bem definidas. No entanto, pode­se utilizar uma metodologia
evolucionária ou um incremental para a construção de seus subsistemas, pois eles estão
sujeitos à maior volatilidade dos requisitos do usuário.
2.1.1. Modelo Sequencial Linear ou Cascata
O Modelo em Cascata, também chamado de Ciclo de Vida Clássico, foi
inicialmente proposto por Winston Royce na década de 70 e continha sete etapas bem
definidas. Desde a sua criação, os diversos autores que o abordaram realizaram nele
pequenas variações, sejam na quantidade ou no objetivo das etapas, porém a essência
deste modelo permanece a mesma.
Tal modelo segue um fluxo sequencial linear e suas etapas são distintas uma das
outras, elas devem ser previamente planejadas antes do início do trabalho. Desta forma,
a etapa posterior não deve iniciar antes que a anterior termine classificando­se, portanto,
como dirigido a planos. Contudo, a prática tem demonstrado que essas etapas se
sobrepõe em alguns momentos.
Na Figura 1 é exibido o Modelo em Cascata mencionado em Sommerville
(2011). De acordo com o renomado autor o processo possui cinco etapas:
1. Definição de Requisitos – tem por objetivo estabelecer a compreensão do
sistema a ser construído entre usuários e desenvolvedores. Nesta etapa,
os requisitos são expostos e as restrições ao sistema estabelecidas;
2. Projeto do Software – tem por objetivo elaborar modelos os quais
representam a estrutura do sistema em diversas perspectivas,
considerando os aspectos de hardware e software, plataforma de
desenvolvimento e ambiente de execução. Em suma, visa estabelecer um
projeto de solução do um problema a ser resolvido;
3. Implementação e Teste de Unidades – esta etapa consiste na construção
efetiva do sistema e os testes unitários garantem que as funcionalidades
do sistema atendem a especificação delas;
4. Integração e Teste de Sistema – as unidades de testes individuais são
integradas e são testadas como um sistema completo. Isso garante que as
funcionalidades em conjunto representam os requisitos estabelecidos em
(1); e
5. Operação e Manutenção – o sistema entra efetivamente em produção2,
no qual ele é instalado no ambiente real de uso. Erros podem ser
descobertos, e melhorias são identificadas em razão das novas
necessidades de seus usuários.
Figura 2.1. Modelo em Cascata.
Fonte: (SOMMERVILLE, 2011, p.20)
A título de comparação a Figura 2 exibe o modelo em cascata definido por
Pressman (2011). De acordo esse autor, o modelo também apresenta as cinco etapas
sequencializadas, uma iniciando após o término da outra, porém perceba que apenas a
nomenclatura diverge da mencionada mencionada na Figura 1, mantendo em essência o
modelo proposto por Royce (1970).
Em princípio, o referido modelo é recomendado para o desenvolvimento de
sistemas cujos requisitos sejam pouco voláteis e, por ser sequencial, sua documentação
é produzida a cada fase, desta forma pode­se monitorar o processo conforme o
planejado e sua gerência fica facilitada. Essas são as principais vantagens deste modelo.
Por exemplo, sistemas com requisitos rígidos de segurança, desempenho e
confiabilidade, geralmente, utilizam este processo, pois tais sistemas exigem uma
gerência mais rígida sobre o caminhar do desenvolvimento do sistema e exigem
requisitos conhecidos e estáveis, logo no início do projeto.
2 Um sistema somente gera valor para seus usuários após sua entrada efetiva em produção. Ao entrar
em produção o sistema está em pleno funcionamento no ambiente real de uso.
Figura 2.2. Modelo em Cascata.
Fonte: (PRESSMAN, 2011, p. 60)
No entanto, a maioria dos usuários não conhece logo no início do
desenvolvimento todos os requisitos de um sistema, tampouco os conhece em um nível
suficientemente apropriado. Portanto, em projetos reais dificilmente os sistemas
seguirão o fluxo sequencial estático proposto pelo Modelo em Cascata, além do mais há
a dificuldade em se reduzir os riscos do desenvolvimento, pois somente após a
publicação do sistema no ambiente real é que os usuários conseguirão avaliar os
resultados. Desta forma, o risco de o sistema não contemplar as necessidades dos
clientes é alta e de custo elevado.
2.1.2. Modelo Incremental
O Modelo Incremental aplica sequências lineares iterativas à medida que o
tempo avança, na qual cada incremento adiciona um produto operacional que será
entregue ao usuário (Figura­3). Ou seja, este modelo passa por uma sequência de
atividades várias vezes até que o sistema seja completamente construído funcionalidade
a funcionalidade, incremento a incremento.
Figura 2.3­ Modelo Incremental
Fonte: (PRESSMAN, 2011, p. 61)
Quando comparado ao modelo em cascata, o modelo incremental apresenta as
seguintes vantagens:
(1) Menor custo para adicionar mudanças;
(2) É mais fácil obter feedback do cliente sobre o que já foi implementado; e
(3) O software consegue agregar valor ao negócio do cliente mais rapidamente.
Todavia de acordo com Sommerville (2011), este tipo de metodologia tende a
degradar a estrutura do sistema, pois adicionar novos incrementos torna­se uma tarefa
onerosa e difícil sendo necessários, para manter a qualidade do código­fonte, investir
tempo e dinheiro com a refatoração constante do código. Um outro problema é a falta
de visibilidade do processo para os gerentes, uma vez que se torna inviável a produção
de documentos que reflitam as várias versões do sistema.
2.1.3. Modelos Evolucionários
Os modelos evolucionários são bastante semelhantes aos modelos incrementais
vistos na seção anterior. Ambos são iterativos, porém os primeiros entregam uma versão
cada vez mais completa do software, não necessariamente prontos para serem
utilizados; e os segundos entregam um produto operacional a cada iteração, ou seja,
adicionam um incremento utilizável de software.
Na Figura­2.4 pode­se observar uma analogia entre as duas abordagens: na parte
superior a abordagem incremental (Incremental plan, em inglês) e na parte inferior a
evolucionária (Iterative plan, em inglês). Naquela, observa­se a imagem crescer com a
adição de incrementos, seria a analogia com a funcionalidade utilizável do software, até
o sistema se tornar completo por inteiro. Ao passo que nessa, a imagem vai se tornando
cada vez mais completa no decorrer das iterações.
Figura 2.4­ Abordagem Incremental x Abordagem
Evolucionária
Fonte: http://www.applitude.se
Observadas tais diferenças, Pressman (2011) define dois tipos principais de
modelos evolucionários: a Prototipação e o Espiral. A prototipação visa ao
esclarecimento de dúvidas que os engenheiros de softwares, clientes e desenvolvedores
possuem acerca de uma solução de software; e o modelo espiral estabelece um processo
que combina aspectos da prototipação com os aspectos sistemáticos e controlados do
modelo em cascata, desenvolvendo versões cada vez mais completas do software.
A prototipação pode entendida como um paradigma 3. Porém ela é mais
comumente utilizada como uma técnica, passível de ser aplicada nos demais modelos
supracitados para ajudar a elicitar os requisitos dos stakeholders4, validá­los ou estudar
as soluções para um problema específico, como avaliar o desempenho de um
algorítimo.
De acordo com Sommerville (2011), a prototipação possui cinco etapas que
estão demonstradas na Figura­4. Para o referido autor, a etapa – (1) Estabelecer
objetivos do protótipo ­, deve estabelecer os objetivos do protótipo logo no início do
processo, de tal forma que sua função seja exposta aos principais interessados. Por
exemplo, se ele servirá para demonstrar uma interface visual ou o funcionamento de
determinada funcionalidade. Já a fase – (2) Definir a funcionalidade do protótipo –,
busca­se determinar quais funcionalidades serão demonstradas no protótipo e quais
delas não serão contempladas. Essa etapa é importante para a economia dos recursos a
serem dispendidos na elaboração do protótipo seja na redução do cronograma, seja na
supressão do tratamento dos erros ou no relaxamento dos requisitos não funcionais. Na
etapa seguinte, (4) desenvolve­se o protótipo e por último (5) realiza­se uma avaliação
afim de descobrir possíveis erros e omissões de requisitos e pontos de melhorias em
uma interface.
Figura 2.5­ Processo de desenvolvimento de protótipo
Fonte: (SOMMERVILLE, 2011, p. 30)
Em geral, os protótipos podem ser classificados como exploratórios – que
servem para avaliar determinada característica do software e, após isso, são descartados
­, ou evolutivos ­ que podem evoluir até tornar­se um sistema real para o uso.
3 Paradigma, no âmbito da engenharia de software pode ser entendido como a abordagem, um modelo.
4 Stakeholders podem ser definidos como os principais interessados em um software. Podem ser
clientes, analistas, gerentes.
Por fim, esta abordagem apresenta algumas dificuldades como:
1. Os interessados podem enxergar os protótipos como softwares operacionais.
Isto torna­se um problema porque os protótipos, em geral, não são
construídos visando o desempenho, a qualidade e segurança de um sistema;
2. Os engenheiros se comprometem a entregá­lo o mais rápido possível,
comprometendo a qualidade final do software.
Nos termos do Modelo Espiral, inicialmente proposto por Barry Boehm em
1988, o desenvolvimento de software é tratado como uma espiral na qual cada volta
nela representa uma fase do desenvolvimento. Nesse sentido, os ciclos mais internos
podem verificar a viabilidade do software, os seguintes os requisitos do sistema, os
próximos o projeto do sistema, e assim por diante. Uma característica fundamental deste
modelo, que o distingue dos demais, é seu tratamento explícito dos riscos ao assumir
que as mudanças são resultados dos riscos inatos a todos os projetos.
Figura 2.6­ Modelo em Espiral de Boehm
Fonte: (SOMMERVILLE, 2011, p. 33)
A Figura 2.6 exibe o Modelo em Espiral, nele observa­se uma divisão em quatro
setores, sendo que o processo começa no quadrante superior esquerdo e prossegue no
sentido horário para os demais quadrantes. Cada quadrante representa uma etapa do
processo:
1. Definição de Objetivos. Neste setor os objetivos para essa fase do projeto
são levantados, os requisitos elicitados e os riscos são identificados. Em
função dos riscos identificados, uma estratégia alternativa pode ser traçada
em função deles;
2. Avaliação e Redução dos Riscos. Nesta etapa, cada risco identificado é
avaliado e medidas saneadoras são tomadas para a redução ou eliminação
destes riscos;
3. Desenvolvimento e Validação. Após a avaliação dos riscos é escolhida uma
abordagem para o desenvolvimento do sistema. Caso o projeto tenha seus
requisitos bem conhecidos e relativamente estáveis, o modelo em cascata
pode ser utilizado, caso o projeto tenha os requisitos instáveis e com riscos
elevados, uma abordagem ágil pode ser a melhor opção; e
4. Planejamento. Nesta etapa é realizada uma revisão do projeto e uma decisão
é tomada acerca da continuidade ou não dele, caso se opte pelo
prosseguimento do projeto, novos planos são elaborados para a fase
seguinte.
Nas palavras de Pressman (2011):
“Este modelo é uma abordagem realista para o desenvolvimento de software em larga escala.
Pelo fato de o software evoluir à medida que o processo avança, o desenvolvedor e o cliente
compreendem e reagem melhor aos riscos em cada nível evolucionário.”
(PRESSMAN, ROGER. 2011. p. 66).
Contudo, este modelo pode exige considerável avaliação do risco pois seu fluxo
depende disto para que ocorra com sucesso. Um risco ignorado pode se tornar um
grande problema caso não seja bem administrado.
2.1.4. Modelos Especializados
Dentre os modelos especializados, o que mais se destaca é o Modelo de
Desenvolvimento Baseado em Componentes (em inglês, Component­Based Software
Engineering – CBSE). Há, ainda, os modelos de métodos formais e os modelos de
desenvolvimento de software orientado a aspectos. Porém estes dois últimos não serão
abordados por se afastarem demasiadamente do escopo proposto no presente estudo.
A CBSE é o processo de definir, implementar, integrar ou compor componentes
independentes em sistemas. Componente é uma abstração de software que realiza
determinada tarefa específica, mantendo oculto seus detalhes de implementação e lógica
negocial e expondo serviços através de interfaces bem definidas às quais são pontos de
integração com os sistemas.
Por conseguinte, Sommerville (2011) elenca cinco características para melhor
definir um componente. Segundo ele, o componente deve ter suas interfaces
padronizadas; deve ser independente, visto que não pode depender de outros
componentes para sua utilização; deve ser passível de composição; deve ser implantável
ou autocontido, significa que ele é capaz de operar de forma autônoma; e deve ser
documentado, para que seus potenciais usuários saibam de suas características antes de
utilizá­lo.
A engenharia baseada em componentes ganhou impulso na década de 90, uma
vez que os softwares foram se tornando cada vez mais complexos e, adicionalmente à
isso, tiveram seu tempo para desenvolvimento reduzido por exigência de seus clientes.
Neste cenário, a única maneira para entregar software complexo, confiável, o mais
rápido possível é reutilizar ao invés de reimplementar.
Para que a CBSE seja viabilizada, um processo distinto deve ser utilizado. Esse
processo, na abordagem de Sommerville (2011) possui as seguintes etapas (Figura 2.7):
Figura 2.7­ Ciclo do CSBE
Fonte: (SOMMERVILLE, 2011, p. 324)
1. Esboço dos requisitos do sistema. Ao contrário da abordagem incremental
para requisitos, neste processo é necessário o maior número possível de
requisitos especificados logo no início do desenvolvimento para a
identificação do maior número de componentes a serem utilizados;
2. Identificação dos componentes candidatos. Esta etapa envolve uma série de
subatividades – buscar os componentes, selecioná­los e validá­los;
3. Modificação dos requisitos de acordo com os componentes descobertos.
Nesta etapa, os requisitos são refinados e modificados para se adequarem aos
componentes disponíveis e àqueles não atendidos são renegociados ou
descartados;
4. Projeto de arquitetura. É a etapa para se refinar os componentes escolhidos,
uma vez que eles podem não trabalhar corretamente ou apresentar problemas
de integração quando utilizados juntos num mesmo sistema;
5. Identificação dos componentes candidatos. Escolha de alguns outros
componentes ou substituição dos que já foram escolhidos, caso seja
necessário; e
6. Composição dos componentes para criação dos sistemas. Trata­se da
integração dos componentes. Nesta etapa pode ser necessário adaptar as
interfaces destes componentes através da geração de códigos próprios do
sistema.
Esta abordagem é bastante útil, uma vez o reúso de software acontece
independentemente da metodologia escolhida. Por isso é uma recomendação que os
softwares sejam projetados visando à utilização de componentes. Isso produz como
benefícios o aumento da qualidade do sistema, o aumento da produtividade e a redução
dos custos globais do sistema. Porque ao reutilizar um componente, evita­se que novos
códigos sejam produzidos nos quais poderiam introduzir novos erros no software que
elevariam os custos do projeto e reduziriam a confiabilidade do sistema como um todo.
Por fim, podem ocorrer situações nas quais o cliente não aceita a mudança de
seus requisitos para se utilizar um determinado componente. Porém eles estão dispostos
a mudar de opinião caso isso se comprove uma forma mais barata ou mais rápida de se
entregar o sistema.
3. Desenvolvimento Ágil
A abordagem ágil surgiu como uma alternativa à forma de se desenvolver
software tradicionalmente. A necessidade de respostas rápidas às mudanças em
requisitos negociais e a diminuição no custo destas mudanças fizeram com que, no
início da década de 1990, os métodos ágeis se popularizassem nos centros de
desenvolvimento de software.
Figura 3.1­ Custo das alterações em função do tempo de desenvolvimento
Fonte: (PRESSMAN, 2011, p. 83)
Na Figura 3.1, pode­se observar o custo do desenvolvimento comparando­se
processos convencionais e processos ágeis de software. Segundo Pressman (2011), o
custo cresce rapidamente ao efetuar uma mudança num requisito do sistema utilizando a
abordagem convencional, porque ela impacta diretamente nas outras etapas da cadeia de
desenvolvimento como o planejamento, análise e projeto, codificação e testes. Ao
contrário, com a utilização dos métodos ágeis, a curva do custo da mudança é
“achatada” pois a entrega incremental reduz o risco de incertezas acerca do projeto e
prepara a equipe a assimilar as mudanças posteriores de forma que não gere impactos
significativos nos custos ou no tempo do projeto.
Para um método de desenvolvimento ser considerado ágil, existem diversas
características que podem ser mencionadas. Dentre elas Sommerville (2011) realça que
desenvolvimento ágil é aquele que produz software de forma rápida em uma série de
incrementos, onde cada incremento possui uma nova funcionalidade útil ao usuário e
cujo tempo de desenvolvimento leve de duas a três semanas. O autor ainda enumera
algumas características comuns às metodologias ágeis, tais como:
1. Desenvolvimento incremental;
2. Planejamento, especificação e projeto intercalados, nos quais são elaborados
o mais simples possível que atenda à necessidade do usuário;
3. Documentação reduzida ao mínimo necessário; e
4. Utilização de ferramentas para a geração das interfaces visuais.
como:
Já para Abrahamsson (2002), algumas outras características são mencionadas
1. Modularidade no desenvolvimento;
2. Iteratividade com ciclos curtos e de duração fixa, com verificações e
correções rápidas;
3. Priorizar pessoas à processos e tecnologia; e
4. Colaboração e comunicação como formas de trabalho.
Em suma, ambos os autores mencionam características análogas umas às outras
que servem de norte às metodologias ágeis de desenvolvimento como o XP – Extreme
Programming.
3.1. XP ­ Programação Extrema
Atualmente, o XP (Programação Extrema, em português) é uma das
metodologias mais populares de desenvolvimento de código cuja orientação filosófica
proveio do Manifesto Ágil5. Elaborado por Kent Beck na década de 1990, o XP busca
desenvolver softwares de maior qualidade, de forma mais econômica e produzidos em
menos tempo que as formas tradicionais. Isso, portanto, é alcançado por de um conjunto
de princípios, práticas e valores nos quais diferenciam o XP das metodologias
tradicionais.
No processo XP – Figura 3.2 ­, os clientes estão intimamente envolvidos na
especificação do software e fazem parte da equipe. As necessidades deles são
levantadas em cenários conhecidos como “histórias de usuário” e são descritas em
5 O Manifesto Ágil, criado em 2001 nos Estados Unidos, é uma fonte de princípios que norteia as
metodologias ágeis para o desenvolvimento de software, elaborado por profissionais de software que
buscavam elevar o desempenho de seus projetos.
cartões CRC6 (Classe­Responsabilidade­Colaborador). Após este levantamento os
clientes priorizam as suas necessidades mais urgentes e importantes que serão enviadas
à equipe de desenvolvimento.
Nessa equipe, as histórias são transformadas em tarefas menores e um conjunto
de testes são elaborados antes mesmo da implementação concreta da funcionalidade. Ao
ser construída, a nova funcionalidade é integrada às demais e, à medida que novas vão
sendo desenvolvidas, todos os testes são executados para garantir que não houve quebra
das funcionalidades já existes. Quando todas as tarefas previstas são concluídas, um
release7 é disponibilizado ao cliente para avaliação. É importante observar que o tempo
para a disponibilização de um release seja pequeno permanecendo de duas a quatro
semanas.
Figura 3.2­ Ciclo de vida de um release em Extreme Programming
Fonte: (SOMMERVILLE, 2011, p. 44)
Obviamente que o sucesso do processo depende de um conjunto de boas
práticas, sem as quais não seria possível o uso do XP. As principais, segundo Beck
(1999), são:
1. Jogo do planejamento. Os clientes decidem o escopo da próxima iteração
baseado nas estimativas fornecidas pelos programadores. Eles
implementarão apenas as funcionalidades exigidas na história desta
iteração.
2. Pequenas releases. O sistema é colocado em produção dentro de alguns
meses antes de resolver todos os problemas. Novas releases são liberadas
diariamente e depois, mensalmente.
3. Metáforas. O sistema é definido através de metáforas que são
compartilhadas entre clientes e programadores.
4. Projeto simples. A todo momento o projeto executa todos os testes que
garantem que o projeto não contém códigos duplicados e está na sua
forma mais simples possível.
6 Os cartões CRC são os únicos artefatos produzidos durante o processo XP.
7 Um release é o fim de um ciclo de desenvolvimento, a entrega final de uma versão de produto ou a
versão de software que o cliente irá utilizar.
5. Testes. Os programadores elaboram os testes de unidade que devem
funcionar corretamente e os clientes elaboram os testes de aceitação nos
quais formam os critérios de aceitação do software.
6. Refatoração. Ela garante que a estrutura do sistema não se degrade com a
adição de novas funcionalidades.
7. Programação em pares. Toda a produção do código é feita por duas
pessoas utilizando o mesmo monitor, o mesmo mouse e o mesmo
teclado.
8. Integração contínua. O código é integrado ao sistema corrente várias
vezes por dia e, ao integrá­lo, o sistema é construído do zero. Portanto,
todos os testes devem passar ou as modificações são descartadas.
9. Propriedade coletiva do código. Todo programador pode melhor
qualquer código do sistema a qualquer momento.
10. Cliente sempre disponível no local. O cliente está disponível a todo
momento.
11. Semanas com 40 horas semanais. Ninguém pode trabalhar na segunda
semana consecutiva com horas­extras.
12. Horas­extras com frequência são sinais de problemas profundos.
Tendo em vista tais práticas, de nada elas serviriam quando utilizadas
isoladamente, alheias à realidade da organização ou da equipe de desenvolvimento.
Ainda conforme o autor, ele estabelece cinco valores – comunicação, simplicidade,
feedback, coragem e respeito ­, que servem para direcionar para as atividades, ações e
tarefas específicas da XP.
Sendo a primeira delas a comunicação, o XP tem o objetivo de mantê­la
fluindo através do emprego das práticas, nas quais não podem realizadas sem a
comunicação. Sem dúvida, ela não está limitada a meros procedimentos formais e se
utiliza, portanto, o melhor meio possível para viabilizá­la como uma conversa informal,
diagramas ou, até mesmo, o próprio código.
O segundo valor, a simplicidade, restringe os desenvolvedores a
projetarem para as necessidades imediatas, ou seja, para a solução mais simples que
funcione neste momento.
O feedback é o terceiro valor da XP. Este valor garante que respostas
rápidas sejam enviadas em várias etapas do processo. Para o desenvolvedor, seu
feedback são os testes unitários; para os clientes e testadores, os testes funcionais.
Coragem, o quarto valor, é gerada a partir das práticas do XP. Tendo em
vista que elas aumentam a confiança do desenvolvedor, ele tará a coragem suficiente
para manter o código ou corrigir algum erro do sistema.
O quinto valor, respeito, é gerado quando se entrega com sucesso os
incrementos de software. Desta forma, gera­se respeito entre os membros da equipe e
entre os demais envolvidos, culminando no respeito ao próprio XP.
É interessante notar que a abordagem ágil, bem como os demais
processos de software supracitados no presente estudo, não se aplica a todas as
situações indistintamente. Há situações em que um processo formal é mais oportuna que
a abordagem ágil, pois alguns softwares podem apresentar requisitos críticos para o
sucesso do projeto nos quais exigem um maior controle para sua definição. De toda
forma, é fato que a metodologia ágil vem tomando espaço ao longo dos anos
principalmente nos projetos pequenos ou médios, cujos requisitos sejam voláteis e
estejam num ambiente negocial onde a resposta a mudança é mais interessante que a
garantia dos requisitos.
Por fim, Sommerville (2011) aponta algumas características que dificulta
a adoção da abordagem ágil pelas empresas. Pode ser difícil manter um cliente
disponível durante todo o processo de desenvolvimento, uma vez que o cronograma
dele pode­se diferenciar do cronograma da equipe de desenvolvimento. Outro problema
é que alguns dos membros da equipe podem não ter a personalidade adequada à tal
metodologia, e priorizar as mudanças pode ser extremamente oneroso, principalmente
quando um sistema possui vários stakeholders onde cada um deles prioriza
diferentemente cada mudança.
3.2. Scrum
Originado na década de 1990 e criado por Ken Shwaber e Jeff Sutherland, o
Scrum é um framework8 simples no qual as pessoas utilizam para resolver problemas
complexos e adaptativos, enquanto criam e entregam produtos de qualidade. Apesar de
sua simplicidade e fácil entendimento, é extremamente difícil de dominar este
framework.
Com raízes na teoria empírica9 para o controle do processo de desenvolvimento,
três pilares são fundamentais para o Scrum: transparência, inspeção e adaptação. O
primeiro deles transparência, significa que aspectos relevantes do processo devem ser
expostos a todos os responsáveis de forma clara, inequívoca e definidos por um padrão
comum para que os responsáveis compartilhem do mesmo entendimento sobre algo. O
segundo, inspeção, serve para averiguar se não há variações indesejadas nos artefatos do
Scrum ou se progresso do trabalho está caminhando conforme o esperado. O terceiro,
adaptação, sugere que os artefatos desviados de seus objetivos devam ser corrigidos o
quanto antes para se evitar maiores problemas.
O Scrum não é um um processo nem uma técnica, mas é uma estrutura
processual que suporta o desenvolvimento de produtos complexos. Por conseguinte,
apresenta uma abordagem coerente com os conceitos de agilidade definidos até então no
Manifesto Ágil. Logo, ele consiste em equipes associadas a papéis, eventos, artefatos e
regras cada qual cumprindo com seu devido propósito e unidos através de regras.
Para uma melhor didática acerca deste framework, serão abordados os conceitos
na seguinte ordem:
1. Papéis;
2. Eventos; e
8 Framework pode ser entendido como uma estrutura de suporte ao desenvolvimento de software.
9 O empirismo, em suma, é uma teoria na qual prega que o conhecimento provém da experiência e a
tomada de decisões, por sua vez, é baseada naquilo em que se conhece.
3. Artefatos.
As regras estarão diluídas no transcorrer destes conceitos. De todo modo, a
Figura 3.3 exibe o funcionamento do Scrum, na qual exibe um esquema para facilitar o
entendimento.
3.2.1. Papéis
Os papéis no Scrum são claros e definidos e possuem características próprias que
garantem o sucesso do framewok. Juntos eles formam o Time Scrum que, uma vez
formados, são auto­organizáveis e multifuncionais, são responsáveis por entregar o
produto em funcionamento, têm liberdade para escolher a melhor forma de entrega do
trabalho e possuem todas as competências necessárias para a conclusão do trabalho. Os
papéis são:
1. Product Owner (PO) ou Dono do Produto. É o único responsável por definir
as funcionalidades do produto e priorizá­las dentro do Backlog do Produto –
uma lista priorizada de necessidades. Nesta lista de tarefas o PO pode alterar
prioridades ou redefinir tarefas.
2. Scrum Master. É o responsável por intercambiar os interesses do PO, da
Equipe de Desenvolvimento e da Organização, ou seja, é um facilitador do
time Scrum que remove impedimentos. Dentre suas principais competências,
estão as de promover e aplicar corretamente o Scrum na organização.
3. Equipe de Desenvolvimento. Essa equipe é mais que um conjunto de pessoas
ou um papel. É aquela que efetivamente cria incrementos funcionais de
software. Tem a característica de ser auto­organizada e multifuncional ao
ponto de não ser pequena demais nem grande demais.
Figura 3.3­ Ciclo de Vida do Scrum
Fonte: http://www.projectprime.com.br
3.2.2. Eventos
Os eventos no Scrum são os responsáveis por garantir os princípios da
transparência, da inspeção e da adaptação nos quais ele se fundamenta. Os eventos têm
uma duração máxima e são realizados com no intuito de reduzir o número de reuniões
não previstas, garantindo uma quantidade adequada de tempo gasto no planejamento.
Sprint é o evento principal do Scrum. Ela é um período de tempo no qual um
incremento funcional de software é produzido, possui duração fixa e é iniciada após o
término da sprint anterior. As sprints são compostas pelas quatro reuniões a seguir:
1. Planejamento. A reunião de planejamento é o passo inicial da sprint (Figura
3.3) onde são planejados os trabalhos que serão entregues no fim do ciclo e
são descritos os modos de execução desses trabalhos. Essa reunião possui
dois períodos: o primeiro para definir a meta da sprint que é baseada no
Backlog do Produto; o segundo, é a seleção de tarefas do Backlog do Produto
cuja execução cabem em uma sprint. Essa seleção forma um outra lista
chamada de Backlog da Sprint.
2. Diária. A reunião diária serve para a equipe de desenvolvimento alinhar as
atividades que estão sendo realizadas na sprint. Esta reunião tem o objetivo
de inspecionar o trabalho realizado e verificar o que foi feito desde a última
reunião diária, o que está sendo feito e o que será feito até a próxima reunião
diária. Desta forma a equipe de desenvolvimento pode se auto­organizar para
manter o trabalho nos trilhos caso ele venha a se desviar.
3. Revisão. A reunião de revisão da sprint serve para o time scrum avaliar os
pontos positivos e negativos ocorridos durante a sprint e demonstrar o
incremento de software entregue. Nessa reunião o Backlog do Produto é
ajustado para a próxima sprint.
4. Retrospectiva. A reunião de retrospectiva serve para o time scrum
inspecionar­se a si mesmo. Com base nisso, é elaborado um plano de
melhorias para o trabalho ser realizado de forma mais eficiente e com maior
qualidade na próxima sprint.
Por fim, mudanças não são admitidas na sprint em execução. Caso surjam mudanças,
elas serão consideradas somente na próxima sprint. Contudo, caso achar necessário, o
PO pode determinar o cancelamento dela alegando, por exemplo, que seus objetivos não
serão cumpridos.
3.2.3. Artefatos
Os artefatos no Scrum são definidos para que colaborem com a transmissão das
informações chave necessárias para a entrega do incremento de software. Nele são
definidos dois tipos de artefatos: Backlog do Produto e Backlog da Sprint.
1. Backlog do Produdo. É uma lista ordenada de todas as necessidades do PO e
a única fonte de requisitos do software. Os itens desta lista possuem atributos
como descrição, ordem e estimativa; e estão ordenados por suas
características como valor, risco, prioridade e necessidade. Nesta lista,
quanto mais ao topo ele estiver um item, maior será sua prioridade, e quanto
mais ao fim da lista, menor é a sua prioridade. Depreende­se disto dois fatos:
o primeiro é de que os itens prioritários serão mais detalhados, ao passo que
os itens de prioridade baixa terão poucos detalhes.
2. Backlog da Sprint. É uma lista gerada a partir do Backlog do Produto com
determinados itens selecionados que definem o trabalho necessário para a
entrega do incremento funcional de software, com uma diferença
fundamental do backlog anterior: o backlog da sprint pode ser alterado
durante a execução dela pela equipe de desenvolvimento.
Por fim, o Scrum ainda define mais dois conceitos importantes para o framework
que é a definição de “pronto” e a definição de “incremento”: esse é a soma de todos os
itens construídos na sprint atual e nas sprints anteriores, desde que sejam utilizáveis;
aquele é o entendimento compartilhado por todos do time acerca do trabalho, ou seja,
todos devem saber exatamente o que será considerado como trabalho pronto.
4. Administração Pública e o Desenvolvimento de Software
A crescente popularização dos métodos ágeis para o desenvolvimento de
software, tanto no mercado nacional quanto no mercado internacional, tem suscitado o
interesse da APF quanto à adoção destes métodos. Esse interesse, somado às constantes
insatisfações e frustrações com os softwares entregues até então por meio do
desenvolvimento tradicional, levou o Tribunal de Contas da União (TCU) 10 a realizar
um importante estudo acerca da adoção das metodologias ágeis nas instituições públicas
federais.
No ano de 2013, o tribunal realizou uma fiscalização expressa no relatório TC
010.663/2013­4, sobre a viabilidade de adoção das metodologias ágeis por órgãos da
APF. A fiscalização consistiu em análises feitas por meio dos contratos administrativos
entre algumas instituições públicas federais e empresas terceirizadas. Nesta fiscalização,
o tribunal buscou investigar como esses órgãos celebravam seus contratos com as
empresas terceirizadas, à luz da legislação nacional, adotando os métodos ágeis.
Adicionalmente, diversos riscos a que estes órgãos estão sujeitos ao realizar este tipo de
contratação foram identificados.
Dentre os órgãos que se destacaram na tentativa de aplicação das metodologias
ágeis, de acordo com o TCU, foram: Tribunal Superior do Trabalho (TST); Banco
Central do Brasil (Bacen); Instituto do Patrimônio Histórico e Artístico Nacional
(Iphan), Instituto Nacional de Estudos e pesquisas Educacionais Anísio Teixeira (Inep)
e Supremo Tribunal Federal (STF). Embora em nenhum dos citados tenha se observado
a aplicação dessas metodologias em sua totalidade, mas se identificou um constante
esforço para compatibilizá­las com a legislação do país.
De forma exemplificativa e de acordo com o relatório, para o planejamento do
produto das entidades supracitadas o framework Scrum foi utilizado. Quanto à aceitação
do produto, o framework estipula que deva haver uma reunião de revisão da sprint,
porém essa prática não é executada por força da Lei de Licitações e Contratos
8.666/1993, art. 73. Nisso as instituições verificam se os artefatos exigidos
contratualmente foram entregues e, assim, fica caracterizada a entrega provisória do
produto no lugar da sprint de revisão. Já o TST afasta­se dos princípios do Scrum ao
tolerar atrasos na entrega do produto. Sendo que para o Scrum uma sprint tem duração
fixa e deve ser executada no prazo estabelecido, se porventura houver possibilidade de
atrasos o escopo da sprint deverá ser reduzido.
O tribunal, também, elencou alguns riscos inerentes a tais contratações a que
estão submetidos os órgãos quando desenvolvem software utilizando as metodologias
ágeis. Ele ainda destaca que alguns dos riscos expostos não são exclusivos dos métodos
ágeis, podendo ocorrer também ao se utilizar os métodos tradicionais de
desenvolvimento de software. Não obstante, esses riscos elencados podem trazer sérios
prejuízos à instituição como diminuição da competitividade da licitação, conflitos entre
instituição e empresa contratada, entrega de produtos de baixa qualidade e, o mais
grave, prejuízo ao erário.
Didaticamente, o acórdão citado divide os riscos em três categorias: processos,
pessoas e produtos. Os primeiros podem distorcer a essência da metodologia ágil, no
início ou durante a execução do contrato; pode exigir artefatos desnecessários ou que se
tornem obsoletos rapidamente; ou, ainda, elaborar um contrato de desenvolvimento
tradicional de software e, na prática, utilizar métodos ágeis. Os segundos tratam dos
10 Nos termos constitucionais, o TCU é o responsável por realizar fiscalizações e auditorias em
qualquer instituição que, de alguma forma, envolva recursos públicos da União.
riscos relativos às pessoas como a falta de comprometimento ou colaboração do
Product Owner (PO) com o desenvolvimento do software; a equipe da empresa contrata
não ter a expertise para o desenvolvimento ágil; e dificuldades de comunicação entre o
PO e a equipe de desenvolvimento. Por último, os riscos envolvendo os produtos
referem­se às alterações constantes da lista de funcionalidades; pagamento pela mesma
funcionalidade mais de uma vez, pois algumas funcionalidades são impossíveis de se
implementar em um único ciclo; e a falta do planejamento adequado do software a ser
construído.
De todo modo, as metodologias de desenvolvimento de software – sejam
tradicionais ou sejam ágeis ­, apresentam pontos fortes e fracos devendo ser
consideradas em um contexto específico. No contexto da APF, há de se compatibilizar
as metodologias ágeis com os princípios legais vigentes, para poder aplicá­las e extrair
delas todos os seus benefícios.
Por fim, apesar do estudo feito pelo TCU, ele deixa claro que maiores estudos
são necessários para identificar os riscos de forma mais precisa visando uma melhor
orientação acerca do tema a seus jurisdicionados.
5. Conclusão
O setor público e o privado diferem profundamente. No entanto, há certas
características visadas que lhes são comuns, como: a eficiência, a qualidade, a
produtividade e a redução dos gastos. No que tange ao desenvolvimento de software, a
abordagem ágil se popularizou e se tornou protagonista em grande parte do cenário
mundial de desenvolvimento de sistemas. Um fluxo iniciado na iniciativa privada que,
posteriormente, adentrou as administrações governamentais.
Por isso, ao longo deste trabalho, abordou­se uma forma de demonstrar as
metodologias de desenvolvimento de software mais utilizadas ao longo do tempo,
desde o modelo sequencial linear até a abordagem ágil, enfatizando suas principais
características positivas e negativas. Por sua vez, este estudo propôs uma solução para o
uso das metodologias e processos ágeis na Administração Pública Federal (APF), que
resulta na harmonização das metodologias ágeis com a legislação existente de modo que
as metodologias não sejam descaracterizadas e nem as leis desrespeitadas.
Por fim, com base nesta pesquisa, conclui­se pela viabilidade da adoção das
práticas e metodologias ágeis na APF, pois elas demonstraram ser mais aplicáveis a
softwares negociais com requisitos de alta volatilidade que necessitem de um retorno
rápido, mesmo que o software não esteja totalmente concluído. Vale ainda esclarecer
que a abordagem ágil na APF é um tema recente que carece de maiores estudos para se
alcançar resultados mais profundos. Com isso, deve­se levar em consideração que
algumas práticas ágeis não se adéquam inteiramente ao setor público, haja vista que tal
setor conta com demasiada burocracia e exige um alto grau de formalidade em seus
processos.
Referências
ABRAHAMSSON, PEKKA; SALO, OUTI; RONKAINEN, JUSSI. Agile Software
Development Methods: Review and Analysis. University of Oulu. Espoo. p. 18­27.
2002.
BOHEM, BARRY W. A Spiral Model of Software Development and Enhancement.
IEEE Computer Society. p. 61­72. 1988.
BECK, KENT. Extreme Programming Explained: Embrace Change. Addison­
Wesley Professional. p. 42­46. 1999.
SCHWABER, KEN. SUTHERLAND, JEFF. Guia do Scrum: Um Guia definitivo
para Scrum: As Regras do Jogo. Scrum.Org and ScrumInc. Disponível em:
<http://www.scrumguides.org/>. Acesso em 24 de jan. 2015.
ROYCE, W. Managing The Development Of Large Software Systems. Los Angeles.
USA. Technical Papers of Western Electronic Show and Convention (WesCon).
p. 1­11. 1970.
PRESSMAN, ROGER S. Engenharia de Software: Uma Abordagem Profissional. 7
ed. McGraw­Hill. p.53­78 .2011.
SOMMERVILLE, IAN. Engenharia de Software. 9 ed. Pearson. p.4­11. p. 38­57.
2011.
TRIBUNAL DE CONTAS DA UNIÃO. Levantamento Sobre Aplicação de
Metodologias Ágeis em Desenvolvimento de Software. Disponível em:
<http://portal2.tcu.gov.br/portal/page/portal/TCU/imprensa/trabalhos_em_destaque/
TECNOLOGIA_INFORMA%C3%87%C3%83O_Levantamento%20Sobre%20a
%20Aplica%C3%A7%C3%A3o.pdf>. Acesso em 24 de jan. 2015.
TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 2.314/2013 Ata 33 – Plenário.
Disponível
em:
<https://contas.tcu.gov.br/juris/Web/Juris/ConsultarTextual2/Jurisprudencia.faces?
colegiado=PLENARIO&numeroAcordao=2314&anoAcordao=2013>. Acesso em 24
de jan. 2015.
GABARDO, MARCO AURÉLIO; GOMES, ALEXANDRE RODRIGUES. Discussão
sobre Motivação de Equipes na Implementação de Métodos Ágeis no
Desenvolvimento de Sistemas na Administração Pública Federal. Fundação
Universa–Universidade Católica de Brasília. Brasil. DF. Brasília. p.1­17. 2009.
PIETRO, MARIA SYLVIA ZANELLA DI. Direito Administrativo. 27 ed. Atlas.
p.49­60. 2014.