With technological disruption in full flow, innovations are on the increase and different technological solutions and products are springing up. This has necessitated the need for proper management of the lifecycle of a product which is vital in achieving the goal of that product.

Product development lifecycle in software development is the process of dividing the development work into distinct phases. There is an increased need for customized software solutions. Whether you are updating your technologies, enhancing systems or developing more customer-centric software solutions, adopting an effective approach to managing the development is vital to the success of that product.

Validation is the process of determining the correctness of the final product of a development project with respect to the user needs and requirements. In software development processes, project management plays a key role as it focuses on matching user requirements to delivered products. Several project management methodologies such as Agile, Scrum, Waterfall and Kanban are used in software development.

Waterfall Approach to Software Development and Validation

The waterfall approach to software development and validation could be considered the original software life cycle model. This methodology involves having different steps to occur in a sequence (non-iterative). The progress can be seen as a flow downwards, hence the name Waterfall. In this model, the development of software initiates with the concept stage and progresses through to the final product. As the software development process is implemented, the software is continually transformed until the final product is realized. The Waterfall concept involves a stepwise progression of activities. The output of one phase becomes the input of the next phase, hence there are no overlapping phases in the Waterfall model. Each phase of the model is unique and well organized. The steps in the development process is broken down below:

Phase 1. Requirement Analysis: Requirement Analysis of customer needs is the first crucial step in Waterfall Methodology of Software Development Life Cycle. It involves gathering the details about what the customer needs and their expectations. If this process is neglected, you might misinterpret the needs and demands of the client which could eventually lead to the project going off track or off the rails. The input to this phase will be a clear communication of the requirements for the software. The output will be a requirements document (for example a user requirements document or a specification requirements document).

Phase 2. Design: The first thing to do is to gather all the information from the previous step (analysis) and the design system is made based upon on the requirements obtained from the analysis. This step consists of defining the flow of hardware and software architecture, data storage, and indicating strategies to effectively deal with issues such as exception handling and resource management etc. The input of this phase is the requirements document, while the output will be a design specification document.

Phase 3. Development: This is the implementation phase. This step is dedicated to constructing of the product as per the specifications and design developed in the previous step. This step is truly dependent on a development team consisting of programmers, interface designers and other experts using multiple tools such as compilers, debuggers, interpreters, media editors etc. The development starts by building small units which will be used to make up the whole system. Unit testing is used to test each unit individually before integration. The design specification document will be the input and the output from this phase of the process will be executable software modules.

Phase 4. Testing: This step is specially prepared for the technical verification of both individual components and the integrated whole. Additionally, one needs to ensure the final output of software developed is bug-free and fully matches with the requirements outlined in the first step. Deployment is done after testing. It involves the delivery of the product (integrated system) to the client.

Phase 5. Maintenance: This step is a form of customer support, providing after-sale service after installation of the software, in the case that any bug is found or modifications are required to the developed solution. Here, patches can be developed in case issues are found. This phase will have the input of the delivered product, which may need to be revised and updated due to changing customer demands and expectations.

Assumptions Vs Reality of the Waterfall Approach

There are some assumptions behind the waterfall approach to software development, one being that each phase occurs in sequence after the previous phase and that each activity neatly commences upon completion of the previous phase. However, in reality, phases tend to overlap, and it may not always be possible to have the output of each phase fully documented, verified and validated, prior to commencing the next phase. A major contributor to phase overlap tends to be project timelines, where work may need to commence on a follow-on phase, prior to completion of a prior phase, due to a need to rapidly progress the project to completion.

 When Should an Organization Consider Applying the Waterfall Approach?

• When the customer requirements are clearly defined and understood.
• When the technology is well established.
• When the definition of the expected output product is stable.

Examples of when the waterfall could be used, are when developing a newer version of an existing product or when transferring an existing product onto a new technology platform.

Early Shortcomings of the Methodology

Waterfall methodology relies heavily on initial requirements. But, if these requirements are faulty in any manner, the project is doomed. Moreover, gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development.

The process can appear to be rigid as a whole product is only tested at the end. If bugs appeared early but discovered late, the cost of the fix could be pretty high.

Because of these problems, Agile methodology evolved for software product development.

AGILE METHODOLOGY

In simple terms, being Agile is the ability to adapt to changes when required. Agile talks about two important concepts — Iterative & Incremental. Agile combines Iterative & Incremental methods and reaps benefits from both to make products better suit customer requirements.

Iterative product development

