ANÁLISE DO BENEFÍCIO DA ABORDAGEM DDD NA DIMINUIÇÃO DE FALHAS DE COMUNICAÇÃO NO DESENVOLVIMENTO DE PROJETOS DE SOFTWARE

1. RESUMO

Esta monografia apresenta a análise dos benefícios da linguagem onipresente que é um dos fundamentos da abordagem DDD (Domain-Driven Design) e seu peso na diminuição de fracassos de projetos de desenvolvimento de software. Dadas as dificuldades enfrentadas por estudantes e desenvolvedores inseridos no mercado de trabalho na compreensão e entendimento de requisitos para o desenvolvimento de software, verificou-se a necessidade da produção desse documento. Em sua produção, foram aplicados os padrões estabelecidos pela ABNT (Associação Brasileira de Normas Técnicas), juntamente com as principais recomendações sobre benefícios da linguagem onipresente na comunicação dentro de projetos de desenvolvimento de software, sendo utilizadas citações e exemplos do próprio criador da abordagem. O formato de análise em casos reais foi escolhido com o objetivo de facilitar a compreensão do material proposto. Com este documento, é esperado que alunos e desenvolvedores sejam capazes de compreender os benefícios da linguagem onipresente da abordagem DDD, em projetos reais de desenvolvimento de um software, pois a maneira de escrita foi a mais clara e concisa possível, e o leitor pode se basear neste documento para outros trabalhos, pois o mesmo gera reflexões, dada a complexidade do assunto, despertando a busca pela desmistificação de uma boa modelagem de comunicação em projetos de desenvolvimento de software, contribuindo assim para a comunidade acadêmica.

Palavras-chave: DDD; Domain-Driven Design; Comunicação; Software.

ABSTRACT

This monograph presents the analysis of the benefits of the ubiquitous language, which is one of the foundations of the Domain-Driven Design (DDD) approach and its weight in reducing the failures of software development projects. Given the difficulties faced by students and developers in the labor market in understanding and understanding requirements for software development, it was verified the need to produce this document. In its production, the standards established by ABNT (Brazilian Association of Technical Standards) were applied, together with the main recommendations on the benefits of the ubiquitous language in communication within software development projects, using citations and examples from the originator of the approach. The format of analysis in real cases was chosen with the purpose of facilitating the understanding of the proposed material. With this document, it is expected that students and developers will be able to understand the benefits of the ubiquitous language of the DDD approach in real software development projects, as the way of writing was as clear and concise as possible, and the reader can based on this document for other works, because it generates reflections, given the complexity of the subject, awakening the search for the demystification of a good modeling of communication in software development projects, thus contributing to the academic community..

Key-words: DDD; Domain-Driven Design; Communication; Software.

2. INTRODUÇÃO

Com o crescimento tecnológico imenso no século XXI, houve uma grande informatização de empresas, o setor de TI (Tecnologia da Informação) foi um dos que mais cresceram de forma global desde os anos 2000, devido à grande revolução digital que a informática e a comunicação proporcionaram na economia, nas empresas e na vida da população em geral.

E esse crescimento tecnológico trouxe facilidades no mundo empresarial, já que o número de ferramentas para melhoria e gestão de processos e pessoas também cresceu, expandindo assim, a demanda de projetos de desenvolvimento de software e atualmente, têm sido necessárias as interfaces interdisciplinares, que conectam pessoas que dominam um determinado assunto, e os desenvolvedores de software.

Essa monografia tem por base, as estatísticas do PMI (Project Management Institute Brasil) que, em 2010 mostraram um déficit no desenvolvimento e na continuidade de projetos, onde para 76% das empresas o principal motivo para seus projetos fracassarem são falhas na comunicação. Esse problema ocorre entre detentores de conhecimento a qual o software se aplica e desenvolvedores de software, pois a equipe de desenvolvimento não encontra maneiras, e/ou preparo para explicação aos que detém o conhecimento. E por outro lado, os especialistas do conhecimento, não sabem como repassá-lo. Logo, os projetos fracassam com tais comportamentos, pois não há harmonia entre as equipes. Com esse cenário, como é possível entender o fracasso em projetos de desenvolvimento de software, bem como apontar as possíveis melhorias na comunicação através da linguagem onipresente da abordagem DDD?

Dada a questão do parágrafo anterior, o objetivo que a responde é: apontar, pela literatura, a importância da comunicação e seus pesos nos fracassos de projetos de desenvolvimento de software, bem como explorar maneiras de organizar a comunicação através da linguagem onipresente da abordagem DDD, trazendo a harmonia nas interfaces entre equipes. Que será destilado em três blocos: analisar e apontar historicamente a importância da comunicação na execução de projetos de desenvolvimento de software; estudar e compreender a linguagem onipresente da abordagem DDD; e explorar as possíveis melhorias na união dos conceitos de linguagem onipresente e comunicação, para a diminuição do fracasso em projetos de desenvolvimento de software.

Nessa monografia, o tipo de pesquisa realizado foi revisão de literatura, no qual foram realizadas consultas em livros, dissertações e artigos científicos selecionados através de busca em livros e sites da web. O período dos artigos pesquisados foram os trabalhos publicados nos últimos 17 anos. As palavras-chave utilizadas na busca foram: “ddd”, “domain-driven design”, “comunicação” e “gestão de projetos”.

