ARTIGO ORIGINAL
PERES, Paulo Júnior de Jesus [1]
PERES, Paulo Júnior de Jesus. Caso de uso: criando uma metodologia de desenvolvimento de software ágil na administração pública federal. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano 04, Ed. 03, Vol. 09, pp. 97-103. Março de 2019. ISSN: 2448-0959.
RESUMO
Criar sistemas complexos e interconectados dentro de uma instituição pública ou privada sempre é um grande desafio, haja visto que a engenharia de um software uma ciência que diverge muito da construção civil devido as diversas variáveis que nem sempre podem ser medidas com exatidão. Por isso, é necessário de forma clara estabelecer metas, documentos, métodos de trabalho de forma que a equipe que trabalha no desenvolvimento não se perca em meio a tantas formas disponíveis no mercado. Tendo em vista esse prisma, este artigo busca descrever a forma em que a Superintendência da Zona Franca de Manaus (Suframa) criou a sua metodologia de desenvolvimento de Sistemas MDS baseada em padrões ágeis. Tal medida buscou agilizar processos, economia de documentações “desnecessária” e foco no resultado que é a entrega do software rodando em produção refletindo no uso dos clientes.
Palavras-chave: PDTI, planejamento, planejamento de TI.
1. INTRODUÇÃO
No contexto atual, com o avanço da tecnologia da informação no que tange o uso dos sistemas de informação como forma de agilizar os processos de trabalho, comunicação, integração e serviços no setor público e privado; é cada vez mais necessária a construção de sistemas especializados livres de falhas e personalizados a regra de trabalho de cada instituição.
Dentro deste prisma, é necessário que os softwares sejam criados dentro de diretrizes pré-estabelecidas pelas empresas com o fim de padronizar e otimizar o processo de desenvolvimento. Tal diretriz é chamada de Metodologia de Desenvolvimento de Softwares.
Buscando atingir esse objetivo, a Coordenação-Geral de Modernização e Informática da Superintendência da Zona Franca de Manaus (Suframa) desenvolveu tal documento focado nas práticas Ágeis, destarte o objetivo deste artigo é abordar a forma como foi feita tal produção.
Segundo o sitio eletrônico da Instituição, a Suframa – é uma autarquia do governo Federal vinculada ao Ministério da Economia que tem como objetivo construir um modelo de desenvolvimento regional que utilize de forma sustentável os recursos naturais garantindo a viabilidade econômica e melhorando a qualidade de vida da população. Atualmente a Suframa tem como abrangência os Estados do Amazonas, Acre, Rondônia, Roraima e Amapá.
Nos próximos capítulos serão abordadas de forma prática como se deu a criação da Metodologia de Desenvolvimento de Software (MDS) da Suframa.
2. QUAL CAMINHO A SEGUIR
Tendo em vista a necessidade da criação da MDS, realizou-se um estudo sobre quais seriam as diretrizes utilizadas para a elaboração da metodologia. Levou-se em consideração que a metodologia utilizada a época pela autarquia era baseada no Rational Unified Process (RUP), por isso, trazia consigo uma gama enorme de documentos que deveriam ser criados a fim de comporem a entrega de um produto de software. Diante disso, por decisão dos gestores a MDS deveria ser baseada em métodos de desenvolvimento ágil.
Neste giro, há que se entender que as metodologias ágeis de desenvolvimento de software se propõem a construir software com maior produtividade e, sobretudo, com qualidade garantida. Para isso elas encaram os projetos sobre um novo paradigma e defendem a adoção de uma série de princípios e práticas (Tavares, 2008)
Nesse panorama de desenvolvimento ágil, destaca-se o Scrum, que possui uma abordagem enxuta de desenvolvimento de produtos. Ele é um processo ágil de desenvolvimento de produto ou administração de qualquer trabalho iterativo e incremental e poder ser aplicado ao desenvolvimento de produtos de maneira geral (RISING,2000). Apesar de ser uma abordagem relativamente nova, a utilização do Scrum tem aumentado bastante nos últimos anos, impulsionados pelas recentes pesquisas que mostram que seu uso aumenta a satisfação dos clientes e diminui o atraso em projetos em relação aos métodos tradicionais (MAURER, 2005).
Por isso, embasados em tais conceitos, o órgão optou por desenvolver sua metodologia baseada no Scrum.
3. A METODOLOGIA
Não foi objetivo da Metodologia de Software (MDS) exaurir o funcionamento da Metodologia Ágil ou do Ciclo PDCA (planejar, fazer, checar e agir) mas sim assegurar um conjunto de artefatos imprescindíveis à execução dos projetos de desenvolvimento de Software da Superintendência da Zona Franca de Manaus (SUFRAMA) garantido a qualidade, produtividade e segurança do processo bem como definir que será adotada uma metodologia Ágil para o desenvolvimento de sistemas.
No caso de ser realizada uma subcontratação dos serviços de desenvolvimento e manutenção dos sistemas a MDS servirá de guia para os serviços do terceiro e também se aplicará às atividades realizadas pelos analistas concursados do órgão e a todos os produtos gerados pela empresa contratada.
4. ESCOPO
Após diversas reuniões realizadas entre os analistas de Tecnologia da Informação concursados o órgão chegou à conclusão de que a MDS teria como escopo o processo de desenvolvimento de novos sistemas, manutenção corretiva e evolução dos softwares já existentes.
Diante disso, a metodologia ficou dividida em tais pontos:
a) Projeto de Desenvolvimento – Criação de novos sistemas;
b) Projeto de Melhoria – Evolução de Sistemas, criação de consultas e relatórios;
c) Manutenção Corretiva – Manutenção de erros específicos ocorridos em produção de sistemas devidamente documentados;
d) Solicitação de Informação – Solicitação de informações sobre o ambiente de desenvolvimento ou software e situações correlatas;
e) Manutenção de Documentação de Sistemas Legados – Documentação de Sistemas com falta ou documentação insuficiente para o trabalho.
5. FASES DO PROCESSO
Para a realização de Projetos de Desenvolvimento, Projeto de Melhoria, Manutenção Corretiva e Manutenção de Documentação de Sistemas Legados serão consideradas as seguintes fases:
a) Planejamento;
b) Desenvolvimento;
c) Conclusão;
5.1 PLANEJAMENTO
A fase de planejamento inicializa-se com a formalização de uma demanda por parte do cliente (usuário do sistema) que será analisada e aprovada pela área de informática. Tal demanda após aprovada será transformada em uma Ordem de Serviço (OS) que será encaminhada ao analista de negócios que deverá abstrair os requisitos e/ou alterações a serem desenvolvidas.
Para tanto, serão necessárias reuniões com os clientes objetivando o entendimento da demanda. Nesta fase o principal artefato de saída será o Resumo Executivo.
5.2 DESENVOLVIMENTO
Esta faze é dividida em outras duas subfases que são:
a) Elaboração;
b) Construção.
As fases de elaboração e construção deverão ocorrer em períodos de máximo três semanas e ao final do ciclo, uma entrega deverá ser feita e validada pelos analistas de negócio envolvidos no projeto.
A fase de elaboração, ou Sprint zero, deverá ocorrer posteriormente ao aceite do Resumo Executivo elaborado na fase de inicialização. Cada requisito deverá possuir um Sprint zero onde serão planejadas a quantidade de Sprint’s necessárias para desenvolver o requisito bem como acordado o produto que será entregue ao final de cada Sprint.
Ao final de cada Sprint deverão ser entregues os protótipos, regras de negócio e quando aplicável, o Modelo de Entidade Relacionamento (MER) sendo que todos estes artefatos devem ter sido validados pelos analistas da autarquia.
Na fase de construção, serão abordados os Sprint’s planejados na fase anterior bem como suas entregas. As entregas dessa fase, entre outros documentos, devem ser, obrigatoriamente o MER atualizado, Código Fonte, Manual do Sistema, Relatório de Testes, Termo de Recebimento e Termo de Aceite.
Um novo release do projeto será gerado quando um requisito for entregue e validado pelo analista da Suframa.
5.3 CONCLUSÃO
A fase de conclusão destina-se a contagem dos pontos por função e faturamento. Segue a ilustração, lembrando que os Sprints terão duração de no máximo 3 semanas e reuniões diárias para controle das atividades realizadas.
6. ARTEFATOS
No caso do Desenvolvimento e Melhoria dos sistemas, serão exigidos os seguintes artefatos mínimos conforme tabela abaixo:
| RELAÇÃO DE ARTEFATOS | ||
| Serviço | Entregáveis obrigatórios | Fase |
| Desenvolvimento e Melhoria de Sistemas | Resumo Executivo | Planejamento |
| Documento de Análise e Projeto (MER, Regras de Negócio, Protótipo, Análise de Riscos, Critérios de aceitação e Termos de Aceitação. | Desenvolvimento | |
| Código Fonte (Documentado por método, classe, arquivo, pacote, etc.) | ||
| Código Compilado e/ou executável | ||
| Relatório de Testes (Unitário e Aceitação) | ||
| Planilha de contagem detalhada | ||
| Manual do Usuário (modo online) | ||
| Manual do Sistema | ||
| Termo de Encerramento | Encerramento | |
| Manutenção Corretiva | Código Fonte (Documentado por método, classe, arquivo, pacote, etc.) | Desenvolvimento |
| Código Compilado e/ou executável | ||
| Relatório de Testes (Unitário e Aceitação) | ||
| Solicitação de Informações | Relatório de Informações Técnicas como por exemplo: laudos, análises, apuração de procedimentos e etc. | Qualquer momento |
| Manutenção de Documentação de Sistemas Legados | Documento de Análise e Projeto (MER, Regras de Negócio, Análise de Riscos, Documento de Arquitetura e Termos de Aceitação. | Planejamento |
| Planilha de contagem detalhada | ||
| Relatório de Testes | ||
| Termo de Encerramento | Encerramento | |
Tabela 01: Tabela de Artefatos. Fonte: Suframa
É importante esclarecer que a Critério da Suframa, poderá ser solicitado algum outro artefato com base na necessidade do projeto, contudo o prazo e o modelo do relatório deverão ser acordados entre as partes conforme a criticidade de tal artefato.
7. PRINCIPAIS PAPÉIS
Os papéis principais do processo estão relacionados aos atores diretos do processo, ou seja, à área de TI, à área de negócio (requisitante) e ao fornecedor externo contratado. Abaixo apresenta-se uma descrição sintética desses papéis:
a) Analista de negócio: representa a área requisitante do produto (área de negócio ou dono do produto) e os stakeholders (envolvidos), centra sua atuação nos itens relacionados ao cliente (históricas de usuário) garantindo que a solução agregue valor ao negócio. Prioriza funcionalidades, ajusta funcionalidade e prioridades, aceita ou rejeita o resultado dos trabalhos.
b) Equipe de Desenvolvimento: é a equipe responsável pela entrega do produto, composta pelas pessoas que executam o trabalho real (analisar, projetar, desenvolver, testar, documentar, etc.).
c) Suframa: entidade governamental que utiliza sistemas de informação para cumprimento de seus objetivos institucionais e negociais; proprietária do processo atua como contratante e demanda atividades de gestão de serviços de TI.
d) Fábrica de Softwares: entidade responsável pela prestação dos serviços de desenvolvimento e manutenção de sistemas; atua como prestador externo de serviços contratado através de procedimento licitatório.
8. MAPEAMENTO DO PROCESSO DE DESENVOLVIMENTO
Conforme figura 02, onde foi utilizado o Mapeamento do processo baseado no BPMN, pode-se observar o seguinte:
- O processo inicia-se com a criação da ordem de serviço;
- O analista de TI do órgão analisa a demanda;
- A empresa terceirizada de desenvolvimento de software analisa a ordem de serviço;
- A área de TI analisa os documentos gerados pela terceirizada para deliberar se é viável tal ordem de serviços;
- Se autorizado, a empresa terceirizada executa a ordem de serviço;
- Após a conclusão a área de TI avalia o produto entre e se aprovado, encaminha para publicação no ambiente de produção.
9. CONCLUSÃO
O objetivo deste artigo, foi descrever a metodologia de desenvolvimento de software criada dentro da Superintendência da Zona Franca de Manaus (Suframa) para atender suas necessidades.
É importante esclarecer que tal metodologia está em pleno uso pelo órgão a época da publicação deste artigo.
Quanto ao embasamento legal, tal metodologia obedeceu às legislações vigentes e as instruções normativas do Governo Federal, cito IN 04/2014.
Assim, este artigo serve como modelo de partida para empresas públicas ou privadas que pretendam criar uma metodologia de desenvolvimento de software. É claro que assim como a tecnologia de criação de softwares evolui constantemente essa MDS sofrerá constantes evoluções a fim de atender o dinamismo do processo de criação de softwares da autarquia.
REFERÊNCIAS
HIGHSMITH, J. Agile Project Management, Creating innocative products. Addison Wesley, 2004.
KOSCIANSKI, A. Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2ª ed. São Paulo: Novatec Editora, 2007.
Mann, C. & Maurer, F. A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction. Agile Development Conference, p. 70-79. IEEE Cumputer Society, 2005.
RISING, L.; Janoff, N.The Scrum software development process for small teams. 2008, In IEEE, v. 17, nº 4, p. 26-32.
TAVARES, A. Gerência de Projetos com PMBOK e SCRUM – Um estudo de caso. Faculdade Cenecista Senhora dos Anjos. Gravataí – RS, 2008.
TURNER, Richard. JAIN, Apurva. Agile Meets CMMI: Culture clash or common cause. XP/Agile Universe. 2002, p.153-165.
[1] Pós-Graduado em Banco de Dados, Bacharel em Sistemas de Informação, Analista Técnico Administrativo – Tecnologia da Informação.
Enviado: Janeiro, 2019.
Aprovado: Março, 2019.
