Mapping of Fusion Process Model onto ISO/IEC 12207:2008

Transcription

1 Mapping of Fusion Model onto ISO/IEC 12207:2008 Rupinder Kaur; Jyotsna Sengupta Department of Computer Science; Punjabi University Patiala, India Abstract Fusion Model is a component driven software development approach and can handle design and requirements changes at later stage very efficiently. The purpose of this paper is to provide a support to the standardization of Fusion Model (FPM). Thus, this paper is based on the results of the FPM assessment outcomes mapping (based on the experience of the team members of the four projects) with the software development standard (Industry Implementation of International Standard ISO/IEC 12207: 2008). Index Terms process model, product, ISO/IEC 12207, Fusion Model (FPM). 1. Introduction The life of a system or a software product can be modelled by a life cycle model consisting of phases. Models may be used to represent the entire life from concept to disposal or to represent the portion of the life corresponding to the current project. The life cycle model is comprised of a sequence of phases that may overlap and/or iterate, as appropriate for the project's scope, magnitude, complexity, changing needs and opportunities. Each stage is described with a statement of purpose and outcomes. The life cycle processes and activities are selected and employed in a stage to fulfil the purpose and outcomes of that stage. Different organizations may undertake different stages in the life cycle. However, each stage is conducted by the organization responsible for that stage with due consideration of the available information on life cycle plans and decisions made in preceding stages. Similarly, the organization responsible for that stage records the decisions made and records the assumptions regarding subsequent stages in the life cycle [1]. Fusion is component driven software process model, where each phase implements a problem solving model, 3C Model [2]. These phases address what is to be built, how it will be built, building it and making it high quality. The problem solving model includes the explicit processes for technically analyzing the problem, solution space analysis, alternative analysis, dynamic design and development and scope for dynamic testing. With the problem analysis process, technical problems are identified and structured into loosely coupled sub-problems that are first independently solved and later integrated in the overall solution. In the solution space analysis process, requirements are specified using any representation and this should be refined along the software development process until the final software is delivered. In the alternative analysis process, different alternative solutions are searched and evaluated against explicit quality criteria. Dynamic design and development is component base approach, which provides scope for dynamic changes during the development life cycle. As fusion process follows the component design approach, it provides scope for dynamic testing (component base testing) [3]. The International Organization for Standardization (ISO) and the International Electro-technical Commission (IEC) established a Joint Technical Committee (JTC1) on Information Technology [128]. The scope of the JTC1 is "Standardization in the field of information technology systems (including microprocessor systems) and equipments" [4]. The JTC1 initiated the development of an International Standard, ISO/IEC 12207: 2008, on software life cycle processes. ISO/IEC 12207: 2008 is a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry [1], [4]. The International Standard fulfils the critical needs by establishing a common framework that can be used by software practitioners to manage and engineer software. Besides, such a uniform framework would promote international trade in software products and services [5]. The standard establishes a top-level architecture of the life cycle of software. The life cycle begins with an idea or a need that can be satisfied wholly or partly by software and ends with the retirement of the software. The International Standard describes a set of primary processes that occur during one period or another in the life cycle of a software project extending from its 53

2 conceptualization through its retirement. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products [1]. In Section 2, we discuss the data collection for the analysis. Then we perform mapping of Fusion Model (FPM) onto ISO/IEC 12207: 2008 in Section 3. Finally, we conclude in Section Data Collection for the Analysis The data for the analysis is collected in Fusion Model assessments which were performed for four different software development projects. All of these assessments were focused on the actual project work (e.g. requirements management, project management and development) excluding the preparation and marketing phases and the project maintenance. Therefore, these problem areas are outside the scope of this mapping. Fusion Model is implemented on varied industry domains for the better assessment of this model. This model offered as a promising way to meet the needs of rapid external changes in the dynamic market situations, lower the defect rates and make the development times faster, due to customer involvement during the development phases, claimed to increase customer satisfaction and the motivation of the software developers. Because of the component driven approach, the risk associated with cost and time is limited to component only and ensure the overall quality of software systems, reduce the development cost and time by considering the changing requirements of customer, risk assessment, identification, evaluation and composition of relative concerns at each phase of the development process. The Fusion Model is implemented in multiple software development projects; the data are collected from the four different industry solutions of software development. The following projects are implemented by independent software development companies. 1. Rights System (Clerisy Solutions) [6] 2. Construction Activities automation (Web Shrub Solutions Ltd.)[7] 3. Job Portal Development ( StepintoJob.com )[7] 4. Redesigning of Website (SCL Group)[7] The Fusion Model assessment data were collected using meeting with project managers / developers directly involved in the development process. The Fusion process model, implementations was conducted in order to identify the strengths and weaknesses of the software development process and to discuss the possibilities of increasing the effectiveness of the development process together with the project stakeholders. The implementation thus supported the project and organizational learning between different projects and also the proposal of a Fusion Model on the organizational level. 3. Mapping of Fusion Development onto ISO/IEC 12207: 2008 In this section, the results of the mapping of the Fusion Model performance assessment experience (from four development projects) with ISO/IEC are described. Table 1 and 2 reveal the outcomes. in the following analysis means information that is not collected or analyzed related to the evaluated project. 54

3 Table 1 Mapping of FPM and ISO/IEC 12207: 2008 Phase in ISO/IEC 12207: 2008 Key Rights System (Clerisy Solutions) Construction Activities automation (Web Shrub Solutions Ltd.) Agreement Acquisition Requirements were defined in the product backlog by the customer and product manager. Requirements were defined from the current manual activities at the customer workplace and defined by the product manager. Supply Organisational Project- Enabling Life Cycle Model 55

4 Infrastructure Project Portfolio Human Resource Quality and Product quality assurance was provided 56

5 Project Project Planning With Project Preparation phase of FPM, effective and workable project was planed. With Project Preparation phase of FPM, technical activities, identifies process outputs were performed Project Assessment and Control Fusion Controller of FPM determine the status of the project and ensure that the project performs according to plans and schedules Fusion Controller of FPM determine the status of the project and ensure that the project performs according to plans and schedules Decision FPM performed decision encountered during the life cycle. FPM performed decision encountered during the life cycle. 57

6 Risk Fusion Controller monitored and identify. Appropriate action was performed. Fusion Controller took corrective actions for risk when identified. Configuration Project Manager made available all identified outputs of a project or process and make them available to concerned parties. Project Manager made available all identified outputs of a project or process and make them available to concerned parties. Information Project Manager and team lead provide relevant, timely, complete, valid information about the project designated parties Project Manager and team lead provide relevant and valid information to designated parties Measurement Project Manager collected, and report data relating to the products developed and processes implemented within the organisational unit Project Manager collected, and report data relating to the products developed and processes implemented within the organisational unit 58

7 Technical Stakeholder Requirements Definition Client was involved throughout the life cycle of the project, and feedback was take to validated and confirm that the product needs. Client was involved in the project throughout its life cycle, and feedback was take to validated and confirm that the product needs. System Requirements Analysis The requirements of the whole product were defined and listed as per the process. They were technically analyzed and prioritized by the product owner and development team The requirements of the whole product were defined and prioritized by the customer only. System Architectural Design Design was completely developed by the development team; In each iteration the customer team was involved to improve the design. Architecture design was implemented by the developers using standard Fusion model process as the requirements were based on current manual processes. Implementation 59

8 System Integration Automated Continuous Integration (As it s a application software, not a system software.) Automated Continuous Integration (As it s a application software, not a system software.) System Qualification Testing Installation Acceptance Support 60

9 Operation Maintenance Disposal Implementation Requirements Analysis The defined features were selected, analyzed and divided into multiple components by the development team and quality team. Each component is further optimized improved based on the requirement as per FPM. All the requirements were clearly divided into components for further processing. 61

10 Architectural Design Architecture was based on common standards. It was developed by the development team Light architecture description was done in the first and refactored later. Detailed Design Detailed design was discussed and updated in further iterations by the development team after discussion with the customer. Detailed design was completed and finally discussed with customer for go ahead. Construction Realization phase of FPM performed, efforts produce executable software Realization phase of FPM performed, efforts produce executable software Integration Integration testing performed after integrating independent artifacts. Integration testing performed after integrating interlinked processes. Qualification Testing Traditional Testing was done feature by feature. With each iteration artifacts are tested. Traditional Test cases and test plan prepared for testing, as the functionality was already clear. Support Documentation Design documents, Architecture documents, Implementation documents and how to use software functionality documents were prepared. Design docs and how to use guides were prepared. 62

11 Configuration Master data file and initial data files were provided Quality Assurance All the unit test, integration test and product test done under the supervision of Quality engineer. All the unit test, integration test and product test done under the supervision of Quality engineer. Verification Control part of 3C- Model. Control part of 3C-Model. Validation Project Manager and Client/Customer Validation Project Manager and Client/Customer Validation Review Team meetings, development planning and design thinking. The review was done initially, and then before the final completion. Audit Heuristic & Optimization techniques as per 3C- Model. Heuristic & Optimization techniques as per 3C-Model including web page audits 63

12 Problem Resolution Any discrepancy identified after validation or audit, discussed and resolved by Development Team Any discrepancy identified after validation or audit, discussed and resolved by Development Team Reuse Domain Engineering 3C Model support domain engineering 3C Model support domain engineering Reuse Asset Reuse Program 64

13 Table 2 Mapping of FPM and ISO/IEC Phase in ISO Key Activities JobPortal Development (StepIntoJob) Redesigining of Website (SCL Group) Agreement Acquisition Requirements were defined in the product backlog by the customer and product manager keeping existing job portal data in place. Requirements were defined user feedback, navigation issues, unable to handle volume of data. Supply Organisational Project- Enabling Life Cycle Model 65

14 Infrastructure Project Portfolio Human Resource Quality 66

15 Project Project Planning With Project Preparation phase of FPM, establishes schedules for project task was performed and identified resources to accomplish project tasks. With Project Preparation phase of FPM, technical activities, website performance, website down time Project Assessment and Control Fusion Controller of FPM determine the status of the project and ensure that the project performs according to plans and schedules Fusion Controller of FPM determine the status of the project and ensure that the project performs according to plans and schedules Decision FPM performed decision encountered during the life cycle. FPM performed decision encountered during the life cycle. Risk Fusion Controller monitored and identify the risk. Appropriate action was performed. Fusion Controller took corrective actions for risk when identified. 67

16 Configuration Project Manager made available all identified outputs of a project or process and make them available to concerned parties. Information Project Manager and team lead provide relevant, timely, complete, valid information to designated parties Project Manager and team lead provide relevant and valid information to designated parties Measurement Reports, data relating to the products developed and processes implemented within the organisational unit Project Manager collected, and report data relating to the products developed and processes implemented within the organisational unit Technical Stakeholder Requirements Definition Client was involved in the development throughout its life cycle, and feedback was take to validated and confirm that the product fulfil the needs. Client was involved throughout its life cycle, and feedback was take to validated and confirm that the project is developed as per requirements. 68

17 System Requirements Analysis System Architectural Design Requirements of the whole product were defined and prioritized by the customer with the help of development team. System architecture was developed during the project. It was updated as per component driven process during multiple iterations based on the details available in current market products. Requirements of the website look and feel along with performance metrics prioritized by the customer with the help of development team. System architecture was developed during the project. It was updated as per component driven process during multiple iterations based on the details available in current web technologies. Implementation Fusion Model implementation based on already existing solution System Integration Automated Continuous Integration (As it s a application software, not a system software.) Automated Continuous Integration (As it s a application software, not a system software.) 69

18 System Qualification Testing Installation Acceptance Support Operation Maintenance 70

