Elicitação de Requisitos na DBC Company Jonatan Vianna da Silva Tecnólogo em Sistemas para Internet Centro Universitário Lasalle, - UNILASALLE Canoas, Brasil
[email protected]
Resumo—Este artigo apresenta uma pesquisa de como a elicitação de requisitos, ciclos de vida de software em alguns dos projetos da empresa DBC Company são aplicados. Esta pesquisa se deu através de entrevista realizada com um dos analistas responsáveis pela entrevista de elicitação, documentação e retorno das informações ao cliente. Palavras chave—requisitos; ciclos de vida; software; soluções; desenvolvimento; engenharia
I.
A oportunidade de entrevista surgiu a partir de um contato profissional que se disponibilizou a atender o entrevistador para o questionamento e apoio de informações durante o processo de desenvolvimento do artigo.
INTRODUÇÃO
Este artigo tem como objetivo mostrar como é feito a elicitação de requisitos de software para alguns dos projetos da empresa DBC Company[1]. Além da elicitação de requisitos ainda foram abordados os ciclos de vida de software utilizados e o porquê destas escolhas, também abordo a verificação e validação dos requisitos de software, o desenvolvimento de soluções de software para a própria empresa entrevistada, as tecnologias e ferramentas utilizadas para o desenvolvimento e a entrega das soluções de software. O artigo trata também de um caso em que o processo de software falhou e culminou na entrega de um produto totalmente fora da expectativa do cliente. Finalizando com um estudo de caso em que foram pontuadas as etapas de elicitação de requisitos de software, verificação e validação de requisitos para um determinado cliente. O levantamento de todas as informações se deu através de entrevista com um dos analistas responsáveis pela elicitação dos requisitos, verificação e validação dos mesmos. Além das entrevistas, foram usados trechos de documentos utilizados para validação das informações por parte do cliente, fornecidos pelo entrevistador.
II.
“A DBC oferece um portfólio completo de soluções em tecnologias móveis, preparada para o impacto que os dispositivos trarão, cada vez mais, aos negócios em todos os setores. Atuando no desenvolvimento de novas soluções ou transformando uma solução existente em mobilidade, a DBC tem como premissas a usabilidade, design e performance no desenvolvimento de aplicativos nativos de todas as plataformas líderes de mercado” (www.dbccompany.com.br).
III.
CICLOS DE VIDA DE SOFTWARE
Para que a entrega dos projetos aos clientes seja controlada e eficiente, a empresa se utiliza dos frameworks SCRUM e Kanban como metodologias de gerenciamento dos projetos. O SCRUM é uma metodologia ágil para gestão e planejamento de projetos onde é difícil planeja a frente. O SCRUM se utiliza de o mecanismos de controle de processo empírico onde ciclos de feedback constituem o núcleo da técnica de gerenciamento que são usadas. O SCRUM não define o que deve ser feito em cada situação e sim auxilia no controle de trabalhos complexos nos quais é muito difícil prever o que irá acontecer no futuro do projeto. O SCRUM pode ser adaptável, ou seja, você pode modifica-lo para que se enquadre nas necessidades do projeto, da etapa do projeto ou da filosofia de quem o utiliza a metodologia. Na figura 1 temos uma ilustração de como é todo o processo do SCRUM.
A EMPRESA
A DBC Company é uma empresa com sede em Porto Alegre/RS fundada em 1995. Atuando no ramo de tecnologia da informação, com o foco em prover soluções e serviços em tecnologia da para atender ao mercado corporativo. Na parte de desenvolvimento de sistemas busca sempre novos processos, ferramentas, tecnologias e capacitação da equipe e com isto torna-se cada vez mais estratégica e ágil no desenvolvimento. Tem ainda como definição desenvolvimento de sistemas:
própria
a
cerca
do Fig. 1. Visão geral sobre o SCRUM
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily SCRUM. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. KanBan é uma ferramenta para acompanhar visualmente o desenvolvimento de sistema, podendo se adaptar ao processo ou a etapa do mesmo. Foi desenvolvido pela Toyota como uma ferramenta para controlar perdas e retrabalho na linha de produção automotiva. O objetivo do Kanban é evitar o trabalho dobrado ou desnecessário que é feito atravéz da visualização do status do projeto e de cada atividade em um quadro, o chamado Kanban Board. Muito importante ressaltar que o KanBan Não define o projeto do desenvolvimento do sistema mas se adapta ao que está sendo utilizado, no caso o SCRUM. O KanBan board é dividido em swimlanes (raias) cada swimlane representa uma etapa do processo, e mais duas swimlanes adicionais, uma de backlog e uma para finalizados. A swimlane de backlog é para as etapas que não foram iniciadas ainda e finalizadas como o nome já diz são para etapas que já passaram por todas as etapas que já foram finalizadas. O Kanban board permite visualizar em que etapa cada atividade está, proporcionando uma visão macro do projeto e assim dando a possibilidade de verificar se há etapas mais adiantadas, ou etapas em atraso, em que fase está o projeto[8].
IV.
DINÂMICA DE ELICITAÇÃO DE REQUISITOS
A Elicitação de requisitos é a atividade que visa extrair e levantar as informações necessárias para o desenvolvimento de um sistema de software, para Sommerville, Ian (2007), requisitos de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais [2]. Neste artigo a empresa em questão utilizou em um determinado caso, a técnica de entrevista com os stakeholders e o acompanhamento de operação do que está sendo elicitado. A entrevista inicialmente é feita com um gestor da área em que respondeu uma série de questionamentos a cerca de como o sistema deveria se comportar enquanto o operador estivesse usando o sistema. Num segundo momento é feito um acompanhamento ao operador, que mostra como é feito o processo que está sendo elicitado. Tendo finalizado as etapas de levantamento é retornado ao cliente, o documento de requisitos. Neste documento de requisitos é que são detalhados todos cenários elicitados, o que cada menu e opção do sistema fará e como será o layout de cada tela. O Detalhamento dos cenários e feitos através de descrição textual em sequência de ações realizadas, informando cada passo realizado pelo fluxo do cenário, além de imagens estáticas da posição de cada menu na tela e o layout de cada opção do menu. Antes de o documento de requisitos ser definitivo, há ainda a análise de tudo que foi elicitado, todos os menus, telas e ações. A aprovação do cliente é concretizada através do documento de requisitos impresso e assinado para comprovação de aceite. Posteriormente segue para a equipe de desenvolvedores.
V. SOLUÇÕES PROPRIAS DE SOFTWARE A empresa em questão, DBC Company por se tratar de uma empresa que atua no mercado de desenvolvimento de sistemas, realiza o desenvolvimento de seus próprios produtos de software para utilização dos funcionários e gestores, não sendo necessário contratar serviço do mercado para o desenvolvimento de sistemas.
VI.
TECNOLOGIAS UTILIZADAS
As tecnologias utilizadas atualmente são ASP .NET MVC, SGBD SQLServer e Framework NHibernate. Essas tecnologias podem variar de acordo com o escopo do projeto, necessidades do cliente e particularidades do sistema. A. ASP .NET MVC Desenvolvida pela Microsoft e baseado em ASP .NET, esta tecnologia está voltada para o desenvolvimento de aplicações para web utilizando o framework MVC (Modeling View Controller) como padrão [4][6]. Fig. 2. Modelo do Kanban Board
B. SGBD SQL Server É um sistema de gerenciamento de base de dados relacional desenvolvida pela Microsoft. A linguagem utilizada para as operações de bancos, tabelas, queries e etc. utilizam a linguagem SQL como padrão. É um SGBD utilizado em larga escala no mercado, atendendo diversas demandas e diferentes níveis de exigência, desde um banco de dados pequeno até um banco de dados de grande escala e alta demanda [5].
suas disposições numa tela apenas. Esta tela será utilizada pelo usuário durante as visitas de fiscalização.
C. Framework NHibernate É um framework que fornece o mapeamento do modelo relacional para a orientação a objeto. É utilizado para persistência de dados e de subjacentes de dados relacionais, gerando automaticamente códigos SQL para carregar e salvar objetos num banco de dados [3].
VII. ESTUDO DE CASO Como estudo de caso será usado um exemplo que foi utilizado durante a entrevista com o analista responsável pela elicitação dos requisitos, um módulo do sistema do Conselho Regional de Engenharia e Arquitetura CREA utilizada no para fiscalização de Obras. O analista realizou a elicitação dos requisitos com um o cliente que no caso era um Engenheiro responsável pela fiscalização de obras de engenharia civil. O papel deste usuário era visitar a obra e verificar por irregularidades durante a visita. Irregularidades de segurança, procedimentos prazos, documentações e etc. Na visita ele utiliza como base, a legislação vigente para notificar, caso seja encontrada irregularidade, os responsáveis pelo andamento da obra. Este recurso de fiscalização está disponível online para o fiscalizador, podendo ser acessado através de um navegador em qualquer dispositivo que tenha acesso a internet. Tendo encontrado alguma irregularidade ele notifica através da utilização deste módulo do sistema que é o modulo de notificações de irregularidades e geração de multas. Este módulo tem os dados do cliente cadastrados, obra cadastrada e tem uma base das irregularidades que podem ser encontradas numa determinada obra, para cada irregularidade se seleciona uma determinada opção que informa qual regra está sendo infligido, preço da multa e prazo para pagamento, ficando registrado no banco de dados da instituição. Posteriormente, o agente que faz a fiscalização pode consultar se houve o pagamento da multa, se o prazo para regularização foi respeitado e pode consultar todo o histórico do cliente no que diz respeito a notificações de obra e pagamento de multas. Durante uma nova visita é possível ter como base o histórico da obra se há alguma irregularidade que ainda não foi resolvida, além de poder fiscalizar novos itens na obra. Como exemplo, na figura 3, apresento parte da tela da prototipação que foi gerada durante a validação dos requisitos junto ao cliente. Esta tela mostra como serão todos os menus e
Fig. 3. Parcial da tela do protótipo fiscalização e notificação
VIII. VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS DE SOFTWARE
O estudo de viabilidade é feito antes da entrevista de levantamento de requisitos, uma conversa com o cliente é registada e através dela se elabora um ponto de partida para os requisitos do sistema. O estudo é completado no momento da entrevista com o cliente e é aprofundado à medida que os requisitos são levantados. Para a verificação e validação de requisitos é feita uma filtragem inicial durante a entrevista, o analista questiona todos os aspectos dos requisitos funcionais ao cliente e tem total autonomia para validar determinados requisitos são possíveis ou não durante a entrevista. Requisitos que não podem ser validados e verificados durante a entrevista são registrados no documento de requisitos e analisados posteriormente levando em consideração validade, consistência, completeza e realismo para que não estejam fora do que o cliente e que não haja conflitos entre os requisitos. O que não pode ser verificado e validade pelo analista é encaminhada aos gerentes de projeto. Portanto a validação dos requisitos elicitados se dá de duas maneiras, durante a entrevista e pelo gerente de projeto.
A. Durante a entrevista Num primeiro momento o entrevistador analisa as necessidades e desejos do entrevistado e filtra o que pode ser inviável durante a entrevista. Posteriormente analista para que não hajam conflitos e que estejam de acordo com o escopo do projeto e necessidades do cliente. B. Gerente de Projeto Recebe do entrevistador os requisitos aos quais não puderam ser verificados e validados durante a entrevista, este analisa e retorna ao entrevistador suas definições a cerca dos requisitos validados ou não. Depois de finalizadas as analises é retornado ao cliente para analise e consentimento. Esta etapa é muito importante porque os erros em um documento de requisitos podem levar a custos excessivos de retrabalho quando são descobertos durante o desenvolvimento ou depois que o sistema estará em operação [2]. Ilustração do processo de engenharia de requisitos [2].
porém não se utilizou da verificação nem validação dos requisitos com o cliente. Tendo repassado o documento de requisitos ao programador, o mesmo realizou o desenvolvimento do sistema sem entregar etapas caso em que o "analista" fez o levantamento e depois não validou com o cliente nem mostrando um protótipo do sistema nem realizando a entrega em etapas o que poderia ter evitado um problema maior que foi que na entrega do sistema, o que foi apresentado não tinha nada ou muito pouco do que o cliente estava necessitando. Facilmente detectado um problema na elicitação dos requisitos, que não foram validados, verificados e confirmados pelo cliente tendo que refazer todo o sistema o que gerou um custo de no mínimo o dobro e que poderia ter sido facilmente resolvido ou detectado se os requisitos tivessem sido validados. XI.
CONCLUSÃO
Podemos concluir que atualmente a metodologia de desenvolvimentos ágeis é um padrão amplamente utilizado no mercado de desenvolvimento de sistemas, e que a constante verificação dos passos já concluídos ajuda no entendimento de como está todo o processo do projeto em relação ao que o cliente deseja. Concluímos também que não há um processo de software melhor que o outro, mas sim que um entendimento dos paradigmas de software podem ajudar a decidir qual metodologia se enquadra melhor em cada projeto a ser realizado. XII. AGRADECIMENTOS
Fig. 4. Processo de engenharia de requisitos
IX.
PROCESSO DE MANUTENÇÃO DE SOFTWARE
O processo de manutenção é muito parecido ou praticamente o mesmo da elicitação inicial dos requisitos. Fazse um novo levantamento de requisito focado na manutenção do sistema. É gerada uma nova documentação de requisitos apenas para a manutenção e não é utiliza a documentação que foi usada para a elicitação e validação inicial, pois a empresa entende se tratar de um processo a parte do inicial. O processo de manutenção não atinge a documentação inicial, portanto não há versionamento ou atualização da documentação, cria-se uma nova. X.
EXEMPLO DE FRACASSO EM UM PROJETO
Houve uma situação em que o analista fez a elicitação através de metodologia de entrevista com os stakeholders,
Agradeço ao meu amigo e compadre Maico Daltoé, que prontamente atendeu a minha solicitação para repassar todas as informações sobra a sua função como analista de requisitos. Programador e analista de requisitos na DBC Company, tem 9 anos de experiência na área de desenvolvimento de sistemas e programação utilizado .NET, já trabalhou em empresas e projetos importantes no ramo de desenvolvimento de sistemas.
[1] [2]
[3] [4] [5] [6] [7]
www.dbccompany.com.br em 11/11/2014 – 23:00 Sommerville, Ian “Engenharia de software, 8ª edição / Ian Sommerville; tradução: Selma Shin Simizu Mlnikoff, reginaldo Arakaki, Edílson de Andrade Barbosa; revisão técnica: Keci Kirama. -- 8ª ed -- . São Paulo : Pearson Addison-Wesley, 2007. http://pt.wikipedia.org/wiki/NHibernate em 11/11/2014 http://www.asp.net/mvc http://en.wikipedia.org/wiki/Microsoft_SQL_Server http://en.wikipedia.org/wiki/ASP.NET_MVC_Framework http://pt.wikipedia.org/wiki/Scrum http://www.infonaveia.com.br/desenvolvimento/desenvolvimento-agilkanban/
