Traditional Software Development Life Cycle Research Articles

A Comprehensive Review of Software Development Life Cycle methodologies: Pros, Cons, and Future Directions

The software development process needs specific and studied steps within a reliable plan to achieve the requirements for the success of any project. Software development life cycle (SDLC) methodologies have provided several models that meet the needs of the various proposed projects. These methodologies present various scenarios that can be applied in the process of developing systems to make them more efficient and predictive. The paper aims to illuminate the paramount Software Development Life Cycle (SDLC) methodologies by conducting a comprehensive review of the pros and cons of the various models widely used for software design. Furthermore, the paper discusses fundamental trajectories that are shaping the future landscape of SDLC methodologies. This review included two main types of software development life cycle approaches such as traditional SDLC (heavy-weight) and agile SDLC (light-weight) approaches. The traditional approach included several models such as the Waterfall model, Iterative model, Spiral model, V-Model, and Big Bang Model. Whereas, the agile approach included various models such as the eXtreme Programming (XP) Model, scrum Model, Feature Driven Development (FDD) Model, and Kanban Model. A comprehensive analytical study of all software development life cycle models was achieved and highlighted their most prominent strengths and weaknesses of them. SDLC methodologies wield substantial ramifications across a multitude of sectors, contingent upon several models tailored to individual developmental and research contexts. In culmination, the paper furnishes an all-encompassing perspective on paramount SDLC models, encompassing two principal paradigms: the traditional and the agile approaches. These encompass fundamental sub-models that encapsulate pioneering models poised for application in system development, thus facilitating their refinement more efficiently and predictably.

Software Development Life Cycle (SDLC) Methodologies for Information Systems Project Management

The software development life cycle (SDLC) is a framework for planning, analyzing, designing, developing, testing, and deploying software. There are many different SDLC methodologies available, each with its advantages and disadvantages. The best methodology for a particular project will depend on factors such as the size and complexity of the project, the availability of resources, and the preferences of the project team. This paper provides an in-depth overview of the different SDLC methodologies used in the industry for IS project management. The paper discusses five significant SDLC methodologies: Waterfall, V-Model, Iterative, Agile, and Hybrid. It also compares and contrasts the traditional SDLC and Agile methodology and discusses using decision support matrices for selecting SDLC methodologies. By providing this comprehensive overview, the paper will help IS practitioners and project managers make informed decisions about the best approach for their specific projects.

Hybrid Project Management between Traditional Software Development Lifecycle and Agile Based Product Development for Future Sustainability

The purpose of this review is to look at the future sustainability of project management by combining agile methodology and product management. Digital transformation is evolving rapidly, and the question is whether traditional project management is sustainable. To ensure sustainability, a hybrid approach is taken by combining agile methodology to ensure the latest trend in software development approaches are maintained. Agile methodologies were crafted in 2000, but it has only been widely used since 2011 for software development. This paper will focus on the types of agile requirements engineering methods used in the agile framework, used and described in various articles, journals, and studies over the last six years, and how this can be applied together with traditional project management.

Construction of a Software Development Model for Managing Final Year Projects in Information Technology Programmes

The final year project (FYP) is considered a capstone course in information technology (IT) programmes and involves the development of a software product. Currently, students are using the traditional software development life cycle approach to manage their FYPs. However, this approach can cause many difficulties. This paper proposes an alternative software development model for managing the FYP in an IT and IT-related degree programmes of study. First, a benchmarking exercise was undertaken to compare the software developed for business purposes with that developed for educational purposes, which took into account the ten project management knowledge areas. The result of this exercise indicated that the differences that exist between business and educational software necessitate the development of a new software development model that is specifically tailored to the development of educational software. Therefore, capability maturity model integration (CMMI) was modified to generate a new version of CMMI – named educational CMMI – which could be used to evaluate educational software projects and detailed mathematical descriptions of the proposed model were composed. As conclusions, the proposed model was then assessed by students’ results and by questionnaire feedback, the results of which showed that the proposed model was both useful and applicable for its intended target users and context.

Modelling Fault Detection Using SRGM in Agile Environment and Ranking of Models

Today's software applications deployed in an enterprise to cater to the complex business processes, integrate various business units and address requirements of a global customer base. The traditional methodology of software engineering succumbs to the changing need of customer and technology advancement. On the behest of the customer, a software system should be designed in a way that it goes in concert with the present user needs. Agile methodology targets complex systems with its iterative, incremental, and evolutionary approach. There are numerous factors attributing towards the successful implementation of agile methodology. This led to adopting an approach of agile based on ‘lean' principles over the traditional software development life cycle (SDLC) approach. Collaborative work is done with the project team on a priority list. The implementation is done through “SCRUM” an empirical framework for learning. It has multiple sprints which are deliverable products. This idea has substantially reduced the ‘time to market' as the customer can decide which features of the software they would like to be delivered on a priority basis. To model trends of fault detection in each sprint, a growth model of software reliability is used. This research article presents a framework to analyze and measure the cumulative errors in an Agile Testing Process, the authors have applied modeling on various SRGMs to prove acceptability in an agile development process and finally compares these models using the Mahalanobis Distance Formula for Model ranking. The Mahalanobis distance criteria is easy to compute and that can be utilized to get the ranks and select the best model in view of an arrangement of contributing criteria.

Emergent Lifecycle: The Tension between Knowledge Change and Knowledge Retention in Open Online Co-Production Communities