A metodologia desse trabalho tem como principal motivo a revisão da literatura, uma pesquisa quantitativa e descritiva. Uma pesquisa descritiva, utilizada para descrever o impacto das falhas de comunicação nos projetos de desenvolvimento de software, assunto que vem evoluindo cada vez mais. Foram utilizadas as pesquisas bibliográficas e documentais para o levantamento e análise de dados. Foram utilizados os autores Molena A. para a conceituação da comunicação na gestão de projetos; Eric Evans para conceituação da linguagem onipresente dentro do DDD; e diversos outros autores para fundamentar os argumentos aqui descritos. Foram utilizados trabalhos publicados nos últimos 17 anos, livros de autores renomados na área acadêmica e sites na área de tecnologia e documentos publicados.

Palavras chaves: DDD, Domain-Driven Design, comunicação em projetos e gestão de projetos de software.

3. A IMPORTÂNCIA DA COMUNICAÇÃO

Ao abordar a importância da comunicação serão apresentados os conceitos e dados estatísticos do PMI (Project Management Institute), que é uma associação não governamental, sem fins lucrativos, que lidera o desenvolvimento da disciplina “Gerenciamento de Projetos” no mundo, possuindo atualmente cerca de 700 mil membros filiados¹.

3.1. COMUNICAÇÃO

Comunicação, no dicionário, é uma palavra derivada do latim “communicare”, cujos sinônimos são: ‘tornar comum’, ‘partilhar’, ‘repartir’, ‘associar’, ‘trocar opiniões’, ‘conferenciar’. Molena (2009) afirma que, comunicar implica na participação, na interação, na troca de mensagens ou na emissão ou recebimento de informações novas.

É também vista como uma troca de experiências socialmente significativas ou um esforço para a convergência de perspectivas. A reciprocidade de pontos de vista implica dessa forma, em certo grau de ação conjugada ou cooperação. (RABAÇA & BARBOSA, 2001. p. 155). Pereira (2007) afirma que o ato de comunicar (algo) ou de comunicar-se (com alguém)”, torna alguma coisa comum a ambos. Quando se publica uma notícia ela passa a fazer parte da comunidade. Comunicação, comunhão, comunidade, etc. são palavras que têm a mesma raiz e estão relacionadas à mesma ideia de algo compartilhado. A comunicação não deve ser vista apenas como uma transição de mensagens. Exige a construção de um relacionamento interpessoal e o mais importante, é de suma importância que tanto o emissor, quanto o receptor queiram se comunicar.

De acordo com Molena (2009), a comunicação é um dos principais problemas que ocorrem com mais frequência na Gestão de Projetos. Essa realidade já vem sendo estudada, e apontada, em outras pesquisas da PMI. Há dados de muitos anos, mas foram reunidas as pesquisas de 2010 nessa monografia. Na tabela 1 é possível analisar os dados coletados pelo PMI, em 2010, onde há casos de falhas advindas da comunicação, direta e indiretamente, onde o texto está realçado.

Tabela 1 - Problemas que ocorrem com mais frequência na Gestão de Projetos

Fonte: <http://www.mp.go.gov.br/portalweb/hp/33/docs/benchmarking_gp_2010_geral.pdf> Acesso em: 19 out. 2018. p. 116.

A partir desse relatório do PMI, é possível a constatação de que problemas de comunicação diretos ultrapassam 40% dos motivos de fracasso de desenvolvimento de projetos e a soma da porcentagem de motivos indiretos advindos da comunicação também são bem altos, já que as mudanças de escopo constantes somam 43%, escopos não definidos adequadamente somam 39,5%, mudanças de prioridade constantes ou falta de prioridade somam 19,8% e a falta de conhecimento técnico sobre a área de negócio da organização somam 2,1%. E esses problemas de comunicação devem ser observados com mais atenção, pelos gerentes de projetos, onde é necessária uma melhor atenção à comunicação, bem como definir e mostrar para os funcionários, a importância da comunicação na empresa e no projeto.

É válido apontar também que para as empresas, a habilidade de comunicação é a segunda mais importante em uma escala feita pelo PMI, na Tabela 2 é possível analisar.

Tabela 2 – Habilidades mais valorizadas pelas organizações no gerenciamento de projetos

Fonte: <http://www.mp.go.gov.br/portalweb/hp/33/docs/benchmarking_gp_2010_geral.pdf> Acesso em: 19 out. 2018. p. 107.

Partindo da análise da Tabela 2, é possível verificar que o conhecimento de gerenciamento de projetos está na 4ª posição. E as habilidades de comunicação diretas e indiretas são muito relevantes. Para Heldman Klin (2005. p. 38), 90% do trabalho do Gerente de Projetos é comunicação.

3.2. PRINCIPAIS MOTIVOS DE FALHAS NA COMUNICAÇÃO

Um dos principais motivos abordados nessa monografia, é a falha no entendimento no fator semântico, que de acordo com Molena (2009), esse fator está ligado ao uso da linguagem adequada para o grupo. Todos entendem da mesma forma o conteúdo e a forma da mensagem? O conjunto de código para se comunicar é de fácil acesso para todos.

