____________________________________________________________________________
105
Gestão de projetos técnicos de baixa complexidade: a relação entre projeto, gestão e desenvolvimento do site SETIS
Bruno Bergmann bernemano@gmail.com
Felipe Valtl de Mello valtlfelipe@gmail.com Gabriel Hobold gabriel.hobolds@gmail.com
Jorge Hess jorgeluis.hess@gmail.com
Resumo: Demonstração do processo de criação de um software de baixa complexidade onde várias equipes foram envolvidas. Este projeto fez uso de várias técnicas, bem como contou com auxílio de ferramentas para criação de cronogramas, distribuição das atividades, de forma a auxiliar no aumento da velocidade de desenvolvimento e na realização de testes do sistema. Com isto verificou-se que foi possível criar um software completo, incluindo a sua documentação e que foi entregue no prazo acordado. O presente artigo descreve a narrativa desta construção.
Palavras-chave: Experiência. Dificuldade. Programação. Projeto. Colaboração.
1 Introdução
Neste artigo será discutido o processo da criação do software criado pela turma de análise e desenvolvimento de sistemas do SENAI, para o evento SETIS. A metodologia utilizada para a criação se baseava na retirada de informações do cliente conforme proposta no modelo em cascata. Além da criação de vários documentos, entre eles, descrições de casos de uso e seus diagramas conforme proposto pela UML. Fazendo assim o uso de duas abordagens metodológicas, buscando extrair as melhores práticas de ambas para atingir os objetivos do projeto.
Também foi proposto a divisão dos módulos a serem feitos para o software final, entre as várias equipes que compuseram a sua construção. Por fim, após os testes finais terem sido feitos e validados, uma consolidação de todos os módulos foi feita, resultando assim na entrega oficial para o cliente. Para que projeto flui-se da melhor forma, foi criada uma equipe de controle para realizar o monitoramento das atividades e especificar a criação de padrões para a construção do software.
____________________________________________________________________________
106 2 Revisão da Literatura
2.1 Projeto de Software
Dentro da construção de um sistema existem várias etapas onde são construídos vários artefatos de softwares, como modelos que envolvem a identificação e descrição das abstrações do novo software.
Para Sommerville (2011) o processo de desenvolvimento possui quatro atividades fundamentais:
1- Especificação de software, onde os cliente e desenvolvedores definem o que será produzido;
2- Desenvolvimento do software, onde o software é projetado e programado; 3- Validação de software, onde é checado se o sistema atende os requerimentos
do cliente;
4- Evolução do software, onde o sistema é modificado para atender os requisitos do cliente e do mercado.
O modelo que aborda as etapas de desenvolvimento do projeto SETIS é o de Royce (1970), conforme a Figura 1.
____________________________________________________________________________
107
Fonte: Adaptado de Royce (1970).
Conforme o modelo descrito na Figura 1, na parte inicial do projeto é feita a comunicação de abertura e o levantamento de requisitos. Após o levantamento, o projeto passa para a parte de planejamento, onde são levados em consideração cronogramas, estimativas, custos etc. A terceira etapa refere-se a modelagem, onde são feitas a análise do que será implementado, diagramas necessários e informações relevantes que auxiliarão na etapa de construção. Na etapa de construção o projeto é codificado e após a conclusão dessa etapa ele é testado indo para a última etapa, a de implementação, onde é feita a entrega do projeto e também as manutenções pós-entrega. No processo de desenvolvimento do projeto foram utilizados alguns artefatos disponibilizados pela “Linguagem de Modelagem Unificada” (UML), a qual serve de auxílio para criação de documentos, como casos de uso (BOOCH, 2012).
2.2 Gestão de Projeto
Assim como usar uma metodologia de desenvolvimento é um desafio na construção de um sistema, realizar a gestão da construção deste mesmo sistema, é algo que necessita um vasto conhecimento na área de aplicação do projeto e também em práticas gerenciais. A prática com administração se torna importante, pois com esta habilidade entende-se que há uma melhor capacidade no desenvolvimento de comunicação pessoal e um maior espírito de liderança.
Gerência de projetos ou gestão de projetos é a aplicação de conhecimentos, habilidades e técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos predefinidos. O conhecimento e as práticas da gerência de projetos são mais bem descritos em termos de seus processos componentes. (CARIBÉ, João Carlos, 2008, p.4)
O gestor de projeto deve trabalhar para conseguir manter o desenvolvimento em um ciclo contínuo e também a interação de todos os participantes da equipe de desenvolvimento, assim reduzindo o risco de fracasso do processo. Quando se fala em gestão de projetos um fato importante é procurar seguir uma metodologia para ter maior
____________________________________________________________________________
108
controle sobre recursos que deverão ser utilizados no projeto, assim se tornando mais eficiente e tendo um aumento no grau de acerto, porém se deve utilizar de uma adequada ao grau de complexidade do projeto em questão.
A comunicação é um item extremamente importante para gestão de projetos, procurar dialogar e realizar reuniões com os membros da equipe do projeto é algo essencial, pois esclarece as dúvidas de maneira geral e aumenta a comunicação entre os membros da equipe, deixa a solução de problemas muito mais fácil.
2.3 Desenvolvimento de Software
O desenvolvimento de um software é um processo complexo e que exige equipes qualificadas e uma boa gestão, além de contínuo feedback (comentários) das pessoas envolvidas no desenvolvimento do projeto e do cliente. Há quatro grandes desafios no processo de desenvolvimento de um software, análise de requisitos, tempo, usabilidade e testes.
2.3.1. Análise de requisitos
Antes de tudo é necessário um bom projeto e uma boa documentação referente as necessidades do cliente, esses são fatores essenciais no desenvolvimento, e que caso não sejam realizados de maneira correta, podem vir a acarretar uma demanda desnecessária de trabalho, e, possivelmente, um resultado diferente do esperado. Essa etapa é a que mais exige do cliente, onde ele deve passar todas as informações, necessidades e situações problemas, que os desenvolvedores poderão precisar. (WAZLAWICK, 2011)
2.3.2. Tempo
É importante estipular e estabelecer datas e prazos para as diversas etapas do desenvolvimento até a entrega do software ao cliente. O processo de desenvolvimento não é preciso, e pode gerar imprevistos que podem acarretar no processo de uma etapa e até atropelar o prazo, atrasando o projeto. Além disto, estipular prazos faz com que as pessoas envolvidas no projeto fiquem mais atentas as atividades e deem prioridade para as tarefas corretas (MARTINS, 2010).
____________________________________________________________________________
109 2.3.3. Usabilidade
A usabilidade é crucial para o usuário final e visa identificar as qualidades relacionadas com a interação entre o usuário e o software. A usabilidade é definida por um grau de facilidade que um usuário consegue interagir com o sistema e/ou interface (KRUG, 2010).
2.3.4. Testes
Os testes fazem parte do processo de finalização de um software, antes da entrega do mesmo. Onde é executado uma série de testes controlados para avaliar o comportamento e as características, onde a intenção é verificar se estão de acordo com o que foi projetado, após a realização dos testes por parte dos desenvolvedores, é realizada a etapa de testes por parte do cliente (DELAMARO, 2007).
2.4 Software de baixa complexidade
Um software de baixa complexidade pode-se caracterizar por possuir apenas uma ou duas funções, como entradas e saídas, ele não possui interação com outras plataformas já criadas ou em desenvolvimento, assim, não é necessária a utilização de várias ferramentas que a UML dispõe para a fase de projeto do mesmo.
Com um sistema simples não é necessária à alocação de uma quantidade grande de recursos para o desenvolvimento, o que gera por consequência baixos custos para a produção e um curto prazo de entrega (SOUZA, 2014, no prelo).
3 Metodologia
No projeto SETIS foi utilizado como base para a estruturação das atividades o modelo de desenvolvimento em cascata, conforme Figura 1. No Quadro 1 é representada a divisão das atividades das equipes com base no modelo cascata de Royce (1970).
Cada equipe recebeu uma etapa do desenvolvimento do projeto SETIS. A equipe 4 corresponde a 1ª etapa de desenvolvimento segundo o modelo de Royce, onde é feita a primeira comunicação com o cliente e o levantamento de requisitos. A fase de planejamento foi feita pela equipe 2, onde foram feitos os cronogramas e a divisão das
____________________________________________________________________________
110
atividades. A equipe 4 ficou responsável pela terceira fase do projeto, onde foi feita a análise dos requisitos e a modelagem do sistema.
Após as etapas descritas acima iniciou-se a fase de codificação e testes, que envolveu diretamente as equipes 5, 6, 7 e 8. Por fim, a etapa de implantação envolveu a equipe 2 com a consolidação, finalização e publicação do sistema na web. A equipe 1 esteve envolvida em todas as etapas de desenvolvimento.
No início do projeto, na fase de planejamento e modelagem, foram utilizados artefatos disponibilizados pela UML, tais como as descrições e diagrama de casos de uso, requisitos funcionais e não funcionais e definição das regras de negócio.
3.1 Divisão das Equipes
Dentro da proposta de trabalho para o desenvolvimento do Software, foi proposta a gestão das atividades de pessoas. Conforme o Quadro 1.
Quadro 1 – Distribuição das Equipes da Sala
Nº Equipe Quant. de
Pessoas
1 Orientadores 4
2 Controllers 4
3 Equipe de documentação de levantamento, análise e especificação
de regra de negócios e requisitos.
13
4 Equipe de controle de versão de documentação de levantamento,
análise e especificação de regras de negócios e requisitos.
3
5 Equipe de desenvolvimento de front-end. 3
6 Analista Web 1
7 Equipe de desenvolvimento de back-end. 10
8 Alfa Teste. 1
____________________________________________________________________________
111
Assim, durante o processo de desenvolvimento do software SETIS, a sala de aula foi dividida em várias equipes. A equipe de orientadores ficou encarregada de direcionar os primeiros passos para as equipes e fornecer a ajuda necessária, também era a responsável por realizar a avaliação do desempenho das pessoas envolvidas.
A equipe de Controle (Controller), ficou responsável pelo gerenciamento do projeto, distribuição das tarefas e criação de documentos para suporte no desenvolvimento do software. Toda a padronização por parte de código e funções do sistema foram criadas também pela equipe de controle, o cronograma e a data de entrega das atividades foram gerenciadas pela equipe em conjunto com os orientadores do processo.
A equipe de documentação, sendo essa de levantamento, análise e especificação das regras de negócios e requisitos ficou encarregada de realizar o levantamento dos casos de uso, assim como os requisitos funcionais e não funcionais do software, criação de seus respectivos documentos e realizar a atualização dos mesmos assim que necessário.
A equipe de análise e especificação das regras de negócios e requisitos ficou responsável pelo primeiro contato com o cliente e a realização do levantamento das regras de negócios assim como a criação da documentação da mesma.
A equipe de Front-End ficou responsável pelo desenvolvimento do layout além da parte visual do software, adequação do conteúdo para acesso via computadores, tablets e celulares.
A equipe de Back-End ficou responsável pela programação do software e realização dos testes propostos pela equipe de controle.
O alfa teste foi realizado por apenas uma pessoa orientada pela equipe de controle. Para estes testes foi utilizada de base uma planilha, no qual esta foi desenvolvida pelo tester, nesta continham as dúvidas e erros encontrados, porém, o foco principal desta etapa foi a realização dos testes controlados.
____________________________________________________________________________
112
A seguir serão mostradas as ferramentas utilizadas pela equipe de controle para o gerenciamento do processo de criação do sistema. Na Figura 2 é exibida a ferramenta para controle do projeto escolhida pela equipe de controle, o Trello. Esta ferramenta baseia-se na estrutura de post-it, onde foram definidas as colunas (A Fazer, Fazendo, Pronto) para auxiliar a visualização das tarefas que cada equipe estava encarregada de fazer.
Figura 2 - Janela do Trello
____________________________________________________________________________
113
Figura 3 - Janela do Google Drive
Fonte: Os Autores (2014)
Na Figura 3 é exibida janela do Google Drive, ferramenta utilizada para o armazenamento de arquivos públicos, como a documentação em geral e backups de segurança. Uma das vantagens da utilização desta ferramenta é a possibilidade de pessoas registradas compartilharem os arquivos, além de tê-los disponíveis de qualquer lugar.
____________________________________________________________________________
114
Fonte: Os Autores (2014)
Na Figura 4 são exibidos todos os documentos utilizados durante o processo de desenvolvimento do software SETIS, arquivos de projeto (especificação de casos de uso, diagrama de casos de uso, especificação de requisitos, situação problema, regras de negócio) além dos documentos de controle (testes iniciais, teste de usuário, nomenclatura de variáveis, documento para desenvolvimento do software SETIS e log de atualização).
4 Resultados e discussão
Para uma análise crítica do desenvolvimento, pontos considerados negativos foram levantados para evidenciar a complexidade das ações em ambiente de trabalho associado a capacidade técnica, trabalho em equipe e compreensão de negócio.
4.1 Pontos Negativos
● O processo de aquisição das funções do software foi feito por integrantes sem muita vivência na área de desenvolvimento de sistemas;
● Problemas devido à inexperiência das equipes envolvidas no processo; ● Muitas versões de documentos;
____________________________________________________________________________
115 ● Documentação com problemas de dados;
● Falta de leitura da documentação por parte das equipes de programação;
● Desnível de conhecimento entre equipes, gerando uma dificuldade / facilidade no cumprimento de tarefas.
A grande dificuldade notada durante o início do projeto e que, gerou problemas durante todo o processo, foi à inexperiência das pessoas envolvidas na atividade inicial do software. Nesta parte do desenvolvimento foram gerados alguns problemas que poderiam ter sido evitados, como a necessidade de diversas atualizações no projeto e problemas na etapa de programação do software.
Para a criação de um software de qualidade é essencial a descrição dos casos de uso e diagramas, porém, durante a criação destes foi notada a falta de conhecimento técnico em programação, devido à falta de vivência da equipe no desenvolvimento de softwares. Os programadores irão retirar as informações necessárias para a construção dos programas que farão parte do software a partir das descrições e dos diagramas, porém isto ocorreu de uma forma um pouco acelerada, tendo a necessidade de reajustes no projeto durante a fase de programação, algo que veio a prejudicar muito a data de entrega do software.
Durante a penúltima fase do projeto, a de programação, foram contados os menores problemas específicos, além dos já gerados devido a erros em etapas anteriores a esta, estes problemas foram em geral por falta de atenção e leitura por parte dos programadores, muitos programas possuíram erros devido à falta de leitura e atenção da documentação do projeto, assim necessitando um reajuste por parte da equipe de controle durante a fase de testes.
Os testes foram realizados pelos programadores com base em uma documentação criada pela equipe de controle, tendo em vista evitar erros nos programas, focando em padrões nominais e estrutura geral, infelizmente. Os testes foram realizados de forma equivocada novamente, deixando tarefas adicionais que poderiam ser evitadas com a equipe de controle.
Mesmo com os aspectos negativos apresentados, muitos pontos podem ser observados como positivos.
____________________________________________________________________________
116 4.2 Pontos Positivos
● Bom tempo para a realização das atividades relacionadas ao projeto; ● Equipe entrosada;
● Boa comunicação entre equipes; ● Ajuda entre equipes;
● Ótima experiência por parte de desenvolvimento e monitoramento;
● Pessoas que possuem mais afinidade com projeto/programação puderam fazer o que gostam;
● A documentação gerada auxiliou o processo;
● Pessoas puderam escolher com quem realizar os processos de desenvolvimento.
O processo foi realizado em um tempo considerável, excedendo em alguns dias a data final do cronograma, visto a complexidade do mesmo, a construção das equipes foi organizada preferenciando pessoas que já tinham contato e assim, criando um entrosamento muito maior. Porém, esta divisão em certos casos veio a prejudicar o processo, devido a pessoas que não possuem convivência com a área técnica estarem em equipes de trabalho iguais. Causando um desempenho inferior em relação ao resto da turma, isto poderia ter sido ajustado com um melhor balanceamento das equipes, mesmo assim, a integração entre equipes foi algo muito positivo e auxiliou o projeto como um todo. Mesmo com os problemas de documentação descritos, anteriormente, notou-se que foi de grande ajuda durante a fase de programação, justamente, pelo uso de framework de baixa complexidade criado pela equipe de controle.
No fim, muitas pessoas ficaram restritas as partes das quais se sentiam mais confortáveis, tanto em projeto quanto em programação, isto é bom, pois faz com que estas mesmas desenvolvam com maior empenho e dedicação, contudo, é muitas vezes a falta de conhecimento da outra área, trazendo erros que a pessoa não percebe por si própria.
4.3 Pontos a melhorar
____________________________________________________________________________
117
● Mais pessoas envolvidas nos projetos, para melhor revisão do mesmo;
● Mais interesse por parte de programação para com a leitura da documentação antes de iniciar as suas tarefas;
● Ao menos uma pessoa de programação / projeto em ambas as etapas programação / projeto;
● Mais pessoas disponíveis para a realização de testes; ● Pessoas se envolverem em ambos (projeto e programação).
No final do trabalho, pode-se perceber que o grande problema ocorrido durante o processo foi à inexperiência das pessoas envolvidas nesse tipo de atividade. Aliado a resistência das pessoas de se envolverem em ambas as áreas do processo, documentação e programação, prejudicou o andamento do projeto. Porém, isto poderia ser, facilmente, ajustado com a melhor preparação das pessoas envolvidas. Algo notado, e que poderia ser aplicado junto a equipe responsável na fase de planejamento, seria a alocação de uma pessoa com experiência técnica na área de programação, que poderia apresentar soluções que fossem mais realistas para a fase de Construção.
Uma necessidade crucial para o desenvolvimento de um software é uma boa fase de testes. Infelizmente, não houveram muitas pessoas disponíveis para a sua realização, e de forma negativa, os programadores deixaram algumas falhas passarem na fase primordial dos testes. Fazendo com que houvesse uma carga considerável de acertos para a equipe de controle resolver, isto poderia ser ajeitado facilmente com um maior interesse por parte dos programadores na fase de realização dos testes, além do auxílio da equipe de controle. Houve a distribuição de um documento para testes, que foi mal utilizado pela maior parte.
5 Conclusão
O processo foi algo que trouxe muito conhecimento e uma nova experiência para todos que participaram, pode-se perceber o quanto a programação depende da fase de projeto, e que a mesma precisa ser elaborada com cuidado, para que se possa evitar erros e reajustes desnecessários no processo final do projeto. Também não foi percebido
____________________________________________________________________________
118
que trabalhar com duas metodologias tenha causado estranheza ou maiores contratempos aos participantes do projeto.
Mesmo em um projeto bem elaborado, aquele que atende as necessidades do cliente e auxilia de forma eficiente a equipe de produção, podem ocorrer ajustes. Porém, para que o projeto se desenvolva de forma adequada é necessário que exista pessoas com um conhecimento relevante durante a etapa de documentação dos requisitos.
Durante o processo ocorrido no SETIS os resultados obtidos foram satisfatórios, contudo, devido a alguns contra tempos durante a fase de programação e diversos ajustes pós análise, houve um atraso no prazo de entrega do produto ao cliente.
Conclui-se que não se deve ignorar a documentação durante a produção do software, pois, é com esta que se podem evitar grandes contratempos e retornos desnecessários, agilizando assim a entrega do produto. E a experiência da equipe tende a ser um fator que contribui para o bom andamento do projeto, independente da metodologia adotada.
Referências
BOOCH, Grady. A UML: Guia do Usuário. Rio de Janeiro: Elsevier, 2012.
CARIBÉ, João Carlos. Gestão de projetos: Aplicada à Web. 2008. Disponível em: < http://www.madeira.ufpr.br/disciplinasklock/gestaodeprojetos/Apostila GPleitura.pdf>. Acesso em: 25 ago. 2014.
DELAMARO, Márcio E. Introdução ao Teste de Software. Rio de Janeiro: Elsevier, 2007.
KRUG, Steve. Não me Faça Pensar!. Rio de Janeiro: Atla Books, 2010.
MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. 5. ed. Rio de Janeiro: Brasport, 2010.
ROYCE, Winston W. Managing the development of large software systems. In: proceedings of IEEE WESCON. 1970.
SOMMERVILLE, Ian. Engenharia de Software. 9.ed. São Paulo: Pearson Education, 2011.
____________________________________________________________________________
119
SOUZA, Renan, DIAS, Juliana R. Metodologia de Desenvolvimento de Software de Baixa Complexidade. No prelo 2014.
WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2011.
