The document discusses pre-project software quality assurance (SQA) components, focusing on contract reviews and the development and quality plans necessary before initiating a software project. Key elements include clarifying customer requirements, evaluating project resources, and defining quality assessment processes to ensure project success and minimize risks. By implementing structured SQA activities, organizations can prevent misunderstandings and maintain high-quality standards throughout the software development lifecycle.

1. Pre-project
Software Quality
Components
Anita Wulansari, S.Kom, M.Kom

2. 0.
Preface
2

3. Rules
Class will be held as scheduled. Changes will be informed in
advance.
Permission to be absent must be informed to the lecturer before
class with supplementary documents.
Pretest and posttest will be held for every week. No extra time or
replacement pretest & posttest.
Final grade composition:
Pretest & posttest : 10%
Assignment : 10%
Final exam : 30%
3

4. References
Software Quality Assurance: From Theory to
Implementation (2004) by Daniel Galin published by
Pearson Education Limited
The Future of Software Quality Assurance (2019)
published by Springer
4

5. Roadmap
5
1 3 4
5
2
Introduction
SQA Components
in the Project Life
Cycle
Software Quality
Infrastructure
Components
Pre-project
Software Quality
Components
Final Exam

6. 1.
Part Overview
6

7. Components of software quality assurance system overview
Software quality assurance consists of different
components
Each component is related to a certain part of the
software development process
If care is taken to perform every component to the
required quality level then a complete system with
high quality is achieved
7

8. Components of software quality assurance system overview
• Pre-project components
• Software project life cycle components
• Infrastructure components for error prevention and
improvements
• Management SQA components
• SQA standards, system certification and assessment
components
• Organizing for SQA – the human components
8

9. Pre-project SQA Components
The SQA components belonging here are meant to
improve the preparatory steps taken prior to initiating
work on the project itself
There are two components in pre-project stage:
Contract reviews: Reviewing the contract prior to
final agreement
Development and quality plans: Preparation of
plans before the actual work is performed
9

10. 2.
Pre-project SQA:
Contract Review
10

11. Contract review
Several situations can lead a software company to sign a
contract with a customer
Participation in a tender.
Submission of a proposal according to the customer’s
RFP.(Request For Proposal)
Receipt of an order from a company’s customer.
Receipt of an internal request or order from another
department in the organization.
11

12. Contract review
Software may be developed within the framework of a
contract negotiated with a customer or in response to
an internal order originating in another department.
Contract review activities must include a detailed
examination of the project proposal draft and the
contract drafts.
12

13. Proposal draft review objectives
Customer requirements have been clarified and
documented
Alternative approaches for carrying out the project
have been examined
Formal aspects of the relationship between the
customer and the software firm have been specified
Identification of development risks
13

14. Proposal draft review objectives
Adequate estimation of project resources and
timetable
Examination of the company’s capacity with respect
to the project
Examination of the customer’s capacity to meet his
commitments
Definition of partner and subcontractor participation
Definition and protection of proprietary rights
14

15. Contract draft review objectives
The three contract draft review objectives that make sure the
following activities have been satisfactorily carried out:
No unclarified issues remain in the contract draft
All understandings reached subsequent to the proposal are
correctly documented.
No “new” changes, additions, or omissions have entered
the contract draft.
15

16. Factors affecting the extent of a contract review
Project magnitude
Project technical complexity
Degree of staff acquaintance with and experience in
the project area
Project organizational complexity
16

17. Contract review
Contract review activities include:
Clarification of the customer’s requirements
Review of the project’s schedule and resource requirement
estimates
Evaluation of the professional staff’s capacity to carry out
the proposed project
Evaluation of the customer’s capacity to fulfill his
obligations
Evaluation of development risks.
17

18. Contract review
As contract reviews may impose a substantial workload and
additional pressures on the proposal team, thought should be
given to when it may be appropriate to abstain from
conducting a contract review. Such situations may occur with
small-scale projects, or small- to medium-scale cost-plus
projects.
Contract review procedures should therefore define those
types of projects for which a contract review is not obligatory.
For other defined types of “simple” projects, it is
recommended that authority be given to a senior manager to
make the decision as to whether to perform the review.
18

