A Closer Look at Extreme Programming (XP) with an Onsite-Offshore Model to Develop Software Projects Using XP Methodology

Author(s):  
Ponmurugarajan S. Thiyagarajan ◽  
Sachal Verma
Author(s):  
D. Berry

Open source software (OSS) is computer software that has its underlying source code made available under a licence. This can allow developers and users to adapt and improve it (Raymond, 2001). Computer software can be broadly split into two development models: • Proprietary, or closed software, owned by a company or individual. Copies of the binary are made public; the source code is not usually made public. • Open-source software (OSS), where the source code is released with the binary. Users and developers can be licenced to use and modify the code, and to distribute any improvements they make. Both OSS and proprietary approaches allow companies to make a profit. Companies developing proprietary software make money by developing software and then selling licences to use the software. For example, Microsoft receives a payment for every copy of Windows sold with a personal computer. OSS companies make their money by providing services, such as advising clients on the GPL licence. The licencee can either charge a fee for this service or work free of charge. In practice, software companies often develop both types of software. OSS is developed by an ongoing, iterative process where people share the ideas expressed in the source code. The aim is that a large community of developers and users can contribute to the development of the code, check it for errors and bugs, and make the improved version available to others. Project management software is used to allow developers to keep track of the various versions. There are two main types of open-source licences (although there are many variants and subtypes developed by other companies): • Berkeley Software Distribution (BSD) Licence: This permits a licencee to “close” a version (by withholding the most recent modifications to the source code) and sell it as a proprietary product; • GNU General Public Licence (GNU, GPL, or GPL): Under this licence, licencees may not “close” versions. The licencee may modify, copy, and redistribute any derivative version, under the same GPL licence. The licencee can either charge a fee for this service or work free of charge. Free software first evolved during the 1970s but in the 1990s forked into two movements, namely free software and open source (Berry, 2004). Richard Stallman, an American software developer who believes that sharing source code and ideas is fundamental to freedom of speech, developed a free version of the widely used Unix operating system. The resulting GNU program was released under a specially created General Public Licence (GNU, GPL). This was designed to ensure that the source code would remain openly available to all. It was not intended to prevent commercial usage or distribution (Stallman, 2002). This approach was christened free software. In this context, free meant that anyone could modify the software. However, the term “free” was often misunderstood to mean no cost. Hence, during the 1990s, Eric Raymond and others proposed that open-source software was coined as a less contentious and more business-friendly term. This has become widely accepted within the software and business communities; however there are still arguments about the most appropriate term to use (Moody, 2002). The OSMs are usually organised into a network of individuals who work collaboratively on the Internet, developing major software projects that sometimes rival commercial software but are always committed to the production of quality alternatives to those produced by commercial companies (Raymond, 2001; Williams, 2002). Groups and individuals develop software to meet their own and others’ needs in a highly decentralised way, likened to a Bazaar (Raymond, 2001). These groups often make substantive value claims to support their projects and foster an ethic of community, collaboration, deliberation, and intellectual freedom. In addition, it is argued by Lessig (1999) that the FLOSS community can offer an inspiration in their commitment to transparency in their products and their ability to open up governmental regulation and control through free/libre and open source code.


Author(s):  
Fabrizio Fioravanti

One of the emerging techniques for managing software project is eXtreme Programming (XP), which surely is changing the way in which we develop and manage software. XP is based on four values and 12 rules that explain how to develop software in an XP-compliant mode. In this chapter, all values and rules are addressed and the XP lifecycle of a project is introduced in order to guide the reader in discovering how XP can aid maintenance by keeping maintenance costs constant over time. Before drawing conclusions, the direct impact on the maintenance process due to the adoption of XP values and rules is also exploited at the end of the chapter.


2022 ◽  
pp. 163-182
Author(s):  
Kamalendu Pal

Agile software development methodologies are attracting attention from academics and practitioners for planning and managing software projects. The eXtreme Programming (XP) challenges conformist wisdom regarding software system development processes and practices as agile methodologies. To work efficiently in the current software development practice, characterized by requirements fuzziness, XP moves away from document-centric operations into people-centric management. In the XP-based software project, the customers play an essential role, having multiple responsibilities such as driving the project, gathering requirements (‘user stories'), and exercising quality control (or acceptance testing). Besides, the customers must liaise with external project stakeholders (e.g., funding authorities, end-users) while maintaining the development team's trust and the wider business. The success of such software project management practices relies on the quality result of each stage of development obtained through rigorous testing. This chapter describes three characteristics of XP project management: customer role, software testing feedback, and learning.


2011 ◽  
pp. 1171-1176
Author(s):  
David Berry

Open source software (OSS) is computer software that has its underlying source code made available under a licence. This can allow developers and users to adapt and improve it (Raymond, 2001). Computer software can be broadly split into two development models: • Proprietary, or closed software, owned by a company or individual. Copies of the binary are made public; the source code is not usually made public. • Open-source software (OSS), where the source code is released with the binary. Users and developers can be licenced to use and modify the code, and to distribute any improvements they make. Both OSS and proprietary approaches allow companies to make a profit. Companies developing proprietary software make money by developing software and then selling licences to use the software. For example, Microsoft receives a payment for every copy of Windows sold with a personal computer. OSS companies make their money by providing services, such as advising clients on the GPL licence. The licencee can either charge a fee for this service or work free of charge. In practice, software companies often develop both types of software. OSS is developed by an ongoing, iterative process where people share the ideas expressed in the source code. The aim is that a large community of developers and users can contribute to the development of the code, check it for errors and bugs, and make the improved version available to others. Project management software is used to allow developers to keep track of the various versions. There are two main types of open-source licences (although there are many variants and subtypes developed by other companies): • Berkeley Software Distribution (BSD) Licence: This permits a licencee to “close” a version (by withholding the most recent modifications to the source code) and sell it as a proprietary product; • GNU General Public Licence (GNU, GPL, or GPL): Under this licence, licencees may not “close” versions. The licencee may modify, copy, and redistribute any derivative version, under the same GPL licence. The licencee can either charge a fee for this service or work free of charge. Free software first evolved during the 1970s but in the 1990s forked into two movements, namely free software and open source (Berry, 2004). Richard Stallman, an American software developer who believes that sharing source code and ideas is fundamental to freedom of speech, developed a free version of the widely used Unix operating system. The resulting GNU program was released under a specially created General Public Licence (GNU, GPL). This was designed to ensure that the source code would remain openly available to all. It was not intended to prevent commercial usage or distribution (Stallman, 2002). This approach was christened free software. In this context, free meant that anyone could modify the software. However, the term “free” was often misunderstood to mean no cost. Hence, during the 1990s, Eric Raymond and others proposed that open-source software was coined as a less contentious and more business-friendly term. This has become widely accepted within the software and business communities; however there are still arguments about the most appropriate term to use (Moody, 2002). The OSMs are usually organised into a network of individuals who work collaboratively on the Internet, developing major software projects that sometimes rival commercial software but are always committed to the production of quality alternatives to those produced by commercial companies (Raymond, 2001; Williams, 2002). Groups and individuals develop software to meet their own and others’ needs in a highly decentralised way, likened to a Bazaar (Raymond, 2001). These groups often make substantive value claims to support their projects and foster an ethic of community, collaboration, deliberation, and intellectual freedom. In addition, it is argued by Lessig (1999) that the FLOSS community can offer an inspiration in their commitment to transparency in their products and their ability to open up governmental regulation and control through free/libre and open source code.


Author(s):  
Naresh E. ◽  
Vijaya Kumar B.P.

The article tries to shed some light on the impact of human psychology on the effective use of pair programming in the modern Software development lifecycle such as SCRUM, Extreme Programming which are in turn used on heterogeneous software projects. This article also tries to identify that if the authors try to pair people keeping their psychology in mind that pair can come up with code with fewer defects, with efficient code, if the paper tries to pair people randomly without any planning or thinking might create a pair which let aside create inefficient code and lead to be unproductive nature, and even it will create a negative impact on the project and the team. This article introduces a few novel approaches in framing the pairs in pair programming's like known and unknown pairs, coder and reviewer pair and coder and tester pair. Applying the described approaches, an industry can improve the quality of the delivered product and improve the efficiency of software engineers.


2019 ◽  
Vol 62 (11) ◽  
pp. 1605-1624 ◽  
Author(s):  
Muhammad Adnan ◽  
Muhammad Afzal ◽  
Khadim Hussain Asif

Abstract Presently, software industry is severely suffering from inaccurate effort estimation and inadequate unstructured or semi-structured project history management. In fact, both are difficult to accomplish and hence badly impact the software projects. We proposed improvements in the effort estimation and the project history management of e-commerce projects focusing on Extreme Programing (XP) and Scrum methodologies using ontology models in our software effort estimation system. Proposed system infers suitable estimate in the form of time, resources and lessons learnt as per the project leader’s requirements by using description logic and HermiT reasoner. To validate our approach, we have performed a case study comprising 20 Business-to-Consumer (B2C) web projects and performed comparative analysis on the collected efforts in both XP and Scrum contexts by applying (Mean Magnitude of Relative Error) MMRE and PRED(25) prediction accuracy measures. Likewise, software functional size of understudy e-commerce projects was measured using COSMIC functional size measurement methodology. Regression analysis of relations among actual COSMIC function points, estimated effort, and actual effort spent for the projects show better significance-F and R2 values for our approach. The comparative results show that overall proposed approach provides accurate estimates and significantly improves over planning poker and delphi methods by 10% and 30%, respectively.


2020 ◽  
Vol 3 (1) ◽  
Author(s):  
Diana Lazarova ◽  
◽  
Mariyana Nikolova ◽  
◽  

This paper presents the life cycle of the process of developing software projects by students. It outlines the theoretical basis of the projects as the modern technology. The suggested life cycle, in which students play the role of junior software developers, results in the acquisition of diverse knowledge and practical skills that contribute to their personal growth. The article also describes the process of students forming and developing digital skills and key competences as they develop software projects. The life cycle in question prepares them for success in the everchanging, dynamic life, because it enables them to develop qualities that stimulate multi-level thinking and help them show their full potential.


2021 ◽  
Vol 12 (3) ◽  
pp. 1717-1727
Author(s):  
Javed Iqbal Et.al

Agile methodologies are always tends to increase the quality of software and also handling the complex software projects. However, the software companies in Pakistan have recently felt the disparity of producing successful software. In this context, an extensive survey has been conducted in 52 prominent software development companies of Pakistan to identify this remedy and the motivation behind this production discrepancy. It is revealed from the survey that there is a lack of empirical evidence in the relationship of agile methodologies with the effective and progressive management of software project management factors including, schedule, scope, risk, budget, quality and resources. Therefore, the proposed study delivers an extensive statistical comparison to determine the effectiveness of agile methodologies in terms of their effects on the project management factors. The results suggest that in general all agile methodologies play a significant role towards the successful software development in the software company. However, Extreme Programming, Scrum, Kanban and Agile modeling are the main determinants of production disparity among software companies. Furthermore, it is determined that the quality factor has a positive correlation with the rest of the factors. It is also found that the budget factor has significantly correlated with other five factors, while rest of the factors has insignificant correlation. We have also compared agile methodologies in terms of project management factors, which specify that each agile methodology has its own importance and effect with respect to managing different factors of project management.


Sign in / Sign up

Export Citation Format

Share Document