A Proposed Hybrid Web Engineering Process Model for Large-Scale Web-Based Applications Development in Large Web Development Enterprises

Transcription

1 A Proposed Hybrid Web Engineering Process Model for Large-Scale Web-Based Applications Development in Large Web Development Enterprises Submitted By Omaima Nazar Ahmad AL-Allaf Supervised By Prof. Dr. Asim El-Sheikh Dissertation Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy In Computer Information Systems Faculty of Information Systems and Technology The Arab Academy for Banking and Financial Sciences Amman-Jordan August 2008

2 II

3 AUTHORIZATION I, the undersigned Omaima Nazar Ahmad Al-Allaf authorize the Arab Academy for Banking and Financial Sciences to provide copies of this Dissertation to Libraries, Institutions, Agencies and any Parties upon their request. Name: Omaima Nazar Ahmad Al-Allaf Signature: Date: 12/8/2008 III

4 DEDICATION All respect and very special appreciation to my Dear mother Doctor.Nida a Hazem for her encouraging and supporting to me And also to my lovely daughter Dalia for her encouraging and patience to me With Respect Omaima Al-Allaf 12 August 2008 IV

5 ACKNOWLEDGEMENTS I would like to thank God, first and foremost, for having guided me through the critical stages of my life to successful completion. This thesis is the result of almost four years of full-time study, and during this time I have been supported by many people. I am delighted to now have the opportunity to express my sincere gratitude and appreciation to all of them. I am deeply indebted to my supervisor, Professor Asim Elsheikh for his stimulating suggestions, guiding hand and expertise in the field of Software Engineering. Special thanks also due to the staff members of the Department of information Systems- The Arab Academy for Banking and Financial Sciences-Amman-Jordan for their constant cooperation and help during this period of research. I would like to extend my deepest gratitude and sincere thanks to my mother for her affectionate support that has acted as a necessary stimulus to my academic quest. Finally, my thanks go to my daughter DALIA has helped me to achieve my goal through her patience, understanding and willingness to accommodate my dream. Omaima Al-Allaf 12 August 2008 V

6 Published Papers Omaima N. Al-Allaf, Guidelines for Using Multimedia in Webpage and User Interface Design, Proceedings of the 4 th International Multiconference on Computer Science and Information Technology (CSIT2006), ASU (private), Vol.3, pp , Amman, Jordan, 5-7 April Omaima Nazar Ahmad AL-Allaf and Asim El-Sheikh, Guidelines for Constructing Web Engineering Process Models for Developing Large-Scale Web-Based Applications, The 1 st international conference on digital communications and computer applications (DCCA 2007), Jordan University of Science & Technology, pp , Irbid, Jordan, March VI

7 ABSTRACT Currently, the level of adoption of current practice and software process improvement (SPI) in large enterprises is unknown. A literature and a practical survey of web development methodologies has been conducted in this thesis to identify web engineering practice and to understand the extent of web practices currently in use in large enterprises to help improving the software processes. This survey clarified that, there were several web methodologies that has concentrated on delivering functional web applications but most of these applications run over time and budget and without consideration on SPI and quality requirements. The survey confirmed also that the: tools and technology, and standards and procedures are partially adopted, whereas, the project management planning, customer involvement practices, web metrics, and the control of the development process are barely used by these enterprises. A Hybrid web engineering process model for developing the large web applications in large enterprises has been proposed in this thesis. This model consists of many activities to follow: possible division of large web application into many small sub applications; possible division of large number of developers into many sub teams; identify a management team to control and monitor the development process; Stakeholders and customers inclusion and feedback during web development process; requirement analysis, management and development; risk analysis of all large web application s components; adopting the Spiral model by management team to manage and monitor the development progress; adopting the Throwaway Prototype model by each sub team for requirements gathering; adopting the XP agile method by each sub team for customer communication during the development process; adopting WebEng process model by each sub team to match web application s properties and challenges; adopting a suitable user interface design approach; conducting CMMI levels key process areas; conducting web engineering practices; integrating SQA activities; and training the mmanagers and developers on CMMI and web engineering practices. This model is focuses on overall development process phases such as: requirement gathering and analysis; cost, time and effort estimation; planning; design; coding; testing, verification and validation; integration; and documentation. According to Hybrid model evaluation with CMMI levels key process areas, we investigate that: This model steps covered and largely satisfied both of CMMI Level2 and CMMI Level3 process areas; whereas, satisfied CMMI Level4 process areas; but partially satisfied CMMI Level5 process areas. According to Hybrid model comparison with XP, Spiral and WebEng in VII

8 their compatibilities with CMMI levels process areas; we investigate that this model can overcome the limitations of these process models to use them in combinations. Finally, the evaluation of the Hybrid model according to CMMI process areas has been conducted in this research. This evaluation has been carried out by the aiding of many professional developers and managers currently working in many large web-development Jordanian enterprises. The evaluation results shows that the Hybrid model satisfied about 85.57% of CMMI level2, 86.86% of CMMI level3, 73.35% of CMMI level4, and finally about only 31.65% of CMMI level5. The study indicates that large enterprises can benefit from Hybrid model if they apply it in good manner with sufficient training because it was being noted from the analysis of Hybrid steps that: this model can overcome as possible as the problems of large web applications development mentioned in the literature researches and also web development problems in these large web enterprises. VIII

9 Table of Contents Contents Page Chapter 1: Overview of the Thesis Introduction The Development Process of Web-Based Applications The Large-Scale Web-Based Applications The Importance of this Research The Problems in Developing Large-Scale Web-Based Applications The Research Objectives Literature Review Literatures Related to Development Methodologies of Web Applications Literatures related to development methodologies of large web applications The Literature Analysis (Problems Obtained from Literature) The Research Methodology Outlines of the Thesis 14 Chapter Two: Review of Web-Based Applications Development and Development Process Models Introduction The Software Web-Based Applications Multidisciplinary Nature of Web Development Web-Based Applications versus Traditional Software Characteristics of Simple and Advanced Web Applications The Components of Web-Based Applications The Basic Requirements for Web Engineering Challenges of Web-Based Applications Development The Software Development Process The Perceived Problems in Software Development The Basics of Good Software Development Ad-hoc Development The Importance of Software Process in Large Organizations Traditional Software Process Models (Heavyweight) Waterfall Software Process Model Incremental Process Model The Rapid Application Development (RAD) Model Prototyping Model Spiral Software Process Model Rational Unified Process Model (RUP) Agile Process Methodologies (Lightweight) Extreme Programming (XP) Strengths and Limitations of Agile Methodologies Introducing Agile Methodologies in Large Organizations Agile Methodologies for Web-Based Applications Development Agile Methods vs. Traditional Methods Mixing Agile Methods with Traditional Methods Challenges to Implementing Agile Processes in Traditional Organizations Web-Based Applications Development Process The Web Engineering Process Model (WebEng) Factors Responsible for the Failure of Web-Based Applications Steps for Successful Web-Based Applications Development IX

10 Contents Page Large-Scale Web-Based Applications Development Requirements Engineering (RE) in Web Development The Modeling of Web-Based Applications Model-Driven Development (MDD) of Web-Based applications Design Models for Web-Based Applications Cost, Effort and Time Estimation of Web-Based Applications The Stakeholders of Web-Based Applications Project Planning Management of Web Development Tools for Web Engineering Testing Web-Based Applications Documenting Web-Based Applications.. 49 Chapter 3: Software Process Improvement and Quality Assurance in Large Enterprises 3.1 Introduction The Software Process Improvement with CMM The Capability Maturity Model Integration (CMMI) The CMMI Capability Maturity Levels The Categories of CMMI Key Process Areas Organizations with Software CMM Experience Immature Versus Mature Software Organizations Training The Software Process Standards (ISO Standards) The Importance of Software Process Improvement (SPI) CMMI for Large Enterprises Lack of Research about SPI for Large Enterprises The Need of SPI to Solve Problems in Large Enterprises Development of SPI Activities in Large Enterprises The SPI Success Factors in Large Organizations Factors Affecting Organizational Change in SPI Efforts The SPI and Agile Methodologies The Elements of SPI in Agile Software Development Comparison of SPI Elements in Traditional and Agile Development Agile Adoption and Improvement Model (AAIM) Compatibility of Agile Methods with CMMI Requirements The Software Quality Assurance (SQA) The Components of Software Quality Assurance The Quality Attributes of Web-Based Applications The Quality Assurance in Web Development Organizations Web Applications Quality and Support in XP Risk Management and SQA The Quality Assurance of Large-Web-Applications and SPI Integrating Quality Activities in Project Life Cycle Chapter 4: An Analytical Survey of Large-Scale Web-Based Applications Development in Large-Scale Jordanian Enterprises Introduction Survey Methodology Statistical Methods Used in Data Analysis The Analysis of the First Questionnaire Factors Used to Select the Large Enterprises (Research Population).. 72 X

11 Contents Page General Characteristics of Large-Scale Jordanian Enterprises Interviews in Large Web Development Enterprises Development Teams in Large-Jordanian Enterprises The Statistical Analysis of the Second Questionnaire Respondent Background Current Position of Respondent Activities Currently Work CMMI-Related Training Participated in Previous Forms of Software Process Assessment Experience of Developers in Present Organization Overall Experience of Developers Level of Experience with Web Based Applications Development Development and Test Methods The Size of Jordanian Enterprises Web Application Domain Web-Based Applications Development Involves The Developers Familiarity with Development Methodologies Development Methodologies Used by Enterprises Test Types Required by Organization Assurance Activities are Performed Who Performs the Assurance Activities? Description of Possible Symptoms at Organizations Web Engineering Practices Organizational issues Standards and Procedures Web Metrics Control of the Development Process Tools and Technology Summary of Statistical Analysis of the Second Questionnaire Summary of Analysis Related to Respondents Background Summary of Analysis Related to Development and Test Methods Summary of Possible Symptoms at Organizations Summary of Web Engineering Practices. 98 Chapter 5: Hybrid Web Engineering Process Model for Large-Scale Web-Based Applications Development Introduction The Need for a Standard Web Engineering Process Model Problems (Related to Large Web Development) to be Solved Guidelines for Constructing Web Engineering Process Models The Proposed Hybrid Web Engineering Process Model The Features of the Hybrid Web Engineering Process Model The Components of the Hybrid Model The Role of the Management Component The Role of Development Component Stakeholders Coordination in the Hybrid Model Requirement Engineering and Management in Hybrid Model Requirements Development Planning Phase in Hybrid Model Risk Analysis and Management in the Hybrid Model Cost, Time and Effort Estimation in Hybrid Model XI

12 Contents Page Management of Large Web Application Development in Hybrid Model Management of Large Number of Developers in Hybrid Model The Properties of Teams in the Hybrid Model The Properties of Sub Teams Members in the Hybrid Model The Relationships of Development Teams in Hybrid Model Management within XP Principles Adoption Quantitative Project Management User Interface Design in the Hybrid Model User Interface Design Approach for Large Web Applications Configuration Management in Hybrid Model Testing, Verification and Validation in Hybrid Model Project Monitoring and Control Organizational Process Performance Technical Solutions in the Hybrid Model Integration in Hybrid Model Product Integration Integrated Project Management Integrated Teaming Integrated Supplier Management Organizational Environment for Integration Developers Training in the Large Web Development Enterprises Organizational Training Integrating QA Activities with Hybrid Model The Activities to the different SQA processes Internal Assessment and Light Formal Reviews External Assessment Software Development Process Models Used in Hybrid Model Spiral Model Adopted by Centralized Team Advantages of the Spiral Model Throwaway Prototype The Limitations and Strengths of Prototype Model The Web Engineering Process Model The XP Adopted by Sub Teams in the Hybrid Model The Benefits of Using XP in Hybrid Model Integrating Web Engineering Practices in Hybrid Model Software Process Improvement in the Hybrid Model The Problems Solved By the Hybrid Model The Advantages and the Limitations of the Hybrid Model. 133 Chapter 6: CMMI-Evaluation of the Proposed Hybrid Web Engineering Process Model 6.1 Introduction Hybrid Model Evaluation According to CMMI Levels The Compatibility of Hybrid Activities with CMMI Level The Compatibility of Hybrid Activities with CMMI Level The Compatibility of Hybrid Activities with CMMI Level The compatibility of Hybrid Activities with CMMI Level The Coverage of XP, Spiral, WebEng and Hybrid with CMMI The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Generic Practices XII 134

13 Contents Page Summary of the Hybrid Analysis versus CMMI process Areas Hybrid Model Evaluation by Large Jordanian Enterprises CMMI level2 Process Areas and Goals CMMI level3 Process Areas and Goals CMMI level4 Process Areas and Goals CMMI level5 Process Areas and Goals The Summary of Hybrid model Evaluation 162 Chapter7: Discussion and Conclusions Introduction Discussion of the Survey Findings Conclusions Contributions Recommendations to Avoid Failure Future Works in Research Limitations of the Research References 173 Appendix A Appendix B. 195 Appendix C. 202 XIII

14 List of Tables Table Name Page Table (2.1): Traditional versus Agile Software Development 33 Table (2.2): The Summary of Risk-Based Method 35 Table (2.3): The Core RE Activities 39 Table (2.4): Estimation Dimensions and Corresponding Project Factors. 44 Table (3.1): The Factors Affecting Organizational Change in SPI Efforts 59 Table (3.2): The Fundamentals of Software Development in Plan-Driven and Agile 61 Table (3.3): The Quality Attributes of Web-Based Applications. 65 Table (4.1): Factors Used by Enterprises to Measure the Size of Web Applications 72 Table (4.2): Descriptive Statistics of the Current Position of Employee 75 Table (4.3): The Descriptive Statistics of Respondents Current Work Activities 76 Table (4.4): Descriptive Statistics of Developers Receiving any CMMI Training Table (4.5): Descriptive Statistics of Respondents Participated in Forms of SPA 77 Table (4.6): Descriptive Statistics of Developers Experience in Present Organization 77 Table (4.7): Descriptive Statistics of Overall Software Experience of Developers 78 Table (4.8): Descriptive Statistics of Level of Experience with Web Development Table (4.9): Descriptive Statistics of Different Sizes of Large Jordanian Enterprises 79 Table (4.10): Descriptive Statistics of Application Domain in Jordanian Enterprises Table (4.11): Describe If Development Involve In-House, Outsource or Reusability 80 Table (4.12): Statistics of Developers Familiarity with Development Methodologies 81 Table (4.13): Descriptive Statistics of Development Methods Used by Enterprises 82 Table (4.14): Descriptive Statistics of Test Types Required by Organization 82 Table (4.15): Descriptive Statistics of Performed Assurance Activities 83 Table (4.16): Frequent Distribution of Who Performed Assurance Activities 84 Table (4.17): Developers Perceptions Toward Symptoms at Organization 85 Table (4.18): The Statistics of Organizational Issues in Web Engineering Practices.. 88 Table (4.19): Statistics of Standards and Procedures in Web Eng Practices 90 Table (4.20): The Frequency Distribution of Web Metrics in Web Engineering Practices.. 92 Table (4.21): The Frequency Distribution of Control of the Development Process.. 94 Table (4.22): The Frequent Distribution of Tools and Technology in Web Eng Practices 95 Table (5.1): Problems in the Literature 102 Table (5.2): Problems of Large Web Development in Large Jordanian Enterprises 102 Table (5.3): Problems of Web Engineering Practices in Large Jordanian Enterprises 102 Table (5.4): The Features of Hybrid by Principles XIV

15 Table Name Page Table (5.5): Problems in the Literature solved by the Hybrid model Table (6.1): Hybrid Activities Against the Activities of CMMI Level Table (6.2): Hybrid Activities Against the Activities of CMMI Level Table (6.3): Hybrid Activities Against the Activities of CMMI Level4 141 Table (6.4): Hybrid Activities Against the Activities of CMMI Level5 141 Table (6.5): Coverage of CMMI-Level2 Areas by XP, Spiral, WebEng and Hybrid Table (6.6): Coverage of CMMI-Level3 Areas by XP, Spiral, WebEng and Hybrid. 144 Table (6.7): Coverage of CMMI-Level4 Process Areas by XP, Spiral, WebEng and Hybrid 146 Table (6.8): Coverage of CMMI-Level5 Process Areas by XP, Spiral, WebEng. and Hybrid Table (6.9): Coverage of CMMI Generic Practices by XP, Spiral, WebEng and Hybrid 147 Table (6.10): The Results of CMMI level2 Requirements Management 149 Table (6.11): The Results of CMMI level2 Project Planning Table (6.12): The Results of CMMI level2 Project Monitoring and Control Table (6.13): The Results of CMMI level2 Supplier Agreement Management 151 Table (6.14): The Results of CMMI level2 Measurement and analysis Table (6.15): The Results of CMMI level2 Process and Product Quality Assurance. 152 Table (6.16): The Results of CMMI level2 Configuration Management 153 Table (6.17): The Results of CMMI level3 Requirements Development 154 Table (6.18): The Results of CMMI level3 Technical solution Table (6.19): The Results of CMMI level3 Product Integration Table (6.20): The Results of CMMI level3 Verification. 156 Table (6.21): The Results of CMMI level3 Validation 156 Table (6.22): The Results of CMMI level3 Organizational Process Focus. 157 Table (6.23): The Results of CMMI level3 Organizational Process Definition Table (6.24): The Results of CMMI level3 Organizational Training Table (6.25): The Results of CMMI level3 Integrated Project Management Table (6.26): The Results of CMMI level3 Risk Management Table (6.27): The Results of CMMI level3 Decision Analysis and resolution 160 Table (6.28): The Results of CMMI level4 (2 Process Areas) 161 Table (6.29): The Results of CMMI level5 (2 Process Areas) 161 Table (6.30): The Summary of Hybrid Model Evaluation by CMMI. 162 Table (7.1): The Hybrid Model Activities Compatibility with CMMI levels KPAs XV

16 Figure Name List of Figures Figure (1.1): The Framework of Web Engineering Process 4 Figure (1.2): The Research Methodology. 15 Figure (1.3): The Outlines of the Thesis. 17 Figure (2.1): The Web Engineering A multidisciplinary field.. 20 Figure (2.2): Complementary and Conflicting Goals in a Software project. 23 Figure (2.3): The Throwaway Prototype.. 26 Figure (2.4): The Spiral Software Process Model 27 Figure (2.5): The Rational Unified Process.. 28 Figure (2.6): The Life Cycle of the XP Process.. 30 Figure (2.7): The General Process for User Requirements Analysis.. 40 Figure (2.8): The Model-Driven Approach for Web Systems 42 Figure (2.9): A More Detailed Model for a Web Application, Showing User Roles and Interactions 47 Figure (3.1): The Staged View of CMMI 53 Figure (3.2): Agile Adoption and Improvement Model.. 62 Figure (4.1): Factors Used by Enterprises to Measure the Size of Web Applications 72 Figure (4.2): Relationships between Teams in Enterprises. 74 Figure (4.3): Describe the Frequencies of Current Position of Employee 75 Figure (4.4): The Frequencies of Respondents Current Work Activities 76 Figure (4.5): The Frequencies of Developers Receiving Any CMMI Training. 76 Figure (4.6): Participation in Software Process Improvement. 77 Figure (4.7): Frequencies of Developers Experience in Present Organization.. 77 Figure (4.8): Frequencies of Overall Experience of Developers 78 Figure (4.9): Frequencies of Level of Experience with Web Development 78 Figure (4.10): Frequencies of Different Sizes of Large Jordanian Enterprises Figure (4.11): Frequency Distribution of Application Domain.. 80 Figure (4.12): Describe If Development Involve In-House, Outsource or Reuse 80 Figure (4.13): Frequencies of Development Methods Which developers Familiar With 81 Figure (4.14): Frequencies of Development Methods Used by Enterprises... Figure (4.15): Frequency distribution of Test Types Required by Organization 83 Figure (4.16): Frequent Distribution of Performed Assurance Activities 83 Figure (4.17): Frequent Distribution of Who Performed Assurance Activities.. 84 Figure (4.18): The Mean of Severity Score Description of All Symptoms 86 Figure (4.19): The Means of Occurrence Frequency Score Description of Symptoms 87 XVI Page 82

17 Figure (4.20): Organizational Issues in Web Engineering Practices Figure Name Page Figure (4.21): Standards and Procedures in Web Engineering Practices 91 Figure (4.22): Web Metrics in Web Engineering Practices 93 Figure (4.23): Control of the Development Process in Web Engineering Practices Figure (4.24): Tools and Technology in Web Engineering Practices. 96 Figure (4.25): Overall Best Practices Adoption in Large Jordanian Enterprises. 99 Figure (5.1): The Proposed Guidelines for Constructing Web Eng Process Models Figure (5.2): Web-Based Application Division Figure (5.3): The Complete Hybrid Web Engineering Process Model Figure (5.4): The Interaction Process between the Management and Sub Team Figure (5.5): The Integration of Web Engineering Process with XP Practices Figure (5.6): Relationships between teams in enterprises 116 Figure (5.7): Steps of UI design of Sub Web Application 119 Figure (6.1): The Results of CMMI level2 Requirements Management. 149 Figure (6.2): The Results of CMMI level2 Project Planning Figure (6.3): The Results of CMMI level2 Project Monitoring and Control Figure (6.4): The Results of CMMI level2 Supplier Agreement Management 151 Figure (6.5): The Results of CMMI level2 Measurement and Analysis. 152 Figure (6.6): The Results of CMMI level2 Process and Product Quality Assurance Figure (6.7): The Results of CMMI level2 Configuration Management. 153 Figure (6.8): The Results of CMMI level3 Requirements Development 153 Figure (6.9): The Results of CMMI level3 Technical Solution Figure (6.10): The Results of CMMI level3 Product Integration 155 Figure (6.11): The Results of CMMI level3 Verification 156 Figure (6.12): The Results of CMMI level3 Validation Figure (6.13): The Results of CMMI level3 Organizational Process Focus 157 Figure (6.14): The Results of CMMI level3 Organizational Process Definition. 158 Figure (6.15): The Results of CMMI level3 Organizational Training. 158 Figure (6.16): The Results of CMMI level3 Integrated Project Management. 159 Figure (6.17): The Results of CMMI level3 Risk Management Figure (6.18): The Results of CMMI level3 Decision Analysis and Resolution. 160 Figure (6.19): The Results of CMMI level4 (2 Process Areas) Figure (6.20): The Results of CMMI level5 (2 Process Areas) Figure (6.21): The Hybrid Evaluation by Large Enterprises According to CMMI. 162 XVII

18 List of Abbreviation Abbreviation of the study s constructs Hybrid Hybrid Web Engineering Process Model WebEng. Web Engineering Process Model XP... Extreme Programming QA.. Quality Assurance SQA Software Quality Assurance SPI.. Software Process Improvement CMM. Capability Maturity Model CMMI. Capability Maturity Model Integration SEI.. Software Engineering Institute KPA s. Key Process Areas SBPQ. Software Best Practice Questionnaire DB.. Data Base ASP Agile Software Development Process OO. Object Oriented OOP Object Oriented Programming RUP... Rational Unified Process RE.. Requirements Engineering ISO. International Organization for Standardization UI... User Interface UID. User Interface Design SCM... Software Configuration Management SEPG.. Software Engineering Process Group XVIII

19 Chapter 1 Overview of the Thesis 1.1 Introduction During the last decades, the web-based applications are evolving rapidly using many new technologies, programming languages and models that are being used to increase the interactivity and usability of these applications. A web-based application is a software system based on technologies and standards of the World Wide Web Consortium (W3C) that provides web resources such as content and services through a user interface and web browser [1]. The web-based applications have the properties of network intensiveness, concurrency, unpredictable load, performance, availability, data driven, content sensitive, continuous evolution, immediacy and security [2]. Web engineering is concerned with the use of scientific, hypertext engineering, software engineering best practices, advances, management principles, disciplined, systematic methodologies, iterative process, better development tools and a set of good guidelines to the successful development, deployment, performance evaluation and maintenance of high quality web sites and web-based applications [3]. The emerging field of web engineering aims to bring the web application s development under control, minimizes risks, enhances web site maintainability, quality and successfully manages the diversity and complexity of web application s development to avoid major failures of web applications development [4]. The complexity of designing, developing, maintaining and managing web applications have increased significantly when web applications have evolved [4]. The objective of this chapter is to give a brief description of web-based application, web engineering, development process of web-based applications and large web applications. This chapter includes the importance of this research, problems in developing large-scale web applications and research objectives. This chapter also includes literature review, literatures related to development methodologies of web applications, literatures related to development methodologies of large web applications and analysis of these literatures. Finally, this chapter includes research methodology and outline of this thesis. 1.2 The Development Process of Web-Based Applications The development of modern web-based applications requires a methodologically sound engineering approach because these web applications are complex software systems. The web engineering comprises the use of systematic and quantifiable approaches based on software 1

20 engineering in order to accomplish the specification, implementation, operation and maintenance of high-quality web applications [1]. The web site s structure, functionality and information contained within it may evolve and change continuously over time to keep information current and to meet user requirements. So it is not possible to specify fully what a web site should contain at the start of the development process. Therefore, the ability to maintain information, scale the structure and functions of web site are major factors that make web application development different in comparison to traditional software development. These factors should be taken into consideration when developing web applications [5]. Many of new methodologies related to web development focused on the user interface design but failed to address the wider aspects, complexity and overall development process of web-based applications [6]. At the same time, the traditional software process models of traditional information systems have challenges to accommodate web specific aspects into their techniques and practices. Therefore, the development of web-based applications requires a mix of web site development techniques together with properties of traditional software process models [7]. 1.3 The Large-Scale Web-Based Applications The simplest form of web applications consists of a set of linked hypertext files that present information using text and limited graphics. When the importance of e-business applications grow, the web applications are evolving into sophisticated computing environments that provide standalone features, computing functions, content to the end user and are integrated with corporate databases and business applications [2]. The properties of large web applications are defined in few literature researches. Garland and Anthony [8] defined a large software project as a system that: including large quantities of source code typically millions of lines; including large number of developers (more than 50, often geographically distributed); including large number of interactive functions; using of multiple programming languages; using multiple mechanisms (files, relational and object databases); and distributing the components over several hardware platforms. Whereas, Bell [9] defined the large-scale software as a system that: comprising a large number of interactive activities that carried out by large number of developers (at least 50) working over lengthy time spans. While, Curtis, et. al. [10] defined the large-scale software project as a system that: involving at least 10 people; involving real-time, distributed or embedded applications; and including hundreds of thousands of lines of delivered system source code. 2

21 On the other hand Burstin and Ben-Bassat [11] defined the large software as a system that having large and diverse community of users, organizational and interactive activities; including hundreds of thousands of lines of code; including hundreds to thousands pages of documentation; requiring long development time; consuming very large resources during the development and maintenance phases. Whereas Tamai and Itou [12] defined the largesoftware project as a system that: is large in program size, investment cost and development period; consisting of large collections of data; and integrating huge number of interacted functions. And Barnett [13] defined large-scale software project as a system that: involving developers from different companies and cultures; comprising teams with 50 or more members; integrating with legacy applications and third-party software packages; and including a number of sub-project teams that integrate their sub-systems to build the final application. Finally, Delic and Dayal [14] defined large-scale software as a system that: is heterogeneous and very dynamic; involving complex interactive activities among many humans, applications, services and devices; including hundreds of thousands of strategic decisions to operational decisions are made on each business day within the large enterprises. 1.4 The Importance of this Research The large-scale web application consists of large number of interactive web pages and functions that supports multiple users who access these functions through internet and connected networks. The development of web-based applications especially large-scale webbased applications has become common because of the growth of the internet and networks. Therefore, successfully developing large-scale web applications that will execute correctly and consistently in a distributed environment where hundreds or millions of requests need to be serviced is a very difficult task. The development methodologies of web-based applications are still in their early stages and new technologies continue to discover. Sometimes these technologies are alternatives and other times they are used in combinations. Balakrishnan and Somasundaram [15] addressed the key requirements for the successful development of large projects such as: user involvement; management support; clear statement of requirements and the ability to verify them; and proper planning [15]. On the other hand, McDonald and Welland [16] suggested that there is a need to focus on many factors to achieve the success of web applications development such as: more requirements analysis; clear analysis of business needs; better 3

22 testing and evaluation of web deliverables; and more focus on the issues associated with the evolution of web applications [16]. There is no uniform approach exists to web applications development. Therefore, the web developers need new techniques and guidelines that capture requirements and integrate them within a systems development methodology [17]. The WebEng is a web engineering process model that developed by Pressman [2]. The WebEng consists of many steps as shown in figure (1.1). Pressman focused in this model on the development of web-based applications in general and did not consider the size of these web applications. After that, many researches worked to create high quality web-based applications that deliver a set of complex content and functionality to a broad population of end users. Bahli and Tullio [18] mapped and discussed in their research the progress made so far on web engineering development. They summarized and classified the literature empirical studies on web engineering based on the six phases of the Pressman web engineering process model. They found that much of the web engineering researches focused on the engineering activity. Almost 70% of the published researches concerned with the engineering part of web applications development process such as architectural design, navigation design and interface design tasks of engineering activity and customer evaluation seem to draw more research. Their results suggested a significant need for theory-based research in web engineering. Figure (1.1): The Framework of Web Engineering Process [2] According to as listed above, the importance of this research is to propose a web engineering process model that we hope to be more suitable for successful development of large web applications and deliver these applications within the time, budget and effort. 4

23 1.5 The Problems in Developing Large-Scale Web-Based Applications Many organizations failed to develop large and high-performance web applications. There are many literature researches which addressed the factors responsible for the failure of web applications and highlights serious problems that affecting the large web applications development. The most important problems that caused the failure of development of large web applications are as follows: 1. Problems in requirement analysis phase [16]. 2. Poor project management of development process [16]. 3. Poor project estimation [16]. 4. The development of web applications that exceeds the budget [19]. 5. Flawed design and development process [20]. 6. Poor understanding of methodology to develop large web-based applications [20]. 1.6 The Research Objectives The objectives of this research are as follows: 1. Proposing a web engineering process model for the development of large-scale webbased applications. We will build this model according to the modification and combination of the basic properties of well known traditional software, agile and web engineering process models. 2. Focusing on the overall development process of large web applications because most of the other earlier researches and methodologies focused only on one development phase such as design, requirements, etc. 3. Reaching a suitable methodology that achieve as possible as an effective development of large web applications and reducing the likelihood of failure of these applications. We will focus in the proposed web engineering model to overcome as possible as the most problems of large web applications development and deliver large web applications on time, effort and within budget. The research questions are: Q.1: Is the proposed web engineering process model compatible with the Software Process Improvement (SPI) Capability Maturity Model Integration (CMMI) key process areas and goals (KPA s) to improve the web development process of the large enterprises and their software quality assurance (SQA)? Q.2: Can the adopting of this proposed web engineering process model overcome as possible as the limitations and challenges of traditional software process models and agile methodologies? 5

24 Q.3: Can the adopting of this proposed web engineering process model overcome as possible as the development problems of large web applications mentioned in literature researches and studies? Q.4: Can the adopting of this proposed web engineering process model in large enterprises for the development of large web applications within budget, effort and time and overcome as possible as the web development problems? 4. Analyzing the compatibility of the proposed model according to CMMI KPA s to determine the advantages properties of this model against other development models. 5. Finally, the objective also is to evaluate this model (according to CMMI levels) by many professional developers and managers currently working in many large Jordanian enterprises which undertaken large web development. The objective of this evaluation is to determine which CMMI level can be reached by these enterprises when adopting this proposed model. 1.7 Literature Review Many software process models and approaches for web applications development had been studied and proposed in the literature. Until now there are few studies about proposing web process models for developing large web applications. However, there is much room for improving existing models and approaches or coming up with new effective web models for the development of large web applications. We divided the literature review into two sections: development methodologies for web applications and the development methodologies for large web applications Literatures Related to Development Methodologies of Web Applications This section includes the literatures related to web engineering process methodologies and techniques for developing web applications without mention to the size of these web applications. A summary and analysis of these literatures are given below: Kushwaha, et. al. [20] addressed the factors that responsible for failure of web applications. They focused on user-centric approach of requirement engineering to help increasing the success rate of web applications development. They proposed the major activities that should be part of a web application s development in order to improve the reliability of web applications. They proposed cognitive process of socio-psychological requirement engineering to overcome the blurring between the requirement engineering and analysis, and also to adopt a more comprehensive approach before cognitive requirement 6

25 engineering is carried out. They highlighted fifteen complexity issues that have a major effect on the successful development of web applications. Hsieh [21] presented a development methodology for web applications that serves as a road map to guide web development. This methodology consists of three phases: structural design, detailed design and implementation. Structural design views a system at the web-page level and detailed design deals with issues of intra-page. The implementation is logically segmented into four steps: implementation of the visual interface, client-side scripting, severside scripting for the visible interface, and server-side scripting for pages and tasks without a visual interface. Souza and Falbo [22] presented an agile approach for development of web applications which used the concept of agile modeling. They started web engineering process with the identification of business needs, followed by project planning. Next, requirements are detailed and modeled, analysis and design. Then the application is built using tools specialized for the web applications. Finally, the system is tested and delivered to end users. Their approach included four activities: requirement specification, analysis, design and implementation. These four activities form should be applied in an iterative fashion, allowing for user feedback and requirements and system evolution. Whitson [23] described a web development process (WebHelix) for the development of web applications. This model consists of project management plan that creates a task list from a systems architecture diagram and uses chart to synchronize the team workload. The WebHelix methodology used a modified spiral approach to systems development. Some parts of the design process, like the business analysis and planning, are done once at the beginning of the process. Some parts of the process, like deployment and maintenance are done once at the end of the process. The major creation of the web application is done by using set of steps repeatedly, producing a set of more complete prototypes, with the final prototype being the completed web application. A WebHelix process consists of the business success evaluation, planning, analysis, design, coding and integration, testing, evaluation, deployment and training, maintenance and future updates. Crane and Clyde [24] described a lightweight two-phase process that integrated advantages from incremental development, throwaway prototyping and waterfall process models to address the challenges of development of web applications such as: frequent changes in requirements; time and cost constraints; and producing quality user interfaces within the 7

26 restrictions of the web environment. Their process consists of cascading phases of interdependent waterfall models. Phase1 follows a modified incremental development model with an emphasis on rapid prototyping and involves the iteration of development activities (requirements definition, systems analysis, design, coding and testing). Phase1 helps the development team to understand the requirements and adapt to frequent changes. Whereas phase2 follows waterfall model with an emphasis on quality and consists of well-defined steps that correspond closely to development activities. Unlike phase1, progress is measured in terms of completion of development activities, instead of the completion of features. Phase2 builds on the knowledge gained from the phase1 and produces a product that has a better user interface, more extensible and maintainable. Zhao and Chen [25] proposed a component-oriented model of web application in which a web application is regarded as a collection of components. Each component have its own functionality and cooperating with others through certain interfaces. They aimed to establish a foundation for methodology to effective development and maintenance of web application that can benefit from the notion of component-oriented approach. Under this model a web application is consisted of client components and server components. All components expose their functionality through interfaces. The client component of a web application will carry out all the tasks at the client side including interacting with end users and any other related activities. The server component takes care of all the processing works to happen at the server side and they do not have user interfaces. This model designed to be used at the application definition phase only during the development process to capture the features of web applications. This model lacked systematic and engineering methodology that can cover the whole lifecycle of web applications. Bochicchio and Paiano [26] discussed a design/prototyping environment and presented the definition and features of JWeb (an environment to support design and prototyping of complex WWW sites). They discussed reasons of why an environment supporting design/prototyping is useful such as: support in the early stage; multi delivery; technological flexibility; design advanced options; and design incompleteness. The JWeb system is a design environment with fast prototyping capabilities based on the hypermedia design methodology (HDM) with the following features: it supports design of the hyper-base and access structures; it supports a clean separation between design in the large and design in the small; and it allows building an environment based on a relational DB to hold the multimedia contents. In many cases they used the prototype as initial version of the application to be worked on in 8

27 order to build up the final version. Sometimes, the prototype could be used as an implementation platform. Finally, we can say that, they didn t discuss design models. Bochicchio and Fiore [27] described an environment (tool) named WARP (Web Application Rapid Prototyping) for the analysis and the rapid prototyping of web applications. This environment offers a set of online software tools, which assist the designer and the user browsing of a web application in all its different aspects. The environment is based on models and techniques used in the hypermedia, information systems and software engineering fields, adapted and mixed. The WARP project proposed a methodology and a development environment for fast prototyping of web applications which support the development cycle from requirement analysis and design of the information and system features till the detailed definition of these schemas and the production of applications (coding, database creation, database filling and creation of interfaces). The process of developing a web application with WARP consists of many steps: collection of requirements; generation of the supporting database; management of the contents; and definition of presentation aspects. After the prototype has created, it must be evolved to create the final web application [27]. Griffiths, et. al. [28] proposed simple web method (SWM) for web engineering. They had built and introduced the prototype WIPSE (Web Integrated Project Support Environment) called PAWS (Project Administration Web Site) that implements some of these whole life cycle activities and to support web engineering. They introduced the following stages and techniques in SWM: project planning; analysis (statement of purpose, audience definition, content analysis and modeling, constraint analysis, and marketing analysis and planning); design (structure/web architecture, page design, visual style, navigation, and metaphor definition); building (preparation, prepare content, build web site, test and evaluate and launch); and maintenance. All of these above efforts offered facilities to speed up design and development of web applications. However, none of them provided an efficient support for the end-to-end process of generation and maintenance of whole web applications Literatures related to development methodologies of large web applications A summary and analysis of literatures related to development process of large-scale web applications is given below: Aoyama [29] proposed an agile software development process (ASP) in order to meet the conflicting of delivering software faster, facilitating distributed development and maintaining 9

28 the flexibility needed that respond to requirements changing. This ASP model consists of upper stream process which covers analysis to implementation phases and the lower stream process which covers the integration testing and system testing phases. The upper stream process consists of several concurrent software processes assigned across multiple teams at geographically distributed sites. When each team completed its upper stream process, it checks in the system to be integrated into a whole system through the lower stream process of integration testing and system testing. McDonald and Welland [30] described the agile web engineering (AWE) process for the development of web applications. They discussed and identified the interaction between business, domain, software and creative design within web projects in their AWE process to deliver solutions that satisfy users. They outlined the AWE process life cycle detailing each stage and how the stages should be used an iterative approach. They identified the various stakeholders that should be reflected within the AWE Process. They discussed how to apply AWE to the development of large web applications with one hundred developers by broken down the developers into smaller teams and each team views the deliverables of other teams through a set of interfaces, one team was responsible for user interface, one for database design, and one for testing system. Each team works on a different type of problem but it may be not systematic process because one team may be wait long time in order to operate on the delivery of previous team. Ginige and Murugesan [31] proposed approach to developing large web systems that is consists of methodologies that enable developers to successfully developing large web applications. They addressed that, there is a need for process to be used in building web systems that assists developers in managing the changing requirements, complexity of the development process, facilitates the communication among members involved in the development process, and supports the continuous evolution, maintenance and management of the content. Their model consists of context analysis, product model, process model, sub project planning, web site development (web site design and construction), web site maintenance, project management, documentation and quality control and assurance. Next to the above research, Ginige [32] highlighted the need to have an appropriate process model when developing large and maintainable web applications. He suggested a process to get user feedback during requirements analysis phase. This process consisted of explicit steps to get feedback from the client at regular intervals. He integrated this process with the overall development model that was already suggested in the previous research. 10

29 Finally, he suggested that, doing high-level analysis and planning when developing large web applications in order to meet customer requirements within an agreed time frame and budget. Tai et. al. [33] described a model-driven approach to support the development of large web applications. They focused on dividing the large development into a number of smaller tasks of different kinds that can be performed by multiple developers to manage the consistency among the sub tasks in an efficient manner. They presented the problems in web application s development such as wide range of technologies involved and a lack of support for the division of work. They suggested that, when web applications grow in size, they are built using various kinds of technologies. They suggested as a one possible solution, the division of design and implementation work and to assign the divided work tasks to a number of developers. They illustrated the development style that categorizes the developer roles and listed the developer roles as screen designers, model maintainers, business logic programmers, server object programmers and application assemblers. Maring [34] suggested four principles to improve the likelihood of success in applying OO development methods in large organizations. The first principle: all control-flow or dynamic behavior should be encapsulated and represented as a design-time abstraction. Second: all business rules that are to change over an application s life should be represented as a single-rules object that business managers can manage. Rule operators and values should be bound dynamically to behaviors and should not be hard-coded as part of the class behavior. Third: class attributes should be mapped to share persistent storage outside of class behaviors. Knowledge of persistence and schemas should not be hard-coded class behaviors. Fourth: class templates should be used to ensure consistency, completeness and testability. He suggested in this research the use of a reuse-centric development process rather than a codingcentric process. He addressed that, the reuse goals should be accompanied by cultural change. Thus, the challenge of cultural change rests more with the management team than with the programmers. He addressed that, there should be a single OO Meta model object to deals with basic object properties, how objects communicate with other objects, and how dynamic behaviors are handled. Finally, he suggested managing class libraries by: minimize sub classing; clarify class abstractions; eliminate behavior overrides; and organize for reuse. Ericsson [35] suggested dividing the large system (super system) into several separate parts, each developed independently as a separate system (subordinate system). A super 11

30 system is implemented by a set of interconnected systems communicating with each other to fulfill the work of this super system. He introduced an architectural pattern for systems of interconnected systems. Each involved system is described by its own set of models, separate from other systems models. Each subordinate system is developed using RUP as a black box considering other systems with which it communicates as actors. This construct allows recursion within one model, and it considers each subsystem a system in its own right and the recursion is between all the artifacts sets of each of the systems. This technique suggested performing the requirements workflow, analysis and design for the subordinate system to understand the boundaries of the subordinate system and what its actors are. The drawback is that you risk more overhead, desynchronized schedules, and it is very hard to employ an iterative lifecycle to the super ordinate system in organizations. 1.8 The Literature Analysis (Problems Obtained from Literature) It becomes more critical to support the development of large web application when the web application is growing in size. This research focuses on problems and challenges that most or even all of the earlier researches and organizations did not take in their considerations when developing the large web applications. These problems are as follows: 1. Most of these earlier researches focused on parts of development process such as requirements, analysis, design or implementation and did not consider the overall development process of large web applications. 2. Most of earlier researches focused on developing a web application in general and did not consider the web application s size if it is small, medium or large sized. 3. Most of earlier researches in the case of large web application did not consider the size of development team and how to manage this large number of developers. 4. Most or even all of the earlier researches did not give details about the requirements elicitation, analysis and management, stakeholders and stakeholders roles in the case of large web applications. 5. Most or even all of earlier researches talked about the large system as a whole and did not talk about how to simplify this large system and how to integrate, test, maintenance, and management of the overall large system. 6. Most of earlier researches did not talk about the management methodology to manage and coordinate the overall development process of large web applications. 12

31 7. Most of earlier researches did not integrate the properties of agile methods such as customer communication and feedback, pair programming and requirements changing during development process with the steps of web development process model. 8. All of earlier researches lacked risk analysis and risks types during the development of large web applications. 1.9 The Research Methodology Figure (1.2) shows the methodology of this research. The brief description points of the research methodology are as follows: 1. At the beginning of this research, we give a description of web engineering, web-based applications and development process of web applications. 2. Listing of the literature studies that defined the large web applications. Building a simple questionnaire (see Appendix A) according to the definitions of large software/projects mentioned in these literature studies. We distributed this questionnaire to many Jordanian enterprises which undertaken development of web applications. 3. The selection of only large Jordanian enterprises as our research population. The selection of large enterprises is done according to the analysis of first questionnaire s results and also according to the interviews with managers working in these Jordanian enterprises that followed this questionnaire. 4. Listing of the previous literature studies related to development methodologies of web applications and highlighted their strengths and limitations. The literature studies included the methodologies that used different approaches of traditional software process models and the web engineering process models in developing web applications. There are few literature researches which undertaken developing of the large web applications. 5. Listing of current and previous literature related to traditional software methodologies (Waterfall, Spiral, Prototyping, et.), agile methodologies (XP, Scrum, et.), software process improvement models (CMM, CMMI, and ISO). 6. Do a survey in the selected large Jordanian enterprises: This survey is divided into two parts. The first part is a second deeper questionnaire (see Appendix B) and the second part is an interview followed this questionnaire. The contents of this questionnaire are determined according to questions reported in the Software Best Practice Questionnaire (SBPQ) which was attached with the report [36]. The units of analysis for this survey are large-scale Jordanian enterprises which undertaken the development of large web applications. 13

32 7. The importance of this second questionnaire is to obtain: developers characteristics; the practices used for web engineering; software development methodologies used; and the symptoms that faced these large enterprises. We will adopt the using of the SPSS statistical analysis tool in order to analyze the results of the second questionnaire. 8. Proposing a web engineering process model to support the suitable development of large web applications within the time, budget and effort and overcome as possible as the problems of web development in literature researches and in large enterprises. The proposing of this web engineering model is very important to meet the web engineering challenges and problems. At the end of this research we will answer the four questions listed earlier in point 3 in research objectives. 9. Analyzing the compatibility of this proposed model with the SPI CMMI key process areas and goals to determine the position of this model among CMMI levels. 10. Comparing the proposed model with many other traditional, agile and web engineering process models according to their compatibilities with SPI CMMI KPA s and goals. 11. Evaluating the proposed model by the aiding of professional developers and managers currently working in different large Jordanian enterprises which undertaken large web development. This evaluation will depend on the CMMI KPA s and goals to determine which CMMI level can be reached when adopting this proposed model by any large web development enterprise Outlines of the Thesis This thesis is divided into seven chapters: Chapter One will include the description of web application, web engineering, development process of web applications and large web applications. Chapter1 will address the importance of this research, problems in developing large web applications and research objectives. Chapter1 will include also the literature review, literatures related to development methodologies of web applications, literatures related to development methodologies of large web applications and analysis of these literatures. Finally, chapter1 will present the research methodology. We will give in Chapter Two details about software types, web applications, differences between web-based applications and traditional software, and challenges of web applications development. Chapter2 will include a description of software development process, the perceived problems in software development, the basics of good software development, adhoc development, the importance of software process in large organizations, and many well known traditional software process models. Chapter2 will include also a description of agile 14

33 process methodologies, extreme programming, introducing agile methodologies in large organizations, the differences between agile and traditional methodologies, and how to mix agile methods with traditional methods. Finally, we will give in chapter2 details about the development process of web applications, the factors responsible for the failure of web applications, steps for successful development of web applications, requirements engineering, modeling, design models, cost estimation, stakeholders, project planning, management, tools, testing and the documentation of web applications. Chapter 1 Listing the literature studies that defined large web applications Chapter 4 Chapter 1 Build Questionnaire1 and distribute it on web development Jordanian enterprises Chapter 4 Selection of only the large-scale Jordanian enterprises Chapter 4 Questionnaire2 on large Jordanian enterprises which undertaken web development Chapter 4 SPSS statistical analysis tool Chapter 4 Obtain problems and challenges of these selected large enterprises Description of web engineering, web-based applications, and development process of web applications Chapter 1 Listing the literature researches related to development methodologies of web applications Chapter 1 Literature analysis and obtain literature problems Chapter 2 Listing of literature related to traditional software methodologies Chapter 2 Listing of literature related to agile methodologies Chapter 3 Listing of literature related to software process improvement models (CMM, CMMI, and ISO), and software quality assurance (SQA) Chapter 5 Proposing a web engineering process model Model Evaluation according to CMMI key process areas and goals Chapter6 Model comparisons with other traditional, agile, and web engineering process models Chapter6 Figure (1.2): The Research Methodology In Chapter Three, we will give a description of SPI, CMM, CMMI, CMMI levels and its KPA s, organizations with CMM experience and ISO concepts. Chapter3 will include also the importance of SPI, CMMI for large enterprises, lack of researches about SPI for large 15

34 enterprises, the need of SPI to solve large enterprises problems, the development of SPI activities in large enterprises, SPI success factors in large enterprises and factors affecting organizational change in SPI efforts. We will describe also in chapter3 the SPI elements in traditional and agile development, agile adoption and improvement model (AAIM), and compatibility of agility with CMMI requirements. Chapter3 will include also a description of SQA and its components, quality attributes of web applications, SQA in web development organizations, risk management and SQA, the SQA of large web applications and SPI, and finally the factors affecting intensity of QA activities in development process. After that, an analytical survey using questionnaires and interviews will carry out in seven large Jordanian enterprises which undertaken large web development. We will give in Chapter Four a detailed analysis of this survey results. The primary objective of this survey is to determine the extent to which these enterprises are using web engineering practices; and examine the software development models adopted for web development in these enterprises. The second objective of this survey is to propose a web engineering process model to overcome as possible as the web development problems that faced these enterprises. Chapter4 will include the details about: the survey methodology of the research; the statistical methods used in data analysis; the analysis of the first questionnaire; the factors used to select the large enterprises; the general characteristics of large Jordanian enterprises; interviews in these enterprises; problems of enterprises; and development teams in these enterprises. Chapter4 will include also the statistical analysis of the second questionnaire such as respondent background; development and test methods; description of possible symptoms at organizations and the web engineering practices. This research focuses on proposing a web engineering process model for development of large web applications to improve web process models and decrease the failure rate of these large web applications. The proposing of this model is based on the literature researches in web development and also is based on the results of the analytical survey. Chapter Five will include details about the need for a standard web engineering process model; problems related to large web development to be solved; and the proposing of guidelines for constructing web engineering process models. Chapter5 will include the detailed description of the proposed Hybrid model, its advantage principles, components and activities. Chapter5 will include also details about software development models used in this model; integrating web engineering practices in Hybrid model; SPI in the Hybrid model. Finally chapter5 will include the problems solved by the Hybrid model; and the advantages and the limitations of the Hybrid model. 16

35 Chapter Six will include the analysis and evaluation of the new Hybrid web engineering process model according to SPI CMMI levels and KPA s and goals. Chapter6 will include also the comparisons between many of traditional, agile, web engineering process models and the Hybrid model according to their compatibilities with SPI CMMI levels and KPA s and goals. Chapter6 will include also the evaluation of the new model according to CMMI levels by the aiding of professional developers currently working the in many large Jordanian enterprises which undertaken large web development. At the end, in Chapter Seven, we will discuss the survey results; conclusion of the research; summary of Hybrid evaluation; and the contributions of this study. Chapter7 will include also the limitations of this study and proposals for future research. Figure (1.3) includes the brief description of thesis outline. Chapter1 Overview of the Thesis Chapter Two Review of Web-Based Applications Development and Development Process Models Chapter 3 Software Process Improvement and Quality Assurance in Large Enterprises Chapter 4 An Analytical Survey of Large Web-Based Applications Development in Large Jordanian Enterprises Chapter 5 Hybrid Web Engineering Process Model for Large-Scale Web-Based Applications Development Chapter 6 CMMI-Evaluation of the Proposed Hybrid Web Engineering Process Model Chapter 7 Discussion and Conclusions Figure (1.3): The Outlines of the Thesis 17

36 Chapter Two Review of Web-Based Applications Development and Development Process Models 2.1 Introduction This chapter includes details about software types, web-based applications, multidisciplinary nature of web development, differences between web applications and traditional software, the characteristics of simple and advanced web applications, components of web systems and challenges of web applications development. We will give a description of software development process, the components of software development, the perceived problems in software development, the basics of good software development, ad-hoc development, the importance of software process in large organizations and many well known traditional software process models. This chapter includes also a description of agile process methodologies and their advantages and limitations, extreme programming, introducing agile methodologies in large organizations, agile methodologies for web development, the differences between agile and traditional methodologies and how to mix agile methods with traditional methods. Finally, this chapter includes more details about the web-based applications development process, the factors responsible for the failure of web applications, steps for successful web-based applications development, requirements engineering, modeling, design models, cost estimation, stakeholders, project planning, management, tools, testing and the documentation of web applications. 2.2 The Software Software is a computer program with associated documentation and configuration data which is needed to make these programs operate correctly [37]. System software and application software are the two major types of software. System software such as operating system, network software and compilers acts as tools to help construct or support application software. Application software helps perform some useful tasks such as games, information systems, real-time systems, embedded systems, office software and scientific software [2][38]. Douglas Bell [9] addressed various software problems such as: it fails to do what users want it to do; it is expensive; it is not always fast enough; it can not be transferred to another machine easily; maintenance is expensive; and it is not always easy to use [9]. This 18

37 thesis focuses on application software which executes on Internet (web-based application) and it especially focuses on only large-scale web-based applications. Software engineering concerns with the development of large and complex software systems. It focuses on: the goals for services provided by such systems; the precise specification of system structure and the implementation of these specifications; the activities required to develop an assurance that the specifications and goals have been met; and the evolution of such systems over time. Software engineering concerns also with processes, methods and tools for the development of software intensive systems in an economic and timely manner [39]. The enterprises may get poor software. The poor software may be incorrect, unreliable, unsafe, late or expensive. A company with negative attitudes has poor senior management response to problems; lack of formal company software design and documentation procedures; lack of professionalism and discipline in the software team; little use of software design tools; no system prototyping; design from scratch; an overrun on time; an overrun on budget; and incorrect trade-off of resources [40]. 2.3 Web-Based Applications Web-based applications handle information in its multiple forms (text, graphics, video and audio). The web-based applications vary in scope and complexity from small-scale to largescale applications distributed across the internet, intranets and extranets [41]. Pressman [2] addressed eight categories of web-based applications: informational (online newspapers); interactive (registration forms); transactional (electronic shopping); workflow-oriented (status monitoring); collaborative work (distributed authoring); online communities (discussion groups); web portals (shopping malls) and web services (enterprise applications). A webbased application may belong to more than one of the above categories. There are many quality criteria for the success of web-based applications such as reliability, usability, security, availability, scalability, maintainability and time-to-market that should be considered by the developers of web-based applications [42] Multidisciplinary Nature of Web Development Web engineering as suggested by Murugesan, et. al. [3] is bound to be a multidisciplinary field according to the nature of the web-based applications. It encompasses inputs from diverse areas such as human-computer interaction, user interface, systems analysis and design, software engineering, requirements engineering, hypermedia engineering, information structures, testing, modeling and simulation, project management, social sciences, arts and graphic design as shown in figure (2.1). 19

38 Human-Computer Interaction Testing Multi Media Project Management Software engineering Web Engineering Modeling and Simulation Hypertext Information Engineering Requirement Engineering System analysis and design Figure (2.1): The Web Engineering A multidisciplinary field [3] Web-Based Applications versus Traditional Software Both of software engineering and web engineering involve programming and software development. While web engineering adopts many software engineering principles, it incorporates many new approaches, methodologies, tools and guidelines to meet the unique requirements of web-based systems [4]. Developing web applications is significantly different from traditional software development and poses many additional challenges. There are major differences in the nature and life cycle of web-based applications and traditional software systems and the way in which they are developed and maintained. The development of webbased applications is a mixture between print publishing and software development, between marketing and computing, between internal communications and external relations, and between art and technology [2]. There are a number of criteria that differentiate web-based application s development from traditional software development such as [16][30]: shortdevelopment life-cycle times; delivery of bespoke systems integrating software and data; multidisciplinary development teams; and more rigorous requirements analysis Characteristics of Simple and Advanced Web Applications Simple web-based applications are: textual information in non-core applications; information content fairly static; simple navigation; limited usefulness, interactivity and functionality; high performance not a major requirement; developed by a single individual or by a very small team; security requirements minimal; easy to create; and feedback from users unnecessary [4][41]. The advanced web-based applications are dynamic web pages because information changes with users needs; large volume of information; difficult to navigate and find information; integrated with database and other planning and scheduling systems; high performance and availability is necessity; may require a larger development team with expertise in diverse areas; needs risk and security assessment, configuration control, management and project plan; and requires a sound development methodology [4][41]. 20

39 2.3.4 The Components of Web-Based Applications The web-based application consists of three-tier architecture: The client, the web server and the database. The client provides the user interface for the web-based application. It is important part because web application is more user-oriented than traditional systems. The web tools can be used to automate some of the designing tasks of the web interface by generating HTML code. The construction of web user interfaces must rely on principles of the human-computer interaction. The web server provides the business logic of web-based applications and it is responsible for interacting with client and database. The web server accepts user request for data from the client, retrieves the data from the database and then responds to the client request. The Java Servlets and Scripts can be used for implementing the web server [43]. The database maintains data needed for the web-based application. The web server can communicate with database via JDBC (Java Database Connectivity). The JDBC is built around the structured query language (SQL) which can be used to manipulate a variety of databases without dealing with specificity of those databases [43] The Basic Requirements for Web Engineering The basic requirements for web engineering are: scalability to enable future service extensions; simple update mechanisms for content managers; a consistent navigational model for users; versioning mechanisms to keep track of changes in content, functionality and layout; location independence for migrating the service; and device independence for supporting the wide range of devices through which users can access the web [44]. There are other requirements to better handle special characteristics of developing web applications such as [45]: how to make systems usable for diverse spectrum of users; how to handle continuously updated with large amounts of information and how to deal with multimedia Challenges of Web-Based Applications Development The developers of web-based applications need an iterative process that outlines the various development phases to better manage the development of web-based application in a systematic manner [5]. This process should be planned well and clearly define a set of manageable steps that developers can follow to help them successfully manage, minimize risks, deals with the likelihood of change and delivers web applications within time. The accurate estimation of work and time required to develop a web application is difficult process [5]. Organizations of web applications development face unique challenges based on rapidly changing markets, demanding customers with poorly-defined requirements, and resulting priority conflicts between product development and customer projects. Alan Hevner, et. al. [46] identified a model for development environment by identifying critical challenges 21

40 to successful development of web-based applications. These challenges are: organization structure and inter-unit communications (achieving effective communication in organizational flux; managing market versus customer goals; and positioning the product function); relationship with the external environment (maintaining customer engagement); and new technology development environment (leveraging e-commerce technology; provisioning e- commerce standards and measuring for improvement). 2.4 The Software Development Process A software process is a set of activities and associated information that are required to develop a software system and are carried out by software engineers. The specification, development, validation and evolution are fundamental process activities [2][37]. Every organization has its own specific software process but these individual approaches follow some more abstract generic process model [47]. A software process model is an abstract representation of a software process from some particular perspective [2][48]. Different software processes organize these activities in different ways. Different organizations may use different processes to produce the same type of software product. Some processes are more suitable than others for some types of software. If an inappropriate process is used, this will probably reduce the quality of the software to be developed [2][37]. Software process research deals with the methods and technologies used to assess and improve software development activities. Software development technology is technological support tools, infrastructures and environments used in the software development activities. We need proper technology that makes it possible to create complex software products. Software development methods and techniques are guidelines on how to use technology and accomplish software development activities [49]. The activities that must be carried out during the development of a software system are: system initiation/planning; requirement engineering; architectural or large-scale design; small-scale design or detailed design; coding; system integration; documentation revision and system delivery; validation and verification; and maintenance. In some process models, all of these stags are visible but in other process models some of these stages become part of some other stage [50] The Perceived Problems in Software Development The goals that software development seeks to achieve are: meeting users' needs; low cost of production; high performance; portability; low cost of maintenance; high reliability; and delivery on time. Many goals are conflict with each other as shown in figure (2.2). For 22

41 example, low cost of construction and high reliability conflict. Some goals do not conflict with each other such as low cost of maintenance and high reliability is complementary [9]. Ease of maintenance Cost of production Meeting deadlines Reliability Performance Conflicting goals Complementary goals Figure (2.2): Complementary and Conflicting Goals in a Software Project [9] The Basics of Good Software Development Jim Cooling [40] suggested that achieving delivery of good software on time and within budget depends on many factors such as: determine a clear statement of software requirements; ensure that the design solution is capable of achieving this goal; organize the development so that the project is manageable and the timescales can be met; make sure that the design can be changed without major rewrites; design for testability; minimize risks by using trusted methods; ensure that safety is given its correct priority; make sure that the project does not completely rely on particular individuals; and produce a maintainable design Ad-hoc Development The development of early systems took place in a chaotic manner depending entirely on the skills and experience of the individual staff members performing the work. Today, many organizations still rely on ad-hoc processes and do not take advantage of software engineering methods either entirely or for a certain subset of their software development [51]. Although there is no idle software process, there is a lot of scope for improving the software process in many organizations. Processes may not take advantage of the best practice in software engineering. The Software Engineering Institute at Carnegie Mellon University points out that with ad-hoc process models, the process capability is unpredictable because the software process is constantly changed as the work progresses. Schedules, budgets, functionality and product quality are inconsistent. Performance depends on the capabilities of individuals and varies with their skills, knowledge and motivations. Performance can be predicted only by individual rather than organizational capability [52]. Mark Paulk, et. al. [53] addressed that some individual software projects produce excellent results in undisciplined organizations through the efforts of a dedicated team rather than through repeating the software process methods of an organization. Repeating results in the absence of an organizational software 23

42 process depends entirely on having the same individuals available for the next project. Success that depends solely on the availability of specific individuals provides no basis for long-term productivity and quality improvement throughout an organization The Importance of Software Process in Large Organizations The software process is a technical framework established for applying tools, methods and people to the software task. The organizations need a defined software process to provide them with a consistent framework for performing and improving their work. When several people work on a common project, they need some way to coordinate their work. For small tasks, this can be done informally, but with larger numbers of people or more complex tasks, more formal arrangements are needed [54]. Dorothy Graham [55] addressed the main problems of large software development such as: it is difficult to estimate the cost, effort, time or size of large systems with a high degree of accuracy; the problem of changing requirements during the development process; significant problems are experienced in the testing and maintenance of large systems; and finally lack of customer confidence. According to above problems, he suggested developing incrementally towards the needed system, confidence is restored to a high level which is then maintained and increased [55]. The process of developing large software systems must be treated at least in part as a learning and communication process [56] Traditional Software Process Models (Heavyweight) Many software development process models are developed to support software development process activities. The most well known used software process models are Waterfall, Build and Fix, Incremental, Prototyping, Rapid Application Development (RAD), Spiral, and Rational Unified Process (RUP). Each model has its own approach, strengths and limitations [2]. There are many problems of traditional software process models. The most frequent criticism of these methodologies is that they are bureaucratic. The several phases in the system development slow down the development process. The second problem with these methodologies is that the requirements specifications are not flexible since it is difficult to get the customers to identify their requirements. Even if the requirements can be identified, the business world is forever changing [2][37] Waterfall Software Process Model The waterfall model is the first published software development process model that consists of six stages: requirements analysis phase; system and software design phase; implementation and unit testing phase; integration and system testing; and operation and 24

43 maintenance phase. The strengths of waterfall model are that: it divides a complex task into smaller tasks; testing is inherent to every phase of this model; documentation is produced at every stage; and the progress can be evaluated at the end of each phase [57]. The waterfall model limitations are that: unresponsive to changes; this model has difficulty accommodating the natural uncertainty that exists at the beginning of the project; the customer only sees a working version of the product after it has been coded; difficult to define all requirements at the beginning of a project; and high maintenance costs [48][58] Incremental Process Model This model combines elements of waterfall model applied in an iterative fashion. When this model is used, the first increment is a core product is used by the customer but many supplementary features remain undelivered. As a result of evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of customer and the delivery of additional features. This process is repeated until the complete product is produced. Incremental development is useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Early increments can be implemented with fewer people [2][48] The Rapid Application Development (RAD) Model The RAD is an incremental software process model that emphasizes a short development cycle. This model is a high-speed adaptation of waterfall model in which rapid development is achieved by using a component based construction approach. If requirements are well understood, the RAD process enables a development team to create a fully functional system within a short time period (60 to 90 days). RAD consists of communication, planning, modeling, design, construction and deployment activities [59] Prototyping Model This is an evolutionary model which consists of two types: Throwaway and Evolutionary Prototype. The result of Throwaway Prototype is a system specification but the result of Evolutionary Prototype is a final system. Throwaway Prototype is the creation of an incomplete model of system parts at early stage that will be discarded rather than becoming part of finally software [60]. After the requirements gathering stage as shown in figure (2.3), a simple model of the system is constructed to visually show the users what their requirements may look like when they are implemented. The Prototype advantages are: the designer can obtain feedback from users early; the contractor can compare if delivered software matches the software specification; allows the software engineer estimates accuracy and whether the 25

44 deadlines proposed can be successfully met; increasing user involvement and get quick feedback [60]; and finally reducing the time and costs because making changes early in development lifecycle is cost effective since there is nothing to redo. If a project is changed after a considerable work has been done then small changes could require large efforts [61]. Prototype have disadvantages: insufficient analysis; user confusion of Prototype and finished system; excessive development time of Prototype; expense of implementing Prototype (training for using Prototype) [61][9]. Outline specification Construct Prototype (according to requirements analysis and definition) Test (Check with user) Refine Prototype OK? No Yes Specification Figure (2.3): The Throwaway Prototype Spiral Software Process Model This model combines the iterative nature of Prototype with the controlled aspects of Waterfall model to provide rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being Prototypes. Later iterations become increasingly more complete versions of the software. The Spiral model is divided into a number of task regions as shown in figure (2.4): customer communication with developers; planning to define resources, time lines and other project information; risk analysis to assess technical and management risks; engineering task to build more representations of application; construction and release to construct, test, install and provide user support (documentation and training); and finally obtain customer feedback based on evaluation of the software representation created during engineering stage [62]. The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal results in a deliverable. The first and second Spiral traversals result in specification and Prototype production. Subsequent traversals may produce more sophisticated versions of the software. The Spiral model has explicit consideration of risk. There are no fixed phases such as specification or design and it encompasses other process models. The Prototyping may be used in one Spiral to resolve requirement uncertainties to reduce risks. This may then be followed by Waterfall development. Each passage through 26

45 planning stage results in an adjustment to project plan (cost and schedule are adjusted based on customer feedback; project manager may adjust number of iterations required to complete the software) [62]. Figure (2.4): The Spiral Software Process Model [62] Rational Unified Process Model (RUP) The RUP is an iterative software development process created by the Rational Software Corporation in the 1980s and 1990s. The RUP is not a single concrete prescriptive process, but an adaptable process framework to be tailored by project teams that will select elements of the process that are appropriate for their needs. RUP is based on software development principles and best practices such as: develop software iteratively; manage requirements; use component-based architecture; visually model software; verify software quality; and control changes to software. The RUP lifecycle is an implementation of the Spiral model. The RUP lifecycle organizes the tasks into phases and iterations. A project has four phases: inception phase; elaboration phase; construction phase; and transition phase. In inception phase, the business case which includes business context, success factors and financial forecast is established. To complement business case, a basic use case model, project plan, initial risk assessment and project description are generated. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. In construction phase, the main focus goes to development and coding of system components being designed. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable Prototypes. In the transition phase, the product has moved from development organization to the end user. The activities of this phase include training of the 27

46 end users and maintainers and testing of the system [63]. As shown in figure (2.5), within each iteration, the tasks are categorized into nine disciplines: engineering disciplines (business modeling discipline; requirements discipline; analysis and design discipline; implementation discipline; test discipline; and deployment discipline); and supporting disciplines (configuration and change management discipline; project management discipline; and environment discipline) [64]. Figure (2.5): The Rational Unified Process [63] Agile Process Methodologies (Lightweight) Agility can be applied to any software process to result in: effective response to changing requirements throughout the development process; effective communication among all stakeholders; drawing the customer onto the team; and organizing a team to control of the work performed to develop software iteratively and delivers multiple software increments and it adapts as changes occur [65]. Agile software development processes are approaches to build systems that emphasize evolutionary development, customer-centricity and lowdocumentation/specification overhead [66]. The Agile Manifesto and its four values establish a common framework for these processes [67]: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over a following plan. A software process is considered agile when it conforms to these above four values and principles [68]. The 12 principles introduced behind agile manifesto are: customer satisfaction; welcome changing requirements; deliver working software frequently; business people and developers must work together daily throughout the project; build projects around motivated individuals; face-to-face conversation within development team; working software is the measure of progress; agile processes promote sustainable development; continuous attention to technical excellence; simplicity; self-organizing teams; and effectiveness [67]. 28

47 There are various agile software processes such as: Agile Manifesto, XP, Scrum, Crystal family, Feature-Driven Development (FDD), Lean Development (LD), Dynamic System Development Method (DSDM), Agile Modeling (AM), and Adaptive Software Development (ASD) method [68]. Many researches and reports in the literature: provided a comprehensive overview and a detailed analysis of various agile methods and their applications [69][70]; summarized empirical studies and lessons learned [71][72]; and finally described and compared some of the more popular methods [73][74] Extreme Programming (XP) XP is the most widely used agile software development methodology and it is one of the most discussed subjects in the software development community [75]. It is originally proposed by Kent Beck [76]. The main aim of XP is to reduce the cost of change by introducing basic values, principles and practices. In traditional development methods the requirements for the system are determined at the beginning of the development and often fixed from that point on. This means that the cost of changing the requirements at a later stage will be high [76]. XP is based on incremental development and continuous integration [77]. XP recognized five values: communication through documentation; simplicity in solution and refactoring; feedback from the system, customer and team; courage; and respect. The principles that form the basis of XP are based on values. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation. These principles are: feedback; assuming simplicity; incremental changes; and embracing change. XP describes four basic activities: listening; planning; designing; coding; and testing that are performed within the software development process [76][78]. The rules of XP are: planning game; small releases; metaphor; simple design; tests; refactoring; pair programming; continuous integration; collective ownership; on-site customer; 40-hour weeks; and open workspace [76]. The life cycle of the XP process is described in figure (2.6). The software industry has practiced pair programming (two programmers working side by side at one computer on the same problem) with great success for years. But people who have not tried it often reject the idea as a waste of resources. Adopt pair programming in software development process yields better products in less time and more confident programmers [79]. Finally, the XP methodology can be used for solving problem in an unpredictable software engineering environment. The XP practices have the ability to deal with unexpected changes resulting in better quality software. The XP practices are complementary to each other. It is best to use as many practices as possible to see the effectiveness of the methodology [80]. 29

48 Figure (2.6): The Life Cycle of the XP Process [70] StrengthS and Limitations of Agile Methodologies Agile processes focus on generating early releases of working software using collaborative techniques, code refactoring and customer involvement. The agile processes are based on software process models that support iterative, incremental development of software. The proper use of agile processes requires an understanding of the situations in which agile processes are and are not applicable [81]. Many researches and surveys have shown that agile methodologies are an efficient way for producing software with significant advantages in production costs, time-to-market, complexity and quality improvement over traditional methodologies. Even with such apparent advantages, the information technology industry has not seen large-scale adoption of agile methods [82]. While there are risks in implementing agile software processes, the benefits are significant and include [65]: shortened development cycle-time by 75%; higher stability of work-loads; higher flexibility to change of development plans; higher quality by earlier feedback from the customers; and higher utilization of work-load by developing software systems with a fixed number of developers. There are various sources that point out the shortcomings of the agile development methods such as: limited support for distributed development environments; limited support for development involving large teams; limited support for developing safetycritical software; and limited support for developing large and complex software. The limitations of agile management methods are: agile development methods do not scale; do not handle large teams well and only works for small to medium teams; and requires highly skilled and motivated individuals [81][82][83] Introducing Agile Methodologies in Large Organizations The requirements often change during the software development life cycle in today s software development environment to meet business needs [84]. Agile processes allow for changing requirements throughout the development cycle, stress collaboration between 30

49 developers and customers and early product delivery. The transition from traditional processes to agile processes affects the development team members, departments and management. Common and effective approaches should be taken to make this change [85]. The development teams range in size from two to several individuals in the software development organizations. Therefore, the development process that is appropriate for very large teams will not work well for tiny teams and vice versa. Small teams can be flexible and adaptable in defining and applying agile methods. For a team with size that exceed 10, the large team can be divided into collections of smaller independent sub teams, each no larger than 10 and the interfaces well defined between sub teams [84]. Successful large projects require many developers at various levels of effort. A requirement for the success of development teams is that everybody follows the principles of the XP such as: rapid feedback, assume simplicity, incremental change, quality work and respect each other [86]. As suggested by Mikael Lindvall, et. al. [87], the success of agile methods in large organizations requires teams of good people to be effective and trusted. The agile methods do not work for systems that have criticality, reliability and safety requirements. The agile methods are more appropriate when requirements are rapidly changing because these methods are based on close interaction with the customer for the rapid feedback. The organizations should analyze their past projects from the perspective of success factors such as culture, people and communication. To be agile is a cultural thing and the organization cannot be agile if its culture is not right. The teams need some amount of local control and they must have the ability to adapt working practices as they feel appropriate. Organizations that want to be agile need to have an environment that facilitates rapid communication between team members [87]. Finally, Barry Boehm [88] suggested that, the most important factor that should be determined when agile is applicable is the project size. Agile processes are more difficult for larger teams. At the same time, the bureaucracy created by traditional plan-driven processes does not fit small projects. Traditional processes are most needed in high-assurance software. Traditional goals of plan-driven processes such as predictability, repeatability and optimization are often characteristics of reliable safety critical software development [88] Agile Methodologies for Web-Based Applications Development Web-based applications are constantly changing, have short development cycles (3 to 6 months) and built by a small multidisciplinary team (3 to 10 people) [30]. Web-based applications present important characteristics that must be addressed by software engineering processes and techniques. The web-based applications have to be delivered for the clients within the time constraints due to its strategic nature [89]. The software organizations 31

50 continue to move toward the development of web-based applications and they assign such projects to small teams of qualified developers. Web-based applications demand faster time to market and the continual integration of new requirements. Therefore, such demands have increased the popularity of agile methodologies which let teams increase development productivity; maintaining software quality and flexibility; and increasing software organization s responsiveness. The XP focuses on small teams and lets them replace paperbased documentation with face-to-face communication. In XP, all developers work closely together and communicate informally rather than spending time documenting designs and decisions. The XP practices reduce management overhead, keep the customer s interest at close range and use the planning game that takes both business priorities and development team realities into consideration. As the development organization grows, the time spent exchanging product knowledge and training new people increases and often renders XP unsuitable [90]. Schatz and Abdelshafi [91] suggested that, adopting agile practices in web development is a process of continuous learning and improvement. The transition to agile required hard work and strict discipline to successfully deliver high quality web-based applications while improving quality of team members. The organization should begin working on team building and learning how to work better across the teams. The organization needs a sponsor- someone who is: willing to put everything on the line; committed to moving to agile; encourage the leaders; communicate the team s vision; focus on teamwork; do not work overtime; learn to negotiate and set expectations; and expect hard work [91]. Grossman, et. al. [92] suggested that, the XP make sense as a development methodology in a diverse and multidisciplinary web development environment by adopting all of the 12 XP practices. This environment includes diverse and distributed teams requiring close coordination with multidisciplinary skills (visual design, Java and others). The potential is to make the development process more responsive to users' changing requirements. This could have high impact on outcomes of the development process, decreasing cost, decreasing time to deployment and increasing user satisfaction. When the team is not following all the XP practices, the methodology appears to be working although exposing them to some risk. In some cases the team has been following modified additional practices such as stand-up meetings and pair coaching. The full set of practices is necessary when building a community with an agile culture [92]. Américo Sampaio, et. al. [89] described an agile process for webbased applications development (XWebProcess) which is based on XP and used for building high quality web applications in effective way. The XWebProcess is suitable to web development in dimensions such as requirements gathering, user interface design and testing. 32

51 XWebProcess seeks to combine the key elements of XP with process structures tailored to tackle the properties of web engineering [89] Agile Methods vs. Traditional Methods Agile processes focus on people over processes with less stress on documentation and more attention on delivering functionality at end of the each iteration. The agile methods have advantages over traditional plan-driven approaches such as: improving return on investment (ROI) by customer frequent feedback in each iteration; improving the software quality by test-driven development, short iterations and frequent customer feedback; early detection and cancellation of failing projects by executing design, analysis and implementation tasks repeatedly in short iterations to allow greater visibility; improving control over project by adopting short iterations, multi-disciplinary teams, knowledge sharing, continuous integration and feedback; and finally reducing dependence on individuals and increasing flexibility by creating teams of developers that collectively analyze, design and code software. This eliminates the possibility of any bottlenecks in the development process because the developers work individually on tasks [93]. Table (2.1) summarizes the comparison between traditional and agile methodologies [94]. Fundamental Assumptions Table (2.1): Traditional versus Agile Software Development [94] Traditional Agile Systems are fully specifiable, predictable and can be built through extensive planning. High-quality software can be developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change. Control Process centric People centric Management Style Command-and-control Leadership-and-collaboration Knowledge Management Explicit Tacit Role Assignment Individual- favors Specialization Self-organizing teams encourage role interchangeability Communication Formal Informal Customer s Role Important Critical Project Cycle Guided by tasks or activities Guided by product features Development Model Life cycle model (Waterfall, Spiral or some variation) The evolutionary-delivery model Desired Organizational Form/Structure Mechanistic (bureaucratic with high formalization) Organic (flexible and participative encouraging cooperative social action) Technology No restriction Favors object-oriented technology Each one of traditional software process models and agile methodologies has its strengths and limitations. Khan [72] suggested that, any organization should think when to use agile and traditional methodologies. Agile methodologies are used when the: requirements are unknown and uncertain; uncertain budget for resources; and unknown risks. Traditional methodologies are used when the: requirements are well known and stable; sufficient budget for resources; and well understood risks. Finally, the compromise between agile and traditional approaches may need to be based on the nature of the project being undertaken. 33

52 Projects are different in size, application domain, criticality and innovativeness. Agile approaches are more suitable for developing small projects [95] Mixing Agile Methods with Traditional Methods The software development can not be considered a defined process because too much change occurs during the development process. It is highly unlikely that any set of predefined steps will lead to a desirable, predictable outcome because requirements changes, technology changes and people are added and taken off the team. The focus currently is how to mix agile methodologies with plan-driven approaches for software development. Any organization should determine the agile properties versus plan-driven properties; highlight the risks associated with each approach; should describe how they would choose which approach to use; should be careful for how and when to mix the two approaches; and under what circumstances they would mix them. [96]. The agile methodologies promise higher customer satisfaction, faster development times and a solution to rapidly changing requirements. The plan-driven approaches promise predictability, stability and high assurance. Both approaches have shortcomings that, if left unaddressed, can lead to project failure [97]. Boehm and Turner [97] listed in their research three categories of risk that can affect the choice of using the agile or plan-driven approach: risks stemming from an agile approach such as scalability, criticality, design simplicity and staff skills; risks stemming from a plan-driven approach such as emerging requirements, constant change and need for rapid results and staff skills; and general environmental risks such as technology uncertainties, diverse stakeholders and complex systems [97]. They established a framework for examining the development approaches characteristics according to these risks. They discussed how they handled diverse interest groups developing a project; lack of testing on the customer s side; imprecise requirements; long-term planning and dependencies among non programming tasks. Their suggested method is summarized in table (2.2) that uses risk analysis and a unified process framework to tailor risk-based processes into an overall development process. The method relies heavily on ability of key team members to understand the organizational capabilities and to collaborate with project stakeholders. Risk analysis is used to define a set of defined risks they see associated with agile and plan driven methods [98]. Today s environments of increasing business change require more adaptable software development methodologies. The software development units face new risks as shortfalls in real-time performance, unrealistic schedules and budgets, development of wrong software solutions and rapidly changes in requirements. Then, organizations focus on development approaches that increase their responsiveness to business 34

53 change. Agile methodologies provide organizations with ability to rapidly evolving systems solutions. The organizations develop their own customized versions of these agile approaches to suit their development needs and environment. As suggested by Peter Meso and Radhika Jain [99], the process of developing software solutions comprises interactions among three dimensions: stakeholders in a development project; process-guidelines to provide a direction to the development effort; and software product generated as a result of this development effort. The project managers of organizations should map agile practices along these three dimensions by identifying the correct set of metrics. The development team frequently adjusts its focus and structure to best address these dimensions to remain responsive. The agile methodologies emphasize a sufficient amount of planning in each iteration and minimal emphasis on documentation [99]. Table (2.2): The Summary of Risk-Based Method [98] Step 1 : Rate the project s environmental, agile, and plan driven risks. Step 2a: If agility risks dominate plan-driven risks, go risk based plan-driven. Step 2b: If plan-driven risks dominate agility risks, go risk based agile. Step 3 : If parts of the application satisfy 2a and others 2b, architect the application to encapsulate the agile parts. Go risk-based agile in agile parts, and risk based plan-driven elsewhere. Step 4 : Establish an overall project strategy by integrating individual risk mitigation plans Step 5 : Monitor progress and risks/opportunities. Many organizations of applications development are attempting to utilize both agile and traditional approaches. Although, the adoption of agile methodologies improves the productivity, quality and business satisfaction, there is also necessary need for other methodologies. Vishnu Vinekar, et. al. [100] suggested that, the agile development of systems requires a suitable organizational culture. It may be difficult to adopt all agile practices in projects that have stable requirements. New organizational structures are needed to sustain these opposing cultures so that organizations can get the full benefits of both agile and traditional systems development. There is a need for simultaneously managing agile and traditional systems development. The client s culture may be the deciding factor in using agile or traditional methods for a project [100]. The development teams in any organization need to find specific project characteristics to determine if they use agile or plan-driven methodology, or hybrid of the two to develop projects [87]. Although many of their advocates consider the agile and plan-driven development methods polar opposites, synthesizing the two can provide developers with a comprehensive spectrum of tools and options [88]. Finally, as suggested by Boehm and Turner [97], there is a pragmatic need to balance stability and agility. The analyzing of agile and traditional approaches based on: application characteristics, management characteristics, technical characteristics, and personnel 35

54 characteristics. The choice of traditional or agile methods for a given project is largely contingent on five factors: the size of the systems development project and team; the consequences of failure; the degree of dynamism of the environment; the competence of personnel; and compatibility with the prevailing culture. The traditional development is desirable when the requirements are stable and predictable and when the project is large and complex. Agile development is suitable when there is a high degree of uncertainty and risk in the project, arising from frequently changing requirements and/or the novelty of technology used. Large and complex projects more suited to the traditional approach making agile development a suboptimal choice. The agile methodologies need a suitable organizational culture to sustain it, one that is very different from organizational culture needed for traditional methodologies [97] Challenges to Implementing Agile Processes in Traditional Organizations Any organization faces several challenges when attempt to use both agile and traditional development on different projects. This is because the variations between projects and clients characteristics and it may be very difficult to change the development organization s characteristics from project to project. Nerur, et. al. [101] viewed these challenges at four levels: management and organizational, people, process and technology. Agile and traditional development has conflicting organizational cultures, management styles and organizational forms [101]. Also the managers face several barriers when they try to use agile approaches into traditional organizations. Boehm and Turner [102] suggested the following approaches to help organizations integrate agile practices into their traditional processes: do some serious preparation up front; build up processes rather than tailoring them down; define specific functionality that you are going to address with agile approaches; develop architectures that support compartmentalization of agile and traditional teams; redefine traditional milestone reviews to better fit an iterative approach; implement agile practices that support existing processes; evaluating risks is the best overall approach to determining how much agility is enough [102]. 2.5 Web-Based Applications Development Process Web engineering deals with all aspects of web-based applications development such as: conception, development, implementation, performance evaluation and continual maintenance. Building and deploying web-based applications involves multiple and iterative steps [4]. Complexity, changeability, invisibility and unrealistic schedule are many of the aspects that make web-based application difficult. Murugesan, et. al. [3] suggested that, the organizations need a process model that describes the phases of web-based applications 36

55 development to reduce the difficulty in building web-based applications. This process model should help developers to address the complexities of web-based applications, minimize development risks, deal with likelihood of change and deliver the web-based application quickly while providing feedback [3] The Web Engineering Process Model (WebEng) Pressman [2] suggested framework of web engineering process model (WebE) as shown previously in figure (1.1) in chapter1, which accommodate incremental delivery, frequent changes and short timeline. The web-based applications developers employ WebE model that consists of the following steps to direct project s life cycle and building cost-effective and quality web-based applications [2]: 1. Customer communication: Business analysis defines the organizational context for the web-based application. Formulation is a requirements gathering which involve all stakeholders to describe the problem that the web-based application is to solve. 2. Planning: the plan consists of a task definition and a timeline schedule for the time period projected for the development of the web-based application s increment. 3. Modeling: consists of analysis model that establishes a basis for design (content, interaction, functional and configuration analysis). The modeling consists also of design model that represents key web-based application s elements (content, aesthetic, architectural, interface, navigation and component design). 4. Construction: web engineering tools and technology are applied to construct the webbased application that has been modeled, then testing of all design elements. 5. Delivery and evaluation: configure for its operational environment. Deliver to end-users, and evaluation feedback is presented to the development team. The increment is modified as required Factors Responsible for the Failure of Web-Based Applications Many organizations and enterprises have successfully developed large and highperformance web-based applications, but others have failed. The primary reasons of these failures are: a lack of vision, shortsighted goals, a flawed development process and poor management of development [5]. Many researches in the literature addressed the factors responsible for the failure of web-based applications. A survey by the Cutter Consortium [19] highlighted serious problems affecting the large web projects development such as: delivered systems did not meet business needs 84%; schedule delays plagued the projects 79%; projects exceeded the budget 63%; delivered system didn t have required functionality 53%; and deliverables web-based applications of poor quality 52%. Another survey of web 37

56 development organizations by McDonald and Welland [16] and the outcome of this survey outlined major problems such as: problems with requirement analysis phase; poor project management; poor project estimation; inadequate testing; and focus on implementation with amalgamation of requirements capturing and designing. Whereas, Kushwaha, et. al. [20] addressed in their research the factors responsible for failure of web applications such as: faulty evaluation of existing applications; poor evaluation of cognitive characteristics of users; neglecting cognitive characteristics of application developers; ignorance of socioethical issues; flawed design and development process; poor management of development efforts; poor understanding of methodology to develop large web systems; variation in user preferences; and improper color mix and ignorance of aesthetic values. Finally, Bolmeson [103] addressed common problems experienced in failed web development projects such as: unstructured development projects which differ in structure from project to project; lack of testing; inexperienced developers with various background; difficulties with configuration management and documentation; difficulties with frequent changes in requirements; customers without clear goal specifications; budget and time-frame exceeds; no environment, programming or coding standards; lack of involvement of nonengineering personnel; no maintenance or evolution planning; lack of extensive stakeholder analysis; high system complexity; and difficulties with project measurement and evaluation Steps for Successful Web-Based Applications Development According to the literature studies, there are no key steps that should be followed to successfully developing large web applications. Athula and Murugesan [5] recommended 10 key steps to follow for successful developing web-based applications in general without mention to the size of these applications. These steps are: understand all functions, environment and objectives of web application; identify stakeholders; specify requirements of both stakeholders and web application; develop architecture that meets all requirements; identify subprojects to implement the architecture; develop the subprojects; use mechanisms to manage the web application s evolution and maintenance; specify organizational and management policies, human resources development, and legal, cultural and social aspects; measure system performance; and refine and update the web-based application Large-Scale Web-Based Applications Development The development of web application is similar to the development of traditional application and it is iterative in nature [104]. Nahrstedt and Balke [105] suggested that, building large web applications are always difficult, costly, time-consuming and challenging 38

57 problem because these applications consist of huge number of complex activities and developed by more than 50 developers working to develop a complex web application. Also, these large web applications will run on heterogeneous network and system platform, hence they faced both system challenges and network challenges [105]. Balasubrantanian, et. al. [104] suggested that, the development of large web applications should be carried out only through careful planning and systematic design methodology, and by integrating management and web technologies. While there is nothing that will guarantee success, developers should take in their considerations during the development process of large web applications five factors which are scalability, availability, manageability, security and use proper development practices to greatly decrease the failure of large web applications [42] Requirements Engineering (RE) in Web Development Requirements engineering is concerned with the identification of the goals to be achieved by the system to be developed, and the assignment of responsibilities for the resulting requirements to humans, devices and software [106]. The RE process discover the system purpose by identifying stakeholders and their needs, and documenting these in a form to analysis, communication and implementation. Nuseibeh and Easterbrook [107] suggested that, there are a number of difficulties in RE process. Stakeholders including customers, users and developers may be numerous and distributed. Their goals may vary and conflict depending on the environment in which they work and the tasks they wish to accomplish. Their goals may not be explicit and hence, the satisfaction of these goals may be constrained by many factors [107]. Many researches [108][109][110] identified a set of core RE activities as shown in the table (2.3) to help develop a sufficient set of requirements. Activities Requirements Elicitation & Analysis Requirements Specification Requirements Validation Requirements Prioritization Requirements Reuse Requirements Tracing Table (2.3): The Core RE Activities [108][109][110] Description Elicit requirements: type of requirements, requirements gathering, and analysis techniques. Specifying requirements: techniques used for the documentation of requirements. Validating and verifying the requirements specifications via review, walk-through, and checklist. Prioritize the set of requirements either on an ordinal or absolute scale. Reuse previously developed artifacts in RE activities of a new project. Trace requirements to source, rationale, etc. The problems of system RE are universal and very significant [111]. Boehm [112] suggested that, the errors in system requirements could be up to 100 times more expensive to 39

58 fix than errors introduced during system implementation [112]. Lamsweerde [106] suggested that, getting high quality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as a most importance area in software engineering research and practice [106]. Maguire and Bevan [113] suggested that, understanding user requirements is an integral part of systems design and it is critical to the success of these systems. Specifying these requirements is not simple to achieve. They described general methods to support user requirements analysis that can be adapted to a range of situations. The basis of different methods of user requirements encompassing four elements as shown in figure (2.7) [113]. Figure (2.7): The General Process for User Requirements Analysis [113] Li Jiang, et. al. [114] suggested that, the adoption of the most suitable RE process and selection of the most appropriate RE techniques for a given project is a common challenge faced by the industry. They presented a methodology for RE process development for any project. This process focused on: establish RE process knowledge base (REPKB) to help during RE process development; provide decision support mechanism during RE process development; use three components (process building blocks, standard templates of the RE process, and development guidelines) to help process development; and finally link project characteristics with RE process development so that the most suitable RE process can be developed. They suggested that this methodology is of valuable help to requirements engineers during RE process development [114]. The RE discipline has become more important in the last years. Tasks such as the requirements elicitation, the specification and validation of requirements are essential to assure the software quality. The development of web applications involves more heterogeneous stakeholders and additional requirements for the navigational and multimedia aspects than the construction of traditional software [115]. Therefore, Escalona and Koch [115] suggested that, a thoroughly requirements analysis is even more relevant. Most of the methodologies that have been proposed for the development of web-based applications focused on the design paying less attention to the requirements engineering. They conducted a comparative study of the requirements handling in web methodologies showed trends in the use of techniques for capturing, specifying and validating web requirements. 40

59 2.5.6 The Modeling of Web-Based Applications Web-based applications are becoming more complex due to several factors such as a larger number of hyperlinks, more complex interaction and increasing the use of distributed servers. Models are: essential step in capturing system behaviors; providing an abstract view of the application; helping designers during design phase by formally defining requirements and providing multiple levels of detail; simplifying any analysis required to check software quality; verification and testing; and managing systems complexity. Different models of web applications have been proposed, while others have been adapted from existing modeling techniques for other software types. Most of the early literature concentrated on the process of modeling the web applications design. It proposed forward engineering based on methodologies designed to simplify the process of building web-based applications. Other researches used reverse engineering methodologies to extract models from existing web-based applications to support their maintenance and evolution [116]. As addressed by Manar Alalfi [116], the web-based application has three orthogonal perspectives: web navigation, web content and web behavior. Desirable properties of web applications can fall within these three dimensions and can be classified into: static navigation; dynamic navigation; interaction navigation; static content; dynamic content; security; and instruction processing properties Model-Driven Development (MDD) of Web-Based Applications Model-driven development is an automatic code generation of web-based applications from high-level feature specifications. As addressed by Doyle and Lopes [117], model-driven development technologies for web-based applications aim to simplify the development process by generating deployable sites from presentational, behavioral and navigational requirements specified in models. Model-driven development technologies aim to reduce the dependency on low-level programming (automatic programming and CASE) by raising the abstraction model to a higher level. Adaptation to web development required creation of new kinds of models and techniques that better match the unique properties of web-based applications [117]. MDD is becoming a widely accepted approach in different software engineering domains. The basic idea of MDD is to separate the platform independent design and the platform specific implementation of applications and delaying as much as possible the construction of models related to specific technologies [118]. As suggested by Koch, et. al. [119], web engineering is a concrete domain where MDD may be helpful particularly in addressing the problems of emerging platforms and changing technologies. The Model Driven Architecture (MDA) offers suitable principles to define model-driven approaches using standard notations 41

60 [120]. Figure (2.8) shows adaptation of MDA principles to the web development visualized as a UML activity diagram. Models are depicted as objects and transformations are represented with activities (special circular icon) [118]. The process proposed by Koch, et. al. [118] starts with the business model (CIM) level defining requirements models. Platform independent analysis models (PIMs) are derived from the requirements based on additional information. On the PIM level, the concerns of web applications: the content, the navigation, the business processes and the presentation are designed in separate models. These models are integrated into a big picture which merges all concerns together and it is used in validation of the design models. Finally, the platform specific models (PSMs) are derived from this validation model. The program code can be generated from these PSMs [118][121]. Figure (2.8): The Model-Driven Approach for Web Systems [118] Design Models for Web-Based Applications The good design models help the designer to be able to formulate and discuss her/his ideas without starting any implementation [26]. The web has been established as a major platform for web-based applications. The increasing complexity of web-based applications makes a disciplined approach for development. Therefore, Gaedke and Graef [122] suggested that, it is desirable to use component-based software development in web engineering, but this is made difficult through the web principles that demand autonomous development within a heterogeneous environment. Since the end of the 1980s several new models have been introduced that based on the traditional process models and focused on the object-oriented development of software systems [122]. The Hypertext Design Model (HDM) [123][124] is a design model for the structured design of hypertext applications. It supports the design phase of hypermedia applications and can be integrated with existing process models. HDM requires that the application uses a consistent and predictable environment. The applicability of HDM is limited by its methodology. The mapping of a hypertext application designed with 42

61 HDM to a web application is difficult because the lacking of an appropriate support. The Object-Oriented Hypermedia Design Method (OOHDM) [125] offered a defined procedure for hypermedia applications development. OOHDM consists of four steps: conceptual design, navigational design, abstract interface design and implementation which have to be executed according to an iterative and incremental process model [125]. As suggested by Schwabe and Rossi [126], a web-based application can be described with the help of three models: the conceptual model which corresponds to object-oriented model and describes design entities using UML notation; the navigation model which describes the navigational view on the conceptual model; and the abstract interface model which describes the presentation of interface objects. The modularity and reusability of design concepts is high due to the high degree of abstraction found in the resulting models [126]. Isakowitz, et. al. [127] proposed the Relationship Management Method (RMM). The RMM is a platform-independent process model for hypermedia applications that can be used for the development of web-based applications. The RMM model consists of seven phases and it focuses on the design, development and construction phases. An important aspect associated with the use of this process model is the support through a tool [127]. De Troyer and Leune [128] presented the Web Site Design Method (WSDM). This method is focused on user-centered rather than data-centered design. The design is driven by the views of different user-classes instead of the available data. This process model is limited to a class of pure information systems. It does not support the user-class "application web-sites" that encompasses more complex application systems. Typical problem areas such as maintenance are not explicitly addressed. Like in other models there is no explicit support for reuse. Finally, Gaedke and Graef [122] proposed a WebComposition process model that consists of several phases which are derived from the common phases of object-oriented process model. This model follows an evolution Spiral consisting of evolution analysis and planning, evolution design and evolution realization. This model describes a consistent approach to the development of web applications as component software. This model is an open process model that allows for the integration of arbitrary processes for the development and reuse of components. Reuse is supported by modeling all artifacts during life cycle of an application component as standardized components. The reuse model supports the use of artifacts by different processes [122]. Many literatures [122][129][130] presented a brief description and a comparative study of most relevant web development methods published in the last few years. Most of these methods focused on the design of web applications; only few cover more 43

62 aspects of the life cycle, such as requirements capture, implementation and/or testing. They compared the main concepts and the steps of these design methodologies Cost, Effort and Time Estimation of Web-Based Applications Cost estimation is important for controlling and planning software risks and scheduling in software development. Cost estimation models are used for budgeting; risk analysis; project planning and control; and software improvement investment analysis. One of the good cost estimation models is Constructive Cost Model (COCOMO) which is used for estimating software cost, effort and schedule and helps the projects managers to avoid insufficient resources being allocated to a project. This model helps the project stakeholders to make informed decisions about how to manage resources, how to control and plan the project, and how to deliver the project on time, on schedule and on budget [131]. The COCOMO also helps developers reason about the cost and schedule implications of their software decisions such as software investment decisions; setting project budgets and schedules; negotiating cost, schedule, and performance tradeoffs; making software risk management decisions, and making software improvement decisions [132]. Barry Boehm, et. al. [133] addressed the critical estimation dimensions such as: effort hours; staff size and deployment cost; hardware resource requirements; risk; and portfolio impact. Table (2.4) shows the important project factors that inform each one of estimation dimensions [133]. Table (2.4): Estimation Dimensions and Corresponding Project Factors [133] Estimation Dimension Project Factors Effort Hours Customer Complexity; Customer Geography; Developer Familiarity; Business Function Size; Target System Sophistication; and Target System Complexity Staff/Cost Effort Hours; Staff Productivity; Skill Level Development; and Rate at Each Skill Level Hardware System Category; Generic System Type; Operating Window; and Transaction Volume Risk System Size; Project Structure; and Target Technology Portfolio Resource Needs of Concurrent Projects; and Relative Project Risks Ian Sommerville [37] addressed software cost components such as: hardware and software costs; travel and training costs; effort costs; and effort costs must take overheads into account (costs of: building, heating, lighting; networking; and shared facilities). He addressed also, the software pricing factors such as: market opportunity; cost estimate uncertainty; contractual terms; requirements volatility; and financial health. Estimation subtasks are estimating software size; estimating development productivity; estimating contractor productivity; and estimating staffing [37]. Capers Jones [134] suggested that, for large software projects, automated estimates are more successful than manual estimates in terms of accuracy and usefulness. The costs of large projects include defect removal, production of paper documents, coding, project management, and dealing with new requirements that appear 44

63 during the development cycle. Successful estimates for large projects must be adjusted to match specific development processes to match the experience of the development team, and to match the results of programming languages and tool sets that are to be utilized. Simple manual estimates can not encompass all of adjustments associated with large projects [134] The Stakeholders of Web-Based Applications Stakeholders are persons affected by the system or who have influence on system development. There are two main groups of stakeholders: customers (users and system owners); and developers (analysts, designers, programmers, etc.). The customer is the person who pays for the development and is responsible for making decisions. Even if the customer is not always right, the customer s requirements can not be changed or rejected by developers. Any conflicting or illegal requirements must be renegotiated with customers [135]. Pfleeger [136] addressed the main causes of software failure can be traced to the stakeholder factor. At the customer end, projects fail because: customer needs are misunderstood or not fully captured; customer requirements change too frequently; customers are not prepared to commit sufficient resources to the project; customers do not want to cooperate with developers; and customers have unrealistic expectations [136]. Bailey, et. al. [137] addressed four other stakeholder groups who affect or are affected by the adoption of a new software development process such as: Quality Assurance (QA) to perform activities relating to system testing, code quality, and defect analysis; Documenters to write various types of documentation for a software product ranging from technical documentation to user manuals and marketing material; Project managers to have overriding responsibility for the delivery of a project and act as the central link between the programmers and management; and finally Management to have overall responsibility for a company s performance with reporting duties to directors and/or shareholders and investors [137]. Finally, Stoica, et. al. [138] suggested that, the involvement of all the stakeholders is a key component for the success of the web development process. It is very complex task to motivate all stakeholders to take part and provide information/feedback [138] Project Planning Project planning is the process of estimating the deliverables, costs, time, risks, milestones and resource requirements of the web-based application. It also includes the selection of development methods, processes, tools, standards and team organization [135]. Project planning is a moving target. It is not something you do once and never change. Project plans evolve with the lifecycle within the framework of a few fixed constraints. Typical constraints are time and money, each project has a clear deadline and a tight budget. One of the first tasks 45

64 in project planning is to assess whether the project is feasible under the time, budget and other constraints [135]. The constructed project plan will constitute the guidance for project and process management. The project plan addresses the following issues: project scope; project tasks; directing and controlling the project; quality management; metrics and measurement; project scheduling; allocation of resources (people, material and tools); and people management [139] Management of Web Development The management of the software development process has several advantages. Project plans become more realistic because they are based on past history rather than guesses and the organization is in a better position to plan future projects. More realistic project plans mean that the resource scheduling can be achieved realistically and deadlines are more likely to be met. Project management is assisted by allowing all information about process definitions and metrics information to be readily accessible to management in an understandable manner. Improved project planning is facilitated through the storage of information from previous projects and allowing this to be viewed at any time. This permits planning decisions to be made on past organizational history. It is important to manage the web development process in a responsible manner to improve the quality of the software [140]. Walter and Scott [141] addressed that, the managing of web-based applications is different from managing the traditional computer systems. It is important to understand the differences when developing and managing these web-based applications. Hansen [142] suggested that, there is an important need for management of web engineering methodologies to accommodate the movement to higher user numbers; distributed and decentralized managed applications; user-centered orientations; and the provision of integrated web-based applications. The administrator has relationships to the data and to the application server operation. These relationships can be divided into various management, monitoring, development, help and reporting functions as applied to the content and operation of the application. Figure (2.9) shows a detailed model of a web-based application, the roles of administrator and associated people, its relationship to other applications and the interactions possible with the internal and external users. The functions of the administrator role include a database administrator, an administrator role for the application, an administration role for the system and intermediate managers. This model can now be used to analyze administration and management requirements of sets of applications, by using this model for each application and analyzing the interactions [142]. Scott and Walter [143] addressed that, the most important problem is a broad management problem 46

65 involving strategy and strategic planning for development and deployment of all of a company s web-based applications within the context of company operations. The highly ranked problems indicate the high level concern of development managers and other managers that the goals and objectives of their company s web-based applications are not consistent with the corporate goals and directions [143]. Figure (2.9): A More Detailed Model for a Web Application, Showing User Roles and Interactions [142] Tools for Web Engineering A process is a sequence of tasks to achieve a particular objective. A method consists of techniques for performing a task. A tool is an instrument that can enhance the efficiency of the task; provided and applied by somebody with proper skills and training. The tool is used to facilitate the accomplishment of the methods. Most tools used to support systems engineering are computer or software-based, which known as Computer Aided Engineering (CAE) tools. An environment consists of the surroundings, the external objects, conditions, or factors that influence the actions of an object, individual person or group [144]. These conditions can be social, cultural, personal, physical, organizational or functional. The project environment should support the use of the tools and methods used on that project. An environment enables or disables the process and the methods [145]. A CASE environment (Autoweb system) offers a set of software tools, which assist the design and execution of web-based applications [146]. The individual categories of tools are: visual editors and site managers; web-enabled hypermedia authoring tools; Web-DBPL integrators; web form editors, report writers, and database publishing wizards; multi paradigm tools; and modeldriven application generators. There is no specific tool product is fully addressing analysis, design, implementation, and evolution of large web-based application, which require the same communication paradigm and interface quality as small-scale user-oriented application, and the same performance and scalability as client-server database application. Therefore, the 47

66 implementation oriented products like Web-DBPL integrators and multi paradigm tools seem the most adequate choice although development with these tools requires a substantial coding effort [147]. Many development tools support the creation of web-based applications such as: HTML editors, Adobe PageMill, Microsoft Office applications, Microsoft FrontPage, NetObjects Fusion, MacroMedia Dreamweaver, Microsoft VisualStudio.NET, Sun Java Studio Creator and the Eclipse-based WebSphere Application Developer [148] Testing Web-Based Applications Testing is a vital phase associated with every software development process. Unfortunately, testing is often considered a tedious process and therefore often neglected. It is usually take place after the coding is completed and just before the code is moved to production [149]. Systems testing can help to reduce the risk of problems occurring during operation of the software system and if defects found are corrected before the system is released for operational use. With the help of testing, it is possible to measure the software quality in terms of defects found for software requirements and characteristics (reliability, usability, efficiency, maintainability and portability). Testing can increase software quality if it finds few or no defects and then fixed these defects. A properly designed test that passes reduces the overall level of risk in a system. Lessons should be learned from previous projects by understanding the root causes of defects found in other projects, then processes can be improved, which in turn should prevent those defects from reoccurring. Then as a consequence, improve the quality of future systems, this is an aspect of quality assurance. Deciding how much testing is enough should take account of the level of risk including technical and business product and project risks, and project constraints (time and budget) [150]. First the test plan has to be in place in order to get the best results. The test plan enables the quality assurance team to go about testing in an organized and efficient manner [151]. The web-based applications ranged from small-scale web site that constructed from simple HTML-editor, to large multi-tiered applications that have huge number of users distributed all over the world and constructed using complicated distributed-object computations based on Java and CORBA. Building these web-based applications is serious and critical problem. The modeling and testing of these applications in a systematic manner can help manage growing complexity of these applications [152]. Nilawar [152] described an approach for web-based applications engineering with UML. He focused on testing such applications using a combo testing strategy. Combo testing involves the use of the new modeling approach web application compound that he proposed and allowed through verification of functional requirements of web applications via two types of testing: use case- 48

67 based testing and web compounds unit testing. The complexity of web-based applications has led to the need to adapt software testing frameworks and tools for these applications. Ji-Tzay Yang, et. al [153] presented a software testing architecture that integrated several common but enhanced testing tools as sub-architecture to fit a common web application framework. This architecture reused several software patterns and architectures from traditional testing environments [153]. Finally, poor performance of web-based applications can adversely impact the profitability of enterprises that rely on these applications. Therefore, the effective performance testing techniques are essential for understanding whether a web application will meet its performance objectives when deployed in the real world [154] Documenting Web-Based Applications Software documentation (or source code documentation) is a written text that accompanies computer software. It either explains how it operates or how to use it. The documentation is an important part of software engineering that is often overlooked. There are many types of software documentation such as: architecture/design, technical, end user and marketing [155]. Documentation has often played a key role in aiding program understanding. The graphical forms of documentation rely on software visualization techniques to make complicated information easier to understand [156]. Boyle and HorTeh [157] addressed that, the first efforts at putting technical documentation online did nothing more than replicate the book model online. Subsequent attempts with greater resources and imagination added passive reading tools such as graphical browsers and views, and adaptive indexes [157]. As addressed by Rob Pierce [158], most companies have two pats of technical information that in many organizations remain entire to themselves. The information presented in the company s documentation deliverables and in their technical support data repository is not always consistent. There can be a real issue of redundancy and inaccuracy between these two areas of information. Maintaining technical support is costly. Better documentation means more successful customers and lower costs of supporting a product. For customers and support personnel, two distinct repositories of information for technical content are the support solutions database and the documentation deliverables. Documentation deliverables are the documentation set for the company s products. The solutions database is a repository that represents a collection of answers to customer questions in the form of technical notes [158]. 49

68 Chapter 3 Software Process Improvement and Quality Assurance in Large Enterprises 3.1 Introduction Early web applications consist of textual user interfaces, limited interactivity and used for accessing static information. Whereas today s web applications consist of interactive interfaces and support collaboration among users. The search, tagging and user interaction are the key components of modern web applications. We need new web technologies, languages and methodologies to create web applications that represent a new model of collaboration among large numbers of users. The development of web applications adopts software engineering techniques. Future developments in web applications will be driven by advances in browser technology, web internet infrastructure, protocol standards and software engineering methods [159]. The software development process is a collection of activities carried out during the life cycle of a software product. Today, software process improvement (SPI) is key research areas in the software engineering field. Extensive research has been carried out and many different kinds of approaches exist to improve the software process [160]. Therefore, there is an emergency need for SPI in large organizations and enterprises. This chapter includes the description of SPI, CMM, CMMI, CMMI levels and its key process areas (KPA s), organizations with CMM experience and ISO concepts. This chapter includes also the importance of SPI, CMMI for large enterprises, lack of researches about SPI for large enterprises, the need of SPI to solve large enterprises problems, the development of SPI activities in large enterprises, SPI success factors in large enterprises, and factors affecting organizational change in SPI efforts. We describe also SPI elements in traditional and agile development, agile adoption and improvement model (AAIM), compatibility of agility with CMMI requirements. Finally, this chapter includes also a description of SQA and its components, quality attributes of web applications, SQA in web development organizations, risk management and SQA, SQA of large web applications and SPI and the factors affecting intensity of QA activities in development process. 3.2 The Software Process Improvement with CMM Capability Maturity Model for software (CMM) refers to a process improvement approach that is based on a process model. This model developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in the mid-1980s to evaluate the maturity of software 50

69 development process of an organization and to provide SPI practices. The CMM model has been through a number of revisions since The CMM provides software organizations with guidance on how to control their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. The CMM was designed to guide software organizations in selecting strategies of process improvement by determining current process maturity and identifying the few issues most critical to software quality and process improvement [161][162]. The CMM can be used to assess an organization against a scale of five process maturity levels based on an organization's support for key process areas (KPAs). Each level ranks the organization according to its standardization of processes in the subject area being assessed. The subject areas are: software engineering, project management and system acquisition [162]. The initial CMM v1.0 released in 1990, and after its successful adoption in many domains, other CMMs were developed for other disciplines such as systems engineering, software acquisition and others. These models have proven useful to many organizations in different industries. Many organizations would like their improvement efforts to span different groups in their organizations. The differences among the discipline models used by each group, including their approach have limited the organizations capability to successful broaden their improvements. At the same time, apply multiple models that are not integrated within organization is costly in training and improvement activities [163]. 3.3 The Capability Maturity Model Integration (CMMI) The CMMI provides guidance to use when developing processes. The CMMI was conceived as an initiative to integrate the various CMMs into a set of integrated models. The source models that served as the basis for the CMMI are: CMM for software V2.0 (Draft C), EIA-731 systems engineering and IPD CMM (IPD) V0.98a. The CMMI models are not processes. The actual processes used in an organization depend on many factors such as: application domain, organization structure and size [164]. The CMMI provides: an integrated vision of improvement for all organization elements; an efficient and effective improvement across multiple disciplines; improvements to best practices incorporated from the software CMM and others; and a means of representing new discipline-specific information in a standard. The benefits of CMMI-based process improvement are: improving schedule and budget predictability; improving cycle time; increasing productivity; improving quality; increasing customer satisfaction; improving employee morale; increasing return on investment; and decreasing cost of quality [165]. 51

70 3.3.1 The CMMI Capability Maturity Levels The maturity level of an organization provides a way to predict the future performance of this organization within given disciplines. There are five maturity levels as shown in figure (3.1) and each level stabilizes a part of organization s processes. These levels are measured by the achievement of the specific and generic goals that apply to each predefined set of process areas. In maturity level1 (Initial), the processes are ad hoc. The organization does not provide a stable environment and the success depends on developers and not on the use of proven processes. The organizations produce products that work but they exceed the budget and schedule and are not able to repeat their past successes. In maturity level2 (Managed), the organization has achieved all the specific and generic goals of the maturity level2 process areas. The projects requirements, processes and products are managed, and the processes are planned, performed, measured and controlled. The status of the products services is visible to management at defined points. Work products are reviewed with stakeholders and are controlled. And in maturity level3 (Defined), the organization has achieved all the specific and generic goals of the process areas assigned to maturity levels2 and 3. At level3, processes are well understood, and are described in standards, procedures, tools and methods. The organization s set of standard processes for level3 is established and improved over time. These standard processes are used to establish consistency across the organization [163][164][165]. At maturity level4 (Quantitatively Managed), an organization has achieved all the specific goals of the process areas assigned to maturity levels2, 3 and 4 and the generic goals assigned to maturity levels 2 and 3. The sub processes are selected that significantly contribute to overall process performance. These selected sub processes are controlled using statistical techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing processes. These objectives are based on the needs of customer, end users and organization. At maturity level5 (Optimizing), an organization has achieved all specific goals of the process areas assigned to maturity levels 2, 3, 4 and 5 and the generic goals assigned to maturity levels 2 and 3. Processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes. Maturity level5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative processimprovement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement [163][164][165]. 52

71 Figure (3.1): The Staged View of CMMI [165] The Categories of CMMI Key Process Areas Each maturity level (except level1) is decomposed into several key process areas (KPA s): process management, project management, engineering and support. Each KPA identifies a set of related activities that achieve a set of goals for enhancing process capability. The KPA s identify the issues that must be addressed by the organization to achieve a maturity level and to improve its software process. It is important to focus on the information relevant to the organization and included in the organization s used model. The process management process areas contain cross-project activities related to defining, planning, resourcing, deploying, implementing, monitoring, controlling, appraising, measuring and improving processes. Process management process areas are: organizational process focus; organizational process definition; organizational training; organizational process performance; and organizational innovation and deployment [162][164]. While, the project management process areas cover the project management activities related to planning, monitoring and controlling the project. Project management process areas are: project planning; project monitoring and control; supplier agreement management; integrated project management; risk management; integrated teaming; integrated supplier management; and quantitative project management. Whereas, engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. The engineering process areas are: requirements development; requirements management; technical solution; product integration; verification; and validation. Finally, support process areas cover the activities that support product development and maintenance, and address processes that are targeted towards the project. Support process areas are: configuration management; process and product quality assurance; measurement and analysis; organizational environment for integration; decision analysis and resolution; and causal analysis and resolution [162][164]. 53

72 3.4 Organizations with Software CMM Experience Many organizations initially make transition to CMMI to update their processimprovement efforts to incorporate version2.0 draftc improvements. These organizations will need to decide the best timing for transition to achieve a particular maturity level. Organizations that have already achieved a high level of maturity may wish to make the transition more quickly to take advantage of additional organizational coverage described in CMMI models. These organizations will find strong commonality between CMMI models and software CMM. There is significant improvement in coverage of the engineering, risk management and measurement and analysis processes, as compared to software CMM [164] Immature Versus Mature Software Organizations Setting goals for process improvement requires an understanding of the difference between immature and mature software organizations. In an immature organization, the software processes are conducted by practitioners and their managers during development. Even if a software process has been specified, it is not followed. The immature organization is reactionary and managers are focused on solving immediate crises. Schedules and budgets are exceeded because they are not based on realistic estimates. The product quality is difficult to predict because there is no objective basis for judging quality or solving problems. Activities intended to enhance quality such as reviews and testing are often eliminated when projects fall behind schedule. While, mature organization has the ability to manage the software development process. The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to planned process. Roles and responsibilities within the defined process are clear across the organization. The managers monitor software quality and customer satisfaction. There is an objective for judging product quality and analyzing problems. Schedules and budgets are based on historical performance and are realistic; the expected results for cost, schedule, functionality and quality of the product are usually achieved [162] Training Training is a key element in the ability of organizations to adopt CMMI. Training is provided to assist those who plan to guide improvement as part of a process group. Training is an integral part of any technology change. CMMI models address training in two ways. First, they treat training as a recurring generic practice (GP). The GP support the institutionalization of all process areas to ensure that the processes associated with the process area will be effective and repeatable. Second, the CMMI models cover training in a separate process area called organizational training. 54

73 An organization that has implemented the CMMI organizational training process area has an excellent infrastructure for supporting software product line practice. This infrastructure includes processes to: determine training needs; determine the level of responsibility for training; and plan and deliver training. A training organization is responsible for managing the training program. The purpose of organizational training is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. Firstly, establish an organizational training capability such as: establish the strategic training needs; determine which training needs are the responsibilities of the organization; establish an organizational training plan and training capability. Secondly, provide necessary training such as: establish training records; and assess training effectiveness [166]. 3.5 The Software Process Standards (ISO Standards) The ISO standards are collection of formal international standards, technical specifications, technical reports, handbooks, and web based documents on quality management and quality assurance. It is maintained by the International Organization for Standardization (ISO). This collection contains over 15,000 standards and provides practical solutions for sectors of business, industry and technology [167]. The family of ISO9000 standards developed by ISO and it is consists of: ISO9000:2000 (fundamentals and vocabulary); ISO 9001:2000 (quality management systems requirements); ISO9004:2000 (quality management systems guidelines for performance improvements); and ISO19011:2002 (guidelines for quality and/or environmental management systems auditing). The main benefits of implementing ISO 9001:2000 are to: provide an opportunity to increase value to the organization s activities; improve the processes performance continually; satisfy customers; attention to resource management; implementation of regulatory product s requirements; and better management control [168]. The CMM and ISO9000 share a common concern with quality and process management. The two are driven by similar concerns. Although ISO 9001 compliant organization would not necessarily satisfy all of the level2 KPA s, it would satisfy most of the level2 goals and many of the level3 goals. Because there are practices in the CMM that are not addressed in ISO 9000, it is possible for a level1 organization to receive ISO9001 registration. At the same time, there are areas addressed by ISO 9001 that are not addressed in the CMM. A level3 organization has little difficulty in obtaining ISO9001 certification, and a level2 organization has significant advantages in obtaining certification [169]. 55

74 3.6 The Importance of Software Process Improvement (SPI) Software process refers to the set of tools, methods and practices used to produce software artifacts. The objective of SPI model is to produce software artifacts according to plans while improving the organization's capability to produce better artifacts. The CMM is a software process management model that assists organizations to provide the infrastructure for achieving a disciplined and mature software process [170]. Since 1980s a large number of SPI efforts has initiated world wide to increase quality and productivity while decreasing cost. Different models are being used depending on the market goals of the organizations [171]. The CMM is popular among the companies that target the US market, whereas, IS09001 is popular among companies that target the European market [168]. The importance of SPI and CMM is to provide a conceptual structure for improving the management and development of software products in a disciplined and consistent way. It does not guarantee that software products will be successfully built or all problems will be resolved. The CMM identifies the characteristics of an effective software development process, whereas the mature organization addresses all issues essential to a successful project including people, technology and process. Past experience shows that organizations do their best when they focus their process-improvement efforts on manageable number of process areas that require increasingly sophisticated effort as the organization improves [162]. Finally, according to the empirical literature researches, the SPI has great impact on the success of software development organizations and improve their processes. 3.7 CMMI for Large Enterprises Large enterprises can spend hundreds of thousands of dollars in SPI to become certified at high CMMI level. The certification process (assessment and implementation of guidelines) can take as many as two years. Whereas, there is a growing concern that the CMMI is not applicable to small firms because it requires a huge investment [170]. The SEI proposed IDEAL model that defines the steps for planning and managing SPI in organizations and to support the implementation of SPI schemes. This model defines five phases, provides a structured approach for continuous improvement, and it is based on SEIs experiences from large organizations. All of IDEAL phases include different activities for guiding the systematic improvement approach. The IDEAL model is a life-cycle model for SPI based upon the standard process of CMM [172]. 56

75 3.7.1 Lack of Research about SPI for Large Enterprises Most of software enterprises, even in the US, Europe and other parts of the world belong to the category of small and very small software enterprises [173]. Small and medium-size enterprises (SME) are usually hindered from improving their processes due to the complexity and costs involved in SPI [174]. Creating quality systems in small firms has primary importance for software industry in many countries where majority of software organizations are small. Application of process improvement models such as IS09001 and CMM has inherent difficulties for small firms because these models do not provide much needed guidance [171]. For this reason, many researches undertaken SPI in small to medium firms and addresses the challenges of SPI in small firms [170][171][173][174]. At the same time, there are very few researches which undertaken the SPI and CMMI in large enterprises. Therefore, there is an important need for researches and empirical studies related for SPI and CMMI in large enterprises The Need of SPI to Solve Problems in Large Enterprises For any organization, one method used to improve software is to analyze the faults for root causes. Sometimes the root cause points to something external to the software development environment that is to the larger organizational context. Many external root causes for software faults are: training, tools and resources; people and materials; and coordination with external organizations and resources. Problems of these kinds may be unsolvable within the framework of the software development organization. Therefore, the software development process of these organizations suffering problems need to be improved. And these organizations attempt to find the solutions for these problems [175]. The webbased application or any software product is developed according to the software process rules. This software process is developed according to the software organization rules, and the software organization exists within a larger organization. The scope of improvement will be limited by the constraints of the larger environment. And so on for every level of process, organization and environment. One viewpoint suggested that, the factors that limit software improvement are side-effects of the structures used by large organizations for coordination and control: bureaucracy, specialization and hierarchy. Each of these structures enables the organization to cope with scale. Each same structure also provides resistance to change and improvement. This will produce organizations that are inflexible and non-responsive to change [175]. Therefore, every organization especially large-scale organizations need to adopt SPI practices, goals, principles and rules in order to overcome as possible as the inflexibility and non-responsive problems and produce quality web applications. 57

76 3.7.3 Development of SPI Activities in Large Enterprises The web-based applications are used increasingly in various domains in recent years. The scale and complexity of these web applications are increasing, and development organizations are becoming large. For any large-scale enterprise, it is necessary to establish an organizational structure and a deployment method to develop training courses, support tools for the effective adoption of SPI activities. It is necessary to implement the optimum software development process in a large development organization in order to build in higher quality and to develop large web applications efficiently. Therefore, the web development process has become a focus of attention in the recent years. The CMMI usually used as a road map for SPI and it is not necessarily sufficient just to introduce such an existing SPI technique in order to improve a software development process efficiently. The SPI changes the culture of a software development organization. The large development organizations vary greatly in terms of culture, and it is rarely effective to apply a uniform SPI technique as it is. Therefore, it is necessary to tailor existing SPI techniques for various large organizations [176] The SPI Success Factors in Large Organizations There exist a few factors that have a significant and positive effect on software business performance in both large and small organizations. Even without formally launching an SPI program. It appears that a software organization can achieve high organizational performance by executing these factors. This means that software organizations with any size can advance their business by adopting and practicing SPI elements. These factors are [177]: 1. Business orientation: the extent to which SPI goals are aligned with explicit and implicit business goals. 2. Involved leadership: the extents to which leaders at all organizational levels are actively participate in SPI. 3. Employee participation: the extent to which employees use their knowledge and experience to decide and take responsibility for SPI. 4. Concern for measurement: the extent to which the organization collects and utilizes quality data to guide and assess the effects of SPI activities. 5. Exploitation: the extent to which the organization uses the existing knowledge. 6. Exploration: the extent to which the organization explores a new knowledge. 3.8 Factors Affecting Organizational Change in SPI Efforts Dirk and Werner [178] addressed ten factors that influence the success of organizational change in SPI based on CMM and ISO9000 standards. Table (3.1) shows that, each one of 58

77 these factors affects organizational change in SPI [178]. On the other hand, Medha and Carolyn [179] presented the factors that would be very relevant to SPI acceptance model. These factors capture some of the organizational and personal issues and possible ways in which developers can perceive SPI. These factors are: organizational issues such as visibility, transparency of a process and reward structure; personal issues such as communication, self efficiency and degree of control; SPI-related issues such as amount of learning required, compatibility of work practices and advocates; and finally, social psychology factors such as perceived usefulness, perceived behavioral control and ease of use. Table (3.1): The Factors Affecting Organizational Change in SPI Efforts [178] Success Factor of Explanation Organizational Change Change agents and opinion leaders Encouraging communication and collaboration Management commitment and support Managing the improvement project Providing enhanced understanding Setting relevant and realistic objectives Stabilizing changed processes Staff involvement Tailoring improvement initiatives Unfreezing the organization 3.9 The SPI and Agile Methodologies Change agents initiate and support the improvement projects at the corporate level, and opinion leaders at a local level. Degree to which communication efforts precede and accompany the improvement program and degree to which staff members from different teams and departments cooperate. Degree to which management at all organizational levels sponsor the change. Degree to which a process improvement initiative is effectively planned and controlled. Degree to which knowledge of current software processes and interrelated business activities is acquired and transferred throughout the organization. Degree to which the improvement efforts attempt to contribute to the success of the organization (relevant) and degree to which the objectives may be achieved in the future (realistic). Degree to which software processes are continually supported, maintained and improved at a local level. Degree to which staff members participate in the improvement activities. Degree to which improvement efforts are adapted to the specific strengths and weaknesses of different teams and departments. Degree to which the "inner resistance" of an organizational system to change is overcome. Agile methodologies originated during the mid 1990s as a reaction against traditional methods in response to the challenges of the web development process and Internet era [180]. Agile methodologies used over a number of years of producing web applications with short development times in large industrial and related hypermedia projects. The agile approach gives lightweight method of capturing and recording the requirements. The agile methodologies also ensure good communication between customer and team to obtain high quality product [181]. Companies often implement agile methodologies such as XP to solve a variety of problems they encounter with traditional development processes [182]. Alegr ıa 59

78 and Bastarrica [183] addressed that, it is possible for software development organizations to achieve a CMMI certification to implement agile methods. They suggested that, it is possible to reach CMMI maturity level2 using agile methods if addressed two issues: firstly, each process area must be explicitly defined within the organization and agile methods provide almost all the required elements for this purpose; and secondly, the process areas such as requirement management, measurement and analysis, quality assurance and configuration management should be complemented with elements obtained from other sources The Elements of SPI in Agile Software Development There are limited amount of references were found to directly address the issue of organizational SPI within the context of agile software development because agile methodologies focus on project level activities of software development. Salo [184] addressed that, there is a relationship between agile software development and SPI. There are three principles of the agile manifesto that deserve attention: the value of individuals and interactions over processes and tools; the principle that encourages regular reflection by development teams to become more effective; and the self-organization of development teams. At the same time, taking regular improvement within project teams as one of the twelve agile development principles also highlights the importance of continuous improvement in agile software development context. Finally, in order to welcome changes during the agile software development according to product requirements: the software process, methods and tools must be able to adapt to the specific context while also to respond to the changes when needed. Therefore, agile specific methods are needed to tailor agile development practices within individual projects and within the entire organization Comparison of SPI Elements in Traditional and Agile Development The differences between the traditional and agile methodologies were discussed earlier in section (2.4.8). Table (3.2) illustrates some aspects of software development in traditional plan-driven and agile approaches. The traditional models provide high predictability, stability and repeatability using highly managed and quantitatively monitored software development processes. Whereas, the agile principles highlight the need for the software process to be flexible, to be able to rapidly respond to the constant changes and context specific needs of software development. The traditional software development emphasizes up-front contract negotiations where the requirements, cost and schedule of the product development are fixed and the end product will be delivered at the end of the project lifecycle. Also in these traditional models, extensive 60

79 documentation and quantitative monitoring of the product development process plays a central role. Whereas, the principles of agile development address: the constant changes but the requirements may not always be definable up-front, and the higher customer satisfaction and products higher quality can be accomplished through continuous customer collaboration and incremental delivery of working software. Also, in these agile methodologies, a face-toface communication, self-organization of teams and flexible software development processes. Salo [184] compared the fundamentals of traditional and agile development from the viewpoint of the six SPI elements: organizational models; standard processes and assessments; process tailoring; process deployment; measurement; and experience, knowledge and learning. One of the characteristics of SPI, it is emphasis on the continuous improvement of organizational software development processes in terms of performance, stability, compliance and capability. And the existing SPI methods and approaches seem to enhance the underlying business goals in the improvement of organizational development processes. The difficulty of adopting agile methods in CMMI based environment and the lacks of guidance on how to take advantage of the organization s existing best practices in transition towards agile methods has been identified as one of the major obstacles in the coexistence of agile and traditional approaches in organizations [184]. Table (3.2): The Fundamentals of Software Development in Plan-Driven and Agile [184] Characteristic Plan-Driven View Agile View High predictability and stability of Rapid response to constant changes Software software development Process Software Development Repeatable, well managed, and measurable software processes Goals of product and productivity fixed before hand Extensive documentation Quantitative monitoring One-off delivery of end-product Monitoring and management of software development Context specific and adaptable software process Product requirements rapidly change throughout the development Light documentation (simplicity) Face-to-face communication Continuous, iterative delivery of working software Self-organization of teams. Regular team reflections to become more effective Agile Adoption and Improvement Model (AAIM) Over the last decade, the software industry has shown a substantial interest in agile practices but there is no standard guiding vision model to adopt in order to improve the agile method in software development organizations, this could result in failure of agile implementation. Qumer, et. al. [185] developed AAIM for the adoption, assessment and improvement of agile process. They analyzed the results of several agile process assessments, 61

80 industrial case studies on the adoption of an agile approach and feedback from the software industry for the construction of the AAIM. The AAIM can be used as a gradual road map for the adoption of an agile approach so that the required agile level can be achieved and improved over a period of time. The AAIM organized in three agile blocks, six agile stages and an embedded agility measurement model as shown in figure (3.2). In AAIM, each stage specifies goals that must be achieved to attain a particular business value through the use of agile approach. The key features of AAIM helps to assess how an agile process is being followed within a software development organization; helps to assess current agile level of an organization; helps to measure and assess the degree of agility of development process; provides a roadmap for establishment of a systematic agile development environment and systematic use of agile practices within that environment; and combines concepts from theory and practice [185]. Figure (3.2): Agile Adoption and Improvement Model [185] Compatibility of Agile Methods with CMMI Requirements Agile methods such as XP have become increasingly popular. At the same time, more organizations rely on process maturity models to assess and improve their own processes because they had noted that most project failures come from inconsistent and undisciplined processes. Many organizations demand CMMI compliance of projects where agile methods are employed. Therefore, it is necessary to analyze the interrelations and mutual restrictions between agile methods and approaches for SPI. Fritzsche and Keil [186] determined which of the CMMI process areas are supported by agile methods, where adjustments need to be made and which process areas are in conflict. Based on this, they described the limitations of CMMI in an agile environment and show that level4 or 5 are not feasible under the current specifications of CMMI and XP. 62

81 3.10 The Software Quality Assurance (SQA) Software quality is described by various views using different attributes and models. There is a rich set of models and techniques for software product quality that support engineers in dealing with multiple quality related issues. All types of software quality have their own benefits and applications [187]. The principal functions of SQA are to: define the standards for the software developed in organizational unit (these standards may be established by a higher organizational unit such as a corporate, or by the particular SQA organization itself); specify and implement tools for assessing software quality; and apply the tools to assess the degree to which the software products developed by its organizational unit adhere to the standards appropriate to that product which it has established. The assessment may be qualitative such as certifying the software development group adopting certain development approaches such as top-down programming and other modern programming practices. The assessment may be quantitative, such as recording the number of major defects found in software design and actual code [188] The Components of Software Quality Assurance The SQA consist of: training and planning; audits, inspections and reviews; standards and procedures; and metrics. SQA planning must begin early in the development process when initial project planning begins to be effective and quality must be planned. SQA planning involves all functions necessary to implement a pre-determined level of quality such as: establish SQA requirements; establish and enforcing procedures for production and maintenance; and establish and implement procedures to evaluate software product s quality and corresponding documentation and processes that affect quality. Some of the plans required for assuring SQA include: audit and review plan, software verification plan, acceptance plan, documentation plan, configuration management plan, and staff development plan. SQA begins with training (the problem with many of organizations is a lack of trained personnel in software quality). Training is required in analysis, statistical modeling and verification and validation techniques. Some areas of analysis that the SQA members should be trained in include: process, cost-benefit and risk analysis. The Audits and reviews are conducted at various times in the development cycle to examine the conformance of process to procedures and product to standards. There are two types of SQA audits: internal and external. Internal audits are used to detect problems internally in process and conducted by inhouse teams. But external audits are conducted by outside auditor and consist of: audit planning, site visit, audit reporting and follow-up. Audit planning addresses four areas: product, process, project and organization. A review is a planned event concentrating on a 63

82 particular sub-product of process. Reviews are components of verification and validation and defined as part of audits and review plan. The purpose of a review is to evaluate a specific element to determine if that element is being developed according to standards and policies in the SQA plan. The purpose of standards and procedures is to bring control to software development process. These standards may include specification, documentation, reviews, audit and software engineering standards. Procedures include: practices to be followed when tracking and resolving software problems; rules for conducting reviews and inspections; and guidelines for updating documents into the configuration management system. A number of standards (documentation, programming and SQA) must be provided in the SQA plan. Many examples of these standards are: ANSI, IEEE and ISO9000 [189]. The software metric is an objective and mathematical measure of software that is sensitive to differences in software characteristics. It provides a quantitative measure of software attribute. The range of values of software metrics should reflect differences with respect to one or more dimensions of the software quality. Metrics are used as predictors of software quality and quality problems. The SQA personnel require extensive training to use metrics successfully. The in-process quality metrics should be taken during each phase of the development process. The metrics required for in-process quality management include: defect density during machine testing; defect arrival pattern during machine testing; phase-based effect removal pattern; and defect removal effectiveness [188] The Quality Attributes of Web-Based Applications Web applications deliver a complex array of content and functionality to a broad population of end users. Web applications differ from traditional applications in the following: they are distributed and component based; high reliability; high scalability; high usability; security; require more technologies (HTML, XML, network protocols, multimedia and Javascript languages); require many roles (authors, developers, graphic designers and legal issues) that have to be managed; and require the shorter time to market, shorter product life cycles and continuous maintenance. The web applications require new approaches to development but present the same issues and challenges as traditional information systems. Therefore, the same software engineering techniques are still necessary but the process should take these differences into account [190]. Many quality attributes of web applications are considered in table (3.3) [191]. The SPI is the means to develop quality applications within time and budget. The CMMI is one of the most well known SPI models that are available for 64

83 Modifiability Integrability Scalability process improvement. It is suitable to perform process improvement of web processes using techniques from empirical software engineering such as quality models [190]. Upgradeability Performance Usability Reliability Data Consistency Transaction Atomicity Isolation Durability Security Accessibility Component data accessibility Component Functionality accessibility User data Accessibility User Functionality Accessibility Table (3.3): The Quality Attributes of Web-Based Applications [191] The ability of a system to be extended to accomplish additional functionality. The ability to easily integrate separate systems or components of a system. The ability of a system to support modifications that dramatically increase the size of the system. The ability of a system to support component upgrades. How well the computer system responds to its inputs. The effort required to learn, operate, prepare input, and interpret output of a program. The ability of the system to sustain operations The ability of a system to preserve all of the invariant properties defined on the data The ability of a system to support atomic transactions. The ability of a system to handle multiple concurrent users/threads/connections/etc. The ability of a system to support persistence of data under fallible circumstances. How well the system supports a consistent security system, including authentication, access control and encryption. How much of the functionality and data that is accessible to individual components and external actors. How much of the data that is accessible to the components. How much of the functionality that is accessible to the components. How much of the data that is accessible to the end-users. How much of the functionality that is accessible to the end-users The Quality Assurance in Web Development Organizations There are two factors that affect the success of web applications: number of returning endusers and the number of end-users which use web application s services. The successful running of web application depends on how good the development team adapts and updates it according to its competitive environment and business changes to improve the quality of its functionality. A web application also compared with its competitor(s) and updated to strengthen its position. The time to develop new functionality, perform changes and test them is limited [192]. The aim of the SQA organization is to assure that the standards, procedures and policies used during software development are adequate to provide the level of confidence required for the process. Policies are general statements concerning development. Procedures are guidelines to accomplish tasks in a structured manner. Standards are mandatory requirements that are enforced to constrain a controlled and uniform approach to software development. The SQA is an independent process and an effective SQA program should consist of training and planning; audits, inspections and reviews; standards and procedures; and metrics. The organizations with SQA departments produced better quality products and more planning and standards more often than organizations with no SQA departments. It was found that the SQA organizations depended more on reviews for verification and validation. Although, the SQA organizations use techniques described by the 65

84 quality experts, but the majority of SQA personnel lacked specific training in SQA. Therefore, The SQA organizations lack of metrics measured for the software project [189]. The organizational quality management is organizational units which define quality standards, guidelines and metrics to be applied in projects, and archive results in metric catalogues to be used by subsequent projects to improve the process on the organizational level. The project results are evaluated according to a product specific evaluation using an evaluation procedure. The SQA reports are created in defined intervals describing the state and quality problems of the product under construction based on the results of the product evaluations. The project manager decides about general project progress based on project and QA reports. Project manager reports to the customer and higher levels in the organization and it is responsible for the overall project quality and for observing agreed upon delivery deadlines and costs [193] Web Applications Quality and Support in XP The XP performs poorly regarding SQA methods and focuses on small development projects that are not necessarily demanding risk management streams. Therefore, XP strengths apply only to smaller projects where XP approach enables fast development, but nevertheless on delivering high quality as it focuses on SQA development. For large development projects, it may be a reasonable approach to integrate some of the key elements of XP into one of the other processes. The XP continuously verifies quality and customer communication and involved in the iteration planning process strengthens the quality control from the customer site. The short iterations force the project team to develop functional releases at end of the each iteration to pass acceptance test. The XP uses user stories to capture requirements but there is no requirements management. The focus on teams together with the pair programming principle forms a very effective team approach [194] Risk Management and SQA Risk management is a key factor in achieving high SQA and enables early risk mitigation and the possibility to act instead of to react to problems and risks. When any organization tries to improve its software development process in order to increase software quality, it must consider the risk management as one discipline in its development process. At the same time, the risk management as a part of daily meetings and other disciplines implies that identifying and managing risks becomes less important since the project team is occupied with other issues. Then the project becomes sensitive to risk factors [194]. The requirements tracing can be treated as part of project risk management. If the project requirements are not 66

85 well understood, the resulting confusion is a major cause for many risks in a project that cause external problems such as delay, low productivity or lower quality. Most projects do not use a systematic tracing approach, but leave it to individuals to perform ad hoc tracing as needed to test planning and checking requirements for consistency. The CMMI demands basic systematic tracing between requirements and artifacts such as design, pieces of code and system test cases. As a result, good requirements tracing can facilitate risk management to support requirements understanding in projects, this would result in more improvement software process [195]. The risk-based software management (RBSM) strategy is used to deliver high-quality project. This strategy is based on five key principles: allocate resources and scale processes to match the assessed function implementation risk; complete all major failure mode identification and management of counter measures early in the development cycle; use existing engineering/software standards (CMMI); maximize the use of requirements modeling, and automatic code generation tools for rapid prototyping and production code generation; and finally, incorporate lessons learned into all ongoing projects and update all impacted standard operating procedures [196] The Quality Assurance of Large Web Applications and SPI Web applications are developed in a competitive environment. A new functionality must be introduced to increase the attractiveness of web applications and their potential users. If the quality of the new functionality is not good enough then it can be improved later [192]. The SQA through SPI and certification is one of the strategies that software companies can adopt to improve their international image to participate in a global market, and the need to make their projects more efficient and effective administrative units [183]. The successful management of software development processes is one of the main goals of large web development organizations to improve SQA. They must produce the expected results and any improvements made should be in accordance with the organization s objectives to satisfy the quality requirements of software processes [49]. The effective modeling and evaluation of the software processes are the two key aspects to be considered in the management of these software processes. The integrated management of these key aspects is not a simple task because the huge number and diversity of elements to take into account makes it complex the management of software processes. In order to promote SPI in any organization, it is very important to previously establish a framework for analysis to determine the strong and weak points of the software processes in this organization. The 67

86 previous step of the SPI is their evaluation and this requires the definition of metrics related to the different elements involved in software processes. Due to the great number of different entities involved in the evaluation of software processes, therefore, the establishment of a common terminology for the definition of metrics is fundamental for integrated and management of measurement process [197]. Today, the SPI is the key research area in the software engineering field. Extensive research has been carried out and many different kinds of approaches exist to improve the software process. The verification and validation processes are parts of the software process activities. These parts play a vital role in QA of the developed product but it is believed that they consume major portion of the development resources. Therefore, different kinds of approaches (standards, best practices based, management styled, measurement-oriented, product-quality based and knowledge-management) for assessment and improvement of the software process exist. The organizations can learn from these approaches to improve the verification and validation process [198]. Quality web applications require appropriate software development and project management processes. For project managers, the cost estimation is one of the important steps at the beginning of any new web project. Accurate cost estimates are an essential element for being able to provide competitive bids and remaining successful in the market. Over and underestimates of the expected costs have a significant influence on a company's competitiveness. Industry still faces difficulties with determining accurate cost estimates, even though the research on software cost estimation methods started already in early 1960's. According to the literature and practical experience on web development, the web applications change more often in terms of their requirements, contents and functionality than traditional software systems. In order to successfully develop quality web applications, a disciplined approach needs to be followed and better development tools need to be established. Standard software engineering approaches seem limited and cannot appropriately address all the challenges related to web development. Web engineering is similar to software engineering but identifies more tailored methods for web development. This is due to the fast evolution of technologies in this area combined with little documented experience. Therefore, recent publications stress the need for web engineering and web cost estimation [199]. Developing large and complex web applications requires partitioning the target application into several subsystems. It is difficult to define each subsystem s scope, functional requirements and data dependencies among subsystems. For this reason Mutchalintungkul, et. 68

87 al. [200] proposed applying the Requirements Integration Model (RIM) to specify and integrate the requirements of subsystems into an overall system. The RIM consists of a workflow model and a work procedure. The RIM can: provide specific guidelines to increase requirements quality obtained under a time constraint; assist the developers to clearly specify functional requirements for each subsystem and to identify data dependencies among subsystems; incorporate requirement engineering process improvement; and utilize software process standards. For a large web project, high levels of changes in requirements are normal during the planning phase when accomplish the requirements definition and analysis. It is also normal in the early design stages. But when developers reach the more detailed design phases of a project, a high volume of changes in requirements can significantly impact a large web project. If there is a high volume of changes later in the project there can be significant impacts to other functionality, interfaces and project schedule and budget. The use of agile methods can overcome this problem. For the agile programmer, changing requirements are expected and embraced. The key is the balancing of these changing requirements with feasibility, applicability and impact to the system under development. The flexibility is important to ensure that all of the customers requirements are met, which is the main goal of any development project, but at the same time eliminate and overcome the requirements that drive the project schedule, cost and risk [201] Factors Affecting Intensity of QA Activities in Development Process The QA activities of the project life cycle are process oriented, because they are linked to completion of a project phase and accomplishment of a project milestone. The QA activities will be integrated in to the development plan that implements one or more software development models such as Waterfall, Prototyping, Spiral, Object Oriented Programming (OOP) or other models. The QA planners for a project required to determine the list of QA activities needed for a project; and determine also the following for each QA activity [202]: 1. Timing 2. Type of QA activity to be applied. 3. Who performs the activity and the resources required. It should be noted that various persons may participate in the performance of QA activities (development team and department staff members together with independent persons such as external QA team members or consultants) 4. Resources required for removal of defects and introduction of changes. 69

88 Chapter 4 An Analytical Survey of Large Web-Based Applications Development in Large Jordanian Enterprises 4.1 Introduction One of objectives of this research is to understand the level of adoption of web development best practices currently in use in large enterprises. To achieve this objective, a literature survey of web development methodologies was conducted in chapter1 to identify web engineering practices in web development. This literature survey clarified that, there were many development methodologies of web applications that focused on delivering functional applications. Most of the studies confirmed that most of web projects run over time and budget and without considering SPIs and SQA requirements. After that, an analytical survey using questionnaires and interviews were carried out in seven large Jordanian enterprises which undertaken large web development. The objectives of this survey are to determine the extent to which these enterprises are using web engineering practices; and to propose a web engineering model to overcome as possible as web development problems. This chapter includes the details about the: survey methodology; statistical methods used in data analysis; analysis of the first questionnaire; factors used to select the research population; and general characteristics and development problems of large Jordanian enterprises. This chapter includes also the statistical analysis of the second questionnaire such as respondent background; development and test methods; description of possible symptoms at organizations; and the web engineering practices. 4.2 Survey Methodology The practical work of this study depended on quantitative research methodology because it was more suitable to the nature of this study. This was done by carried out two questionnaires. The analysis units for this survey were large Jordanian enterprises which undertaken the development of large web applications. We divided this analytical survey into two parts: The first part was a simple questionnaire that has been distributed on web development Jordanian enterprises to obtain the main characteristics of these enterprises. According to the results of the first questionnaire, we adopted as a research population, seven large-scale Jordanian enterprises which undertaken the development of large web applications. We carried out interviews with the managers in these selected enterprises after the first questionnaire to obtain the problems of web development. 70

89 The second part of this analytical survey was another deeper questionnaire that has been distributed on the developers in only selected seven large Jordanian enterprises. Fifteen developers were selected randomly from each one of these seven enterprises. The contents of this questionnaire were determined according to questions listed in the software best practice questionnaire (SBPQ) which was attached with the report [36]. The second questionnaire were used to identify: the development methodologies used by these enterprises; symptoms that large enterprises suffering from; and web engineering practices. Drift versions of the two questionnaires were approved with the aid of four university research professors either in management or information technology. The Appendix A indicates the steps of modified first questionnaire whereas the Appendix B indicates the steps of modified second questionnaire Statistical Methods Used in Data Analysis In order to fulfill the objective of this study, a two of statistical techniques (descriptive statistics and explanatory factor analysis) were utilized in the data analysis. Descriptive statistics such as frequencies, percentage, mean and standard deviation were used firstly, to identify the major characteristics of respondents in section1 in the second questionnaire in terms of their current position of employee, activities currently work, experience of developers in organization and so on. Descriptive statistics were used secondly, to identify the major characteristics of development and test methods in section2 in second questionnaire. Many of these characteristics are the size of enterprises, web application domain, development methodologies used by enterprises and so on. Thirdly, descriptive statistics were used in section3 in term of description of possible symptoms at Jordanian enterprises. Finally, descriptive statistics were used in section4 in term of web engineering practices. Factor analysis is a class of multivariate statistical technique whose main objective is to define the underlying structure in the data matrix. It addresses the interrelationships between variables by defining a set of common underlying dimensions. Once these dimensions are determined, two main uses for factor analysis, summarization and data reduction can be achieved. The former use refers to the process of describing the data in much smaller number of variables and the latter describes the process of calculating the score for each underlying dimension and substituting them for the original data [203]. Explanatory factor analysis was used to define the dimensions of the variables in each specified construct in this study and all variables loadings were inspected carefully. We used factor analysis in section3 in term of description of possible symptoms at organizations. Factor analysis was used in section4 in term of web engineering practices. 71

90 4.3 The Analysis of the First Questionnaire At the beginning of this research, we carried out a simple questionnaire in many Jordanian enterprises which undertaken web development to select only large enterprises which undertaken the development of large web applications. We built this questionnaire according to the definitions of large software project mentioned in literature researches. The first questionnaire format contains two parts: The first part included questions related to characteristics of web applications which undertaken by enterprise. The second part included questions related to characteristics of web applications development process in the enterprise Factors Used to Select the Large Enterprises (Research Population) We obtained from the results analysis of this questionnaire the main characteristics of Jordanian enterprises. According to these characteristics, we decided to include these enterprises as a research population in our study or not according to many factors. These factors are used also to measure the size of web applications. From this questionnaire, we noticed that all Jordanian enterprises adopt many of these factors to measure the size of their undertaken web applications. Table (4.1) and figure (4.1) shows these factors and percentages of answer yes for each factor. Table (4.1): Factors Used by Enterprises to Measure the Size of Web Applications Factors used by enterprises to measure the size of web-based applications Yes Number of requirements 100% Number of functions that the web application delivered to customers 87.5% Number of developers 87.5% Number of programming languages used to program the web application 25% Size of budget 62.5% Time required to develop the web application 37.5% Number of lines (code) in program 12.5% Number of web pages 0% Number of companies to develop the web-based application 12.5% Factors used to measure the size of web application Yes Answer Yes Size of budget Time required to develop the web applications No. of lines (code) in program No.of web pages No. of companies to develop the web application Factors Figure (4.1): Factors Used by Enterprises to Measure the Size of Web Applications General Characteristics of Large-Scale Jordanian Enterprises After we had analyzed the results of the first questionnaire, we summarized the characteristics of large-scale Jordanian enterprises as follows: 1. They develop web applications with medium to large scale sizes. 72

91 2. They involve 50 and more developers in the development process. 3. They use more than three programming languages and tools in development. 4. They develop web applications to provide 50 functions or more to customers. 5. They develop web applications with more than 100 web pages. 6. They develop web projects with more than hundreds of thousands lines of code. 7. They require average time ranged from 1 to 3 years to develop web applications. 8. Many of these companies have many branches in other countries and other companies related to another companies outside Jordan Interviews in Large Web Development Enterprises After we carried out the first questionnaire, interviews were carried out with developers worked in these selected seven Jordanian enterprises. The objectives of these interviews are to determine the problems associated with time, cost and effort estimation, the success rate of web applications development, and finally the reasons for web project failure. This was done by asked every interviewer about: the time required to develop the web applications and if this development runs over the estimated time? And what are the reasons for this?. We asked also about the required budget for web application s development and if this process runs over budget? And what are the reasons for this?. Finally, we asked about software tools required to develop web applications, and at what development phase are they used? The survey was conducted in a qualitative manner using a one-to-one interview technique. The interviews in all selected enterprises showed that, the failure to deliver on time was main cause for going over budget on a web project. All the interviewers mentioned the reasons for web projects running over time such as: poor communication between developers and customers, late customer feedback, problems in requirements phase, poor project management, lack of resources, poor delivery of data and content, lack of professional developers and poor project cost, time and effort estimation techniques. Finally, the interviews showed that all enterprises depend on software tools in most cases of web design. The most popular used tools are Outlook Express, Photoshop, Dream weaver, Microsoft front Page, Flash publisher and so on. From the interviews with many developers in these enterprises, we noticed that many of these enterprises suffering from many of the following web development problems: 1. Misunderstanding of system requirements because lack of customer communication. 2. The requirements changing during and after the development process. 3. Lack of standardization in programming the web applications. 4. Lack of standardization in documentation of the development process. 73

92 5. Lack of refactoring the components. 6. Lack of suitable management methodology. 7. Communication cap between the developers in different development teams. 8. Sometimes there are insufficient resources. 9. Problems of deadlines Development Teams in Large Jordanian Enterprises From the interviews which followed the first questionnaire, we noticed that all of these enterprises involved number of development teams in the development process but each team concentrated in only one development phase. For example, requirement gathering and analysis team, design team, coding team and quality assurance team as shown in figure (4.2). This technique lead to problem of teams dependencies, one team may be wait long time for the outcome of another team. The requirement analyzers may delay the work of the designers and so on. Each one of these Jordanians enterprises has its own a management team but each of them has its own management and organization methodology that depend on the nature and structure of the enterprise. Requirement Gathering Team Designers Team Project Manager Team leaders Implementation team Testing Team Quality Assurance Team Figure (4.2): Relationships between Teams in Enterprises 4.4 The Statistical Analysis of the Second Questionnaire The format of the second questionnaire included four parts: The first part listed six questions about respondent background. The second part listed one question about number of developers, one question about application domain and six questions about development and test methods. The third part asked the respondents 25 questions about symptoms that large enterprises facing during the web applications development. The forth part related to web 74

93 development practices and listed 8 questions related to organizational issues, 13 questions related to standards and procedures, 8 questions related to web metrics, 6 questions related to control of the development process and finally 7 questions related to tools and technology. A copy of second questionnaire was included in Appendix B. This section describes the results of second questionnaire Respondent Background The following sub sections include the descriptive statistics such as frequencies, percentages, mean and standard deviation for the answers related to questions in the first part Current Position of Respondent Table (4.2) shows descriptive statistics of respondents current position in large Jordanian enterprises. As shown in figure (4.3), the highest ratio (41%) is for software engineering process group, whereas the technical members ratio is 28%. Table (4.2): Descriptive Statistics of the Current Position of Employee Value Current Position of Employee Frequency Percentage 1 Project or Team Leader 14 14% 2 Manager 17 17% 3 Technical Member 28 28% 4 Software Engineering Process Group (SEPG) Member 41 41% Mean = 2.96 Std. Deviation = Frequency Project or Team Leader Frequency of current position of employee Manager Technical Member Current possition of employee Software Engineering Process Group (SEPG) Member Frequency Figure (4.3): Describe the Frequencies of Current Position of Employee Activities Currently Work Table (4.3) shows the descriptive statistics of respondents current work activities. As shown in figure (4.4), the highest ratio (24%) is for software design, software requirements ratio is 21%, code and unit test ratio is 16%, test and integration ratio is 15%, software quality assurance ratio is 10%, software process improvement ratio is 8% and finally configuration management ratio is 6%. 75

94 Table (4.3): The Descriptive Statistics of Respondents Current Work Activities Value Activities currently work Frequency Percentage 1 Software Design 24 24% 2 Code And Unit Test 16 16% 3 Software Requirements 21 21% 4 Software Process Improvement 8 8% 5 Test And Integration 15 15% 6 Software Quality Assurance 10 10% 7 Configuration Management 6 6% Mean = 3.28 Std. Deviation = Frequencies of activities currently work Frequency 0 Software Design Code And Unit Test Software Requirements Software Process Improvement Test And Integration Software Quality Assurance Configuration Management Activities currently work Figure (4.4): The Frequencies of Respondents Current Work Activities CMMI-Related Training Table (4.4) shows the descriptive statistics of developers receiving any CMMI-related training. As shown in figure (4.5), the group of (No) answers got the highest ratio (88%). Whereas the group of (Yes) answers got the ratio (12%). Table (4.4): Descriptive Statistics of Developers Receiving any CMMI Training Value Received any CMMI-related training Frequency Percent 1 No 88 88% 2 Yes 12 12% Mean = 1.12 Std. Deviation = Frequency 50 0 No Yes Have you received any CMMI-related training? Frequency Figure (4.5): The Frequencies of Developers Receiving Any CMMI Training Participated in Previous Forms of Software Process Assessment Table (4.5) shows the descriptive statistics of respondents participation in previous forms of software process assessment. As shown in figure (4.6), the majority of the respondents (81%) have not previously participated in any software process improvement activities, while the ratio of those who participated is 19%. The types of software process improvement 76

95 activity that the respondent has involved in are shown in the same table, software process assessment ratio is 6%, software capability evaluation ratio is 9% and others ratio is 4%. Table (4.5): Descriptive Statistics of Respondents Participated in Forms of SPA Value Participated in previous forms of SPA Frequency Percent 1 No 81 81% 2 Yes : SPAs (Software Process Assessments) 6 6% 3 Yes : SCEs (Software Capability Evaluations) 9 9% 4 Yes : Other SEI_BASED Methods 4 4% Mean = 1.36 Std. Deviation = Frequency Frequency No Yes : SPAs Yes : SCEs Yes : Other Participated in previous forms of software Process Assessment Figure (4.6): Participation in Software Process Improvement Experience of Developers in Present Organization Table (4.6) shows the descriptive statistics related to the years of experience of developers in present organization. As shown in figure (4.7), the group of (5 years and less) got the highest ratio (76%). The second group (6-10 years) got the ratio (18%) and the group of (11 years and above) got the ratio (6%). Table (4.6): Descriptive Statistics of Developers Experience in Present Organization Value Experience in present organization Frequency Percent 1 5 years and less 76 76% years 18 18% 3 11 years and above 6 6% Mean = 1.30 Std. Deviation = Frequency Frequency 5 year and less 6-10 years 11 years and above Experience in present organization Figure (4.7): Frequencies of Developers Experience in Present Organization Overall Experience of Developers Table (4.7) shows the descriptive statistics of overall software experience years of developers. As shown in figure (4.8), the group of (5 years and less) got the highest ratio 77

96 (49%). The group of (6-10 years) of experience got the ratio (36%) and finally the group (11 years and above) got the ratio (15%). Table (4.7): Descriptive Statistics of Overall Software Experience of Developers Value Overall Experience of Developers Frequency Percent 1 5 years and less 49 49% years 36 36% 3 11 years and above 15 15% Mean = 1.66 Std. Deviation = Frequency 5 year and less 6-10 years 11 years and above Frequency Overall Experience of Developers Figure (4.8): Frequencies of Overall Experience of Developers Level of Experience with Web Based Applications Development Table (4.8) shows the descriptive statistics of respondents level of experience with web development. As shown in figure (4.9), the group of basic knowledge of web applications development got the highest ratio (53%), whereas the group of advanced knowledge of web development got the ratio (31%), while the group of know very little about web development got the ratio (13%) and the group of no knowledge of web development got the ratio (3%). Table (4.8): Descriptive Statistics of Level of Experience with Web Development Value Level of Experience with Web Based Applications Development Frequency Percent 1 Know very little about web application 13 13% 2 Basic knowledge of web applications development 53 53% 3 Advanced knowledge of web applications development 31 31% 4 No knowledge of web applications development 3 3% Mean = 2.24 Std. Deviation = Frequency Frequency know Very Little About Web Application Basic Knowledge of Web Applications Development Advanced Knowledge of Web Applications Development Level of Experience with Web Based Applications Development No Knowledge of Web Applications Development Figure (4.9): Frequencies of Level of Experience with Web Development 78

97 4.4.2 Development and Test Methods The second part of the second questionnaire listed one question about number of developers in selected enterprises, one question about applications domain in these enterprises and six questions about development and test methods. The following sub sections include the descriptive statistics such as frequencies, percentages, mean and standard deviation for the answers related to these eight questions The Size of Jordanian Enterprises Table (4.9) shows the descriptive statistics of different sizes of large Jordanian enterprises. As shown in figure (4.10), about 50% of the Jordanian enterprises have size (between 76 and 100 developers), 30% of these enterprises have size in the range (50-75 developers) and finally 20% of these enterprises have size (more than 100 developers). Table (4.9): Descriptive Statistics of Different Sizes of Large Jordanian Enterprises Value No. of Developers Frequency Percent Developers 30 30% Developers 50 50% 3 More than 100 Developers 20 20% Mean = 1.9 Std. Deviation = Organization Size Developers Developers No. of Developers More than 100 Develpers Frequency Figure (4.10): Frequencies of Different Sizes of Large Jordanian Enterprises Web Application Domain The table (4.10) shows the descriptive statistics of the application domain in Jordanian enterprises. As shown in figure (4.11), the highest ratio (66%) is for business information systems group, whereas the ratio of E-Business group is (50%). The minimum ratio (15%) related to web engineering tools. Table (4.10): Descriptive Statistics of Application Domain in Jordanian Enterprises Value Application Domain Frequency Percentage 1 Business Information Systems 66 66% 2 E-Learning 31 31% 3 E-Banking 40 40% 4 Web Engineering Tools 15 15% 5 E-Commerce 32 32% 6 Personal Web Pages 23 23% 7 E-Business 50 50% Mean = Std. Deviation =

98 70 Frequencies of application domain Frequency Business Information Syst ems E_ Learning E_ Banking Web Engineering Tools E_ Commerce Personal Web Pages E_ Business Application Domain in Jordanian enterprises Figure (4.11): Frequency Distribution of Application Domain Web-Based Applications Development Involves Table (4.11) shows the descriptive statistics of that, if the web application s development involve in-house, outsourcing or reusability. As shown in figure (4.12), the highest ratio (99%) is for in-house development. The outsourcing ratio is (42%) and finally the reusability ratio is (23%). Table (4.11): Describe If Development Involve In-House, Outsource or Reusability Value Development Involves Frequency Percentage 1 In-house development 99 99% 2 Outsourcing 42 42% 3 Reusability 23 23% Mean = Std. Deviation = Frequency In_house Outsourcing Reusability Development Involves Frequency Figure (4.12): Describe If Development Involve In-House, Outsource or Reuse The Developers Familiarity with Development Methodologies Table (4.12) shows the descriptive statistics of developers familiarity with development methodologies. As shown in figure (4.13), the highest ratio (70%) is belong to object-oriented programming, structured programming ratio is (64%) and waterfall ratio is (63%). The consecutive groups have pointed out the following ratios: flowcharting (51%), structured systems analysis and design (50%), rapid application development (33%), extreme programming (31%) and so on. 80

99 Table (4.12): Statistics of Developers Familiarity with Development Methodologies Value Development Methodology Frequency Percent 1 Flowcharting 51 51% 2 Waterfall 63 63% 3 Structured Programming 64 64% 4 Structured Systems Analysis and Design Methodology (SSADM) 50 50% 5 Information Engineering (IE) 12 12% 6 Top Down Programming 25 25% 7 Jackson Structured Programming 2 2% 8 Dynamic Systems Development Method 4 4% 9 Object Oriented programming (OOP) 70 70% 10 Rational Unified Process (RUP) 24 24% 11 Enterprise Unified Process (EUP) 7 7% 12 Agile Unified Process (AUP) 7 7% 13 Extreme Programming (XP) 31 31% 14 Agile Methodologies (other than XP) 12 12% 15 Virtual Finite State Machine (VFSM) 1 1% 16 Praxis 0 0% 17 Rapid Application Development (RAD) 33 33% 18 Spiral RAD 3 3% 19 Test Driven Development (TDD) 9 9% 20 Other 6 6% Mean = Std. Deviation = Figure (4.13): Frequencies of Development Methods Which Developers Familiar With Development Methodologies Used by Enterprises Table (4.13) shows the descriptive statistics of development methodologies used by enterprises. As shown in figure (4.14), waterfall model got the highest ratio (62%), OOP ratio is (51%), structured programming ratio is (48%), flowcharting ratio is (43%) and structured systems analysis and design methodology ratio is (41%). 81

100 Table (4.13): Descriptive Statistics of Development Methods Used by Enterprises Value Development Methodologies used by Enterprises Freq. Percent 1 Flowcharting 43 43% 2 Waterfall 62 62% 3 Structured Programming 48 48% 4 Structured systems analysis and design methodology (SSADM) 41 41% 5 Information Engineering (IE/IEM) 14 14% 6 Top Down Programming 29 29% 7 Jackson Structured Programming 0 0% 8 Dynamic Systems Development Method 6 6% 9 Object Oriented programming (OOP) 51 51% 10 Rational Unified Process (RUP) 6 6% 11 Enterprise Unified Process (EUP) 3 3% 12 Agile Unified Process (AUP) 2 2% 13 Extreme Programming (XP) 10 10% 14 Agile Methodologies (other than XP) 1 1% 15 Virtual Finite State Machine (VFSM) 0 0% 16 Praxis 0 0% 17 Rapid Application Development (RAD) 29 29% 18 Spiral RAD 0 0% 19 Test Driven Development (TDD) 6 6% 20 Other 7 7% Mean = Std. Deviation = Figure (4.14): Frequencies of Development Methods Used by Enterprises Test Types Required by Organization Table (4.14) shows the descriptive statistics of test types required by enterprises. Figure (4.15) shows that the integration test got the highest ratio (64%), web metrics got the ratio (30%). Each of unit tests and acceptance tests got ratio equal to (27%), code coverage tests ratio is (23%) and so on. Table (4.14): Descriptive Statistics of Test Types Required by Organization Value Kinds of Tests Frequency Percentage 1 Unit tests 27 27% 2 Integration tests 64 64% 3 Code coverage tests 23 23% 4 Acceptance tests 27 27% 5 Database tests 17 17% 6 Web metrics 30 30% 7 No tests are required 0 0% 8 Performance tests 6 6% Mean = Std. Deviation =

101 Frequency Frequency 0 Unit tests Integration tests Code coverage tests Acceptance tests Database tests Web metrics No tests are required Performance tests Kinds of Tests Figure (4.15): Frequency Distribution of Test Types Required by Organization Assurance Activities are Performed Table (4.15) shows descriptive statistics of assurance activities which were performed when developing web applications in these enterprises. Figure (4.16) shows that the highest ratio (65%) is for testing of web applications, the second highest ratio (43%) is for code review. Development process audit ratio is (20%), functional configuration audit ratio is (16%), physical configuration audit ratio is (12%), configuration management audit ratio is (12%) and finally version description document ratio is (11%). Table (4.15): Descriptive Statistics of Performed Assurance Activities Value Assurance Activities are performed Frequency Percentage 1 Testing of web-based applications 65 65% 2 Code review (formal or informal) 43 43% 3 Development process audit 20 20% 4 Configuration management audit 12 12% 5 Functional configuration audit 16 16% 6 Physical configuration audit 12 12% 7 Version description document or equivalent 11 11% 8 No assurance activities are performed 2 2% Mean = Std. Deviation = Frequency 60 Frequency Testing of web-based applications Code review (formal or informal) Development process audit Configuration management audit Functional configuration audit Physical configuration audit Version description document or equivalent no assurance activities are performed Assurance Activities are performed Figure (4.16): Frequent Distribution of Performed Assurance Activities 83

102 Who Performs the Assurance Activities? Table (4.16) shows the descriptive statistics of who perform assurance activities when developing web applications in enterprises. As shown in figure (4.17), the highest ratio (52%) is for software assurance group. The second highest ratio (37%) is for project team. Other assurance group (outside) got the ratio (8%) and other 3%. Table (4.16): Frequent Distribution of Who Performed Assurance Activities Value Who Performs the Assurance Activities? Frequency Percentage 1 Project team 37 37% 2 Software assurance group 52 52% 3 Other assurance group (outside) 8 8% 4 Other 3 3% Mean = 1.77 Std. Deviation = Frequency Frequency 0 Project team Software assurance group Other assurance group (outside) Other Who Performs the Assurance Activities? Figure (4.17): Frequent Distribution of Who Performed Assurance Activities Description of Possible Symptoms at Organizations This section includes descriptive statistics of the severity score description and occurrence frequency score description for symptoms which faced large Jordanian enterprises when they were developing large web applications. We include in this study 25 symptoms (questions). These questions are obtained from the software best practice questionnaire which was listed in report [36]. The selection of these 25 questions is firstly, depend on the problems in developing large web applications mentioned in the literature researches which were previously listed in section 1.5. Secondly, these questions are selected according to the interviews after the first questionnaire with developers in large-jordanian enterprises (section 4.3.4). In this study we adopted scores ranged between 1 and 5, to select one of these scores for each severity and occurrence frequency. Table (4.17) shows the factor analysis of all symptoms and the mean and standard deviation of both each of the severity score description and occurrence frequency score description. This table explicates that the respondents perceptions level of the severity score description of symptoms that face the enterprise during web applications development has been of a medium level with average

103 No Table (4.17): Developers Perceptions Toward Symptoms at Organization Symptoms Factor analysis Severity Score Description Occurrence Frequency Score Description Mean Std. Mean Std. 1 Delivery dates which were originally promised are not met The scope, design, planned implementation methods, timing, etc. change significantly during the project. 3 Necessary things (eg. info, specs, materials, authorization, drawings, etc.) are not available on-time or when needed. 4 There are discussions &/or disagreements about the priority of different or competing projects. 5 There are large variations between our quoted vs. As-built costs. Our planned profits suffer, or we risk being perceived as taking unfair profits (gouging our customers). 6 We have quality problems. There is too much re-designing, rework, scrap, mis-communication, unnecessary details, customer complaints, warranty, returns, etc Some tasks can only be done by a few, key individuals Some steps, systems, resources, or processes are critical bottlenecks that hurt the entire operation due to their limited capacity Work expands to fill the time available to our project workers A project s assigned resources are moved to another pressing need during the project There is a shortage of skilled people & resources for our projects We don t realize all the issues & potential problems until it's too late (or almost too late) We have a few big holes, and many small holes in our skills, knowledge, attitude, & capabilities needed for the project Too many tasks get assigned to too few people There is poor prioritization of the various projects &/or tasks Available resources are not used effectively Current project methods & systems are so historical and accepted; they are/will be difficult to change Projects are abandoned before completion. Significant resources were spent with little or no benefit Projects suffer from delays & schedule conflicts Costs, resources, & benefits for important projects are estimated so pessimistically that the idea is abandoned Suppliers &/or sub-contractors don t live up to their commitments There is lack of teamwork &/or co-operation within project teams The project plan is significantly different from reality, but official plan changes are not made The same project problems keep happening again & again; we never seem to stop, learn, & fix We waste time & resources during the implementation phase because of insufficient planning Based on the results of table (4.17) which represent the relative significance to the sample responses about Symptoms variable, it showed a one factor solution of symptoms. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.824) which is related to question 8, whereas 85

104 question 24 is in the second level, it equals (0.792). While question 12 in the third level of significance it equals (0.787). While question 23 in the fourth level of significance it equals (0.786). While other questions: Q5(0.783), Q13(0.782), Q11(0.781), Q20(0.773), Q1(0.771), Q18(0.77), Q22(0.755), Q17(0.754), Q16(0.746), Q19(0.739), Q14(0.738), Q15(0.735), Q3(0.717), Q25(0.682), Q21(0.663), Q4(0.66), Q6(0.654), Q9(0.625), Q7(0.587), Q10(0.568), and Q2(0.505) came in the 5 th, 6 th, 7 th, 8 th, 9 th, 10 th, 11 th, 12 th, 13 th, 14 th, 15 th, 16 th, 17 th, 18 th, 19 th, 20 th, 21 st, 22 nd, 23 rd, 24 th, and 25 th level respectively. According to the mean results of severity score description in the above table, the first symptom (1) (delivery dates which were originally promised are not met) was of a first order with average equal Secondly, symptom (24) (the same project problems keep happening again and again; we never seem to stop, learn and fix) came in the next order with average equal Thirdly, symptom (11) (there is a shortage of skilled people and resources for our projects) with average equal Fourthly, symptom (5) (there are large variations between our quoted vs. As-built costs. Our planned profits suffer, or we risk being perceived as taking unfair profits) with average equal 4.0. Fifthly, symptom (25) (we waste time and resources during the implementation phase because of insufficient planning) with average equal Sixthly, symptom (19) (projects suffer from delays and schedule conflicts) with average equal 3.83., and so on until finally, the symptom (8) (some steps, systems, resources, or processes are critical bottlenecks that hurt the entire operation due to their limited capacity) with lowest average equal Figure (4.18) shows the mean of severity score description of all symptoms. Severity Score Mean Mean Questions M ean Figure (4.18): The Mean of Severity Score Description of All Symptoms Table (4.17) explicates also that the respondents perceptions level of Occurrence Frequency Score Description of the symptoms that face the enterprise during web development has been of a medium level with average According to the mean results of occurrence frequency score description, the first symptom (1) (Delivery dates which were 86

105 originally promised are not met) was of a first order with 3.83 average. Secondly, symptom (24) (The same project problems keep happening again & again; we never seem to stop, learn, & fix), came in the next order with average equal Thirdly, both of symptom (5) (There are large variations between our quoted vs. As-built costs. Our planned profits suffer, or we risk being perceived as taking unfair profits (gouging our customers)) and symptom (19) (Projects suffer from delays & schedule conflicts) have the same average equal Fourthly, symptom (2) (The scope, design, planned implementation methods, timing, etc. change significantly during the project.) with average equal 3.53., and so on. Finally symptom (18) (Projects are abandoned before completion. Significant resources were spent with little or no benefit) came with lowest average equal 2.49 Figure (4.19) shows the mean of the Occurrence Frequency Score Description of all symptoms. O ccurrence Frequency Mean Mean Questions Mean Figure (4.19): The Means of Occurrence Frequency Score Description of Symptoms Web Engineering Practices This section includes descriptive statistics (frequency and percentage) and factor analysis of the results related to the web engineering practices such as organizational issues, standards and procedures, web metrics, control of the development process and tools and technology Organizational issues This section contains descriptive statistics (frequency and percentage) and factor analysis of the results related to organizational issues as shown in table (4.18). This table represents also the relative significance to the sample responses about organizational issues variable, it showed a one factor solution of organizational issues. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.887) which is related to question 1.5, where question 1.1 is in the second level, it equals (0.804). While question 1.8 in the third level of significance it equals (0.732). While question 1.3 in the fourth level of significance it equals (0.700). While other questions: Q1.6(0.680), Q1.4(0.646), Q1.7(0.52) and Q1.2(0.51) came in the 5 th, 6 th, 7 th and 8 th level respectively. 87

106 Table (4.18): The Statistics of Organizational Issues in Web Engineering Practices No. Question Factor Does Not Don t Yes No analysis apply know Freq. % Freq. % Freq. % Freq. % Does each web project have a 1.1 nominated web project % 42 42% 14 14% 10 10% manager? 1.2 Does the web project manager report to a business project manager responsible for the % 36 36% 20 20% 16 16% overall benefit of the project to the business? 1.3 Does a web Quality Assurance (WQA) function exist within an independent reporting line % 36 36% 13 13% 17 17% from web development project management? Is a change control function 1.4 established for each web % 39 39% 18 18% 13 13% project? Is there a required training program for all newlyappointed web managers 1.5 which is designed to % 33 33% 25 25% 10 10% familiarize them with in-house web project management procedures? Is there a procedure for 1.6 maintaining awareness of the state-of-the-art in CASE of % 37 37% 20 20% 14 14% web engineering technology? Is there a procedure for ensuring that appropriate 1.7 levels of user/ % 35 35% 23 23% 11 11% customer/marketing input is made throughout the project? Where other non-web 1.8 resources are critical to the success of the project is there a procedure for ensuring their availability according to plan? % 31 31% 17 17% 22 22% Average Standard deviation Figure (4.20) shows that the most of the respondents answers to most of the questions (1-8) are No. The questions with the highest No percentages were as follows: Firstly, the question (1.1) (Does each web project have a nominated web project manager?) has ratio 42% of No answers. Secondly, the question (1.4) (Is a change control function established for each web project?) has ratio 39% of No answers. Thirdly, the question (1.6) (Is there a procedure for maintaining awareness of the state-of-the-art in CASE of web engineering technology?) has ratio 37% of No answers. Finally, each of question (1.2) (Does the web project manager report to a business project manager responsible for the overall benefit of the project to business?) and question (1.3) (Does web QA function exist within an independent 88

107 reporting line from a web development project management?) has the same ratio 36% of No answers. Respondents Organizational Issues Questions (1-8) Yes No Does not apply Don t Know Figure (4.20): Organizational Issues in Web Engineering Practices Standards and Procedures This section contains descriptive statistics (frequency and percentage) and factor analysis of the results related to standards and procedures as shown in table (4.19). This table represents also the relative significance to the sample responses about standards and procedures variable, it showed a one factor solution of standards and procedures. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.806) which is related to question 2.7, where question 2.6 is in the second level, it equals (0.776). While question 2.4 in the third level of significance it equals (0.762). While question 2.1 in the fourth level of significance it equals (0.702). While other questions: Q2.3(0.699), Q2.2(0.598), Q2.9(0.576), Q2.8(0.568), Q2.10(0.567), Q2.11(0.561), Q2.13(0.495), Q2.5(0.478) and Q2.12(0.386) came in the 5 th, 6 th, 7 th, 8 th, 9 th, 10 th, 11 th, 12 th and 13 th level respectively. Figure (4.21) shows that most of the respondents answers to most of the questions are yes. The questions with the highest yes percentages were as follows: Firstly, question (2.11) (Does test planning prior to programming beginning based on user requirements and high-level design documents?) has ratio 44% of yes answers. Secondly, the question (2.2) (Do management formally conduct periodic reviews of each web project status?) has ratio 42% of yes answers. Thirdly, the question (2.6) (Is there a documented procedure for estimating web applications size and productivity measures?) has ratio 41% of yes answers. Fourthly, each of the question (2.3) (Are there procedures to ensure that external web development subcontracting organizations follow a disciplined development process?), and the question (2.10) (Are there procedures to ensure that the functionality and weaknesses of the system which the web application is replacing are reviewed?) has same ratio 40% of yes answers. Finally, question (2.1) (Do management formally assess the benefits, and risk of each web project prior to make contractual commitments?) has ratio 39% of yes answers. 89

108 Table (4.19): Statistics of Standards and Procedures in Web Engineering Practices no Question Do management formally assess the benefits, viability, and risk of each web project prior to making contractual commitments? Do management conduct periodic reviews of each project s status? Are there procedures to ensure that external web development subcontracting org.s, follow a disciplined development process? For each project, are independent audits (inspections or walkthrough) conducted for each major stage in development? Are common coding standards applied to each web project? Is there a documented procedure for estimating project size and thus for using productivity measures? Is a formal procedure used to produce web development effort, schedule, and cost estimates? Is a formal procedure (review) used whenever a deliverable (user requirements) is passed from one discrete group to another to ensure it is properly understood? Is there a mechanism to ensure that systems selected for development qualitatively or quantitatively support org. s objectives. Are there procedures to ensure that the functionality, strengths, and weaknesses of system which the web application is replacing are formally reviewed? Does test planning commence prior to programming beginning based on user requirements and highlevel design documents? Is independent testing conducted by users under the guidance of SQA before any system goes live? Is there a procedure to check that system configuration (programs and data) passing user acceptance test is the same as that which is implemented for live operation and that no changes are made to a "live" version of any system? Average Standard deviation factor analysis Does Don t Yes No Not apply know freq % freq % freq % freq % % 27 27% 20 20% 14 14% % 31 31% 16 16% 11 11% % 22 22% 21 21% 17 17% % 31 31% 20 20% 16 16% % 28 28% 20 20% 17 17% % 29 29% 17 17% 13 13% % 28 28% 21 21% 17 17% % 28 28% 23 23% 17 17% % 26 26% 23 23% 18 18% % 27 27% 22 22% 11 11% % 23 23% 20 20% 13 13% % 32 32% 20 20% 13 13% % 30 30% 21 21% 15 15%

109 Standards and Procedures Respondents Yes No Does Not Apply Don t Know Questions (1-13) Figure (4.21): Standards and Procedures in Web Engineering Practices Web Metrics This section contains descriptive statistics (frequency and percentage) and factor analysis of the results related to web metrics as shown in table (4.20). This table represents also the relative significance to the sample responses about web metrics variable. It showed a one factor solution of web metrics. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.766) which is related to question 3.7, whereas question 3.3 is in the second level, it equals (0.753). While question 3.6 in the third level of significance it equals (0.699). While question 3.1 in the fourth level of significance it equals (0.698). While other questions: Q3.4(0.665), Q3.8(0.564), Q3.5(0.547) and Q3.2(0.50) came in the 5 th, 6 th, 7 th and 8 th level respectively. Figure (4.22) shows that, the ratios are distributed among Yes, No, Dose not apply and don t know, but the most of respondents 32.25% have answered the questions with don t know, whereas 24.62% of respondents answer Yes. The questions with the highest Don t know percentages were as follows: Firstly, question (3.2) (Are records of web application size maintained for each web application configuration item, over time, and fedback into the estimating process?) has ratio 36% of Don t know answers. Secondly, each of the question (3.1) (Are records of actual project resourcing and timescales versus estimates maintained (at individual resource/resource-type level) and regularly analyzed/fed-back into the estimating and scheduling procedures?), and the question (3.4) (Are statistics on test efficiency (% of errors actually detected by an activity against the maximum theoretically possible) gathered and analyzed for all testing stages in the development process?) has the same ratio 35% of don t know answers. Thirdly, question (3.3) (Are statistics on the sources of errors in web application code gathered and analyzed for their cause, detection and avoidance measures?) has ratio 34% of Don t know answers. Finally, question (3.8) (Do records exist from which (and requiring nothing extra) all current versions and variants of web systems and their components can be quickly and accurately reconstructed in the development environment?) has ratio 31% of Don t know answers. 91

110 Table (4.20): The Frequency Distribution of Web Metrics in Web Engineering Practices Does Don t No. Question Factor Yes No analysis Not apply know Freq. % Freq. % Freq. % Freq. % Are records of actual project resourcing and timescales 3.1 versus estimates maintained (at individual resource level) % 24 24% 17 17% 35 35% and regularly analyzed/fedback into estimating and scheduling procedures? 3.2 Are records of web application size maintained for each web application configuration item, % 27 27% 11 11% 36 36% over time, and fed-back into the estimating process? 3.3 Are statistics on the sources of errors in web application code gathered and analyzed for % 29 29% 12 12% 34 34% their cause, detection and avoidance measures? Are statistics on test efficiency (% of errors actually detected by an activity against the 3.4 maximum theoretically % 26 26% 17 17% 35 35% possible) gathered and analyzed for all testing stages in the development process? Is "earned value" project tracking used throughout the web development (actual 3.5 versus planned deliverables analyses, designed, unit tested, % 24 24% 21 21% 29 29% system tested, acceptance tested over time) to monitor project progress? Are estimates made and 3.6 compared with actuals for target computer performance % 29 29% 16 16% 30 30% (memory utilization, processor throughput and file I/O)? 3.7 Are post-implementation sw problem reports logged and their resolution effectively % 25 25% 21 21% 28 28% tracked and analyzed? Do records exist from which all current versions and variants of web systems and 3.8 their components can be % 26 26% 20 20% 31 31% quickly and accurately reconstructed in the development environment? Average Standard deviation

111 40 Web Metrics Respondents Yes No Does not apply Don t know Questions (1-8) Figure (4.22): Web Metrics in Web Engineering Practices Control of the Development Process This section contains descriptive statistics (frequency and percentage) and factor analysis of the results related to control of the development process as shown in table (4.21). This table represents also the relative significance to the sample responses about control of the development process variable. It showed a one factor solution of control of the development process. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.710) which is related to question 4.4, where question 4.1 is in the second level, it equals (0.648). While question 4.3 in the third level of significance it equals (0.611). While question 4.2 in the fourth level of significance it equals (0.532). While other questions: Q4.6(0.524) and Q4.5(0.50) came in the 5 th and 6 th level respectively. In this section, the figure (4.23) shows that most of respondents have answered the questions with does not apply. The questions with the highest Does not apply percentages were as follows: Firstly, question (4.3) (Is there a procedure for controlling changes to the web applications requirements, designs and accompanying documentation?) has ratio 47% of Does not apply answers. Secondly, the question (4.2) (Does the overall business project manager gain agreement and sign-off from all parties who have produced detailed estimates and schedules before publishing or revising a consolidated project plan?) has the ratio 46% of Does not apply answers. Thirdly, question (4.5) (Is there a mechanism for assuring that regression testing (i.e. the forced re-run of all previous tests prior to any new tests) is routinely performed during and after initial implementation?) has ratio 43% of Does not apply answers. Finally, question (4.4) (Is there a procedure for controlling changes to the code and specifications?) has ratio 40% of Does not apply answers. 93

112 Table (4.21): The Frequency Distribution of Control of the Development Process Does Don t Factor Yes No Not No. Question analysis know apply Freq. % Freq. % Freq. % Freq. % 4.1 Are estimates, schedules and subsequent changes produced only by the project managers who directly control the project resources and are % 15 15% 38 38% 14 14% fully aware of their abilities and availabilities? 4.2 Does the overall business project manager gain agreement and sign-off from all parties who have produced detailed estimates and schedules before % 46 46% 8 8% publishing or revising a consolidated project plan? 4.3 Is there a procedure for controlling changes to the web applications requirements, designs and % 10 10% 47 47% 8 8% accompanying documentation? 4.4 Is there a procedure for controlling changes to the code and specifications? % 16 16% 40 40% 12 12% 4.5 Is there a mechanism for assuring that regression testing (i.e. the forced re-run of all previous tests prior to any new % 19 19% 43 43% 7 7% tests) is routinely performed during and after initial implementation? 4.6 Do procedures exist to ensure that every required function is tested? % 14 14% 39 39% 10 10% Average Standard deviation Control of the Development Process 50 Respondents Yes No Does not apply Don t know Questions (1-6) Figure (4.23): Control of the Development Process in Web Engineering Practices Tools and Technology This section contains descriptive statistics (frequency and percentage) and factor analysis of the results related to tools and technology as shown in table (4.22). This table represents also the relative significance to the sample responses about tools and technology variable. It showed a one factor solution of tools and technology. The factor analysis showed clear discriminate validity since all items are loaded on that one factor. The first level regarding its significance equals (0.706) which is related to question 5.4, where question 5.6 is in the 94

113 second level, it equals (0.705). While question 5.7 in the third level of significance it equals (0.696). While question 5.1 in the fourth level of significance it equals (0.671). While other questions: Q5.5(0.657), Q5.2(0.565) and Q5.3(0.527) came in the 5 th and 6 th level respectively. In his section, the figure (4.24) shows that most of respondents have answered the questions with Yes. The questions with the highest Yes percentages were as follows: Firstly, question (5.7) (Are software tools used for web project planning, estimating, scheduling, and critical path analysis?) has ratio 72% of Yes answers. Secondly, the question (5.4) (Are software tools used for tracking and reporting the status of the web based applications?) has the ratio 70% of Yes answers. Thirdly, question (5.5) (Are prototyping methods used in ensuring the requirements elements of the web based applications?) has ratio 66% of Yes answers. Fourthly, question (5.2) (Are design notations used in web based applications design?) has ratio 64% of Yes answers. Finally, question (5.6) (Are Is a data dictionary available for controlling and storing details of all data files and their fields?) has ratio 60% of Yes answers. Table (4.22): The Frequent Distribution of Tools and Technology in Web Engineering Practices Does Don t Factor Yes No Not No. Question Know analysis Apply 5.1 Are software tools used to assist in forwards and/or backwards tracing of web application requirements to web designs through to code? 5.2 Are design notations used in web based applications design? 5.3 Are automated testing tools used (for capturing and replaying tests) ensuring logic paths coverage)? 5.4 Are software tools used for tracking and reporting the status of the web based applications? 5.5 Are prototyping methods used in ensuring the requirements elements of web applications? 5.6 Is a data dictionary available for controlling and storing details of all data files and their fields? 5.7 Are software tools used for web project planning, estimating, scheduling, and critical path analysis? Freq. % Freq. % Freq. % Freq. % % 19 19% 17 17% 13 13% % 15 15% 11 11% 10 10% % 19 19% 13 13% 11 11% % 12 12% 10 10% 8 8% % 15 15% 7 7% 12 12% % 16 16% 15 15% 9 9% % 13 13% 8 8% 7 7% Average Standard deviation

114 80 Tools and Technology Respondents Questions (1-7) Yes No Does not apply Don t Know Figure (4.24): Tools and Technology in Web Engineering Practices 4.5 Summary of Statistical Analysis of the Second Questionnaire This section presents the summary of the statistical analysis of the responses to the second questionnaire which was done in large Jordanian enterprises which undertaken large web development Summary of Analysis Related to Respondents Background The analysis of the respondents background shows the following results: 1. About 41% of the respondents occupied the position of software engineering process group member. Whereas about 28% of respondents occupied the position of technical member. Few respondents occupied either the position of project leader or manager. 2. About 24% of the respondents involved in software design activity and 21% of them involved in software requirement. Other percentages of respondents involved in either code test, or integration. Whereas a small percentage (10%) of respondents involved in SQA, SPI (8%) and configuration management (6%). This result implies that there is a weakness in SQA, SPI and configuration management in these enterprises. 3. Only 12% of the respondents received CMMI-related training. 4. A small percentage (19%) of the respondents participated in previous SPI activities. These results indicate that most of respondents did not have required knowledge in SPI. 5. High percentages (76%) of respondents had 5 years or less of experience in their present enterprises and 49% of them had 5 years or less overall software experience. 6. High percentages (53%) of respondents had basic knowledge of web development. Whereas only 31% of respondents had advanced knowledge of web development Summary of Analysis Related to Development and Test Methods The analysis of the development and test methods shows the following results: 1. All of large Jordanian enterprises have 50 or more than 50 employees. About 50% of these enterprises have number of developers in the range developers. 96

115 2. The highest ratio (66%) of web applications domain in Jordanian enterprises was for business information systems group. Whereas e-business ratio was 50% and e-banking ratio was 40%. Each of personal web sites group, and web tools had small ratios. 3. All of these Jordanian enterprises adopted in-house web applications development. Whereas only 42% of these enterprises adopted outsourcing together with in-house. Very small percentages (23%) of these enterprises adopted reusability. 4. Most of these enterprises developers familiar with few number of software development methods such as OOP (70%), structured programming (64%), waterfall (63%) and flowcharting (51%).Whereas very few developers which familiar with agile methods (12%). 5. Many of software development methodologies mostly adopted by these enterprises such as: waterfall model (62%), OOP (51%), structured programming (48%) and flowcharting (43%). Whereas only 11% of these enterprises adopted agile methods. 6. There are 64% of Jordanian enterprises that adopted integration test as a test type. Whereas only 30% of these enterprise adopted web metrics. 7. The highest percent of these enterprises (65%) performed testing of web applications as assurance activities, whereas 43% of them performed code review as assurance activities. 8. About 52% of these enterprises involved software assurance group, whereas 37% of them depended on project team Summary of Possible Symptoms at Organizations According to analysis of the highest values related to mean results of severity score description in the table (4.17), there are many problems that faced large Jordanian enterprises when they were developing large web applications as follows: 1. Problems in delivery dates. 2. The developers can not examine more occurrence project problems and fix it. 3. There is a shortage of skilled developers. 4. There are insufficient resources. 5. Poor project estimation of cost, time and effort. 6. Poor and insufficient project planning. This lead to waste time and resources. 7. There are problems conflicting in project scheduling. 8. The current project methods are so historical and accepted by these enterprises. 9. Communication problems between team and stakeholders. 10. Poor project management of development process. 11. Problems in requirements changing and misunderstanding. 97

116 4.5.4 Summary of Web Engineering Practices The adoption level of the organizational issues in large Jordanian enterprises according to table (4.18) was 31%. There are few large Jordanian enterprises that: 1. Assign a project manager for each web project. 2. Have a separate quality assurance function. 3. Establish a change control function for each web project. 4. Establish a training program for all newly appointed web managers. 5. Establish a procedure to maintain awareness of latest web engineering technology. 6. Ensure availability of non software and web resources. 7. Establish a procedure to ensure the appropriate levels of user input during project. While, the adoption level of the standards and procedures in large Jordanian enterprises according to table (4.19) was 37.07%. There are many large Jordanian enterprises that: 1. Assess the benefits and risks of project prior to making contractual commitments. 2. Conduct periodic reviews of the status of each web project. 3. Have method to ensure that subcontractors follow disciplined web process. 4. Conduct inspection and walkthroughs at each stage in web development process. 5. Apply common coding standards for web projects. 6. Have formal methods of estimating web applications size. 7. Use formal methods to produce development effort, schedule and cost estimates. 8. Have a formal review of deliverables is passed from one project group to another. 9. Procedure to review the functionality of system which the web application is replacing. 10. Plan testing before beginning of programming based on the user requirements. 11. Perform independent testing by users under guidance of software QA. 12. Check if the system configuration (program and data) pass the user acceptance test. And, the adoption level of the web metrics in large Jordanian enterprises according to table (4.20) was 24.62%. There are few large Jordanian enterprises that: 1. Gather and analyze statistics on test efficiency for all test stages in development. 2. Maintain records of project resourcing and timescales versus scheduling procedures. 3. Maintain records of project size for each web application configuration item. 4. Gather statistics on errors sources in web application code and analyze for their cause. 5. Use earned-value project tracking during web development to monitor project progress. 6. Make estimation and compare with actual for target computer performance. 7. Log post-implementation software problems and track and analyze their resolution. 8. Have records to reconstruct all versions of web systems in the development environment. 98

117 And, the adoption level of the control of development process in large Jordanian enterprises according to table (4.21) was 33.83%. There are few large Jordanian enterprises that: 1. Allow only project managers to control the project resources and produce estimates, schedules and control subsequent changes. 2. Project manager gain agreements from all parties involved before publish project plans. 3. Adopt procedure to control changes to code, requirements and design. 4. Adopt procedures to ensure that every function is tested. 5. Have a mechanism to ensure testing performance during and after initial implementation. Whereas, the adoption level of the tools and technology in large Jordanian enterprises according to table (4.22) was 62.85%. Most of large Jordanian enterprises are: 1. Use software tools to assist in tracing of web application design and code. 2. Use design notations used in web applications design. 3. Use automated testing tools. 4. Use software tools for tracking and reporting the status of the web applications. 5. Use prototyping methods for ensuring the requirements elements of web applications. 6. Use a data dictionary to store details of all data files and system development. 7. Use software tools for project planning, estimating and scheduling. The overall average (38%) of adoption level implies that the surveyed enterprises have adopted at best 38% of all the web engineering best practices. Figure (5.25) shows the best practices adoption in large Jordanian enterprises. A the end, The previous results showed that there is a weakness in the application of web engineering best practices in large Jordanian enterprises, especially in web metrics, organizational issues and then in control of the development process. The Enterprises showed a high adoption ratio for using web tools and technology, and then for using standards and procedures in the web applications development process. 70% 60% 50% 40% 30% 20% 10% 0% Organizational issues Web Enginering Best Practices Standards and Procedures Web Metrics Web Enginering Best Practices Control of the development process Series1 Tools and Technology Figure (4.25): Overall Best Practices Adoption in Large Jordanian Enterprises 99

118 Chapter 5 Hybrid Web Engineering Process Model for Large-Scale Web-Based Applications Development 5.1 Introduction The large web development enterprises aim to produce web applications that should be maintainable, reliable, efficient and appropriate for user interface and delivered within the time and budget. We need a web process model that describes the phases of web applications development to help reducing the difficulty in building web applications. At the same time, it is important to find a suitable process model that complies with software process improvement and to be capable of being tailor able to any particular stage of organizational development of large web development enterprises. Extreme programming is the lightweight process model that can help large enterprises in implementation of SPI. This research focuses on proposing a Hybrid web engineering process model for large web applications development to improve web process models and decrease the failure rate of these large web applications. The proposing of this Hybrid model based on the literature researches in web development and also based on the results of the analytical survey. The target population of this research include all large Jordanian enterprises which undertaken large web development. We hope that this Hybrid model overcome as possible as the web development problems which obtained from the literature and also web development problems in these enterprises. This chapter includes details about the need for a standard web engineering process model; problems related to large web development to be solved; and the proposed guidelines for constructing web engineering process models. This chapter includes the detailed description of the proposed Hybrid model, its advantage principles, components and activities. This chapter includes also details about software development models used in the Hybrid model; integrating web engineering practices in Hybrid model; SPI in the Hybrid model. Finally this chapter includes the problems solved by the Hybrid model and the advantages and the limitations of the Hybrid model. 5.2 The Need for a Standard Web Engineering Process Model The goal of web applications developers is to build effective, quality and cost-effective web applications that support business objectives and customer requirements. Therefore the developers employ some kind of system development process model to direct the project s 100

119 life cycle. Most of current web development models provide users with approaches for the systematic design of high-level, well-organized and easy to maintain web applications in different domains. Their coverage of the application life cycle focuses on the design stage with different levels of support provided at different phases within the design process. None of the current web methods addresses in detail the overall web development process [181]. Agile development methods have been embraced by many software companies because of their lightweight nature. Although many instructional resources exist to guide companies through a change to agile development, there are few resources available on agile development. Companies often implement agile development to solve a variety of problems they encountered with traditional development processes. These problems are catalysts for requirements change; inaccurate time and resource estimates; lack of visibility and predictability in the development process; feedback arriving late in the release cycle; and long release cycles. With agile, the company has seen more frequent and predictable releases. Developers feel this process improves work quality and overall job satisfaction. However the user experience team has found the transition challenging [182]. At the same time, the agile methodologies have limitations in project management and large development teams. The web development enterprises faced problems that influence SPI programs. Therefore, these enterprises need an efficient mechanism for implementing SPI initiatives in their development environment. Moreover, it is essential to manage software processes efficiently to maintain the SPI implementations and to increase the chances of obtaining positive results of SPI investments [173]. There is a need for project specific process tailoring. Many reasons for a standard process framework such as [54]: process standardization is required to permit training, management and review; with standard methods, each project s experiences can contribute to overall process improvement in the organization; process standards provide a structured basis for measurement; it is impractical to produce new framework for each project because process definitions take time and effort to produce; and finally a standard process framework will need only modest customization to meet most special project needs because the basic tasks are common to most software projects. 5.3 Problems (Related to Large Web Development) to be Solved Many literature researches highlighted the serious problems which affecting the large web applications development. Also, after we analyzed the literature related to web development 101

120 in chapter1, we obtained many other problems. Table (5.1) shows the most of these web development problems which we would like to overcome as possible as in this research. Table (5.1): Problems in the Literature Web Applications Development Problems 1 Poor project estimation. 2 The developed web-based application exceeded the budget. 3 Focused on parts of web development process. 4 Did not consider the size of web application. 5 Did not consider the number of developers. 6 Problems in requirement engineering and analysis phase. 7 Lack the stakeholders involvement. 8 Poor project management of large web development process. 9 Lack integration with agile methodologies principles. 10 Lack risk analysis and management. 11 Flawed design and development process. Poor understanding and lack of well-defined web development processes for the 12 building of large web applications in large enterprises. 13 Poor utilization of SPI in large enterprises in order to increase the productivity. According to analysis of Mean results of symptoms in the table (4.17), there are many problems that faced large Jordanian enterprises which undertaken large web development. Table (5.2) shows the most serious problems. The survey also showed the problems related to web engineering best practices as shown in table (5.3). Table (5.2): Problems of Large Web Development in Large Jordanian Enterprises 1 Problems in delivery dates. 2 The developers can not examine more occurrence project problems and fix it. 3 There is a shortage of skilled developers. 4 Sometimes there aren t sufficient resources. 5 Poor project estimation cost, time and effort. 6 Poor and insufficient project planning. This lead to waste time and resources. 7 There are problems conflicting in project scheduling. 8 The current project methods are so historical and accepted. Most of these enterprises suffer from the difficulty to change to more newly suitable methods. 9 Communication problems between team and stakeholders. 10 Poor project management of development process. 11 Problems in requirements changing and misunderstanding. 12 Lack of standardization and refactoring components in programming the web applications. 13 Basic knowledge of web applications development. Table (5.3): Problems of Web Engineering Practices in Large Jordanian Enterprises Problem Level of adoption Organizational Issues. 31% Standards and Procedures %. Metrics % Control of the development process % 102

121 5.4 Guidelines for Constructing Web Engineering Process Models Agile methods promise higher customer satisfaction, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability and high assurance. Both approaches have shortcomings that, if they left unaddressed, they lead to project failure. In this section, we propose a set of guidelines which must be considered when constructing web engineering process models for large web applications development. Figure (5.1) shows these guidelines. These guidelines are used to improve web process models and decrease the failure rate of these web applications. These guidelines are based on the web development problems addressed in the literature researches and problems obtained from the survey: 1. Considering web application's properties such as size, number of developers, objectives and goals. Addressing non technical issues such as: organizational and management policies; human resources; and legal, cultural and social aspects. 2. Understanding web application's operational environment and overall functions through customer communications and requirement gathering. The environment change with the time and collecting data in such cases is complex because it requires knowledge about all stakeholders needs and problems. 3. Possible division of large numbers of developers into a set of small sub teams. 4. Adopting management method to manage development process of web application. 5. Identifying and involving all stakeholders (users of the web application and organization that needs this application and those who fund system s development). Coordinating stakeholders to follow time table and coordinate with each other and sub team members. 6. Identifying technical and non technical requirements of the web application. 7. Customer communication and feedback during the overall web development process. 8. Considering all phases of the development process such as requirement analysis, design, coding, testing, documentations and maintenance. 9. Division of large web application according to its size into many sub web applications as shown in figure (5.2). Developing and implementing the web application architecture that meets requirements. More goals description, planning and cost estimation for each sub web application. 10. Risk analysis of overall web application and for each one of sub web application. 11. Adopting agile XP principles such as pair programming and refactoring. 12. Appropriate documentation of the overall large web application activities. 13. Considering and undertaking CMMI key process areas and goals. 103

122 Web Application s Environment Size of WebApp.& the number of Developers Key process areas of CMMI Appropriate Documentation Typical Tasks in the WebApp Development Process Life Cycle Developers' arrangements Management methodology Agile Properties Stakeholders' involving Risk Analysis Division of Web Application Req. elicitation and classification Figure (5.1): The Proposed Guidelines for Constructing Web Eng. Process Models WebApp. Environment Large Scale Web Application Sub WebApp.A Sub WebApp.B Sub WebApp.N Develop. TeamA Develop. TeamB Develop. TeamN Customers Customers Figure (5.2): Web-Based Application Division 5.5 The Proposed Hybrid Web Engineering Process Model The traditional software methodologies aim to make software development more efficient for producing better quality systems. These process models have many problems and as a reaction to these problems, a new group of agile methods evolved. Agile methods accept changing requirements, more people-oriented rather than process-oriented and require an effective team of quality developers [1][2]. However, software process models are not mutually exclusive and are not isolated from each other. As an example, the Spiral model uses ideas from the Waterfall, Evolutionary and Prototyping models. Many factors determine the appropriate process model: project size and complexity; required development time; degree of 104

123 risk; and degree to which the customer requirements may change [2]. This section includes a detailed description of the Hybrid web engineering process model The Features of the Hybrid Web Engineering Process Model The Hybrid web engineering model is based on integration of traditional (Throwaway Prototype and Spiral), agile (XP) and web engineering (WebE) process models to improve web process models for large web applications development as follows: 1. The Spiral model to be conducted by centralized team to manage all sub teams. 2. The Throwaway Prototype model for requirement gathering of web application. 3. The web engineering process model (WebEng) to be conducted by each one of the sub teams to develop one sub web application. 4. The Extreme Programming (XP) to be conducted by each one of the sub teams to gain short development life-cycle times, small multidisciplinary development teams and delivery of web application with minimum likelihood of failure. Hybrid web engineering process model is based on a set of software development principles and SPI practices such as: develop web application iteratively; carefully analysis and manage requirements; use component-based architecture; visually model web application; testing and verifying web application quality; and control changes to web application. It is also consider the web engineering practices and CMMI key process areas and goals. The major distinguishing features of the Hybrid model against other existing web engineering models for large web applications are shown in table (5.4) The Components of the Hybrid Model The Hybrid model consists of two major components as follows: 1- Management Component to be conducted by the centralized team to manage sub teams and overall large web development process. The centralized team consists of many professional software engineering members; each one of them has responsibility of one sub team management. They meet weekly. 2- Development Component to be conducted by a set of sub teams. The sub teams may work in parallel (independent sub systems) or may work in incremental fashion if each sub system is depend on each other. Figure (5.3) shows the relation ships between the management team and other sub teams. They met every day. 105

124 Table (5.4): The Features of Hybrid by Principles No. Hybrid Principles 1 Possible division of large-scale web application into a set of sub web applications. 2 Possible division of large numbers of developers into many small sub teams. 3 Centralized management team to manage the development process of large web application. 4 Stakeholder identification and classifications into groups. 5 Stakeholders and customers inclusion and feedback during overall web development process. 6 Requirement analysis, classification, management and development 7 Suitable planning of large web application and also for each one of sub application. 8 Risk analysis of large web application and also for each one of sub application. 9 Cost, effort and time estimation of large web application and also for each one of sub application. 10 Focusing on overall development process phases such as: requirement gathering and analysis, cost estimation, planning, design, coding, testing, integration, documentations and maintenance. 11 Adopting the Spiral traditional software process model by management team. 12 Adopting the Throwaway Prototype traditional software process model by each sub team. 13 Adopting the Extreme programming (XP) agile methodology by each sub team. 14 Adopting the web engineering process model (WebEng) by each sub team. 15 Adopting proposed XP-PROTOTYPING UI design approach by each sub team for sub application. 16 Configuration management of overall large web application. 17 Testing, verification and validation of the large web application and for each sub web application. 18 Overall large web application project monitoring and control. 19 Provide technical solutions for each sub web application Integration of product, project management, teaming, supplier management and organizational environment. Managers and developers training in the large web development enterprises on both CMMI and web engineering best practices 22 Integrating the software quality assurance (SQA) activities with the web development process. 23 Conducting the CMMI key process areas and goals. 24 Conducting the web engineering best practices. 25 Documenting and integrating all large web application and all sub application activities The Role of the Management Component Figure (5.4) explains the main steps which accomplished between each one of the sub team and the management team. The management team has the responsibility to do the following: 1. Understanding the system s overall functions, business objectives, goals, operational environment and stakeholders needs and their problems through customers communications and requirements gathering. 2. Requirement analysis and classification into classes. 106

125 3. Dividing the large web application according to its size in to many sub applications. 4. Dividing the large development team into a set of small sub teams. Assign the responsibilities for particular tasks to certain team members during the project. 5. Adopting the advantage properties of Spiral method (planning, scheduling, cost estimation and risk analysis for the overall large web application components. 6. Identifying and involving all stakeholders (users of web application and organization that needs this application and those who fund system s development). 7. Assigning each management team member the management role of the only one sub team and giving him the initial requirements, planning, risk analysis and estimation of one sub web application. Then later, accepting from him the Prototype of sub application. Repeat the process until delivery of Prototype of sub application that matching the requirements of sub web application. After the agreement of the management team on the final Prototype, the sub team begins to develop this web application. The management team integrating each developed sub application with overall large web application and if there is a mismatch with requirements then returning feedback about the sub application problems. 8. Addressing the non technical issues such as organizational and management policies; human resources development; and legal, cultural and social aspects. 9. Integration, testing and evaluating performance of all sub web applications. Sub Team Sub Team Throwaway Prototype + WebE process + XP Throwaway Prototype + WebE process + XP Management Team SPIRAL Sub Team Throwaway Prototype + WebE process + XP Sub Team Throwaway Prototype + WebE process + XP Sub Team Throwaway Prototype + WebE process + XP Sub Team Throwaway Prototype + WebE process + XP Figure (5.3): The Complete Hybrid Web Engineering Process Model 107

126 Customer Communications Management Team (Spiral) Customer communications and requirement gathering. 2- Analysis objectives, goals and functions of the large web application. 3- Divide the large web application into many sub web applications. 4- Divide the large number of developers into many sub teams. 5- Project planning and risk analysis of overall large web application. 6- Cost estimation and project scheduling of overall large web application. 7-Assign each sub application to the sub team manager and accept later the delivery product (sub web application) from him. 8- Integration of all sub web applications into the final large web application. 1- Take requirements of the sub web application. 2-Apply Throwaway Prototype + WebE + XP processes to develop sub application. 3- Deliver the sub application to management team. 4- Accept management team feed back. 5- Make the required changes and so on. Manager of sub system A Customer Communications Sub Team A Throwaway Prototype + WebE process + XP Figure (5.4): The Interaction Process between the Management and Sub Team The Role of Development Component Figure (5.5) shows the role of each one of the sub team in order to build the required sub web application and deliver it to the management team. The management team verifying and integrating this sub web application with the overall large web application. The role of each sub team can be summarized into the following points: 1. The manager of each sub team takes the sub web application requirements. 2. More analysis for these requirements through Use cases/user stories. 3. More description of sub application goals, tasks and estimated effort. 4. Each sub team adopts the Throwaway Prototype for more requirements gathering. Each sub team manager display the sub web application Prototype and take the feed back from the management team until the final version of sub web application Prototype which match the user requirements is build. 5. Each sub team builds the sub web application using the WebEng process model and XP principles according to the final version of sub web application Prototype. 6. The manager of each sub team delivers the sub application with its documentation to the management team to integrate it later with the main web application after testing it. 108

127 Release the Sub Web Application to Centralized Team Manager of sub web application A Delivery sub web application and Feedback from management team Delivery Accept Management team communication + Customer communication Verification Feedback Throwaway Prototype for sub web application Acceptance test Customer use Customer evaluation Construction (Coding component test) (Pair programming) (Refactoring) Feedback Not accept The 12 practices of XP are applied during the development process Planning of sub web application Modeling 1- Analysis model A- Content Analysis. B- Interaction Analysis. C- Functional Analysis. D- Configuration Analysis. 2- Design model A- Content design B- Aesthetic design C- Architectural design D- Interface design E- Navigation design F- Component design Figure (5.5): The Integration of Web Engineering Process with XP Practices Stakeholders Coordination in the Hybrid Model The Hybrid model adopts identifying the stakeholder roles within the development teams during large web applications development as follows: 1. End users which represent all users of the developed application in a project. 2. Clients which represent persons who are paying for the project development. 3. Software engineers which have the responsibility for project s technical issues. 4. Creative designers which have responsibility for aesthetic issues (layout, color). 5. Team leader which responsible for team guidance and project management. The management team has the responsibility to manage the stakeholders by: identifying and contacting all the stakeholders; defining and agreeing the specific interests and involvement of each stakeholder; and defining the stakeholder communication strategy. On the other hand, and in order to ensure the successful delivery of web applications and to 109

128 overcome many reasons that lead to failure of web applications. We suggested the following points to be included with the Hybrid model: 1. Hire the best developers. 2. Provide developers with training and education on web engineering best practices. 3. Encourage the interaction and information exchange between developers in each sub team and also between the other different development teams. 4. Emphasis team work by adopting pair programming by each sub team. 5. Encourage and motivate the developers by removing the obstacles. 6. Align personal goals with organizational objectives Requirement Engineering and Management in Hybrid Model The development of web applications is a complicated and time-intensive process. It consists of defining the requirements for the web application to be developed and then transforming those requirements into a web application. The requirement engineering (definition and gathering) is the first and most important stage in successful web development process. Therefore, performing requirement engineering ineffectively will significantly impact the outcome of the web application under development. The users of web applications are not easily identified and their requirements are more difficult to define. Therefore, we suggested many steps to be integrated with the Hybrid model as follows: 1. Focusing on all types of requirements such as: system requirements; users/clients requirements; functional requirements; non functional requirements; and user interface design requirements. These requirements must be gathered from customers at the beginning and even during the web development process. 2. Requirements understanding and analysis through the customer integration and communication with the team during the planning phase. Any changes in requirements are quickly exchanged and discussed. 3. The management team is responsible to produce the main document of web application s requirements to define what the web application must do to meet these requirements. This include: main objectives of large web application; constraints placed on developers; and overall web application work plan. 4. The use of XP customer communication principle during the overall development process lead to overcome the problem of requirements misunderstanding. 5. The use of more suitable requirement engineering approach when developing web applications to be adopt by centralized team and also by each one of sub teams. 6. The requirements management is important to: analyze the problem; understand stakeholder needs; define the system; manage system s scope; and manage changing 110

129 requirements. The requirements management is concerned with meeting the needs of end users by identify and specify what the end users need and identify when those needs change. The benefits of requirements management are: the correct requirements generate the correct product and the customer's needs are met; necessary features will be included; and reducing the development cost Requirements Development Developing the customer requirements is adopted by both the centralized team at the beginning of the development process and then by each one of the sub team to get detail information about the sub web application to be developed. The Hybrid model includes the following steps: 1. The sub team developers support customers in elicit requirements and specifies them in story cards and functional tests. The developers can get more details from the customer during development. 2. The developers develop product requirements by refining the customer requirements into product requirements. 3. Analyze and validate requirements through customer communication during requirements elicitation. 4. Adopting XP principles by each sub team lead to acceptance of changing requirements and use of iterations allow analysis and validation of requirements. 5. Operational concepts are established using functional tests Planning Phase in Hybrid Model In Hybrid model, this phase is one of the responsibilities of the centralized team to define the business objectives and specifies in detail the user requirements of the web-based application as follows: 1. What are the main purposes of the web application to be developed? 2. Who want to visit the site of web application? is it internet or intranet? 3. What are the user categories and what are their goals? 4. What experience do these users have? And what nationality are they? 5. What type of pages will meet users needs? (information, database and files) 6. How will they want to use the information: read it, print it or download it? 7. What is the budget for achieving these goals? 8. What type of browsers will they use? And how fast their communication links is? 9. What are quality and usability goals which can be evaluated to competition? The quality goals may be: suitability of web application s site to user's needs; web site s 111

130 professionalism; percentage of users who can find the information they need; and ease with which users can locate information. We suggested that the Hybrid model must include the following steps: 1. Develop a project (large web application) plan by the management team in terms of activities and deliverables. Individually develop all sub applications plans by sub teams. 2. Establish tasks estimates for each sub application. This is can be corrected during the project because Hybrid model adopt XP principles by each sub team. 3. The management team must identify risks, plan the training needs and resource utilization and the involvement of all stakeholders. 4. The management team should identify responsibilities for achieving quality and usability objectives, and estimate the resources and budget for these activities. Obtain commitment to release plans through involvement of all team members. 5. The relationships between sub web applications must be clarified and understood. 6. Monitor the progress of all sub applications and the dependencies between them Risk Analysis and Management in the Hybrid Model The Hybrid model includes the preparing for risk management task because it adopts the Spiral model to be conducted by management team. The Spiral model is: explicitly states how risk management is to be conducted; and identify and analyze of risks during the planning phase. A notable feature of the Spiral model is that risks are addressed repeatedly at each stage of the project. The Spiral model recognizes that the major steps have a number of activities in common with each other. Thus each major step consists of: 1. Identifying product objectives of this stage; alternatives ways of implement this stage (buy it or re-use); and constraints that affect this stage (cost, time, interfaces with components). 2. Dealing with risks by identifying risk s areas, and overcome or reduce this risk. 3. Requirements analysis, design, coding, validation and verification, planning next stage, and review. At the same time, further risk analysis to be conducted by each sub team for each sub application. Finally, the management team should consider the following: 1. Changing requirements (business changes and new functionality). 2. Changing priorities (different stakeholders and new situations). 3. Changing environment (new OS, languages, etc.). 4. Changing budgets (fewer developers). 112

131 5.5.7 Cost, Time and Effort Estimation in Hybrid Model After determining the goals, mission and vision and all functionality of large web application to be delivered to the end users, the centralized team must make an accurate cost, time and effort estimation for all functionalities. The process of cost, time and effort estimation is very complex and complicated task, and requires more professional persons to do it. But in the case of the Hybrid model, this process may be with less complexity because we earlier divide the large web application into a set of sub web applications and include the following steps: 1. Assign each sub web application to a sub team. This is done under the supervision of the centralized team. 2. Each sub team has the responsibility to undertake the sub web application and conduct more analysis and estimation of the cost, time and effort required to accomplish it. Each one of the sub team can adopt COCOMO model, which is one of the good cost estimation models to estimate sub application cost, time and effort and avoid insufficient resources being allocated to a project [131][132][133]. This model is described in details in section in chappter2. 3. The sub team manager has the responsibility to display the results of sub team estimations to the centralized team to verify and then later to accept it. 4. After that, the management team will take the cost, time and effort estimation of all sub web applications from the sub teams managers. 5. Then according to these results, they produce final cost, time and effort estimation for the overall large web application Management of Large Web Application Development in Hybrid Model Literature studies and the survey in this research assure that the web applications projects suffer from numerous problems such as: deadlines; inaccurate budgets; unforeseen project risks; changing requirements; poor planning and poor management. These problems may lead to failure of web application product and slow down the progress of web development organization. Although implementing the fundamentals of project management on large web applications is a challenging and complex task, we suggested that, it is possible to minimize these risks by improving project planning and management Management of Large Number of Developers in Hybrid Model Large number of developers in large enterprise reduces effectiveness of meetings and face to face communications. Therefore, in the Hybrid model, we suggested to: 113

132 1. Divide the large web application into a number of smaller sub web applications. 2. Divide the large number of developers into a number of sub development teams. 3. Distribute these sub web applications on the multiple sub development teams. 4. Construct centralized management team to manage these sub teams in efficient and systematic manner and also to manage the overall development process. We suggested that, the centralized team has the responsibility to: 1. Defining the roles and responsibilities of managers of all sub web applications. 2. Ensuring that the web development process must be executed according to documented development plan; and regular and effective mechanisms used to report work progress. 3. Involving and maintaining customer communication during the development process. 4. Performing complete testing and evaluation the performance of large web application. 5. Keeping the project sub teams intact until the project closes. On the other hand, the adoption of the XP principles by all sub teams reduces the management team overhead. We suggested that, the management team should consist of persons who have professional development and management skills. At the same time, the master of the management team has the responsibilities to: 1. Ensure that the team is fully functional and productive. 2. Plan meetings to enable close cooperation across all roles and functions. 3. Shield the team from external interferences. 4. Ensure that the process is followed in successful manner by continuous reporting and daily iteration review. Whereas, the owner of web application must define the web application s features; decide on release date and content; prioritize features according to market value; change features and priorities every month; and accept or rejects work results The Properties of Teams in the Hybrid Model A team is a set of equal persons which together are responsible for the quality and success or failure of a web application project. In Hybrid model, we suggested focusing on teamwork to improve the motivation of the project members so that everyone has equally important part in the project. Motivated team members will produce high quality web application and lead to a high identification of team members with the final product. We suggested that: a development process of large web application should include a well-defined team structure to include an efficient task assignment and clear communication guidelines between team 114

133 members. In most projects some goals have a higher importance and priority than others. We suggested that, all team members should have the responsibility for setting goals priorities to enable a project to profit from the full capability of team work. We suggested also many conditions that should be exist in the members of all teams in Hybrid as follows: play to win, communication skills, cooperation, trust, domain knowledge, adaptable to changes, ability to learn and team work skills. In Hybrid model, we suggested many factors that affect each one of development teams even the management team. These factors are: legacy systems; customers and stakeholders; project manager; web application requirements; other sub teams; web application architecture; software processes used by enterprise; SQA activities and SPI CMMI key process areas The Properties of Sub Teams Members in the Hybrid Model We suggested that each sub development team focuses on developing only one sub web application at a time. We suggested also, that each sub team has all the skills it needs (analysis, design, code, test and documentation). The sub team may consist of 5-10 people to cover all the skills. The objective of each one of sub team is to: 1. Define and agree the roles and responsibilities of sub teams members. 2. Define and agree the relationship between the sub team members. 3. Select the iteration goal and specifies work results. 4. Has the right to do everything within project boundaries to reach the goal. 5. Organize itself and its work. 6. Demo work results to the management team and web application owner. We suggested that each sub team should adopt the XP principles such as: planning game, short development cycles, pair programming, test-first programming, collective code ownership, frequency integration, refactoring and minimal documentation The Relationships of Development Teams in Hybrid Model From the interviews in enterprises, we noted that all of these enterprises involved number of development teams during the development process but each team concentrated in only one development phase. For example, requirement gathering and analysis team, design team, coding team, quality assurance team as shown earlier in figure (4.2). This technique may lead to the problem of teams dependencies; one team may wait long time for the outcome of another team. The requirement analyzers may delay the work of the designers and so on. As a solution for this problem, we suggested suitable relationships between these teams as 115

134 illustrated in figure (5.6). This is done by adopting a multidiscipline development teams. The benefit of management team is to control and management the overall sub teams during the development process. Each member belong to management team is a manger of only one sub team. The benefit of SQA team is to control and monitor the quality of web development process. Each SQA team member is a SQA of only one sub team. The requirement gathering team is to control the requirement gathering process related to all sub web applications. We suggested that, each multidiscipline sub team has all the skills it needs (analysis, design, code, test and documentation). Project Manager Requirement Gathering Team Designers Team Implementation team Testing Team Quality Assurance Team Team leaders Sub team A Sub team B Sub team N Figure (5.6): Relationships between Teams in Enterprises Management within XP Principles Adoption XP is suitable for: projects with uncertain requirements; projects that are risky; small groups of programmers (2 to 12); where an extended development team can be involved and all can work together; responsible and motivated developers; and customer who understand. The question is that can large enterprises use XP agile concepts? The answer to this question is that: although XP is not suitable for a project with a large staff. Nothing prevents large organizations from trying XP on small sub web applications. According to literature researches that talked about adopting XP by small teams to develop small projects (XP works best for small and independent projects). Therefore, we suggested that XP principles could be adopted by each one of sub teams to develop large web application, only if we divide the large web application into many sub systems. 116

135 To keep the project on schedule and within the budget, the large enterprise should accomplish the following: maintain close communication through weekly meetings; keep close watch on development progress; address meeting overload by introducing agendas to give structure to the meetings; and adapt XP principles by sub teams. At the same time, we addressed that, the managers of XP sub teams had to deal with a number of difficulties such as: suffering added stress for conventional managers in the agile environment; maintaining productive and motivated teams; unmotivated and unproductive team members; and dealing with the daily standup meeting was complicated by the size of the team Quantitative Project Management The Hybrid model supports quantitative project management by conducting the following: 1. The management team determines the project objectives. 2. The management team controls the WebEng, XP and Throwaway Prototype processes which are adopted by sub teams by receiving progress reports from sub teams leaders. 3. The management team monitors the work and performance of all sub teams according to early defined measures. 4. Each sub team s leader reviews the status of sub application with management team through frequent releases User Interface Design in the Hybrid Model A multimedia system can include a combination of text, still images, graphics, video and sound. The strength of multimedia lies in the integration of different media thus increasing the understanding of information. However, the success of multimedia depends on how the combinations of media are used and good design. We addressed in a research paper [203] the guidelines for designing multimedia user interfaces. Most of these guidelines are based on independent researches. Many of these guidelines are: 1. User interaction with the interface (keep user interface simple and consistent, and let the user control interaction and give immediate feedback for every user action) 2. Use familiar Metaphors in the design of user interface. 3. Safely exploring the Web site. 4. User interface colors and fonts (use of appropriate layout, grid and animation). 5. Using of sound in user interface design. 6. Touch (use large touch areas; use consistent colors and shapes to designate touch areas; and use different touch styles where appropriate). 7. Aesthetics of layout (avoid rectangle, use a grid and so on). 117

136 We addressed the factors for web page designing such as: effectiveness, efficiency, satisfaction, content, structure, access and style. We addressed also the general principles of web site design such as: completeness, controllability, consistency, redundancy, orientation, feedback, flexibility and reversibility [204] User Interface Design Approach for Large Web Applications We proposed a new UI design approach named XP-PROTOTYPING that related to large web applications development in order to avoid the problems of UI design. The UI design of large web application depended on literature analysis and on survey results. The XP- PROTOTYPING includes the following steps: 1. The enterprise should build at the beginning of the development process a management team. The role of the management team is to coordinates the overall development process among the sub teams. 2. At the beginning of the development process, the management team conducts an initial customer communication in order to obtain main characteristics (size, objectives, functions and requirements) of the large web application. The objective of this activity is to classify the requirements into classes according to the size, complexity and objectives. 3. Divide the large web application into a set of sub web applications according to the requirement classes and the size of this web application. 4. Divide large number of developers into a set of sub teams and these teams may work in parallel or in incremental manner according to the dependability of these sub systems on each other. Assign one manager for each sub team and this manager should be a member of the management team. 5. Distribute sub web applications among these sub teams. 6. The UI designers of each sub team start to build the initial UI using Throwaway Prototype model according to user requirements. To minimize cost, we suggested the use of paper Throwaway Prototype. To build the Throwaway Prototype, the sub team needs to communicate more with the customers. After the initial Prototype is build, customer communication is undertaken to verify the Prototype using the customer feed back. This process is repeated until the UI designer gets all customer requirements especially those that are related to sub application s UI. We suggested that XP principles should be adopted during this phase and mixed with the Prototyping steps to get best customer satisfaction, low cost and early delivery of sub application. Figure (5.7) shows the main steps of web application s UI design. 7. We suggested that each UI designer should take care of web application environment; end user culture and characteristics; web application objectives and functions; and technology 118

137 used by web application s UI designers. The UI designers should also take in their consideration the activity analysis and planning of web application, dialogue management and context management when designing UI. No Throwaway paper Prototype + XP for initial UI design Accept Yes Customer Communication Building UIs of the SubWeb App. Using Prototyping + XP principles No Customer Verification Accept Yes Integrate UIs of Sub WebApp. with overall UIs of WebApp. Figure (5.7): Steps of UI design of Sub Web Application Configuration Management in Hybrid Model Software Configuration management (SCM) is a set of activities that have been developed to manage change throughout software life cycle. Whereas configuration management is a discipline applying technical and administrative direction to: identify and document the functional and physical characteristics of configuration item; control changes to those characteristics; report change processing and implementation status; and verify compliance with specified requirements [2]. We suggested that, the following SCM activities should be integrated with the Hybrid model activities: 1. Defining configuration items such as code, design, tests and requirements. 2. Manage the configuration items. 3. Adopt test cases and measurement data. 4. Identifying plans to establish and maintain control over configuration items. 5. Implementing configuration plans and providing information on the status and relationships of all configuration items. The adoption of XP principles by members of each sub team enforces the configuration management by: 1. Enforcing continuous integration and it is easy to read because of coding standards. 119

138 2. Establishing baselines regularly through functional tests. The baselines are created also at the end of each iteration. 3. Controlling changes through various XP principles such as pair programming, tests and customer involvement Testing, Verification and Validation in Hybrid Model Testing is used to find defects, determine the level of web application quality and prevent defects. Testing should provide sufficient information to stakeholders to make decisions about the release of the web application project being tested for the next development step. There are many test activities such as: planning and control; choosing test conditions; designing test cases and checking results; evaluating exit criteria; reporting on the testing process and system under test; finalizing after a test phase has been completed; and reviewing source code and analysis documents. The choice of which test techniques to use depends on a number of factors including: the type of system; standards; customer requirements; level of risk; type of risk, test objective; documentation available; knowledge of the testers; time and budget; development life cycle; use case models and previous experience of types of defects found. Some techniques are more applicable to certain situations and test levels; others are applicable to all test levels. We suggested that the large enterprise should use two or more of the following test types: unit tests; integration tests; code coverage tests; acceptance tests; database tests; performance tests and web metrics. Verification methods are peer reviews and testing, which both are performed constantly. Verification is carried out in Hybrid model using testing in WebEng and XP models adopted by each sub team in the Hybrid model. The XP employs a test-first approach and all tests have to be written before the code. On the other hand, the peer reviews, pair programming and refactoring are always part of XP. Validation is performed in Hybrid model by customer participation and frequent releases in XP and WebEng models adopted by each sub team. The main goal to be achieved by the validation is the customer acceptance. The customer constantly validates the work done by the sub team and validates the deliveries at the end of the each iteration. This may result in additional or changed requirements specified by the customer. Therefore, this will improve the chances that the product is suitable for use in its intended operating environment. 120

139 Project Monitoring and Control The project monitoring and control is another important task which adopted by the management team in the Hybrid model. The management team always: 1. Monitors the large web application project against plan. 2. Monitors the schedule and estimates. 3. Gathers information related to project s progress (the progress of each sub web application) by using measures and sub teams communications with the customers. 4. Collects and analysis the issues and guidelines that demand corrective actions. Corrective actions can be method adjustments. In addition new iterations offer opportunities to make adjustments. 5. Checks milestones against the schedule by functional tests. The short iterations of sub applications and the regular commitments to the plan make it easier to monitor the project against the baseline Organizational Process Performance In the Hybrid model, the management team enforces the performance of the organizational process as follows: 1. Establishes and control the WebEng, XP and Throwaway Prototype processes conducted by sub teams. 2. Establishes the performance and SQA measures. 3. Continuously monitors the performance of each sub team Technical Solutions in the Hybrid Model The technical solutions are adopted by the management team by integrating documents of all sub web applications. At the same time, the technical solutions are adopted by each one of the sub teams in the Hybrid model as follows: 1. Develops sub application according to WebEng process. 2. Adopt XP principles such as pair programming, coding standards and refactoring. 3. Explore alternative solutions using Throwaway Prototype. 4. Adopt user interface design of each sub application (XP_PROTOTYPING). 5. Develop a simple design in an iterative way. 6. Document the sub application. The code is used as a design document Integration in Hybrid Model The Hybrid model enforces the product integration, project management integration, teaming integration and supplier management integration. 121

140 Product Integration The product integration is adopted in Hybrid model as follows: 1. Each sub team adopts continuous integration of the sub web application components through iterations and customer communication. 2. Each sub team ensures compatibility of all sub web application components by running all tests at each integration step. 3. Continuous integration of all sub web applications by the management team. 4. Assemble large web application components and deliver the product Integrated Project Management The integrated project management is adopted by the Hybrid model as follows: 1. Use the project s defined process by adopting Spiral by management team, and adopting each of Throwaway Prototype and WebEng by each one of the sub team for every web application project. 2. Integrate the overall sub web applications by the management team. 3. XP integrates and coordinates developers, customer, testers and management. 4. XP contributes the project members integration and their close collaboration to establish a shared vision Integrated Teaming The Integrated Teaming is adopted by the Hybrid model as follows: 1. The management team establishes a self-organizing sub teams in which all relevant stakeholders are integrated. 2. The team operation is governed through a clear definition of the different roles, pair programming, code s collective ownership and focus on cooperation and communication Integrated Supplier Management The management team conduct Spiral model and has the responsibility to: 1. Evaluate the sources of products. 2. Communicates with the suppliers. 3. Monitor and manage the supplier processes and agreements. 4. Evaluate the products Organizational Environment for Integration The management team has the responsibility to establish an organizational policy, manages all the sub teams and adopt Spiral model to: 122

141 1. Plan the organization process. 2. Provide resources required to overall large web development process. 3. Provide tools required to overall development process of large web application. 4. Establish the objective, goals, mission and vision of the organization. 5. Determine all the environments elements that affect the organization work. 6. Determine the relationships with those environment elements Developers Training in the Large Web Development Enterprises The Hybrid model principles addressed earlier in table (5.1) are not simple and require developers in large web development enterprises with a complex set of activities that involve intellectual skills of planning, analysis, designing, evaluating and revising. The large web development enterprises must take in their considerations the different types of developers required to build successful large web applications. We suggested that: in order to use the proposed Hybrid model in a successfully matter, all of people involved in large web development enterprises (developers, project mangers and team leaders) must have a good web development knowledge and must be trained on: 1. CMMI key process areas and goals and SPI concepts. 2. Web engineering best practices. 3. How to adopt XP agile principles such as pair programming and customer communication during the overall development process. We suggested also that, the training process must be controlled by the managers of the sub teams under the supervision of centralized team. Therefore, the centralized team must: 1. Establish planning for training the developers. 2. Estimate the cost required for training and if it is suitable to enterprise budget. 3. Estimate the time required to train the overall developers in the organization. 4. Determine if there is a need for outsource professional persons in training process Organizational Training Good web engineering practice requires expertise in a complex set of activities that involve the intellectual skills of planning, designing, evaluating and revising. A web engineering process must take into consideration the different types of developers required to build a successful solution. All of the people involved in software development must have a good knowledge in web engineering development and must be trained. In the Hybrid model, 123

142 the management team has the responsibility to establish an organizational training capability as follows: 1. The training is carried out before the enterprise start adopting the Hybrid model in web development process to make the enterprise developers get more details about the Hybrid activities. 2. The use of XP by each sub team requires organizational training capabilities. At the same time, the pair programming can also be regarded as training during the whole project life cycle. Therefore, XP enhances the organization s training capabilities Integrating QA Activities with Hybrid Model An effective SQA program should consist of the following four components: training and planning; audits, inspections and reviews; standards and procedures; and metrics as discussed previously in section The centralized team members should establish a quality policy. The quality policy describes the organizational goals and objectives relating to SQA. The quality policy also defines how the organization is going to accomplish the SQA goals and objectives. We suggested that every large enterprise should establish an effective SQA department to perform the SQA activities by all teams during the overall web development process. This cannot be built without commitment and leadership from the centralized team. The following steps are required to build an effective SQA department: 1. Assign and train a Quality manager which is responsible for getting the initial guidelines, training and procedures for establishing the SQA department. 2. Educate all developers about the SQA current literature and benefits of SQA. 3. Adopt web process model that is consistent with web development environment. 4. Decide on a standard to use for SQA plan. 5. Develop SQA manual to address: project process management; reviews, inspections and audits; standards; configuration management; and metrics. 6. Define roles and responsibilities for all involved in SQA. 7. Tailor the plan to organization. 8. Test the SQA plan by adopting reviews, inspections, document everything, implement configuration management system and utilize web engineering metrics. 9. Repeat for the next project, using knowledge gained from previous projects to improve processes, product and your SQA program. 124

143 The Activities to the Different SQA processes The SQA manager is responsible for defining and documenting the project quality standards, metrics and methods within the quality management manual. Whereas, the project leader is responsible for setting up the project initially; performs basic estimations for the project with his management team; get literature data from similar projects using the metrics infrastructure; responsible for implementing the guidelines from the quality management manual within the project. Finally, the evaluators are performing the product SQA tasks depending on the specific requirements for specific work products as expressed in SQA manual. They are preparing evaluation specifications and evaluation procedures for each evaluated product. The project management has the responsibility of construct the project plan according to the product evaluations and SQA measures. According to these guidelines, the evaluators perform the product evaluations and document the results in evaluation reports. The SQA manager compiles Quality Status Reports out of the product evaluation reports in regular intervals. The project leader and project management are continuously assessing project progress and are responsible for making regular project progress decisions according to Quality Status Reports. In the Hybrid model, we suggested performing many or all of the following SQA activities to be executed during the large web application development: testing of web applications; code review; development process audit; configuration management audit; functional configuration audit; physical configuration audit; and version description document or equivalent. We suggested also that these SQA activities might be conducted by one or many of the following: project team; software assurance group; and other assurance group from outside the enterprise Internal Assessment and Light Formal Reviews An internal assessment is necessary to assure those project teams learn how to implement the Hybrid model. Light formal reviews could be done as follow: 1. The web project manager reviews the process progress. 2. The web project manger reviews the process with the teams leaders. 3. The team members review their work with each others. 4. The formal reviews should be done during each release. 125

144 External Assessment External assessment is necessary to assure the quality. This can be done by another quality assurance company. The benefits of external assessment are as follows: 1. Early warning-system for problems. 2. Measure of product quality. 3. Indicator of where to direct improvement efforts. 4. Monitor of changes in technology and web practices. 5.6 Software Development Process Models Used in Hybrid Model This section includes details about the software development process models such as Spiral, Throwaway Prototype, XP and WebEng which are included in the Hybrid model Spiral Model Adopted by Centralized Team We adopt the Spiral model as a management methodology in the Hybrid model to control the overall development process of the large web application. We suggested that the Spiral model to be conducted by centralized team. The Spiral model consists of major steps: feasibility study; requirement analysis; architectural software design; implementation (including detailed design, coding, unit testing, integration and acceptance). The distinctive feature of the Spiral model is that it makes explicit the idea of risk (identify the risks and assign priorities to risks). The Spiral model recognizes that there are uncertainties associated with software development and that they should be dealt with as carefully as possible. Examples of risks are: someone leaves the development team; project performs much too slowly; project occupies too much main memory; a new software development tool becomes available; misunderstood user requirement; user changing requirements; and changes of target hardware configuration. We described earlier the full steps of Spiral in section and showed these steps in figure (2.4) Advantages of the Spiral Model In the Hybrid model, we conduct the Spiral to be adopted by the centralized management team during the overall web development process because of its advantages as follows: 1. The Spiral is an incremental and evolutionary model. Therefore this approach is more suitable to be adopted for the development of large-scale web applications. 2. The Spiral has the ability for risk analysis at each development step. 3. The Spiral uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development. 126

145 4. The Spiral maintains a systematic stepwise approach, like the classic life cycle model (Waterfall), but incorporates it into an iterative framework that more reflect the real world. Whereas, in the Hybrid we adopt the general web engineering process model instead of Waterfall model as in traditional Spiral Throwaway Prototype In the Hybrid model, the Throwaway Prototype is conducted by centralized team in order to take the initial idea about the large web application through applying the Spiral concepts (initial requirements gathering). Then Throwaway Prototype is adopted by each one of the sub team in order to get more requirements related to their sub web application. The stages of Throwaway Prototyping are: outline specification; establishment of objectives; selection of functions; prototype construction; evaluation (check with the user); iteration (refinement); and completion (specification). These steps are previously described in details in section and shown in figure (2.3) The Limitations and Strengths of Prototype Model The limitations of Prototype model are: the user will see a partial system that is quickly developed and the user may not understand that it is not the finished system; incomplete requirements analysis; estimating, planning and managing a Prototype project can be difficult because it can be hard to predict how many iterations of Prototyping will take place; and the procedures for change and configuration management may be unsuitable for controlling the rapid change inherent in Prototyping. As a reaction to these problems, we suggested in the Hybrid model to conduct the Throwaway Prototype to be adopted by both the centralized management team and each one of the sub development teams during the overall web development process because of its advantages as follows: overcome the lack of clarity in requirements; easy to determine user requirements; increase customer satisfaction; facilitate end-user involvement; enhance userdeveloper communication; fast development of systems; reducing the development effort; reducing the maintenance effort; users can see a working system and not wait for final system; systems are easer for end-users to learn and use; gradually introduced the system into an organization; and it facilitates user training during development process. In Hybrid model, we suggested also to use Throwaway Paper Prototyping because it is less cost and implemented using paper and pencil that mimics actual system functions but does not look at all like it. 127

146 5.6.3 The Web Engineering Process Model In the Hybrid model, the Web Engineering process model is conducted by each one of the sub development teams. This model consists of: planning phase to identify key project members and expert users; requirements phase to gather all the system requirements; analysis phase to examine requirements and make a conceptual model of the system to be built, to build classes, sequence diagrams, state diagrams and activity diagrams; design phase to make the analysis model of the system realizable in software; implementation phase to implement the software system and manage all the technologies involved; testing phase to test all the executable artifacts of the system and perform unit test, integration test, system test and acceptance test; deployment phase to setup security and redundancy and deploy completed application; and finally, evaluation phase for configuration and change management. These steps are described in details in section The XP Adopted by Sub Teams in the Hybrid Model We suggested in the Hybrid model that, the XP principles are to be conducted by each one of the sub teams (because firstly XP is more suitable for small team and secondly the XP is more suitable for small sub system). We should focuses on pair programming and refactoring because these two features are the key features of XP. The programmers in each sub team should: test, code, refactor and make schedule estimated when adopting the XP principles. The programmers should: choose the tasks and work in pairs; write unit tests; add features to pass unit tests; fix features/tests as necessary, until all tests pass; integrate code; and produce a released version. Then the customer runs acceptance tests and version goes into production. After that the programmers update their estimates based on the amount of work they have done in release cycle. The customers should choose the features they want and rank them by importance; answer questions; write acceptance tests; run acceptance tests; steer the iteration; and accept the release. The sub team leader which works also as a centralized team member should maintain the relationship between the sub team and the centralized management team; form the sub team; obtain resources; manage the team; and manage problems. We had explained in details the XP rules, principles and values in section We described the life cycle of the XP process previously in figure (2.8) The Benefits of Using XP in Hybrid Model Web applications demand faster time to market and the continual integration of new requirements. Such demands have increased the popularity of agile processes which: let teams increase development productivity; maintaining software quality and flexibility; and increasing software organization s responsiveness while decreasing development overhead. 128

147 The XP s focus on small teams lets it replace paper based documentation with face-to-face communication. In XP, all developers work closely together so they can communicate informally rather than spending time documenting designs and decisions. The XP includes practices aimed at reducing management overhead. Pair programming is used by each one of sub teams. The XP addressed how two developers can work together on the same computer to complement each other. One developer implements the current method while the other is working on integration issues. This approach saves time and minimizes the number of errors and can obtain better solutions since two persons most likely have different perspectives of the same problem and therefore complement each other in solving it [194]. 5.7 Integrating Web Engineering Practices in Hybrid Model According to the literature researches and practical survey in large enterprises, it is clearly that the most key factor that affects the success of large web development process is the weakness in adopting web engineering practices by these enterprises. Therefore, we suggested to integrate the web engineering best practices (organizational issues; standards and procedures; web metrics; control of the development process; and tools and technology) with the Hybrid model activities and steps. The management team must conduct the organizational issues practices such as: 1. Assign manager for each sub web application. 2. Establish and use software quality assurance (SQA) functions. 3. Establish a training program for enterprise s developers especially for managers. 4. Check and maintain availability of web engineering technologies and resources. The management team must conduct the standards and procedures practices such as: 1. Assess project s benefits and risks prior to make the contract. 2. Ensure that subcontractors follow disciplined web process. 3. Conduct periodic reviews of each sub web application s status. 4. Monitor the progress at each stage in web development process. 5. Use methods to estimating project size, development effort, schedule, and cost. 6. Ensure that each sub team must apply common coding standards. 7. Ensure that each sub team must plan testing before programming beginning based on user requirements and each sub team must perform testing by users. 129

148 8. Ensure that each sub team must check if the system configuration (program and data) pass user acceptance test. The web metrics helps organizations to understand, manage and improve quality of web applications. The management must conduct web metrics practices such as: 1. Analyze the statistics to test development efficiency; 2. Analyze records of project timescales versus scheduling procedures; 3. Use statistics on sources of errors in web application code and analyze for their cause, detection and avoidance. 4. Monitor the progress of each sub web application. 5. Make estimation and compare with actual for computer performance. The management team must conduct the control of the development process practices such as: 1. Control the project resources and produce estimates and schedules. 2. Control subsequent changes in the enterprise. 3. Adopt procedure to control changes to code, requirements and design. 4. Adopt procedures to ensure that every function is tested. 5. Use a mechanism to ensure testing performance during and after implementation. The management team must conduct the tools and technology practices and check if these practices are used by each one of the sub teams as follows: 1. Use software tools to assist in tracing of web application design and code. 2. Use software tools for reporting the status of the web applications. 3. Use Prototyping methods for ensuring requirements elements of web applications. 4. Use a data dictionary to store details of all data files and system development. 5. Use software tools for project planning, estimating and scheduling. 5.8 Software Process Improvement in the Hybrid Model In the Hybrid model, the management team has the responsibility to control the overall development process and all sub teams according to software process improvement principles and CMMI key process areas and goals in order to improve organization s process. The management team adopt Spiral model and has the responsibility to: 1. Determine the organization s current culture and structure. 130

149 2. Keep the organization s structure simple. On the other hand, the organization s structure and culture may need to change according to its environment. 3. Bring in an expert to advise the management team. 4. Analysis all the organization s functions and procedures. 5. Collect all important data related to organization functions. 6. Analysis the errors and the causes of these errors to avoid happen again. 7. Identify the consumers and suppliers for each web project. 8. Introduce a Software Engineering Process Group (SEPG). 9. Hold everyone responsible for software process improvement. 10. Document all the activities related to process improvement. 11. Develop a user guide to describe Hybrid model processes and steps. 5.9 The Problems Solved By the Hybrid Model The literature and surveys in this research highlighted serious problems which affecting the large web applications development in large enterprises. We previously listed these problems of web development in tables (5.1), (5.2) and (5.3). The ability of the Hybrid model to solve these problems could be inherent in the points addressed in table (5.5) Table (5.5): Problems in the Literature Solved by the Hybrid model Web Applications Development Solutions by the Hybrid model Problems Focused on parts of web development process. Did not consider the size of web application. Did not consider the number of developers. Problems in requirement engineering and analysis phase. Problems in requirements changing during the web development process. Lack the stakeholders involvement. The Hybrid considers all the web development phases. The Hybrid considers the size of web application. The Hybrid considers the large number of developers. 1. Integrating with the Hybrid model many steps related to requirements classification, analysis, development, documentation and management. 2. Adopting Throwaway Prototype by each sub team to gather, analyze requirements for sub application. Enforce this operation using XP customer communication. Adopt agile XP customer communication and feed back during the development process. 1. The Hybrid involving the stakeholders and their roles in the development process. 2. The management team identify stakeholders and their interests, manage them, contact them and define 131

150 Poor project management of large web development process. Lack integration with agile methodologies principles. Lack risk analysis and management. Poor and insufficient project planning. This lead to waste time and resources. There are problems conflicting in project scheduling. Flawed design and development process stakeholder communication strategy. 1. Divide the large web application into many sub applications. 2. Divide large number of developers into many sub teams. 3. Construct a management team to adopt Spiral model to manage and control the development process. The Hybrid adopts the XP principles such as customer communication and feed back, pair programming and refactoring to be used by each sub team. 1. The Hybrid adopts Spiral to be conducted by management team to identify and analysis risks and their types, and to put strategies to eliminate or delete effects during the development process. 2. Further risk analysis to be conducted by each sub team for each sub application. 1. Control and arrange the development process activities by the management team. 2. The Hybrid model consists of a planning phase to define project characteristics, goals and objectives, and specifies in detail the user requirements. 3. the Hybrid model conducts developing the project plan to include estimates for each sub application, identify responsibilities for achieving quality and usability, relationships between sub applications and teams, and to monitor the progress of all sub applications Poor project estimation cost, time and effort. Poor understanding and lack of well-defined web development processes for the building of large web applications in large enterprises. Poor utilization of SPI in large enterprises in order to increase the productivity. 16 Problems in delivery dates. 1. The Hybrid model conducts the using of suitable cost, time and effort estimation model (COCOMO). 2. The Hybrid integrates many steps related to cost estimation to be used by both management team and each one of the sub teams. 1. The Hybrid web engineering process model was suggested to obtain as possible as successful large web applications development in large enterprises. 2. The Hybrid model undertakes all the phases in web development process and CMMI process areas. 3. The Hybrid model adopts training the managers and developers on all its components, especially on using Spiral, Throwaway Prototype, WebEng and XP principles. 4. The Hybrid model adopts training on SPI CMMI process areas and goals. 1. In Hybrid model, the management team considers the SPI and CMMI process areas with low cost, less resources and little efforts. 2. The management team monitors the development progress according to CMMI to improve the development process. This problem can be solved by more project planning; risk analysis; and accurate time, cost and effort estimation. 132

151 There is a shortage of skilled developers. Lack of standardization and refactoring components in programming the web applications. Basic knowledge of web applications development. Development practices (Organizational Issues, Standards and Procedures, Metrics, Control of the development process Hybrid model adopt continuous training for manager and developers on the CMMI process areas and other process models conducted by it. Adopting the XP principles such as refactoring and standardization to be used by each sub team. The management team controls the training of all developers in sub teams on WebEng process model and also on web engineering practices. 1. The Hybrid adopts the WebEng process model to be used by each sub team. 2. The management team conducts and executes the web engineering practices The Advantages and the Limitations of the Hybrid Model The strengths and advantages properties of the Hybrid model are showed previously, in table (5.4). Whereas the limitations of the Hybrid model are as follows: 1. The adoption of this Hybrid model by any large enterprise may need long time in order to understand this model by every one in this enterprise. On the other hand, the enterprise may need to reorganize its culture and structure according to the concepts of this Hybrid model. 2. The Hybrid model activities and principles must be understood by management team members and even all sub teams members. 3. The management team members and even each sub team s members need knowledge and training on CMMI key process areas and goals. 4. We suggested in the Hybrid model, that each sub team should adopt the using of XP agile principles, Throwaway Prototype and WebEng process. Therefore, each sub team member needs knowledge and training on XP principles such as pair programming. 133

152 Chapter 6 CMMI-Evaluation of the Proposed Hybrid Web Engineering Process Model 6.1 Introduction Good and easily understood software process models are an important element of SPI. The software process models must represent the way the work is actually performed and provide flexible and easily understandable steps. Also, an effective web development process model requires an understandable and clearly planning and suitable management approach. In chapter 5, we presented the full details of the proposed Hybrid model. This chapter includes the analysis and evaluation of this Hybrid model according to SPI CMMI levels. This chapter includes also the comparisons between Spiral, Agile XP, WebEng and Hybrid model according to their compatibilities with CMMI levels. Finally, this chapter includes the evaluation of the Hybrid model according to CMMI levels by the large Jordanian enterprises. 6.2 Hybrid Model Evaluation According to CMMI Levels This section includes the analysis of the Hybrid model compatibility with CMMI requirements and mapping CMMI levels and process areas versus Hybrid activities. The CMMI consists of specific and general practices. The CMMI contains 25 key process areas indicating the aspects of product development that are to be covered by company processes. This section includes details about which of the CMMI process areas are supported by Hybrid in terms of largely satisfied, satisfied and partially satisfies The Compatibility of Hybrid Activities with CMMI Level2 Table (6.1) identifies the principles and activities of the Hybrid model that can be used to perform the activities of all key process areas related to CMMI level2 as follows: 1. The CMMI requirements management process area is largely satisfied by Hybrid model. 2. The CMMI project planning process area is largely satisfied by the Hybrid model. 3. The CMMI project monitoring and control process area is largely satisfied by Hybrid. 4. The CMMI supplier agreement management process area is satisfied by the Hybrid model. Additional activities must be added to Hybrid to completely satisfy CMMI level2 goals. 5. The CMMI measurement and analysis process area is also satisfied by the Hybrid. Additional activities must be added to Hybrid to completely satisfy the CMMI level2 goals. 134

153 6. The CMMI process and product QA process area is largely satisfied by the Hybrid model. 7. The CMMI Configuration Management process area is largely satisfied by Hybrid model. SG1 SG1 Table (6.1): Hybrid Activities Against the Activities of CMMI Level2 Process Areas, Specific Goals and Practices Mapping level Hybrid practices ---- CMMI ML2 : Managed ---- Requirements Management SP 1.1 Obtain an understanding of requirements Sp 1.2 Obtain Commitment to requirements SP 1.3 Manage requirement changes SP 1.4 Maintain bidirectional traceability of requirements SP 1.5 Identify inconsistencies between project work and requirements Project Planning SP 1.1 Estimate the scope of the project SP 1.2 Establish estimates of work product and task attributes SP 1.3 Define project lifecycle SP 1.4 Determine estimates of effort and cost Largely satisfies Largely satisfies Largely satisfies Largely satisfies 1. Divide large application into sub applications. 2. Classify requirements into classes. 3. Divide large numbers of developers into sub teams. 4. Availability of product owner. 5. Availability of customers. 6. User stories (Agile XP). 7. Negotiated contract. 8. Analysis of sub web application. 9. Tracing requirements by each sub team using Throwaway Prototype. 10. Planning meeting of sub application 11. Analysis of environment factors. 1. Weekly planning by centralized team. 2. Cost, effort and time estimation of the large web application project. 3. Availability of product owner. 4. Planning meeting of sub application. 5. Throwaway Prototype model. 6. Estimating sub application cost, effort, and time by sub team. SG2 SP 2.1 Establish the budget and schedule SP 2.2 Identify project risks SP 2.3 Plan for data management SP 2.4 Plan for project resources SP 2.5 Plan for needed knowledge and skills SP 2.6 Plan stakeholder involvement SP 2.7 Establish the project plan Largely satisfies 1. Risk analysis for large application by centralized team (Spiral). 2. Stakeholder classification and involvement. 3. Daily sub team meeting. 4. Sub team plan for resources and skills. 5. Determine the budget and schedule by the centralized team. 6. Availability of product owner. SG3 SP 3.1 review plans that that affect the project SP 3.2 Reconcile work and resource levels SP 3.3 Obtain Plan commitment Largely satisfies 1. Daily sub team meeting for review. 2. Weekly planning by centralized team. 3. Estimating sub application effort. 4. Availability of product owner. SG1 SG2 Project Monitoring and Control SP 1.1 Monitor project planning parameters SP 1.2 Monitor commitments SP 1.3 Monitor project risks SP 1.4 Monitor data management SP 1.5 Monitor stakeholder involvement SP 1.6 Conduct progress reviews SP 1.7 Conduct milestone reviews SP 2.1 Analyze Issues SP 2.2 Take corrective actions SP 2.3 Manage corrective actions Largely satisfies Largely satisfies The centralized team monitors the project plans, risks, commitments, data and stakeholders involvement. 2. Centralized team meeting for analyzes issues and control work progress. 3. Availability of product owner. 4. Daily Sub team meeting for review. 5. Customer availability. 6. Daily stand-up meetings by sub teams.

154 Supplier Agreement management SP 1.1 Determine acquisition type SP 1.2 Select Suppliers SG1 SP 1.3 Establish supplier agreements SP 2.1 Review COTS products SP 2.2 Execute the supplier agreement SG2 SP 2.3 Accept the acquired product SP 2.4 Transition products Measurement and analysis SP 1.1 Establish measurement objectives SP 1.2 Specify measures SG1 SP 1.3 Specify data collection and storage procedures SP 1.4 Specify analysis procedures SP 2.1 Collect measurement data SP 2.2 Analyse measurement data SG2 SP 2.3 Store data and results SP 2.4 Communicate results SG1 SG2 SG1 SG2 SG3 Process and Product Quality Assurance SP 1.1 Objectively evaluate processes SP 1.2 Objectively evaluate work products and services SP 2.1 Communicate and ensure resolution of noncompliance issues SP 2.2 Establish records Configuration Management SP 1.1 Identify configuration items SP 1.2 Establish a configuration management system SP 1.3 Create or release baselines SP 2.1 Track change requests SP 2.2 Control configuration items SP 3.1 Establish configuration Management records. SP 3.2 Perform configuration audits Satisfy Additional activities must be added to Hybrid to completely satisfy goals of this CMMI PA Satisfy Additional activities must be added to Hybrid to completely satisfy goals of this CMMI PA Largely Satisfy Largely Satisfy Largely Satisfy Largely Satisfy 1. The Spiral model adopted by management team is partially satisfies practices within this CMMI process area such as: select suppliers, establish and execute suppliers agreements. 1. Some of Hybrid practices can be used to support effort measurement. 2. Centralized team review meeting. 3. Daily sub team stand-up meetings (Agile XP). 4. The measures specification and analysis are covered by the WebEng process adopted by each sub team. 1. Assign and train a quality manager. 2. Educate all developers about the SQA benefits. 3. Develop SQA manual. 4. Define SQA roles for all developers. 5. Tailor the enterprise plan. 6. Test the SQA plan by reviews. 1. More sub application planning. 2. User stories (Agile XP). 3. Sub team review meeting. 4. Incremental deployment (Spiral). 5. Sub web application code and tests. 6. Continuous integration code. 7. Define configuration items. 8. Identify plans to establish control. 9. Implementing configuration The Compatibility of Hybrid Activities with CMMI Level3 Table (6.2) identifies the principles and activities of the Hybrid model that can be used to perform the activities of all key process areas related to CMMI level3 as follows: 1. The CMMI Requirements Development process area is largely satisfied by Hybrid. 2. The CMMI Technical Solution process area is largely satisfied by the Hybrid model. 3. The CMMI Product Integration process area is largely satisfied by the Hybrid model. 4. The CMMI Verification process area is largely satisfied by the Hybrid model. 5. The CMMI Validation process area is largely satisfied by the Hybrid model. 136

155 6. The CMMI Organizational Process Focus process area is satisfied by the Hybrid model. Additional activities must be presented to completely satisfy CMMI level3 goals. 7. The CMMI Organizational Process Definition process area is satisfied by the Hybrid model. Additional activities must be presented to completely satisfy CMMI level3 goals. 8. The CMMI Organizational Training process area is largely satisfied by Hybrid model. 9. The CMMI Integrated Project Management process area is largely satisfied by Hybrid. 10. The CMMI Risk Management process area is largely satisfied by the Hybrid model. 11. The CMMI Integrated Teaming process area is largely satisfied by the Hybrid model. 12. The CMMI Integrated Supplier Management process area is satisfied by Hybrid model. Additional activities must be presented to completely satisfy goals of this CMMI level The CMMI Decision Analysis and resolution process area is satisfied by the Hybrid model. Additional activities must be presented to completely satisfy CMMI level3 goals. 14. The CMMI Organizational Environment for Integration process area is satisfied by Hybrid. Additional activities must be presented to completely satisfy CMMI level3. Table (6.2): Hybrid Activities Against the Activities of CMMI Level3 Mapping Process Areas, Specific Goals and Practices Hybrid Practices level CMMI ML3 : Defined Requirements Development Largely Satisfies SP 1.1 Elicit needs SG1 SP 1.2 Develop the customer requirements SG2 SG3 SP 2.1 Establish product and product-component requirements SP 2.2 Allocate product-component requirements SP 2.3 Identify interface requirements SP 3.1 Establish operational concepts and Scenarios SP 3.2 Establish a definition of required functionality SP 3.3 Analyze requirements SP 3.4 Analyze requirements to achieve balance SP 3.5 Validate requirements with comprehensive methods Largely Satisfies 1. Elicit requirements of each sub web application by sub teams. 2. Product owner availability. 3. Customer availability to take users stories (XP). 4. Analyze requirements of each sub application by Throwaway Prototype. 5. Undertake all types of web application requirements such as user req., interface design req., functional and non functional requirements. SG1 SG2 SG3 Technical Solution SP 1.1 Develop detailed alternative solutions and selection criteria SP 1.2 Evolve operational concepts and scenarios SP 1.3 Select product-component solutions SP 2.1 Design the product or product component SP 2.2 Establish a technical data package SP 2.3 Design interfaces using criteria SP 2.4 Perform make, buy, or reuse analyses SP 3.1 Implement the design SP 3.2 Develop product support documentation Largely Satisfies Largely Satisfies 1. Each sub team develops sub application according to WebEng process. 2. User interface design of each sub application by each sub team. 3. Pair programming (Agile XP). 4. Possible documentation of each sub application. 5. Integrate documents of all sub applications. 137

156 SG1 SG2 SG3 Product Integration SP 1.1 Determine Integration Sequence SP 1.2 Establish the product integration environment SP 1.3 Establish product integration procedures and criteria SP 2.1 Review interface descriptions for completeness. SP 2.2 Manage Interfaces. SP 3.1 Confirm readiness of product components for integration SP 3.2 Assemble product components SP 3.3 Evaluate assembled product components SP 3.4 Package and deliver the product or product component Verification SP 1.1 Select work products for verification SG1 SP 1.2 Establish the verification environment SP 1.3 Establish verification procedures &criteria SP 2.1 Prepare for peer reviews SG2 SP 2.2 Conduct peer reviews SP 2.3 Analyze peer review data SP 3.1 Perform verification SG3 SP 3.2 Analyze verification results and identify corrective action SG1 SG2 Validation SP 1.1 Select products for validation SP 1.2 Establish the validation environment SP1.3 Establish validation procedures &criteria SP 2.1 Perform Validation SP 2.2 Analyze validation results Largely Satisfies Largely Satisfies Largely Satisfy Largely Satisfy Largely Satisfy Largely Satisfy 1. The centralized team manages the user interface design, and coding of all sub applications. 2. Frequent integration of sub applications by centralized team. 3. Integration of user interface design for all sub applications by centralized team. 4. Automated tests, configuration management and frequent integration. 1. Verification activity in WebEng process model by each sub team. 2. Automated tests and configuration management. 3. User write acceptance tests (AgileXP). 4. Centralized team executes frequent Integration (Spiral). 1. Validation activity in WebEng process model by each sub team. 2. Automated tests and configuration management. 3. User write acceptance tests (Agile XP) 4. Centralized team executes frequent integration (Spiral). SG1 SG2 SG1 SG1 Organizational Process Focus SP 1.1 Establish organizational process needs SP 1.2 Appraise the organization s processes SP 1.3 Identify the organization s process improvements SP 2.1 Establish process action plans SP 2.2 Implement process action plans SP 2.3 Deploy organizational process assets SP 2.4 Incorporate process-related experiences into the organizational process assets Organizational Process Definition SP 1.1 Establish standard processes SP 1.2 Establish life-cycle model descriptions SP 1.3 Establish tailoring criteria and guidelines SP 1.4 Establish the organization s measurement repository SP 1.5 Establish the organization s process asset library Organizational Training SP 1.1 Establish the strategic training needs SP 1.2 Determine which training needs are the responsibility of the organization 138 Satisfy Additional activities must be presented to completely satisfy goals of this CMMI PA Satisfy Additional activities must be presented to completely satisfy goals of this CMMI PA Largely Satisfy Largely Satisfy 1. Spiral model as a management process. 2. WebEng model as a development process. 3. Throwaway Prototype for requirements gathering. 4. Establish web engineering practices. 1. Spiral model as a management process. 2. WebEng model as a development process. 3. Throwaway Prototype for requirements gathering and analysis. 4.Establish web engineering practices. 1. Train the developers and managers on: CMMI, SPI practices, and web engineering practices.

157 SG2 SP 1.3 Establish an organizational training tactical plan SP 1.4 Establish training capability SP 2.1 deliver training SP 2.2 Establish training records SP 2.3 Assess training effectiveness 2. Train the developers on how to adopt Agile principles. 3. Establish plan for train the developers. 4. Estimate training cost. 5. Estimate training time. 6. Determine if there is a need for outsourcing professional persons in training process. Integrated Project Management SP 1.1 Establish the project s defined process SP 1.2 Use organizational process assets for planning project activities SG1 SP 1.3 Integrate Plans SP 1.4 Manage the project using integrated plans SP 1.5 Contribute to organizational process assets SP 2.1 Manage stakeholder involvement SG 2 SP 2.2 Manage dependencies SP 2.3 Resolve coordination issues SP 3.1 Define Project s Shared-Vision Context SG3 SP 3.2 Establish the Project s Shared Vision SP 4.1 Determine Integrated Team Structure for the Project SG4 SP 4.2 Develop a Preliminary Distribution of Requirements to Integrated Teams SP 4.3 Establish Integrated Teams SG1 SG2 SG3 Risk Management SP 1.1 Determine risk sources and categories SP 1.2 Define risk parameters SP 1.3 Establish a risk management strategy SP 2.1 Identify risks SP 2.2 Evaluate, categorize, and prioritize risks SP 3.1 Develop risk mitigation plans SP 3.2 Implement risk mitigation plans Largely Satisfy Largely Satisfy Largely satisfies Largely satisfies 1. Centralized team controls and establish process according to plans. 2. Centralized team manages stakeholders involvement and relationships between sub teams. 3. Centralized team manages dependency between the sub applications. 4. Daily sub team meeting. 5. Customer availability 6. Sub application planning and review meetings. 7. centralized team integrates all sub web applications into the large system 1. Centralized team classifies, identify, prioritize, and evaluate risks (Spiral). 2. Centralized team meeting to avoid risks. 3. Risk analysis conducted by each sub team. 4. Sub team planning and review. 5. Daily sub team meeting. SG1 SG2 Integrated Teaming SP 1.1 Identify Team Tasks SP 1.2 Identify Needed Knowledge and Skills SP 1.3Assign Appropriate Team Members SP 2.1 Establish a Shared Vision SP 2.2 Establish a Team Charter SP 2.3 Define Roles and Responsibilities SP 2.4 Establish Operating Procedures SP 2.5 Collaborate among Interfacing Teams Largely satisfies Largely satisfies 1. The management team divides the large number of developers into sub teams, and assigns a team leader for each sub team. 2. The management team decides the required skills and professionals. 3. The management team distributes the sub web applications among the sub teams. 4. The management team determines the responsibilities of each sub team. 5. Each sub team leader determines the roles, procedures and responsibility of each member in the team. 6. Adopt agile XP pair programming in each sub team 7. The management team has the responsibility to integrate all the sub teams work. 139

158 SG1 SG2 Integrated Supplier Management SP1.1 Analyze potential sources of products SP1.2 Evaluate and determine sources of products SP 2.1 Monitor selected supplier processes SP 2.2 Evaluate selected supplier work products SP 2.3 Revise the supplier agreement or relationship Satisfy Additional activities must be presented to completely satisfy goals of this CMMI PA The management team conduct Spiral model and has the responsibility to: 1. Evaluate the sources of products. 2. Communicates with the suppliers. 3. Monitor and manage the supplier processes and agreements. 4. Evaluate the products. SG1 SG1 SG2 Decision Analysis and resolution SP 1.1 Establish guidelines for decision analysis SP 1.2 Establish evaluation criteria SP 1.3 Identify alternative solutions SP 1.4 Select evaluation methods SP 1.5 Evaluate alternatives SP 1.6 Select solutions Organizational Environment for Integration SP1.1 Establish the Organization s shared vision SP1.2 Establish an integrated work environment SP1.3 Identify IPPD-unique skill requirements SP2.1 Establish leadership mechanisms SP2.2 Establish incentives for integration SP2.3 Establish mechanisms to balance team and home organization responsibilities Satisfy Additional activities must be presented to completely satisfy goals of this CMMI PA Satisfy Additional activities must be presented to completely satisfy goals of this CMMI PA 1. Centralized team identifies and analyzes, and evaluates solutions for web application problems. 2.Develop SQA manual to address metrics. The management team adopt Spiral model and has the responsibility to: 1. Establish the objective, goals, mission and vision of the organization. 2. Determine all the environments elements that affect the organization work. 3. Determine the relationships with those environment elements. 4. Provide resources and tools required to overall development process of large web application The Compatibility of Hybrid Activities with CMMI Level4 Table (6.3) identifies the activities and principles of the Hybrid model that can be used to perform the activities of all CMMI level4 process areas. The CMMI (OPP) process area is satisfied by the Hybrid model. Additional activities must be presented to completely satisfy CMMI level4 goals. Whereas the CMMI (QPM) process area is satisfied by the Hybrid model. Additional activities must be presented to completely satisfy CMMI level4 goals The Compatibility of Hybrid Activities with CMMI Level5 Table (6.4) identifies the activities and principles of the Hybrid model that can be used to perform the activities of CMMI level5 process areas. The (OID) process area is partially satisfied by Hybrid. Additional activities must be presented to completely satisfy level4 goals. Whereas the (CAR) process area is partially satisfied by Hybrid model. Additional activities must be presented to completely satisfy level4 goals. 140

159 Table (6.3): Hybrid Activities Against the Activities of CMMI Level4 Mapping Process Areas, Specific Goals and Practices Hybrid Practices Level CMMI ML4: Quantitatively Managed Organizational Process Performance (OPP) Satisfies SP 1.1 Select processes SP 1.2 Establish process performance measures SG1 SP 1.3 Establish quality and process-performance objectives SP 1.4 Establish process performance baselines SP 1.5 Establish process performance models Additional activities must be presented to completely satisfy goals of this CMMI PA 1. The management team establishes and control the WebEng, XP, and Throwaway Prototype processes conducted by sub teams. 2. The management team establishes the performance and SQA measures. 3. The management team continuously monitors the performance of each sub team. SG1 SG2 Quantitative Project Management (QPM) SP 1.1 Establish the project s objectives SP 1.2 Compose the defined process SP 1.3 Select the sub processes that will be statistically managed SP 1.4 Manage project performance SP 2.1 Select Measures and analytic techniques SP 2.2 Apply statistical methods to understand variation. SP 2.3 Monitor performance of the selected sub processes SP 2.4 Record statistical management data Satisfies Additional activities must be presented to completely satisfy goals of this CMMI PA 1. The management team determines the project objectives. 2. The management team control the WebEng, XP, and Throwaway Prototype processes conducted by sub teams by receiving the progress reports from the sub teams leaders. 3. The management team monitors the work and performance of all sub teams according to early defined measures. 4. Each sub team leader review sub application status with management team through frequent releases enable reviews by the management. Table (6.4): Hybrid Activities Against the Activities of CMMI Level5 Process Areas, Specific Goals and Practices Mapping level Hybrid Practices CMMI ML5: Optimizing Organizational Innovation and Deployment Partially (OID) satisfies SP 1.1 Collect and analyze Improvement proposals SP 1.2 Identify and analyze Innovations SG1 SG2 SG1 SG2 SP 1.3 Pilot improvements SP 1.4 Select improvements for deployment SP 2.1 Plan the Deployment SP 2.2 Manage the Deployment SP 2.3 Measure Improvement Effects Causal Analysis and Resolution (CAR) SP 1.1 Select defect data for analysis SP 1.2 Analyze causes SP 2.1 Implement the action proposals SP 2.2 Evaluate the effect of changes SP 2.3 Record data Additional activities must be presented to completely satisfy goals of this CMMI PA 141 Partially satisfies Additional activities must be presented to completely satisfy goals of this CMMI PA 1. Management team control the overall development process by conducting the SPI practices and web engineering practices to improve the organization process. 2. Management team document all the activities related to process improvement. The management team adopt Spiral model and has the responsibility to: 1. Analysis all the organization s functions and procedures. 2. Collect all important data related to organization functions. 3. Analysis the errors and the causes of these errors to avoid happen again.

160 6.3 The Coverage of XP, Spiral, WebEng and Hybrid with CMMI Fritzsche and Keil [186] suggested an approach to determine which of the CMMI process areas are supported by XP agile method and where adjustments need to be made. They analyzed every process area and all of its specific goals in detail. They addressed that, CMMI states that they can be replaced by alternative practices and agile methods employ different approaches than those suggested by CMMI. Therefore they concentrated on analysis of the goals using the practices only as guidelines and looked for possible alternative ways of implementing the goals. They applied a rating system for the coverage of specific goals, process areas and generic practices as follows: conflicting ( ); not addressed (0); partially supported (+); supported (++); and largely supported (+++). In largely supported, the agile method s practices if employed correctly satisfy the major part of the respective model component. The supported and partially supported describe a restricted coverage and not addressed reflects that there is no coverage at all. These ratings do not imply that the respective CMMI goals cannot be attained. They pointed out that additional practices have to be introduced to fully satisfy the CMMI requirements. The conflicting indicates that the CMMI goal cannot be reached with the agile method being used. To differentiate between not addressed and conflicting, they always check whether the agile method could be extended to reach the CMMI goal without interfering with the method s basic practices or contradicting to the principles stated in the agile manifesto. In this section we adopt the same approach on Spiral, WebEng and Hybrid models and show the interrelations and conflicts between these models and the CMMI process areas and goals The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level2 Table (6.5) shows the coverage of Spiral, WebEng and Hybrid models with the CMMI level2 process areas. Table (6.5) shows that: 1. The manage requirements, project planning, and project monitoring and control are largely supported (+++) by each of XP, Spiral and WebEng. As a result it is largely supported (+++) by Hybrid model. 2. The supplier agreement management is not addressed (0) by Agile XP, and partially supported (+) by WebEng, whereas it is supported (++) by Spiral. As a result, it is supported (++) by Hybrid because the Hybrid model adopt Spiral by management team. 3. The measurement and analysis, and align measurement and analysis activities are partially supported (+) by Agile XP, whereas they are supported (++) by each of Spiral, and WebEng. As a result, it is supported by Hybrid model. While provide measurement results is 142

161 supported (++) by each of agile XP, Spiral and WebEng. As a result it is supported (++) by Hybrid Model. 4. The process and product quality assurance are partially supported (+) by both agile XP and Spiral, whereas they are supported (++) by WebEng model. As a result they are largely supported (+++) by Hybrid, because each sub team adopt WebEng model to develop sub web application. And also we integrated many SQA steps with Hybrid model. 5. The configuration management are largely supported (+++) by agile XP, whereas they are supported (++) by both Spiral and WebEng. As a result they are largely supported (+++) by Hybrid. Table (6.5): Coverage of CMMI-Level2 Areas by XP, Spiral, WebEng and Hybrid Process Areas and Their Specific Goals Agile XP Spiral WebEng Hybrid 1 Requirements management Manage requirements (+++) (+++) (+++) (+++) 2 Project planning (+++) (+++) (+++) (+++) Establish estimates (+++) (+++) (+++) (+++) Develop a project plan (+++) (+++) (+++) (+++) Obtain commitment to the plan (+++) (+++) (+++) (+++) 3 Project monitoring and control (+++) (+++) (+++) (+++) Monitor project against plan (+++) (+++) (+++) (+++) Manage corrective action to closure (+++) (+++) (+++) (+++) 4 Supplier agreement management (0) (++) (+) (++) 5 Measurement and analysis (+) (++) (++) (++) Align measurement and analysis activities (+) (++) (++) (++) Provide measurement results (++) (++) (++) (++) 6 Process and product quality assurance (+) (+) (++) (+++) Objectively evaluate processes and work products (+) (+) (++) (+++) Provide objective insight (+) (+) (++) (+++) 7 Configuration management (+++) (++) (++) (+++) Establish baselines (+++) (++) (++) (+++) Track and control changes (+++) (++) (++) (+++) Establish integrity (+++) (++) (++) (+++) The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level3 Table (6.6) shows the coverage of Spiral, WebEng and Hybrid models with the CMMI level 3 process areas. Table (6.6) shows that that: 1. The requirements development are supported (++) by both agilexp and Spiral, whereas they are largely supported (+++) by WebEng model. As a result they are largely supported (+++) by Hybrid. 2. Technical solution are largely supported (+++) by both agile XP and WebEng, whereas they are supported (++) by Spiral. As a result they are largely supported (+++) by Hybrid. 3. Product integration are largely supported (+++) by each of XP, Spiral, and WebEng. As a result it is largely supported (+++) by Hybrid. 143

162 Table (6.6): Coverage of CMMI-Level3 Areas by XP, Spiral, WebEng and Hybrid Process Areas and Their Specific Goals Agile XP Spiral WebEng Hybrid 2. CMMI Level 3 1 Requirements development (++) (++) (+++) (+++) Develop customer requirements (++) (++) (+++) (+++) Develop product requirements (++) (++) (+++) (+++) Analyze and validate requirements (++) (++) (+++) (+++) 2 Technical solution (+++) (++) (+++) (+++) Select product-component solutions (+++) (++) (+++) (+++) Develop the design (+++) (++) (+++) (+++) Implement the product design (+++) (++) (+++) (+++) 3 Product integration (+++) (+++) (+++) (+++) Prepare for product integration (+++) (+++) (+++) (+++) Ensure interface compatibility (+++) (+++) (+++) (+++) Assemble product components and deliver the product (+++) (+++) (+++) (+++) 4 Verification (+++) (+++) (+++) (+++) Prepare for verification (+++) (+++) (+++) (+++) Perform peer reviews (+++) (+++) (+++) (+++) Verify selected work products (+++) (+++) (+++) (+++) 5 Validation (+++) (+++) (+++) (+++) Prepare for validation (+++) (+++) (+++) (+++) Validate product or product components (+++) (+++) (+++) (+++) 6 Organizational process focus ( ) (+) (++) (++) 7 Organizational process definition (0) (+) (++) (++) 8 Organizational training (++) (+) (+) (+++) Establish an organizational training capability (++) (+) (+) (+++) Provide necessary training (++) (+) (+) (+++) 9 Integrated project management (++) (++) (+++) (+++) Use the project s defined process (0) (++) (+++) (+++) Coordinate and collaborate with relevant stakeholders (+++) (++) (++) (+++) Use the project s shared vision for IPPD (+++) (++) (++) (+++) Organize integrated teams for IPPD (0) (++) (+) (+++) 10 Risk management (+++) (+++) (++) (+++) Prepare for risk management (+) (+++) (++) (+++) Identify and analyze risks (+++) (+++) (++) (+++) Mitigate Risks (+++) (+++) (++) (+++) 11 Integrated teaming (+++) (+) (+) (+++) Establish team composition (+++) (+) (+) (+++) Govern team operation (+++) (+) (+) (+++) 12 Integrated supplier management (0) (++) (+) (++) 13 Decision analysis and resolution ( ) (++) (++) (++) 14 Organizational environment for integration (+) (++) (+) (++) Provide IPPD infrastructure (++) (++) (+) (++) Manage people for integration (+) (++) (+) (++) 4. Verification and Validation are largely supported (+++) by each of XP, Spiral and WebEng. As a result it is largely supported (+++) by Hybrid model. 5. Organizational process focus is conflicting ( ) with agilexp, partially supported (+) by Spiral, and supported (++) by WebEng. As a result it is supported (++) by Hybrid. 6. Organizational process definition is not addressed (0) by agilexp, partially supported (+) by Spiral, and supported (++) by WebEng. As a result it is supported (++) by Hybrid. 7. Organizational training are supported (++) by agile XP, and partially supported (+) by both Spiral and WebEng model. As a result they are largely supported (+++) by Hybrid because we add many steps related to developers and organization training to the Hybrid. 144

163 8. Integrated project management supported (++) by both agile XP and Spiral, whereas largely supported (+++) by WebEng. As a result it is largely supported (+++) by Hybrid. 9. Use the project s defined process is not addressed (0) by agile XP, supported (++) by Spiral, and largely supported (+++) by WebEng. As a result it is largely supported (+++) by Hybrid. 10. Both of Coordinate and collaborate with relevant stakeholders, and Use the project s shared vision for IPPD are largely supported (+++) by agilexp, supported (++) by both Spiral and WebEng. As a result they are largely supported (+++) by Hybrid. 11. Organize integrated teams for IPPD is not addressed (0) by agile XP, supported (++) by Spiral, and partially supported (+) by WebEng. As a result they are largely supported (+++) by Hybrid. 12. Risk management (Identify and analyze risks, and Mitigate Risks) are largely supported (+++) by agile XP and Spiral, whereas supported (++) by WebEng model. Therefore, they are largely supported (+++) by Hybrid model. While Prepare for risk management is partially supported (+) by agile XP, largely supported (+++) by Spiral, supported (++) by WebEng model. Therefore it is largely supported (+++) by Hybrid model. 13. Integrated teaming are largely supported (+++) by agile XP, partially supported (+) by both Spiral and WebEng. As a result they are largely supported (+++). 14. Integrated supplier management is not addressed (0) by agile XP, supported (++) by Spiral, and partially supported (+) by WebEng. As a result it is supported (++) by Hybrid. 15. Decision analysis and resolution is conflicting ( ) with agile XP, supported (++) by both Spiral and WebEng. As a result it is supported (++) by Hybrid; 16. Each of Organizational environment for integration and Manage people for integration are partially supported (+) by agile XP and WebEng, and supported (++) by Spiral. Therefore they are supported (++) by Hybrid. While Provide IPPD infrastructure is supported (++) by both agile XP, and Spiral, whereas partially supported (+) by WebEng. As a result it is supported (++) by Hybrid The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level4 Table (6.7) shows the coverage of Spiral, WebEng and Hybrid models with the CMMI level 4 process areas. This table shows that the organizational process performance is conflicting ( ) with agile XP, supported (++) by Spiral, and partially supported (+) by WebEng. As a result it is supported (++) by Hybrid model. While the Quantitative project management is conflicting ( ) with agile XP, supported (++) by Spiral, and partially supported (+) by WebEng. As a result it is supported (++) by Hybrid. 145

164 Table (6.7): Coverage of CMMI-Level4 Process Areas by XP, Spiral, WebEng and Hybrid Process Areas and Their Specific Goals Agile XP Spiral WebEng Hybrid 3. CMMI Level 4 Organizational process performance ( ) (++) (+) (++) Quantitative project management ( ) (++) (+) (++) The Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Level5 Table (6.8) shows the coverage of Spiral, WebEng, and Hybrid models with the CMMI level 5 process areas. This table shows that the Organizational innovation and deployment is conflicting ( ) by the agile XP, partially supported (+) by Spiral, and not addressed (0) by WebEng. Therefore, it is partially supported (+) by Hybrid. Whereas, Causal analysis and resolution is not addressed (0) by agile XP, partially supported (+) by Spiral, and not addressed (0) by WebEng. Therefore, it is partially supported (+) by Hybrid. Table (6.8): Coverage of CMMI-Level5 Process Areas by XP, Spiral, WebEng and Hybrid Process Areas and Their Specific Goals Agile XP Spiral WebEng Hybrid 4. CMMI Level 5 Organizational innovation and deployment ( ) (+) (0) (+) Causal analysis and resolution (0) (+) (0) (+) Coverage of XP, Spiral, WebEng and Hybrid with CMMI-Generic Practices Table (6.9) shows the coverage of Spiral, WebEng and Hybrid models with the CMMI Generic practices. Table (6.9) shows that: 1. Establish an organizational policy is not addressed (0) by agile XP, whereas supported (++) by Spiral, and not addressed (0) by WebEng. Thus, it is supported (++) by Hybrid. 2. Plan the process is not addressed (0) by agile XP, whereas largely supported (+++) by each of Spiral and WebEng. Therefore, it is largely supported (+++) by Hybrid. 3. Provide resources is partially supported (+) by agile XP, whereas supported (++) by Spiral, and partially supported (+) by WebEng. Therefore, it is supported (++) by Hybrid. 4. Assign responsibility is largely supported (+++) by agile XP, whereas, supported (++) by each of Spiral and WebEng. Therefore, it is largely supported (+++) by Hybrid. 5. Train people is largely supported (+++) by agile XP, whereas, partially supported (+) by each of Spiral and WebEng. Therefore, it is largely supported (+++) by Hybrid. 6. Manage configurations is supported (++) by each of agile XP, Spiral and WebEng. Therefore, it is supported (++) also by the Hybrid model. 146

165 7. Identify and involve relevant stakeholders is largely supported (+++) by agile XP, whereas, it is partially supported (+) by each of spiral and WebEng. Therefore, it is largely supported (+++) by the Hybrid. 8. Monitor and control the process is supported (++) by each of agile XP and WebEng, whereas it is largely supported (+++) by Spiral. Thus, it is largely supported (+++) by Hybrid. 9. Objectively evaluate adherence is partially supported (+) by each of agile XP, Spiral and WebEng. Therefore, it is partially supported (+) by the Hybrid model. 10. Review status with higher level management is supported (++) by each of agile XP and Spiral, whereas, it is partially supported (+) by WebEng. Thus, it is it is largely supported (+++) by Hybrid model. 11. Establish a defined process is not addressed (0) by agile XP, whereas it is partially supported (+) by Spiral, and largely supported (+++) by WebEng. Therefore, it is largely supported (+++) by Hybrid model. 12. Collect improvement information is conflicting ( ) with agile XP, whereas, it is not addressed (0) by both Spiral and WebEng. Therefore, it is supported (++) by Hybrid. Table (6.9): Coverage of CMMI Generic Practices by XP, Spiral, WebEng and Hybrid Generic Practices Agile Spiral XP WebEng Hybrid 1 Establish an organizational policy (0) (++) (0) (++) 2 Plan the process (0) (+++) (+++) (+++) 3 Provide resources (+) (++) (+) (++) 4 Assign responsibility (+++) (++) (++) (+++) 5 Train people (+++) (+) (+) (+++) 6 Manage configurations (++) (++) (++) (++) 7 Identify and involve relevant stakeholders (+++) (+) (+) (+++) 8 Monitor and control the process (++) (+++) (++) (+++) 9 Objectively evaluate adherence (+) (+) (+) (+) 10 Review status with higher level management (++) (++) (+) (+++) 11 Establish a defined process (0) (+) (+++) (+++) 12 Collect improvement information ( ) (0) (0) (++) Summary of the Hybrid Analysis versus CMMI Process Areas There are five of the seven process areas of CMMI level2: Requirements management, Project planning, Project monitoring and control, Process and product quality assurance and Configuration management are largely supported (+++) by Hybrid model. Whereas, Supplier agreement management and Measurement and analysis are supported (++) by Hybrid model. Therefore, the Hybrid activities are compatible with CMMI level2 process areas. At the same time CMMI level2 can be attained without major adaptations. 147

166 There are five of the fourteen process areas of CMMI level3: Organizational process focus, Organizational process definition, Integrated supplier management, Decision analysis and resolution, and Organizational environment for integration are supported (++) by Hybrid model. And all of the remaining process areas of CMMI level3 are largely supported (+++) by Hybrid model. Therefore, the Hybrid activities are compatible with CMMI level3 process areas. At the same time CMMI level3 can be attained without major adaptations. Both of the two process areas of CMMI level4: Organizational process performance and Quantitative project management are supported (++) by Hybrid model. Therefore, the Hybrid activities are compatible with CMMI level4 process areas. At the same time CMMI level4 can be attained without major adaptations. Both of the two process areas of CMMI level5: Organizational innovation and deployment and Causal analysis and resolution are partially supported (+) by Hybrid model. Therefore, the Hybrid activities are partially compatible with CMMI level5 process areas. At the same time CMMI level5 can be attained with major adaptations and new activities required to be added to Hybrid. Finally, seven of CMMI generic practices: Plan the process, Assign responsibility, Train people, Identify and involve relevant stakeholders, Monitor and control the process, Review status with higher level management, and Establish a defined process are largely supported (+++) by Hybrid. Whereas, four of CMMI generic practices: Establish an organizational policy, Provide resources, Manage configurations, and Collect improvement information are supported (++) by Hybrid. Only one of CMMI generic practices: Objectively evaluate adherence are partially supported (+) by Hybrid. Therefore, the Hybrid activities are compatible with CMMI general practices. At the same time CMMI general practices can be attained without major adaptations. 6.4 Hybrid Model Evaluation by Large Jordanian Enterprises A formal evaluation of the use of Hybrid Web Engineering process model by large scale Jordanian enterprises has been undertaken. A third questionnaire is prepared to include all the CMMI levels process areas and goals. The questionnaire format contains four parts: The first part lists CMMI level2 process areas and goals; the second part lists CMMI level3 process areas and goals; the third part lists CMMI level4 process areas and goals; and finally, the forth part lists CMMI level5 process areas and goals. A copy of the third questionnaire is included in Appendix C. This questionnaire is given to 50 professional developers in software 148

167 engineering and management working in large Jordanian enterprises (research population). We received only 30 replies. The Hybrid model should be clearly read and understood by the professional developers in large Jordanian enterprises to evaluate it according to CMMI levels process areas and goals. Therefore a hard copy and sometimes a soft copy which includes the detailed description of the proposed Hybrid model were attached with this questionnaire. This section includes details about the developers responses CMMI level2 Process Areas and Goals This section includes the descriptive statistics (frequencies, percentages, mean and standard deviation) of the responses evaluations related to CMMI level2 steps. Table (6.10) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the requirements management process area related to level2. Figure (6.1) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 89.32%, whereas the answer No get average of ratios equal to 4.86, and Don t know responses get average of ratios equal to 6. Table (6.10): The Results of CMMI level2 Requirements Management Process Areas, Goals and Practices Yes No Don t Know Requirements Management Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Obtain an understanding of req.s SP 1.2 Obtain Commitment to req.s SG1 SP 1.3 Manage requirement changes SP 1.4 Maintain bidirectional traceability of requirements SP 1.5 Identify inconsistencies between project work and req.s Averages Requirements Management freq SP 1.1 Obt ain an understanding of req.s Sp 1.2 Obtain Commitment to req.s SP 1.3 Manage requirement changes SP 1.4 Maintain bidirectional traceability of req.s SP 1.5 Identify inconsistencies between project work and req.s Yes No Don t Know Questions Figure (6.1): The Results of CMMI level2 Requirements Management Table (6.11) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the project planning process area related to level2. Figure (6.2) shows frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 85.95%, whereas the answer No get average of ratios equal to 6.421% and Don t know responses get average of ratios equal to 7.62%. 149

168 Table (6.11): The Results of CMMI level2 Project Planning Process Areas, Goals and Practices Yes No Don t Know Project Planning Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Estimate the scope of the project SP 1.2 Establish estimates of work product and task attributes SG1 SP 1.3 Define project lifecycle SP 1.4 Determine estimates of effort and cost SP 2.1 Establish the budget and schedule SP 2.2 Identify project risks SP 2.3 Plan for data management SG2 SP 2.4 Plan for project resources SP 2.5 Plan for needed knowledge and skills SP 2.6 Plan stakeholder involvement SP 2.7 Establish the project plan SP 3.1 review plans that that affect the project SG3 SP 3.2 Reconcile work and resource levels SP 3.3 Obtain Plan commitment Averages Project Planning freq Yes No SP1.1 Estimate the SP1.3 Define SP2.1 Establish the SP2.3 Plan for data SP2.5 Plan for needed SP2.7 Establish the SP3.2 Reconcile Don t Know Questions Figure (6.2): The Results of CMMI level2 Project Planning Table (6.12) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Project Monitoring and Control process area related to level2. Table (6.12): The Results of CMMI level2 Project Monitoring and Control Process Areas, Goals and Practices Yes No Don t Know Project Monitoring and Control Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Monitor project planning parameters SP 1.2 Monitor commitments SP 1.3 Monitor project risks SP 1.4 Monitor data management SP 1.5 Monitor stakeholder involvement SP 1.6 Conduct progress reviews SP 1.7 Conduct milestone reviews SG1 SG2 SP 2.1 Analyze Issues SP 2.2 Take corrective actions SP 2.3 Manage corrective actions Averages

169 Figure (6.3) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 89%, whereas the answer No get average of ratios equal to 2%, and Don t know responses get average of ratios equal to 8.99%. Project Monitoring and Control freq yes no don t know SP 1.1 Monitor project SP 1.3 Monitor project risks SP 1.5 Monitor stakeholder SP 1.7 Conduct milestone SP 2.2 Take corrective actions Questions Figure (6.3): The Results of CMMI level2 Project Monitoring and Control Table (6.13) shows the frequencies, mean, st-deviation and averages of developers responses to the Supplier Agreement management process area related to level2. Figure (6.4) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 84.28%, whereas the answer No get average of ratios equal to 2.82%, and Don t know responses get average of ratios equal to 12.85%. Table (6.13): The Results of CMMI level2 Supplier Agreement Management Process Areas, Goals and Practices Yes No Don t Know Supplier Agreement Management Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers SP 1.3 Establish Supplier Agreements SP 2.1 Review COTS Products SP 2.2 Execute the Supplier Agreement SP 2.3 Accept the Acquired Product SP 2.4 Transition Products Averages SG1 SG2 freq SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers Supplier Agreement management SP 1.3 Establish Supplier Agreements SP 2.1 Review COTS Products SP 2.2 Execute the Supplier Agreement SP 2.3 Accept the Acquired Product SP 2.4 Transition Products yes no don t know Questions Figure (6.4): The Results of CMMI level2 Supplier Agreement Management Table (6.14) shows the frequencies, mean, st-deviation and averages of developers responses to the Measurement and analysis process area related to level2. Figure (6.5) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios %, whereas the answer No get average of ratios equal to 5.425%, and Don t know responses get average of ratios equal to 13.35%. 151

170 Table (6.14): The Results of CMMI level2 Measurement and Analysis Process Areas, Goals and Practices Yes No Don t Know Measurement and Analysis Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish measurement Objectives SP 1.2 Specify measures SP 1.3 Specify data collection and Storage procedures SP 1.4 Specify analysis procedures SG1 SG2 SP 2.1 Collect measurement data SP 2.2 Analyze measurement data SP 2.3 Store data and results SP 2.4 Communicate results Averages Measurement and analysis SP1.1 Establish measurement Objectives SP1.3 Specify data collection and Storage SP2.1 Collect measurement data SP2.3 Store data and results freq yes no don t know Questions Figure (6.5): The Results of CMMI level2 Measurement and Analysis Table (6.15) shows the frequencies, percentages, mean, st-deviation, and averages of developers responses to the Process and Product Quality Assurance process area related to level2. Figure (6.6) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 85.85%, whereas the answer No get average of ratios equal to 4.975%, and Don t know responses get average of ratios equal to 9.175%. Table (6.15): The Results of CMMI level2 Process and Product Quality Assurance Process Areas, Goals and Practices Yes No Don t Know Process and Product Quality Assurance Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products and Services SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues SP 2.2 Establish Records Averages SG 1 SG 2 Process and Product Quality Assurance freq SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products and Services SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues SP 2.2 Establish Records yes no don t know Questions Figure (6.6): The Results of CMMI level2 Process and Product Quality Assurance 152

171 Table (6.16) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Configuration Management process area related to level2. Figure (6.7) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 83.32%, whereas the answer No get average of ratios equal to 5.71%, and Don t know responses get average of ratios equal to 10.97%. Table (6.16): The Results of CMMI level2 Configuration Management Process Areas, Goals and Practices Yes No Don t Know Configuration Management Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Identify configuration items SP 1.2 Establish a configuration management system SP 1.3 Create or release baselines SG1 SG2 SG3 SP 2.1 Track change requests SP 2.2 Control configuration items SP 3.1 Establish configuration Management records SP 3.2 Perform configuration audits Averages Configuration Management freq yes no don t know 0 SP 1.1 Identify SP 1.2 Establish a SP 1.3 Create or SP 2.1 Track SP 2.2 Control SP 3.1 Establish SP 3.2 Perform configuration configuration release baselines change requests configuration configuration configuration items management items Management audits system records Questions Figure (6.7): The Results of CMMI level2 Configuration Management CMMI level3 Process Areas and Goals This section includes the descriptive statistics (frequencies, percentages, mean and standard deviation) of the responses evaluations related to CMMI level3 steps. Table (6.17) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Requirements Development process area related to level3. Figure (6.8) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 89.34%, whereas the answer No get average of ratios equal to 1.65%, and Don t know responses get average of ratios equal to 9%. Requirements Development freq yes no don t know SP 1.1 Elicit Needs SP 2.1 Establish Product and Product- SP 2.3 Identify Interface Requirements SP 3.2 Establish a Definition of Required SP 3.4 Analyze Requirements to Achieve Questions Figure (6.8): The Results of CMMI level3 Requirements Development 153

172 Table (6.17): The Results of CMMI level3 Requirements Development Process Areas, Goals and Practices Yes No Don t Know Requirements Development Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Elicit Needs SP 1.2 Develop the Customer Requirements SP 2.1 Establish Product and Product- Component Requirements SP 2.2 Allocate Product-Component Requirements SP 2.3 Identify Interface Requirements SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements with Comprehensive Methods Averages SG1 SG2 SG3 Table (6.18) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Technical solution process area related to level3. Figure (6.9) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 82.23%, whereas the answer No get average of ratios equal to 4.42%, and Don t know responses get average of ratios equal to 13.33%. Table (6.18): The results of CMMI level3 Technical Solution Process Areas, Goals and Practices Yes No Don t Know Technical Solution Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria SG1 SP 1.2 Evolve Operational Concepts and Scenarios SP 1.3 Select Product-Component Solutions SP 2.1 Design the Product or Product Component SG2 SP 2.2 Establish a Technical Data Package SP 2.3 Design Interfaces Using Criteria SP 2.4 Perform Make, Buy, or Reuse Analyses SP 3.1 Implement the Design SG3 SP 3.2 Develop Product Support Documentation Averages Table (6.19) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Product Integration process area related to level3. Figure (6.10) shows the frequencies of each of Yes, No and Don t know answers. The answer yes 154

173 got the highest average of ratios 90.37%, whereas the answer No get average of ratios equal to 4.07%, and Don t know responses get average of ratios equal to 5.54%. Technical solution freq yes no don t know SP 1.1 Develop Detailed Alternative SP 1.3 Select Product- Component SP 2.2 Establish a Technical Data Package SP 2.4 Perform Make, Buy, or Reuse Analyses SP 3.2 Develop Product Support Documentation Questions Figure (6.9): The Results of CMMI level3 Technical Solution Table (6.19): The Results of CMMI level3 Product Integration Process Areas, Goals and Practices Yes No Don t Know Product Integration Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Determine Integration Sequence SP 1.2 Establish the Product Integration SG1 Environment SP 1.3 Establish Product Integration Procedures and Criteria SP 2.1 Review Interface Descriptions SG2 for Completeness SP 2.2 Manage Interfaces SP 3.1 Confirm Readiness of Product Components for Integration SP 3.2 Assemble Product Components SG3 SP 3.3 Evaluate Assembled Product Components SP 3.4 Package and Deliver the Product or Product Component Averages Product Integration freq yes no don t know SP 1.1 Determine Integration Sequence SP 1.2 Establish the Product Integration Environment SP 1.3 SP 2.1 Review SP 2.2 Manage SP 3.1 Confirm Establish Interface Interfaces Readiness of Product Descriptions Product Integration for Components Procedures and Completeness for Integration Criteria SP 3.2 Assemble Product Components SP 3.3 Evaluate Assembled Product Components SP 3.4 Package and Deliver the Product or Product Component Questions Figure (6.10): The Results of CMMI level3 Product Integration Table (6.20) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Verification process area related to level3. Figure (6.11) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 91.26%, whereas the answer No get average of ratios equal to 3.72%, and Don t know responses get average of ratios equal to 5.01%. 155

174 Table (6.20): The Results of CMMI level3 Verification Process Areas, Goals and Practices Yes No Don t Know Verification Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Select Work Products for Verification SG1 SP 1.2 Establish the Verification Environment SP 1.3 Establish Verification Procedures and Criteria SP 2.1 Prepare for Peer Reviews SG2 SP 2.2 Conduct Peer Reviews SP 2.3 Analyze Peer Review Data SP 3.1 Perform Verification SG3 SP 3.2 Analyze Verification Results and Identify Corrective Action Averages Verification freq yes no don t know SP 1.1 Select Work Products for Verification SP 1.3 Establish Verification Procedures SP 2.2 Conduct Peer Reviews SP 3.1 Perform Verification Questions Figure (6.11): The Results of CMMI level3 Verification Table (6.21) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Validation process area related to level3. Figure (6.12) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 92.68%, whereas the answer No get average of ratios equal to 2.66%, and Don t know responses get average of ratios equal to 4.66%. Table (6.21): The results of CMMI level3 Validation Process Areas, Goals and Practices Yes No Don t Know Validation Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Select Products for Validation SP 1.2 Establish the Validation SG1 Environment SP 1.3 Establish Validation Procedures and Criteria SP 2.1 Perform Validation SG2 SP 2.2 Analyze Validation Results Averages Validation freq SP 1.1 Select Products for Validation SP 1.2 Establish the Validation Environment SP 1.3 Establish Validation Procedures and Criteria SP 2.1 Perform Validation SP 2.2 Analyze Validation Results yes no don t know Questions Figure (6.12): The Results of CMMI level3 Validation 156

175 Table (6.22) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Organizational Process Focus process area related to level3. Figure (6.13) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 77.62%, whereas the answer No get average of ratios equal to 3.78%, and Don t know responses get average of ratios equal to 18.58%. Table (6.22): The Results of CMMI level3 Organizational Process Focus Process Areas, Goals and Practices Yes No Don t Know Organizational Process Focus Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish Organizational Process Needs SG1 SP 1.2 Appraise the Organization s Processes SP 1.3 Identify the Organization s Process Improvements SP 2.1 Establish Process Action Plans SP 2.2 Implement Process Action Plans SP 2.3 Deploy Organizational Process SG2 Assets SP 2.4 Incorporate process-related experiences into organizational process assets Averages Organizational Process Focus SP 1.1 Establis h Or ganizati onal Pr ocess N eed s SP 1.3 Iden tif y the Or ganizati on s Process SP 2.2 Implem en freq Process Ac tion Pla ns.4 Incorp ora te process-related ences t yes no don t know SP 2 experi Questions Figure (6.13): The Results of CMMI level3 Organizational Process Focus Table (6.23) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Organizational Process Definition process area related to level3. Table (6.23): The Results of CMMI level3 Organizational Process Definition Process Areas, Goals and Practices Yes No Don t Know Organizational Process Definition Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish Standard Processes SP 1.2 Establish Life-Cycle Model Descriptions SG1 SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization s Measurement Repository SP 1.5 Establish the Organization s Process Asset Library A verages

176 Figure (6.14) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest av erage of ratios 80.68%, whe reas the answ er No get average of ratios equal to 7.32%, and Do n t know respon ses get averag e of ratios equ al to 12%. freq SP 1.1 Establish St andard Processes SP 1.2 Establish Life-Cycle Model Descriptions Organizational Process Definition SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization s Measurement Repository SP 1.5 Establish the Organization s Process Asset Library yes no don t know Questions Figure (6.14): The Results of CMMI level3 Organizational Process Definition Table (6.24) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Organizational Training process area related to level3. Figure (6.15) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 88.55%, whereas the answer No get average of ratios equal to 5.22%, and Don t know responses get average of ratios equal to 6.18%. Table (6.24): The Results of CMMI level3 Organizational Training Process Areas, Goals and Practices Yes No Don t Know Organizational Training Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish the Strategic Training Needs SP 1.2 Determine which training needs SG1 are the responsibility of organization SP 1.3 Establish an Organizational Training Tactical Plan SP 1.4 Establish Training Capability SP 2.1 Deliver Training SG2 SP 2.2 Establish Training Records SP 2.3 Assess Training Effectiveness Averages Organizational Training eq fr SP 1. the stablish E ic Strateg eeds ining N Tra 2 SP 1. ine Determ aining h tr whic are the ds nee 1.3 SP Es tab lish an Organi zational Training SP 1.4 Esta blish Trai ning Capability SP 2.1 D eliver ng Traini SP 2.2 Establish Training Records SP 2.3 Assess Training Effectiveness yes no don t know Questions Figure (6.15): The Results of CMMI level3 Organizational Training 158

177 Table (6.25) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Integrated Project Management process area related to level3. Figure (6.16) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 92.5%, whereas the answer No get average of ratios equal to 2.06%, and Don t know responses get average of ratios equal to 5.41%. Table (6.25): The Results of CMMI level3 Integrated Project Management Process Areas, Goals and Practices Yes No Don t Know Integrated Project Management Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish the project s defined process SP 1.2 Use Organizational Process Assets for Planning Project Activities SP 1.3 Integrate Plans SP 1.4 Manage the Project Using the Integrated Plans SP1.5 contribute to the organizational process assets SP 2.1 Manage Stakeholder Involvement SP 2. 2 Manage Dependencies SP 2. 3 Reso lve Coordination Issues Averages SG1 SG2 q fre SP 1.1 stablish the E Project s Defined SP 1.3 Integrated Project Management grate Plans Inte SP 1.5 Contribute to Questions Figure (6.16): The Results of CMMI l evel3 Integrated Project Management the O rg anizational e S P 2. 2 Mana g Depe ndenci es yes no don t know Table (6.26) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Risk Management process area related to level3. Table (6.26): The Results of CMMI level3 Risk Management Process Areas, Goals and Practices Yes No Don t Know Risk Management Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Determine Risk Sources and Categories SP 1.2 Define Risk Parameters SG1 SP 1.3 Establish a Risk Management Strategy SG2 SG3 SP 2.1 Identify Risks SP 2.2 Evaluate, Categorize, and Prioritize Risks SP 3.1 Develop Risk Mitigation Plans SP 3.2 Implement Risk Mitigation Plans Averages

178 Figure (6.17) shows the frequencies of e ach of Y es, No and D on t kn ow answers. The answer yes got the highest average of ratios 88.57%, whereas the answer No get average of ratios equal to 4.75%, and Don t know responses get average of ratios equal to 6.67%. Risk Manage ment q fre SP 1.1 SP 1.2 Define Determine Risk Risk Sources Parameters and Categories SP 1.3 Establish a Risk Management St rat egy SP 2. 1 Identify Risks SP 2.2 Evaluate, SP 3.1 Develop Risk Categorize, Mitigation and Prioritize Plans Risks SP 3.2 Implement Risk Mitigation Plans yes no don t know Questions Figure (6.17): The Results of CMMI level3 Risk Management Table (6.27) shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the Decision Analysis and resolution process area related to level2. Figure (6.18) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 87.4%, whereas the answer No get average of ratios equal to 3.4%, and Don t know responses get average of ratios equal to 9.2%. Table (6.27): The Results of CMMI level3 Decision Analysis and Resolution Proc ess Areas, Goals and Practices Yes No Don t Know Decision Analysis and Resolution Freq. % Freq. % Freq. % Mean Stdev SP 1.1 Establish Guidelines for Decision Analysis SP 1.2 Establish Evaluation Criteria SG1 SP 1.3 Identify Alternative Solutions SP 1.4 Select Evaluation Methods SP 1.5 Evaluate Alternatives SP 1.6 Select Solutions Averages freq SP 1.1 Establish Guidelines for Decision Analysis SP 1.2 Establish Evaluation Criteria Decision Analysis and resolution SP 1. 3 Identify Alternative Solut ions Questions SP 1.4 Select Evaluation Methods SP 1. 5 Evaluate Alternatives SP 1.6 Select Solutions Figure (6.18): The Results of CMMI level3 Decisi on Analysis a nd Resolution yes no don t know CMMI level4 Process Areas and Goals This section includes the descriptive statistics (frequencies, percentages, mean and standard deviation) of the responses evaluations related to CMMI level4 steps. Table (6.28) 160

179 shows the frequencies, percentages, mean, st-deviation and averages of developers responses to the level4 process areas. Figure (6.19) shows the frequencies of each of Yes, No and Don t know answers. The answer yes got the highest average of ratios 73.35%, whereas the answer No get average of ratios equal to 6.7%, and Don t know responses get average of ratios equal to 20%. Table (6.28): The Results of CMMI level4 (2 Process Areas) Maturity Level 4 process areas Yes No Don t Know Freq. % Freq. % Freq. % Mean Stdev Organizational Process Performance (OPP) Quantitative Project Management (QPM) Averages freq Organizational Process Performance (OPP) CMMI level4 (2 Process Areas) Questions Quantitative Project Management (QPM) Figure (6.19): The Results of CMMI level4 (2 Process Areas) yes no don t know CMMI level5 Process Areas and Goals This section includes the descriptive statistics (frequencies, percentages, mean and standard deviation) of the responses evaluations related to CMM I level5 steps. Table ( 6.29) shows the frequencies, percentages, mean, st-deviation a nd averages of developers responses to the leve l5 process areas. Figure (6.20) shows the frequencies of e ach of Y es, No and Don t know answers. The answer Don t know got the highest average of ratios 36.65%, whereas each of Yes and No responses get average of ratios equal to 31.65%. Table (6.29): The Results of CMMI level5 (2 Process Areas) Maturity Level 5 process areas Yes No Don t Know Freq. % Freq. % Freq. % Mean Stdev Organizational Innovation and Deployment (OID) Causal Analysis and Resolution (CAR) Averages freq Organizational Innovation and Deployment (OID) CMMI level5 (2 Process Areas) Questions Causal Analysis and Resolution (CAR) yes no don t know Figure (6.20): The Results of CMMI level5 (2 Process Areas) 161

180 3.6.5 The Summary of Hybrid Model Evaluation This section includes the summary of the ove rall above results o f the Hybrid model evaluation by Jordanian enterprises accord ing to CMMI process areas and goals. Table (6.30) shows this summary. The results shows tha t the Hybrid model satisfied about 85.57% of CMMI level2, 86.86% of CMMI level3, 73.35% of CMMI level4, and finally about only 31.65% of CMMI level5. Figure (6.21) shows these percentages. Table (6.30): The Summary of Hybrid model Evaluation by CMMI Yes No Don t Know A CMMI level2 Process Areas and Goals 1 Requirements Management 89.32% 4.68% 6% 2 Project Planning 85.95% 6.42% 7.62% 3 Project Monitoring and Control 89% 2% 8.99% 4 Supplier Agreement management 84.28% 2.82% 12.85% 5 Measurement and analysis % 5.425% 13.35% 6 Process and Product Quality Assurance 85.85% 4.975% 9.175% 7 Configuration Management 83.32% 5.71% 10.97% Average 85.57% 4.58% 9.85% B CMMI level3 Process Areas and Goals 1 Requirements Development 89.34% 1.65% 9% 2 Technical solution 82.23% 4.42% 13.33% 3 Product Integration 90.37% 4.07% 5.54% 4 Verification 91.26% 3.72% 5.01% 5 Validation 92.68% 2.66% 4.66% 6 Organizational Process Focus 77.62% 3.78% 18.58% 7 Organizational Process Definition 80.68% 7.32% 12% 8 Organizational Training 88.55% 5. 22% 6.18% 9 Integrated Project Management 92.5% 2.06% 5.41% 10 Risk Management 88.57% 4.75% 6.67% 11 Decision Analysis and resolution 87.4% 3.4% 9.2% Average 86.86% 4.17% 8.96% C CMMI level4 Process Areas and Goals 1 Organizational Process Performance (OPP) 80.0% 6.7% 13.3% 2 Quantitative Project Management (QPM) 66.7% 6.7% 26.7% Average 73.35% 6.7% 20% D CMMI level5 Process Areas and Goals 1 Organizational Innovation and Deployment (OID) 43.3% 33.3% 23.3% 2 Causal Analysis and Resolution (CAR) 20.0% 30.0% 50.0% Average 31.65% 31.65% 36.65% Hybrid model Evaluation by CMMI levels on Percentage of Adopti Level2 Level3 Level4 Level5 Series1 CMMI levels Figure (6.21): The Hybrid Evaluation by Large Enterprises According to C MMI 162

181 Chapter7 Discussion and Conclusions 7.1 Introduction We described earlier, the traditional process models, agile methodologies, their strengths and limitations and SPI CMMI. We listed literature related to large web applications development and development problems. We noted that there is a lack of researches which undertaken the overall web development process. Most of studies showed that large web projects development in large enterprises often runs over time and budget and deliverables are of poor quality. And also there is a lack in empirical studies and surveys in large web development enterprises. We did a survey in large Jordanian enterprises which undertaking large web development. The importance of this survey is to get the developers characteristics, web engineering practices used, software methodologies used and finally the symptoms which faced these enterprises. According to literature related to web development, and according to survey results, the large web development enterprises are suffering from many problems and are ignoring SPI practices. Therefore, this research focused on finding a proper solution for these enterprises to overcome as possible as their development problems. There is a need for web development model for large web applications. The success of the web application is judged on its ability to meet users expectations and delivered within time and budget. The SPIs are required to increase productivity of large enterprises and increase web application s quality. In chapter5, we suggested a Hybrid model as a solution to these large enterprises. In chapter6, we evaluated this model according to its compatibility with CMMI levels process areas. Thus, this chapter includes discussion of survey results, conclusion and summary of Hybrid evaluation, contributions, recommendations and proposals for future research and limitations of this study. 7.2 Discussion of the Survey Findings The analysis of the survey conducted in large web development Jordanian enterprises showed that all of these enterprises have 50 or more than 50 employees. About 50% have number of developers lied between 76 and 100 developers. The important statistical analysis of the survey results showed that: 1. The majority of respondents occupied the position of SEPG member and the highest percentage of them involved in design activities. 163

182 2. The majority of the participants were never involved in SPI activities. 3. About 53% of participants have basic knowledge of web applications development. 4. Very small percentages (23%) of these enterprises adopt reusability. 5. Many software development methodologies are mostly adopted by these enterprises such as: waterfall model (62%), OOP (51%) and structured programming (48%). 6. About only 11% of these enterprises adopt agile methods. 7. Only about 30% of these enterprises adopt web metrics. 8. About 65% of these enterprises perform testing of web applications as SQA activities. About 52% of these enterprises involve SQA group to perform SQA activities, whereas 37% of them depend on same project development team. According to the Mean results of severity score in table (4.17), these enterprises are suffering from many problems during the development process such as: problems in delivery dates; shortage of skilled developers; insufficient resources; poor project estimation cost, time and effort; insufficient project planning; conflicting in project scheduling; communication problems between team and stakeholders; poor project management of development process; and requirements changing during the development process. From descriptive statistics of the results related to the web engineering practices presented previously in section (4.4.4), it is clearly that there is a weakness in levels of adoption of web engineering best practices by these enterprises, especially in web metrics. Because the web metrics got the lowest ratio (24.62%), which implies that, the majority of respondents are not familiar with web metrics practice. This means that there are very few enterprises which adopt the web metric practice. The organizational issues have the second small ratio (31%) in enterprise adoption. This means that many of these enterprises adopt organizational issues practice. The control of development process practice also have small ratio This means that many of these enterprises adopt control of development process practice. The adoption ratio (37.07%) of standards and procedures practice is not too small. This implies that the majority of respondents are familiar with standards and procedures practice and the most of these enterprises adopt this practice. At the end, the large Jordanian enterprises show a high adoption ratio (62.85) for using web tools and technology, which implies that this practice is the most applied web engineering practice in these large enterprises in the web development process. The overall average adoption level of 38% implies that these enterprises have adoption of 38% of all the web engineering best practices. 164

183 7.3 Conclusions Developing web-based applications is significantly different from traditional software development and poses many additional challenges. There are major differences in the nature and life cycle of web applications and traditional software systems and the way in which they are developed and maintained. Therefore, the web engineering process model should: adopt suitable management methodology; minimize web development risks; consider requirements changing; monitor development progress; and deliver the web application quickly while providing feedback for management. The large enterprises which undertake the large web applications development suffering from many development problems such as: poor management method; deadlines problems; cost and effort estimation problems; and changing and meeting requirements. The main reasons of project failures are lack of customer involvement. There are many problems of traditional software process models: the several phases in the system development slow down the development process. The second problem with these methodologies is that the requirements specifications are not flexible since it is difficult to identify all customers requirements at the beginning. Even if the requirements can be identified, the business world is forever changing. Therefore, the traditional software process models have limitations to adopt them in the web applications development because the nature of these web applications in rapidly changing requirements. Many researchers recommend that these problems can be addressed by the adoption of lightweight iterative and incremental approaches such as XP. The most popular reference model for SPI is the SEI s CMMI. The CMMI is a process improvement approach that provides organizations with the essential elements of effective processes. The XP addresses Level2 s requirements management key process area through its use of stories, customer communication, refactoring and continuous integration. The contribution of XP to software development is expressed in the quality improvement of the entire software development process and software quality. On the other hand, XP has many limitations such as: 1. XP is used in small to medium size software projects. 2. There is no requirement gathering approach in XP. The XP expect that most of the requirements are known at the beginning of the first iteration for release planning meeting. 3. Lack requirements management and lack of documentation of requirements. 4. XP is not suitable to adopt it by the large teams. 165

184 Therefore, in order to overcome the limitations of both traditional software process models and agile XP when adopting them in large web applications development in large enterprises, we proposed a Hybrid web engineering process model. The adoption of this Hybrid model can: overcome as possible as the limitations of these models; support the suitable development of large web applications within the time, budget and effort; and finally, overcome as possible as the most important web development problems in literature and in large web development enterprises. We proposed this Hybrid model according to: 1. The problems obtained from the results of the SPSS analysis of second questionnaire that were distributed on large Jordanian enterprises which undertaken large web development. 2. The analysis of the literature studies related to large web applications development that addressed the steps and guidelines that result in successful web applications development. 3. The results of earlier researches that are related to the software process models, agile methodologies, their strengths and limitations and web engineering process model. We included the major characteristics of well known used software process models (Spiral and Throwaway Prototype), agile XP principles and WebEng process model in the proposed Hybrid web engineering process model. In Hybrid model, we suggested to: divide the large number of developers into many small sub teams; identify a management team to manage the overall development process and all sub teams; divide the large web application into many small sub web applications; and adopt the Spiral model to be used by the management team as solution of poor risk identification and analysis and poor management problem. At the same time, we suggested to adopt the XP principles to be used by each one of the sub team, as a solution for above mentioned problems. The agile methodologies promising priorities to satisfy customers through early and continuous product delivery as well as allowing changes to requirements late in the development cycle. We suggested in Hybrid model to adopt the Throwaway Prototyping to be used by each one of sub teams to overcome the XP requirement gathering, identifications and management limitations. The core of agile is to embrace change. To succeed, enterprises need to change their core business principles and the ways they are conducting business (change the organization culture). This means that agile methodologies could change how software businesses are conducting business. We believe that the agile principles will change the way the enterprises manage their software projects. Therefore, we suggested adopting sufficient training for all developers on agile XP principles. 166

185 We suggested also adopting the WebEng process model to be used by each one of the sub teams in order to match the nature of web applications development and web engineering best practices. At the same time, the management team monitors and controls the development process of sub web applications conducted by each sub team to be under the SQA activities, SPI practices and CMMI process areas and goals. The proposing of this new Hybrid model is very important to: overcome as possible as the limitations of traditional software process models, agile methodologies and web engineering process models; overcome the limitations and challenges of large web applications development; and match the SPI and CMMI key process areas and goals to improve the large enterprises software process and software quality assurance. According to the literature, it is clearly that, the CMMI evaluates an organization as a whole and its development processes. The CMMI is a method for software management and an appropriate way to improve processes, whereas agile XP, Spiral, WebEng and Hybrid approaches are methods for software development. According to Hybrid model analysis with CMMI process areas in chapter 6, we investigate that: The Hybrid model activities covered and largely satisfied the CMMI Level2 process areas and goals. Because, there are five of the seven process areas of CMMI level2 are largely satisfied by Hybrid model, while, supplier agreement management area and measurement and analysis area are satisfied. Therefore, the Hybrid activities are compatible with CMMI level2 process areas. The Hybrid model activities also covered and largely satisfied the CMMI Level3 process areas and goals. Because, there are five of the fourteen process areas of CMMI level3: organizational process focus, organizational process definition, integrated supplier management, decision analysis and resolution, and organizational environment for integration are satisfied by Hybrid model. And all of the remaining process areas of CMMI level3 are largely satisfied by Hybrid model. Therefore, the Hybrid activities are compatible with CMMI level3 process areas. The Hybrid model activities covered and satisfied the CMMI Level4 process areas and goals. Because, both of the two process areas of CMMI level4: organizational process performance and quantitative project management are satisfied by Hybrid model. Therefore, the Hybrid activities are compatible with CMMI level4 process areas. The Hybrid model activities partially satisfied the CMMI Level5 process areas and goals. Because, both of the two process areas of CMMI level5 (organizational innovation and deployment; and causal analysis and resolution) are partially satisfied by Hybrid model. Therefore, the Hybrid activities are partially compatible with CMMI level5 process areas. At the same time CMMI 167

186 level5 can be attained with major adaptations and new activities required to be added to Hybrid model. Table (7.1) shows the summary of analysis of Hybrid model activities against the CMMI levels key process areas. Table (7.1): The Hybrid Model Activities Compatibility with CMMI levels KPAs CMMI Level2 Process Areas 1 requirements management largely satisfied 2 project planning largely satisfied 3 project monitoring and control largely satisfied 4 supplier agreement management satisfied 5 measurement and analysis satisfied 6 process and product quality assurance largely satisfied 7 Configuration Management largely satisfied CMMI Level3 Process Areas 1 Requirements Development largely satisfied 2 Technical Solution largely satisfied 3 Product Integration process Largely Satisfies 4 Verification largely satisfied 5 Validation largely satisfied 6 Organizational Process Focus satisfied 7 Organizational Process Definition satisfied 8 Organizational Training largely satisfied 9 Integrated Project Management largely satisfied 10 Risk Management largely satisfied 11 Integrated Teaming largely satisfied 12 Integrated Supplier Management satisfied 13 Decision Analysis and resolution satisfied 14 Organizational Environment for Integration satisfied CMMI Level4 Process Areas 1 Organizational Process Performance (OPP) satisfied 2 Quantitative Project Management (QPM) satisfied CMMI Level5Process Areas 1 Organizational Innovation and Deployment (OID) partially satisfies 2 Causal Analysis and Resolution (CAR) partially satisfies At the same time an evaluation of the Hybrid model has been carried out by distributing questionnaire to many professional developers and managers currently working in different large Jordanian enterprises. These enterprises are previously selected in this research as a research population. This questionnaire is based on the CMMI key process areas and goals. The analysis of results shows that the Hybrid model satisfied about 85.57% of CMMI level2, 86.86% of CMMI level3, 73.35% of CMMI level4, and finally about only 31.65% of CMMI level5. At the end, the answers to the research questions are as follows: 1. According to the analysis of the Hybrid model compatibility with CMMI levels key process areas and goals in chapter6, and also according to results of the Hybrid evaluation by large Jordanian enterprises, We investigate that: the answer of question one is YES 168

187 because: the Hybrid model steps and activities covered and largely satisfied both of CMMI Level2 and CMMI Level3 process areas; whereas, covered and satisfied CMMI Level4 process areas and goals; but partially satisfied CMMI Level5 KPAs and goals. 2. According to Hybrid model comparison with XP, Spiral and WebEng in their compatibilities with CMMI levels process areas and goals; we investigate that: the answer of question two is YES because this model can overcome the limitations of traditional Spiral, agile XP and WebEng by adopting them in combinations and integrating their strengths and capabilities in one web development process. At the same time eliminate the drawbacks of each one of them. The properties of each one of them were discussed in details in chapter2 and chapter5. 3. According to web development problems obtained from the literature and surveys in this research which were affecting the large web applications development in large enterprises (see tables (5.1), (5.2) and (5.3)), and according to the discussion of the ability of the Hybrid model to solve these problems (see table (5.5)), we investigated that, the answer of both question three and question four is YES. Because it has been noted that the Hybrid model have the ability to solve most of these problems. Therefore, the large web development enterprises can benefit from Hybrid model if they apply it in a good manner with sufficient training because it has been noted from the analysis of Hybrid steps that: this model can overcome as possible as the problems of large web applications development mentioned in the literature researches and also web development problems in these large enterprises. 7.4 Contributions The literature researches and survey clarified that, the web engineering processes used for large web development need to focus more on project management, analysis and requirements phases to increase the rate of successful projects. The contributions of this research are as follows: 1. The assignment of centralized team in Hybrid model leads to more arrangement and organization in web development process. The main roles of the centralized team in Hybrid model is to adopt the Spiral model and to focus on: analyzing of main problems of the large web application; determine precisely what the new web application is supposed to do, its objectives, goal, mission and vision; document these aspects in a clear and understandable way; risk analysis and management; and control and mange all sub teams and overall web development process. 169

188 2. The approach of dividing the large numbers of developers adopted in the Hybrid model will result in: manageable and flexible the overall large web application; the sub web application can be made small enough for few persons to work on (sub team); and large web application can be designed as a set of parallel or concurrent actions. 3. Identifying and classifying requirements by management team into classes; and more analysis and gathering of each sub web application s requirements carried out by each sub team using Throwaway Prototype, will result in easy to manage, understand, design, code and test them each alone. 4. The adoption of XP reusability principle by each sub team in Hybrid model lead to: reduce the times of design and code; reduce the development effort; need less number of developers; need less debugging because of use of proven software; reduce the costs; and more easy to achieve the correct and reliable designs. 5. The adoption of XP customer communications and feed back principle during the overall development process of sub web application will overcome as possible as the requirements misunderstanding and changing requirements problems. 6. The adoption of WebEng process model by each one of sub teams will ensure matching the sub web application development process with the special characteristics of web based applications. 7. The adoption of test mechanism and integrating the SQA activities within the Hybrid model steps for measuring project success during the development process and involving the end users as a mechanism for validating the success of a project. Then, the management team measure the success at the end of a project s life-cycle or after the project had ended. 8. In order to improve the development process and performance of large enterprise, the management team must always: monitor the overall web development progress, sub team activities to be under the conditions of SPI and CMMI KPAs and goals; and also conduct the web engineering best practices. 7.5 Recommendations to Avoid Failure The results of the survey in large web development Jordanian enterprises and the limitations of these enterprises lead to suggestion of a set of recommendations that must be considered by these enterprises to improve the web development process and web engineering practices as follows: 170

189 1. Identifying its management team to include many persons professional in management techniques, web development activities, and have knowledge in web engineering best practices, SPI and CMMI KPAs and goals. 2. Adopting efficient and suitable project management methodology. 3. Understanding all web application s functions, objectives and its environment. 4. Addressing its organizational policies, human resources, and legal, cultural and social aspects by the management team. 5. Identifying and involving all stakeholder and their roles. 6. Focusing on requirements gathering, analysis, classifying and management. 7. Divide large web application into a set of sub web applications according to its size. 8. Divide the large numbers of developers into a set of small multidisciplinary sub teams working in parallel. 9. Adopting Spiral for risk identification, analysis, and management of the overall web application and also for each one of sub web applications. 10. Adopting Throwaway Prototype for requirement elicitation and analysis for each sub application. 11. Adopting WebEng process model by each sub team to develop sub web application according to special characteristics of web development process and web engineering best practices. 12. Adopting XP principles such as pair programming, refactoring and customer communications and feed back by each sub team. 13. Managing the integrating all sub web applications by management team after verifying and testing them according to SQA activities. 14. Test, evaluate and update all delivered sub web applications by management team. 15. Documenting the overall large web application development activities by the management team, and for all sub web applications by each individual sub team. 16. Monitoring and controlling the maintenance of the large web application and its sub applications by the management team and also by the sub teams. 17. Focusing on the quality management and standards and SQA activities. 18. Focusing on the software process improvement levels and monitoring the enterprise s level against the CMMI KPA s and goals. 19. Continues education and training of all developers in large enterprise and teach them how to deal with CMMI KPAs and goals. 171

190 7.6 Future Works in Research This work will open many possibilities for further research in the field of web engineering and process models for large web applications development as follows: 1. This research could be extended to practically conduct this Hybrid model by large Jordanian enterprises which undertaken large web development. This is can be done by adopting a suitable modification and more deep description on the Hybrid steps. This modification includes removal of mention to each of Spiral, Throwaway Prototype, XP and WebEng models and then summarize only their important steps and strengths to be included in the Hybrid model. After that we can adopt another evaluation for this Hybrid model to ask these enterprises about its benefits, strengths and limitations. 2. Adopt a comparative study between the other literature web engineering models for developing large web applications and the Hybrid model. This is can be achieved by addressing the steps, strengths and limitations of each one of these models. 3. This research could be extended to investigate the impact of large enterprises culture on adoption of this Hybrid model. 7.7 Limitations of the Research As with any study, there are many limitations of this research. The scope of the research has been limited to only large Jordanian enterprises which undertaken large web development. It is recognized that such enterprises have cultural and high security properties which distinguish them from other enterprises. These properties lead to slow response rate by these enterprises to the questionnaire during the survey stage of the research. This is the most important limitation of this research. Another limitation is the lack of researches and surveys related to web engineering best practices in large web development enterprises. 172

191 9. References [1] Gerti Kappel, Birgit P., Siegfried R. and R. Werner. Web Engineering: The Discipline of Systematic Development of Web Applications, John Wiley & Sons, Ltd., pp.1-2, [2] Roger S. Pressman. Software Engineering: A Practitioner s Approach, 6 th edition, McGraw-Hill International Edition, [3] Murugesan S., Deshpande Y., Hansen S. and A. Ginige. Web Engineering: A New Discipline for Development of Web-Based Systems. Proceedings of the First International Conference on Software Engineering. ICSE 99 Workshop on Web Engineering, pp , [4] Athula Ginige and San Murugesan. Web Engineering: An Introduction, IEEE MultiMedia, Electronic Edition (IEEE Computer Society DL), Vol.8, No.1, pp.14-18, January [5] Athula Ginige and San Murugesan. The Essence of Web Engineering, Managing the Diversity and Complexity of Web Application Development, IEEE Multimedia, Electronic Edition (IEEE Computer Society DL), Vol.8, No.2, pp.22-25, [6] Howcroft, D. and J. Carroll. A Proposed Methodology for Web Development, ECIS, a Cyberspace Odyssey, Hansen, H.R., Bichler, M. & Mahrer, H. (eds). Proceedings of the Eighth European Conference on Information Systems (ECIS), Vienna, 3 5 July, [7] Richard Vidgen. Constructing a Web Information System Development Methodology, Blackwell Science Ltd, Information Systems Journal, Vol.12, issue.3, pp , July2002. [8] Jeff Garland and Richard Anthony. Large-Scale Software Architecture, A Practical Guide Using UML, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, [9] Douglas Bell. Software Engineering: A Programming Approach, 3 rd edition, Addison Wesley, Pearson Education Limited, [10] Bill Curtis, Herb Krasner and Nell Iscoe. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, New York, NY, USA, Vol.31, Issue 11, pp , November [11] Meir Burstin and Moshe Ben-Bassat. A User's Approach to Requirements Analysis of a Large Software System, ACM Annual Conference/Annual Meeting, Proceedings of the TH 1984 annual conference of the ACM on the 5 generation challenge, pp , October1984. [12] Tetsuo Tamai and Akito Itou. Requirements and Design Change in Large-Scale Software Development: Analysis from the Viewpoint of Process Backtracking, International Conference on Software Engineering, Proceedings of the 15th international conference on 173

192 Software Engineering, Baltimore, Maryland, United States, IEEE Computer Society Press Los Alamitos, CA, USA, pp , [13] Liz Barnett. Learning from Others: Best Practices for Large-Scale Agile Development, Agile Journal, CMC Media, Inc., 12Nov [14] Kemal A. Delic and Umeshwar Dayal. Adaptation in Large-Scale Enterprise Systems: Research & Challenges, Ubiquity: An ACM IT Magazine and Forum, Vol.5, Issue.23, pp.1-1, ACM New York, NY, USA, 4-10August2004. [15] S. Balakrishnan and M. Somasundaram. Large Scale Object-Oriented Application Development In Practice, Technology Review# , Tata Consultancy Services, November2001. [16] McDonald A. and R. Welland. Web Engineering in Practice, Proceedings of the 10 th International World Wide Web Conference (WWW10) 4 th Workshop on Web Engineering, pp.21-30, 2 May2001. [17] Barry, C. and M. Lang. A Survey of Multimedia and Web Development Techniques and Methodology Usage, IEEE Multimedia, Special issues on Web Engineering, Vol.8, No.2, pp.52-60, [18] Bouchaib Bahli and Dany Di Tullio. Web Engineering: An Assessment of Empirical Research, Communications of the Associations for Information Systems, Vol.12, pp , [19] M. Epner. Poor Project Management Number-One Problem of Outsourced E-Projects, Research Briefs, Cutter Consortium, 7 November2000. [20] Dharmender Singh Kushwaha, R.K. Singh and A.K.Misra. Cognitive Web Based Software Development Process: Towards a more Reliable Approach, ACM SIGSOFT Software Engineering Notes, Vol.31, No.4, pp.1-6, ACM Press New York, NY, USA, July2006. [21] Samuel Hsieh. Software Engineering For Web Application Development, Journal of Computing Sciences in Colleges, Consortium for Computing Sciences in Colleges, USA, Vol.19, Issue.1, pp.10-19, October2003. [22] Vítor Estêvão Silva Souza and Ricardo de Almeida Falbo. An Agile Approach for Web Systems Engineering, ACM International Conference Proceeding Series; Proceedings of the 11th Brazilian Symposium on Multimedia and the Web, Pocos de Caldas - Minas Gerais, Brazil, Vol.125, pp.1-3, ACM Press New York, NY, USA, 5-7December2005. [23] George Whitson. Webhelix: Another Web Engineering Process, Journal of Computing Sciences in Colleges, Vol.21, Issue.5, pp.21-27, Publisher: Consortium for Computing Sciences in Colleges USA, May2006. [24] Crane, A. and S. Clyde. A Lightweight Development Process for Implementing Business Functions on the Web, Proceedings of AACE (WEBNET). Chesapeake, VA:AACE, pp , Ed/ITLib Digital Library, Association for the Advancement of Computing in Education (AACE),

193 [25] Weiquan Zhao and Jian Chen. CoOWA: A Component Oriented Web Application Model, Technology of Object-Oriented Languages and Systems, Proc. of 34h International Conference on TOOLS Asia. IEEE Sch. of Comput. & Inf. Sci., South Australia Univ., Adelaide, SA, pp , [26] Mario Bochicchio and Roberto Paiano. Prototyping Web Applications, Symposium on Applied Computing, Proceedings of the 2000 ACM symposium on Applied computing (SAC00 Como), Vol. 2, pp , ACM New York, NY, USA, 19-21March [27] Mario Bochicchio and Nicola Fiore. WARP: Web Application Rapid Prototyping, Symposium on Applied Computing, Proceedings of the 2004 ACM symposium on Applied computing, SESSION: Web technologies and applications (WTA), pp , ACM New York, NY, USA, March2004. [28] G. Griffiths, B. D. Hebbron, M. A. Lockyer, and B. J. Oates. A Simple Method & Tool for Web Engineering, ACM International Conference Proceeding Series; Vol.27, Proceedings of the 14th international conference on Software engineering and knowledge engineering (SEKE), Ischia, Italy, SESSION: Workshop on web engineering, pp , ACM New York, NY, USA, [29] Mikio Aoyama. Web-Based Agile Software Development, IEEE Software, Vol.15, No.6, pp.56-65, IEEE Computer Society Press Los Alamitos, CA, USA, Nov1998. [30] Andrew McDonald and Ray Welland. Agile Web Engineering (AWE) Process, Technical Report TR , Department of Computing Science, University of Glasgow, Glasgow, Scotland, G12 8QQ, 02 December2001. [31] Athula Ginige and San Murugesan. Web Engineering: A Methodology for Developing Scalable, Maintainable Web Applications, Cutter Journal, Vol.14, No.7, July2001. [32] Athula Ginige. Web Engineering: Managing the Complexity of Web Systems Development, ACM International Conference Proceeding Series, Proceedings of 14 th international conference on Software engineering and knowledge engineering, SESSION: Workshop on Web Eng., Vol.27, pp , Ischia, Italy, ACM Press, NewYork, NY, USA, [33] H. Tai, K. Mitsui, T. Nerome, M. Abe, K. Ono and M. Hori. Model-Driven Development of Large-Scale Web Applications, IBM Journal of research & development, IBM research in Asia, Vol.48, No.5/6, September/November2004. [34] Blayne Maring. Object-Oriented Development of Large Applications, IEEE Software, Vol.13, No.3, pp.33-40, GTE Telephone Operations Headquarters, Irving, TX, May1996. [35] Maria Ericsson. Developing Large-Scale Systems with the Rational Unified Process, Rational Software White Paper, Rational, the e-development company, USA, Rational Software Corporation, [36] European Software Institute. Software Best Practice Questionnaire, Esi Code/Version, European Software Institute, Spain, December

194 [37] Ian Sommerville. Software Engineering, 7 th edition, Pearson Addison Wesley, Pearson education limited, chapter1, [38] James F. Peters and Witold Pedrycz. Software Engineering: An Engineering Approach, John Wiley & Sons, Inc., New York, chapter1, [39] Anthony Finkelstein, and Jeff Kramer. Software Engineering: A Roadmap, International Conference on Software Engineering, Proceedings of the Conference on The Future of Software Engineering, Limerick, Ireland, pp.3 22, ACM New York, NY, USA, [40] Jim Cooling. Software Engineering for Real-Time Systems, Addison Wesley, Pearson Education Limited, Edinburgh Gate, Harlow, Essex CM20 2JE, England and Associated Companies throughout the world, chapter 2, pp.45-49, [41] Yogesh Deshpande, San Murugesan, Athula Ginige, Steve Hansen, Daniel Schwabe, Martin Gaedke and Bebo White. Web Engineering, Journal of Web Engineering, Vol.1, No.1, pp , Rinton Press, [42] Jeff Offutt. Quality Attributes of Web Software Applications, Software, IEEE, Vol.19, Issue.2, pp.25-32, ISSN: , References Cited:12, CODEN: IESOEG, INSPEC Accession Number: , Mar/April2002. [43] Said Hadjerrouit. Web-based Application Development: A Software Engineering Approach, ACM SIGCSE Bulletin, Vol.33. No.2, pp.31-34, ACM New York, NY, USA, June [44] Engin Kirda, Mehdi Jazayeri, Clemens Kerer and Markus Schranz. Experiences in Engineering Flexible Web Services, IEEE MultiMedia, Vol.8, No.1, pp.58-65, Jan2001. [45] Jesper Holck. 4 Perspectives on Web Information Systems, Proceedings of the 36 Annual Hawaii International Conference on System Sciences (HICSS 03), Vol.8, Computer Society, IEEE, 6-9 January [46] Alan R. Hevner, Rosann W. Collins and Monica J. Garfield. Product and Project Challenges in Electronic Commerce Software Development, ACM SIGMIS Database, the DATA BASE for Advances in Information Systems, Vol.33, Issue.4, pp.10-22, ACM New York, NY, USA, [47] Ian Sommerville. Software Process Models, ACM Computing Surveys, CRC Press, Vol.28, No.1, pp , March1996. [48] Adrian Als, Charles Greenidge and P. Walcott. Software Process Models, Adrian Als, Charles Greenidge & P. Walcott, [49] Alfonso Fuggetta. Software Process: A Roadmap, International Conference on Software Engineering, Proceedings of the Conference on The Future of Software Engineering, Limerick, Ireland, pp.25-34, th 176

195 [50] Walt Scacchi. Process Models in Software Engineering, J.J. Marciniak (ed.), Encyclopedia of Software Engineering, 2 nd Edition, John Wiley and Sons, Inc, New York, Institute for Software Research, University of California, Irvine, February [51] Center for Technology in Government University at Albany SUNY. A Survey of System Development Process Models, CTG.MFA 003, Models for Action Project: Developing Practical Approaches to Electronic Records Management and Preservation. This material is based upon work supported in part by the National Historical Publications and Records Commission under Grant No , [52] Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis and Marilyn Bush. Key Practices of the Capability Maturity Model SM, Version 1.1, Technical Report, CMU/SEI-93-TR-025, ESC-TR , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, p.1, February [53] Mark C. Paulk, Bill Curtis, Mary Beth Chrissis and Charles V. Weber. Capability Maturity Model SM for Software, Version 1.1, Technical Report, CMU/SEI-93-TR-024, ESC-TR , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, p18, February [54] Watts S. Humphrey and Marc I. Kellner. Software Process Modeling: Principles of Entity Process Models, International Conference on Software Engineering, Proceedings of the 11th international conference on Software engineering, Pittsburgh, Pennsylvania, United States, pp , ACM Press New York, NY, USA, [55] Dorothy R. Graham. Incremental Development and Delivery for Large Software Systems, Software Engineering for Large Software Systems, ed. B. A. Kitchenham, Proceedings of the Sixth Annual CSR Conference on Large Software Systems, Elsevier. Software Prototyping and Evolutionary Development, IEE Colloquium on., Vol.25, No.2, pp.1-9. London, UK, 11 Nov1992. [56] Bill Curtis, Herb Krasner, Vincent Shen and Neil Iscoe. On Building Software Process Models Under the Lamppost, International Conference on Software Engineering, Proceedings of the 9th international conference on Software Engineering, Monterey, California, United States, pp , IEEE Computer Society Press Los Alamitos, CA, USA, [57] Royce Winston. Managing the Development of Large Software Systems: Concepts and Techniques, International Conference on Software Engineering, Proceedings of the 9th international conference on Software Engineering, Monterey, California, United States, pp , IEEE Computer Society Press Los Alamitos, CA, USA, [58] Mary Hanna. Farewell to Waterfalls?, Software Magazine, Vol.15, Issue.5, pp.38 46, Wiesner Publishing, LLC Englewood, CO, USA, May [59] J. Martin. Rapid Application Development, Prentice-Hall, Macmillan Publishing Co., Inc. Indianapolis, IN, USA,

196 [60] John Crinnion. Evolutionary Systems Development: a Practical Guide to the Use of Prototyping within a Structured Systems Methodology, Plenum Press, New York, [61] S. P. Overmyer. Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia, [62] Barry W. Boehm. TRW Defense Systems Group, A Spiral Model of Software Development and Enhancement, Computer: The flagship publication of the IEEE Computer Society, Vol.21, No.5, pp.61-72, May1988. [63] Rational Software Corporation. Rational Unified Process Best Practices for Software Development Teams, A Rational Software Corporation White Paper, TP-026A Rev. 11/98, Corporate Headquarters, Homestead Road, Cupertino, CA 95014, web: [64] Rational Software Corporation. Rational Unified Process for Systems Engineering RUP SE1.1, A Rational Software White Paper TP 165A, 5/02, Corporate Headquarters, Homestead Road, Cupertino, CA 95014, TP165A 5/02, web: [65] Mikio Aoyama. Agile Software Process and Its Experience, Proceedings of the 1998 (20th) International Conference on Software Engineering, IEEE, pp.3-12, Kyoto, Japan, 19-25April [66] Steven R. Haynes and Marc Friedenberg. Best Practices in Agile Software Development, Technical Report No.0018, College of Information Sciences and Technology, The Pennsylvania State University, 19May2006. [67] Kent Beck, James Grenning and Robert C. Martin. Manifesto for Agile Software Development, Ward Cunningham, Feb2001, and [68] Scott Ambler. Quality in an Agile World, 34 SQP, Vol.7, No.4, ASQ, [69] David Cohen, Mikael Lindvall and Patricia Costa. Agile Software Development, A DACS State-of-the-Art Report, Produced by Fraunhofer Center for Experimental Software Engineering Maryland and the University of Maryland, Prepared by: Data and Analysis Center for Software.775 Daedalian Dr.Rome, New York , January [70] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta. Agile Software Development Methods: Review and Analysis, Espoo, VTT Publications 478, pp.107, [71] Jonna Kalermo and Jenni Rissanen. Agile Software Development in Theory and Practice, Software Business Program, Master s thesis, University of Jyvaskyla, Department of Computer Science and Information Systems, Jyvaskyla, 6Augest

197 [72] Ali Khan. A Tale of Two Methodologies for Web Development: Heavyweight vs. Agile, Report, Minor research project in IS to the Dept. of Information Systems, The University of Melbourne, Australia, June [73] Pekka Abrahamsson, J Warsta, MT Siponen and J Ronkainen. New Directions on Agile Methods: A Comparative Analysis, IEEE, Proceedings of the International Conference on Software Engineering, (ICSE25), p. 244, Portland, Oregon, USA, 3-5 May [74] Zoran Stojanovic, Ajantha Dahanayake and Henk Sol. Modeling and Architectural Design in Agile Development Methodologies, In - (Ed.), Proceedings of the 8th CAISE/IFIP8.1 International Workshop on Evaluation Methods in System Analysis and Design EMMSAD '03. pp Velden, Austria, [75] James Newkirk. Introduction to Agile Processes and Extreme Programming, ICSE'02, ACM 1-5, Orlando, Florida, USA, 19-25May [76] Kent Beck. Extreme Programming Explained: Embrace Change, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, ISBN , Reading MA, [77] Daniel H. Steinberg and Daniel W. Palmer. Extreme Software Engineering, A Hands-On Approach, Pearson Education, Inc., Upper Saddle River, New Jersey 07458, [78] Jim Highsmith. Extreme Programming: Agile Project Management Advisory Service White Paper, Cutter Consortium, 2002, (site:[email protected]: [79] Laurie Williams, Robert R. Kessler, Ward Cunningham and Ron Jeffries. Strengthening the Case for Pair Programming, Software, IEEE, Vol.17, Issue.4, pp.19-25, Jul/Aug [80] Sharifah Lailee Syed-Abdullah. Empirical Study on Extreme Programming, a thesis submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy, Department of Computer Science, University of Sheffield, January [81] Daniel Turk, Robert France and Bernhard Rumpe. Research Review: Assumptions Underlying Agile Software-Development Processes, Journal of Database Management, Vol.16, No.4, pp.62-87, October-December [82] Aniket Mahanti. Challenges in Enterprise Adoption of Agile Methods A Survey, Journal of Computing and Information Technology, CIT 14, Vol.3, pp , [83] Dan Turk, Robert France and Bernhard Rumpe. Limitations of Agile Software Processes, Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering, XP2002, May 26-30, Alghero, Italy, pp.43-46, [84] Linda Rising and Norman S. Janoff. AG Communication Systems. The Scrum Software Development Process for Small Teams, IEEE Software, Vol.17, Issue.4, pp.26-32, IEEE Computer Society Press Los Alamitos, CA, USA, July/August

198 [85] Mike Cohn and Doris Ford. Introducing an Agile Process to an Organization, IEEE Computer Society, Vol.36, Issue.6, pp.74-78, IEEE 74 Computer Introducing an Agile, Process to an Organization Since the publication of Kent, June (ieeexplore.ieee.org) [86] Michael Kircher and David L. Levine. The XP of TAO-eXtreme Programming of Large, Open-source Frameworks, Proceedings of the 1 st International Conference on extreme Programming and Flexible Processes in Software Engineering, Cagliari, Italy, 21-23June [87] Mikael Lindvall, Vic Basili, Barry Boehm, Patricia Costa, Kathleen Dangle, Forrest Shull, Roseanne Tesoriero, Laurie Williams and Marvin Zelkowitz. Empirical Findings in Agile Methods, Proceedings of Extreme Programming and Agile Methods - XP/Agile Universe 2002: Second XP Universe and First Agile Universe Conference, Chicago, IL, USA, Vol.2418/2002, pp , 4-7August2002. [88] Barry Boehm. Get Ready for Agile Methods with Care, IEEE 64 Computer, Vol.35, Issue.1, pp.64-69, January [89] Américo Sampaio, Alexandre Vasconcelos and Pedro R. Falcone Sampaio. Design and Empirical Evaluation of an Agile Web Engineering Process, 18º Simpósio Brasileiro de Engenharia de Software, [90] Frank Maurer and Sebastien Martel. Extreme Programming Rapid Development for Web-Based Applications, IEEE Internet Computing Magazine, Vol.6, No.1, pp.86-90, ISSN: , publisher: IEEE Educational Activities Department Piscataway, NJ, USA, January [91] Bob Schatz and Ibrahim Abdelshafi. Primavera Gets Agile: A Successful Transition to Agile Development, IEEE Software, IEEE Computer Society, Vol.22, No.3, May/June 2005.( [92] F. Grossman, J. Bergin, D. Leip, S. Merritt and O. Gotel. One XP Experience: Introducing Agile (XP) Software Development into a Culture that is Willing but not Ready, Dr. Fred Grossman, Dr. Joseph Ber-gin, and IBM Corp, 2004 [93] S. Hayes. Why use Agile Methods?, ZDNet Australia Article, Melbourne, Australia: Khatovar Technology, 2003, http www_builderau_com_au_program_development_htm [94] Sridhar Nerur, RadhaKanta Mahapatra and George Mangalaraj. Challenges of Migrating to Agile Methodologies, Communications of the ACM ISSN CODEN CACMA2 Communications of the Association for Computing Machinery., Vol.48, No.5, pp.72-78, May [95] Robert L. Glass. Agile Versus Traditional: Make Love, Not War!, Cutter IT Journal: The Journal of Information Technology Management, Vol.14, No.12, The Great Methodologies Debate: Part 1, December

199 [96] Laurie Williams and Alistair Cockburn. Agile Software Development: It s about Feedback and Change, Computer, Vol.36, Issue.6, pp.39-43, IEEE Computer Society, June [97] Boehm B. and R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed, Boston: Addison-Wesley, [98] Barry Boehm and Richard Turner. Balancing Agility and Discipline: Evaluating and Integrating Agile and Plan-Driven Methods, Proceedings of the 26th International Conference on Software Engineering (ICSE 04), pp , May [99] Peter Meso and Radhika Jain. Agile Software Development: Adaptive Systems Principles and Best Practices, Contemporary Practices in Systems Development, Information Systems Management, Vol.23, Issue.3, 1June2006. [100] Vishnu Vinekar, Craig W. Slinkman and Sridhar Nerur. Can Agile and Traditional Systems Development Approaches Coexist? An Ambidextrous View, Contemporary Practices In Systems Development, Information Systems Management, JOURNAL.COM, Vol.23 Issue.1, p31-42, [101] Sridhar Nerur, RadhaKanta Mahapatra and George Mangalaraj. Challenges of Migrating to Agile Methodologies, Communications of the ACM, Communications of the ACM, Vol.48, No.5, pp.72 78, ACM New York, NY, USA, May [102] Barry Boehm and Richard Turner. Management Challenges to Implementing Agile Processes in Traditional Development Organizations, IEEE SOFTWARE, Published by the IEEE Computer Society , Vol.22, No.5, pp.30-39, September/October [103] Jan Bolmeson. Web Development Roadmap: a Methodology for Structured Development of Web-Based Systems, Master s Thesis, Department of Communication Systems, Lund Institute of Technology, Lund University, CODEN:LUTEDX(TETS- 5531)/1-72/(2005) & local 12, [104] V. Balasubramanian, Alf Bashian and Daniel Porcher. A Large-Scale Hypermedia Application Using Document Management and Web Technologies, Conference on Hypertext and Hypermedia, Proceedings of the eighth ACM conference on Hypertext, Southampton, United Kingdom, pp , ACM New York, NY, USA, [105] Klara Nahrstedt and Wolf-Tilo Balke. Towards Building Large Scale Multimedia Systems and Applications: Challenges and Status, International Multimedia Conference, Proceedings of the first ACM international workshop on Multimedia service composition (MSC 05), Hilton, Singapore, Session: Keynote, pp.3-10, ISBN: , ACM New York, NY, USA, 11November2005. [106] Axel van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective, Proceedings of the 22nd international conference on Software Engineering, Limerick, Ireland, pp.5-19, ACM New York, NY, USA, [107] Bashar Nuseibeh and Steve Easterbrook. Requirements Engineering: A Roadmap, International Conference on Software Engineering, Proceedings of the Conference on The 181

200 Future of Software Engineering, Limerick, Ireland, pp.35 46, ACM NewYork, NY, USA, [108] Kotonya, G. and I. Sommerville. Requirements Engineering: Process and Techniques, Chichester, England, John Wiley and Sons Inc, [109] Sawyer, P., I. Sommerville and S. Viller. Requirements Process Improvement through the Phased Introduction of Good Practice. Software Process - Improvement and Practice, Vol.3, No.1, pp.19-34, [110] Ian Sommerville and P. Sawyer. Requirements Engineering: A Good Practice Guide, John Wiley & Sons, Inc., New York, NY, USA, [111] Ian Sommerville and Jane Ransom. An Empirical Study of Industrial Requirements Engineering Process Assessment and Improvement, ACM Transactions on Software Engineering and Methodology (TOSEM), Vol.14, Issue.1, pp , ACM New York, NY, USA, January [112] B. W. Boehm. The Economics of Software Maintenance. Proceedings of 1st International Conference on Software Maintenance. IEEE Press. Software Maintenance Workshop pp.9-37, [113] Martin Maguire and Nigel Bevan. User Requirements Analysis: A Review of Supporting Methods, Proceedings of IFIP 17th World Computer Congress, Montreal, Canada, p Kluwer Academic Publishers, 25-30August [114] Li Jiang, Armin Eberlein, Behrouz Homayoun Far. A Methodology for Requirements Engineering Process Development, Proceedings of the 11th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS 04). IEEE, [115] Escalona, M.J. and N. Koch. Requirements Engineering for Web Applications A Comparative Study, Journal of Web Engineering, Vol.2, No.3, pp , [116] Manar Alalfi, James R.Cordy and Thomas R. Dean. A Survey of Analysis Models and Methods in Website Verification and Testing, Technical Report , School of Computing, Queen s University Kingston, Ontario, Canada, February [117] Barry Doyle and Cristina Videira Lopes. Survey of Technologies for Web Application Development, ACM Journal Name, Vol.2, No.3, pp.1 43, June [118] Nora Koch, Gefei Zhang, and María José Escalona. Model Transformations from Requirements to Web System Design, ACM International Conference Proceeding Series; Vol.263, Proceedings of the 6th international conference on Web engineering (ICWE'06), Palo Alto, California, USA, SESSION: Session 11: design and development methods, pp , ACM, New York, NY, USA, 11-14July2006. [119] Nora Koch, Vallecillo A. and G. Rossi. Model-Driven Web Engineering, (Eds.) In Proc. Workshop on Model-Driven Web Engineering (MDWE 2005), Sydney, Australia,

201 [120] Object Management Group (OMG). MDA Guide pdf. Version 1.0.1, [121] S. Meliá, A. Kraus and N. Koch. MDA Transformations Applied to Web Application Development. In Proc.5 th International Conference on Web Engineering (ICWE 2005), LNCS 3579, pp , Sydney, Australia, [122] M. Gaedke and G. Graef. Development and Evolution of Web-Applications Using the WebComposition Process Model. International Workshop on Web Engineering at the 9 th International World-Wide Web Conference (WWW9), Amsterdam, Netherlands, 15May2000. [123] Franca Garzotto, Luca Mainetti and Paolo Paolini. Hypermedia Design, Analysis, and Evaluation Issues, Communications of the ACM, Vol.38, Issue.8, pp.74 86, ISSN: , publisher: ACM New York, NY, USA, August [124] Franca Garzotto, Paolo Paolini and Daniel Schwabe. HDM a Model for the Design of Hypertext Applications, Conference on Hypertext and Hypermedia, Proceedings of the third annual ACM conference on Hypertext, San Antonio, Texas, United States, pp , ISBN: , publisher: ACM NewYork, NY, USA, [125] Daniel Schwabe, Gustavo Rossi and Simone Barbosa. Systematic Hypermedia Application Design with OOHDM, Conference on Hypertext and Hypermedia, Proceedings of the seventh ACM conference on Hypertext, Bethesda, Maryland, United States, pp , ACM, New York, NY, USA, [126] Daniel Schwabe and Gustavo Rossi. An Object Oriented Approach to Web-Based Applications Design, Theory and Practice of Object Systems, Vol.4, Issue.4 Special issue objects, databases, and the WWW, pp , ISSN: , John Wiley & Sons, Inc. New York, NY, USA, October [127] Tomás Isakowitz, Edward A. Stohr, and P. Balasubramanian. RMM: a Methodology for Structured Hypermedia Design, Communications of the ACM, Vol.38, Issue.8, pp.34-44, ISSN: , publisher: ACM New York, NY, USA, August [128] O.M.F. De Troyer, C.J. Leune. WSDM: A User Centered Design Method for Web Sites. In: Computer Networks and ISDN Systems 30 Special Issue on the 7th Intl. World-Wide Web Conference, Brisbane, Australia, [129] Nora Koch, A Comparative Study of Methods for Hypermedia Development, LMU Technical Report 9905, Ludwig-Maximilians-Universität München, Institute of Computer, November [130] Damiano Distante, Gustavo Rossi, Gerardo Canfora and Scott Tilley. A Comprehensive Design Model for Integrating Business Processes in Web Applications, International Journal of Web Engineering and Technology, Vol.3, No.1, pp.43-72, [131] Zhihao Chen, Tim Menzies, Dan Port and Barry Boehm. Feature Subset Selection Can Improve Software Cost Estimation Accuracy, ACM SIGSOFT Software Engineering 183

202 Notes, SESSION: Predictor Models in Software Engineering (PROMISE 05), Vol.30, Issue.4, pp.1-6, ACM New York, NY, USA, 15May2005. [132] Barry Boehm, E. Horowitz, Ray Madachy, D. Reifer, B. K. Clark, Bert Steece, A. W. Brown, S. Chulani, and C. Abts. Software Cost Estimation with COCOMO II with CDROM, 1st edition, Prentice Hall PTR Upper Saddle River, NJ, USA, [133] Barry Boehm, Chris Abts and Sunita Chulani. Software Development Cost Estimation Approaches A Survey, Annals of Software Engineering, Springer Netherlands, (Print) (Online), Vol.10, Numbers 1-4, pp , [134] Capers Jones. Software Cost Estimating Methods for Large Projects, The Journal of Defense Software Engineering, Software Productivity Research, LLC, Capers Jones, [135] Leszek A. Maciaszek. Requirements Analysis and System Design, second edition, Pearson Addison Wesley, Pearson Education Limited, chapter 1, pp.4, [136] S. L. Pfleeger. Software Engineering: Theory and Practice, Prentice Hall, pp.576, [137] Peter Bailey, Neil Ashworth and Nathan Wallace. Challenges for Stakeholders in Adopting XP. Third International Conference on extreme Programming and Agile Processes in Software Engineering (XP2002), [138] Anca-Juliana Stoica, Maliha Mushabbar, Syed Mushabar Sadiq, Stakeholder/Value Approach to Integrating System Development Model and Dependability Analysis: CS-GPE Case Study, 19th International Forum on Software Cost Modeling, L.A., U.S.A, 26-29October2004. [139] Jeffrey L Whitten and Lonnie D. Bentley. Systems Analysis and Design Methods, 4 th edition, Irwin McGraw-Hill, pp.724, [140] Karlie Hutchens, Michael Oudshoorn and Kevin Maciunas. Web-Based Software Engineering Process Management, Proceedings of the 30th Annual Hawaii International Conference on System Sciences (HICSS): Software Technology and Architecture, Vol.1, pp.676, IEEE Computer Society, Washington, DC, USA, [141] Zhiping Walter and George Scott. Management Issues of Internet/Web Systems, Communications of the ACM, Self managed systems, pp.87 91, ACM New York, NY, USA, March2006. [142] Steve Hansen. Web Information Systems: The Changing Landscape of Management Models and Web Applications, ACM International Conference Proceeding Series; Vol. 27, Proceedings of the 14th international conference on Software engineering and knowledge engineering (SEKE '02), Ischia, Italy, SESSION: Workshop on web engineering, pp , ACM, New York, NY, USA, 15-19July2002. [143] George Scott and Zhiping Walter. Management Problems of Internet Systems Development, Proceedings of the 35th Hawaii International Conference on System Sciences (HICSS), 7-10 January

203 [144] Martin, James N., Systems Engineering Guidebook: A Process for Developing Systems and Products (Systems Engineering), CRC Press, Inc.: Boca Raton, FL, [145] Jeff A. Estefan, Survey of Model-Based Systems Engineering (MBSE) Methodologies, INCOSE MBSE Focus Group, 25May [146] Piero Fraternali and Paolo Paolini. Model-Driven Development of Web Applications: The Autoweb System, ACM Transactions on Information Systems (TOIS), pp , Vol.18, Issue.4, ACM New York, NY, USA, October [147] Piero Fraternali. Tools and Approaches for Developing Data-Intensive Web Applications: A Survey, ACM Computing Surveys (CSUR), Vol.31, Issue.3, pp , ACM New York, NY, USA, September [148] Barry Doyle and Cristina Videira Lopes. Survey of Technologies for Web Application Development, ACM Journal Name, Vol.2, No.3, pp.1 43, June [149] Arturo Sanchez, Brandon Vega, Alexander Gonzalez and Gregory Jackson. Automatic Support for Testing Web-Based Enterprise Applications, ACM Southeast Regional Conference, Proceedings of the 44th annual Southeast regional conference (ACM SE 06), Melbourne, Florida, SESSION: Software engineering and testing, pp , ACM New York, NY, USA, 10-12March2006. [150] Thomas Müller, Dorothy Graham, Debra Friedenberg and Erik van Veendendal. Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board, Version, [151] Rashmi Joshi. Security Testing for Web Based Applications, Netkode Solutions Pvt. Ltd., September2006. [152] Manish Nilawar. A UML-Based Approach for Testing Web Applications, master thesis of Science with major in Computer Science, University of Nevada, Reno, August [153] Ji-Tzay Yang, Jiun-Long Huang, Feng-Jian Wang and William. C. Chu. Constructing an Object-Oriented Architecture for Web Application Testing, Journal of Information Science and Engineering 18, pp.59-84, [154] Mahnaz Shams, Diwakar Krishnamurthy and Behrouz Far. A Model-Based Approach for Testing the Performance of Web Applications, Foundations of Software Engineering, Proceedings of the 3rd international workshop on Software quality assurance (SOQUA 06), Portland, Oregon, SESSION: Testing and fault detection, pp.54 61, ACM New York, NY, USA, 6November [155] Wikipedia, Software Documentation, Software_documentation. Last modified on 14 May [156] Scott Tilley and Shihong Huang. Documenting Software Systems with Views III: Towards a Task-Oriented Classification of Program Visualization Techniques, ACM Special Interest Group for Design of Communication, Proceedings of the 20th annual 185

204 international conference on Computer documentation (SIGDOC 02), Toronto, Ontario, Canada, pp , ACM New York, NY, USA, 20-23October [157] Craig Boyle and Wee HorTeh. Multimedia Intelligent Documentation: Metactoc V, ACM Special Interest Group for Design of Communication, Proceedings of the 11th annual international conference on Systems documentation, Waterloo, Ontario, Canada, pp.21-27, ACM New York, NY, USA, [158] Rob Pierce. Optimizing Your Documentation with the Help of Technical Support, ACM Special Interest Group for Design of Communication, Proceedings of the 21st annual international conference on Documentation (SIGDOC 03), San Francisco, CA, USA, SESSION: Building on the user's experience, pp.6-11, ACM New York, NY, USA, 12-15October [159] Mehdi Jazayeri, Some Trends in Web Application Development, Future of Software Engineering (FOSE'07), pp , IEEE, May [160] Ayaz Farooq and Reiner R. Dumke. Research Directions in Verification & Validation Process Improvement, ACM SIGSOFT Software Engineering Notes, Page.1, Vol.32, Issue.4, ACM New York, NY, USA, July [161] Paul Mark and et. al., Capability Maturity Model for Software, Software Engineering Institute, CMU/SEI-91-TR-24, August [162] Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability Maturity Model SM for Software, Version 1.1, Technical Report, CMU/SEI-93-TR-024, ESC-TR , Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, February [163] CMMI Product Team, CMMI for Development, Version 1.2, CMMI-DEV, V1.2, CMU/SEI-2006-TR-008, ESC-TR , Improving processes for better products, Carnegie Mellon University, August [164] CMMI Product Team. Capability Maturity Model Integration (CMMI SM ), Version 1.1, CMMI SM for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1), Carnegie Mellon University, March [165] Software Engineering Institute, Capability Maturity Model Integration (CMMI ) Overview, Pittsburgh, PA , Carnegie Mellon University, [166] Lawrence G. Jones, Software Process Improvement and Product Line Practice: Building on Your Process Improvement Infrastructure Product Line Practice Initiative, Technical Note, CMU/SEI-2004-TN-044, Carnegie Mellon University, September [167] ISO Central Secretariat, ISO in Brief: International Standards for a Sustainable World. International Organization for Standardization, 21September2005,

205 [168] ISO 9000:2000 Frequently Asked Questions (FAQ's). International Organization for Standardization. Retrieved: 18May [169] Mark C. Paulk, A Comparison of ISO 9001 and the Capability Maturity Model for Software, Technical Report, CMU/SEI-94-TR-12, ESC-TR-94-12, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213, July [170] Hossein Saiedian and Natsu Carr. Characterizing A Software Process Maturity Model for Small Organizations, ACM SIGICE Bulletin, Vol.23, Issue.1, pp.2 11, ACM New York, NY, USA, July [171] Elif Demiriirs, Onur Demiriirs, Oguz Dikenelli and Billur Keskin. Process Improvement Towards IS Certification in a Small Software Organization, Proceedings of the 1998 International Conference on Software Engineering, IEEE, 438, Kyoto, Japan, April [172] Jennifer Gremba and Chuck Myers. The IDEAL(SM) Model: A Practical Guide for Improvement, Software Engineering Institute (SEI) publication, Bridge, issue.3, 1997, Carnegie Mellon University, [173] Karlheinz Kautz, Henrik Westergaard Hansen, and Kim Thaysen. Applying and Adjusting a Software Process Improvement Model in Practice: The Use of the IDEAL Model in a Small Software Enterprise, Proceedings of the 2000 International Conference on Software Engineering, ACM, ICSE, pp , Limerick, Ireland, [174] Mariano Montoni, Gleison Santos, Ana Regina Rocha, Kival C. Weber, and Eratóstenes E. R. de Araújo. MPS Model and TABA Workstation: Implementing Software Process Improvement Initiatives in Small Settings, Fifth International Workshop on Software Quality (WoSQ'07), IEEE, pp.4, May [175] Robert Schaefer. Deeper Questions: The Metaproblem of Large Organizations Developing Complex Systems and the Limits of Process, ACM SIGSOFT Software Engineering Notes, Vol.30, No.4, pp.1-6, ACM New York, NY, USA, July [176] Hideto Ogasawara, Takashi Ishikawa and Tetsuro Moriya. Practical Approach to Development of SPI Activities in a Large Organization: Toshiba s SPI History Since 2000, International Conference on Software Engineering, Proceedings of the 28th international conference on Software engineering (ICSE 06), Shanghai, China, SESSION: Far east experience papers: software process, pp , ACM New York, NY, USA, May [177] Tore Dybå. Factors of Software Process Improvement Success in Small and Large Organizations: An Empirical Study in the Scandinavian Context, Foundations of Software Engineering, Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE 03), Helsinki, Finland, SESSION: Software process and workflow, pp , ACM New York, NY, USA, 1-5September

206 [178] Dirk Stelzer and Werner Mellis. Success Factors of Organizational Change in Software Process Improvement, Software Process Improvement and Practice, Vol.4, Issue.4, John Wiley & Sons Ltd, 14May1999. [179] Medha Umarji and Carolyn Seaman. Predicting Acceptance of Software Process Improvement, Human and Social Factors of Software Engineering (HSSE), International Conference on Software Engineering, Proceedings of the 2005 workshop on Human and social factors of software engineering, St. Louis, Missouri, SESSION: Human and Social Factors of Software Engineering (HSSE), pp.1-6, ACM New York, NY, USA, 16May2005. [180] Mandy Northover, Alan Northover, Stefan Gruner, Derrick G. Kourie and Andrew Boake. Agile Software Development: A Contemporary Philosophical Perspective. ACM International Conference Proceeding Series; Vol. 226, Proceedings of the 2007 Annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries (SAICSIT), Port Elizabeth, South Africa, pp , ACM New York, NY, USA, 2-3October [181] Gary B. Wills, Noura Abbas, Rakhi Chandrasekharan, Richard M. Crowder, Lester Gilbert, Yvonne Howard, David E. Millard, Sylvia C. Wong and Robert J Walters, An Agile Hypertext Design Methodology. Conference on Hypertext and Hypermedia, Proceedings of the 18th conference on Hypertext and hypermedia (HT 07), Manchester, UK, SESSION: Hypertext models & theory, pp , ACM New York, NY, USA, 10-12September2007. [182] Kathy Baxter, Aviva Rosenstein, Kuldeep Kelkar, Craig Villamor, Lynn Miller, Melissa Federoff and Jeff Patton. Extreme Usability: Adapting Research Approaches for Agile Development, Conference on Human Factors in Computing Systems, CHI '08 extended abstracts on Human factors in computing systems, Florence, Italy, PANEL SESSION: Panels, pp , ACM New York, NY, USA, 5-10April [183] Julio Ariel Hurtado Alegr ıa and Mar ıa Cecilia Bastarrica. Implementing CMMI Using a Combination of Agile Methods, CLEI ELECTRONIC Journal, Vol.9, No.1, Paper 7, June [184] Outi Salo. Enabling Software Process Improvement in Agile Software Development Teams and Organizations. Espoo VTT Publications p. + app.96 p. VTT Technical Research Centre of Finland, Academic Dissertation, Faculty of Science, University of Oulu, Auditorium L10, Linnanmaa, 12January2007. [185] Asif Qumer, Brian Henderson-Sellers and Tom McBride. Agile Adoption and Improvement Model. Proceedings European and Mediterranean Conference on Information Systems (EMCIS2007), Polytechnic University of Valencia, Spain, June web: [186] Martin Fritzsche and Patrick Keil. Agile Methods and CMMI: Compatibility or Conflict?. E-Informatica Software Engineering Journal, Vol.1, Issue.1, [187] Stefan Wagner and Florian Deissenboeck. An Integrated Approach to Quality Modelling, Fifth International Workshop on Software Quality (WoSQ'07), ICSE Workshops, IEEE, Minneapolis, MN, May

207 [188] J. E. Gaffney, Jr. Metrics in Software Quality Assurance, ACM Annual Conference/Annual Meeting, Proceedings of the ACM '81 conference, pp , ACM New York, NY, USA, 9-11November1981. [189] Sharon Wheeler and Sheryl Duggins. Improving Software Quality, ACM Southeast Regional Conference, Proceedings of the 36th annual Southeast regional conference, pp , ACM New York, NY, USA, [190] D. Rodriguez, R. Harrison and M. Satpathy. A Generic Model and Tool Support for Assessing and Improving Web Processes, Proceedings of the Eighth IEEE Symposium on Software Metrics (METRICS.02), pp , [191] Jonas Anderson and Pontus Johnson. Architectural Integration Styles for Large-Scale Enterprise Software Systems, Proceedings of Fifth IEEE International on Enterprise Distributed Object, Computing Conference (EDOC '01). pp , Seattle, WA, USA, [192] Sven Ziemer, Tor Stålhane, and Magnar Sveen. Trade-off Analysis in Web Development: An experiment on the use of QFD, International Conference on Software Engineering, Proceedings of the third workshop on Software quality (3-WoSQ 05), St. Louis, Missouri, SESSION: Quality tools and techniques II, pp.70 75, ACM New York, NY, USA, 17May2005. [193] Stefan Wagner and Michael Meisinger. Integrating a Model of Analytical Quality Assurance into the VModellXT, Foundations of Software Engineering, Proceedings of the 3rd international workshop on Software quality assurance(soqua 06)., Portland, Oregon, SESSION: Metrics for quality assurance, pp.38-45, ACM New York, NY, USA, 6November2006. [194] Wolfgang Zuser, Stefan Heil and Thomas Grechenig. Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study, International Conference on Software Engineering, Proceedings of the third workshop on Software quality (3-WoSQ 05), St. Louis, Missouri, SESSION: Quality process improvement and methodologies, pp.1-6, ACM New York, NY, USA, 17May2005. [195] Matthias Heindl and Stefan Biffl. Risk Management with Enhanced Tracing of Requirements Rationale in Highly Distributed Projects. International Conference on Software Engineering, Proceedings of the 2006 international workshop on Global software development for the practitioner (GSD 06), Shanghai, China, SESSION: Project management, pp.20-26, ACM New York, NY, USA, 23May2006. [196] Christopher Davey and Jon Friedman. Software Systems Engineering with Model-Based Design, International Conference on Software Engineering, Proceedings of the 4th International Workshop on Software Engineering for Automotive (SEAS'07), Page.7, IEEE Computer Society Washington, DC, USA, [197] Félix García, Mario Piattini, Francisco Ruiz, Gerardo Canfora and Corrado A. Visaggio. FMESP: Framework for the Modeling and Evaluation of Software Processes. Workshop QUTE-SWAP@ACM /SIGSOFT-FSE12, Newport Beach, CA, USA, ACM, 5November

208 [198] Ayaz Farooq and Reiner R. Dumke. Research Directions in Verification & Validation Process Improvement, ACM SIGSOFT Software Engineering Notes, Vol.32, No.4, ACM New York, NY, USA, July [199] Melanie Ruhe, Ross Jeffery and Izabella Wieczorek, Cost Estimation for Web Applications, IEEE, Proceedings. 25th International Conference on Software Engineering, pp , 3-10 May [200] Autcha Mutchalintungkul, Juthamas Oonhawat, Kittiphong Pholpipatanaphong, Daricha Sutivong and Nakornthip Prompoon. Experience from Applying RIM to Educational ERP Development, International Conference on Software Engineering, Proceedings of the 28th international conference on Software engineering (ICSE'06), Shanghai, China, POSTER SESSION: Far east experience papers: posters, pp , ACM New York, NY, USA, 20-28May2006. [201] Deb Jacobs. Requirements Engineering So Things Don t Get Ugly. International Conference on Software Engineering, Companion to the proceedings of the 29th International Conference on Software Engineering (ICSE'07 Companion), pp , IEEE Computer Society Washington, DC, USA, [202] Daniel Galin, Software Quality Assurance: From Theory to Implementation, Pearson Addison Wesley, Pearson Education Limited, England, [203] Darroch, jenny. Developing Measure of Knowledge Management Behaviors and Practices, Journal of knowledge management, Vol.7, No.5, pp41-54, Dorrach, [204] Omaima N. Al-Allaf, Guidelines for Using MultiMedia in Web Page and User Interface Design, CSIT2006, Amman-Jordan, Vol.3, pp , 5-7April

209 Appendix (A) Questionnaire to Select the Large Jordanian Enterprises Specialized in Developing Large-Scale Web-Based Applications CIS-Phd Student: Omaima Nazar Ahmad AL-Allaf Faculty of Information Systems and Technology The Arab Academy for Banking and Financial Sciences, Amman- Jordan This questionnaire is a part of PHD research and it is designed to investigate the characteristics of Jordanian enterprises specialized in developing web-based applications. This questionnaire is aim to help in selecting only large Jordanian enterprises specialized in developing large-scale web-based applications to be our PHD population study. So we need your help to fill out the following questionnaire. (This Questionnaire is for studying objectives only) Researcher Omaima AL-Allaf 191

210 A-Characteristics of Web-Based Applications Developed by the Enterprise 1- What is the size of the web-based applications developed by your enterprise? Small scale Medium scale Large scale 2- What are the factors that your enterprise used to measure the size of web-based applications? Number of requirements Number of functions that the web-based application delivered to customers Number of developers Number of programming languages used to program the web-based application Size of Budget Time required to develop the web-based application Number of lines (code) in program Number of web pages Number of companies to develop the web-based application 3- How many functions that the developed web-based application provide to users? 10 or less Between 11 and 25 Between 26 and and more 4- How many developers in your enterprise? 10 or less Between 11 and 25 Between 26 and and more 5- What are the numbers of programming languages used by your enterprise developers to code the web-based application? Only one programming language Two programming language Three programming language More than three programming languages 6- What is the budget or budget range of your enterprise? 192

211 7- What is the average time that your enterprise required to develop web-based application? Less than one year More than one year and less than two years More than two years and less than three years More than three years and less than four years More than four years 8- How many numbers of program statements of web-based application that was developed by your enterprise? Less than 5000 lines of code Between 5000 and lines of code Between and lines of code Between and lines of code Between and lines of code Between and lines of code Between and lines of code Between and lines of code More than one million lines of code 9- How many numbers of web pages in web-based application that was developed by your enterprise? 10 or less Between 11 and 25 Between 26 and and more 10- Is the development process of web-based application accomplished only in your enterprise? Yes, the development process only inside the enterprise. No, the enterprise use outsourcing from other(s) company (s). 11- Is the company has branches or it is related to another company? It is a single company. It is related to another company. It has many branches. Please how many. B-Characteristics of the Web-Based Applications Development Process in the Enterprise 1- Please mark all the software development methodologies that your enterprise utilized. (Please mark as many boxes as apply) Ad Hoc and depending on the experiences of developers. Waterfall Software Process Model. Incremental and Evolutionary Software Process Model. Rational Unified Process. 193

212 Object-Oriented Process Model. Web Engineering Process Model. 2- Did your enterprise use agile methodologies during the development process? Did not use any agile methodologies. Extreme Programming (XP). SCRUM. Dynamic System development Method (DSDM). Agile Modeling. 3- What was the methodology used by your enterprise for requirement elicitation? Ad Hoc and depending on the experiences of developers. Build and Fix. Throwaway prototype. Another software process for requirement engineering. 4- What was the methodology used to manage the large number of requirements? No methodology (Ad Hoc) and depend on the experiences of developers. Classifying the requirements into classes. 5- Did your enterprise involve the customers and users during the development process? Involved customers and users during requirement gathering phase only. Involved customers and users throughout the overall development process. 6- Did your enterprise developers considered risk analysis during the development process? No Yes 7- How many numbers of development teams during the development process? Only one team Set of sub teams according to the complexity and size of web-based application 8- Is there management team in your enterprise? No Yes 9- Did the developers divide the web-application into sub systems? No toke the web-based application as a whole. Yes and assigned all the sub systems to only one team and work in incremental fashion. Yes and assigned each one of sub system to one team and work in parallel. 194

213 Appendix (B) Questionnaire Related to Large-Scale Web-Based Applications Development in Large Jordanian Enterprises CIS-PhD Student: Omaima Nazar Ahmad AL-Allaf Faculty of Information Systems and Technology The Arab Academy for Banking and Financial Sciences Amman- Jordan This questionnaire is a part of PHD research and it is designed to investigate the properties of software engineers, web developers and development process in the large Jordanian enterprises specialized in developing large-scale web-based applications. This questionnaire is aim to help in constructing web engineering process model that is more suitable for large Jordanian enterprises and to overcome as possible as the problems of development process in these enterprises. So we need your help to fill out the following questionnaire. (This Questionnaire is for studying objectives only) Researcher Omaima AL-Allaf 195

214 Section I: Respondent Background (6 Questions) 1. Which best describes your current position (s)? (Please mark as many boxes as apply) Project or Team Leader Manager Technical Member Software Engineering Process Group (SEPG) Member 2. On what activities do you currently work? (Please mark as many boxes as apply) Software Requirements Software Design Code and Unit Test Software Quality Assurance Configuration Management Software Process Improvement Test and Integration 3. Have you received any Capability Maturity Model Integration(CMMI)-related training? No Yes 4. Have you participated in previous forms of Software Process Assessments, Software Capability Evaluations, and/or other forms of Software Process Appraisals? (Please mark one box) No Yes How many? (Please specify for each category) Number of SPAs (Software Process Assessments) Number of SCEs (Software Capability Evaluations) Number of other SEI (Software Engineering Institute)- Based methods Please describe What is your software experience? (Please specify for each category) In your present organization? In your overall software experience? Years Years 6. What is your level of experience with Web-based Applications Development? (Please mark one box) Know very little about web application Basic knowledge of web applications development Advanced knowledge of web applications development No knowledge of web applications development 196

215 Section II: (Development and Test Methods) (8 Questions) 1. How big is your organization? (Please mark one box) Between 50 and 75 people Between 76 and 100 people More than 100 people 2. Application Domain (Please mark as many boxes as apply) Business information systems (general) E-banking E-commerce E-learning Web engineering tools Personal web pages E-business (general) 3. Web based applications development involves: (Please mark as many boxes as apply) In-house development Outsourcing Reusability 4. Which of these software development methodologies are you familiar with? (Please mark as many boxes as apply) Flowcharting Waterfall Structured programming Structured Systems Analysis & Design (SSADM) Information Engineering (IE/IEM) Top-down programming Jackson Structured Programming Personal web pages Dynamic Systems Development Object-Oriented Programming (OOP) Agile Unified Process (AUP) Virtual finite state machine (VFSM) Spiral RAD Rational Unified Process (RUP) Extreme Programming (XP) Praxis Test-Driven Development (TDD) Enterprise Unified Process (EUP) Agile methodologies (other than XP) Rapid Application Development Other (please specify) 197

216 5. Please mark all the software development methodologies that your firm utilizes. (Please mark as many boxes as apply) Flowcharting Waterfall Structured programming Structured Systems Analysis & Design (SSADM) Information Engineering (IE/IEM) Top-down programming Jackson Structured Programming Personal web pages Dynamic Systems Development Object-Oriented Programming (OOP) Rational Unified Process (RUP) Enterprise Unified Process (EUP) Agile Unified Process (AUP) Extreme Programming (XP) Agile methodologies (other than XP) Virtual finite state machine (VFSM) Praxis Rapid Application Development Spiral RAD Test-Driven Development Other (please specify) 6. Which kinds of tests are required by your organization? (Please mark as many boxes as apply) Unit tests Integration tests Code coverage tests Acceptance tests Database tests Web metrics Performance tests No tests are required 7. For Web-based Applications that you are involve in, what assurance activities are performed? (Please mark as many boxes as apply) Testing of Web-based Applications Code review (formal or informal) Development process audit Configuration management audit Functional Configuration Audit Physical Configuration Audit Version Description Document No assurance activities are performed 8. For Web-based Applications that you are involved in, who performs the assurance activities? Project team Software Assurance Group Other Assurance Group (outside) Others (please specify). 198

217 Section III: Description on of Possible Symptoms at your Organization There are may be many symptoms (problems) that your organization faced during the development process of web based applications. Please determine the severity score of each symptom and the occurrence frequency of this symptom (by select value between 1 and 5) Score Severity Score Description Occurrence Frequency Score Description 5 Huge or catastrophic negative effect on the success of our projects Always or almost always Occurs 4 Large negative effect Usually Occurs 3 Significant negative effect Often Occurs 2 Small negative effect Sometimes Occurs 1 Trace or no negative effect on the success of our projects Rarely or never Occurs No Symptoms 1 Delivery dates which were originally promised are not met. 2 The scope, design, planned implementation methods, timing, etc. change significantly during the project. 3 Necessary things (eg. info, specs, materials, authorization, drawings, etc.) are not available on-time or when needed. 4 There are discussions &/or disagreements about priority of different or competing projects. 5 There are large variations between our quoted vs. As-built costs. Our planned profits suffer, or we risk being perceived as taking unfair profits (gouging our customers). 6 We have quality problems. There is too much re-designing, re-work, scrap, miscommunication, unnecessary details, customer complaints, warranty, returns, etc. 7 Some tasks can only be done by a few, key individuals. 8 Some steps, systems, resources, or processes are critical bottlenecks that hurt the entire operation due to their limited capacity. 9 Work expands to fill the time available to our project workers. 10 A project s assigned resources are moved to another pressing need during the project 11 There is a shortage of skilled people & resources for our projects 12 We don t realize all the issues & potential problems until it's too late (or almost too late). 13 We have a few big holes, and many small holes in our skills, knowledge, attitude, & capabilities needed for the project. 14 Too many tasks get assigned to too few people. 15 There is poor prioritization of the various projects &/or tasks. 16 Available resources are not used effectively. 17 Current project methods &systems are so historical and accepted; they are difficult to change. 18 Projects are abandoned before completion. Significant resources were spent with little or no benefit. 19 Projects suffer from delays & schedule conflicts. 20 Costs, resources, & benefits for important projects are estimated so pessimistically that the idea is abandoned. 21 Suppliers &/or sub-contractors don t live up to their commitments. 22 There is lack of teamwork &/or co-operation within project teams. 23 The project plan is significantly different from reality, but official plan changes are not made. 24 The same project problems keep happening again & again; we never seem to stop & fix. 25 We waste time & resources during implementation phase because of insufficient planning. Severity (1-5) Occurrence Frequency (1-5) 199

218 Section IV: Web Engineering Practices No. Part 1 - Organizational Issues (8 questions) Question 1.1 Does each web project have a nominated web project manager? 1.2 Does the web project manager report to a business project manager responsible for the overall benefit of the project to the business? 1.3 Does a web Quality Assurance (WQA) function exist within an independent reporting line from web development project management? 1.4 Is a change control function established for each web project? 1.5 Is there a required training program for all newly-appointed web managers which is designed to familiarize them with in-house web project management procedures? 1.6 Is there a procedure for maintaining awareness of the state-of-the-art in CASE of web engineering technology? 1.7 Is there a procedure for ensuring that appropriate levels of user/customer/marketing input are made throughout the project? 1.8 Where other non-web resources are critical to the success of the project is there a procedure for ensuring their availability according to plan? Yes No Does Not apply Don t know Part 2 - Standards and Procedures (13 questions) No. Question Yes No 2.1 Does management formally assess the benefits, viability, and risk of each web project prior to making contractual (or internal) commitments? 2.2 Does management formally conduct periodic reviews of status of each web project? 2.3 Are there procedures to ensure that external web development subcontracting organizations, if any, follow a disciplined software development process? 2.4 For each project, are independent audits (such as inspections or walkthroughs) conducted for each major stage in the web development process? 2.5 Are common coding standards applied to each web project? 2.6 Is there a documented procedure for estimating web applications size (such as "Lines of Source Code") and thus for using productivity measures? 2.7 Is a formal procedure used to produce web development effort, schedule, and cost estimates? Is a formal procedure (such as a review or handover with sign-off) used whenever a 2.8 deliverable (such as a user statement of requirements or system requirements) is passed from one discrete group to another (e.g. user to analyst to designer) to ensure it is properly understood? 2.9 Is there a mechanism to ensure that the systems projects selected for development qualitatively or quantitatively support organization s business objective/problems? 2.10 Are there procedures to ensure that the functionality, strengths, and weaknesses of the system" which the web application is replacing are formally reviewed? 2.11 Does test planning commence prior to programming beginning based on the user requirements and high-level design documents? 2.12 Is independent testing conducted by users (appropriate representatives) under guidance of SW Quality Assurance before any system or enhancement goes live? Is there a procedure to check that the system configuration (i.e. the programs and 2.13 any data) passing user acceptance testing is the same as that which is implemented for live operation and that no changes are made directly to a "live" version of any system (other than through modification to its development version)? Does Not apply Don t know 200

219 Part 3 -Web Metrics (8 questions) Web Metrics helps organizations to understand, manage and improve quality of web applications. No Question Yes No Are records of actual project resourceing and timescales versus estimates maintained (at individual resource) and analyzed/fed-back into estimating and scheduling procedures? Are records of web application size maintained for each web application configuration item, over time, and fed-back into the estimating process? Are statistics on the sources of errors in web application code gathered and analysed for their cause, detection and avoidance measures? Are statistics on test efficiency (% of errors actually detected by activity against maximum theoretically possible) gathered and analyzed for test stages in development process? Is "earned value" project tracking used throughout the web development process (actual versus planned deliverables analyses, designed, unit tested, system tested, acceptance tested over time) to monitor project progress? Are estimates made and compared with accruals for target computer performance (e.g. memory utilization, processor throughput and file/channel I/O and disk usage)? Are post-implementation software problem reports logged and their resolution effectively tracked and analyzed? Do records exist from which (and requiring nothing extra) all current versions and variants of web systems and their components can be quickly and accurately reconstructed in the development environment? Does Not apply Don t know Part 4 - Control of the Development Process (6 questions) No. Question Yes No 4.1 Are estimates, schedules and subsequent changes produced only by the project managers who directly control the project resources and are fully aware of their abilities and availabilities? 4.2 Does the overall business project manager gain agreement and sign-off from all parties who have produced detailed estimates and schedules before publishing or revising project plan? 4.3 Is there a procedure for controlling changes to the web applications requirements, designs and accompanying documentation? 4.4 Is there a procedure for controlling changes to the code and specifications? 4.5 Is there a mechanism for assuring that regression testing (forced re-run of all previous tests prior to any new tests) is routinely performed during and after initial implementation? 4.6 Do procedures exist to ensure that every required function is tested/ verified? Part 5 - Tools and Technology (7 questions) No. Question Yes No 5.1 Are software tools used to assist in forwards and/or backwards tracing of web application requirements to web designs through to code? 5.2 Are design notations used in web based applications design? 5.3 Are automated testing tools used (for example for capturing and replaying tests 5.4 Are software tools used for tracking and reporting the status of the web applications? 5.5 Are prototyping methods used in ensuring requirements elements of web applications? 5.6 Is a data dictionary available for control and store details of all data files and their fields? 5.7 Are software tools used for web project planning, estimating, scheduling, and critical path analysis? Does Not apply Does Not Apply Don t know Don t Know 201

220 Appendix (C) Questionnaire in Large Web Development Jordanian Enterprises To Analyze the Coverage of CMMI Process Areas in Proposed Hybrid Web Engineering Model CIS-PhD Student: Omaima Nazar Ahmad AL-Allaf Faculty of Information Systems and Technology The Arab Academy for Banking and Financial Sciences Amman- Jordan This questionnaire is a part of PHD research. It is designed to ask the project managers, team leaders, and web developers worked in the large web development Jordanian enterprises to check and analyze the compatibility of proposed Hybrid Model with the CMMI key process areas. The CMMI process areas are listed in this questionnaire as questions. This questionnaire is aim to help finding the accurate position of Hybrid Model in CMMI levels. So we need your help to clearly read the suggested Hybrid model steps attached with this questionnaire, and then to fill out this questionnaire. (This Questionnaire is for studying objectives only) Researcher Omaima AL-Allaf 202

221 ---- CMMI ML Process Areas, Specific Goals and Practices Yes No Requirements Management Don t Know SG 1 SG 1 SG 2 SG 3 SG 1 SG 2 SP 1.1 Obtain an understanding of requirements Sp 1.2 Obtain Commitment to requirements SP 1.3 Manage requirement changes SP 1.4 Maintain bidirectional traceability of requirements SP 1.5 Identify inconsistencies between project work and requirements Project Planning SP 1.1 Estimate the scope of the project SP 1.2 Establish estimates of work product and task attributes SP 1.3 Define project lifecycle SP 1.4 Determine estimates of effort and cost SP 2.1 Establish the budget and schedule SP 2.2 Identify project risks SP 2.3 Plan for data management SP 2.4 Plan for project resources SP 2.5 Plan for needed knowledge and skills SP 2.6 Plan stakeholder involvement SP 2.7 Establish the project plan SP 3.1 review plans that that affect the project SP 3.2 Reconcile work and resource levels SP 3.3 Obtain Plan commitment Project Monitoring and Control SP 1.1 Monitor project planning parameters SP 1.2 Monitor commitments SP 1.3 Monitor project risks SP 1.4 Monitor data management SP 1.5 Monitor stakeholder involvement SP 1.6 Conduct progress reviews SP 1.7 Conduct milestone reviews SP 2.1 Analyze Issues SP 2.2 Take corrective actions 203

222 SG 1 SG 2 SG 1 SG 2 SG 1 SG 2 SG 1 SG 2 SG 3 SP 2.3 Manage corrective actions Supplier Agreement management Yes No SP 1.1 Determine Acquisition Type SP 1.2 Select Suppliers SP 1.3 Establish Supplier Agreements SP 2.1 Review COTS Products SP 2.2 Execute the Supplier Agreement SP 2.3 Accept the Acquired Product SP 2.4 Transition Products Measurement and analysis SP 1.1 Establish measurement Objectives SP 1.2 Specify measures SP 1.3 Specify data collection and Storage procedures SP 1.4 Specify analysis procedures SP 2.1 Collect measurement data SP 2.2 Analyze measurement data SP 2.3 Store data and results SP 2.4 Communicate results Process and Product Quality Assurance SP 1.1 Objectively Evaluate Processes SP 1.2 Objectively Evaluate Work Products and Services SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues SP 2.2 Establish Records Configuration Management SP 1.1 Identify configuration items SP 1.2 Establish a configuration management system SP 1.3 Create or release baselines SP 2.1 Track change requests SP 2.2 Control configuration items SP 3.1 Establish configuration Management records SP 3.2 Perform configuration audits Don t Know 204

223 CMMI ML3 Process Areas, Specific Goals and Practices Yes No Requirements Development SG 1 SP 1.1 Elicit Needs SP 1.2 Develop the Customer Requirements SP 2.1 Establish Product and Product-Component Requirements SG 2 SP 2.2 Allocate Product-Component Requirements SP 2.3 Identify Interface Requirements SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality SG 3 SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements with Comprehensive Methods Technical solution SP 1.1 Develop Detailed Alternative Solutions and Selection Criteria SG 1 SP 1.2 Evolve Operational Concepts and Scenarios SP 1.3 Select Product-Component Solutions SP 2.1 Design the Product or Product Component SP 2.2 Establish a Technical Data Package SG 2 SP 2.3 Design Interfaces Using Criteria SP 2.4 Perform Make, Buy, or Reuse Analyses SP 3.1 Implement the Design SG 3 SP 3.2 Develop Product Support Documentation Don t Know Product Integration SP 1.1 Determine Integration Sequence Yes No Don t Know SG 1 SP 1.2 Establish the Product Integration Environment SP 1.3 Establish Product Integration Procedures and Criteria SG 2 SP 2.1 Review Interface Descriptions for Completeness SP 2.2 Manage Interfaces SP 3.1 Confirm Readiness of Product Components for Integration SG 3 SP 3.2 Assemble Product Components SP 3.3 Evaluate Assembled Product Components SP 3.4 Package and Deliver the Product or Product Component 205

224 Verification SP 1.1 Select Work Products for Verification Yes No Don t Know SG 1 SP 1.2 Establish the Verification Environment SP 1.3 Establish Verification Procedures and Criteria SP 2.1 Prepare for Peer Reviews SG 2 SP 2.2 Conduct Peer Reviews SP 2.3 Analyze Peer Review Data SG 3 SP 3.1 Perform Verification SP 3.2 Analyze Verification Results and Identify Corrective Action Validation SP 1.1 Select Products for Validation Yes No Don t Know SG 1 SP 1.2 Establish the Validation Environment SP 1.3 Establish Validation Procedures and Criteria SG 2 SP 2.1 Perform Validation SP 2.2 Analyze Validation Results Organizational Process Focus SP 1.1 Establish Organizational Process Needs Yes No Don t Know SG 1 SP 1.2 Appraise the Organization s Processes SP 1.3 Identify the Organization s Process Improvements SP 2.1 Establish Process Action Plans SG 2 SP 2.2 Implement Process Action Plans SP 2.3 Deploy Organizational Process Assets SP 2.4 Incorporate process-related experiences into organizational process assets Organizational Process Definition Yes No SG 1 SP 1.1 Establish Standard Processes SP 1.2 Establish Life-Cycle Model Descriptions SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization s Measurement Repository SP 1.5 Establish the Organization s Process Asset Library Don t Know 206

225 Organizational Training Yes No SG 1 SG 2 SP 1.1 Establish the Strategic Training Needs SP 1.2 Determine which training needs are the responsibility of organization SP 1.3 Establish an Organizational Training Tactical Plan SP 1.4 Establish Training Capability SP 2.1 Deliver Training SP 2.2 Establish Training Records SP 2.3 Assess Training Effectiveness Don t Know Integrated Project Management Yes No SG 1 SG 2 SP 1.1 Establish the project s defined process SP 1.2 Use Organizational Process Assets for Planning Project Activities SP 1.3 Integrate Plans SP 1.4 Manage the Project Using the Integrated Plans SP1.5 contribute to the organizational process assets SP 2.1 Manage Stakeholder Involvement SP 2.2 Manage Dependencies SP 2.3 Resolve Coordination Issues Don t Know Risk Management Yes No SG 1 SG 2 SG 3 SP 1.1 Determine Risk Sources and Categories SP 1.2 Define Risk Parameters SP 1.3 Establish a Risk Management Strategy SP 2.1 Identify Risks SP 2.2 Evaluate, Categorize, and Prioritize Risks SP 3.1 Develop Risk Mitigation Plans SP 3.2 Implement Risk Mitigation Plans Don t Know Decision Analysis and resolution SP 1.1 Establish Guidelines for Decision Analysis Yes No Don t Know SP 1.2 Establish Evaluation Criteria SG1 SP 1.3 Identify Alternative Solutions SP 1.4 Select Evaluation Methods SP 1.5 Evaluate Alternatives SP 1.6 Select Solutions 207

226 Maturity Level 4 (2 Process Areas) Maturity Level 4 process areas Yes No Don t Know 1 Organizational Process Performance (OPP) 2 Quantitative Project Management (QPM) Maturity Level 5 (2 Process Areas) Maturity Level 5 process areas Yes No Don t Know 1 Organizational Innovation and Deployment (OID) 2 Causal Analysis and Resolution (CAR) 208