Software Development Process: Explaining the Full-Cycle Model

Of the three models of cooperation with our clients in the software development process, Software Product Development is synonymous with the ‘full-cycle development’. It comprises all the stages of software development. Here we’ll explain what a full-cycle software development process looks like.

Overview of the software product development process

The software development life cycle comprises a regular set of activities, or stages, that transform an idea of a product into a working solution. Any full-cycle IT development process has four software development phases:

1. Ideation and requirements engineering – product discovery, defining key features, eliciting functional and non-functional requirements and constraints.
2. Design and implementation – the actual work of the dev team to design and build the functionality.
3. Verification and validation – testing the software deployed to various environments (staging, production) as part of the development process, in order to check its compliance with the requirements and user needs.
4. Maintenance and evolution – improving and modifying the ready solution based on business needs and customer feedback. This is a complex process in itself, with the identical software development stages.

These core phases of the software development life cycle include various sub- and supportive activities like requirements validation, architectural design, unit testing, configuration and change management, quality assurance, project management, etc.

‘Business – IT’ collaboration models vary across teams and project types as the development process is complex and no one-size-fits-all methodology framework exists.

Software development estimation phases

With projects having a shorter time span and a defined scope of functionality that is unlikely to change during the development, we can provide a precise estimate of cost and time. In case of uncertainty, or if flexibility is needed because the requirements may evolve, it will be safer to go for Agile and, consequently, the T&M model.

Regardless of a model, the first phase of our collaboration with a client – Presales – is the same. Here are the steps we take:

1. Examine the Request for Quote (Request for Proposal) and get back to you to clarify project requirements.
2. Provide a ballpark estimate.
3. If suitable, discuss the model of cooperation and recommend a pricing model.

Next, there are two scenarios: Waterfall (Fixed-Price model) and Agile (Time and Materials model).

Our approach to fixed-price contracts for software development process

In order to provide our client with a clear understanding of what results he or she can expect, at what cost, and within what timeframe, we need to elicit all requirements and prepare documentation at the very beginning. That’s why we divide our projects into two stages: Project planning stage and Project development stage.

Software project planning stage

Project planning stage involves working out detailed requirements and visualizing them through wireframes, data flow diagrams and even clickable prototypes. Next, we provide the client with a detailed estimate.

Throughout this phase we closely collaborate with the client. Our first aim is to see the whole product and identify the set of top-level real business requirements. Then, as each component piece is worked on, relevant, real business requirements need to be driven down to more detail so that responsive product requirements can be defined.

By the end of the project planning stage our clients receive:

• Software requirements specification – a document detailing the main functionalities of the software and the constraints around them.
• Wireframes – a layout of key web pages with interface elements.
• Design concept – the core idea around which the elements of a project revolve.
• Work order, which includes detailed project estimate, a project plan, technical requirements, acceptance criteria.
• Development team – a designer, developers, project manager, QA, etc.

Since this stage involves a large amount of work, it’s paid separately.

Software project development stage

When all terms are negotiated and the work order is signed, we proceed to the next stage:

1. Implementation. We engage in the actual design, development, and testing of the software product.
2. Deployment. We deploy the product to staging environment for user acceptance testing (UAT).
3. Release. We deploy the product to production environment.
4. Stabilization. After the release, we offer a month-long warranty period.

UAT begins with a build delivered to the client. At this point, the client can review the product and send us the first feedback. Often clients want addition or alteration to the initial product requirements. Such a change may involve an additional feature or customization or extension of existing functionality. A change request is a formal proposal for the adjustment of some product or system. Because change requests are beyond the scope of the agreement, they generally mean that the client will have to pay for the extra resources required to satisfy them.

Why do we need Agile for software development process?

Since we have such a straightforward development process as described above, why do we need to implement an Agile approach to software development?

Because a large number of our clients can really benefit from Agile. Early and continuous delivery of valuable software, continuous integration, daily meetings, changing requirements, even at later stages of development, are things that came out of the Agile space.

Waterfall methodology relies heavily on initial requirements. All project requirements should be written down in SRS during the project planning stage. But this approach doesn’t take into account the evolution of the project’s requirements.

Especially, when we are talking about startups. The main aim and challenge of any software startup is bringing a new idea to the market. The key concept here is a verification of the initial idea and discovering a sustainable, profitable and successful product.

Due to the fact that at the beginning founders have only an idea, the process of product development includes a lot of assumptions that need to be implemented and evaluated as soon as possible.

Characteristics of Agile development approach

Agile came about as a solution to the disadvantages of the waterfall methodology. As opposed to the Waterfall model, where the product is delivered at once, at the very end of the project, Agile lets a client see and influence the product’s evolution.

We start from requirements analysis and planning, which ends with a Product Backlog and a Roadmap. After that, we engage in a series of self-contained iterations (Sprints) with their own planning, analysis, designing, development, and testing procedures.

By the end of a sprint, our clients get a tangible result. They can make changes, introduce new ideas to the project and control the process in full.

Iteration Zero

Sprint 0 (or Iteration 0) begins with a kickoff meeting, where all the parties meet – the team, the management, the domain experts, and the stakeholders. We set out by exploring the initial business idea, technology, architectural goals, and study development practices. We also discuss critical dates. Our vision is transformed into estimated Backlog items (user stories). That serves as the basis for the ballpark estimate and a release plan. It’s crucial to work towards a common understanding of a project’s goals and keep in mind the product needs, which serve for priorities. After we have worked out a shared understanding of the definition of done, the actual development starts.

Sprints

Next we get down to iterating. Each sprint (2-4 weeks) starts from a planning meeting, where the team examines the user stories from the top of Product Backlog, identifies Sprint Backlog tasks and selects how much to commit to deliver by the sprint’s end. To improve progress tracking and individual commitment to team performance, Sprint Backlog tasks are estimated in hours by direct implementers: software developers, testers or designers.

Each sprint ends in delivering some functionality, i.e. a product increment corresponding to the definition of done.

The remaining items are backlogged for the following sprints. That is followed by a review and prioritization of the Product Backlog.

We estimate user stories (Product Backlog items) in approximate, relative units – story points. This allows us to make high-level forecasts about how much will be done by when.

Throughout the development, the team works as a unity and there’s a regular feedback on the progress. A burndown chart shows the decreasing amount of work.

Release

When the desired amount of product features are designed, coded and tested (according to release plan, roadmap), the team starts a release process. This process begins from a freeze, in which all work on adding new features is suspended, shifting the effort towards fixing bugs and improving the source code.

We are big fans of version control and GitHub and use branching to alleviate delays in development caused by freezes. The project repository has a “release” branch from which new versions of the software are released to “production” branch, and a separate “development” branch in which the developers add new code.

The freeze applies only to the “release” branch, and developers can continue their work on the “development” branch.

We build and deploy release code to the staging environment, in order to test and verify the product version.

To conclude

The goal of our Software Product Development model is to better plan and create a reliable product that meets the client’s expectations and industry standards. Though universal, the four stages will be realized differently depending on the software development process methodology.

Our approach helps choose the best possible software development process for your project.