19 Disposal Implementation Requirements Analysis The defined features were selected and analyzed in Project Preparation phase together with the customer, project and product management and development team during the initial phases. The defined features were selected and analyzed in Project Preparation phase together with the customer, project and product management and development team during the initial phases. Website Pages were identified and laid out modified along with performance metrics such max time for navigation between pages in the website. Architectural Design Architectural baseline was defined before the development. Baseline was updated during the project. Architectural baseline was defined before the development. The base web pages were identified and used as as the baseline. Baseline was updated during the project. 71

20 Detailed Design As simple as possible to give much freedom to the developers. Daily technology risk management and problem solution discussed with the client. As simple as possible to give much freedom to the developers. Daily technology risk management and problem solution discussed with the client. Construction Component driven development approach used throughout the development process. Component driven development approach used throughout the development process. Integration Integration testing performed after integrating multiple features. Integration testing performed after integrating a page, few pages or multiple pages. Qualification Testing Each feature was tested before moving to next step. Traditional Combinational of functionalities were tested and the working model are already available online. Each page's behaviour was tested before moving to next step. Traditional Combinational of functionalities were tested and the working website beta versions made available online. Support Documentation Design Documents were prepared. Design Documents were prepared. Page layouts were identified 72

21 Configuration Quality Assurance All the unit test, integration test and product test done under the supervision of Quality engineer. All the unit test, integration test and product test done under the supervision of Quality engineer. Verification Control part of 3C- Model. Control part of 3C-Model. Validation Project Manager and Client/Customer Validation Project Manager and Client/Customer Validation; stress testing; performance metrics such time to navigate between pages, inserting data into database; report generation; search page performance. Review Review done on ongoing basis. Review done on on-going basis. 73

22 Audit Heuristic & Optimization techniques as per 3C-Model. Heuristic & Optimization techniques as per 3C-Model including web page audits Problem Resolution Any discrepancy identified after validation or audit, discussed and resolved by Development Team Any discrepancy identified after validation or audit, discussed and resolved by Development Team Reuse Domain Engineering 3C Model support domain engineering process 3C Model support domain engineering process Reuse Asset Reuse Program 74

23 4. Conclusions The empirical evidence of Fusion Model assessment by the development team is used to define how the FPM for software development could be mapped against the ISO/IEC 12207: 2008 standard. 3C-Model assisting FPM activities of Capture could be mapped to the Technical and Implementation es of ISO/IEC 12207:2008 standards. Similarly the activities from the Control part mapped to the ISO/IEC 12207: 2008 Support es. Domain engineering processes could be mapped with the model concept of domain engineering. Component driven development leads to Test Driven Development and continuous integration of artifacts from multiple stages give mechanisms for the implementation and testing activities of ISO/IEC 12207: 2008 development process. 5. References [1] International Standard ISO/IEC 12207, System and software engineering Life Cycle, IEEE Std , Second Edition [2]Rupinder Kaur and Jyotsna Sengupta, Development and Analysis of 3C-Model for Development Lifecycle, IEEE 2 nd International Conference on Computer Engineering and Technology (ICCET 2010), Volume 6, pp , April 16-18, Chengdu, China, [3] Rupinder Kaur and Jyotsna Sengupta, A New Approach in Development-Fusion Model, Journal of Engineering and Applications, Volume 3, Issue 10, pp , October [4] Raghu Singh, An introduction to ISO/IEC (Tutorial), August [5 ] Raghu Singh, International Standard ISO/IEC 12207: Life Cycle es, Federal Aviation Administration Washington, DC, USA, [6] Rupinder Kaur and Jyotsna Sengupta, Analysis of Fusion Model Case Study, Journal of Engineering and Applications, 2012, Volume 5, Issue 3, pp , [7] Rupinder Kaur and Jyotsna Sengupta, Fusion Model Implementation Case Studies, International Journal of Advancements in Research Technology Volume 1, Issue2, pp. 1-15, July