**********MID-II Question Bank ********

Q1)What are the Testing Strategies?

Q2)Explain Metrics for Analysis Model.

Metrics for the Analysis Model in software engineering assess the quality and
completeness of requirements and functional specifications. They include
Requirements Stability, measuring the frequency of changes; Requirements
Volatility, tracking the extent of requirement modifications; and
Requirements Traceability, ensuring each requirement is linked to its origin
and implementation. Functional Completeness assesses whether all required
functions are defined. Correctness measures the accuracy of requirements.
Clarity evaluates the understandability of requirements. These metrics
provide insights into the effectiveness of the analysis process, aiding in early
identification of issues and ensuring that the software requirements
accurately reflect stakeholder needs.

Q3)List the types of Software Risks.

5. *Business Risks:*
- Risks affecting the business goals and outcomes of the software project,
such as market changes, competitive pressures, and regulatory compliance.

6. *Security Risks:*
- Risks related to cybersecurity threats, data breaches, unauthorized access,
and vulnerabilities in the software system.

Q4)State the differences between TQM and Six Sigma?

Q5)What are the project management tools used by the Project
Managers?

Q6)What is meant by System Testing?

Q7)Explain about Metrics for Source code.
A)Metrics for source code in software engineering quantify various aspects of
code quality, complexity, and maintainability. Common metrics include Lines
of Code (LOC) to measure size, Cyclomatic Complexity (CC) for control flow
complexity, and Code Coverage to assess testing completeness.
Maintainability Index evaluates how easy it is to maintain code. Coupling
metrics like Coupling Between Objects (CBO) measure dependencies between
modules. Cohesion metrics like Lack of Cohesion in Methods (LCOM) assess
how well methods within a class are related. These metrics help developers
identify potential issues, optimize code, and ensure software meets quality
standards throughout the development lifecycle.

Q8)What is meant by System Complexity?

Q9)What are the objectives of CMMI?

Q10)Classify the Advantages and Disadvantages of TQM.
Q11)Explain about Metrics for software quality.
Q12)List the steps involved in Risk Identification
A)Risk identification in software engineering is a crucial process that involves
systematically identifying potential risks that could negatively impact a
project. Here are the steps involved:

1. *Preparation and Planning*

- *Define Objectives*: Understand the goals and scope of the risk
identification process.
- *Assemble a Risk Management Team*: Gather a diverse team with various
expertise to provide comprehensive insights into potential risks.

2. *Information Gathering*
- *Review Project Documentation*: Examine project plans, requirements,
design documents, and other relevant materials.
- *Conduct Interviews and Surveys*: Talk to stakeholders, team members,
and experts to gather insights on potential risks.
- *Use Checklists*: Employ standardized checklists of common risks to
ensure nothing is overlooked.

3. *Identify Risks*
- *Brainstorming Sessions*: Conduct brainstorming sessions with the team
to identify as many risks as possible.
- *SWOT Analysis*: Evaluate the project’s Strengths, Weaknesses,
Opportunities, and Threats to identify risks.
- *Risk Breakdown Structure (RBS)*: Develop an RBS to categorize risks
systematically into different levels (e.g., technical, organizational, external).

5. *Risk Analysis*
- *Qualitative Risk Analysis*: Assess the likelihood and impact of each risk
using qualitative methods (e.g., High/Medium/Low scales).
 - *Quantitative Risk Analysis*: Where applicable, use quantitative methods
(e.g., statistical models) to estimate the probability and impact of risks more
precisely.

6. *Risk Categorization*
- *Group Similar Risks*: Categorize risks into groups based on their nature
or source (e.g., technical risks, project management risks, external risks).
- *Prioritize Risks*: Rank risks based on their potential impact and
likelihood to focus on the most critical ones.

8. *Regular Updates*
- *Continuous Monitoring*: Regularly review and update the risk register as
the project progresses and new risks emerge.
- *Periodic Reassessment*: Conduct periodic reassessments of risks to
ensure all potential risks are identified and managed.

Q13)Difference between Reactive and Proactive Risk Strategies.

Q14)Describe about the RMMM Plan.

The RMMM (Risk Mitigation, Monitoring, and Management) Plan in software

engineering is a comprehensive framework designed to handle risks
throughout the lifecycle of a software project. It encompasses strategies to
identify, assess, mitigate, monitor, and manage risks effectively. Here’s an in-
depth look at each component of the RMMM Plan:

