The AGILE SOFTWARE PRODUCT LINE AUTOMOTIVE - ASSESSMENT MODEL




Purpose

The purpose of Scoping is to identify the reuse assets that should be developed in a software product line. This includes the identification of products and features that should be part of the product line and the definition of common and variable features.


Outcomes

Process related Outcome - Base Practices - Work Products

ProcO_02.01 An adequate scoping process is established.
BP_ProcO_02.01 Set up a scoping meeting. Ensure that scoping meetings are implemented. They are implemented in a recurrent and defined timeframe to prioritize and categorize new required software parts. In the scoping meetings, it is determined, if the feature is part for the common baseline or a product/market specific feature.
A_04-03 Domain model
A_08-12 Project Plan
A_09-03 Reuse policy
A_13-04 Communication record
A_13-04 Review plan
A_13-04 Meeting support record
A_13-04 Documentation Plan
A_13-04 Configuration management record
A_13-04 Progress status record
A_13-04 Proposal review record
A_15-07 Reuse evaluation report
ProcO_02.02 Rapid changes in requirements are considered and handled by the scoping process.
BP_ProcO_02.02 Consider rapid changes in requirements in scoping meetings. Ensure that rapid changes in requirements are considered in the scoping meetings each time, even the original feature was already assigned and prioritized for the development.
A_08-28 Change Management Plan
A_13-16 Change request
ProcO_02.03 Critical errors of high priority are handled in a privileged way by the scoping process.
BP_ProcO_02.03 Allow situational extraordinary scoping meetings. Ensure that important and necessary features, which could become showstoppers, are scoped in extraordinary scoping meetings and the backlog is adjusted accordingly.
ProcO_02.04 Critical but feasible and noncritical features are scoped in a faster pace.
BP_ProcO_02.04 Permit low hierarchy levels to scope features. Ensure that scoping can be conducted on low hierarchy levels and results are published to all involved parties.
ProcO_02.05 Software requirements are assigned to software units in the scoping process.
BP_ProcO_02.05 Assign required new functionality to the software units. Ensure that required functionality is developed in the most suitable software units and prevent unnecessary double implementation of new functionality..
A_04-02 Domain architecture
A_04-06 System architectural design
A_17-03 Stakeholder requirements
ProcO_02.06 Software parts that are procured from suppliers are identified in the scoping process.
BP_ProcO_02.06 Identify software units which are supplied and implemented by the supplier. Ensure the identification of software units which is procured by suppliers.
A_02-01 Commitment/ Agreement
A_04-02 Domain architecture
ProcO_02.07 Similarities of software features are identified in the scoping process.
BP_ProcO_02.07 Identify similarities of desired software features. Ensure that a twofold development of one feature is avoided and grant a time for refactoring to make the similar features compatible with the software baseline development.
A_04-04 Software architectural design
A_14-09 Work breakdown structure
ProcO_02.08 Common software parts for different products are identified.
BP_ProcO_02.08 Identify software units for potential reuse. Ensure the application of the reuse strategy.
A_04-04 Software architectural design
A_08-17 Reuse plan
A_08-17 Reuse proposal
A_09-03 Reuse policy
A_14-09 Work breakdown structure
A_19-05 Reuse Strategy
A_19-05 System requirements specification
ProcO_02.09 Incompatibilities between software features are revealed.
BP_ProcO_02.09 Identify incompatible desired software features. Ensure that incompatible features are resolved and grant a time for refactoring to make the features compatible with the software baseline development.
A_04-04 Software architectural design
A_14-09 Work breakdown structure
ProcO_02.10 Features are prioritized and assigned to (market-) specific products.
BP_ProcO_02.10 Prioritize required new software parts. Ensure that for every feature a priority is assigned and a market-specific backlog is defined for the implementation in the next increment.
A_04-04 Software architectural design
A_08-12 Project Plan
A_08-17 Reuse plan
A_08-17 Reuse proposal


Product related Outcome - Process Attributes - Work Products

ProdO_02.01 A high amount of reusable software elements is achieved.
PA_ProdO_02.01 Reusable software units shall be defined. Ensure that software parts which can be reused are identified and required new functionality is first checked against existing functionality to ascertain that the functionality is not implemented already in another software variant, by means of scoping meetings.
A_08-17 Reuse plan
A_08-17 Reuse proposal
A_09-03 Reuse policy
A_15-07 Reuse evaluation report
A_19-05 Reuse Strategy
A_19-05 System requirements specification
ProdO_02.02 Results and decisions resulting from scoping meetings are stored in backlogs.
PA_ProdO_02.02 New software units shall be prioritized before implementation. Ensure that a priority value is assigned to each feature which identifies the priority for the implementation in the next increment, by means of an ordered list within a backlog.
A_08-12 Project Plan
A_11-04 Product release information
A_11-04 Product release package
A_13-08 Baseline
A_13-08 Delivery record
ProdO_02.03 A priority level is assigned to features.
PA_ProdO_02.03 A priority value for software features shall be assigned. Ensure that the features are rated and a priority value is assigned, by means of assigning the priority value in the requirement specification of the feature.
A_15-01 Analysis Report
A_15-01 Risk analysis report
ProdO_02.04 A critically level is assigned to features.
PA_ProdO_02.04 A critically value for the software feature shall be assigned. Ensure that the features are rated and a critically value is assigned, by means of assigning a critically value in the requirement specification of the feature.
A_15-01 Analysis Report
A_15-01 Risk analysis report