1

METODOLOGIAS PARA GESTÃO DE PROJETOS DE DESENVOLVIMENTO DE

SOFTWARE COMBINANDO ABORDAGENS ÁGEIS E TRADICIONAIS

Henrique Pereira Oliveira d’Eça Neves1

RESUMO

Atualmente as equipes envolvidas em projetos de desenvolvimento de software dispõem de diversas alternativas de metodologias, processos e melhores práticas para condução desse tipo de projeto. Muitas delas podem ser aplicadas parcial ou integralmente, de forma isolada ou combinadas entre si. Essa multiplicidade de opções gera dificuldades às equipes de gestão na escolha dos processos que devem ser efetivamente executados em cada etapa do projeto. Tais dificuldades são mais intensas em ambientes com metodologias menos consistentes. Este artigo apresenta algumas alternativas para gestão de projeto, descrevendo suas principais características e aplicações. Também são destacadas as diferenças de abordagem entre as metodologias ágeis e as tradicionais. Para cada uma das etapas do ciclo de vida típico de um projeto de software, são apresentadas sugestões de aplicação de algumas das alternativas discutidas (independentemente se ágil ou tradicional) tendo como objetivo principal a adoção de boas práticas com uso comprovado na busca da melhoria da qualidade dos produtos gerados nesse tipo de projeto.

Palavras chave: Projeto de Software. Metodologias de Desenvolvimento. Ciclo de

vida de projetos.

1 Bacharel em Ciência da Computação. e-mail: hike.neves@gmail.com

2

1. INTRODUÇÃO

Conforme Paula Filho (2005), os projetos de desenvolvimento de software

compreendem início, meio e fim, e são executados por equipes usando ferramentas

e processos.

Esses processos, quando bem definidos, determinam os outros itens de um

projeto tais como metodologia, sistemas de apoio, pessoas com a qualificação

necessárias para integrar a equipe que irá elaborá-lo.

Muitos profissionais, por conhecerem as linguagens de desenvolvimento e

funcionamento dos softwares sentem-se capazes de desenvolver um projeto sem o

cuidado de usar métodos ou processos, isto por esquecimento, desleixo ou por falta

de conhecimento resultando em problemas durante seu desenvolvimento e

principalmente no que diz respeito ao suporte do software.

“O desafio mais comum dentro do desenvolvimento de software, é entregar

um produto que atenda às reais necessidades do cliente, dentro do prazo e

orçamento previsto.” (FAGUNDES, 2005, p. 19).

Nesse artigo busca-se apresentar as principais etapas de um projeto e alguns

usos das técnicas, ferramentas e métodos para alcançar um melhor resultado para o

software e principalmente a satisfação do cliente.

2. UM PROJETO

Segundo Sbrocco (2012) um projeto de software é um empreendimento com

características próprias, conduzido por pessoas dentro de um período de tempo,

seguindo métricas para alcançar a melhor qualidade, prazo e custo em seu produto

final.

Os projetos surgem a partir de necessidades específicas de origem interna ou

externa a uma instituição. Uma vez entendidos e estruturados os objetivos do projeto

devem ser selecionadas táticas, técnicas e métricas conhecidas para chegar a tal

objetivo. Existem diversos métodos para trilhar esse caminho e a escolha dos

mesmos varia conforme o contexto em que o projeto é executado.

Estas ideias são pontuadas para um melhor entendimento e definição das

mesmas sendo chamadas de Requisitos. Depois de estudados é elaborado um

3

modelo do sistema que é apresentado ao cliente e após sua aceitação é iniciada a

elaboração de uma estrutura em alto nível para o entendimento do que realmente

será o software, com suas funcionalidades e comunicações. Esta etapa é conhecida

como Design. Na próxima etapa do projeto, nomeada de Arquitetura do Software,

são especificadas as funcionalidades do sistema, assim como a linguagem a ser

utilizada para codificação do software, as ferramentas que auxiliarão nos trabalhos

do projeto e a metodologia a serem aplicadas para atender os requisitos e

necessidades.

O Teste não se trata de uma etapa do projeto isolada, ele transpassa diversas

etapas fazendo diferentes tipos de verificação de acordo com a abrangência da

