Il termine artifact
(or artefact
) sembra essere stato reso popolare in tutto il tempo che Booch, Rumbaugh e Jacobsen (la 3 amigos) ha descritto il Rational Unified Process.
La parola Artifact in ingegneria del software RUP era un termine generico per riferirsi a qualsiasi 'risultato finale', che potrebbe essere prodotta da qualsiasi 'ruolo' nello sviluppo del ciclo di vita del software, tra cui:
- Documenti, come Project Plan, Requirements Document, Specifications etc
- Un modello generato durante la progettazione, di solito uno dei diagrammi disponibili UML, ad esempio un diagramma di classe o ERD
- Manufatti di codice, inclusi file di origine, uscite binarie e codice di test o supporto.
Gli artefatti possono essere introdotti nella gestione della configurazione del software (identificato, versione, modifica potrebbe essere gestito, ecc.).
Il termine artefatto si manifesta anche nella modellazione dei processi aziendali, di solito riferita a un documento fisico o elettronico prodotto da un processo, ad es. un modulo di richiesta, un documento EDI o un output di report.
Al giorno d'oggi, la parola artifact
può essere considerata alla stessa luce di pretentious management speak e il termine è solitamente troppo vago e generico per essere utilizzato frequentemente dall'effettivo team di sviluppo del software, ad es. si otterrà sguardi fissi nel vuoto se si utilizza termini come:
-
"Ho finito il check-in del manufatto"
-
"Per favore si potrebbe scrivere un artefatto per la nostra banco di prova successiva"
cioè È probabile che desidera utilizzare ter più specifica Minologia alla faccia del carbone dello sviluppo del software!
Puoi aggiungere qualche citazione da quel libro che contatina la parola "artefatto"? – Roman