Upload
isabella-white
View
214
Download
1
Tags:
Embed Size (px)
Citation preview
Software Product Line (SPL)
A SPL is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
(Clements & Northrop, 2001)
Software Product Line (SPL)
Essential Activities for Software Product Lines (Clements & Northrop, 2001)
Software Product Line (SPL)
Sub-processes for Software Product Lines (Pohl et al., 2005)
Core Asset Development
Product Development
Software Product Line (SPL)
Motivation Reduction of Costs Enhancement of Quality Reduction of Time to Market
(Pohl et al., 2005)
Requirement Engineering (RE)
It requires significant effort in a project.
“Software requirements have been repeatedly recognized during the past 25 years to be a real problem.” (Lamsweerde, 2000)
“Incomplete and inconsistent requirements are some of the great factors for deficiency and cancellation of software projects.” (Chaos Report, 1994)
Requirement Engineering (RE)
In SPL is more complex: several stakeholders more products requiring attentions to variability and reuse platform
Practices Risks scope includes the wrong products essential stakeholders don't participate. wrong or inappropriate requirements inadequate domain undestanding
(Clements & Northrop, 2001; Birk et al., 2003)
Requirement Engineering (RE)
Essential Activities Elicitation Analysis and Negotiation Specification Validation Management
(Kotonya & Sommerville, 1998)
How are these activities in SPL?
Requirement Engineering (RE)
Elicitation focus in scoping; must capture anticipated variations explicitly
over the foreseeable lifetime of the SPL; involve more stakeholders.
(Clements & Northrop, 2001; Durán et al., 2003; Pohl et al., 2005)
Requirement Engineering (RE)
Analysis and Negotiation find variations and commonalities; analyze impact of new requirements in product
line architecture; identify opportunity for reuse; conflicts must be solved not only from a logical
view point, but also taking into consideration economical and market issues.
(Clements & Northrop, 2001; Durán et al., 2003; Pohl et al., 2005)
Requirement Engineering (RE)
Specification must document a product-line-wide set of
requirements and product-specific requirements
(Clements & Northrop, 2001; Pohl et al., 2005)
Requirement Engineering (RE)
Validation must check the consistency, completeness and
accuracy of the common and variable requirements.
(Clements & Northrop, 2001; Pohl et al., 2005)
Requirement Engineering (RE)
Management support the systematic assessment of how the
proposed changes will impact the product line; traceability links between requirements and their
associated core assets.
(Clements & Northrop, 2001)
Requirement Engineering (RE)
Different SPL situations that influence the RE: Starting situations Market orientation Product type Domain maturity Domain stability SPL Architecture Organizational size
(Birk et al, 2003)
SPL Approaches
Review - Research questions
Q1.What activities, techniques and methods of requirement engineering are adopted in each software product line approach?
Q2. Does the approach have a technology and/or socio-organizational viewpoint?
SPL ApproachesReview - Selected approaches:
FODA (1990) [Kang et al., 1990] FAST (1997) [Gupta et al., 1997; Weiss, 1997] FORM (1998) [Kang et al., 1998] PULSE (1999) [Bayer et al., 1999; Bayer et al., 2000; John et al., 2006] SEI’s Framework (1999) [Clements & Northrop, 2001; http://www.sei.cmu.edu] ODYSSEY (1999) [Braga et al., 1999] COPAM (2000) [America et al., 2000] Kobra (2002) [Atkinson et al., 2000] PLUS (2005) [Gomma, 2005] SPLE Framework (2005) [Pohl et al., 2005] RiDE (2007) [Almeida, 2007]
SPL Approaches
RE essential activities summary
0%
20%
40%
60%
80%
100%
Elicitation Analysis Specification Validation ManagementNo definedDefinedPartially defined
SPL Approaches
Approaches viewpoints
Approaches' Viewpoint
1
10
0
Both
Technology
Socio-organizational
RE Methods for SPL Viewpoint-based Goal-based Scenario and goal-based Feature-oriented Use case-based Orthogonal variability
RE Methods for SPLViewpoint-based
Viewpoints are an explicit mechanism which takes into account the different system and problem perspectives of different stakeholders.
(Kotonya & Sommerville, 1998)
RE Methods for SPLViewpoint-based
Product Line Stakeholder Viewpoint Approach
Stakeholders views Management View Reuse Team View Products developers View
Viewpoints' Development Process Viewpoint Identtfication Viewpoint Structuring Viewpoints Documentation
(Jaber et al., 2000)
(Jaber et al., 2000)
RE Methods for SPLViewpoint-based
Viewpoint-Oriented Domain Requirements Definition (VODRD)
(Mannion et al., 1998)
(Jaber et al., 2000)
RE Methods for SPLGoal-based
The goal means the direction, purpose, and objective of the organization. (Kim et al., 2006)
RE Methods for SPLGoal-based
Goal-based Variability Acquisition and Analysis
(Liaskos et al., 2006)
Variability example
RE Methods for SPLScenario and goal-based
Scenarios show the behavior of system.(Kim et al., 2006)
(Liaskos et al., 2006)
RE Methods for SPL
Goal and Scenario Modeling
(Kim et al., 2006)The relationship between goal, scenario and use case.
Scenario and goal-based
The structure of goal and scenario modeling process.
RE Methods for SPL
Features are the attributes of a system that directly affect end-users. (Kang et al., 1990)
Feature-oriented
RE Methods for SPLUse case-basedProduct Line UML-Based Software Engineering (PLUS)
Reuse Category: optional, mandatory (kernel), alternative
Variation point (small variation) Name Type of functionality (optional, mandatory alternative, optional alternative) Line number(s) Description of functionality.
Extend and Include Relationship (several variability)
(Gomma, 2005)
(Gomma, 2005)
RE Methods for SPLUse case-based
PuLSE CaVE (Commonality and Variability Elicitation)
(Fantechi et al, 2003)
RE Methods for SPLUse case-based
PuLSE CaVE (Commonality and Variability Elicitation)
(Fantechi et al, 2003)
Conclusion The RE process is not well defined in the found
approaches Requirements analysis was the activity best defined
in these studies. Several gaps in definition of guidelines for capturing
of requirements. Requirement management is the more critical. Multiple viewpoints is, in general, overlooked. Due to the complex and evolutionary nature of SPL
development, it is essential to have a systematic requirements engineering process.
Conclusion Methods with abstraction high-level
feature-oriented and goal-based Integration of methods to represent different
viewpoints. Selection of methods depends of the SPL context
ReferencesClements, P. & Northrop, L., 2001, Software Product Lines: Practices and Patterns, Addison-Wesley.
Pohl, K.; Böckle, G. & van der Linden, 2005, Software Product Line Engineering: Foundations, Principles, and Techniques, Springer.
van Lamsweerde, A., 2000, Requirements engineering in the year 00: a research perspective, in 'International Conference on Software Engineering', pp. 5-19.
Chaos Report 1994. Software Development Report, The Standish Group, West Yarmouth, MA, access in http://www.standishgroup.com.
Birk, A.; Heller, G.; John, I.; Joos, S.; Müller, K.; Schmid, K. & Maßen, T. v. d., 2003, 'Report of the GI Work Group "Requirements Engineering for Product Lines"', Technical report, Fraunhofer EPrints [http://publica.fraunhofer.de/eprints.har] (Germany).
Kitchenham, B., 2004, "Procedures for Performing Systematic Reviews," Joint Technical Report, Keele University TR/SE-0401 and ICTA 0400011T.1.
Kang, K. C.; Cohen, S. G.; Hess, J. A.; Novak, W. E. & Peterson, A. S. (1990),'Feature-Oriented Domain Analysis (FODA) Feasibility Study', Technical report, Carnegie-Mellon University Software Engineering Institute.
Gupta, N. K.; Jagadeesan, L. J.; Koutsofios, E. E. & Weiss, D. M. (1997),Auditdraw: Generating Audits the FAST Way, in 'RE '97: Proceedings of the 3rd IEEE International Symposium on Requirements Engineering (RE'97)', IEEE Computer Society, Washington, DC, USA, pp. 188.
Weiss, D. (1997),'Defining Families: The Commonality Analysis', submitted to IEEE Transactions on Software Engineering.
Kang, K. C.; Kim, S.; Lee, J.; Kim, K.; Shin, E. & Huh, M. (1998),FORM: A feature-oriented reuse method with domain-specific reference architectures, in , J. C. Baltzer AG, Science Publishers, Red Bank, NJ, USA, pp. 143-168.
ReferencesBayer, J.; Flege, O.; Knauber, P.; Laqua, R.; Muthig, D.; Schmid, K.; Widen, T. & DeBaud, J.
(1999),PuLSE: A Methodology to Develop Software Product Lines, in 'ACM SIGSOFT Symposium o Software Reusability (SSR'99)', pp. 122-131.
Bayer, J.; Muthig, D. & Widen, T. (2000),Customizable Domain Analysis, in 'Proceedings of the First International Symposium on Generative and Component-Based Software Engineering (GCSE '99)', Springer-Verlag, London, UK, pp. 178--194.
Fantechi, A.; Gnesi, S.; John, I.; Lami, G. & Dörr, J. (2003),Elicitation of Use Cases for Product Lines, in 'Software Product-Family Engineering, 5th International Workshop, PFE 2003, Siena, Italy', pp. 152-167.
John, I.; Knodel, J.; Lehner, T. & Muthig., D. (2006),A Practical Guide to Product Line Scoping, in , pp. 3-12
Braga, R. M. M.; Werner, C. M. L. & Mattoso, M. (1999),Odyssey: A Reuse Environment based on Domain Models, in 'ASSET '99: Proceedings of the 1999 IEEE Symposium on Application - Specific Systems and Software Engineering and Technology', IEEE Computer Society, Washington, DC, USA, pp. 50.
America, P.; Obbink, J. H.; van Ommering, R. C. & van der Linden, F. (2000),CoPAM: A component-oriented platform architecting method family for product family engineering, in 'SPLC', pp. 167-180.
Atkinson, C.; Bayer, J.; Bunse, C.; Kamsties, E.; Laitenberger, O.; Laqua, R.; Muthig, D.; Paech, B.; Wüst, J. & Zettel, J., Component-based product line engineering with UML, Addison-Wesley, Boston, MA, USA, 2002.
Gomaa, H., Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, 2005.
Almeida , E. S. RiDE: The RiSE Process for Domain Engineering, Ph.D. Thesis, Federal University of Pernambuco, Recife, Pernambuco, Brazil, May, 2007.
ReferencesKotonya, G. & Sommerville, I. (1998), Requirements Engineering: Processes and Techniques, John
Wiley & Sons, Inc. New York, NY, USA.
Durán, A.; Benavides, D. & Bermejo, J. (2003), Applying System Families Concepts to Requirements Engineering Process Definition, in 'PFE', pp. 140-151.
Jaber, K.; Nada, N. & Rine, D. (2000), Product line stakeholder viewpoint approach and validation model, in 'SAC '00: Proceedings of the 2000 ACM symposium on Applied computing', ACM, New York, NY, USA, pp. 871--875.
Mannion, M.; Keepence, B. & Harper, D. (1998),Using Viewpoints to Define Domain Requirements, IEEE Computer Society Press, Los Alamitos, CA, USA, pp. 95--102.
Liaskos, S.; Lapouchnian, A.; Yu, Y.; Yu, E. & Mylopoulos, J. (2006),On Goal-based Variability Acquisition and Analysis, in 'RE '06: Proceedings of the 14th IEEE International Requirements Engineering Conference (RE'06)', IEEE Computer Society, Washington, DC, USA, pp. 76--85.
Kim, J.; Kim, M. & Park, S. (2006),Goal and scenario based domain requirements analysis environment, Elsevier Science Inc., New York, NY, USA, pp. 926--938.