etapa vigente. Ele inicia na etapa de design quando a proposta é desenhada.

Na etapa de Desenvolvimento o teste tem seu maior trabalho, já que é nesse

momento do projeto que são testadas as funções e funcionalidades do software em

desenvolvimento buscando encontrar erros e falhas dentro do que foi produzido.

Muitos autores e especialistas da área de testes de software pregam que os testes

buscam quebrar o funcionamento daquilo que se está testando. No desenvolvimento

a busca pelo melhor entendimento do que foi elaborado pela arquitetura com o

objetivo de traduzir as especificações em código fonte utilizando a linguagem e

metodologia determinadas visando alcançar e sanar necessidades almejadas.

Não há relação entre linguagem de programação e metodologia, existe sim é

uma relação entre o tamanho do projeto e a metodologia aplicada. Há metodologias

que melhor se aplicam a uma ou outra etapa do projeto, ou conforme o tipo de

contrato firmado com o cliente.

Após o desenvolvimento vem a etapa de Homologação e aceite daquilo que

foi desenvolvido. Uma vez aprovado, é o momento de implantar o software no

cliente. Esta atividade envolve colocar em produção o software desenvolvido e a

partir daí surgirão dúvidas e problemas que passarão pelas fases de análise,

solução, teste, homologação e atualização. Estes problemas são recebidos pela

equipe de suporte do projeto, que organiza as dúvidas e problemas apresentados

atuando sobre eles.

Um aspecto de suma importância para o projeto é a Documentação. Nela é

descrito cada passo dado desde o início dos trabalhos até sua conclusão. De forma

geral existem dois focos, um foco para a documentação técnica destinada a equipe

4

do projeto e outra focada no cliente. O uso da documentação se dá pela equipe do

projeto, na revisão de resultados e objetivos alcançados, relatando as ocorrências e

também na busca de soluções para os problemas que surgirem. Já o cliente faz uso

da documentação como manual de bom uso do software para tirar dúvidas quanto

ao uso do mesmo.

A Figura 1 ilustra a sequência de etapas descrita acima. Nela encontram-se

as etapas, a comunicação entre elas e o tempo de existência dentro de um projeto.

Figura 1: Etapas do projeto de software.

Fonte: do Autor (2011)

Este trabalho propõe a conjugação das melhores práticas sugeridas por

diversas metodologias com o objetivo de alcançar um produto de qualidade e que

melhor atenda às necessidades do cliente ao final do projeto. Na próxima seção é

apresentada uma relação de metodologias e melhores práticas.

5

3. METODOLOGIAS

“Tudo começa quando um cliente procura uma empresa dizendo precisar de

um software. O analista de sistemas o escuta com toda a atenção e faz uma série de

perguntas. Posteriormente, ele escreve durante alguns minutos e faz um primeiro

esboço do que o cliente descreveu” (KOSCIANSKI; SOARES, 2007).

De forma geral existem duas abordagens para a classificação de

metodologias: as metodologias tradicionais (MT) e as metodologias ágeis (MA). Os

conceitos e diretrizes são distintos, mantendo somente algumas poucas coisas em

comum: objetivos e o resultado final.

As MT são conhecidas pela robustez e por aceitarem requisitos e atributos

pré-estabelecidos. Além disto, as MT trabalham com um conjunto de atividades

predefinidas dentro de cada etapa de um projeto, tornando-as restritas não

permitindo que a equipe escolha o caminho a seguir no desenvolvimento do

software, fazendo com que elas se tornem “pesadas”.

As MA se caracterizam por aceitarem mudanças no desenvolvimento do

software baseando no histórico do projeto. O cliente está, de certa forma, presente

no desenvolvimento do software onde ele realiza testes e provas, além de trazer as

mudanças necessárias. Estas mudanças surgem a partir dos negócios envolvidos,

mercado, regras e ideias que estão em constante alteração.

As MA surgiram na década de 90 quando houve uma explosão do mercado

de informática que possibilitou o uso da tecnologia em diversos meios e levantando

a necessidade de rápidas soluções para o mercado.

Outras características que diferem MT e MA é o fato das MA serem abertas a

opiniões do cliente a respeito do software em desenvolvimento.