1. *Risk Mitigation*
Risk mitigation involves developing strategies and actions to reduce the
likelihood or impact of identified risks. This step includes:

- *Risk Avoidance*: Changing project plans to circumvent the risk, such as

adopting a different technology or methodology.
- *Risk Reduction*: Implementing measures to lessen the impact or likelihood
of the risk, such as additional testing or redundant systems.
- *Risk Transfer*: Shifting the risk to a third party, such as through
outsourcing or insurance.
- *Contingency Planning*: Preparing an alternative plan or workaround to be
executed if the risk occurs.

2. *Risk Monitoring*
Risk monitoring involves continuously tracking identified risks and new risks
as they emerge. This step includes:

- *Risk Indicators*: Defining and tracking key risk indicators (KRIs) that
signal potential issues.
- *Regular Reviews*: Conducting periodic risk review meetings to assess the
status of risks and the effectiveness of mitigation strategies.
- *Documentation*: Keeping detailed records of risk status, changes, and
outcomes in a risk register.
- *Alert Mechanisms*: Establishing systems for early warning signs of risk
events, enabling prompt action.

3. *Risk Management*
Risk management involves making decisions and taking actions to address
risks as they arise. This step includes:

- *Risk Assessment*: Evaluating the probability and impact of new and

ongoing risks to prioritize them.
- *Decision Making*: Choosing the appropriate response strategy based on
the risk assessment and available resources.
- *Implementation*: Executing the chosen risk response strategy and
allocating necessary resources.
- *Communication*: Keeping stakeholders informed about risk status and
actions taken.

Components of an RMMM Plan

A well-structured RMMM plan typically includes the following components:

- *Risk Identification*: Listing all potential risks along with their sources and
descriptions.
- *Risk Analysis*: Assessing the likelihood and impact of each risk using
qualitative and quantitative methods.
- *Risk Prioritization*: Ranking risks based on their severity to focus on the
most critical ones.
- *Monitoring Plan*: Outlining how risks will be tracked, including metrics,
frequency, and responsible parties.
- *Management Plan*: Describing the process for managing risks as they
occur, including roles and responsibilities.
Q15)Explain about the ISO 9000 Certification.

Q16)Summarize the types of Programming Environments in Software

Development.
Q17)Write about the Total Quality Management (TQM)
Q18)Explain about Requirements Analysis.
Requirements analysis in software engineering is a crucial process that
involves identifying, documenting, and managing the needs and expectations
of stakeholders for a new or modified product. This process ensures that the
final software product meets the specified requirements and functions as
intended.

### 1. *Purpose of Requirements Analysis*

- *Understanding Needs*: To fully understand what the stakeholders need
from the software.
- *Defining Scope*: To determine the scope of the project and establish clear
boundaries for what the software will and will not do.
- *Avoiding Misunderstandings*: To prevent misunderstandings or
assumptions that could lead to project failures.

### 2. *Types of Requirements*

- *Functional Requirements*: Define what the system should do. They
describe specific behaviors, functions, and features (e.g., user authentication,
data processing).
- *Non-Functional Requirements*: Define how the system should perform.
They include performance metrics, usability, reliability, security, and
scalability.
- *Business Requirements*: Describe the high-level business needs and
objectives (e.g., improve customer satisfaction, increase sales).
- *User Requirements*: Capture the needs of the end-users, often described
through use cases or user stories.

### 3. *Steps in Requirements Analysis*

(i) Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system. The context diagram of student result management
system is given below:

(ii) Development of a Prototype (optional): One effective way to find out what
the customer wants is to construct a prototype, something that looks and
preferably acts as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is
satisfied continuously. Hence, the prototype helps the client to visualize the
proposed system and increase the understanding of the requirements. When
developers and users are not sure about some of the elements, a prototype
may help both the parties to take a final decision.

Some projects are developed for the general market. In such cases, the
prototype should be shown to some representative sample of the population
of potential purchasers. Even though a person who tries out a prototype may
not buy the final system, but their feedback may allow us to make the product
more attractive to others.

The prototype should be built quickly and at a relatively low cost. Hence it
will always have limitations and would not be acceptable in the final system.
This is an optional activity.

(iii) Model the requirements: This process usually consists of various

graphical representations of the functions, data entities, external entities, and
the relationships between them. The graphical view may help to find
incorrect, inconsistent, missing, and superfluous requirements. Such models
include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will have
a better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.

Q19)Explain about the Art of Debugging.

Q20)Distinguish between the Black box testing and White box testing.
Q21)Explain about the RISK Components.
In software engineering, risk management is a critical aspect of project
management. Understanding and managing risks ensures that projects are
delivered on time, within budget, and with the desired quality. The key
components of risk in software engineering include:

1. Risk Identification
Definition: The process of determining what risks might affect the project and
documenting their characteristics.
Examples: Identifying potential risks like changing requirements, technology
challenges, resource availability, and stakeholder conflicts.
2. Risk Analysis
Qualitative Analysis: Evaluating the impact and likelihood of identified risks
using subjective judgment.
Tools: Risk matrices, risk probability and impact assessment.
Quantitative Analysis: Numerically analyzing the effect of risks on project
objectives.
Tools: Monte Carlo simulation, decision tree analysis, and sensitivity analysis.
3. Risk Prioritization
Definition: Ranking risks based on their potential impact and likelihood to
determine which risks require immediate attention.
Tools: Risk assessment matrices, prioritization charts.
4. Risk Response Planning
Avoidance: Changing project plans to eliminate the risk or its impact.
Example: Using a well-known technology instead of a new, untested one.
Mitigation: Reducing the probability or impact of the risk.
Example: Adding extra time to the schedule to account for potential delays.
Acceptance: Acknowledging the risk without taking any action unless it occurs.
Example: Deciding to accept the risk of occasional network outages.
Transfer: Shifting the impact of the risk to a third party.
Example: Outsourcing certain project activities to a vendor.
5. Risk Monitoring and Control
Definition: Tracking identified risks, monitoring residual risks, identifying new
risks, and evaluating risk process effectiveness throughout the project.
Activities: Regular risk reviews, status meetings, and risk audits.
Tools: Risk registers, risk dashboards, and performance metrics.
6. Risk Documentation
Definition: Keeping records of identified risks, analysis results, and response
plans.
Documents: Risk register, risk management plan, risk assessment reports.

Q22)Describe the metrics for the Design Model with formulas.

Q23)Explain about Metrics in the process and project domains.
Metrics in Process and Project Domains in Software Engineering
Metrics are quantitative measurements used to assess the effectiveness and
efficiency of software development processes and projects. They provide
valuable insights that help teams identify areas for improvement, track
progress, and make informed decisions.
Process Metrics:
Focus on optimizing the development and maintenance activities.
Examples:
Defect injection rate: Measures the number of defects introduced per unit of
effort.
Lead time: Measures the time it takes to complete a task or process.
Effort variance: Measures the difference between planned and actual effort.
Code churn: Measures the amount of code that is added, removed, or
modified.

Project Metrics:
Focus on tracking the progress and performance of a specific project.
Examples:
Velocity: Measures the amount of work completed in a specific timeframe
(e.g., sprint).
Cost: Measures the total financial expenditure of the project.
Schedule variance: Measures the difference between planned and actual
completion date.
Defect density: Measures the number of defects found per unit of code.
Benefits of using metrics:

Improved decision-making:
Data-driven insights help make informed decisions about resource allocation,
process improvement, and project management.
Increased productivity:
Identifying bottlenecks and inefficiencies allows for process optimization and
improved team performance.
Enhanced quality:
Tracking defect rates and other quality metrics helps ensure the delivery of
high-quality software.
Better communication:
Metrics provide a common language for stakeholders to discuss progress and
challenges.

Q24)Describe the Risk Mitigation and Rist Monitoring.

Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
Finding out the risk.
Removing causes that are the reason for risk creation.
Controlling the corresponding documents from time to time.
Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

To check if predicted risks occur or not.

To ensure proper application of risk aversion steps defined for risk.
To collect data for future risk analysis.
To allocate what problems are caused by which risks throughout the project.

Risk Mitigation:

To mitigate this risk, project management must develop a strategy for

reducing turnover. The possible steps to be taken are:

Meet the current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
Mitigate those causes that are under our control before the project starts.
Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
Organize project teams so that information about each development activity
is widely dispersed.
Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner.
Assign a backup staff member for every critical technologist.
Risk Monitoring:

As the project proceeds, risk monitoring activities commence. The project

manager monitors factors that may provide an indication of whether the risk
is becoming more or less likely. In the case of high staff turnover, the
following factors can be monitored:

General attitude of team members based on project pressures.

Interpersonal relationships among team members.
Potential problems with compensation and benefits.
The availability of jobs within the company and outside it.

Q25)Compare ISO and SEI- CMM model.

Q26)Discuss about Key Process Areas of a Software Organization with
the help of Table.
### Detailed Description

1. **Requirements Management**
- Ensures traceability and alignment between the project deliverables and user expectations.
- Manages changes to requirements over the project lifecycle.

2. **Project Planning**
- Includes activities like work breakdown structure creation, resource allocation, and budget
estimation.
- Sets the foundation for project execution and control.

3. **Project Monitoring and Control**

- Involves regular tracking of project milestones and deliverables.
- Uses metrics to assess project health and make necessary adjustments.

4. **Supplier Agreement Management**

- Ensures that suppliers and vendors meet their commitments.
- Manages procurement processes and contract negotiations.

5. **Measurement and Analysis**

- Establishes measurement objectives aligned with business goals.
- Uses data to improve decision-making and project outcomes.

6. **Process and Product Quality Assurance**

 - Conducts audits and reviews to ensure compliance with standards.
- Identifies process improvements and ensures corrective actions are taken.

7. **Configuration Management**
- Controls changes to software artifacts such as code, documents, and data.
- Maintains version history and ensures consistent project documentation.

Q27)Describe about Design Modeling Tools.

Q28)Explain different types of ISO 9000 models.

The ISO 9000 series is a set of international standards for quality
management and quality assurance. These standards help organizations
ensure they meet customer and other stakeholder needs within statutory and
regulatory requirements related to a product or service. Here are the main
types of ISO 9000 models:

### ISO 9000:2015

**ISO 9000:2015** covers the basic concepts and language used in quality
management systems. It provides fundamental principles and vocabulary that
form the foundation for understanding and applying the other standards in
the ISO 9000 family. Key topics include:

- Quality management principles

- Quality management system fundamentals
- Terminology

### ISO 9001:2015

**ISO 9001:2015** is the standard that specifies the requirements for a

quality management system (QMS). Organizations use it to demonstrate their
ability to consistently provide products and services that meet customer and
regulatory requirements. Key aspects include:

- Context of the organization

- Leadership and commitment
- Planning
- Support (resources, competence, awareness, communication, documented
information)
- Operation (planning and control, requirements for products and services,
design and development, control of externally provided processes, products,
and services)
- Performance evaluation
- Improvement

### ISO 9004:2018

**ISO 9004:2018** provides guidance for organizations to achieve sustained

success through a quality management approach. It focuses on enhancing the
overall performance of an organization. Unlike ISO 9001, it is not intended for
certification but rather for continuous improvement. Key elements include:

- Sustained success through quality management

- Quality of an organization and its products and services
- Strategy and policy deployment
- Resource management
- Process management
- Improvement, learning, and innovation

### ISO 19011:2018

**ISO 19011:2018** provides guidance on auditing management systems,
including the principles of auditing, managing an audit program, conducting
management system audits, and evaluating the competence of individuals
involved in the audit process. It applies to various types of management
systems, such as quality, environmental, and occupational health and safety
management systems. Key components are:

- Principles of auditing
- Managing an audit program
- Conducting an audit
- Competence and evaluation of auditors

### ISO/TS 9002:2016

**ISO/TS 9002:2016** provides guidance on the application of ISO

9001:2015. It offers explanations, examples, and approaches to assist
organizations in implementing a quality management system based on ISO
9001:2015 requirements. Key topics include:

- Understanding the context of the organization

- Leadership and commitment
- Planning for the quality management system
- Support for the QMS
- Operation of the QMS
- Performance evaluation
- Improvement of the QMS

### Other Related Standards

- **ISO 10001:2018**: Quality management — Customer satisfaction —

Guidelines for codes of conduct for organizations.
- **ISO 10002:2018**: Quality management — Customer satisfaction —
Guidelines for complaints handling in organizations.
- **ISO 10003:2018**: Quality management — Customer satisfaction —
Guidelines for dispute resolution external to organizations.
- **ISO 10004:2018**: Quality management — Customer satisfaction —
Guidelines for monitoring and measuring.

These standards collectively help organizations implement effective quality

management systems, ensuring consistent quality, improving customer
satisfaction, and driving continuous improvement.

Q29)Explain about White box testing techniques with example.

Q30)Discuss about the Test strategies for conventional software