An artifact can be thought of as a tangible component or document that imparts a structured format of performing a task. In the context of software, an artifact could be a use case, class diagram and UML diagrams which are used to depict the way a system must function.
What is Baseline Artifact?
The term Baseline Artifact is a part of ‘configuration management’. Baselining means laying the foundation upon which software development activities depend. In simplest of terms, baselining an artifact means updating the version number of the artifact document during the process of development.
A software or technical baseline thus consists of:
Requirement Specifications.
UML Diagrams.
Standards For Developing a Software.
Models and Simulation
Baselining an artifact typically comprises of the following types of activities:
Artifacts are allocated to an individual depending upon the task that are to be performed.
When there’s some change in the artifact, the version number within it is also changed.
When review of an artifact is done, that is, all defects have been covered or fixed, the baseline is updated with the date and version number.
When the artifact is integrated with the product, the integration tests helps to unravel the defects, so that they can be fixed at that time.
When all the artifacts are finished the same is approved and sent for delivery to the client.
Baseline Artifact Document:
Name of Artifact: Specific document file name.
Development Baseline Date: The due date by which development shall be completed
Development Baseline Version: Name of the specific version completed so far and approved
Testing Baseline Date: Date on which testing has been completed including fixing of defects
Testing Baseline Version: Version number that has been updated and approved
Integration Baseline Date: The date on which integration of modules have been completed and approved
Integration Baseline Version: The version number that has been completed in terms of meeting integration criteria and approved
Delivery Baseline Date: The date on which delivery of an artifact to the customer is approved
Delivery Baseline Version: The version that is ready for delivery to the customer
Categories of Configuration Baselines:
A baseline is a way to manage changes in hardware, software and firmware in the context of software development, the term for which is 'Configuration Management'.
The technical baseline is thus categorised as:
Functional Baseline: This document intends to outline the functional specifications of a software. Technically, a functional baseline specification is reviewed under System Functional Review which outlines the detailed description of functional deliverables.
Allocated Baseline: This is the baseline that consists of defining the items which includes functional and interface characteristics. The term ‘allocated’ is used in this context because requirement specifications are distributed across the various levels. The idea is to map higher and lower level configuration items with derived requirements, interface requirements and various other components that are essential with regard to accomplishment of development objectives.
Allocated baseline’s configuration items are the ones that need to be verified and validated against the desired performance criteria.
Product Baseline:: This document describes functional and physical characteristics of a configuration item. Functional and physical features for a product is meant for acceptance testing including those tests that are important from deployment, operation, support and training point of view.
Why Baseline at all?
Baselining helps to determine factors which need a close attention in the context of achieving the desired requirements. Therefore there are few factors which should be taken into consideration before listing 'requirements baseline'.
Business Rules: Determine whether all the business rules have been identified that apply to system's functioning.
Change control: There must be a back-up plan in order to implement changes during the process of testing and defect correction. We may opt for a change control tool that aids in planning, configuring and implementing a certain change.
Perspective of Customers:Customers are the prime actors in defining artifacts with regard to a software development project. It is to be identified whether the prerogatives for baselining requirements have been met from the end users perspective, which must take into account – how business rules play a major role, whether there has been requisite modifications in the rules of late, change in needs be identified or not.
Interfaces: Determine whether user interfaces are defined as per the desired functionality.
Prototypes: Has the prototypes been prepared in accordance to the requirement specifications.
Alignment: Aligning project requirements with the business objectives, is very important. Both objectives must proceed in parallel for an efficient and successful development project.
Reviews: Baselining requirements also includes a very major aspect of verifying or reviewing the requirement specifications by designers, analysts, programmers, testers.
Scope: Identifying the scope of the project is one step towards forming the baseline.
Templates: Each section within the SRS document must be filled with details.
Verifiability: Defining the assessment criteria for validating the correctness of the development process.
Conclusion:
Software is prone to frequent changes, therefore a plan works as a foundation stone for building a constructive path towards an objective.
'Baseline artifacts' is one such concept with the help of which we strive to achieve the target.
.png)
.png)
.png)
.png)
