Study on A Few Software Development Methodologies

Amir Azimi
Aug 9, 2017 · 10 min read

SDLC

“The systems development life cycle (SDLC below), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system.” (CMS , 2008) “The systems development life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both.” (Parag C. Pendharkar, 2008)

When it comes to software engineering process and methodologies, there are many methodologies. To analyse and consider which one is suitable for this project, it is important to choose the best super methodology and then choose the suitable sub methodology for this projects after analysis and comparison.

Waterfall Model

The reason why this method titled Waterfall is because this method follows a sequential process in software development process. The processes in this methodology are descending or downward such as Waterfall. Waterfall’s phases are Requirements, Analysis, Design, Construction, Testing, Implementation and Maintenance.

One of the reasons why this methodology is not suitable for this project is because once the system is on testing stage; it is very difficult to go back and alter something. The other reason is no software is created and is pending until the end of the life cycle and there are high amount of risks involved for instance the question of whether the software will be the one which the clients needs it to be and that is uncertainty. Whilst this project is based on Object-Oriented and is complex, therefore the Waterfall model is not going to be a suitable model for this project as it is deprived model for large and constant projects.

RAD

Rad stands for Rapid Application Development and one of the conventional Waterfall Models for software development. The products in this methodology can be implement faster with high quality by collecting needs from user groups in workplaces, client testing and design, process of software components, a severely walked timetable that submits design developments to the next product version and is using less

smartness in reviews and group infrastructures. This model is sub-model of Waterfall.

MDD

MDD stands for Model-Driven Development. Together with a number of non-functional requirements such as event management and security, there are 3 main architectural characteristics that can be outlined for the functional requirements, aforementioned to development. These are the solutions:

  • Limitations
  • Configuration
  • Domain model

It is clear that the efficiency improvements from MDD are unquestionable and this methodology was used to implement numbers of Microsoft co-operation’s projects.

DDD

Domain Driven Design or DDD is a software development method for multipart requirements through linking the development to a growing model and it has some relationship to other ideas such as:

  • Model Driven Engineering
  • Object-Oriented Analysis and Design
  • Model Driven Architecture
  • POJOs (Plain Old Java Object)
  • POCOs (Plain Old CLR Object)
  • Event Sourcing (ES)
  • Domain-specific language (DSL)
  • Command Query Responsibility Segregation (CQRS)
  • Aspect-oriented programming (AOP)
  • The naked objects pattern

One of the disadvantages of this methodology and the reason why it is not used for this project is because there has to be a great sequestration and encapsulation deal for implementation within the domain model. This is acceptable when there are number of business domain complexity.

V-Model

Before V-Model exploration and consideration the Figure 6 - V-Model (Softobiz)(Softobiz) is a good source to have a look at, which shows the verifications and validations of planning and testing. V-Model is not only because of its processes shown in Figure 6 that is V-Shaped named V-Model but also it means Validation and Verification. Similar to Waterfall Model the V-Model’s life cycle is a sequential path of execution of processes and that also means each process must be finalised before the next one begins. Promptly the question of why this model is V-shaped may have been asked and the answer is because testing of the product is planned in parallel and matching with the related or corresponding phase of development. Although is simple to use this model, it is very unyielding and not as flexible as it should be. Also this works really well with small projects when requirements are clearly comprehended, however, if any alters occur in between, the testing and requirements has to be updated along with it. This is improved version of Waterfall Model.

Spiral

Spiral Model has more emphasis on risk analysis. The Spiral Model has four phases:

  • Planning
  • Risk Analysis
  • Engineering
  • Evaluation

In planning stage the requirements are collected together and in risk analysis stage one process is commenced to classify risk and complementary solutions. Usually, a prototype will be produced at the end of this stage. In engineering stage, the actual software will be implemented and developed alongside with testing at the very end of the stage. Finally, in evaluation stage permits the client to assess the productivity of the project before the next spiral. “When to use Spiral model:

  • When budgets and risk assessment is important
  • For moderate to high-risk projects
  • Lasting project obligation unwise because of possible changes to economic main concern
  • Clients are uncertain of their requirements
  • Requests are complex
  • New product line
  • Substantial changes are anticipated.” (ISTQB EXAM CERTIFICATION)

Agile

Unlike Waterfall Model, Agile Methodologies phases do not have to wait until the next phase process is finalised to be able to adapt. Agile is iterative team-based approach when it comes to software development processes. Iteration means rapid delivery or it should have been terms deliveries as the complete phase may have repeated again in order to change and adaptation for better performance. All time is positioned into phases called sprints and these sprints have distinct period and this period is no more than approximately two weeks or in some cases only a week. The sprints are planned in advance and deliverables are ordered by business value as determined by the client. Every work has its continuation of reviews and assessments by the clients when completed in every sprint. Agile is relies on an appropriate high level of customer participation through the project development and this is the most suitable methodology for this project. Now to consider what sub methodology is the best one for this project; first some of the methodologies under Agile Methodology need to be analysed, although the decision between Agile and Waterfall is Agile Methodology for this system.

The Agile Software Development consists of seven methods:

  • Extreme Programming (XP)
  • Scrum
  • Crystal Orange
  • Dynamic System Development (DSDM)
  • Adaptive Software Development (ASD)
  • Future Driven Development (FDD)
  • Pragmatic Programming

DSDM