Unindo ao tema da monografia, Molena (2009) completa afirmando que, um grupo de advogados terá uma dificuldade para se comunicar com especialistas de TI, por exemplo. Aqui também podemos ver as diferenças da língua portuguesa. Apesar de no Brasil falarmos somente uma língua, temos variações entre regiões, cidades, e até mesmo bairros com muitas influências de colonização de imigrantes diferentes. Há também a preocupação quanto a grupos culturais ou etários. Não é necessário dizer que os jovens de hoje têm uma linguagem com códigos diferentes até mesmo dos adultos, sem precisar falar dos mais velhos.

Com esse cenário de problemas de entendimento na comunicação, o desenvolvimento de projetos se torna difícil, pois sempre há a dificuldade de passar a informação quando há a necessidade.

Drucker (2007, p.200) afirma que, a comunicação sempre exige de quem a está recebendo a fazer ou acreditar em algo. A comunicação sempre atrai motivação, atrai ajustes de valores, ou atrai propósitos. Se a comunicação for contra as aspirações, contra os valores ou contra as motivações de quem a recebe, é provável que o receptor não deseje receber ou esteja resistivo à informação.

Para completar, Molena (2009), afirma ainda que, ao se gerenciar um projeto, as relações humanas devem ser trabalhadas no contexto da comunicação. A troca de informações entre as partes envolvidas ou interessadas no projeto, com todas as suas aspirações e necessidades, deve ser identificada para que ocorra uma harmonia na fase de execução do projeto.

Em uma pesquisa realizada por Carvalho & Mirandola (2007), foram constatadas algumas barreiras na comunicação na área de TI entre detentores de conhecimento e desenvolvedores de software, a estatística é apontada na Tabela 3.

Tabela 3 – Principais barreiras na comunicação entre desenvolvedores e detentores de conhecimento

Fonte: Carvalho & Mirandola (2007, p.11, adaptado).

Nessa mesma pesquisa de Carvalho & Mirandola (2007), alguns comentários ainda foram incluídos, onde duas pessoas foram entrevistadas: um analista de sistemas e um gerente de negócios. Um analista de sistemas diz: “É difícil explicar para os donos do processo, que são da área de negócios, o que é possível fazer com a tecnologia disponível, pois eles às vezes pedem coisas impossíveis”. Já o gerente de negócios afirma: “Nós da área de negócio estamos conectados às demandas do cliente, mas o pessoal de sistemas coloca dificuldades intransponíveis e se esconde atrás de um linguajar técnico, o que dificulta uma negociação e a solução do problema”.

Esse “linguajar técnico” mencionado pelo gerente de negócios, justifica a necessidade dessa monografia ser aprofundada, pois mostra em ambientes reais que realmente há uma deficiência na comunicação em projetos de desenvolvimento de software, fortalecendo o alto índice de fracassos.

4. DOMAIN-DRIVEN DESIGN

Após o levantamento da importância da comunicação, bem como seus conceitos e principais motivos de falha, essa monografia propõe a análise da Linguagem Onipresente para auxílio no aprimoramento da comunicação dentro de um projeto de desenvolvimento de software. E para facilitar a compreensão do conceito de linguagem onipresente, serão abordados os conceitos de DDD, Projeto, Software e Comunicação.

Domain-Driven Design, ou DDD, é uma abordagem de desenvolvimento de software, que foi formulada e apresentada em um livro lançado entre 2003 e 2004, por Eric Evans. No livro, o DDD une fundamentos de boas práticas de programação e de organização de projetos. Trabalha muito na comunicação entre equipes e utiliza a programação orientada a objetos no desenvolvimento de modelos abstratos que representem o domínio do negócio a qual o software se aplica da forma mais próxima possível que ele é no mundo real.

O nome DDD faz menção a palavra domínio, que nesse contexto pode ser entendida como uma como uma palavra chave de valor ao negócio a qual o software em desenvolvimento se aplica, envolvendo regras e processos do negócio. No DDD a comunicação é um dos conceitos mais importantes, já que só é possível criar um domínio rico, através da destilação e desmistificação das regras do negócio, que só são disponíveis de conhecimento se houver a fonte desse conhecimento.

Evans (2003), afirma em seu livro que deve-se obter um bom modelo de domínio para controlar a complexidade do software a ser desenvolvido, modelo este que deve conter informações relevantes para a construção do domínio, de modo que proporcione aos desenvolvedores de software um aproveitamento satisfatório, o que é considerado algo difícil de fazer.

O DDD é um dos artefatos que pode auxiliar, principalmente, na comunicação entre o grupo de desenvolvimento e o grupo de profissionais especialistas no domínio do sistema. Com isso torna-se mais fácil o processo de levantamento de requisitos, que é fundamental para o planejamento do sistema (AVRAM; MARINESCU, 2006).

Avram e Marinescu (2006), completam ainda, mostrando que o conhecimento sobre a área em questão deve ser organizado para que ele possa ser dividido em pequenos pedaços, os quais devem ser organizados em grupos lógicos, que por sua vez serão trabalhados um a um. Contudo, algumas partes do domínio poderão ser descartadas desse estudo, um domínio pode abordar muita informação e nem tudo é necessariamente relevante. Porém, diferenciar informação relevante de informação irrelevante pode não ser tão simples dependendo do domínio abordado.

