Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

SE MODULE 5 ANSWER QBANK Merged

Download as pdf or txt
Download as pdf or txt
You are on page 1of 30

MODULE 5-QUESTION BANK

Subject : Software Engineering And Project Management (21CS61)


Faculty Name: Prof. Shruti B Gowda

1. Explain the place of software quality in project planning.

 Quality will be of concern at all stages of project planning and execution, but will be
particular interest at Stepwise framework .

Step 1 : Identifying project scope and objectives Some objective could relate to the quality of the
application to be delivered.

Step 2 :Identifying project infrastructure Within this step activity 2.2 involves identifying
installation standards and procedures. Some of these will almost certainly be about quality
requirements.

Step 3 : Analyze project characteristics. In this activity the application to be implemented will be
examined to see if it has any special quality requirements.

Example: Safety-critical applications might require additional activities such as n-version


development, where multiple teams develop versions of the same software to cross-check
outputs.

Step 4 : Identify the product and activities of the project. It is at that point the entry, exit and
process requirement are identified for each activity.

Step 8: Review and publicize plan. At this stage the overall quality aspects of the project plan
are reviewed.
Explanation of the Figure 13.1

Initial Step: Select Project

 Ensure the project aligns with strategic goals and has clear objectives related to software
quality.

1. Identify Project Scope and Objectives

 Define clear, concise, and achievable objectives with established quality criteria for
deliverables.
2. Identify Project Infrastructure

 Determine the necessary tools, technologies, and resources that support quality assurance
processes.

3. Analyze Project Characteristics

 Assess the complexity, size, and scope, identifying potential quality risks and strategies
to mitigate them.

4. Identify the Projects and Activities

 Break down the project into smaller, manageable activities with defined quality standards
and completion criteria.

5. Estimate Effort for Each Activity

 Accurately estimate the time and resources needed, including quality assurance activities
like testing and reviews.

6. Identify Activity Risks

 Identify potential risks for each activity, including those affecting quality, and develop
mitigation plans.

7. Allocate Resources

 Allocate appropriate resources, including skilled personnel for quality assurance and
control tasks.

8. Review and Publicize Plan

 Review the project plan to ensure all quality standards are included and inform
stakeholders about the quality importance.

9. Execute Plan

 Continuously monitor quality standards during execution, implementing quality control


measures to ensure deliverables meet established criteria.

10. Lower-Level Planning

 For detailed planning of individual activities, include quality assurance steps like detailed
testing plans, review processes, and quality checkpoints.
2. What are the Special Characteristics of Software Affecting Quality
Management? Explain.

 Now a days, quality is the important aspect of all organization. Good quality software is the
requirement of all users, There are so many reasons that describe why the quality of software is
important, few among of those which are most important are.

1. The intangibility of software :

 Difficulty in verifying the satisfactory completion of project tasks.


 Tangibility is achieved by requiring developers to produce "deliverables" that can be
examined for quality.

2. Accumulating errors during software development :

 Errors in earlier steps can propagate and accumulate in later steps.


 Errors found later in the project are more expensive to fix.
 The unknown number of errors makes the debugging phase difficult to control.

 Quality is a rather vague term and we need to define carefully what we mean by it. For any
software system there should be three specifications.
 A functional specification describing what the system is to do
 A quality specification concerned with how well the function are to operate
 A resource specification concerned with how much is to be spent on the system.

Attempt to identify specific product qualities that are appropriate to software , for instance,
grouped software qualities into three sets. Product operation qualities, Product revision qualities
and product transition qualities.

Product operation qualities:

 Correctness: The extent to which a program satisfies its specification and fulfil user
objective.
 Reliability: the extent to which a program can be expected to perform its intended
function with required precision.
 Efficiency: The amounts of computer resource required by software.
 Integrity: The extent to which access to software or data by unauthorized persons can be
controlled.
 Usability: The effort required to learn, operate, prepare input and interprets output.

Product Revision Qualities:

 Maintainability: The effort required to locate and fix an error in an operational program
 Testability: The effort required to test a program to ensure it performs its intended
function.
 Flexibility: The effort required to modify an operational program.

