How to Develop Software: Basic Methodologies

Waterfall Software Development Methodology

The Waterfall methodology represents a linear approach to software development. The development team applies Waterfall when it is working on a simple project that doesn’t require many stages.

In the Waterfall methodology, the process of software development is described as a chain of successive steps.

There is no jumping back and forth between stages. Developers move on to the next stage only when the previous one is finished.

Stages of Waterfall Software Development Model

Waterfall Methodology follows this pattern of stages:

• Requirements analysis. This is the stage where the development team analyzes the client’s ideas. Going over the concepts provided by the client allows the team to establish the project’s purpose, functionality, performance requirements, time scope, and budget. Each idea or feature has its place and priority.
  The team then prepares a Vision Scope document in which the project is outlined.
• Design. Now it is time to decide on how the requirements will be implemented. Designers build software mockups, and CTOs decide on the architecture, programming language, and database tables.
  The result of this stage is that all the team members and the client have a clear vision of how the project will be executed.
• Development. This stage includes actual application development. Programmers write the code, implement features, and build UI.
  Here the process may be split into units. The development team builds and tests the units one by one. After that, they compile software from the already-built units.
  At the end of this stage, the team has almost complete software ready for testing.
• Testing. After the developers complete building the software, it’s time to see if there are any defects or issues with it. Testers make sure the product meets the requirements, performs well, and doesn’t have any bugs.
  If testers find bugs, the developers go back into the code and fix errors. Then the test is run again to make sure that everything is perfect.
  The result of this stage should be software that works perfectly and is ready for release.
• Maintenance. This stage comes after the product is completely developed. The team releases the software and customers begin using it. But the programmers still work on it — testing out and implementing new features, supporting customers, and catching bugs that may have been missed during the testing stage.

As you can see, the Waterfall model is pretty straightforward. However, this algorithm is suitable only for a simple software, where the requirements will not change.

Advantages and disadvantages of Waterfall

When it comes to developing more complex software with many aspects, we need a more sophisticated approach.

Scrum Software Development Methodology

The Scrum model is a must for developers working on complex software projects. Many things can go wrong during a project with many peculiarities, and the best approach here is to divide the development process into phases.

That’s what Scrum methodology offers. Each phase can be completed and reviewed separately, and changes can be introduced as needed.

Stages of Scrum Software Development Model

In Scrum, role breakdown is a bit different from the Waterfall model. In addition to regular roles such as Project Manager, Developer, and QA Tester, there are additional twists, such as:

• Product owner — This is the person who communicates the client’s interests. It may be the client if s/he has a suitable experience. Sometimes the Project Manager takes on the role of Product Owner.

• Scrum Master — This is the person who coordinates the whole project. Most of the time, it’s a Project Manager from the software development team.

• Scrum team — This is a team of developers, testers, and designers who work on the software.

The Scrum methodology includes the following stages:

Product Backlog Creation

A product backlog is a document that contains the features of the future software product. Each feature has its place, based on agreed priority. It has its own ID, and it is usually called the User Story.

The User Story includes the following features:

• Importance. Each story is ranked, usually by number.
• Estimate. This describes the capacity of required work.
• Demo. Explains how the built feature will be demonstrated.

The base unit of Scrum methodology is the Sprint — a period of one to four weeks during which a piece of work is to be accomplished.

Before the Sprint begins, the development team does Sprint planning and compiles a Sprint backlog.

Want to build your software solution?

We are ready to provide our skilled pofessionals to develop your ideal product.

Aleksandra Golik
Head of Sales
at HQSoftware

Get a Free Quote

Sprint Planning and Sprint Backlog Creation

The first task is to determine how long the Sprint will last. If the development team opts for a shorter Sprint, it will be able to release software updates and work on bug fixes quicker. On the other hand, taking the time to work on a certain task will result in a much more stable product.

After the Sprint duration is chosen — say, one week — the Scrum team decides on the most important User Stories to work on. Those User Stories are registered in the Sprint Backlog. The number of stories in the backlog depends on the duration of the particular Sprint.

Sprint and Scrum Meetings

Having finished the Sprint Backlog, it’s time to start working on User Stories. During the Sprint, there is a daily Scrum meeting, at which team members describe their progress by answering the questions:

• “What did I do yesterday?”
• “What am I going to do today?”
• “What problems have I had so far?”

The daily Scrum meeting is a convenient way for a Scrum Master to keep tabs on everybody’s work. If unexpected obstacles have arisen, the Scrum Master will be able to deal with them quickly and adjust strategy within the Sprint.

Testing and Product Demonstration

