Warning: Undefined variable $ebook_id in /home/dhekac77/public_html/wp-content/themes/dheka/functions.php on line 932
Warning: Undefined variable $ebook_id in /home/dhekac77/public_html/wp-content/themes/dheka/functions.php on line 934
https://dheka.com.br/wp-content/uploads/2018/01/Aspectos-Sociologicos-e-a-Engenharia-de-Software-700x541.webp;
Evolução Tecnológica sim…
A Engenharia de Software vem evoluindo muito ao longo dos anos. Desde o desenvolvimento de um software por um único profissional até ser considerada uma engenharia com diferentes disciplinas e mais formalidade, e com a necessidade de um corpo de profissionais de diversas especialidades, situação simular às outras engenharias.
Esta mudança veio acompanhando a evolução tecnológica, mas também se fez necessária devido a crescente complexidade das soluções de TI. Atualmente, não se concebe mais um negócio de sucesso que não tenha ao menos um software de apoio gerencial.
Assim, a área de TI deixou de ser uma área meramente de apoio para se tornar uma área estratégica da qual os negócios dependem diretamente para ter sucesso. Quantas vezes nos deparamos com situações em que um serviço qualquer se torna indisponível por um problema de sistema ou uma indisponibilidade de rede? Em alguns casos, tal situação implica em perda de lucros ou redução na carteira de clientes.
… mas e a Visão Sociológica?
Porém, com toda a evolução tecnológica, uma área crucial se perdeu, ou ao menos não teve uma evolução compatível com as demais. Nossos profissionais de TI, cada vez mais conhecedores de tecnologias mais avançadas, utilização de serviços, mineração de dados, entre outros, carecem de uma visão sociológica dos projetos, relacionada às diferentes percepções dos envolvidos.
As próprias disciplinas das universidades de TI não contemplam estes aspectos com a devida profundidade. Diversos projetos depositam toda a possibilidade do sucesso nas tecnologias e arquiteturas sem levar em conta os diversos aspectos sociológicos envolvidos.
Cabe ressaltar que ao mencionar os aspectos sociológicos do projeto não devemos nos restringir à interação entre equipe de desenvolvimento e equipe cliente. Conforme mencionado por Goguen (1993), considerando que em um projeto haja uma equipe de requisitos, uma equipe de desenvolvimento e a equipe cliente, existem ao menos seis possíveis fontes de questões sociológicas, visto que tais questões podem ocorrer sempre que houver interações entre pessoas. Neste caso, teremos interações Intra-equipes e Inter-equipes ou, até mesmo, com equipes fora das fronteiras organizacionais. Os envolvidos podem fazer com que uma tecnologia naufrague, mesmo que ela seja excelente, se eles não a entenderem e a apoiarem.
Mas como tudo isso começa?
Tais questões surgem devido à forma como cada indivíduo entende o mundo e as situações do dia-a-dia. Segundo o sociólogo Erving Goffman (1974), quando um indivíduo reconhece um novo evento ele tende a aplicar em resposta um ou mais frameworks ou esquemas de interpretação denominados primários.
Tais esquemas são idéias pré-concebidas baseadas em todas as experiências anteriores vividas por este indivíduo, e vêm sendo criados e aprimorados em cada convívio social que temos desde a família até as relações de trabalho e demais relacionamentos.
Assim, o indivíduo escolhe o esquema que considera mais adequado para entender uma determinada situação com base em seus interesses pessoais e experiências anteriores. Como cada indivíduo teve experiências diferentes ao longo da vida, é natural que sua percepção do mundo que o cerca seja única e pessoal. Assim, no momento em que se faz necessária qualquer troca de informações, tais visões de mundo estão embutidas no conteúdo da informação e sujeitas a interpretação de cada indivíduo.
Porém, não é só isso.
Logicamente, isto é uma fonte inesgotável de possíveis equívocos no momento da comunicação. Como, no mundo atual, devido à complexidade das soluções de TI, o desenvolvimento de soluções depende da interação entre diversos profissionais, tais equívocos aparecem e podem influenciar as soluções desviando-as do objetivo e, por conseguinte, devem ser foco de atenção constante por parte dos envolvidos no projeto. O ideal é que todos os envolvidos estejam atentos a estas fontes de problemas de comunicação, mas principalmente gerentes, líderes técnicos e os profissionais de requisitos e processos, visto que interagem constantemente com as demais equipes.
Outra observação feita por Goffman (1974) foi a de que estes esquemas de interpretação são também influenciados pela cultura de um grupo social ou uma organização. Segundo Goffman (1974), os esquemas primários constituem um elemento central da cultura de um grupo. Isto significa que este grupo também possui esquemas comuns que são utilizados entre seus membros.
Logo, ao iniciarmos o desenvolvimento de um sistema em uma nova organização ou grupo é importante se fazer uma observação da cultura deste grupo e de seus hábitos de comunicação e entendimentos comuns para reduzir as possibilidades de equívocos de entendimento. Uma possibilidade de mitigação destes equívocos é a realização de uma etnografia na área cliente por um pequeno período para se conhecer minimamente sua cultura. Outra ação possível é a utilização de um especialista do domínio do cliente na equipe do sistema que poderá fazer uma “tradução” de termos e jargões de uma área para outra.
Conclusão
Qualquer que seja o sistema, é importante que as questões sociológicas sejam fruto de acompanhamento tão constante quanto o acompanhamento das tecnologias envolvidas, pois, caso sejam negligenciadas, podem contribuir fortemente para o insucesso deste sistema.
Referências
GOFFMAN, E.; “Frame Analysis”. Northeastern University Press, Boston Massachusetts. 1974.
GOGUEN, J.; “Social Issues in Requirements Engineering”. Proceedings of IEEE International Symposium on Requirements Engineering. 1993.
Publicado por: Fernando Muradas fernando.muradas@marinha.mil.br
Possui graduação em Engenharia pela UERJ, pós-graduação em Ciência da Computação pela PUC-RJ, mestrado em Qualidade de Software pela COPPE-UFRJ, quando desenvolveu o processo de avaliação utilizado pelos modelos MPS.Br e QPS como sua dissertação de mestrado, e doutorado em Ciência da Computação com ênfase em Engenharia de Requisitos pela Universidade de Oxford (Reino Unido). Atuou como Gerente da área de qualidade de Software do CASNAV até o ano de 2009. Atualmente é Especialista em Requisitos do Laboratório de Análise de Sistemas do Centro de Análises de Sistemas Navais, bem como Gerente do Desenvolvimento do Sistema de Saúde da Marinha do Brasil. É avaliador Líder do MPS.Br. Tem mais de 15 anos de experiência na área de Desenvolvimento de Sistemas, com ênfase em Gerência, Modelagem e Requisitos, atuando nas seguintes áreas: Sistemas Administrativos e Operativos da Marinha do Brasil, Ministério da Defesa e ANTAQ.