Um artefacto (Pt/Pt) ou artefato (Pt/Br) é um dos vários tipos de subprodutos concretos produzido durante o desenvolvimento de software. Alguns artefatos (por exemplo, casos de uso, diagramas de classes, requisitos e documentos de projeto) ajudam a descrever a função, arquitetura e o design do software. Outros artefatos estão relacionados com o próprio processo de desenvolvimento - tais como planos de projetos, processos de negócios e avaliações de risco. Podem ser manuais, arquivos executáveis, módulos etc.
O termo artefato em conexão com o desenvolvimento de software é amplamente associado com métodos ou processos de desenvolvimento específicos, por exemplo, o Processo Unificado. Este uso do termo pode ter sido originado com esses métodos.
Autores como Orlikowski e Iacono (2001, p.19)[1] definem artefato como "pacotes de propriedades materiais e culturais empacotados em alguma forma socialmente reconhecível como hardware e / ou software". Por outro lado, autores como Curry, Marshall e Kawalek (2014)[2] comentam que é cada vez mais complexo definir o limite entre os artefatos e funções tecnológicas dado a evolução da modalidade prática do artefato em si, o qual passa de um simples substituto do trabalho para um atuador no processamento de informação.
Quando se cria ou se mantém um software, vários documentos são criados no processo. Por exemplo:
- Casos de uso, para detalhar a interação do usuário com o software;
- Modelos de dados, para descrever como se estruturam os dados que o software usa;
- O próprio código-fonte do software;
- Diagramas UML de vários tipos;
- Atas ou outros registros de reuniões.
Esses documentos (e muitos outros) são necessários para que as pessoas envolvidas no desenvolvimento de software tenham uma base de informação em comum para se comunicar a respeito do software. Esses documentos são chamados, coletivamente, de artefatos de software. Dependendo da metodologia de desenvolvimento (se alguma for usada), os tipos de artefato variam.
É possível, em tese, não ter artefatos, exceto pelo código-fonte, mas isso vai tornar qualquer tarefa de manutenção do programa um pesadelo: para descobrir o que faz cada parte do sistema, seria preciso fazer engenharia reversa do programa! É muito mais prático consultar um diagrama ou documentação, e entender de cara como aquele pedaço do sistema funciona (ou deveria funcionar).
- ↑ Orlikowski, Wanda J.; Iacono, C. Suzanne (junho de 2001). «Research Commentary: Desperately Seeking the "IT" in IT Research—A Call to Theorizing the IT Artifact». Information Systems Research (2): 121–134. ISSN 1047-7047. doi:10.1287/isre.12.2.121.9700. Consultado em 10 de abril de 2021
- ↑ Curry, Michael; Marshall, Byron; Kawalek, Peter (agosto de 2014). «IT artifact bias: How exogenous predilections influence organizational information system paradigms». International Journal of Information Management (4): 427–436. ISSN 0268-4012. doi:10.1016/j.ijinfomgt.2014.02.005. Consultado em 10 de abril de 2021