19. Contract review
Contract review is an important software quality
component because it ensures that we understand and
agree on all project details. It eliminates any disagreement
that might happen between the project parties.
Contract review is the software quality element that
reduces the probability of such undesirable situations.
Contract review is a requirement by the ISO 9001 standard
and ISO 9000-3 Guidelines
19

20. 3.
Pre-project SQA:
Development &
Quality Plans
20

21. Overview
Once a software development contract has been
signed or a commitment made to undertake an
internal project for the benefit of another department
of the organization, a plan is prepared of the project
(“development plan”) and its integrated quality
assurance activities (“quality plan”)
21

22. The main issues treated in the project development plan
Schedules (What are tasks and how much time is
required)
Required manpower and hardware resources
Risk evaluations
Organizational issues: team members, subcontractors
and partnerships
Project methodology, development tools, etc.
Software reuse plans.
22

23. The elements comprising a development plan
Project products, specifying “deliverables”, software
product and training tasks
Project interfaces, such as software interface,
hardware interface also cooperation and coordination
links.
Project methodology and development tools
Software development standards and procedures
The mapping of the development process, specifying
inputs, outputs and specifics activities planned.
23

24. The elements comprising a development plan
Project milestones
Project staff organization, comprises organizational
structure, professional requirements, number of team
members and their identities.
Development risks, for example technological gaps,
staff shortages, interdependence of organizational
elements.
Control methods
Project cost estimation
24

25. Software quality plan
A quality plan sets out (within a particular project) the
desired product qualities and how these are assessed and
define the most significant quality attributes
It should define the quality assessment process.
Software quality plan is a document that describes the
quality activities of a software project that should be
implemented to ensure that the results of the work
performed will satisfy the users and achieve the required
quality.
25

26. Software quality plan
Usually a software quality plan includes:
Quality goals, expressed in the appropriate
measurable terms
Criteria for starting and ending each project stage
Lists of reviews, tests, and other scheduled verification
and validation activities.
26

27. Development and quality plans for small projects
Advantages of “planned” small projects:
A more comprehensive and thorough understanding of the
task is attained.
Greater responsibility for meeting obligations can be
assigned.
Easier for management and customers to share control of
the project and to identify unexpected delays early on.
Better understandings with respect to the requirements
and timetable can be reached between the developer and
the customer.
27

28. Recommended elements of development and quality
plans for small projects
The development plan:
Project products, indicating “deliverables”
Project benchmarks
Development risks
Estimates of project costs
The quality plan:
Quality goals
28

29. Development plans and quality plans for internal projects
Internal projects are those projects intended for use by
other departments in the organization or by the entire
organization, as well as those projects dealing with
software package development for the software market.
Common to all these project types is the fact that no
external body participates as customer in their
development. Internal projects can be of medium or large
scale.
Yet even in these cases, there is a tendency to avoid
preparation of adequate development and quality plans.
29

30. Advantages of plan preparation for software development
departments
Avoiding budget overruns. This is of special importance
where the profit center system is applied.
Avoiding damage to other projects caused by delays in
release of professionals occupied in an internal project.
Avoiding loss of market status, especially regarding the
firm’s reputation, caused by delayed completion of
external projects triggered by late completion of internal
projects.
30

31. Advantages of plan preparation for internal customers
Smaller deviations from planned completion dates and
smaller budget overruns.
Better control over the development process, including
earlier identification of possible delays that enables the
search for and resolution of their causes.
Fewer internal delay damages.
31

32. Advantages of plan preparation for organization
Reduced risk of market loss (i.e., opportunity window) due
to late arrival of the product.
Reduced risk of being sued for late supply of products;
hence, reduced penalties for non-compliance with contract
demands.
Reduced risk of impairing the firm’s reputation as a reliable
software developer.
Reduced risk of requesting a budget supplement.
32

33. “
Quality is never an accident. It is
always the result of intelligent
effort
~John Ruskin~
33

34. Thanks!
Any questions?
34