Product Transition Qualities:

 Portability: The efforts require to transfer a program from one hardware configuration
and or software system environment to another.
 Reusability: The extent to which a program can be used in other applications.
 Interoperability: The efforts required to couple one system to another.

When there is concerned about the need for a specific quality characteristic in a software product
then a quality specification with the following minimum details should be drafted .

1. Definition/Description

Definition: Clear definition of the quality characteristic.

Description: Detailed description of what the quality characteristic entails.

2. Scale 0 Unit of Measurement:

The unit used to measure the quality characteristic (e.g., faults per thousand lines of code).

3. Test

Practical Test: The method or process used to test the extent to which the quality attribute exists.
4. Minimally Acceptable

Worst Acceptable Value: The lowest acceptable value, below which the product would be
rejected.

5. Target Range

Planned Range: The range of values within which it is planned that the quality measurement
value should lie.

6. Current Value

Now: The value that applies currently to the quality characteristic.

3. Explain the quality models: 1) Garvin’s Quality Dimensions


2) Mccall Model
3) Boehms Model

1) Garvin’s Quality Dimensions: David Gravin , a professor of Harvard Business school, defined
the quality of any product in terms of eight general attributes of the product.

 Performance: How well if performs the jobs.


 Features: How well it supports the required features.
 Reliability: Probability of a product working satisfactorily within a specified period of time.
 Conformance: Degree to which the product meets the requirements.
 Durability: Measure of the product life.
 Serviceability: Speed and effectiveness maintenance.
 Aesthetics: The look and feel of the product.
 Perceived quality: User’s opinion about the product quality.

2) McCall’ Model: McCall defined the quality of a software in terms of three broad parameters:
its operational characteristics, how easy it is to fix defects and how easy it is to part it to
different platforms. These three high-level quality attributes are defined based on the following
eleven attributes of the software:
 Correctness: The extent to which a software product satisfies its specifications.
 Reliability: The probability of the software product working satisfactorily over a given
duration.
 Efficiency: The amount of computing resources required to perform the required functions.
 Integrity: The extent to which the data of the software product remain valid.
 Usability: The effort required to operate the software product.
 Maintainability: The ease with which it is possible to locate and fix bugs in the software
product.
 Flexibility: The effort required to adapt the software product to changing requirements.
 Testability: The effort required to test a software product to ensure that it performs its
intended function.
 Portability: The effort required to transfer the software product from one hardware or
software system environment to another.
 Reusability: The extent to which software can be reused in other applications.
 Interoperability: The effort required to integrate the software with other software.

3) Boehm’s Model:

Boehm’s suggested that the quality of a software can be defined based on these high-level
characteristics that are important for the users of the software. These three high-level
characteristics are the following:
As-is -utility: How well (easily, reliably and efficiently) can it be used?

Maintainability: How easy is to understand, modify and then retest the software?

Portability: How difficult would it be to make the software in a changed environment?

Boehm’s expressed these high-level product quality attributes in terms of several measurable
product attributes. Boehm’s hierarchical quality model is shown in Fig 13.3 .

4. Explain ISO 9126.

 ISO 9126 standards was first introduced in 1991 to tackle the question of the definition of
software quality. The original 13-page document was designed as a foundation upon which
further more detailed standard could be built. ISO9126 documents are now very lengthy.

Motivation might be-

 Acquires who are obtaining software from external suppliers


 Developers who are building a software product
 Independent evaluators who are accessing the quality of a software product, not for
themselves but for a community of user.

 ISO 9126 also introduces another type of elements – quality in use- for which following
element has been identified

• Effectiveness : the ability to achieve user goals with accuracy and completeness;

• Productivity : avoiding the excessive use of resources, such as staff effort, in achieving user
goals;

• Safety: within reasonable levels of risk of harm to people and other entities such as business,
software, property and the environment

• Satisfaction: smiling users

ISO 9126 is a significant standard in defining software quality attributes and providing a

framework for assessing them. Here are the key aspects and characteristics defined by ISO
9126:

ISO 9126 identifies six major external software quality characteristics:

1. Functionality:

Definition: The functions that a software product provides to satisfy user needs.