“Metodologias ágeis são baseadas em dados estatísticos obtidos de

históricos referentes à implementação do código. Já os métodos tradicionais

utilizam como base normas que definem padrões a serem seguidos.”

(SBROCCO, 2012, p. 184).

Considerando seus princípios, as metodologias ágeis já estão preparadas

para aceitar mudanças no projeto, pois estão focadas nas pessoas e não

nos processos, e por natureza denotam um controle rígido deles. Nas

metodologias tradicionais, à medida que alterações são necessárias na fase

6

próxima de seu encerramento, seu custo tende a crescer exponencialmente.

Nas metodologias ágeis o custo não cresce ao final, mesmo que alterações

de requisitos devam ser realizadas. (SBROCCO, 2012, p. 184)

Os métodos ágeis apresentam uma abordagem bastante pragmática para o

desenvolvimento de software. Planos detalhados são feitos apenas para a

fase atual do projeto. Para fases futuras, os planos são considerados

apenas rascunhos que podem se adaptar a mudanças conforme o time

aprende e passa a conhecer melhor o sistema e as tecnologias utilizadas.

(SATO, 2009, p. 6)

Fransson e Klercker (2005) propõem uma classificação das diversas

metodologias disponíveis na literatura ao longo de um “Eixo de Agilidade”. Este eixo

varia do ‘Extremamente Ágil’ até o ‘Extremamente Tradicional’. A Figura 2 ilustra

esta classificação.

Figura 2: Eixo de Agilidade.

Fonte: adaptado de Fransson Klercker (2005, p. 35)

A seguir são apresentadas características de algumas das principais

metodologias e técnicas utilizadas em projetos de desenvolvimento de software.

RUP (Rational Unified Process)

A metodologia RUP reúne melhores práticas em uma plataforma para

desenvolvimento de sistema e arquitetura configuráveis.

Os métodos do RUP são de fácil entendimento, porém de difícil

aprendizado e aplicação, mesmo assim, algumas ferramentas dele são muito

úteis e práticas para o entendimento dos módulos de um projeto.

7

Mesmo sendo uma MT, ela atua de forma dinâmica ao mostrar as fases

do modelo ao longo do tempo, atua de forma estática mostrando as atividades

de um processo e de forma prática apresentando boas práticas para uso

durante os processos. (SOMMERVILLE, 2007, p. 54)

XP (eXtreme Programming)

XP é um método leve, da MA, destinado ao desenvolvimento de

software e funciona para equipes de qualquer tamanho, com melhor resultado

nas pequenas. Ele preza pela Economia, Comunicação, Feedback, Coragem,

Oportunidade, Qualidade entre outros princípios e padrões.

SW-CMM (Software Capability Maturity Model)

O modelo SW-CMM busca a melhor qualidade de softwares, ele deriva

do modelo de qualidade industrial CMM. Tem foco na melhoria do potencial dos

processos e seu tempo de execução. O SW-CMM não é tido como uma

metodologia em si, mas como uma reunião de melhores práticas para gerir um

projeto.

Há uma grande complexidade nos processos propostos pelo modelo, por

serem imprevisíveis e de difícil repetição, além da dificuldade de serem

antecipados, como diz Dias (2010, p. 5).

PMBoK (Project Management Body of Knowledge)

É um guia de conhecimentos e de melhores práticas, ferramentas e

técnicas para auxiliar no gerenciamento de um projeto. O PMBoK se propõe a

ser uma referência genérica, não apresentando particularidades relacionadas a

nenhum tipo específico de projeto.

SCRUM

O SCRUM, uma MA, se concentra no gerenciamento do

desenvolvimento do software realizando ciclos de duas a quatro semanas,

chamados de Sprints. Diariamente são realizadas rápidas reuniões para

acompanhamento das atividades atuais e futuras, as Stand-up Meetings.

8

O SCRUM é um trabalho em equipe onde cada membro possui uma

atividade, com isso há uma valorização do indivíduo e rumando a um resultado

da melhor qualidade a equipe se torna auto gerenciável. De forma geral

existem quatro papeis principais: Product Owner, SCRUM Master, Team e o

Cliente, cada qual com sua função específica.

LEAN Software Development

Baseado no Sistema de Produção da Toyota adaptou-se trazendo para a

área de desenvolvimento de software sete princípios: “Elimine Desperdícios”,

“Inclua a Qualidade no Processo”, “Crie Conhecimento”, “Adie

Comprometimentos”, “Entregue Rápido”, “Respeite as Pessoas” e “Otimize o

Todo”. (SATO, 2009, p. 8)

Trata-se de boas práticas para a gestão do projeto, ou etapas do

mesmo.

BPM (Business Process Management)

Método de modelagem de negócios que como o nome já sugere

Business Process Management, Gerenciamento de Processos de Negócio.

Boa opção para a etapa de levantamento de Requisitos e apresentações ao

cliente do que será e esta sendo elaborado. Método com uma boa ferramenta

de diagramação e fluxo das etapas envolvidas na proposta.

Dentre todas as metodologias e melhores práticas citadas há a possibilidade

de realizar escolhas dentre uma ou mais de uma destas e a seção seguinte

apresenta alguns aspectos para o mesmo.

4. ESCOLHA DA(S) METODOLOGIA(S)

A escolha de uma metodologia não é tarefa simples. Existem alguns critérios

a serem levados em conta para tal escolha como Abraham Maslow, um famoso

psicólogo americano, e Giovanni Asproni, membro da Agile Alliance, relatam:

fisiológicas, segurança, realização, possibilidade de crescimento, reconhecimento,

trabalho em si, avanço nos conhecimentos, supervisão técnica, relacionamento com

9

os pares, relacionamento com subordinados, amor, salário, estima e autoestima

(SBROCCO, 2012, p. 195). Para um projeto de software há de se montar um

ambiente favorável, que leve em consideração a maioria destes critérios e que os

atenda de forma plena.

Estes aspectos servem de forma motivacional a equipe do projeto, ela deve

estar confortável e apta para exercer as tarefas solicitadas. Caso contrário existirão

desavenças no grupo.

A metodologia almejada tem que suprir, principalmente, os critérios já citados,

além de facilitar os trabalhos para alcançar os objetivos esperados pelo cliente.

Todas as metodologias abrangem as etapas de um Projeto, porém com diferentes

particularidades em seus métodos de atuação e lida tendo aquelas que se adequam

melhor às exigências do trabalho. A escolha das metodologias e métodos não deve

ocorrer somente pelo gosto ou simpatia, mas sim pela sua abrangência, aplicação e

gestão, isto para buscar a melhor qualidade do produto final.

As características de cada metodologia possuem níveis diferentes de

abrangência em cada etapa do projeto. Isto é caracterizado pelas métricas

adotadas, como modelagem do domínio, domínio e comportamento dos objetos,

análise e modelagem dos requisitos, sua robustez, código-fonte, testes e

documentação. Esta abrangência varia também pela aceitação da equipe

desenvolvedora, ela tem de estar confortável e apta para trabalhar com tal.

Das etapas até aqui citadas (Requisitos, Design, Arquitetura,

Desenvolvimento, Implantação, Suporte, Documentação e Teste) cada uma pode

receber uma metodologia ou método diferente:

Tabela 1: Indicação de Metodologia-Método para cada Etapa

Etapa Metodologia-Método

Requisitos BPM

Design BPM / UML / PMBox

Arquitetura UML / XP / PMBox / SW-CMM

Desenvolvimento SCRUM / XP

Implantação SCRUM / LEAN

Suporte SCRUM

Documentação RUP

Teste SCRUM

Fonte: Do Autor

10

A proposta que se apresenta é a da mescla de metodologias que melhor se

adequam e adaptam ao Projeto. Esta proposta refere-se à separação das

metodologias-métodos que melhor funcionam nas etapas de um projeto.

Exemplificando faz-se a indicação das metodologias-métodos para cada

etapa:

Requisitos: como diz Paula Filho (2005) em seu capítulo 5, os requisitos

devem ser levantados pela equipe do projeto através de representantes do

cliente, usuários chaves e outros especialistas da área de aplicação. Os pontos

levantados, em reuniões e entrevistas, devem ser pontuados e acrescidos das

