Page 40 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT

Software Project Management

Notes  Software Requirements Specifications (SRS)
 High Level Design (HLD), written by R&D
 Low Level Design, written by the R&D
 Project Schedule
 Software Quality Assurance Plan (SQA)
There are many templates and different names to the above documentation. Nevertheless, the
important thing is that their survival requires the position holder to think before working on
the project. The documents need to be stored and updated during the life of the project as it is
done in a source code case (out of date document is a bug).

!

Caution Badly written or no MRD or SRS document can cause project failure.
Bad or no Software Requirements

As much as it sounds strange, in some software projects SRSs (Software Requirement Specifications)
do not exist or are badly written. There are many types of SRS formats and even if it was only
one common template, the content would vary from company to company. It is a question of
how well-defined the requirements are. We have never heard about a well-defined SRS that
caused projects to fail, but I am familiar with the opposite. A terse requirements document
affects the ability to break the software complexity, generate tasks and estimate time.
Furthermore, inadequate definitions cause misunderstandings and wrong implementation.
Changes to the project during the development become inevitable and, in time, project deadlines
will be missed.

Lack of Testing

 Those who develop the software should not test it. The developer should run unit testing,
but it is not a replacement to an objective QA test.

 Testing only at the end of a long milestone raise harms due to the load of testing and
inherent problems that should have been caught at earlier stages.
 Furthermore, managers tend to rush the testing period at the end of the milestone in order
to release on time.
 QA that does not bite and has no real power does not have the right effect on the R&D
department and is there for the project itself.
 QA should be started as soon as the software project starts. Hence, even in the planning
stage. QA participation in early stages is important for its preparation for the software.
For example, QA should also check the SRS document and make sure that the software was
implemented according to it.
 The following Professor Brooks rule of thumb might seem radical, but being given no
proportional time for planning and testing is indeed problematic: “1/3 of the schedule for
design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.”
 Tester to developer ratio: there is no rule of thumb that defines the number of QA engineers
per software engineer. The reason for that is that it depends on many variables and more
specifically on the characteristics of the software. For example, if “multilingual” is a
software requirement, then the number of tests increases. Another example will be the

34 LOVELY PROFESSIONAL UNIVERSITY