At this stage, the testers come into play, checking for bugs and errors, so that the developers can polish the product. After that, the team demonstrates the product to the Product Owner, who decides on further changes to the software.

Sprint Retrospective and Next Sprint Planning

At the end of the Sprint, the programmers engage in a Sprint Retrospective, where they discuss the results of their work, assessing its strengths and weaknesses.

Based on the Sprint Retrospective, the strategy for ongoing development can be adjusted. Then the cycle repeats with planning for the next Sprint session.

There you have it  — Scrum software development methodology. Its structure is easy to comprehend and learn, and it allows for handling complex software projects.

Advantages and disadvantages of Scrum

The advantages of this pattern include time-effectiveness and agility. Workflow can be adjusted during the software development process, and it is simple to grasp. At the end of each Sprint, the team has a more or less finished product, which is also beneficial.

But Scrum relies on having a versatile team that is capable of self-organization, which can solve problems without extensive coordination. If the team can’t do that, the Scrum won’t work. So the company has to make sure to hire skilled and experienced developers or spend money on training their staff.

Dmitry Sokolovski
Project Manager
at HQSoftware

In most of our projects we rely on Scrum Methodology. Since we deal with big and complex projects, we appreciate the ability to divide our work in Sprints, keep tabs on everyone’s work, and find and eliminate problems as soon as possible.

Alternatives

Apart from Waterfall and Scrum methodologies, the development team can also follow Spiral and Iterative software development models. Those also can be useful for tackling projects of various degrees of complexity.

Spiral Methodology

Stages of Spiral Software Development Model

The Spiral software development methodology is suitable for large-scale projects that might require thorough risk management. It consists of four phases:

• Planning. Here the team establishes project requirements: business requirements specifications and systems requirement specifications. They analyze the product objectives, costs, technology stack, and timeframes.
• Risk analysis. Next, team members evaluate the risks involved in product creation. If possible, they also discuss approaches and solutions to potential problems.
• Engineering. This is the phase where the development and testing process happens. Here, the programmers may apply the Waterfall methodology.
• Evaluation. At this stage, the team reviews and evaluates the completed work. Members discuss problems that occurred during the process and decide on solutions. After that, the cycle repeats.

Such an approach to the development process allows for handling large-scale projects; it is also easy to monitor, adjustable to the client’s changing needs, fast, and cost-effective. Also, the risk management approach helps to avoid undue risk and create reliable software.

But it also can get expensive quickly — if the project is large, the spirals may go on and on. Documentation can be hard to grasp, due to the repeating stages. Also, continuous spirals may prolong the project development process.

Iterative Methodology

The Iterative methodology is much more time-effective than the Spiral model. The advantage is that the developers do not need a full product specification before they start building the software.

The developers start designing and coding a certain part of the software and then return to specifications for the next part.

Stages of Iterative Software Development Model

Iterative development follows this pattern:

• Initial planning. Here the client, with the development team, outlines the software project. There is no need to be exact — later on, the team will define precise requirements.
• Planning. This is the first part of the iterative cycle, which will repeat until the project is done. The team goes over a certain part of the project, defining the requirements and tasks.
• Analysis and design. This is the coding part of the cycle. It can be pretty short since the developers only work on a limited part of the software.
• Testing. The testers go through the developer’s work to make sure it has no bugs.
• Evaluation. The programmers go over their work, review the issues and correct mistakes.
  This is the last phase of the iterative cycle. After the team does an evaluation, its members start over with planning the next part of the software.
• Implementation and deployment. At this stage, the team finishes up the software development and rolls it out to the public.

The iterative methodology allows developers to catch bugs and fix them fast. Also, they spend less time writing documentation and more time actually working on a project. Since the development process is modular, it is really easy to adjust.

But Iterative development makes it hard to pinpoint the date of product deployment: the more issues developers come across, the more time and cycles they need to work on them. That may result in unexpected expenses.

Bottom Line

The process of software development and software reengineering will fall apart if it’s not monitored and controlled. There must be a certain succession of steps, which requires constant communication and evaluation of each decision.

For more or less straightforward projects, Waterfall is the best. It is easy to understand, has fixed time scales and requirements, and should not incur any unexpected expenses. The downside is that it is not flexible and is hard to apply to large-scale projects.

For complex projects, we have a Scrum methodology. It is extremely agile and cost-effective if the development team knows how to apply it. The development team can identify issues and solve them as fast as possible before the product is finished.

Waterfall and Scrum are the most widely used software development methodologies. There are also alternatives, such as Spiral software development, but even that does refer to the traditional Waterfall model.