regras de negócio da área surgindo assim os requisitos que iram guiar o

projeto. Este levantamento deve ser todo documentado, desde as partes

técnicas até comentários a respeito do que se espera do produto final do

projeto.

Depois de recolhidos os requisitos, eles são estudados e organizados

numa ordem de funcionamento do sistema proposto. Para este trabalho é

recomendado desenhar fluxogramas de alto nível para o melhor entendimento

das etapas do produto e para isto há a ferramenta de modelagem da BPM.

Nestes fluxos são definidos os módulos que atenderam as necessidades e

principalmente o fluxo das informações solicitadas. Deste estudo o fluxo é

elaborado, uma documentação relatando o seu funcionamento e sugestões são

descritas, isto é apresentado ao cliente como uma proposta esperando sua

aceitação.

Algumas fases na etapa de requisitos existem, como:

- Obtenção: onde são recolhidas as ideias e desejos para o software

proposto;

- Análise: estudo do que foi solicitado e especificado, da experiência da

equipe do projeto.

Existem algumas orientações para a definição dos requisitos do

software:

- Natureza: define as funcionalidades desejadas ao software, suas

interfaces, seu desempenho e restrições;

11

- Elaboração: os requisitos são definidos por membros da equipe de

desenvolvimento, junto com o usuário chave indicado pelo cliente para ser a

pessoa capacitada por definir requisitos para o software. (PAULA FILHO, 2005,

p. 88)

- Ambiente: diz respeito ao ambiente onde o software funcionará. Se ele

é uma necessidade do cliente, ou parte de um software maior. Sendo descritos

em documentos que tratam desde a especificação de requisitos de sistema,

definição de produto até proposta de desenvolvimento.

- Evolução: a evolução trata dos requisitos já definidos ou suas

alterações. Motivos que levam a alteração de um requisito: defeitos e

inadequações descobertas, falta de detalhamento, mudanças em algum ponto

de negócio que afetem o funcionamento do software.

- Limites: a elaboração dos requisitos de software não deve incluir

definições a respeito de desenho, codificação e gerenciamento do projeto.

Nesta etapa descreve-se os requisitos de forma completa e correta de acordo

com a natureza do problema a ser solucionado.

Design: as ferramentas de modelagem da BPM podem ser utilizadas, mas a

UML é mais indicada por apresentar características mais técnicas, sendo

definida com os conceitos das melhores práticas do PMBoK.

Na etapa de design são definidas as estruturas do software, como os

requisitos funcionais e não funcionais, as classes e elementos de modelo

necessários para a implementação do software. O foco dessa etapa é a

elaboração da estrutura e mecanismo que tornem a implementação do

software mais confiável e produtiva. (PAULA FILHO, 2005, p. 148)

Arquitetura: nessa etapa é avaliada a abrangência do software onde se

estuda o desempenho, segurança, proteção, disponibilidade e sua facilidade de

manutenção. Dependendo do tamanho do software ele é desmembrado em

módulos que juntos compõem um todo do software. Nesta etapa são definidas

as camadas do software e sua arquitetura. Aqui se faz a decomposição do

código, se ele será estruturado ou orientado a objeto criando modelos de

12

funcionalidade e gerando uma documentação que descreve as funções,

características, artefatos funcionais e não funcionais do software.

“A arquitetura de software é o framework fundamental para a estruturação

do sistema. As propriedades de um sistema, como desempenho, proteção e

disponibilidade são influenciadas pela arquitetura usada.” (SOMMERVILLE,

2007, p. 175)

Desenvolvimento:

“Os negócios atualmente operam em um ambiente global sujeito a rápidas

mudanças. Eles têm de responder a novas oportunidades e mercados,

mudanças de condições econômicas e ao surgimento de produtos e

serviços concorrentes.” (SOMMERVILLE, 2007, p. 259).

Este trabalho propõe o uso das metodologias SCRUM ou XP, por serem

de fácil aplicação à uma equipe, deixando os membros livres para opinar e

desenvolverem seus trabalhos sem burocracia de normas, regras e definições

rígidas.

Com as MA sugeridas o software é desenvolvido de forma incremental.

Permitem também que os usuários finais avaliem e participem da especificação

