Page 1

1

METODOLOGIAS PARA GESTÃO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE COMBINANDO ABORDAGENS ÁGEIS E TRADICIONAIS

1

Henrique Pereira Oliveira d’Eça Neves

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 Requisitos Design Arquitetura Desenvolvimento Implantação Suporte Documentação Teste

Metodologia-Método BPM BPM / UML / PMBox UML / XP / PMBox / SW-CMM SCRUM / XP SCRUM / LEAN SCRUM RUP 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, fazse 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 AddisonWesley, 2007.

METODOLOGIAS PARA GESTÃO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE  

Abordagem, dentro da engenharia de software, sobre as metodologias mais utilizadas e as possíveis mesclas entre metodologias ágeis e tradici...

Read more
Read more
Similar to
Popular now
Just for you