Sub-characteristics: Suitability, accuracy, interoperability, security, compliance.


‘Functionality Compliance’ refers to the degree to which the software adheres to application-
related standard or legal requirements. Typically, these could be auditing requirement.
‘Interoperability’ refers to the ability of software to interact with others.

2. Reliability:

Definition: The capability of the software to maintain its level of performance under stated
conditions.

Sub-characteristics: Maturity, fault tolerance, recoverability.

Maturity refers to frequency of failures due to fault in software more identification of fault more
changes to remove them. Recoverability describes the control of access to a system.

3. Usability:

Definition: The effort needed to use the software.

Sub-characteristics: Understandability, learnability, operability, attractiveness.

Understand ability is a clear quality to grasp. Although the definition attributes that bear on the
user efforts for recognizing the logical concept and its applicability in our actually makes it less
clear. Learnability has been distinguished from operability. A software tool might be easy to
learn but time consuming to use say it uses a large number of nested menus.
This is for a package that is used only intermittently but not where the system is used or several
hours each day by the end user. In this case learnability has been incorporated at the expense of
operability

4. Efficiency:

Definition: The ability to use resources in relation to the amount of work done.

Sub-characteristics: Time behavior, resource utilization.

5. Maintainability:

Definition: The effort needed to make changes to the software.

Sub-characteristics: Analyzability, modifiability, testability.

Analysability is the quality that McCall called diagnose ability, the ease with which the cause of
failure can be determined. Changeability is the quality that others call flexibility : the latter name
implies suppliers of the software are always changing it. Stability means that there is a low risk
of a modification to software having unexpected effects.

6. Portability:

Definition: The ability of the software to be transferred from one environment to another. \

Sub-characteristics: Adaptability, install ability, co-existence.


Portability compliance relatesto those standardsthat have a bearing on portability. Replaceability
refers to the factors that give upward compatibility between old software components and the
new ones. 'Coexistence' refers to the ability of the software to share resources with other
software components; unlike' interoperability', no direct data passing is necessarily involved.

5. How does ISO 14598 relate to the assessment of software quality


characteristics as defined by ISO 9126?

 ISO 9126 provides structured guidelines for assessing and managing software quality
characteristics based on the specific needs and requirements of the software product. It
emphasizes the variation in importance of these characteristics depending on the type and
context of the software product being developed.
 Steps Suggested After Establishing Requirements

Once the software product requirements are established, ISO 9126 suggests the following steps:

1. Specify Quality Characteristics: Define and prioritize the relevant quality characteristics
based on the software's intended use and stakeholder requirements.

2. Define Metrics and Measurements: Establish measurable criteria and metrics for evaluating
each quality characteristic, ensuring they align with the defined objectives and user expectations.

3. Plan Quality Assurance Activities: Develop a comprehensive plan for quality assurance
activities, including testing, verification, and validation processes to ensure adherence to quality
standards.
4. Monitor and Improve Quality: Continuously monitor software quality throughout the
development lifecycle, identifying areas for improvement and taking corrective actions as
necessary.

5. Document and Report: Document all quality-related activities, findings, and improvements,
and provide clear and transparent reports to stakeholders on software quality status and
compliance.

1. Judge the importance of each quality characteristic for the application.

• Identify key quality characteristics (e.g., Usability, Efficiency, Maintainability).

• Assign importance ratings to these characteristics based on their relevance to the application.

Importance of Quality Characteristics:

Reliability: Critical for safety-critical systems where failure can have severe consequences.
Measures like mean time between failures (MTBF) are essential.

Efficiency: Important for real-time systems where timely responses are crucial. Measures such
as response time are key indicators.

2. Select the external quality measurements within the ISO 9126 framework relevant to the
qualities prioritized above.

Determine appropriate external quality measurements that correspond to each quality


characteristic.

• Reliability: Measure with MTBF or similar metrics.

• Efficiency: Measure with response time or time behavior metrics.

3. Map measurements onto ratings that reflect user satisfaction. for example, the mappings
might be as in Table 13.1 .

For response time, user satisfaction could be mapped as follows (hypothetical example):

