Furthermore, architecture pro- uct line engineering is an essential activity for improving cess maturity assessment determines the current status of the the overall software product line engineering process in an architectural dimension of the software product line engi- organization. The general objective of a maturity assess- neering process in an organization. The assessment process ment model in software engineering is twofold. First, it yields a number of recommendations based on the identi- provides mechanism to perform assessment and second it fication of weaknesses in the current process for improve- provides further guidelines to introduce changes in the cur- ment.
Ideally, after the assessment process the improvement rent process to make improvements. The software product guidelines highlight changes in current software product line line engineering process like others requires improvements engineering process to introduce improvements based on the over time.
However, it is very difficult to develop an effi- assessment activities. However, the maturity model presented cient and effective improvements plan unless it is based on in this work does not provide any guidelines for the improve- the results of a comprehensive assessment exercise. Fig- ment process, which we consider as a future project for this ure 2 illustrates the framework of a comprehensive archi- study.
The over- 3. They are blended into The functional configuration of the APMM of a SPL con- the software product line engineering process and can be sists of six key architecture process activities. Specifically, used as indicators for the process assessment of architec- Table 1 defines the hierarchy and domains of the APMM of a ture dimension of software product line engineering.
For SPL. Key architecture they contribute to the development and management of the process activities SPLA. Architecture design 1 Domain engineering 2 Requirements management 3. Each questionnaire contains a number of state- evaluation, and architecture artifact management. We divided ments that are divided into six key architecture process activ- these six architecture process activities into a set of three ities. In comparison, with each statement in the questionnaire. All questionnaires Hofmeister et al.
The ture analysis, and evaluation activities. Throughout the rest of iability management of product line architecture. Ahmed this paper, abbreviations for each key process activity will and Capretz [1] conducted an empirical investigation and be used. These include domain engineering DE , require- found that these six architecture process activities have pos- ments management and modeling RMM , commonality itive impact on the performance of software product line management CM , variability management VM , architec- development in an organization.
This empirical investiga- ture analysis and evaluation AAE , and architecture artifact tion motivates the inclusion of these six architecture pro- management AAM. The following sub-sections describe cess activities into this maturity model development. These the characteristics of an organization dealing with the SPL. In describing the mea- S. K analysis techniques. In an organization at this level, there is a lack APA. Furthermore, there is no evidence that the organization performs SPL engineering activities in a coordinated way.
Also, there is no defined protocol to switch from a single product to a line of products that share APA. The following measuring instru- vidual product level.
The organi- S. At this earlier stage, the organization is concen- needed basis. The organization understands the significance of modeling architectural structures and patterns and is currently develop- APA. Furthermore, the organization understands the importance S.
Also, there are uct levels. Capretz The organization is not maintaining the appropriate docu- APA. The measuring ment of the variability among products. SPLA requirements S. The strategic S. SPLA requirements are identified and documented as Requirements, but there is a lack of technical a result of sufficient knowledge about the domain.
The orga- knowledge for developing architectural models. Subsequently, the organiza- APA. Specifically, the commonality and guidelines or a well-documented methodology to variability among products are explicitly identified in the evaluate the SPLA.
The organization has established clear S. Accordingly, the employees are trained with the required knowledge of a SPLA methodology. Overall, the APA. The subsequent measuring instru- S. The organization at this level is able to of product lines. The organization develops and manages variability and commonality models to introduce controlled APA.
Furthermore, the organization explicitly S. The components description, interface the SPLA. Effective to analyze the structure of and interconnection communication channels are present in the organization in among the SPLA components. The organization S. The organizational structure supports SPL S. Also, the process activities among various departments and sub APA. The resulting measuring instrument illustrates the set of statements that apply to an organization S.
Capretz APA. At this level, the SPLA plays an integral models to introduce controlled variability among role in the business of the organization. There is strong evi- successive products.
Cross-functional APA. The S. SPLA process methodology and avoids making future mis- S. Hence, learning and acquiring new knowledge about metrics to evaluate the performance of the SPLA. Domain S. The evaluation. SPLA requirements are regularly reviewed and updated when necessary. Furthermore, the effective commonality manage- APA. The organization regularly conducts market reviews and uses S. They also support innovation in the SPLA product specific issues rather than on issues com- and promote research and development.
The organization mon to all products. The fol- ument commonality in products. The qualitative ratings, in ing with innovative methods. These statements and their numerical value, documented. As illustrated in Table 3, the performance scales are similar to S.
We intentionally based mum amount of software reuse in the organization. Conse- S. However, we have APA. Specifically, our questionnaires take a process of managing variability among products. The structure of the rating APA.
Each of these terms is tance to variability management in the overall calculation of discussed in detail below. In this table, the values are calculated to the nearest We applied the APMM presented in this work to two orga- hundred. In doing the statements in the questionnaire are agreed upon. If NAPA so, we performed a maturity assessment on their architecture [J] is the total number of statements at the Jth maturity level, development process.
The two organizations, whose names then the pass threshold PTAPA at the Jth maturity level is are kept confidential, agreed to participate in our study. Table 6 reports the summary of the assessment results. IEEE Software, 20 6 , 52— Bosch, J. Design and use of software architectures: Adopting and evolving a product-line approach.
Reading, MA: Addison Wesley. Software product lines: Organizational alternatives. Campbell, D. Convergent and discriminant validation by the multitrait-multimethod matrix. Psychological Bulletin, 56 2 , 81— Cao, G. A systematic view of organizational change and TQM. The TQM Magazine, 12 3 , — Cattell, R. The scree test for the number of factors. Multivariate Behavioral Research, 1 , — Clements, P. On the importance of product line scope.
Project management in a software product line organization. IEEE Software, 22 5 , 54— Software product lines practices and patterns. Cohen, J. A coefficient of agreement for nominal scales. Educational and Psychological Measurement, 20 , 37— Comrey, A. A first course on factor analysis. Hillsdale: Lawrence Erlbaum Associates.
Crewson, P. Public service motivation: Building empirical evidence of incidence and effect. Journal of Public Administration Research and Theory, 7 , — Cronbach, L. Coefficient alpha and the internal consistency of tests. Psychometrica, 16 , — Dikel, D. Applying software product-line architecture. IEEE Computer, 30 8 , 49— El Emam, K. Benchmarking kappa: Inter-rater agreement in software process assessments.
Empirical Software Engineering, 4 2 , — Gordon, J. Organizational behavior: A diagnostic approach. New Jersey: Prentice Hall. Hames, R. The management myth. Sydney: Business and Professional Publishing.
Hellriegel, D. Organizational behavior. Canada: ITP Nelson. Jacobsen, I. Software reuse—architecture process and organization for business success. Jazayeri, M. Software architecture for product families: Principles and practice. MA: Addison Wesley. Jehn, K. A multi-method examination of the benefits and detriments of intra-group conflict.
Administrative Science Quarterly, 40 , — Kaiser, H. The application of electronic computers to factor analysis. Educational and Psychological Measurement, 20 , — A second generation little jiffy. Psychometrika, 35 , — Kilmann, R. Gaining control of the corporate culture. Koh, E. Issues on adopting software product line. Kottler, J. Beyond blame: A new way of resolving conflicts in relationships. San Francisco: Jossey-Bass. Kotter, J. Corporate culture and performance. Kuvaja, P.
Software process assessment and improvement—the bootstrap approach. Oxford: Blackwell. Landis, J. The measurement of observer agreement for categorical data. Biometrics, 33 , — Lee, H. Lyles, M. An analysis of discrimination skills as a process of organizational learning. The objective of the questionnaires is to collect information about the SPLA development process.
Thus, in general this work contributes towards the establishment of a comprehensive and unified strategy for the process maturity evaluation of software product line engineering. Furthermore, we conducted two case studies and reported the assessment results, which show the maturity of the architecture development process in two organizations. Follow Contact.
0コメント