Para facilitar o desenvolvimento de um software complexo, segundo o DDD, o mesmo deve ser dividido em camadas com baixo acoplamento, e todos os processos de desenvolvimento de software devem envolver a segregação de responsabilidades, e que principalmente concentre o código relacionado ao domínio em uma camada apenas, onde estarão entidades, objetos de valor e regras de negócio, arquitetada conceitualmente de forma que esteja isolada da interface com o usuário, afirma Evans (2003).

Santos Júnior (2017), completa afirmando que os objetos de domínio, são livres da responsabilidade de se exibir, de se armazenar, de gerenciar tarefas de aplicação, e assim por diante, podem se concentrar em expressar o domínio. Isso permite que um modelo evolua para se tornar rico e limpo o suficiente para captar o conhecimento essencial do negócio e colocá-lo em funcionamento.

Após o entendimento dos fundamentos do DDD, é possível afirmar que as tarefas no desenvolvimento de software são complexas e, quanto maior a complexidade do sistema, maior a dificuldade na organização e comunicação, ocorrendo, principalmente porque o desenvolvedor e o cliente não têm completo conhecimento do domínio do sistema a ser desenvolvido.

4.1. LINGUAGEM ONIPRESENTE

Linguagem Onipresente ou Ubiquitous Language, é um conceito que Evans (2003), descreve no início de seu livro sobre a abordagem DDD, e mostra que a complexidade do desenvolvimento do software poderá ser diminuída conforme a comunicação entre os detentores do conhecimento melhorar. Os conceitos de cada área devem andar em conjunto com a implementação, ou seja, a linguagem que é falada entre os detentores do conhecimento, deve se apresentar na prática, ao codificar. Ocorrendo principalmente, porque a preciosidade de um modelo de domínio está no fato de que ele se ajusta com a linguagem onipresente.

O coração do software está na casa da sua capacidade de resolver problemas relacionados ao domínio para os usuários, todas as outras características formais, por mais vitais que possam ser se apoiam nessas finalidades básicas. Quando o domínio é complexo esta é uma tarefa difícil, exigindo a concentração de esforços de pessoas talentosas e capacitadas. Os desenvolvedores têm de mergulhar a fundo do domínio para adquirir conhecimentos sobre o negócio e é preciso afiar sua capacidade de modelagem e dominar design de domínios (EVANS, 2003).

A Linguagem Ubíqua, como mostra a Figura 1, proporciona a união entre os stakeholders: especialistas, desenvolvedores, analistas, tecnólogos e qualquer outro membro inserido no domínio do projeto.

Figura 1 – Exemplificação sistemática da linguagem onipresente

Fonte: <https://ptgmedia.pearsoncmg.com/images/chap5_9780735685352/elementLinks/05fig02.jpg> Acesso em: 19 mai. 2018.

Acreditar que modelos são feitos primeiro e em seguida implementados é um engano. Na metodologia ágil, o pensamento de projetar e depois construir tornou-se obsoleto. Os modelos que evoluem com o tempo são os considerados verdadeiramente bons, e os modeladores com maior experiência acreditam que conquistam melhores ideias depois do lançamento inicial do sistema (EVANS, 2003).

4.2. PROJETO

Projeto é um empreendimento não repetitivo, caracterizado por uma sequência bem definida de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros definidos de tempo, custo, recursos envolvidos e qualidade (VARGAS, 2005, p. 7).

Esmeraldo (2018), completa reafirmando que projeto pode ser considerado como um conjunto de ações sistematicamente ordenadas, com início, meio e fim preestabelecidos, e com objetivos claramente definidos. Portanto, elaborar um projeto passa pela concretização de ideias de forma planejada e organizada, e tem como foco resolver um problema em um determinado local ou ambiente.

4.2.1. Gestão de Projetos

Esmeraldo (2018), possui uma definição interessante, inserindo uma analogia com um toque de humor em seu conceito. Ele mostra que gerir ou gerenciar um projeto é como acompanhar o nascimento de um filho: deve-se tomar todos os cuidados necessários para que tudo ocorra dentro do esperado, isto é, o filho nasça sem problemas e todos fiquem tranquilos e comemorem este dia tão importante e significativo em nossas vidas. Mas atenção! Normalmente, em um determinado projeto, não temos nove meses disponíveis para planejarmos, executarmos, controlarmos, avaliarmos e, finalmente, podermos comemorar. Isto só é possível, tendo à frente um ótimo gerente de projetos e uma equipe capacitada e motivada, aí sim, a festa estará garantida.

O conceito de Gerenciamento de Projetos está bem definido no manual do PMI (Project Management Institute) guide to the Project Management Body of Knowledge, também conhecido como PMBOK Guide. Esse conceito é o uso do conhecimento, das habilidades, ferramentas e técnicas com a finalidade de suprir as necessidades e expectativas do empreendedor com relação a um projeto. Qualquer atividade, mesmo uma ida ao supermercado, pode ser tratada como um projeto. A lista de compras é o objetivo do projeto, o tempo disponível para as compras é o prazo, e o custo do projeto é o preço das compras. Se você planejar bem, comprará o que precisa, poupará tempo no supermercado e, comprando só o que precisa, economizará dinheiro (VARGAS, 2003, prefácio).