Excellent: Response time < 1 second


Good: Response time 1-3 seconds

Acceptable: Response time 3-5 seconds

Poor: Response time > 5 seconds

4. ldentify the relevant internal measurements and the intermediate products in which they
appear.

• Identify and track internal measurements such as cyclomatic complexity, code coverage, defect
density, etc.

• Relate these measurements to intermediate products like source code, test cases, and
documentation.

5. Overall assessment of product quality: To what extent is it possible to combine ratings


for different quality characteristics into a single overall rating for the software?

• Use weighted quality scores to assess overall product quality.

• Focus on key quality requirements and address potential weaknesses early to avoid the need
for an overall quality rating later.

6. Describe the relationship between software quality and project planning


with a neat diagram.

In software development, managing quality can be approached from two main perspectives:
product quality management and process quality management. Here’s a breakdown of each
approach and their key aspects:

1. Product Quality Management

Product quality management focuses on evaluating and ensuring the quality of the software
product itself. This approach is typically more straightforward to implement and measure after
the software has been developed Aspects:
1. Measurement Focus: Emphasizes metrics that assess the characteristics and attributes of the
final software product, such as size (LOC, function points), reliability (defects found per LOC),
performance (response time), and usability (user satisfaction ratings).

2. Evaluation Timing: Product quality metrics are often measured and evaluated after the
software product has been completed or at significant milestones during development.

3. Benefits:

 Provides clear benchmarks for evaluating the success of the software development project.
 Facilitates comparisons with user requirements and industry standards.
 Helps in identifying areas for improvement in subsequent software versions or projects.

4. Challenges:

 Predicting final product quality based on intermediate stages (like early code modules or
prototypes) can be challenging.
 Metrics may not always capture the full complexity or performance of the final integrated
product.

2. Process Quality Management

Process quality management focuses on assessing and improving the quality of the development
processes used to create the software. This approach aims to reduce errors and improve
efficiency throughout the development lifecycle.

Aspects:

1. Measurement Focus: Emphasizes metrics related to the development processes themselves,


such as defect detection rates during inspections, rework effort, productivity (e.g., lines of code
produced per hour), and adherence to defined standards and procedures.

2. Evaluation Timing: Process quality metrics are monitored continuously throughout the
development lifecycle, from initial planning through to deployment and maintenance.
3. Benefits:

 Helps in identifying and correcting errors early in the development process, reducing the
cost and effort of rework.
 Facilitates continuous improvement of development practices, leading to higher overall
quality in software products.
 Provides insights into the effectiveness of development methodologies and practices used by
the team.

4. Challenges:

 Requires consistent monitoring and analysis of metrics throughout the development


lifecycle.
 Effectiveness of process improvements may not always translate directly into improved
product quality without careful management and integration.

Integration and Synergy

 While product and process quality management approaches have distinct focuses, they are
complementary.
 Effective software development teams often integrate both approaches to achieve optimal
results.
 By improving process quality, teams can enhance product quality metrics, leading to more
reliable, efficient, and user-friendly software products.
7. List the popular capability models to manage the quality of the Software
and Explain SEI CMM with an appropriate diagram.

Process Capability Models

1. SEI Capability Maturity Model (CMM) and CMMI:

❖ Developed by the Software Engineering Institute (SEI), CMM and CMMI provide a
framework for assessing and improving the maturity of processes.

❖ They define five maturity levels, from initial (ad hoc processes) to optimized (continuous
improvement).

❖ CMMI (Capability Maturity Model Integration) integrates various disciplines beyond


software engineering.
2. ISO 15504 (SPICE):

❖ ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability
determination), is an international standard for assessing and improving process capability.

❖ It provides a framework for evaluating process maturity based on process attributes and
capabilities.

3. Six Sigma:

❖ Six Sigma focuses on reducing defects in processes to a level of 3.4 defects per million
opportunities (DPMO).

❖ It emphasizes data-driven decision-making and process improvement methodologies like


DMAIC (Define, Measure, Analyze, Improve, Control).

Importance of Process Metrics

During Product Development:

❖ Process metrics are more meaningfully measured during product development compared to
product metrics.