de cada incremento.

Há a possibilidade da criação de prototipação do software onde o

objetivo é validar ou derivar os requisitos levantados. Esta prototipação serve

para trazer um melhor entendimento dos requisitos mal compreendidos e para

isto é necessário conhece-los.

Implantação: nesta etapa ocorre aquilo que o cliente mais deseja ver e ter, o

software posto em produção para seu uso, mesmo que particionado.

A implantação de um software deve seguir o que foi acordado com o

cliente. Se ele deseja uma implantação completa, a equipe do projeto

preparará o sistema para ser colocado em produção no cliente de uma só vez.

Agora se o acordado for de entrega particionada ele é posto em produção de

acordo com o que foi planejado e desenvolvido pela equipe do projeto. Esta

última forma de implantação é muito comum nas MA e permite averiguar, junto

13

ao cliente, possíveis defeitos de implantação e um rápido reparo no problema

apresentado.

A execução de uma implantação deve seguir alguns cuidados com o

software, como: testes de funcionalidades, testes de segurança, transação das

informações, comunicação entre módulos, garantia da qualidade,

documentação, aceite do cliente, entre outros.

As metodologias sugeridas nessa etapa do projeto são:

- SCRUM: metodologia que lida com etapas, as sprints, mais utilizadas

na etapa de desenvolvimento é bem aplicável quando um software é entregue

de forma particionada. Cada parte segue uma lógica para ser implantada e no

SCRUM segue a sequência de aceites proferidos pelo cliente.

- LEAN: esta prega uma entrega do software ou partes dele levando em

conta a qualidade do software e do processo realizado no momento,

respeitando o cliente. Exige foco em sua aplicação não permitindo desperdícios

Suporte: o suporte funciona como uma ponte de contato entre o cliente e a

equipe do projeto referente ao software desenvolvido e já implantado. Seu

maior objetivo é manter o software em funcionamento.

Nesta etapa é recomentado trabalhar com a metodologia SCRUM, onde

ao receber o comunicado a respeito de um problema no software, ele seja

solucionado. Com a aplicação do SCRUM que trabalha com o desenvolvimento

em partes do software, no suporte funciona da mesma forma. Cada reparo que

ingressa na etapa é assumido por um membro da equipe e é ele quem buscará

solução para o problema.

A equipe responsável pelo suporte necessita conhecer pelo menos o

básico do software para fornecer orientações ao usuário quanto o seu

funcionamento.

Quando o suporte não consegue dar uma solução ao problema ele é

repassado à equipe de desenvolvimento para uma solução. No momento em

que o problema apresentado afeta alguma regra de negócio que atinja a

funcionalidade de alguma parte do software, ele é levado a equipe de

arquitetura ou design do projeto seguindo as etapas de forma incremental.

14

Qualquer alteração no software solicitada pelo cliente ou desenvolvida

pela equipe do projeto gera a necessidade de retorno às etapas anteriores do

projeto na forma incremental. Este retorno irá verificar o que será afetado no

software caso a alteração venha acontecer e dependendo da abrangência dela

pode-se fazer uma atualização ou a criação de um novo projeto.

Caso o projeto tenha sido concluído e o software continue em uso, faz-

se uso de sua documentação, experiência do usuário e da equipe de suporte

para solucionar o problema apresentado.

Documentação: a documentação de software possui duas vertentes, uma

técnica e outra explicativa destinada ao usuário. A vertente técnica tem início

no registro dos requisitos levantados junto ao cliente e é concluída somente

quando o software sai de uso. Em quanto à documentação destinada ao

usuário, funciona como um manual relatando o funcionamento do software.

Uma metodologia indicada é a RUP, nela há um fluxo de trabalho para

determinar as melhores práticas que foram utilizadas no projeto e assim

registrá-las. A documentação técnica funciona como um diário de bordo com

registros de todos os passos dados, desde ociosidades, produtividades,

alterações e inovações.

A RUP, como busca as melhores práticas, apresenta uma boa didática

para com a documentação. Essa etapa trabalha no decorrer de todo o projeto.

Teste: a maioria das metodologias prega que os testes devem começar

quando parte do código está pronta. Neste artigo prega-se que os testes

devem ter início quando começam as definições das funcionalidades do

software (ainda na etapa de design) e percorre de forma transversal todo o

projeto.

Um dos objetivos da etapa de teste é a busca por defeitos existentes no

que é planejando e desenvolvendo. A etapa de teste está dividida em partes,

como a bateria de Requisitos onde são avaliados os requisitos existentes e

suas interações, a bateria de Integração que busca saber se a interação entre

as partes do software atende às expectativas de funcionamento, a bateria de

15

Unidade analisa os elementos que possam ser tratados de forma lógica, como

uma classe.

Após o término das baterias citadas, existe a bateria de Aceitação onde

um representante do cliente, seja um usuário ou alguém com capacidade

técnica para avaliar, venha testar a fim de validar o software desenvolvido

oferecendo um aceite para o trabalho realizado ou negação do mesmo.

5. CONCLUSÃO

Visando um produto final com qualidade o projeto necessita de uma boa

gestão, trabalho em equipe e que os requisitos, desejos e expectativas do cliente

sejam alcançados.

Para um bom resultado nos trabalhos de um projeto e principalmente no seu

produto há de ter organização, esta organização se consegue com a aplicação de

metodologias e métricas e uma boa documentação. Com esta aplicação o projeto é

guiado para um software de qualidade, mantendo a essência dos requisitos e

necessidades do cliente.

As diferentes metodologias existentes trabalham focando uma ou outra etapa

do projeto de desenvolvimento de software e combinando-as de forma a oferecer o

que elas têm de melhor, facilitando o trabalho esperado.

Cabe ao gestor do projeto fazer suas escolhas quanto ao que será feito.

16

ABSTRACT

Currently the teams involved in software development projects have a number of alternative methodologies, processes and best practices for conducting this type of project. Many of them can be applied partially or completely, on its own or in combination. This multiplicity of options creates difficulties for management teams in the choice of processes that must be effectively implemented in each stage of the project. Such difficulties are more severe in areas with less consistent methodologies. This article presents some alternatives for project management, describing its main features and applications. Also highlighted are the differences in approach between the traditional and agile methodologies. For each stage of the life cycle of a typical software project, suggestions are made for the implementation of some of the alternatives discussed (whether agile or traditional) having as main objective the adoption of best practices with proven use in the pursuit of improved quality of the products generated in this type of project.

Keywords: Software Project. Development Methodologies. Project Life Cycle.

REFERÊNCIAS

DIAS, Marisa Villas Boas. ENGENHARIA DE SOFTWARE MAGAZINE. Métodos

Ágeis de Desenvolvimento de Software, Rio de Janeiro, v. 2, n. 20, 2010.

FAGUNDES, Priscila Basto. Framework para comparação e análise de métodos

ágeis. 2005. 134p. Dissertação (Mestrado em Ciência da Computação).

Universidade Federal de Santa Catarina, Florianópolis, 2005.

FRANSSON, Oskar; af KLERCKER, Patrick. Agile Software Development in

Sweden – A quantitative study of developers´ satisfaction and their attitude

towards agile thinking. Dissertação de mestrado em Informática. Jönköping

University: Sweden, 2005.

KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de software:

aprenda as metodologias e técnicas mais modernas para desenvolvimento de

software. 2. ed. São Paulo: Novatec Editora, 2007.

17

PAULA F.,Wilson de Pádua. ENGENHARIA DE SOFTWARE, fundamentos,

métodos e padrões. 2. ed. Rio de Janeiro, 2005.

PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São

Paulo, 2004.

SATO, Danilo. ENGENHARIA DE SOFTWARE MAGAZINE. Introdução à

Programação Extrema (XP), Rio de Janeiro, v.1, n.10, 2009.

SBROCCO, José Henrique Treixera de Carvalho Metodologias águeis: engenharia

de software sob medida. 1. ed. São Paulo, Érica, 2012.

SILVA,Ricardo Pereira. UML: Modelagem Orientada a Objetos. Florianópolis,

Visual Books, 2007.

SOMMERVILLE, Ian. Engenharia de software, 8. ed. São Paulo: Pearson Addison-

Wesley, 2007.