Part A

Que1. Spiral model, V model and modified V model offer some challenges from the
Quality Assurance perspective. Discuss those challenges in detail.

Ans1. Quality Assurance is defined as the planned and systematic activities necessary to provide
adequate confidence that the product or service will meet the given requirements. Quality Assurance
makes sure the project will be completed based on the previously agreed specifications, standards and functionality
required without defects and possible problems. It monitors and tries to improve the development process from the
beginning of the project to ensure this. It is oriented to "prevention".

Spiral model : The spiral model is a software development process combining elements of
both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also
known as the spiral lifecycle model Different challenges:-

1. Can be a costly model to use.

2. As Project’s success is highly dependent on the risk analysis phase and Risk analysis
requires highly specific expertise.

• Spiral Model – risk driven rather than document driven

• The "risk" inherent in an activity is a measure of the uncertainty of the outcome

of that activity

• High-risk activities cause schedule and cost overruns

• Risk is related to the amount and quality of available information. The less
information, the higher the risk

• Lack of risk management experience

3. Lack of milestones

4. Management is dubious of spiral process

5. Doesn’t work well for smaller projects

V Model : V stands for "Verification and Validation". The V-model promotes the idea that the dynamic test stages
(on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing.
The V-Model further promotes the notion of early test preparation. Early test preparation finds faults in baselines and
is an effective way of detecting faults early. This approach is fine in principle and the early test preparation
approach is always effective. However Different Challenges are offered:-

1. There is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test
activities on the right. For example, functional specifications don’t usually provide enough information for a
system test. System tests must often take account of some aspects of the business requirements as well as
physical design issues for example. System testing usually draws on several sources of requirements
information to be thoroughly planned.

2. V-Model has little to say about static testing at all. The V-Model treats testing as a back-door activity on the
right hand side of the model. There is no mention of the potentially greater value and effectiveness of static
 tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model
does not support the broader view of testing as a constantly prominent activity throughout the development
lifecycle.

Modified V Model: It attempts to address shortcomings in the V-Model. Rather than focus on specific dynamic test
stages, as the V-Model does, the W-Model focuses on the development products themselves. Essentially, every
development activity that produces a work product is shadowed by a test activity. The purpose of the test activity
specifically is to determine whether the objectives of a development activity have been met and the deliverable
meets its requirements. Different challenges offer:-

1. Models simplify the real facts. In practice there are more relations between the different parts of
a development process. However there is a need for a simple model if all people involve in a
project are to accept it. This is also a reason why simple model is so frequently used.

2. They don’t clarify the expenditure needed for resources that needed to be assigned to the
individual activities. It also appears that the different activities have an equal requirement of
resources but in practice this is not the case. The important aspects may vary so the resource
allocationis unlikely to be equal.

Que2. Three successive versions of the product had respectively 0, 79, and 21 defects
respectively. Which of these products would be of high quality? Explain the criteria that
you employed, to come upon the result. Also specify the result if the three successive
versions of the product had 85,90, and 79 defects respectively.

Que3. Which SDLC model would be most suitable for each of the following scenarios?

a. The product is a bespoke product for a specific costumer, who is always available
to give feedback.

Prototyping Model

b. The same as above, except that we also have access to a CASE tool that
generates program code automatically.

RAD Model

c. A general purpose product, but with a very strong product marketing team who
understand and articulate the overall customer requirements very well.

V Model

d. A product that is made of a number of features that becomes available

sequentially and incrementally.

Spiral Model
 Part B

Que4. What should be the contents of the QA report, keeping in mind the goal that the
defects found in a test should eventually be fixed?

Ans4. A well-written quality assurance report are very important to implement total quality systems in the
organization. One of the most important steps in implementing quality systems is to fix the defects found in a test.
defects give a clear picture about the how the software quality so they are to be fixed before implementation. To
improve the quality of the products and services in a efficient and effective way quality assurance report is must.

Content of the Quality Assurance report:-

Introduction:- Begin your QA report with the title, date and the name of the author. Follow with an
abstract section. This is a summary of the contents of the report. Generally, upper levels of management
may read only the abstract to decide whether they need to read the rest of the report. All of the major
findings of the report should be listed in the abstract section in concise language.

Task:- Include a section on task information following the abstract section. Describe the test objectives
and how many test cases to be made. Also you may describe the historical results of similar tasks
performed earlier and any past quality problems that are related to what is discussed in the report.
Include information about the dates covered by the task performed and which department is covered.
Describe the general scope of the purpose of the report. Describe why the report was written and what
aspects of quality are covered in the report. If there was a particular reason for the report was called for,
state it.

Execution:- Include the section for the execution of the above mentioned tasks. How to execute the tasks and what is
the expected output of the test so that comparison can be made later on.
Write a section with findings next. In this section, describe the findings of the quality assurance activity
or test. Include facts and figures in this section, along with any other data obtained. Any calculations that
were conducted in the QA function should be included here.

Results:- Include the section for the comparisons as

1.Total No.of test cases vs No.of test cases passed
2.No of defects found Vs No.of defects resolved
3.No of defects retested vs No.of defects pending for retest
Maintaining in Excel spread sheet is a good idea or graphical representation can also be a good idea.

QA recommendations and risks:- To analyze of the statistical data (described by previous posters here).
For example it could appear that 54 out of 57 failed test cases are failed due to few defects that are
described as known problems in release notes. So only those 3 more failed tests are to be pointed out.
You may also want to mention what tests you missed to execute due to time limitations or decisions by
managers.

Assestment:-
Finish the QA report with a section on conclusions. Include any discussion about the findings in this
section. An assessment should be made in this section about whether the quality assurance procedures
within the organization are being followed or not.

Que5. How do you introduce a new software Quality Assurance process? Elaborate on
the same.
Ans5. The function of software quality that assures that the standards, processes, and procedures
are appropriate for the project and are correctly implemented.
To introduce a new SQA process : -

Phase: As the process is divided into different modules so write a phase number on the top of
the page.

Description: SQA provides visibility to management that the software products and processes
in the project life cycle conform to the specified requirements and established plans for the
organization.

Entry Criteria/Inputs:

1. Project requirements, standards, organizational standards/processes, specifications

2. Commitment to SQA Policy
3. Project software quality goals
4. Adequate resources committed to SQA

Exit Criteria/Outputs:

1. Documented SQA Plans and procedures

2. Trained SQA practitioners
3. Results of Engineering activity reviews, process area reviews and work product reviews
4. Reports of deviations on both products and processes
5. Metrics of project and process status

Roles:

Project Manager (PM) or other authority above software development organization: appoints
and oversees SQA organization
SQA Manager (SQAM), if appointed: leads SQA group
SQA Engineer(s): team of individual SQA practitioners who implement this process
Senior Management: periodically reviews SQA activities and resolves issues when necessary

Assets/References:

1. SQA Policy
2. SQA Plan Template
3. Create Project SQAP
4. Review ENG Activities Proc
5. Review SW Work Products Proc
6. SQA Process Area Checklist Proc
7. SQA Track Deviations Proc
8. Review SQA Activities
9. SQA Measure
10. Software Project Management Plan Template
11. SQA Review Closure Report Temp
12. SQA Review Findings Temp
13. SQA Status Report Template
14. SQA Orientation/Training Checklist
15. Software Quality Assurance Orientation
TASKS:

1. Read the SQA Policy document.

2. Establish SQA organization for the project.
a. Senior Management appoints an individual or group responsible for SQA (SQA Manager). SQA
must have organizational freedom, authority, and independence of software development
activities to permit objective reporting. Guidance on reviews is contained in SQA Policy.

3. Select SQA tasks.

The SQA Group selects the tasks that will be performed, such as those listed below:
a. Reviewing software processes and tools against requirements and guidelines for compliance
with standards and KPAs of the SW-CMM. Process evaluation and KPA verification tasks are
documented in Review ENG Activities Proc , Review SW Work Products Proc , and SQA Track
Deviations Proc .
b. Review software work products against requirements and guidelines using SQA Review
Software Work Products Procedure.
c. Participate in Peer Reviews and Project Reviews (technical and management reviews) by
providing status on compliance, problem areas, and risks. Guidance on reviews is contained in
SQA Review Software Work Products Procedure.
d. Suggesting methods, standards, guidelines, and tools to be defined for the project and
seeing that they are documented in the project’s Software Project Management Plan, which is
based on Software Project Management Plan Template.
e. Reporting results of product evaluations and process audits to the Project Manager, senior
management, affected development groups, and the Organizational Process Group (OPG), as
appropriate. Guidance on SQA status reports is contained in Review SQA Activities.
f. Collect and report metrics on the status of cost and schedule, product evaluations, project
quality, and audits according to Software Quality Assurance Measures.
g. Select and identify SQA tools required to perform SQA tasks, based on project requirements.

4. Create SQA plan.

The SQA Group follows Create SQAP Procedure and documents the SQA plan in the Software
Project Management Plan or in a separate SQA Plan, following SQA Plan Template. An SQA Plan
will include the following information:
a. Quality objectives, in measurable terms
b. Responsibilities of the SQA group
c. Resource requirements for the SQA group
d. Schedule and funding of SQA activities
e. Documenting and tracking noncompliance issues, and the escalation procedure
f. SQA participation in project plans, standards, and procedures
g. Evaluations to be performed by SQA
h. Reviews to be conducted by SQA
i. Standards and procedures used for SQA

5. Maintain and implement SQA Plan.

The SQA Group performs the SQA function as defined in the SQA Plan, which is based on SQA
Plan Template. Maintaining and implementing the SQA Plan involves the following activities:
a. Detecting, managing, and escalating (if necessary) deviations. Refer to SQA Track Deviations
Proc as necessary.
b. Reporting progress of SQA activities and results of evaluations. Refer to SQA Review Findings
Temp, SQA Status Report Template Review Closure Report Temp, and Review SQA Activities as
necessary.
c. Responsibilities of the SQA group
d. Resource requirements for the SQA group Problems or deviations with requirements are
documented and reported to the PM and appropriate authority. Senior management addresses
noncompliance issues that cannot be resolved within the project.

6. Provide SQA training.

The SQA Group identifies training required to perform SQA tasks, based on project
requirements. Training includes training of the SQA Group and SQA orientation for the software
project team members. Refer to Software Quality Assurance Orientation and SQA
Orientation/Training Checklist as necessary.

7. Participate in lessons learned session(s).

The SQA Group reviews SQA processes and identifies improvements and efficiencies for future
use. SQA activities are reviewed with the PM and with senior management on a periodic and
event-driven basis. Many improvements can be supported by quantitative analysis collected in
the Software Quality Assurance Measures database.

Measures:

1. Effort and funds expended for each activity

2. Number of SQA reviews and audits conducted (planned vs. actual)
3. Number of unresolved issues (elevated to PM) compared to all issues reported

Que6. What are the common problems with respect to Quality assurance, which are
encountered in the software development process?

Ans6.I n developing products and services, quality assurance is any systematic process of checking to see whether a product or
service being developed is meeting specified requirements. A quality assurance system is said to increase customer confidence and
a company's credibility, to improve work processes and efficiency, and to enable a company to better compete with others. Today's
quality assurance systems emphasize catching defects before they get into the final product. Quality assurance, or QA for short,
is the systematic monitoring and evaluation of the various aspects of a project, service or facility to maximize the
probability that minimum standards of quality are being attained by the production process. QA cannot absolutely
guarantee the production of quality products.

A software development process, also known as a software development lifecycle, is a structure imposed on
the development of a softwareproduct.

Software development activities

Planning:- The important task in creating a software product is extracting the requirements or requirements analysis.
Customers typically have an abstract idea of what they want as an end result, but not what software should do. Once
the general requirements are gathered from the client, an analysis of the scope of the development should be
determined and clearly stated. This is often called a scope document.
Problems:-
• Poor requirements:- customer is able to express what he wants at the end but don’t know
what and how actually the software should do.
• Goal is not defined acurately:- It may be possible that the defined goal is not accurate or
can define what the project is all about and what is the result of the project
• Wrong Lifecycle model chosen:- May be wrong Lifecycle is implemented
• Inadequate Cost estimation:- It may be possible at end of the project, the cost goes out
of control and one needs to stop the project because of finance problems or the project
gives loss to the management.
 • Inappropriate Software Quality assurance report:- SQA report may be inappropriate which
donot difine the roles or task to be perform
• Unrealistic schedule:- if too much work is crammed in too little time, problems are inevitable.
• Not good Software Configuration management plan
• Miss Communication:- Communication gap may occur between the customer and the
developer causing problem in the project

Implementation, Testing and documentation:-

Implementation is the part of the process where software engineers actually program the code for the project.

Software testing is an integral and important part of the software development process. This part of the process ensures
thatdefects are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and enhancement is done
throughout development. This may also include the writing of an API, be it external or internal. It is very important to
document everything in the project.
Problems:-
• Non availability of the resources:- During implementation of the project, the non
availability of the resources cause problem in the quality of the project
• Inadequate testing:- If testing is not done correctly the quality of the project depreciates.
• Incomplete testing:- Incomplete implementation of the test cases results in decreasing
the value of the project which further decrease the quality of the project
• No documentation:- Proper documentation is must for quality assurance
• Futurities:- When customer requests to add on new features after development goals are agreed on then
it causes problem and may not give quality assurance.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a
production environment.

Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more
time than the initial development of the software.

Problems:-
• Code addition:-It may be necessary to add code that does not fit the original design to correct an unforeseen
problem or it may be that a customer is requesting more functionality and code can be added to accommodate
their requests.

• Labor cost:-If the labor cost of the maintenance phase exceeds 25% of the prior-phases'
labor cost, and then it is likely that the overall quality of at least one prior phase is poor.
In that case, management should consider the option of rebuilding the system (or
portions) before maintenance cost is out of control.

• No standardization:- When standard is followed while implementing or during the

maintainace of the software then the problem will occur with respect to the quality
assurance.