❖ They help in identifying process inefficiencies, bottlenecks, and areas for improvement early
in the development lifecycle.

1. SEI Capability Maturity Model (SEI CMM)

The SEI Capability Maturity Model (CMM) is a framework developed by the Software
Engineering Institute (SEI) to assess and improve the maturity of software development
processes within organizations.

It categorizes organizations into five maturity levels based on their process capabilities and
practices:
SEI CMM Levels:

1. Level 1: Initial

Characteristics:

❖ Chaotic and ad hoc development processes.

❖ Lack of defined processes or management practices.

❖ Relies heavily on individual heroics to complete projects.

Outcome:

❖ Project success depends largely on the capabilities of individual team members.

❖ High risk of project failure or delays.


2. Level 2: Repeatable

Characteristics:

❖ Basic project management practices like planning and tracking costs/schedules are in
place.

❖ Processes are somewhat documented and understood by the team.

Outcome:

❖ Organizations can repeat successful practices on similar projects.

❖ Improved project consistency and some level of predictability.

3. Level 3: Defined

Characteristics:

❖ Processes for both management and development activities are defined and
documented.

❖ Roles and responsibilities are clear across the organization.

❖ Training programs are implemented to build employee capabilities.

❖ Systematic reviews are conducted to identify and fix errors early.

Outcome:

❖ Consistent and standardized processes across the organization.

❖ Better management of project risks and quality.

4. Level 4: Managed

Characteristics:

❖ Processes are quantitatively managed using metrics.

❖ Quality goals are set and measured against project outcomes.


❖ Process metrics are used to improve project performance.

Outcome:

❖ Focus on managing and optimizing processes to meet quality and performance goals.

❖ Continuous monitoring and improvement of project execution.

5. Level 5: Optimizing

Characteristics:

❖ Continuous process improvement is ingrained in the organization's culture.

❖ Process metrics are analyzed to identify areas for improvement.

❖ Lessons learned from projects are used to refine and enhance processes.

❖ Innovation and adoption of new technologies are actively pursued.

Outcome:

❖ Continuous innovation and improvement in processes.

❖ High adaptability to change and efficiency in handling new challenges.

❖ Leading edge in technology adoption and process optimization.

Use of SEI CMM:

1) Capability Evaluation: Used by contract awarding authorities (like the US DoD) to assess
potential contractors' capabilities to predict performance if awarded a contract.

2) Process Assessment: Internally used by organizations to improve their own process


capabilities through assessment and recommendations for improvement. SEI CMM has been
instrumental not only in enhancing the software development practices within organizations but
also in establishing benchmarks for industry standards.
8) Identify how Automation testing is preferred over manual testing, with different tools
used for Automation Testing.
Answer: Automation Testing vs. Manual Testing
Automation testing offers several advantages over manual testing, making it a preferred
choice in many scenarios. Here are some of the key reasons:
Efficiency and Speed: Automation testing can significantly reduce the time required to run
repetitive tests. Automated tests can be executed much faster than manual tests, allowing for
more extensive testing in a shorter amount of time.
Consistency and Repeatability: Automated tests perform the same operations consistently
without human errors. This ensures that the tests are repeatable and reliable.
Coverage: Automation allows for a more extensive test coverage. Automated tests can
simulate thousands of virtual users interacting with a network, software, and web
applications. This is particularly useful for performance testing.
Cost-Effectiveness: Although the initial cost of setting up automation testing can be high, it
becomes cost-effective in the long run. Automated tests can be reused, which reduces the cost
of regression testing and the overall testing effort.
Parallel Execution: Automation testing can be run on multiple machines simultaneously,
which helps in reducing the overall test execution time.
Continuous Integration and Continuous Deployment (CI/CD): Automation testing
integrates well with CI/CD pipelines, ensuring that the code changes do not break existing
functionality and allowing for rapid release cycles.
Tools for Automation Testing
Selenium: A widely-used open-source tool for automating web applications for testing
purposes. It supports multiple browsers and operating systems.
JUnit/NUnit: Popular frameworks for unit testing in Java and .NET, respectively. They help
in writing and running repeatable automated tests.
TestNG: A testing framework inspired by JUnit and NUnit, designed for test configurations
and parallel execution.
QTP/UFT (Unified Functional Testing): A commercial tool by Micro Focus for functional
and regression test automation.
Appium: An open-source tool for automating native, mobile web, and hybrid applications on
iOS and Android platforms.
LoadRunner: A performance testing tool by Micro Focus that helps in identifying and
diagnosing performance issues in web applications.
Jenkins: An open-source automation server that supports building, deploying, and
automating any project, including testing.
Cucumber: A tool that supports Behavior Driven Development (BDD), allowing tests to be
written in plain language.
SoapUI: A tool for testing web services and APIs, supporting functional testing, load testing,
and security testing.
Robot Framework: A generic open-source automation framework for acceptance testing and
acceptance test-driven development (ATDD).

