ZeePedia buy college essays online

Software Project Management

<<< Previous Software Quality Assurance Activities Next >>>
Software Project Management (CS615)
2. Software Development Fundamentals
Technical Fundamentals
Quality Assurance Management
Software Quality Assurance Activities
SQA is the process of evaluating the quality of a product and enforcing adherence
to software product standards and procedures. It is an umbrella activity that
ensures conformance to standards and procedures throughout the SDLC of a
software product. There are a large number of tasks involved in SQA activities.
These include:
Formulating a quality management plan
Applying software engineering techniques
Conducting formal technical reviews
Applying a multi-tiered testing strategy
Enforcing process adherence
Controlling change
Measuring impact of change
Performing SQA audits
Keeping records and reporting
Formulating a Quality Management Plan
One of the tasks of SQA is the formulation of a quality management plan. The
quality management plan identifies the quality aspects of the software product to
be developed. It helps in planning checkpoints for work products and the
development process. It also tracks changes made to the development process
based on the results of the checks. The quality management plan is tracked as a
live plan throughout the SDLC.
Applying Software Engineering
Application of software engineering techniques helps the software designer to
achieve high quality specification. The designer gathers information using
techniques such as interviews and FAST. Using the information gathered, the
designer prepares project estimation with the help of techniques such as WBS,
SLOC estimation, or FP estimation.
Conducting Formal Technical Reviews
Formal technical review (FTR) in conducted to assess the quality and design of
the prototype. It is a meeting with the technical staff to discuss the quality
Software Project Management (CS615)
requirements of a software product and its design quality. FTRs help in detecting
errors at an early phase of development. This prevents errors from percolating
down to the latter phases and resulting in rework.
Applying a Multi-tiered Testing Strategy
Software testing is a critical task of SQA activity, which aims at error detection.
Unit testing is the first level of testing. The subsequence levels of testing are
integration testing and system level testing. There are various testing strategies
followed by organization. At times, developers perform unit testing and
integration testing with independence testing support. There are also occasions
where testers perform functional testing and system level testing with developer
support. Sometimes beta testing with selected clients is also conducted to test the
product before it is finally released.
Enforcing Process Adherence
This task of SQA emphasizes the need for process adherence during product
development. In addition, the development process should also adhere to
procedures defined for product development. Therefore, this is a combination of
two tasks, product evaluation and process monitoring.
Product Evaluation
Product evaluation ensures that the standards laid down for a project are followed.
During product evaluation, the compliance of the software product to the existing
standards is verified. Initially, SQA activities are conducted to monitor the
standards and procedures of the project. Product evaluation ensures that the
software product reflects the requirements identified in the project management
Process Monitoring
Process monitoring ensures that appropriate steps to follow the product
development procedures are carried out. SQA monitors processes by comparing
the actual steps carried out with the steps in the documented procedures.
Product evaluation and process monitoring ensure that the development and
control processes described in the project management plan are correctly carried
out. These tasks ensure that the project-re1ated procedures and standards are
followed. They also ensure that products and processes conform to standards and
procedures. Audits ensure that product evaluation and process monitoring are
Controlling Change
This task combines human procedures and automated tools to provide a
mechanism for change control. The change control mechanism ensures software
quality by formalizing requests for change, evaluating the nature of change, and
controlling the impact of change. Change control mechanism is implemented
during the development and maintenance stages.
Software Project Management (CS615)
Measuring Impact of Change
Change is inevitable in the SDLC. However, the change needs to be measured and
monitored. Changes in the product or process are measured using software quality
metrics. Software qua1ity metrics helps in estimating the cost and resource
requirements of a project. To control software quality; it is essential to measure
quality and then compare it with established standards. Software qua1ity metrics
are used to evaluate the effectiveness of techniques and tools, the productivity of
development activities and the qua1ity of products. Metrics enables mangers and
developers to monitor the activities and proposed changes throughout the SDLC
and initiate corrective actions.
Performing SQA Audits
SQA audits scrutinize the software development process by comparing it to
established processes. This ensures that proper control is maintained over the
documents required during SDLC. Audits also ensure that the status of an activity
performed by the developer is reflected in the status report of the developer.
Keeping Records and Reporting
Keeping records and reporting ensure the collection and circulation of information
relevant to SQA. The results of reviews, audits, change control, testing, and other
SQA activities are reported and compiled for future reference.
Software Review
Software review is an effective way of filtering errors in a software product.
Typically, an error found after the product release costs 50 times as much to
correct as one detected during the design phase.
This means the cost of fixing a defect rises dramatically if it is found late in the
development life cycle of the product. Therefore, you need to filter errors as early
as possible.
Software review is used as a filter at various points of software development.
Reviews conducted at each of these phases, analysis, design, coding, and testing
reveal areas of improvement in the product.
Reviews also indicate those areas that do not need any improvement. You can use
software reviews to achieve consistency and uniformity across products. Reviews
also make the task of product creation more manageable. Some of the most
common software review techniques, practiced across software organizations
a) Inspection
b) Walkthrough
c) Formal technical reviews
a) Inspections
Software Project Management (CS615)
Inspections improve the reliability, availability, and maintainability of a
software product. Anything readable that is produced during software
development can be inspected. The readable material can be requirements
specifications,  design  documents  and  models,  test  plans,  system
documentation, and user aids. Group inspections enable team members to
exchange knowledge and ideas during an inspection session.
Inspections can be combined with structured, systematic testing to provide a
powerful tool for creating defect-free programs. The inspection activity
follows a specified process and the participants play well-defined roles. An
inspection team consists of three to eight members who play the roles of
moderator, author, reader, recorder, and inspector.
Moderator leads the inspection, schedules meetings, controls meetings, reports
inspection results, and follows up on rework issues. Author creates or
maintains the work product being inspected. Reader describes the sections of
the work product to the team as they proceed through inspection. Recorder
classifies and records defects and issues raised during the inspection. The
moderator might perform this role in a small inspection team. Inspector finds
errors in the product. All participants play the role of inspectors. However,
good inspectors are those who have created the specification for the work
product being inspected. For example, the designer can act as an inspector
during code inspection while a quality assurance representative can act as
standard enforcer. It also helps to have a client representative participate in
requirements specification inspections.
b) Walkthroughs
The term walkthrough refers to a group activity in which the developer of the
product guides the progress of the review. Walkthroughs are less rigorous than
either formal inspections or peer reviews in which the developer plays a more
passive role. Normally walkthroughs turn into a presentation by the author.
The focus of finding errors is diluted. Such misadventures make walkthroughs
usually less successful at detecting bugs than the more formal review
Two useful walkthrough approaches adopted worldwide are group reviews
with individual preparation and individual peer desk-checks. Group reviews
are not very rigorous like inspections. The group reviews involve many of the
same activities and roles, such as individual preparation and the use of a
moderator and a recorder. Usually the overview meeting and the follow-up
steps are skipped and checklists are used sparingly. At the end, the readers
paraphrase their interpretation of what a program is doing.
Software Project Management (CS615)
Individual peer desk-checks are quite cost-effective. Only one person besides
the author examines the material. This approach can be more effective if there
are individuals who are extremely good at finding defects on their own.
If someone consistently finds most of the group-identified defects during the
individual preparation step, such a person is fit to perform individual peer
c) Formal Technical Reviews
One of the most common, yet important, software quality assurance activity
performed is FTR. This activity is performed to check errors in logic,
function, or implementation for any representation of the software.
Using FTR, you can verify whether or not the software product adheres to the
defined standards. FTR is also conducted to check for consistency in the
software product and audit the manageability of the software product. It
includes activities such as walkthrough and inspection.
FTR focuses on specific parts of the software product, such as the
requirements components, detailed design module, and the source code listing
for a module.
FTR also concentrates on the entire product. The participants in FTR are the
developer, the project leader, and all the reviewers.
At the end of the review meeting, the issues recorded are formalized into
review issues list. The minutes of the meeting are summarized into a review
summary report as displayed in table 4.
Technical Review Report
Review Identification
Project Name
Current Phase
Review Number
Product Identification
Item Reviewed
Version No.
Brief Description
Documents Referred (along with versions, if any)
Start Name
End Time
Review Material Attached: Yes / No
Preparation Time
Software Project Management (CS615)
Total Review Time (No. of Participants * Actual duration of meeting)
Total Review Person Hours
Product Appraisal
Accepted as is ( )
With Minor Modification ( )
Not Accepted Major Revision ( )
Minor Revision ( )
Review Not Completed (Explanation as follows)
Supplementary Material Attached
Issue Lists:
Revise and Reschedule (if required)
Target Date for Next Review
Verification of Defect Closure
Responsibility of:
Planned Date of Verification
Recommended for Release
Table 4: Technical Review Report
To prepare realistic schedule, you can collect data from past projects. Speak to related
project managers regarding time estimation for reviews, the review capacity of the
reviewer, and estimates the review effort accordingly.
Most Organizations Are somewhere around this
Fastest schedule
(BEST schedule)
Time Time
95% 100%
Percentage of
Defects Removed
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration