Documentação de arquitetura de software em contextos ágeis de desenvolvimento
| Ano de defesa: | 2024 |
|---|---|
| Autor(a) principal: | |
| Outros Autores: | |
| Orientador(a): | |
| Banca de defesa: | |
| Tipo de documento: | Dissertação |
| Tipo de acesso: | Acesso aberto |
| Idioma: | por |
| Instituição de defesa: |
Universidade Federal do Amazonas
Instituto de Computação Brasil UFAM Programa de Pós-graduação em Informática |
| Programa de Pós-Graduação: |
Não Informado pela instituição
|
| Departamento: |
Não Informado pela instituição
|
| País: |
Não Informado pela instituição
|
| Palavras-chave em Português: | |
| Link de acesso: | https://tede.ufam.edu.br/handle/tede/10437 |
Resumo: | O contexto de desenvolvimento de software atual contém alta competitividade e impõe às empresas a necessidade crescente de entregar valor rapidamente e com custo baixo. Nesse caso, os recursos são alocados no desenvolvimento acelerado em detrimento de atividades de planejamento e de documentação de arquitetura de software. Dessa forma, informações relevantes sobre o sistema como interações do usuário, infraestrutura e plataforma de desenvolvimento, por exemplo, não são definidas ou documentadas da melhor forma, levando à maior complexidade de desenvolvimento e manutenção dos sistemas. Nesse contexto, a questão de pesquisa deste trabalho é quais abordagens de documentação da arquitetura de sistemas são viáveis em contextos ágeis de desenvolvimento de software e como utilizá-las? Para respondê-la, uma revisão da literatura e uma Feature Analysis foram realizadas, para avaliar as abordagens 4+1, S4V, ADD, BAPO/CAFCR, C3A e C4. A análise indicou as abordagens 4+1 e C4 com potencial de aplicação no contexto estudado e, para validá-las, três estudos experimentais foram realizados. Foi possível mostrar que não há diferença significativa na corretude da documentação ao utilizar as duas abordagens. Entretanto, algumas visões, como a de contexto (C4) e física (4+1), por exemplo, são mais importantes e mais fáceis de utilizar nas fases iniciais de desenvolvimento e outras, como a de componentes (C4) e lógica (4+1), por exemplo, só serão úteis em estágios futuros. Por fim, verificou-se também que, para não impactar o processo de desenvolvimento, uma solução é definir uma pessoa da equipe para documentar a arquitetura do sistema, desde que tenha conhecimento amplo sobre o produto e, se não o tiver, permita a contribuição por parte dos outros membros da equipe. |