9) Explain Six Sigma in detail.


Answer: Six Sigma is the most widely used strategy for statistical quality assurance in indus
try today. Originally popularized by Motorola in the 1980s, the Six Sigma strategy
“is a rigorous and disciplined methodology that uses data and statistical analysis to
measureandimproveacompany’soperationalperformancebyidentifyingandelim
inating defects’ in manufacturing and service-related processes” [ISI08]. The term
Six Sigmaisderivedfromsixstandarddeviations—3.4 instances (defects) per million
occurrences—implying an extremely high quality standard. The Six Sigma method
ology defines three core steps:
 Define customer requirements and deliverables and project goals via well defined methods of
customer communication.
 Measure the existing process and its output to determine current quality performance (collect
defect metrics).
 Analyze defect metrics and determine the vital few causes.
If an existing software process is in place, but improvement is required, Six Sigma suggests two
additional steps:
• Improve the process by eliminating the root causes of defects.
• Control the process to ensure that future work does not reintroduce the causes of defects.
These core and additional steps are sometimes referred to as the DMAIC (define, measure, analyze,
improve, and control) method. If an organization is developing a software process (rather than
improving an existing process), the core steps are augmented as follows:
• Design the process to (1) avoid the root causes of defects and (2) to meet customer
requirements.
• Verify that the process model will, in fact, avoid defects and meet customer requirements.
10) Explain Structured programming and clean-room software development.
Answer: The sequence of cleanroom tasks for each increment is illustrated in Figure. Within the
pipeline for cleanroom increments, the following tasks occur:
Increment planning: A project plan that adopts the incremental strategy is developed. The
functionality of each increment, its projected size, and a cleanroom development schedule are created.
Special care must be taken to ensure that certified increments will be integrated in a timely manner.
Requirements gathering: a more-detailed description of customer-level requirements (for each
increment) is developed.
Box structure specification: A specification method that makes use of box structures is used to
describe the functional specification. Box structures “isolate and separate the creative definition of
behavior, data, and proce dures at each level of refinement”.
Formal design: Using the box structure approach, cleanroom design is a natural and seamless
extension of specification. Although it is possible to make a clear distinction between the two
activities, specifications (called black boxes) are iteratively refined (within an increment) to become
analo gous to architectural and component-level designs (called state boxes and clear boxes,
respectively).
Correctness verification: The cleanroom team conducts a series of rigorous correctness verification
activities on the design and then the code. Verification begins with the highest-level box structure
(specification) and moves toward design detail and code. The first level of correctness verification
occurs by applying a set of “correctness questions” . If these do not demonstrate that the specification
is correct, more formal (mathematical) methods for verification are used.
Code generation, inspection, and verification: The box structure speci fications, represented in a
specialized language, are translated into the appropriate programming language. Technical reviews are
then used to ensure semantic conformance of the code and box structures and syntactic correctness of
the code. Then correctness verification is conducted for the source code.
Statistical test planning: The projected usage of the software is analyzed, and a suite of test cases
that exercise a “probability distribution” of usage is planned and designed. Referring to Figure this
cleanroom activity is conducted in parallel with specification, verification, and code generation.
Statistical use testing: Recalling that exhaustive testing of computer soft ware is impossible it is
always necessary to design a finite num ber of test cases. Statistical use techniques execute a series of
tests derived from a statistical sample (the probability distribution noted earlier) of all possible
program executions by all users from a targeted population.
Structured Programming is a design technique that constrains logic flow to three constructs:
sequence, condition, and repetition. This approach was proposed to limit the procedural
design of software to a small number of predictable logical structures, which reduces program
complexity and enhances readability, testability, and maintainability. The three constructs are
fundamental:
• Sequence: This is the simplest form where one action follows another in a linear flow.
• Condition: This introduces decision-making capabilities with constructs such as if-
then-else, allowing different actions based on different conditions.
• Repetition: This allows looping, enabling a set of instructions to be executed
repeatedly based on a condition.
Graphical tools such as UML activity diagrams or flowcharts are often used to represent these
structured constructs. These tools depict procedural detail and make the design more
understandable by breaking down the logic into manageable chunks, aiding the human
understanding process known as chunking. Any program, regardless of its complexity, can be
designed and implemented using only these three constructs, though practical difficulties
might sometimes arise if they are used too rigidly.

11) Explain the Structure and Levels of CMMI in detail.


Answer: Each process area is formally assessed against specific goals and practices and is rated
according to the follow ing capability levels:

Level 0: Incomplete—the process area (e.g., requirements management) is either not


performed or does not achieve all goals and objectives defined by the CMMI for level 1
capability for the process area.
Level 1: Performed—all of the specific goals of the process area (as defined by the CMMI)
have been satisfied. Work tasks required to produce defined work products are being
conducted.
Level 2: Managed—all capability level 1 criteria have been satisfied. In addi tion, all work
associated with the process area conforms to an organizationally defined policy; all people
doing the work have access to adequate resources to get the job done; stakeholders are
actively involved in the process area as required; all work tasks and work products are
“monitored, controlled, and reviewed; and are evaluated for adherence to the process
description”.
Level 3: Defined—all capability level 2 criteria have been achieved. In addi tion, the process
is “tailored from the organization’s set of standard processes according to the organization’s
tailoring guidelines, and con tributes work products, measures, and other process-
improvement informa tion to the organizational process assets”.
Level 4: Quantitatively managed—all capability level 3 criteria have been achieved. In
addition, the process area is controlled and improved using measurement and quantitative
assessment. “Quantitative objectives for qual ity and process performance are established and
used as criteria in managing the process”.
Level 5: Optimized—all capability level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative (statistical) means to meet changing
customer needs and to continually improve the efficacy of the process area under
consideration.

Capaability level:
Maturity Levels:

12) Explain Quality Management Systems with Principles of BS EN ISO 9001:2000.


