Software product lifecyle

"...your document is just great. Please put this on your blog or somewhere ..."
--
Mdsr


The initiation of a project can be started by any of è

èMarketing Requirement Document MRD: This document is conducted by marketing team, which identifies possible product gaps in the industry. They later come up with MRD, highlighting what market is anticipating in the future. This serves as stimulus for product/project initiation. It can be regarded as a wish list + requirement.

èSoftware Requirement Specification SRS: This document is composed by Technical Management at the company. They take input from MRD and devise how to achieve what is proposed by marketing guys. If marketing guys are just beating about the bush, than engineering starts from this document. This document explains the product composition and/or product placement. It shows what is required and where, but not shows how.

*There is an IEEE standard for SRS, which is just amazing template to use. IEEE 830 is very helping this regard as we found It.* 

Sometime an architectural document is also created following IEEE 1016, but it’s very high level and may come handy when working on huge product.

The following two documents are created in *parallel*. One by engineering team, other by QA team. SRS serves as impetus for the following two in parallel.

A. Functional requirement specification FRS: This document expands SRS. It adds how thing should be achieved. It also shows what should be dropped from SRS which is not feasible in this release. Sometime FRS is skipped and just SRS is detailed enough and matured. Sometime SRS is created and it’s debated on with marketing and management, which results in FRS.

Technology choices; most of the times it is required to decide some technical off-the-shelf technology choices, to speed up *time-to-market*. Like which available open source technology, if any should be used. And what package should be extended to achieve what’s in SRS. This results in appropriate licensing and escalation process which should be kept in mind, explained later.

B. QA Test plan: In parallel to FRS or SRS, which one is available, the QA team is assigned to create all the possible test scenarios *prior* to development. The prepare test charts and group test scenarios. When the FRS/SRS is finalized, and agreed by the Engineering and Management teams, in the same time QA plan is also finalized. Here again IEEE 829 is very handy, but can be skipped easily. If the end product is source code, than QA team should include unit testing using CUNIT or JUNIT or any other where required.

DEVELOPMENT:  Now development is started. In parallel the QA is asked to finalize the test plan and soon QA is handed over the *first prototype*. This prototype is than handed to QA for testing. They log in the findings in any software like bugzilla which is free, or Rational ClearCase and or TestTrack. We used all three from time to time, and bugzilla is just fine.

During development a versioning system is a *must*. SVN is quite handy as well as CVS. But it should be used.

Every found bug should be logged in the bug tracking system. Same as every fix should be released as part of install-able solution. This should be strictly followed. No fix should be shared separate of the next coming build.

Numerous code review sessions are required. Similarly for critical applications, and/or where end product is source code, coding standards are followed, like MISRA. PC Lint is a tool which is very good for dry code verification.

How to hand over the first prototype, i.e. build generation. The prototype should be *install-able*. For this reason, various setup creation tools are available. Used InstallShield, it is same as Setup Factory.  The Installer is than delivered to QA team.

Here also branding is done. What name should be displayed, what contact information should be there etc. what credits should be mentioned. Once setup is created it is handed over to the packaging team which comes up with package and licensing as well. We followed another process which we named IV&V, internal validation and verification before mass production in on-shore office.

Licensing should be decided as well prior to release. *This is very important*, it’s called *product escalation process*. What license products should be used? Some licenses are viral, like GNU. A company once paid nearly 30 m, in copyright infringement.  Same is anything compiled in GNU should also be open source. Eclipse license is far better, EPL.

The above mentioned cycle continues through numerous but finite iterations. For every next release same thing is restarted from SRS document or MRD if marketing guys are really that smart. Once finalized development and testing starts in parallel. It’s ensured that nothing misses shared repository in SVN and/or bugzilla. The internal release is shared with fellow developers of other teams to give possible feedback.

Every step seems crucial, starting from SRS, development/testing, build and release.  But over planning is over kill. For this reason, sometime soft deadlines, and sometimes hard deadlines are introduced.