4.3. SOFTWARE

Para Leite (2006), Softwares podem ser definidos como programas de computadores, em suas diversas formas, e a documentação associada. Completa ainda afirmando que um programa é um conjunto de soluções algorítmicas, codificadas numa linguagem de programação, executado numa máquina real. Software é um produto conceitual e lógico.

5. UTILIZAÇÃO DA LINGUAGEM ONIPRESENTE NA COMUNICAÇÃO

Para auxiliar na organização de ideias, advindas da comunicação com aquele que detém o conhecimento, são utilizadas algumas ferramentas, onde é possível gerar diagramas de classe, modelos entidade-relacionamento, e para a modelagem de banco de dados, tais ferramentas serão descritas nessa seção.

Segundo a SWEBOK² (2013, tradução própria), a fase de modelagem oferece a quem a utiliza, uma abordagem sistematizada e organizada de representação dos pontos significativos do software, facilitando estudos, tomadas de decisão sobre o software e a comunicação entre stakeholders sobre essas decisões.

A modelagem é uma parte central de todas as atividades que levam à implantação de um bom software. (BOOCH; RUMBAUGH, JACOBSON. 2000. p. 3). Neis e Junckes (2014), completam afirmando que, se bem utilizada, ela pode reduzir alguns dos maiores riscos de qualquer projeto de software, que são a qualidade da entrega e o tempo previsto.

5.1. FERRAMENTAS

Para a união da linguagem onipresente com a comunicação dentro de projetos de desenvolvimento de software, a ferramenta Draw.io³ é muito útil, pois serve para criar desenhos de diagramas online, é gratuita e dos mesmos desenvolvedores das bibliotecas JGraph. Ela apresenta uma interface intuitiva e diversas variedades de componentes para criação de diagramas. Diagramas foram criados e exportados em diversos formatos para que pudesse ser feito uma análise das principais funcionalidades da ferramenta (COELHO, 2015).

Uma de suas principais características é apresentar componentes especiais para criação de diagramas UML, que significa Linguagem de Modelagem Unificada ou Unified Modeling Language, como caixas de texto e tabelas, assim como componentes e ícones presentes em sistemas operacionais modernos como o Android e IOS, que são sistemas para dispositivos móveis amplamente utilizados. Vale destacar que por ser executada direto no browser do usuário, não requer instalação e pode ser utilizada em qualquer sistema operacional, contudo só pode ser utilizada se uma conexão com a internet estiver disponível (COELHO, 2015).

Com relação à importação e exportação de arquivos, Coelho (2015), completa afirmando que, Draw.io se mostra repleto de possibilidades. Ao iniciar a ferramenta, ou seja, acessar o endereço web, é apresentado ao usuário uma janela em que deve ser escolhido o local de armazenamento dos diagramas. Dentre as opções de armazenamento disponíveis estão as ferramentas de armazenamento em nuvem Dropbox e Google Drive, bem como as opções de salvar no browser e no computador. Escolhido o local onde serão armazenados os diagramas e criado um diagrama, os diagramas criados podem ser exportados em diversos formatos como png, xml, gif, pdf, svg, jpg ou com a opção de exportação avançada que permite a exportação nos mesmos formatos, porém com formatação de tamanho e cor de fundo.

5.2. UTILIZAÇÃO

Evans (2003) deixa claro em suas menções à linguagem onipresente que todos os processos de conversação nos ciclos do desenvolvimento de software devem ser levados em conta na codificação. Destilando essa frase, os conceitos devem ser padronizados entre os detentores de conhecimento e os desenvolvedores de software. Se há um termo, alguma palavra, ou, um conceito importante para o domínio do negócio, o mesmo deve estar presente no conceito e na codificação prática do domínio, pois será válido em momentos cuja manutenção necessitará dos mesmos. Boas práticas afirmam que, métodos e variáveis que forem desenvolvidas no código, não devem estar abreviadas e devem ter títulos em harmonia com suas utilizações. Outro ponto válido de discussão em linguagem onipresente é a padronização da língua em que o código está sendo escrito. Deve-se utilizar apenas uma língua para codificação. Prefere-se então utilizar a língua do cliente, ou seja, utilize ObterPessoaPorID(int pessoaID), ao invés de GetPessoaByID(int personID). Evans (2003), afirma ainda que, as relações do modelo se tornam regras combinatórias que todas as linguagens possuem. Os significados das palavras e das frases ecoam a semântica do modelo.

Os conceitos das palavras e termos da linguagem onipresente são tão importantes que remetem diretamente ao domínio, logo, conforme os termos mudarem, todo o domínio mudará, inclusive funções, métodos e variáveis dentro do sistema por completo.

Evans (2003) completa em seu livro, afirmando assiduamente que após o modelo do domínio estar pronto, com todas as nomenclaturas de métodos e variáveis, tendo sido criado pelos desenvolvedores de software e um especialista no domínio, detentor de conhecimento tentar compreendê-lo e não conseguir, há algo de errado com o modelo. Logo, a harmonia de termos e palavras dentro de um desenvolvimento deve ser, de acordo com Evans (2003), a espinha dorsal do modelo de domínio.

