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.
No comments:
Post a Comment