Propostas Submetidas - sem aluno

DEI - FCTUC
Gerado a 2024-05-01 22:59:56 (Europe/Lisbon).
Voltar

Titulo Estágio

Estudo da aplicabilidade da Lei de Conway

Áreas de especialidade

Engenharia de Software

Sistemas de Informação

Local do Estágio

Software and Systems Engineering Group (SSE) do CISUC (piso5, torre E, no DEI)

Enquadramento

Segundo a Lei empírica de Conway, "a estrutura dos artefactos de software reflecte a estrutura das organizações que os criaram". Esta 'lei', encarada mais como uma ironia do que como um facto real, está associada a um certo número de exemplos que a parecem comprovar, ainda que sem qualquer fundamento científico.

Contudo, mais recentemente, e com a crescente importância dos aspectos socio-técnicos nas organizações especialmente de base tecnológica, a validade desta lei tem sido de alvo de inúmeros estudos recentes, sob a designação de 'mirroiring hypothesis'.


[url=https://en.wikipedia.org/wiki/Conway%27s_law]lei de Conway[/url]

Objetivo

O objectivo deste estágio é estudar a consistência da Lei de Conway nas organizações actuais de desenvolvimento de software.

Dado o crescente número de canais de comunicação dentro estas organizações (e.g. o slack), e da utilização de ferramentas de gestão de código (nomeadamente o git), o foco deste estudo assentará no mapeamento da intensidade e natureza de comunicação entre membros da equipa de software e a estrutura (design) do código gerado. Ou seja, queremos avaliar se existe uma congruência entre os interfaces dos componentes de software e a interacção entre os developers desses componentes.

A hipótese de partida é a de que os componentes de software em cujo interface são detectados mais defeitos serão aqueles em que a intensidade de comunicação entre os membros da equipa que os desenvolveram foram menos intensos. Outros aspectos a estudar, focando o reflexo da organização da equipa na estrutura do artefacto desenvolvido (*), serão definidos ao longo do trabalho.

Os resultados deste estudo têm um enorme potencial para melhorar a qualidade software desenvolvido, podendo mesmo servir como um indicador de dívida técnica acumulada, mas actualmente invisível. No limite poderão guiar a selecção dos componentes a ser alvo de maior controlo de qualidade, nomeadamente inspecções de código, walkthroughs ou injecção de defeitos, entre outras.

(*) por exemplo, se existirem três equipas distintas envolvidas num projecto, existirão três grandes módulos arquitecturais?

Plano de Trabalhos - Semestre 1

-Levantamento do estado da arte sobre a 'mirroiring hypothesis'.
-Contacto com as empresas (**) em cujo ambiente irão decorrer os estudos.
-Identificação dos processos internos e ferramentas utilizadas em cada uma das empresas-alvo.
-Desenho do ambiente de investigação a montar (APIs de recolha de dados, desenho das experiências, análise de dados e realizar).
-Definição de um plano de trabalhos.
-Início do estudo de campo.
-Recolha e análise dos primeiros resultados (Iteração 1).
-Escrita do relatório Intermédio.

----------------------------------
(**) da zona de Coimbra.

Plano de Trabalhos - Semestre 2

-Análise e integração do feedback do júri da avaliação intermédia.
-Definição do plano de investigação para o segundo semestre: que novas hipóteses serão testadas e que infraestrutura será necessário instalar para as realizar.
-Iteração 2
-Iteração 3
(...)
O trabalho decorrerá em modelo de 'agile-research', ou seja estará organizado em múltiplas iterações de pequena dimensão, em que no final de cada iteração uma nova questão de investigação (research question) é colocada e validade na iteração seguinte.

-Escrita de um artigo científico para publicação.
-Escrita do relatório de Dissertação final.
-Defesa da tese.

Condições

Até ao momento ainda não foi possivel assegurar financiamento (bolsa de investigação) para este estudo.

Orientador

Mário Zenha Rela
mzrela@gmail.com 📩