A busca constante é para que haja uma linguagem comum durante o projeto de desenvolvimento de software, pois enquanto a identificação dos conceitos bem como os seus limites não ficarem explícitos, alguns problemas serão encontrados.

Veras (2017) exemplificou um desses problemas, fazendo menção a uma brincadeira infantil denominada telefone sem fio, ele exemplifica afirmando que chama as pessoas a quem atende em sua área de trabalho de cliente, já outros colaboradores chamam de titular, fornecedor, ou qualquer outra coisa, menos o que já foi dito por ele. E no momento em que é preciso mencionar a palavra cliente em seu vocabulário a alguém, pode gerar alguma dúvida, pois nem todos estão harmonizados com as mesmas nomenclaturas.

A linguagem onipresente, ou ubíqua, é uma técnica que faz parte do bloco estratégico do DDD, e que nesse ambiente auxilia na comunicação, contextualização, identificação, refinamento ou concepção e delimitação dos conceitos de um processo de negócio, ela nos direciona na construção do desenho de modelo do domínio do negócio. No geral, ela fortalece os laços entre os especialistas do negócio e a equipe de desenvolvimento. E quanto melhor for a comunicação entre as equipes, mais fácil será o desenvolvimento, aumentando a qualidade do software em tempo e código.

Na Figura 2 é possível visualizar um código implementado, utilizando conceitos de linguagem onipresente. A leitura da imagem pode ser feita até por alguém que não conhece profundamente técnicas de programação e desenvolvimento de software. E qualquer desenvolvedor de software que tiver de fazer a leitura desse trecho de código, a faz com facilidade, pois nela há uma linguagem que com uma pequena interpretação já é lida.

Basicamente o método “Conferir” realiza as seguintes operações: o produto deve ser lido pela classe “Scanner” através do método “Ler” e lá são passados como parâmetros a lista de produtos e o código de barras a ser pesquisado na lista. Em seguida o “Cupom” a ser escolhido é o que está “aberto” através do método “Aberto()”. O próximo passo é registrar o cupom com a quantidade e o produto advindo da leitura pelo método “Ler”, onde será recebido o “ItemDoCupom”. O cupom será gravado, através do método “Gravar”, recebendo o “Cupom” em aberto e por fim, será feita a impressão do “ItemDoCupom”, através do método “Imprimir”.

Nesse exemplo fica claro apresentar o quão importante é a linguagem onipresente. O leitor é convidado a ler em voz alta o parágrafo anterior, enquanto visualiza a Figura 2 para que seja possível compreender a facilidade que o conceito de linguagem onipresente oferece.

Figura 2 – Exemplo implementado utilizando a linguagem onipresente

Fonte: <https://medium.com/@vsveras/domain-driven-design-linguagem-ub%C3%ADqua- 9a7d2b3a0f74> Acesso em: 22 out. 2018.

Fowler (2004) cria uma frase cômica, mas que passa a mensagem da importância do tema dessa monografia: Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender.

6. CONSIDERAÇÕES FINAIS

Foi possível indicar que a comunicação é um dos pilares fundamentais em todas as relações interpessoais, e que quando se trata da vertente profissional, mais especificamente em projetos, a comunicação é a base de todo o entendimento e está presente durante toda a evolução do projeto, desde o escopo, até a conclusão, e essa monografia buscou, através da revisão bibliográfica, formas de apresentar dados de outras pesquisas para confirmar a argumentação de que muitos dos problemas que causam fracassos nos projetos são advindos de falhas de comunicação, também foram apresentadas formas de unir a engenharia de software aos projetos de desenvolvimento de software, buscando no aprofundamento da abordagem DDD, alguns pontos que unem os desenvolvedores de software aos detentores de conhecimento, pessoas que estão incluídas nos projetos de desenvolvimento software.

E considera-se que a linguagem onipresente da abordagem DDD, pode e deve ser utilizada sem moderação, uma boa comunicação entre as equipes é fundamental para o conhecimento do negócio. Nas reuniões, no planejamento ou na implementação através de código, deve-se focar no que traz maior valor ao negócio e buscar utilizar as formas abstratas para transcrever em código todos os processos reais do negócio, ou seja, todos os participantes do projeto devem falar a mesma linguagem.

Mediante os parágrafos anteriores, a diminuição dos fracassos em projetos de desenvolvimento de software, pode ser alcançada se os profissionais de desenvolvimento unirem-se aos detentores de conhecimento, fazendo com que todos possam se comunicar utilizando os mesmos termos, destilando o problema do cliente para que seja possível compreender o escopo e a necessidade do cliente, e então o projeto seja desenvolvido de maneira escalável, e a implementação não será dificultada se todos souberem do assunto. Sendo ainda possível que os desenvolvedores de software inseridos no projeto possam propor soluções mais cabíveis a um determinado nicho de problemas. E a contribuição acadêmica dessa monografia está focada na problematização do tema, pois são tratados assuntos complexos, viabilizando a comunicação facilitada dentro do desenvolvimento de projetos de software, sendo unida a engenharia de software, trabalhando com paradigmas e boas práticas de desenvolvimento de software, citadas na abordagem DDD, como a plena utilização da linguagem onipresente, orientada por Eric Evans em seu livro, por isso, há muitos cenários para a evolução dessa pesquisa, aprimorando conceitos e compreendendo melhores maneiras de desenvolver um projeto de sucesso, contribuindo com a sociedade e o mercado nos dias atuais.

