Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Artifact (software development).
Nothing was collected or created yet.
Artifact (software development)
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (August 2009) |
An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, requirements and design documents) help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.
The term artifact in connection with software development is largely associated with specific development methods or processes e.g., Unified Process. This usage of the term may have originated with those methods.
Build tools often refer to source code compiled for testing as an artifact, because the executable is necessary to carrying out the testing plan. Without the executable to test, the testing plan artifact is limited to non-execution based testing. In non-execution based testing, the artifacts are the walkthroughs, inspections and correctness proofs. On the other hand, execution based testing requires at minimum two artifacts: a test suite and the executable. Artifact occasionally may refer to the released code (in the case of a code library) or released executable (in the case of a program) produced, but more commonly an artifact is the byproduct of software development rather than the product itself. Open source code libraries often contain a testing harness to allow contributors to ensure their changes do not cause regression bugs in the code library.
Much of what are considered artifacts is software documentation.
In end-user development an artifact is either an application or a complex data object that is created by an end-user without the need to know a general programming language. Artifacts describe automated behavior or control sequences, such as database requests or grammar rules,[1] or user-generated content.
Artifacts vary in their maintainability, which is primarily affected by the role the artifact fulfills. The role can be either practical or symbolic. In the earliest stages of software development, artifacts may be created by the design team to serve a symbolic role to show the project sponsor how serious the contractor is about meeting the project's needs. Symbolic artifacts often convey information poorly, but are impressive-looking. Symbolic artifacts are sometimes referred to in the information architecture industry[like whom?] as illuminated scrolls, because the decorations do nothing to enhance understanding. Generally speaking, symbolic artifacts are also considered unmaintainable due to the diligence it requires to preserve the symbolic quality. For this reason, once symbolic artifacts are shown to the project sponsor and approved, they are replaced by artifacts which serve a practical role. Practical artifacts usually need to be maintained throughout the project lifecycle, and, as such, are generally highly maintainable.
Artifacts are significant from a project management perspective as deliverables. The deliverables of a software project are likely to be the same as its artifacts with the addition of the software itself.
The sense of artifacts as byproducts is similar to the use of the term artifact in science to refer to something that arises from the process in hand rather than the issue itself, i.e., a result of interest that stems from the means rather than the end.
To collect, organize and manage artifacts, a software development folder may be utilized.
See also
[edit]References
[edit]- ^ H. Lieberman; B. A. Nardi; D. Wright (April 1998). Grammex: Defining grammars by example. ACM conference on Human Factors in Computing Systems (Summary, Demonstrations; CHI 1998). Los Angeles, California, U.S.: ACM Press. pp. 11–12. doi:10.1145/286498.286504.
Further reading
[edit]- Per Kroll; Philippe Kruchten (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison-Wesley Professional. ISBN 978-0-321-16609-8.
Artifact (software development)
View on Grokipediafrom Grokipedia
In software development, an artifact refers to any tangible or intangible byproduct produced during the creation of software, including source code, design documents, executables, data models, prototypes, and workflow diagrams.[1] These artifacts emerge across various stages of the development lifecycle, from requirements gathering to deployment, and serve as essential records of the system's architecture, design, and functionality.[2] They are critical for facilitating team collaboration, enabling version control, supporting testing and quality assurance, and aiding in maintenance and scalability efforts.[3] In modern practices like agile and DevOps, artifacts are often stored in repositories for automated pipelines, ensuring traceability and reproducibility in continuous integration and delivery processes.[4]
Overview
Definition
A software artifact is any tangible or intangible item produced as a byproduct during the software development lifecycle, intended to describe, implement, or support the architecture, design, function, or deployment of software.[3][5] These artifacts exhibit key characteristics such as being versioned to track changes, traceable to related elements in the development process, and evolving iteratively as the project progresses.[1][6] For instance, source code serves as a primary artifact representing the implementation, while derived items like executables embody the functional output.[4] In software engineering, artifacts refer to purposeful, engineered outputs integral to systematic processes, distinct from archaeological artifacts which are historical relics without such developmental intent.[3] The term originated in structured methodologies during the late 1990s, notably with the Rational Unified Process (RUP), and was formalized in the Unified Modeling Language (UML) 1.0 specification adopted in 1997.[7][8]Historical Development
The concept of software artifacts in software development originated in the 1970s and 1980s, amid the rise of structured programming and efforts to address the software crisis through formalized documentation practices. As software systems grew more complex, the need for tangible by-products like requirement specifications, design documents, and test plans became evident to ensure traceability and quality. A pivotal standard in this era was IEEE Std 829-1983, which defined a set of basic documents for software testing, including test plans, test designs, and test reports, to support the dynamic execution of procedures and verification of software functionality.[9] The 1990s marked key milestones in formalizing artifacts within object-oriented and lifecycle frameworks, driven by influential figures such as Grady Booch and Ivar Jacobson. Booch's seminal book Object-Oriented Design with Applications (1991) outlined methods for object-oriented system design, emphasizing artifacts like class diagrams and module charts to model structure and behavior, thereby promoting reuse and modularity.[10] Building on this, Booch, Jacobson, and James Rumbaugh collaborated at Rational Software to develop the Unified Modeling Language (UML) in 1997, a standardized notation for specifying, visualizing, and documenting software artifacts to bridge analysis and implementation.[11] Jacobson's earlier work on use case-driven development, introduced in his 1992 book Object-Oriented Software Engineering, further shaped artifact practices by focusing on behavioral models derived from user requirements.[12] The Rational Unified Process (RUP), formalized in 1998, integrated UML into an iterative process framework that produced and managed artifacts across disciplines like requirements, analysis, and design.[13] Concurrently, ISO/IEC 12207 (published 1995 and revised in 2008) provided a global standard for software lifecycle processes, defining activities that generate artifacts from acquisition through retirement to ensure consistency across development stages.[14] In the post-2000 era, evolving methodologies shifted the role of artifacts toward efficiency and automation. The Agile Manifesto, published in 2001 by a group of software leaders including Jacobson, prioritized working software over comprehensive documentation, advocating for lightweight artifacts like user stories and backlogs to foster collaboration while minimizing overhead. This agile influence persisted into the 2010s with the emergence of DevOps, where practices emphasized binary artifacts—such as compiled executables and container images—integrated into continuous integration/continuous delivery (CI/CD) pipelines to enable rapid, reliable deployments. Complementing these shifts, the Capability Maturity Model Integration (CMMI) version 1.0, released in 2000 by the Software Engineering Institute, incorporated artifact management into its process areas for assessing and improving software development maturity, drawing on prior models to align artifacts with organizational goals.Classification
Engineering Artifacts
Engineering artifacts in software development refer to the tangible technical outputs produced during the design, implementation, and deployment phases, serving as the foundational elements for constructing executable software systems. These artifacts encapsulate the core technical specifications and implementations that enable the realization of software functionality, distinguishing them from administrative or planning documents.[1] Core types of engineering artifacts include source code, which forms the human-readable instructions in programming languages; UML diagrams such as class diagrams for structural modeling, sequence diagrams for interaction flows, and deployment diagrams for system distribution; executable binaries that result from compilation; configuration files that define runtime parameters; and APIs that specify interfaces for component interactions.[15][16][1] In the design phase, engineering artifacts often manifest as use case models outlining user interactions and architectural blueprints depicting high-level system structures, providing a blueprint for subsequent implementation. During the implementation phase, these evolve into compiled libraries, such as JAR files in Java environments, and automation scripts that facilitate build and deployment processes.[17][3] These artifacts are typically executable or model-based, meaning they can be directly interpreted by machines or tools to produce working software components, and they are frequently generated or edited using integrated development environments (IDEs) like Eclipse or Visual Studio. In continuous integration pipelines, engineering artifacts constitute the primary "build" outputs, such as binaries and packaged deployments, which are versioned and tested iteratively to ensure system integrity.[1][4] Engineering artifacts align with established standards for consistency and interoperability, particularly UML 2.5 (2015), which defines a graphical notation for specifying and documenting modeling artifacts like diagrams and deployment configurations in object-oriented systems. Additionally, they adhere to IEEE 1471 (2000), now evolved into ISO/IEC/IEEE 42010:2022, which provides a framework for architectural descriptions as concrete artifacts representing system viewpoints and models.[18][19]Management Artifacts
Management artifacts in software development encompass the documents, templates, and outputs that facilitate planning, monitoring, and control of the development process, ensuring alignment with project objectives and stakeholder expectations.[20] These artifacts support governance by providing a structured record of decisions, progress, and compliance, distinct from technical elements by focusing on process oversight rather than implementation details. They are essential for coordinating teams, mitigating uncertainties, and demonstrating accountability throughout the software lifecycle. Core types of management artifacts include requirements specifications, which outline stakeholder needs and system functionalities; project plans, which detail timelines, resources, and milestones; risk assessments, which identify potential threats and mitigation strategies; test plans, which define testing scopes and criteria; and user manuals, which provide guidance for end-users post-deployment.[20] Requirements specifications serve as the foundational reference for development, while project plans allocate efforts across phases. Risk assessments, often in the form of registers, prioritize issues based on likelihood and impact. Test plans ensure systematic validation, and user manuals bridge the gap between delivery and operational use. Specific examples illustrate their application: the Software Requirements Specification (SRS) follows ISO/IEC/IEEE 29148:2018, recommending a structured format with sections on purpose, scope, definitions, and specific requirements to promote clarity and verifiability.[21] Gantt charts, used in project plans for scheduling, visualize task dependencies and durations on a timeline to track progress in software projects.[22] Traceability matrices link requirements to design elements, code implementations, and tests, enabling verification that all needs are addressed and facilitating change impact analysis.[23] These artifacts are primarily textual or tabular in nature, designed for ease of review, revision, and sharing among stakeholders to support compliance with regulatory or contractual obligations and to enhance communication across distributed teams.[24] They evolve iteratively, starting from high-level overviews in early phases—such as preliminary risk assessments—and progressing to detailed versions, like comprehensive test plans, as the project advances and more information becomes available. This progression ensures adaptability while maintaining a historical audit trail for post-project reviews. Management artifacts align with established standards for quality and project governance, including ISO 9001:2015 for quality management systems, which, through guidelines in ISO/IEC 90003:2018, mandates documented plans and records tailored to software processes to achieve consistent outcomes and customer satisfaction.[24] Similarly, the PMBOK Guide (7th edition, 2021) from the Project Management Institute categorizes them as key deliverables, such as charters and risk registers, to support effective project delivery in software contexts.[20] These ties promote standardized practices that reduce variability and enhance project success rates.Role in Software Processes
In Traditional Methodologies
In traditional software development methodologies, such as the waterfall model, artifacts are generated sequentially across distinct phases to ensure a structured progression from requirements to maintenance. During the requirements phase, the primary artifact is the Software Requirements Specification (SRS) document, which outlines functional, non-functional, and quality requirements derived from stakeholder needs.[25] In the design phase, artifacts include detailed design documents like data flow diagrams (DFDs), which model the system's processes, data movements, and component interactions to guide architectural decisions.[25] The implementation phase produces source code modules and associated configuration items, translating the design into executable software components.[25] Testing artifacts, standardized under IEEE 829, encompass test plans, cases, procedures, logs, and reports to verify functionality through unit, integration, and system-level testing. Finally, the maintenance phase generates change logs, modification requests, and updated documentation to track enhancements, bug fixes, and impact analyses.[25] The process flow in these methodologies emphasizes linear advancement, where artifacts are produced in sequence and subjected to formal reviews at phase gates, such as requirements reviews for validation and design inspections for anomaly detection.[25] These reviews, often managed by a Configuration Control Board (CCB), ensure completeness, traceability, and compliance before transitioning to the next phase, with customer approvals serving as milestones.[25] This approach prioritizes comprehensive documentation to establish baselines, facilitating auditability and contractual adherence in large-scale projects. One advantage of this artifact-centric process is enhanced traceability from requirements through to deployment, promoting predictability and suitability for environments with stable requirements.[25] However, it can result in outdated artifacts if requirements change mid-process, leading to inflexible rework and high costs due to late defect discovery.[25] Historically, these practices were formalized in defense software projects under DoD-STD-2167A (1988), which mandated extensive artifact sets—including detailed SRS, design specifications, and test documentation—for mission-critical systems to enforce rigorous quality and configuration management.[26]In Agile and DevOps
In Agile methodologies, artifacts emphasize minimal viable documentation to support iterative development and rapid feedback, prioritizing working software as the core deliverable over exhaustive specifications. The Agile Manifesto explicitly values "working software over comprehensive documentation," positioning executable code as the primary artifact that demonstrates progress and value to stakeholders.[27] This shift reduces reliance on traditional documents like full software requirements specifications (SRS), favoring lightweight alternatives such as user stories, which capture user needs in concise, prioritized formats to guide development without extensive elaboration.[28] Key Agile artifacts include the product backlog and sprint backlog, which serve as dynamic, ordered lists of work items refined collaboratively by the team. The product backlog, managed by the product owner, represents an emergent plan for product evolution, while the sprint backlog outlines selected items and an actionable plan for a specific iteration, ensuring focus on achievable goals.[29] During sprint reviews, teams inspect the increment—a potentially shippable product version—and adapt the product backlog based on feedback, integrating artifacts into short cycles (typically 1-4 weeks) to foster continuous improvement. Burndown charts, though not official artifacts in the Scrum framework, are widely used by practitioners to visualize remaining work versus time, aiding transparency in sprint progress.[30] In the Scrum framework, originally outlined in 1995 and updated in the 2020 guide, these artifacts promote adaptability by evolving through refinement and inspection rather than rigid upfront planning.[29] DevOps extends Agile principles by incorporating binary artifacts into continuous integration and continuous delivery (CI/CD) pipelines, enabling automated builds, testing, and deployments for faster release cycles. Examples include Docker container images, which package applications and dependencies for consistent runtime environments, and Helm charts, which define Kubernetes deployments as OCI-compliant artifacts to streamline orchestration in cloud-native settings.[31] Infrastructure as code (IaC) further treats configuration files, such as Terraform scripts, as versioned artifacts that declaratively provision and manage resources, ensuring infrastructure aligns with application needs through automation.[32] Artifacts in Agile and DevOps processes are versioned within sprints or releases using tools like Git, which integrates with backlogs and pipelines to track changes and maintain a single source of truth. This versioning supports reproducibility by enforcing deterministic builds in CI/CD, where identical inputs yield consistent outputs, minimizing deployment risks and enhancing reliability across environments. The focus on deployment readiness is evident in practices like GitOps, where declarative configurations in Git repositories automatically reconcile desired states with live systems, automating artifact management for infrastructure and applications in production.[33]Management and Tools
Artifact Repositories
Artifact repositories are specialized storage systems designed to manage, version, and distribute software artifacts generated during the development lifecycle, such as compiled binaries, libraries, and packages. These repositories serve as centralized or distributed hubs that facilitate collaboration across development teams, CI/CD pipelines, and deployment environments by providing reliable access to artifacts while ensuring reproducibility and consistency in builds. Unlike source code repositories, which focus on textual files, artifact repositories handle immutable binary outputs to support efficient sharing and reduce redundant builds.[34][35] There are primarily two types of artifact repositories: binary-specific repositories tailored for particular formats, such as JAR files in Java ecosystems or npm packages in Node.js environments, and universal repositories that support multiple package formats including Docker images, Python wheels, and NuGet packages. Binary repositories optimize storage and retrieval for domain-specific needs, while universal ones offer flexibility for polyglot development teams managing diverse technologies. Prominent examples include JFrog Artifactory, which provides universal support across over 30 package types, and Sonatype Nexus Repository, known for its robust handling of Maven and npm artifacts.[35][34][36] Key features of modern artifact repositories include metadata tagging for tracking artifact provenance and dependencies, fine-grained access controls to enforce role-based permissions, and integrated vulnerability scanning to detect known security issues in stored components. These systems often integrate seamlessly with build tools like Apache Maven and Gradle, allowing automated publishing and resolution of artifacts during the build process. For instance, repositories can attach metadata such as build timestamps or scan results to artifacts, aiding in compliance and auditing.[37][38][6] The concept of artifact repositories emerged prominently with the release of Apache Maven 1.0 in 2004, which introduced standardized dependency management and remote repository protocols to address the fragmentation in Java build environments. This evolution has since aligned with security standards from the Open Web Application Security Project (OWASP), particularly in guidelines for artifact integrity validation to mitigate supply chain risks in CI/CD pipelines. These repositories complement version control systems by focusing on built outputs rather than source files.[39][40][41]Version Control Integration
Version control integration enables the tracking and evolution of software artifacts, such as source code, binaries, and documentation, by leveraging systems that record changes over time. Git, created in 2005 by Linus Torvalds to manage Linux kernel development, has emerged as the dominant distributed version control system due to its efficiency in handling non-linear workflows. Core mechanisms include branching to create parallel development lines, merging to integrate changes from those branches, and tagging to mark significant points like releases.[42] For binary artifacts, which are inefficient to version directly in Git due to their size, Git Large File Storage (LFS) extends the system by replacing large files with lightweight text pointers while storing the actual content on a remote server, maintaining the standard Git workflow.[43] Artifacts are integrated with version control through direct linkages to commits, ensuring traceability. For instance, Git tags—lightweight or annotated pointers to specific commits—can denote release points, embedding commit hashes into build artifacts for verification.[42] This allows teams to associate generated binaries or packages with exact code states. Text-based artifacts, such as documentation in Markdown or reStructuredText, benefit from Git's delta compression, which stores only differences between versions in pack files, optimizing storage and retrieval for iterative updates. A key challenge addressed by version control integration is reproducibility, achieved by pinning artifacts to specific versions via tags or commit references, preventing drift in dependencies or builds.[44] Semantic Versioning (SemVer) 2.0.0, released in 2013, provides a standardized scheme for artifact releases using MAJOR.MINOR.PATCH numbering: major increments for incompatible changes, minor for backward-compatible additions, and patch for bug fixes, facilitating predictable evolution and dependency management.[45] Platforms like GitHub and GitLab support these workflows by automatically generating and linking artifacts to commits during continuous integration, with features for uploading build outputs tied to workflow runs.[46] Similarly, Jenkins, an open-source CI tool, generates versioned build artifacts using thearchiveArtifacts step, fingerprinting files to track origins and enable reproducible pipelines.[47]