Iterative product development means building something through successive refinements, starting from the crudest implementation that will do the job, and at each stage refining in such a way that you maintain a coherent whole. With each iteration, you have captured some value. If your understanding of value changes, you still retain your captured value, and you can also adjust your future activities to accommodate your new understanding.

Incremental product development

Incremental product development, on the other hand, means building something piece by piece, like creating a picture by finishing a jigsaw puzzle. This is great for the visibility of progress, especially if you make the pieces very small. However, the inherent risk is that an incremental build is not done until the last piece is in place.

 

The Agile methodology is an umbrella term for several methodologies that are based on incrementation and iterations. One of these is the Scrum Framework.

 

THE SCRUM AGILE FRAMEWORK

Scrum is the most popular of the many frameworks of Agile Methodology used by a majority of Agile practitioners. In Scrum approach, you work on one feature (of the total feature work) at a time. In Scrum, the requirements are given to the team in the form of an easily understandable, jargon-free one-liner, which is also known as user stories. Scrum approach to product development is as follows:

• Divide the total work in multiple feature work (user stories)
• Analysis for Feature1
• Design of Feature1
• Implementation of Feature1
• Testing of Feature1
• Release Feature1 as a working software and move to Feature 2

 Relevant Terminologies in Scrum

User Stories – User stories are made up of sentences describing the functionalities which the client would like the system to have. They are short and simple descriptions of features written in a language comprehensible to both the client and the developer. They are written after a discussion with the clients. User Stories are written in sticky notes or cards and placed in a place visible and accessible to the developers working on the project.

Sprint – It is a time-boxed period in which the team accepts some user stories given by the Product Owner and works to convert them to working software at the end of it. With each sprint, the development team has to develop and test one functionality of the project. Usually, one sprint targets to complete one user story and as one sprint ends another one starts to ensure delivery within a deadline.

Daily Stand-up meetings – are conducted during sprints to provide brief on what has been achieved since the previous day, what needs to be done by the end of the next day and what challenged have been faced. They are usually time-boxed to 15 minutes.

Sprint Backlog — Top priority items from the Product Backlog that the team will work upon in the sprint are put in the Sprint Backlog. These stories will ideally become the working software at the end of the current sprint.

Product Owner — This person communicates with various stakeholders, creates and maintains product backlog, and works to maximize the ROI on the product.

Scrum Master — A role orthogonal to Product Owner, this person helps the team achieve the task and build long-term sustainability. He is a coach for the team.

Developers — Everyone else on the team is called a developer, irrespective of their qualifications, expertise and work.

Product Backlog — This is an artifact created by the Product Owner. This contains all the requirements in form of user stories. These stories will someday become a part of the working software.

 The Scrum Workflow

The process begins by gathering every involved personnel to discuss and write the backlog or user stories, which are written from the client’s perspective. Priorities are then set on each user story and time estimates are allocated. Complex user stories are broken down further. Daily stand-up meetings which are time-boxed to 15 minutes are conducted for the Scrum Team to update each other on their progress and any impediments they may be facing. Sprint objectives are set and after each sprint, a shippable product must be developed.

The steps to be followed for any feature release are:

• Ideate
• Design
• Implement
• Test
• Deploy

The Manifesto for Agile Software Development is based on twelve principles:

• Customer satisfaction by early and continuous delivery of valuable software
• Welcome changing requirements, even in late development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Face-to-face conversation is the best form of communication (co-location)
• Working software is the primary measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done—is essential
• Best architectures, requirements, and designs emerge from self-organizing teams
• Regularly, the team reflects on how to become more effective and adjusts accordingly

TYPES OF REQUIREMENT DOCUMENT

A Product Requirements Document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do. A PRD should, however, generally avoid anticipating or defining how the product will do it in order to later allow interface designers and engineers to use their expertise to provide the optimal solution to the requirements.

The User Requirement (s) Document (URD) or user requirement(s) specification is a document usually used in software engineering that specifies what the user expects the software to be able to do. Once the required information is completely gathered it is documented in a URD, which is meant to spell out exactly what the software must do and becomes part of the contractual agreement. A customer cannot demand features, not in the URD, whilst the developer cannot claim the product is ready if it does not meet an item of the URD. The URD can be used as a guide to planning cost, timetables, milestones, testing, etc. The explicit nature of the URD allows customers to show it to various stakeholders to make sure all necessary features are described.

 

PLANNING IS KEY TO DEVELOPMENT

Most product development endeavours fail because of lack of proper planning. So spend more time planning to make execution seamless.