7. REFERÊNCIAS BIBLIOGRÁFICAS

ANDRADE, Antonio José F. et al. Gestão de projeto com Scrum: Um estudo de caso. Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE). Aracati, p. 12, 2009.

AVRAM, Abel; MARINESCU, Floyd. Domain-Driven Design: Quickly. EUA: C4Media, 2006.

BARGOSA, Gustavo; RABAÇA, Carlos Alberto. Dicionário de comunicação – 2. ed. ver. e atualizada – Rio de Janeiro: Campus, 2001.

BASS, Len; CLEMENTS, P., KAZMAN, R. (2003). Software Architecture in Practice. Addision-Wesley, 2. ed. Disponível em: <http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/SWEBOK/Addison%20 Wesley%20- %20Software%20Architecture%20In%20Practice%202nd%20Edition.pdf> Acesso em: Acesso em: 29 abr. 2018.

BISSI, Wilson. Metodologia de desenvolvimento ágil. Campo Digital, v. 2, n. 1, 2007. DELGADO SG, Kenneth et al. Aprendizaje eficaz y recuperación de saberes. Lima: Editorial San Marcos, 2004.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia de Usuário. Rio de Janeiro: Ed. Campus. 2000.

CAMILO, F. C; JUNIOR, F. F.; NOGUEIRA, R. V. A Melhoria de Desempenho de Processos em uma Instituição Bancária. Portal Centro Paula Souza. Disponível em: <http://www.portal.cps.sp.gov.br/pos-graduacao/workshop-de-pos-graduacao-e- pesquisa/007-workshop-2012/workshop/trabalhos/servenggest/melhoria-de- desempenho.pdf>. Acesso em: 30 abr. 2018.

CARVALHO, Marly Monteiro de; MIRANDOLA, Daniela. A comunicação em projetos de TI: uma análise comparativa das equipes de sistemas e de negócios. Production Journal, v. 17, n. 2, 2007.

COELHO, Willian Domingues. Editor de Gramáticas de Grafos Orientados a Objeto. 2015.

DRUCKER, Peter F. O Melhor de Peter Drucker: Homem, Sociedade, Administração. São Paulo: Nobel, 2002.

DRUCKER, Peter F. The Essential Drucker - with an appreciation by Charles Handy. 2. ed. Oxford: Ed. Butterworth Heineman, 2007.

ESMERALDO, Jorge Ney. Gestão de Projetos: Técnico em Serviços Públicos. IFMG, 2018.

EVANS, E. Domain-Driven Design – Atacando as complexidades no coração do software. 3ª Ed. Revisada. Rio de Janeiro: Alta Books, 2017. p. 499. ISBN: 978-85- 508-0065-3.

FALBO, R. A., Integração de Conhecimento em um Ambiente de Desenvolvimento de Software, Tese de Doutorado, COPPE/UFRJ, 1998. Disponível em: <http://sedici.unlp.edu.ar/bitstream/handle/10915/24194/Documento_completo.pdf?s equence=1>. Acesso em: 17 abr. 2018.

FARIA, Ivano Gomes de. O Impacto da Falta de Comunicação entre o Gerente e a Equipe de Projetos. Revista TecHoje, 2010. Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1580>. Acesso em: 17 abr. 2018.

FIRMINO, Giovanni Luis Baroni; ZANELATO, Ana Paula Ambrósio.

DESENVOLVIMENTO DE CAMADAS UTILIZANDO DDD. ETIC – Encontro de Iniciação Científica, 2014. Disponível em: <http://intertemas.toledoprudente.edu.br/revista/index.php/ETIC/article/view/3978/37 40>. Acesso em: 17 abr. 2018.

FOWLER [I], Martin. 2004. Refatoração – Aperfeiçoando o Projeto de Código Existente. Bookman 2004. p.774. ISBN 0-201-48567-2.

FOWLER [II], Martin. Patterns of Enterprise Architecture. Addision-Wesley, 2002.

FRANCO, J. R.; MATTOS, K. M.; DOLL, L. M.; ALMEIDA, J. Domain-Driven Design e Test-Driven Development. In: 5º Encontro de Engenharia e Tecnologia dos Campos Gerais, 2010. Disponível em: <http://www.5eetcg.uepg.br/Anais/artigospdf/50021_vf1.pdf>. Acesso em: 29 abr. 2018.

GARLAN, David; PERRY, Dewayne. Software Architecture: Practice, Potential, and Pitfalls. In: IEEE Transactions on Software Engineering, 21:4, 1995). Disponível em: <http://users.ece.utexas.edu/~perry/work/papers/icse16.pdf>. Acesso em: 30 abr. 2018.

HELDMAN, Klin. Gerência de projetos fundamentos: um guia prático para quem quer certificação em gerência de projetos. Tradução: Luciana do Amaral Teixeira. Rio de Janeiro: Elsevier, 2005