Online co-production communities often face a challenge of whether to change or retain the knowledge they have created. Disparate and often conflicting theoretical models have been used to explain how these communities respond to this tension. We conducted a case study of how one online co-production community – the nine-year history of the Wikipedia article on Autism – handles this tension. We find that the nature of the change-retain tension and the community’s response to it fluctuates considerably over the life of the community. These changes bear striking similarities to processes associated with traditional software development lifecycle, despite the absence of traditional control mechanisms. What initially appear to be conflicts in the extant literature actually describe different roles and production focus at the different stages of development. Disruptive events signal the need for the community to shift production focus, which often involves members joining and leaving the production process, rather than adopting new roles.

Factors Influncing Quality of Mobile Apps: Role of Mobile App Development Life Cycle

In this paper, The mobile application field has been receiving astronomical attention from the past few years due to the growing number of mobile app downloads and withal due to the revenues being engendered .With the surge in the number of apps, the number of lamentable apps/failing apps has withal been growing.Interesting mobile app statistics are included in this paper which might avail the developers understand the concerns and merits of mobile apps.The authors have made an effort to integrate all the crucial factors that cause apps to fail which include negligence by the developers, technical issues, inadequate marketing efforts, and high prospects of the users/consumers.The paper provides suggestions to eschew failure of apps. As per the various surveys, the number of lamentable/failing apps is growing enormously, primarily because mobile app developers are not adopting a standard development life cycle for the development of apps. In this paper, we have developed a mobile application with the aid of traditional software development life cycle phases (Requirements, Design, Develop, Test, and, Maintenance) and we have used UML, M-UML, and mobile application development technologies.

A Mapping Model for Transforming Traditional Software Development Methods to Agile Methodology

Agility is bringing in responsibility and ownership in individuals, which will eventually bring out effectiveness and efficiency in deliverables. Agile model is growing in the market at very good pace. Companies are drifting from traditional Software Development Life Cycle models to Agile Environment for the purpose of attaining quality and for the sake of saving cost and time. Nimbleness nature of Agile is helpful in frequent releases so as to satisfy the customer by providing frequent dual feedback. In Traditional models, life cycle is properly defined and also phases are elaborated by specifying needed input and output parameters. On the other hand, in Agile environment, phases are specific to methodologies of Agile - Extreme Programming etc. In this paper a common life cycle ap proach is proposed that is applicable for different kinds of teams. The paper aims to describe a mapping function for mapping of traditional methods to Agile method .

CHUNK: An Agile Approach to the Software Development Life Cycle

ABSTRACT This article introduces a methodology for developing applications incorporating components of Agile development methods with the traditional software development life cycle (SDLC), a.k.a. the “waterfall” model of software development. We look at the causes for failure of software development projects and propose steps in the development process to address many of the root causes of these failures (it would be implausible to state that any development methodology could eliminate the risk of failure). We also provide a critical review of Agile principles and the traditional SDLC. The steps of the new methodology are then described with rationalization for their necessity.

Agile or analytic? Book reviews: Cohn versus Lavi and Kudish

Every now and again a pair of books come on to the market offering interestingly contrasting perspectives on the same area. Since Kent Beck’s dramatic Extreme Programming burst onstage in 2000, there has been a stream of books from the object-oriented software community on the theme of first ‘extreme’ and now ‘agile’ development approaches. These have argued, sometimes roughly and forcefully, that the traditional software development life cycle was too cumbersome and often ineffective. Meanwhile, the more traditional requirements of engineering and systems communities have continued to do their own thing, tutting politely at the behaviour of the young bolsheviks torching outside their institutions. Cohn’s readable book offers a practical introduction to the use of brief scenarios in the form of Kent Beck’s user stories. A user story is just what it says on the tin: it is a short, informal description of how some class of user could interact with and benefit from the proposed software. Is not that exactly what Ivar Jacobson meant to do with his use cases? Sssh! Of course, both scenarios and use cases now have (a range of) different meanings. Cohn is careful to distinguish user stories from these in Chap. 12, ‘What Stories Are Not’. Something that is particularly welcome is recognition that there are many kinds of user; Cohn suggests brainstorming possible kinds, perhaps an odd choice of technique here, but much better than just assuming that all users are rather like programmers. And that is not all; Cohn shows in a practical way with examples and advice how to use stories to drive software development, so the book in fact covers all the early part of the life cycle, and even strays into XP to show how the whole cycle works. But instead of shouting in the streets, Cohn ventures inside the requirements literature, and reflects in a fresh and practical way on what is good and not so good in the tradition. First to go is vague talk of ‘‘elicitation’’ or ‘‘capture’’ (several well-known books are criticised at this point): requirements do not run about by themselves, nor are they waiting fully formed inside people’s heads just to be elicited. The Robertsons’ ‘‘trawling’’ is however taken up with enthusiasm: you would not catch all the requirements in one trawl, so the process is inevitably iterative—which chimes well with the agile theme. We may argue that we knew it was iterative already, but far too many projects were not; and it is really welcome to see the Agile community engaging with the ongoing debate. However, Chap. 12 of Cohn also attacks traditional IEEE 830-style requirements as

Continuous evolutionary one-step-ahead testing

The traditional software development life cycle considers testing to be an activity that occurs between the implementation phase of development and software release [4]. With this approach any testing subsequent to release is done in reaction to failures reported by software users. The realities of software in operation however causes questions about this approach to arise. Adams [1] showed that organizations developing significant software applications often provide several fixes after their software has been released as the result of errors found in the field. This work also showed that the most serious and frequently recurring errors are usually found by users soon after a product has been released. These are referred to by Adams [1] as virulent errors. The negative effects of remaining defects implies that post-release activities should be proactive. These post-release activities must include continued testing by the vendor to find errors even after release. This paper proposes a solution to this requirement.