Answer: Quality Management Systems (QMS) are crucial frameworks for ensuring that
organizations meet customer and regulatory requirements while continually improving their
operational processes. The BS EN ISO 9001:2000 standard specifies requirements for a QMS
where an organization needs to demonstrate its ability to consistently provide products that
meet customer and applicable statutory and regulatory requirements and aims to enhance
customer satisfaction through the effective application of the system, including processes for
continual improvement of the system and the assurance of conformity to customer and
applicable statutory and regulatory requirements.
Principles of BS EN ISO 9001:2000:
Management Responsibility:
Leadership Commitment: Top management must demonstrate commitment to developing
and improving the QMS. This includes defining a quality policy, setting quality objectives,
and ensuring that these are understood and implemented throughout the organization.
Customer Focus: Understanding and meeting customer requirements is paramount.
Organizations should strive to exceed customer expectations by aligning their objectives with
customer needs.
Quality System:
Process Approach: The standard encourages a process approach to quality management.
This means identifying, understanding, and managing interrelated processes as a system
contributes to the organization’s effectiveness and efficiency in achieving its objectives.
Continual Improvement: A key principle is the commitment to continuous improvement.
This involves regularly reviewing and enhancing the QMS and its processes to drive better
performance.
Contract Review:
Requirement Analysis: Organizations must review contracts to ensure that customer
requirements are clearly understood and can be met. This involves identifying specific
requirements and ensuring that they can be fulfilled within the given constraints.
Feasibility Studies: Before accepting contracts, conducting feasibility studies to assess the
capability to meet the contractual obligations is essential.
Design Control:
Planning and Development: Design and development planning is critical to ensuring that
the product meets the required specifications. This involves stages like design input, design
output, design review, and verification and validation.
Control of Design Changes: Any changes in design should be systematically controlled and
reviewed to avoid unintended consequences on product quality.
Document and Data Control:
Documentation: Effective documentation is vital for maintaining a QMS. This includes
creating, managing, and controlling documents and records to ensure consistency and
traceability.
Data Management: Accurate and timely data management supports decision-making and
continuous improvement processes.
Product Identification and Traceability:
Tracking: Identifying products and tracking their status throughout production ensures that
only conforming products are used and delivered. This includes proper labeling and
documentation.
Traceability: Maintaining traceability from raw materials to finished products helps in
managing recalls and quality issues efficiently.
Process Control:
Consistency: Establishing controlled conditions for production and service delivery ensures
that processes are performed under consistent conditions to achieve the desired quality.
Preventive Action: Implementing preventive actions to eliminate potential causes of
nonconformities in products and processes is essential for maintaining quality.
Inspection and Testing:
Verification: Regular inspection and testing verify that the product meets the required
specifications. This includes both in-process and final product inspections.
Control of Nonconforming Product: Identifying, controlling, and addressing
nonconforming products prevents their unintended use and ensures that corrective actions are
taken.
Corrective and Preventive Action:
Root Cause Analysis: Investigating nonconformities to identify root causes and
implementing corrective actions to prevent recurrence is critical.
Preventive Action: Identifying potential issues and implementing preventive measures to
avoid nonconformities.
Control of Quality Records:
Record Keeping: Maintaining accurate quality records provides evidence of conformity to
requirements and effective operation of the QMS. These records should be readily accessible
and properly controlled.
Internal Quality Audits:
Audit Program: Regular internal audits assess the QMS's effectiveness and compliance.
Auditors should be independent of the areas being audited to ensure objectivity.
Management Review: Periodic reviews by top management ensure that the QMS remains
suitable, adequate, and effective.
Training:
Competence and Awareness: Ensuring that employees are trained, competent, and aware of
the relevance and importance of their activities in achieving quality objectives is
fundamental.
Servicing and Statistical Techniques:
Customer Service: Providing ongoing support and services to customers ensures satisfaction
and loyalty.
Data Analysis: Using statistical techniques to analyze data helps in understanding trends,
identifying areas for improvement, and making informed decisions
13) What are the various quality methods used to measure the quality of the
software? Explain any 2 models in brief.
Answer: Although there are many measures of software quality,8 correctness, maintainabil
ity, integrity, and usability provide useful indicators for the project team.
Correctness: A program must operate correctly or it provides little value to its users.
Correctness is the degree to which the software performs its re quired function. The most
common measure for correctness is defects per KLOC, where a defect is defined as a verified
lack of conformance to require ments. When considering the overall quality of a software
product, defects are those problems reported by a user of the program after the program has
been released for general use. For quality assessment purposes, defects are counted over a
standard period of time, typically one year.
Maintainability: Software maintenance and support accounts for more ef fort than any other
software engineering activity. Maintainability is the ease with which a program can be
corrected if an error is encountered, adapted if its environment changes, or enhanced if the
customer desires a change in requirements. There is no way to measure maintainability
directly; there fore, you must use indirect measures. A simple time-oriented metric is mean-
time-to-change (MTTC), the time it takes to analyze the change request, design an
appropriate modification, implement the change, test it, and distribute the change to all users.
Integrity: Software integrity has become increasingly important in the age of cyber terrorists
and hackers. This attribute measures a system’s ability to withstand attacks (both accidental
and intentional) to its security. Attacks can be made on all three components of software:
programs, data, and documention. To measure integrity, two additional attributes must be
defined: threat and security
Usability: Usability focuses on the user experience, measuring how easily and effectively
users can operate the software to achieve their goals. Factors influencing usability include
user interface design, documentation, and support. Usability is often assessed through user
feedback, usability testing, and metrics like the time required to perform tasks or the error
rate during usage.

You might also like