A Brief Overview of Software Product Development

There are various methodologies like Agile, Srum, and Water fall etc for software product development. Some methods have proven to be effective. Different organizations have different strategy for product development. In this post I’ll give the heads up on activities involved in developing typical software product and some best practices to perform these activities effectively.

A new product evolves from marketing need. So a product starts from Market Requirement Document (MRD) which is typically written by marketing team. It can also be written by Business Analysts, varies based on the business model of the organization. It’s very much essential for every stakeholder to understand the market need for the product because each product has something called Market Window and needs to be delivered at planned date. If market window is crossed, the product may not sell in the market and will be a failure. 

From MRD, a Product Requirement Specifications (PRS) document is written by marketing team or requirements owner. In certain organizations there will be a requirements owner who owns requirements. Any modifications/addition of new requirements will be entertained only by this person.  This gives control over managing the requirements.  For effective requirements management, the requirements are logged into project management tools like Jama contour. 

From PRS a detailed Software Requirement Specifications (SRS) document is written. This might require meeting the key customers who are going to use the product. VOC (Voice of customer) is mandatory to better understand the requirements from end users perspective. One lesson learnt is that VOC must capture the product deployment scenarios. This is very important; we should know how & where the product will be used before even start understanding the detailed product requirements. 

Understanding the requirements

Once the software requirements are base lined, there will be series of requirements walkthrough sessions where the requirements are reviewed/discussed with the team members. It is crucial for all team members to understand and acknowledge the requirements. Asking all the questions on requirements and getting them clarified with requirements owner or the customers is crucial for successful product delivery. Imagine a situation where all the customer requirements written are addressed but one particular customer requirement is completely missed because it was never written down and no one in the team is aware of it! This can happen because of poor VOC. In order for a team member to design and write code with zero defects, there has to be granular requirement analysis. It might so happen that for some abstract requirements there could be implicit requirements. All implicit requirements should also be captured as software requirements. 

Converting requirements to Design

The design can start by writing use cases.  You might be required to do prototyping before taking up some designs. From requirements document, you can start identifying the classes from nouns and verbs in requirements to get started (Just a method). Creating a good design comes by practice and experience, there are no fixed rules for designing software that all should just follow. Quality design requires experience. Typically UML (Unified Modeling Language) is used for creating the design and there are tools to capture the design. The UML design tools such as Enterprise Architect, Rational Rose etc are used for designing. There are many UMLdesign tools, select the one that suits your requirements. There are different types of design diagrams, architectural diagram, deployment diagrams, class diagrams, sequence diagrams, activity diagrams etc. An understanding of what these design diagrams depict is required for designing. The key point in achieving the design excellence is by reviews. The entire design has to be reviewed by software architects to find design defects if any.  Before you say the design is complete, you need to ask certain questions like, does the design address all functional and non-functional (like performance related) requirements? Are all the failure modes captured in the design? etc.  And also it is important to have treatability from requirements to design. All requirements must be mapped to some design tags. 

Implementation

Some UML design tools have capability of creating skeleton code from the design. This can save some coding time.  Keeping the design as reference, the coding will happen. For any language there are coding guidelines which all developers have to follow. Let all classes and methods contain the design tags for treatability purposes. Ensure that the code will handle all the exceptions. Once coding is completed, there will be code reviews. There are static code analyzers for reviewing the code, these analyzers help programmers  know what rules have been violated during coding. Ex: CheckStyle, FindBugs etc.  

  

Unit testing the code (White Box Testing)

Each developer will test the code written by them. Unit testing can be automated using JUnit for testing java code. During unit testing, it’s important to collect code coverage reports to understand if all the code written by you is covered during unit testing. The code coverage tool I used was Emma. As a good practice, it’s very important to log unit test defects into defecting tracking tools like (JIRA, DevTrack, Bugzilla etc). It’s required understand ourselves as to what is the defect count in each phases of software development.  Defects can be in any phases, it can be requirements collection, design & implementation. Its good practice to maintain code coverage reports for your reference and unit test case records

Developer Integration Testing (DIT)

Once each individual finishes the unit testing, a DIT build is made for integration testing the product. This is when the interfaces get tested. I’m not sure if collecting the code coverage during DIT is a good practice or not, but we did collect the coverage. Coverage data from all the members involved integration testing is merged and a final code coverage report is generated and kept as a reference. Certain DIT test cases can be automated (This depends on the kind of the project) and test cases that can’t be automated are captured in a DIT test case document and DIT test results are entered against each test case. DIT is where developers still have control over the product because the build is not handed over to testing team yet.

Product Assurance Testing (PAT)

Product Assurance Testing is done by testing team (Black Box testing). A PAT release is handed over to testing team after completing DIT and fixing DIT issues if any. Before starting the actual PAT, the testing team would perform different tests like Acceptance Testing, Smoke testing to find if PAT can be continued or not. Testing team will a Test plan and PAT test case document. The testing team logs the bugs into defect tracking tool. There will be multiple PAT cycles planned based on the test design.

System Integration Testing (SIT)

SIT is system level testing performed by testing team. If the product being tested has to work with other systems (product), it’s tested in this phase.

Performance and Capacity Testing (PCT)

If the product has non-functional requirements like performance and capacity testing, and then testing team perform a separate test cycle called PCT. Performance constraints will be captured as requirements. Ex: User should be able download a file with 10 seconds. Capacity testing involves load/stress testing. Ex: Server must handle 500 requests at the same time. The key factor to meet performance and capacity requirements is to start addressing them right from design, coding. Faster code helps to meet. If performance requirements are crucial in the product, then having experienced developers for design and coding is important equally.

Beta Release

The beta release is done by the end customers and there will be beta feedback which will be addressed in the final release. Beta testing is performed by identified key customers.

Final Release

The product is made available in the market for the customers. No product is bug free. The final product release will follow a Software Release Bulletin that will have open issues. User guide will also follow. The marketing team will have training programs for the customers as to how to get familiar and use the product.

Conclusion

In all the above phases, the activity that leads to quality product is review. The result of root cause analysis for most of the issues reported was poor or no reviews and improper impacts testing. The best practice is to have reviews for all the activities starting from Software Requirements to change requests. The reviewer has to have domain knowledge and a checklist with him/her to make sure all the review items have been covered.Based on the code change, the impacts have to be identified and tested. This will make sure the code change done by you does not break any other functionality. It is general tendency to have more bugs being reported during DIT than UT. As a best practice defects must be caught in early phases of the product development like, requirements, design etc.