DSDM or Dynamic System Development Method is the first Agile Methodology type that needs to be analysed in this report before choosing the right Agile Methodology for this project. There is increasing pressure on organisations to deliver working solutions to business problems than opportunities in ever shorter time-scales without compromising quality and that was the reason why DSDM was released. DSDM was released in 1994 and the reason why it was released was because it required obtaining some regulation to RAD or Rapid Application Development methodology, which was categorised under one of the Waterfalls Models as the first methodology defined in this report but in 2007 DSDM enhanced the standard method for project management and resolution distribution. The DSDM philosophy is the best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. The DSDM Agile project framework provides the structure and guidance needed to bring this philosophy to life from understanding the business need for establishing the firm, high-level foundation for the project and collaboratively evolving the solutions that the business needs, to deploying it to life operational use. DSDM is clear the definition of roles and responsibilities for everybody involved along with proven techniques to help them collaborate effectively underpins the capability of the project team to deliver what the business needs, when it needs it, predictably and reliably every time. Business people are proactively engaged in their project from the day one, two and three and so on guiding the development of the solution prioritising the work of the team and ensuring the what is delivered is the best that could be achieved within budget and time-scale allowed.

In organisations, which have already invested in Agile Project Delivery, DSDM can be easily tailed to become and Agile Project Management Frameworks to wrap around Scrum, Extreme Programming or other Agile Development approaches. In organisations, which already have invested in Prince 2 for project management and governance, DSDM can be tailed and integrated as an Agile Project Delivery Framework to bring all the benefits of its Agile approach within the traditional governance structure. The DSDM also uses MoSCoW principle, which prioritises with: Must have, Should have, Could have and Won’t have technique management.

Figure 10 - DSDM Principles clearly shows the DSDM’s principles and the way it works. With DSDM’s ability to wrap-around Scrum, XP and other Agile Development approaches, first it is a good idea to analyse other Agile Methods such as Scrum and Extreme Programming to see which one is suitable for this project and it how it is going to work with DSDM.

Scrum

Nowadays, Scrum is one of the best Agile Development approaches. To use Scrum first as usual, requirements need to be gathered from client and specified by Scrum Master as User Stories. The collection of all User Stories termed Product Backlog. Another way to think of a Product Backlog is to think of it as a wish list of all the objects that would make the product and the system great. Once the wish list or Product Backlog is obtained, planning needs to be started to which specific user-stories need to be put into the particular list of the product. However, to build the product, it is always required that to work in a team with people who are going to play variety of roles and one of them is Product Owner. The product Owner helps to make sure the correct features make it into the Product Backlog, representing the user and client of the product. The Product Owner helps to set the direction of the product. There is another person in the team called Scrum Master. The Scrum Master’s job is to make sure the product is progressing smoothly and that every member of the team has the tools they need to get their job done. Also The Scrum Master establishes meetings, monitors the work being done and facilitates release planning. The rest of the team has similar roles to other development processes. The user-stories generated from Product Backlog become part of the Release Backlog. The team prioritises the user-stories within The Sprint Backlog and estimates the amount of work involved for each item. It is good to mention that larger user-stories often are broken down to smaller and more manageable portions. The collection of all estimates provides a rough idea of total amount of work involved to complete the entire sprint. Fundamentally, there are a lot of good techniques for creating good estimates. The most effective techniques are to estimate work hours. Sprints are short-duration milestones that allow teams to tackle manageable portion of the project and get it to a ship-ready state.

As it is better to have at least 2 to as many as dozen sprints in a given release, therefore, at this point, The Release Backlog can be taken and divided up into several of Sprint Backlog. Since sprints are very short, but a realistic representation of part of the product, a late finish of the sprint is a great indicator that the project is not on schedule and something needs to be done. Therefore, it is extremely important to monitor the progress of each sprint with Burn-down Chart. The Burn-down Chart is number one reason for Scrum’s popularity and one of the best project visibility tools to ensure the project is progressing smoothly. The Burn-down Chart provides the day-to-day measuring of the work amount remains in a given sprint or release. By using The Burn-down Chart, the team can quickly calculate the slope of the graph, which is also called The Burn-down Velocity.

TDD

TDD is a software development discipline where developers write automated test cases for enhancement or new features before they write any code. The basic premise of TDD is to begin by writing a failing test for the simplest piece of functionality that it needed to be implement. Afterwards, simplest code possible will be written to pass the test. Once this is done, the new code is reworked or refactored to ensure it meets the requirement standards of the code. TDD helps to ensure the quality by focusing on requirement before writing the code. It assists in keeping the code clear, simple and testable by breaking it down into small achievable steps. It is also provides documentation about how the system works for anyone coming into the team later, it builds the suite of repeatable regression tests and it acts as an enabler for rapid change.

BDD

BDD or Behaviour Driven Development is similar to TDD with some differences such as language and scope. With language, it means writing code in BDD is different than TDD. BDD stretches a richer indulgent as to what the system should do from of the programmer’s viewpoint and the client. Also BDD focuses on the behavioural aspect of the system rather than the implementation aspect of the system. BDD permits both the programmer and the client to work laid-back on requirements analysis that is contained within the source code of the system.

Amir Azimi

Written by

Creator of Parsclick | Software Engineer | Web Developer | PHP | Ruby | Laravel | Ruby on Rails

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade