Por que eu devo ler este artigo:

Para reduzir os riscos envolvidos no desenvolvimento de projetos, ferramentas de apoio ao desenvolvimento têm sido criadas.

Estas ferramentas auxiliam projetistas, analistas, desenvolvedores, testadores e demais profissionais de TI no acompanhamento e gerenciamento das atividades, custos associados ao projeto e desvios na implementação da solução.

Este artigo apresenta o uso de duas ferramentas que apoiam o desenvolvimento de sistemas de uma unidade hospitalar, mostrando como é feito o gerenciamento e controle da evolução das atividades da equipe de desenvolvimento de sistemas por meio destas ferramentas.[

Dentro de um ambiente de desenvolvimento de software, seja em uma empresa de pequeno, médio ou grande porte com uma equipe de Tecnologia da Informação (TI) ou uma software house, há uma demanda reprimida de desenvolvimento de sistemas que não condiz com a quantidade de colaboradores na equipe.

Demandas estas que exigem entregas cada vez mais rápidas, a um custo limitado aos recursos da empresa e com alta qualidade a fim de reduzir o retrabalho e, por consequência, custo e prazo de entrega. Se um dos elementos for negligenciado, todo o projeto corre o risco de fracassar.

Neste cenário, não é difícil de ver projetos serem descartados ou inutilizados pelo fato de um dos três pilares (tempo de entrega, custo e qualidade) não serem atendidos.

Tendo então, a equipe de TI, que se justificar frente aos gestores sobre as falhas que ocorreram no processo de desenvolvimento do software em questão.

Isto é ainda mais agravado pela falta de documentação dos processos de desenvolvimento de sistemas e a comunicação falha entre a TI e a alta direção das empresas.

Para minimizar a taxa de projetos fracassados, ferramentas de apoio ao desenvolvimento têm sido criadas. Estas ferramentas auxiliam projetistas, analistas, desenvolvedores, testadores e demais profissionais de TI no acompanhamento e gerenciamento das atividades (cronograma), custos associados ao projeto e desvios (requisitos não especificados) na implementação da solução.

Este artigo se propõe a apresentar as ferramentas de apoio ao desenvolvimento de sistemas em uma rede de hospitais, fornecendo seus pontos fracos e fortes na visão dos usuários e desenvolvedores da solução.

O mesmo se inicia mostrando o ciclo de vida do software, por conseguinte, é apresentado o ambiente de trabalho, o fluxo de desenvolvimento de sistemas e as ferramentas utilizadas.

O ciclo de vida do software

O ciclo de vida do software ou o ciclo de vida do desenvolvimento de sistemas se refere aos estágios necessários para se desenvolver um sistema ou partes dele.

Todo sistema ou componente de sistema, antes de utilizado pelo usuário, precisa ser projetado, desenvolvido, utilizado e sofrer melhorias até que, ao final de seu ciclo, seja inutilizado ou substituído.

O objetivo desta segmentação é a de criar subprodutos bem definidos que comporão o produto final, porém que serão validados e homologados em cada uma destas etapas. Com isso, especializam-se as etapas de desenvolvimento e acompanhamento da construção dos sistemas, direcionando profissionais com habilidades específicas para o gerenciamento de cada fase.

O ciclo de vida do software é explicitado nos modelos de desenvolvimento de sistemas. Como exemplo, pode-se citar o , o qual possui as seguintes fases:

· Comunicação: é onde o projeto se inicia através do levantamento de requisitos;

· Planejamento: nesta fase o projeto é pensado em termos de recursos disponíveis (tempo, pessoas, custo etc.);

· Modelagem: o sistema começa a ser planejado para o devido desenvolvimento e posterior utilização pelo usuário;

· Construção: os desenvolvedores iniciam a codificação do sistema com o apoio dos projetistas que modelaram o sistema e com o apoio dos testadores que irão testar as funcionalidades com base no que foi especificado na fase de comunicação; e

· Implantação: entrega do sistema para o usuário, o qual utilizará a solução no dia a dia e fornecerá feedback à equipe de desenvolvimento para possíveis ajustes e melhorias.

Inicialmente, este modelo era estático e não contemplava o retorno para fases anteriores, porém, com o passar do tempo, percebeu-se que ao decorrer do desenvolvimento de sistemas é necessária a participação dos stackholders que participaram das fases iniciais.

Com isso, o modelo em cascata deixou de ser estritamente unidirecional, tendo retornos para as fases iniciais sempre que encontrado dificuldades em prosseguir com o projeto nas fases posteriores.

Ressalta-se ainda que erros de projeto e desenvolvimento não devam ser identificados apenas nas fases finais do ciclo de vida, visto o elevado custo que gerará para o projeto, já que será necessário identificar a origem do erro que pode estar nas fases iniciais.

Este custo e o desperdício de tempo dos profissionais devem ser minimizados, já que o dia a dia exige que o software se adeque à realidade do negócio, sofrendo alterações de regras de negócio para atender ao público ou a uma determinação governamental, por exemplo.

Ambiente de trabalho

A unidade hospitalar considerada para análise nesse artigo conta com equipe própria de tecnologia da informação a qual é responsável pelo suporte a equipamentos, gerenciamento de servidores, desenvolvimento e implantação de sistemas.

O Sistema de Informação Hospitalar (HIS – Health Information System) é responsável por armazenar, gerenciar e processar dados referentes ao atendimento do paciente em todas as áreas hospitalares, desde a entrada do paciente pela emergência até a sua alta, passando pela assistência médica, farmacêutica, nutricional, enfermagem, ou seja, por toda assistência ao paciente.

Este HIS foi desenvolvido por uma equipe de tecnologia da informação da própria instituição, a qual é composta por um administrador de banco de dados, seis analistas de sistemas e dois coordenadores. As ferramentas de desenvolvimento Oracle, associadas ao Redmine e ao Tortoise SVN apoiaram a equipe na construção do HIS.

A decisão de se ter uma equipe própria de desenvolvimento de sistemas fornece à instituição uma capacidade de decisão e mudança de regras mais rápidas, visto que não é necessária toda a parte burocrática existente em uma software house, a qual teria de agendar visita para estudo da alteração a ser realizada, analisar impactos nos demais clientes, gerar orçamento, aguardar aprovação da direção da instituição, enfileirar a demanda, aguardar desenvolvimento do sistema, testes e implantação.

A depender do contrato e do custo da alteração, uma simples alteração pode demorar muito tempo para ser implantada, o que não é compatível com a velocidade de mudança dos negócios atuais.

A Figura 1 mostra resumidamente as etapas de desenvolvimento de solicitações feitas para a TI, a qual pode sofrer pequenas alterações a depender da complexidade da solicitação. O processo inicia quando o usuário faz uma solicitação de alteração ou criação de um sistema. Em seguida, o analista faz o levantamento dos requisitos com o usuário.

Neste momento são identificadas todas as necessidades e prazos para implantação do sistema, o que resultará em um documento com todas as informações coletadas. Este documento é analisado internamente na TI pelos analistas, os quais farão a análise de impactos e definirão como o sistema será construído.

As tarefas são definidas pelos coordenadores, cadastradas no Redmine e distribuídas para os analistas e para o administrador de banco de dados. O DBA então define as tabelas e os tipos de dados nas ferramentas da Oracle e gera o banco de dados.

De posse das tarefas definidas no Redmine, os analistas iniciam o desenvolvimento da solução apoiados pelo gerenciador de controle de versões Tortoise SVN e realizam testes de unidade após a implementação de cada atividade.

Após todas as tarefas concluídas, o analista que fez o levantamento dos requisitos realiza testes em todo o sistema para verificar se há alguma inconsistência com os requisitos. Em caso afirmativo, os analistas e coordenadores analisarão os impactos destas inconsistências e redistribuirão as tarefas, caso não haja, o usuário é convidado a testar a solução. Caso o usuário aprove o que foi desenvolvido, o sistema é implantado e as pessoas capacitadas a utilizá-lo.


abrir imagem em nova janela

Figura 1. Processo resumido de desenvolvimento de sistemas

Redmine

O Redmine é um gerenciador de projetos gratuito que permite aos gestores de projetos definirem os projetos das empresas com suas respectivas atividades às direcionando a analistas específicos.

Na unidade hospitalar considerada, todos os projetos, sejam de sistemas novos, correções ou melhorias em sistemas já existentes, são inicialmente discutidos com o auxílio do quadro branco, onde todas as atividades são identificadas. Estas tarefas são então inseridas no redmine dentro de um dos projetos já existentes e distribuídas para cada analista.

O Redmine é então organizado em diversos macro projetos relacionados à área de saúde, os quais são divididos em projetos menores, sendo que cada projeto é composto por atividades. Na Figura 2 é possível visualizar alguns projetos do Hospital, são eles: alergias, aprazamento eletrônico, checagem eletrônica de medicamentos, controle de acesso, dentre outros. Cada projeto será composto por diversas atividades que serão destinadas a analistas ou desenvolvedores.


abrir imagem em nova janela

Figura 2. Tela de projetos do Redmine

A Figura 3 mostra as atividades que foram cadastradas para o projeto Faturamento. Nesta figura é possível identificar que cada tarefa possui algumas propriedades. Dentre elas estão:

· # : o identificador da atividade;

· Tipo: se é uma nova funcionalidade ou a correção de um defeito;

· Criado em: data de criação da atividade pelo analista ou gestor;

· Prioridade: o grau de prioridade que a equipe de desenvolvimento deve dar a esta atividade (pode variar de baixa a imediata);

· Situação: registra o status da atividade que pode ser:

o Nova: atividade criada, mas que ainda não foi direcionada para desenvolvimento a algum analista;

o Em Andamento: atividade já foi direcionada a algum analista e está sendo desenvolvida a solução;

o Resolvida: analista finalizou a implementação da solução;

o Em Aguardo: atividade necessita de algum recurso ou informação a mais para ser entendido pelo analista, o qual aguarda retorno do gestor ou de outro analista ou do usuário;

o Fechada: analista finalizou o desenvolvimento e o gestor aprovou a implementação. Neste momento, uma outra atividade de testes e correções pode ser iniciada direcionada a outro analista.

· % Terminado: quanto o projeto está próximo de finalizar. Fornece ao analista o andamento de seu trabalho e permite ao gestor acompanhar a produtividade de sua equipe;

· Título: descrição sucinta da atividade que está sendo desenvolvida;

· Atribuído para: nome do analista responsável pela implementação da atividade;

· Tempo estimado: tempo aproximado, em horas, que o analista gastará para implementar a solução. Também é utilizado pelo gestor para prever quando poderá iniciar novas atividades ou novos projetos;

· Tempo gasto: quanto tempo o analista se dedicou na resolução daquela atividade.


abrir imagem em nova janela

Figura 3. Lista de atividades do projeto Faturamento

A tela exibida também pode ser utilizada como um dashboard de acompanhamento das atividades de cada analista, visto que todas as informações necessárias para o acompanhamento das atividades estão neste quadro.

Ao cadastrar estas atividades, o usuário ainda pode definir os observadores, ou seja, as pessoas que irão acompanhar a evolução daquela atividade e poderão opinar sobre a sua evolução. Podem anexar documentos, imagens, áudio e vídeo que facilitem o desenvolvimento e que mantenham o máximo de documentação possível que norteou a atividade.

O Redmine encaminhará um e-mail para cada observador toda vez que alguma modificação foi realizada na tarefa.

Ao clicar na tarefa é possível ver todo o histórico de evolução com os comentários e sugestão dos envolvidos, além das modificações que foram feitas em cada atividade em cada um dos atributos das atividades.

Esta ferramenta permite ainda que seja visualizado o gráfico de Gant e o calendário das tarefas, conforme a Figura 4, a qual exibe as funcionalidades a serem implementadas no mês de Julho de 2014.


abrir imagem em nova janela

Figura 4. Calendário de tarefas

O Redmine possui ainda uma tela que mostra aos desenvolvedores quais atividades estão atribuídas a ele para que o mesmo possa gerenciar suas atividades e priorizar o que deve ser feito sem precisar consultar projeto a projeto registrado na ferramenta.

A Figura 5 mostra esta tela, a qual é acessada através do link “Minha Página” disponível na parte superior esquerda da imagem. Nesta figura é possível verificar que a tarefa “Sugerir data e hora de alta internamento” é nova, faz parte do projeto “Emergência” e é uma funcionalidade a ser incluída no sistema.

Além disso, é possível visualizar ainda as tarefas em que este usuário foi marcado como observador no quadro “Tarefas Reportadas”.

Figura 5. Tela do Redmine exibindo as tarefas de um analista.

Tortoise SVN

Após a definição das tarefas, o analista deve ir ao repositório de código-fonte e bloquear as telas que fará modificações para impedir que outras pessoas trabalhem nas mesmas telas, o que geraria perda de trabalho.

Para realizar este controle, a unidade hospitalar definiu a utilização do Tortoise SVN, o qual é um software de controle de versões, revisões e código fonte para Windows. Para sua utilização é necessária a criação de um repositório, onde são armazenados os programas fonte, o qual será gerenciado pelo Tortoise, o qual permite ao desenvolvedor, dentre outras opções (conforme a Figura 6):

· Comparar versões de programas;

· Consultar o log de alterações;

· Renomear programas do repositório;

· Deletar programas do repositório;

· Bloquear programas para que nenhum outro desenvolvedor possa fazer modificações;

· Atualizar o repositório;

· Submeter o programa alterado ao repositório.


Figura 6. Lista de opções do Tortoise SVN

A Figura 7 mostra um exemplo de log de modificações de um programa. Nesta tela é possível consultar o responsável pela alteração, a data em que a modificação foi realizada e a mensagem ou descrição que detalha a alteração. Com este recurso, os desenvolvedores visualizam detalhadamente o histórico do programa, facilitando os trabalhos, além de identificar quem realizou uma modificação indevida, por exemplo.

abrir imagem em nova janela

Figura 7. Log de modificações de um programa

Por fim, a Figura 8 mostra a tela que o analista preenche antes de publicar o programa. Nesta tela é necessário detalhar qual modificação foi realizada. Este texto irá compor o histórico de modificações que fica disponível para os demais analistas.

Um dos pontos fracos do Tortoise é que, para a tecnologia utilizada no hospital, a ferramenta não consegue ler o código fonte para gerar comparação do que foi modificado nas últimas versões. Para linguagens como Java e C, ele fornece tal comparação, o que dá ao desenvolvedor uma melhor visão do que foi modificado, permitindo um controle mais preciso.

Figura 8. Tela de commit de programa

Há inúmeras ferramentas disponíveis no mercado que se dedicam a apoiar o desenvolvimento de sistemas na gestão dos projetos, equipes, orçamentos, horas, código fonte e muito mais. As empresas têm se utilizado destas ferramentas para agilizar e melhor controlar o desenvolvimento de sistemas. É claro que cada empresa utiliza as ferramentas que melhor atende seus objetivos com base na maturidade da instituição e na necessidade do negócio.

A unidade hospitalar analisada, com sua equipe de desenvolvimento de sistemas, definiu que o Tortoise SVN e o Redmine seriam as duas ferramentas necessárias para atender às suas necessidades. Ambas estão em uso na instituição desde 2011 e contribuíram com a melhoria no desenvolvimento das atividades da equipe de TI.

Referências

PRESSMAN, Roger S. Engenharia de Software. 6ed. São Paulo: McGraw Hill, 2006.

PRODAL SAUDE
www.prodalsaude.com.br

REDMINE
http://www.redmine.org

TORTOISE SVN
http://tortoisesvn.net/