10-09-2016, 03:19 PM
1454495400-actualLR.docx (Size: 20.83 KB / Downloads: 5)
F. et al (1993) stated that the alteration in the software application may be due to its requirement modification or due to functional defects during its use. If the software application is not constructed with the skills to handle maintainability changes demanded then, certainly it consumes more resources and makes the maintenance as a boring task. Software maintainability engineering must be given most important accent in the requirement's definition, design, coding, testing and maintenance of systems development processes. A comparative study done on waterfall and agile model and concludes that the Agile-Waterfall model aims to remember the dependency tracking and simplicity of Waterfall, while accepting the strengths of the Agile methodology, providing the flexibility and transparency essential to adjust to the fast-changing requirements of stakeholders.
Nelson and Teng (2000) described that there is a phase in life where a need rises within the organization to securing or develops a system. This need may involve the organization to knowledge through a system development life cycle in order for it to raise productivity to persist competitive. To attain that, most organisations have to make a conclusion to developing a system or obtaining a system. Thus, there are numerous systems development methodologies that can be followed after making that vital decision because there are assets involved. Define SDLC as a guideline and logical process used by system developers to develop systems.
M. and I. (2000) stated that Software life cycle models defined stages of the
software cycle and the order in which those phases are performed. There are lots of models, and many companies implement their own, but all have very similar arrangements. Each phase
produces deliverables required by the next stage in the life cycle. Requirements are interpreted
into design. Code is created during Development that is driven by the design. Integration and
Test verify the deliverable of the development phase in contradiction of requirements. Unfortunetely, there is no “one size fits all” methodology to applying SDLC methodologies.
Avison and Fitzgerald (2003) describe that the designed result meets the user requirements that support business tactical objectives and aims. The SDLC can be either agile or traditional. However, the main purpose is to examine the agile and waterfall methodologies together and to understand why, who and how they are used and also highlight the limitations thereof.
Larman and Basili (2003) stated that Software development life cycle is aapproach for designing,building, and maintaining information and industrial systems. Thus far, there exist
many SDLC models, such as the Waterfall model, which includes five stages to be concluded
sequentially in order to improve a software solution. SDLC has been examined by many researchers and frequent models have been planned where their acknowledged powers and flaws are presented. They all contain of a sequence of phases or steps that must be followed and finalized by system developers and designers in order to attain developed systems and bring required products.
Rob (2004) stated that SDLC desired the needed ways that include various
stages and activities to successfully develop the system. The software_development team
has reasonably select the suitable methodology for a specific project they are undertaking.
Highsmith (2004) stated proposed five periods of the agile approach: Envision (characterize vision, venture extension, and undertaking association), Speculate (create model characterized by the item qualities and time limitations, and emphasis arrangement for vision usage), Explore (convey tried parts in brief time and ceaselessly look for an approach to decrease venture danger and vulnerability), Adapt (check deliverables, current circumstance, and group conduct to adjust if vital) and (close venture, make lessons learned, and celebrate). Similarly, DeCarlo (2004) sets up his Flexible Project Model with four iterative stages: Visionate, Speculate, Innovate, and Reevalute, and with shutting stage Disseminate.
Bartels et al (2006) stated that social factors were major cost drivers for the development of software development. Study in this field revealed a grounded theory of how people achieve the process of software development. To get the job done, people comprise in a four-stage process of Reconciling Perspectives. Reconciling Perspectives represent an effort to congregate persons’ points of view or perceptions about a software development. The process highlights the status of individuals’ capabilities to both reach out and participates in discussions and creates shelter from environmental sound to bring a software project to completion. Software development is a risky and exclusive suggestion. Talking with software developers rapidly explains the swamp that software development can become. Late provision, unreliable products, cost ravages, and unsatisfied staff and stake holders are some of the remains consequential from an unsuccessful or less than successful project. This is expensive debris seeing that global software development is a 1.6 trillion US dollar industry.
Despite the fact that customary way to deal with undertaking administration emphaiszes heartiness as one of its focal points, endorsing that the same strategies and systems could be connected to all tasks consistently, it is progressively said as one of the pivotal disservices of such approach. Today, expanding number of creators push the way that "one size does not fit all" (Aguanno, 2004; Chin, 2004; Shenhar, 1998; Shenhar&Dvir, 2007; Wysocki, 2007).
Conboy (2009) stated that agile software development (ASD) teams were involved in critical decisions that support vital project success or failure. Zannier and Maurer (2006) said that ASD team members also trusted on their experience to determine whether a design decision is necessary and then matches options when making design decisions (Zannier and Maurer, 2007).
Somervilla (2010) stated that Software engineering is an engineering field whose objective is the development of excellence quality product with consistency and within budget and given time frame. Development of software projects requires an appropriate process to be tracked by the organization. This software process which is required to produce software varies from company to company. SDLC model offers a method for developing a software artifact. There are numerous software development models. The adoptability of them looks upon project needs. The important thing which organizations must take into concern is that they should progress towards a „bug‟ free product before induction it in the market. Fusion of more than one model may be essential in some software-development product to make a contrast between the suggested model, and the previous software processes management models to highlight the defects and features of each development model.
Cohen et al (2010) said that each SDLC methodology was only active under specific circumstances. SDLC Models have also been planned for refining cooperation and stakeholder communication. Alarmingly, recent industry developments have found that mainstream of the projects to exceed budget, are completed past scheduled deadlines and do not encounter original business purposes.
Drury et al. (2011) Describe that related research has found that ASD teams face a number of negative factors preventing them from following a linear decision process and that experience is a driving force in ASD project management decisions (Drury et al., 2011).
Strode et al (2012) stated that agile software development offered a way to organize the complex task of multi-contributing software development while accepting constant project change. Agile software development is well accepted in the expert community but there is little understanding of how such projects attain effective management, which is known to be serious in successful software projects. A theoretic model of coordination in the agile software-development context is presented based on experimental data from three cases of co-located agile software development. Many practices in these projects act as coordination mechanisms, which together form acoordination strategy. The theoretical model of coordination in agile software-development projects suggests that an agile coordination approach raises coordination effectiveness. This model has application for practitioners who want to select suitable practices from agile methods to ensure they achieve coordination coverage in their project. For the field of information systems development, this theory pays to knowledge of coordination and coordination effectiveness in the context of agile software development.