KNIBERG, H.; SKARIN, M. Kanban and Scrum – Making the Most of Both. 1 ed. Estocolmo, Suécia: InfoQ, 2009.

KRAFZIG, D., BANKE, K. & SLAMA, D. (2004). Enterprise SOA: Service-Oriented Architecture Best Practices. Indianapolis: Prentice Hall.

LEITE, Jair C. Engenharia de Software. 2006. Disponível em: <https://www.dimap.ufrn.br/~jair/ES/slides/Software.pdf>. Acesso em: 30 abr. 2018.

MACHADO, Marcos; MEDINA, Sérgio Gustavo. SCRUM–Método Ágil: uma mudança cultural na Gestão de Projetos de Desenvolvimento de Software. Revista Científica Intr@ ciência, Guarujá, 2009.

MARTIN, R. C. SRP – The Single Responsibility Principle. 2009. Disponível em: <http://www.objectmentor.com/resources/articles/srp.pdf> Acesso em: 23 set. 2018.

MELO, C. D.; SANTOS, V. A.; CORBUCCI, H.; KATAYAMA, E.; GOLDMAN, A.; KON, F. Métodos ágeis no Brasil: estado da prática em times e organizações. São Paulo: IMEUSP, Departamento de Ciência da Computação, 2012.

MOLENA, A. A Comunicação na Gestão de Projetos. Revista eletrônica “Prodan Tecnologia – 3ª Edição, ano 2, São Paulo, 2009. Disponível em: Acesso em 20 de out. de 2018.

MORAIS, Marcelo. 2015. Desmistificando o DDD. Disponível em: < http://www.mrmorais.com/2015/11/22/desmistificando-o-ddd/>. Acesso em: 23 set. 2018.

NEIS, Eduardo Claumann; JUNCKES, Gabriel Dias. Ferramenta web para modelagem de diagramas UML com integração à ferramenta desktop. Sistemas de Informação-Pedra Branca, 2014.

PILLEGGI, Marcus Vinicius. Falhas na comunicação são principal motivo de fracasso nos projetos das empresas. Pequenas Empresas & Grandes Negócios, 2010. Disponível em: <http://revistapegn.globo.com/Revista/Common/0,,EMI138376- 17180,00- FALHAS+NA+COMUNICACAO+SAO+PRINCIPAL+MOTIVO+DE+FRACASSO+NO S+PROJETOS+DAS+EMP.html>. Acesso em: 17 abr. 2018.

PIRES, Eduardo; DDD não é arquitetura em camadas. Eduardo Pires – Treinamento e Consultoria, 2016. Disponível em: <http://www.eduardopires.net.br/2016/08/ddd- nao-e-arquitetura-em-camadas/>. Acesso em: 17 abr. 2018.

SANTOS, Eloisa Cristina Silva. Integração da abordagem Domain-Driven Design e da técnica Behaviour-Driven Development no Desenvolvimento de Aplicações web. Dissertação de Mestrado, UFSCAR, 2015. Disponível em: <https://repositorio.ufscar.br/bitstream/handle/ufscar/7588/DissECSS.pdf?sequence= 1&isAllowed=y>. Acesso em: 17 abr. 2018.

SANTOS JÚNIOR, Edson Batista dos. Implementando Domain-Driven Design no desenvolvimento Javascript. UFF, 2017. Disponível em: <https://app.uff.br/riuff/handle/1/5184>. Acesso em: 23 set. 2018.

SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with SCRUM. Prentice Hall, 2002.

SERRANO, Edgar. A reforma trabalhista e o desenvolvimento tecnológico no Brasil. O GLOBO, 2017. Disponível em: <https://oglobo.globo.com/opiniao/a-reforma- trabalhista-o-desenvolvimento-tecnologico-no-brasil-21409049>. Acesso em: 17 abr. 2018.

SOARES, Matheus Maciel. Análise comparativa de ferramentas utilizadas para Kanban. UFRGS. 2017.

SORDI, J.O.; MARINHO, B.L; NAGY, M. Benefícios da Arquitetura de Software Orientada a Serviços para as Empresas: Análise da Experiência do ABN AMRO Brasil. 2006. Revista de Gestão da Tecnologia e Sistemas de Informação. Disponível em: <http://www.spell.org.br/documentos/ver/21412/beneficios-da-arquitetura-de- software-orientada-a-servicos-para-as-empresas--analise-da-experiencia-do-abn- amro-brasil->. Acesso em 29 abr. 2018.

VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 6. ed. Rio de Janeiro: Brasport, 2005. p. 7.

VASCONCELOS, Yumara Lúcia. Metodologia Scrum e a gestão de atividades didático-pedagógicas realizadas em colaboração. Revista Tecnologias na Educação – Ano 8 - número 14. 2016.

VERAS, Veranildo. Domain-Driven Design - Linguagem Ubíqua. Estabelecendo uma comunicação mais real. Linkedin Pulse, 2017. Disponível em: <https://pt.linkedin.com/pulse/domain-driven-design-linguagem-ub%C3%ADqua- veranildo-veras>. Acesso em: 17 abr. 2018.

VERSIONONE. 11th Annual State of Agile Report. 2017. Disponível em: <https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile- report-2> Acesso em: 23 de mai. 2018.