Evolving Role of Software (UNIT 1)

Software has undergone a major transformation over the decades.

Initially, software was simple and used only for basic calculations and automation.
Today, software has become a critical component in almost every field — business, communication,
science, education, medicine, entertainment, and government systems.
The role of software is continuously evolving in the following ways:

✅ 1. From Simple Programs to Complex Systems

Early software performed limited tasks like arithmetic, payroll, and record keeping.
Modern software controls:
 Banking systems
 Air traffic
 Smartphones

✅ 2. From Support Function to Core Business Asset

Software is no longer just a supporting tool; it is now central to business operations.
Examples:
 E-commerce platforms
 ERP systems
 Digital payments (UPI)
 Supply chain automation

✅ 3. Growth of Embedded and Real-Time Software

Software is embedded into:
 Cars
 Medical devices
 Smart home appliances
 Robots
These systems depend on real-time decision making.

✅ 4. Artificial Intelligence & Machine Learning

Modern software can learn from data, recognize patterns, and make decisions.
Used in:
 Face recognition
 Recommendation systems
 Self-driving vehicles
 Fraud detection

✅ 5. Internet, Networks & Cloud Computing

Software now connects millions of devices and users:
 Cloud services (AWS, Azure, Google Cloud)
 Social media
 Video conferencing
 Online storage (Google Drive)
Software is delivered as a service (SaaS), accessible anytime and anywhere.

✅ 6. Mobile & Web-Based Applications

Software now runs on a variety of platforms such as Android, iOS, and browsers.
Apps support:
 Banking
 Education
Software Crisis & Myths (UNIT 1)
Software Crisis refers to the major problems faced by the software industry during the early years of
software development.
These problems occurred because software systems were becoming large and complex, while
development techniques were still primitive.

✅ 1. Software Crisis
Software crisis describes the difficulties in developing software on time, within budget, and with good
quality.
Major Causes of Software Crisis
1. Increasing complexity of software systems
2. Poor project management
3. Unclear or changing requirements
4. Lack of proper design and testing methods
5. Shortage of trained professionals
6. Inadequate tools and techniques
7. Weak communication among stakeholders

Effects or Symptoms of Software Crisis

 Cost overruns
 Project delays
 Low-quality and unreliable software
 High maintenance cost
 Project failure or cancellation
 System crashes and security issues
The crisis highlighted the need for structured software engineering practices.

✅ 2. Software Myths
Software myths are false beliefs or misunderstandings about software development.
These myths create unrealistic expectations and lead to failures.

A) Management Myths
1. “Adding more people to a late project speeds it up.”
(Fact: It often increases delays.)
2. “If we have good tools, we don’t need proper planning.”
3. “A running program is the only work product that matters.”

B) Customer Myths
1. “Software requirements can be written once and never change.”
2. “A general statement of need is enough to start coding.”
3. “Changes in requirements cost nothing.”

C) Developer Myths
1. “Once the program works, the job is finished.”
2. “Documentation is not necessary.”
3. “Testing is needed only when development is finished.”
Software Engineering (UNIT 1)
Software Engineering is the systematic, disciplined, and quantifiable approach to the development,
operation, and maintenance of software.
It applies engineering principles to produce high-quality, reliable, and cost-effective software systems.

✅ 1. Definition
Software engineering is defined as:
✔ “The application of engineering principles to software development to ensure high quality,
maintainability, and reliability.”
It focuses on solving the problems raised during the software crisis.

✅ 2. Need for Software Engineering

 Software became large and complex
 High cost of development
 Unreliable and low-quality software
 Increasing user expectations
 Frequent changes in requirements
Software engineering provides structured methods for producing high-quality software.

✅ 3. Characteristics of Software Engineering

1. Systematic approach – follows defined methods and processes
2. Engineering principles – design, testing, documentation
3. Focus on quality – reliability, maintainability, performance
4. Team-oriented – supports group development
5. Lifecycle-based – considers all phases from requirements to maintenance

✅ 4. Software Engineering Activities

Software engineering covers several major activities:
A) Requirements Analysis
Understanding what the user needs.
B) System Design
Planning architecture, data design, and user interfaces.
C) Coding / Implementation
Converting design into program code.
D) Testing
Finding and fixing errors to ensure quality.
E) Deployment
Installing software in the user environment.
F) Maintenance
Improving and fixing software after delivery.

✅ 5. Importance / Benefits
 Reduces development cost and time
 Improves software quality
 Allows building of large, complex systems
 Ensures proper documentation
 Helps avoid failures and delays
 Supports teamwork and project management
Linear Sequential Model (Waterfall Model) (UNIT 1)
The Linear Sequential Model, also known as the Waterfall Model, is one of the earliest and simplest
software development process models.
It follows a step-by-step, top-down, sequential approach, where each phase must be completed before
moving to the next.

✅ 1. Definition
The Linear Sequential Model is a systematic, plan-driven software process model in which development
flows downward through phases, like a waterfall.

✅ 2. Phases of the Linear Sequential Model

1. Requirements Analysis
 Collect and document all system requirements
 Create Software Requirements Specification (SRS)

2. System Design
 Convert requirements into design
 Includes architecture, database design, interface design

3. Implementation (Coding)
 Actual programming based on design
 Modules and components are built

4. Testing
 Testing of modules and the whole system
 Find and fix errors
 Includes unit testing, integration testing, system testing

5. Deployment
 Install the software in the user environment
 Make it operational

6. Maintenance
 Fix issues found after deployment
 Add new features and improvements

✅ 3. Characteristics
 Linear and rigid
 Each phase has specific deliverables
 Easy to understand and manage
 Best for well-defined requirements

✅ 4. Advantages
✔ Simple and easy to follow
✔ Well-documented process
✔ Good for small projects
✔ Suitable when requirements are stable
✔ Each phase is clearly defined
Prototyping Model (UNIT 1)
The Prototyping Model is a software development model in which a working model (prototype) of the
system is built early in the project to understand and refine user requirements.
It is especially useful when requirements are unclear or incomplete.

✅ 1. Definition
The Prototyping Model is an iterative development process where a prototype is created, tested by
users, and refined repeatedly until the final requirements are understood and agreed upon.

✅ 2. Steps in the Prototyping Model

1. Requirements Gathering
Basic, unclear, or partial requirements are collected from the user.
2. Quick Design
A rough design or layout is prepared for the user interface or main functions.
3. Build Prototype
A working model is developed quickly showing:
 Screens
 Inputs
 Outputs
 Basic functionality
(Not a complete system)
4. User Evaluation
Users test and provide feedback on what they liked or disliked.
5. Refinement
Based on feedback, the prototype is improved and refined many times.
6. Final System Development
After requirements become clear, the actual system is developed using SDLC.
7. Testing & Deployment
The final system is tested and installed.

✅ 3. Types of Prototyping
A) Throwaway Prototype
 Built only to understand requirements
 Discarded after use
 Actual system developed separately
B) Evolutionary Prototype
 Developed step by step
 Improved gradually
 Becomes the final system

✅ 4. Advantages
✔ Helps clarify unclear requirements
✔ Early user involvement increases satisfaction
✔ Detects problems early
✔ Reduces risk of project failure
✔ Improves communication between users and developers
RAD Model (Rapid Application Development) (UNIT 1)
The Rapid Application Development (RAD) model is a software development methodology that
focuses on quick development and fast delivery.
It uses prototyping, iterative development, and reusable components to speed up the process.
RAD is useful when the project requires short development time and frequent customer feedback.

✅ 1. Definition
RAD is an incremental and rapid software development model where the project is divided into small
modules, and each module is developed quickly and delivered in a short cycle.
RAD emphasizes:
 Fast development
 User involvement
 Prototyping
 Reusability

✅ 2. Phases of RAD Model

1. Requirements Planning Phase
 Users, managers, and developers discuss the goals
 Identify business needs and constraints
 Requirements are gathered quickly using workshops or JAD (Joint Application Design)

2. User Design Phase

 Users actively participate
 Prototypes are built
 Feedback is collected
 System design and user interface evolve together

3. Construction Phase
 Actual development begins
 Components are built using:
o Reusable modules
o Automated tools
o Code generators
o CASE tools
 Testing is performed in parallel with development

4. Cutover (Implementation) Phase

 Final testing, data conversion
 User training
 System delivered to the customer

✅ 3. Characteristics of RAD
 Very short development cycle
 High user involvement
 Extensive use of prototypes
 Emphasis on modularization
 Uses automated tools for faster development
Evolutionary Product & Process (UNIT 1)
The evolutionary approach in software engineering focuses on building software step-by-step and
improving it continuously based on user feedback and changing requirements.
Both the product (software) and the process (development method) evolve over time.

✅ 1. Evolutionary Product
The software product evolves as new features are added, defects are fixed, and user requirements
change.
Characteristics of Evolutionary Product
 Developed incrementally (in small versions or releases)
 Each version adds more features
 Based on continuous user feedback
 Suitable for projects where requirements are unclear
 Supports rapid changes in functionality
Examples
 Mobile apps (updated regularly)
 Web applications
Benefits
 Early delivery of working software
 Users get a usable version quickly
 Easier to adapt to changing needs
 Lower risk because feedback is continuous

✅ 2. Evolutionary Process
The software development process evolves along with the product.
It is iterative, adaptive, and allows cycles of improvements.
Characteristics of Evolutionary Process
 Based on repeated cycles (iterations)
 Each cycle includes:
o Planning
o Design
o Coding
o Testing
o Delivery
 Supports incremental improvements
 Allows parallel development of components
Common Evolutionary Process Models
1. Incremental Model
Software is built and delivered in increments. Each increment adds features.
2. Spiral Model
Development proceeds in loops, focusing on risk analysis and prototyping.
3. Prototyping Model
Early prototype built, refined through user feedback.
4. Agile Development
Modern evolutionary process using short iterations (sprints).

✅ 3. Advantages of Evolutionary Product & Process

 Flexible to changing requirements
 Lower project risk
 Early availability of working software
Project Management Concepts: People (UNIT 1)
In software project management, People are the most important resource.
The success or failure of a software project largely depends on the skills, motivation, communication,
and coordination of the people involved.
The "People" component deals with managing the human side of software development.

✅ 1. Importance of People in Software Projects

 Software is built by people, not machines
 Productivity depends heavily on the team's skills
 Good teamwork leads to faster and better-quality software
 Planning, communication, leadership, and motivation are essential

✅ 2. Roles of People in a Software Project

A) Project Manager
 Plans, organizes, schedules, and controls the project
 Manages risks, resources, and communication
 Ensures project is completed on time and within budget
B) Software Engineers / Developers
 Write, test, and debug code
 Implement design into functional modules
 Cooperate with team members
C) System Analyst
 Interacts with clients
 Understands user needs
 Converts requirements into specifications
D) Designers / Architects
 Create system architecture
 Define interfaces, data structures, and modules
E) Testers / QA Engineers
 Test software for defects
 Ensure quality, reliability, and security
F) Users / Stakeholders
 Provide requirements and feedback
 Validate final system output

✅ 3. Key Aspects of People Management

1. Communication
 Clear and continuous communication avoids misunderstandings
 Meetings, reports, documentation, and collaboration tools are used
2. Motivation
 Motivated team works with higher productivity
 Managers must provide encouragement, rewards, and a good work environment
3. Team Building
 Focus on cooperation instead of competition
 Teamwork improves problem-solving
4. Training & Skill Development
 Regular training improves technical and soft skills
 Helps team stay updated with new technologies
5. Leadership
 Strong leadership provides direction
Project Management Concepts: Product & Process (UNIT 1)
In software project management, Product and Process are two key components that determine how
software is developed and what the final outcome will be.

✅ 1. Product (What is being built?)

The Product refers to the software system that is being designed, developed, and delivered.
It includes all features, functionalities, and constraints of the application.
✔ The Product defines:
 What the software will do
 The functions it must perform
 Performance requirements
 User interface and user needs
 Input/output behavior
 Quality requirements
 Reliability and security needs
✔ Key Product Factors
1. Product Scope
o Defines the boundaries of the software
o What will be included or excluded
2. Product Objectives
o Purpose of the system
o Expected results
3. Product Requirements
o Functional and non-functional requirements
o Specifications and design constraints
4. Users/Stakeholders
o Who will use the product
o Their needs and preferences
✔ Importance of Product in Project Management
 Guides planning and estimation
 Helps developers understand what to build
 Ensures user satisfaction
 Forms the basis for acceptance testing
 2. Process (How it is built?) (UNIT 1)
The Process is the set of activities, methods, and tools used to build the product.
It defines how development will take place.
✔ The Process defines:
 Development methodology (Waterfall, Agile, Spiral, RAD, etc.)
 The sequence of activities
 Roles and responsibilities
 Tools and technologies used
 Quality assurance and testing methods
✔ Key Process Activities
1. Planning
o Scheduling, resource allocation, budgeting
2. Requirements Analysis
o Understanding user needs
3. Design
o Architecture, data structures, interfaces
4. Coding
o Writing source code
5. Testing
o Verifying correctness and quality
6. Deployment
o Delivering the product to users
7. Maintenance
o Fixing bugs and adding improvements
✔ Importance of Process in Project Management
 Ensures project moves in a structured manner
 Improves productivity and quality
 Reduces risks and errors
 Helps achieve deadlines
 Provides repeatability and predictability

✅ 3. Relationship Between Product and Process

 The product defines what is to be developed
 The process defines how it will be developed
 Good product understanding + good process = successful software
 A poor process can result in delays and low-quality software
 A poor product definition leads to incorrect system building
W5HH Principle (UNIT 1
The W5HH Principle was introduced by Barry Boehm as a simple and effective approach to project
planning and management.
It helps project managers ensure that all important questions are answered before and during a software
project.
This principle is based on 7 key questions, each beginning with W or H, hence called W5HH.

✅ The W5HH Questions

1✅⃣ Why is the system being developed?
 Defines purpose, business need, and project objectives
 Helps justify the project

2✅⃣ What will be done?

 Defines the scope, requirements, deliverables, and features
 Clarifies what the final product will include

3✅⃣ When will it be done?

 Defines the schedule, timeline, milestones, and deadlines
 Helps track project progress

4✅⃣ Who is responsible?

 Specifies roles and responsibilities
 Assigns tasks to team members (developers, testers, project manager)

5✅⃣ Where are they located?

 Identifies the workplace location of team members
 Useful for distributed teams or global projects
 Helps plan communication channels

6✅⃣ How will the job be done?

 Describes the methodology and process model used (Agile, Waterfall, RAD, etc.)
 Includes tools, technologies, design, testing methods, and workflow

7✅⃣ How much will it cost?

 Defines the budget, resources, effort estimation, and overall cost
 Helps control project expenses

✅ Purpose of W5HH Principle

 Ensures complete project understanding
 Reduces risks and uncertainties
 Helps in planning, control, and team coordination
 Supports successful project execution
 Ensures no important factor is missed
Q1)Measures, Metrics and Indicators Measure

Measures, Metrics and Indicators Measure: The Quantitative indication of the extent, amount,
dimension, or size of some attribute of a product or process. A single data point. Metrics: The degree
to which a system, component, or process possesses a given attribute. Relates several measures (e.g.
average number of errors found per person hour).

Indicators: A combination of metrics that provides insight into the software process, project or
product.

Metrics in the Process and Project Domains: - The only rational way to improve any process is

 To measure specific attributes of the process.

 Develop a set of meaningful metrics based on these attributes.

 Use the metrics to provide indicators that will lead to a strategy for improvement

Software Measurement

Software measurement is a quantified attribute of a characteristic of a software product or the

software process. Measurement helps in estimation, quality control, productivity assessment and
project control throughout a software project.

Software measurements are of two categories

1. Direct measures 2. Indirect measures.

1. Direct measures:- It include software processes like cost and effort applied and products like lines
of code produced, execution speed, and other defects that have been reported.

2. Indirect measures:- It include products like functionality, quality, complexity, reliability,

maintainability, and many more.

Measurement process is characterized by a set of five activities, they are :-

 Formulation: This performs measurement and develops appropriate metric for software under
consideration.

 Collection: This collects data to derive the formulated metrics.

 Analysis: This calculates metrics and the use of mathematical tools.

 Interpretation: This analyzes the metrics to attain insight into the quality of representation.

 Feedback: This communicates recommendation derived from product metrics to the software team.
Q2)Software Quality Metrics
Software metrics can be classified into three categories −
 Product metrics − Describes the characteris cs of the product such as size, complexity, design
features, performance, and quality level.
 Process metrics − These characteristics can be used to improve the development and
maintenance activities of the software.
 Project metrics − This metrics describe the project characteris cs and execu on. Examples
include the number of software developers, the staffing pattern over the life cycle of the
software, cost, schedule, and productivity.

Some metrics belong to multiple categories. For example, the in-process quality metrics of a project
are both process metrics and project metrics.

Software quality metrics are a subset of software metrics that focus on the quality aspects of the
product, process, and project. These are more closely associated with process and product metrics
than with project metrics.

Software quality metrics can be further divided into three categories −

 Product quality metrics

 In-process quality metrics
 Maintenance quality metrics

Product Quality Metrics

This metrics include the following −

 Mean Time to Failure

 Defect Density
 Customer Problems
 Customer Satisfaction

Mean Time to Failure .

It is the time between failures. This metric is mostly used with safety critical systems such as the
airline traffic control systems, avionics, and weapons.

Defect Density It .

measures the defects relative to the software size expressed as lines of code or function point, etc.
i.e., it measures code quality per unit. This metric is used in many commercial software systems.

Customer Problems It measures the problems that customers encounter when using the product. It
contains the customer’s perspective towards the problem space of the software, which includes the
non-defect oriented problems together with the defect problems.
Q3)Software Project Planning

Project planning is an organized and integrated management process that focuses on the actions
necessary for the project's practical completion. It avoids problems in the project, such as changes in
the project's or organization's objectives, resource shortages, and so forth. Project planning also aids
in improved resource use, and the most efficient use of a project's allowed time. The following are the
other project planning goals.

•It establishes the project management team's duties and responsibilities.

•It guarantees that the project management team adheres to the company's goals.

•It examines the schedule's viability and the needs of the users.

•It establishes the project's limits.

Some guidelines are followed when designing a project. These guidelines are outlined below.
•Planning: Before starting a project, it's essential to plan. Objectives and timelines should be clear and
understandable for efficient planning.

•Risk analysis: Before beginning the project, senior management and the team should think about
the potential hazards. Changes in requirements, for example, maybe desired by the user while the
project is in process. In this instance, time and cost estimations should be made by the requirements
(new requirements).

•Monitoring the project's progress: The project plan should be tracked and adjusted as needed once it
is completed.

•Meet quality standards and offer high-quality results: The project plan should outline the project
management team's procedures to assure software quality. The project's duration and cost are
calculated based on the quality assurance approach.

•Flexibility to accommodate changes: The result of project planning is recorded in the form of a
project plan, which should allow for new modifications to be accommodated as the project
progresses.

. The project planning process also includes the following steps. •The project's objectives and scope
•Techniques for undertaking project planning •Individuals participating in the project's effort
(measured in time) • Timeline and milestones for the project •The project will require specific
resources. •The project's potential dangers.
Q4)RMMM plan.

A risk management technique is usually seen in the software Project plan. This can be divided into
Risk Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are done as part
of risk analysis. As part of the overall project plan project manager generally uses this RMMM plan. In
some software teams, risk is documented with the help of a Risk Information Sheet (RIS). This RIS is
controlled by using a database system for easier management of information i.e creation, priority
ordering, searching, and other analysis. After documentation of RMMM and start of a project, risk
mitigation and monitoring steps will start. Risk Mitigation : It is an activity used to avoid problems
(Risk Avoidance).

Steps for mitigating the risks as follows.

[Link] out the risk. [Link] causes that are the reason for risk creation. [Link] the
corresponding documents from time to time. [Link] 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.

[Link] check if predicted risks occur or not. [Link] ensure proper application of risk aversion steps
defined for risk. [Link] collect data for future risk analysis. [Link] allocate what problems are caused by
which risks throughout the project.

Risk Management and planning : It assumes that the mitigation activity failed and the risk is a reality.
This task is done by Project manager when risk becomes reality and causes severe problems. If the
project manager effectively uses project mitigation to remove risks successfully then it is easier to
manage the risks. This shows that the response that will be taken for each risk by a manager. The
main objective of the risk management plan is the risk register. This risk register describes and focuses
on the predicted threats to a software project.

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.

Drawbacks of RMMM: •It incurs additional project costs. •It takes additional time. • For larger
projects, implementing an RMMM may itself turn out to be another tedious project. • RMMM does
not guarantee a risk-free project, infact, risks may also come up after the project is delivered.
Project Scheduling – (UNIT 3)
Project scheduling is a key activity of project management that deals with planning, organizing, and
controlling the timeline of project tasks. It ensures that the project is completed on time, within budget,
and with optimum use of resources.

1. Definition of Project Scheduling

Project scheduling is the process of identifying project activities, arranging them in a logical sequence,
estimating time and resources, and developing a timeline (schedule) for the execution of the project.
It answers three major questions:
 What activities need to be done?
 When should they be done?
 Who will do them?

2. Objectives of Project Scheduling

 To ensure timely completion of the project
 To allocate resources optimally
 To find the critical path and avoid delays
 To monitor project progress systematically
 To minimize cost overruns
 To improve coordination among teams and departments

3. Elements of Project Scheduling

The project schedule is built using the following components:
a) Activities / Tasks
Work units that need to be done (e.g., design, coding, testing).
b) Milestones
Major events or checkpoints (e.g., “Phase 1 completed”).
c) Time Estimation
Duration required to complete each task, using methods like:
 Expert judgment
 Historical data
 PERT estimation (Optimistic, Pessimistic, Most likely)
d) Resources
People, tools, equipment, budget, or materials required.
e) Dependencies
Relationships between tasks:
 Finish-to-Start (FS)
 Start-to-Start (SS)
 Finish-to-Finish (FF)

4. Techniques Used in Project Scheduling

1. Gantt Chart
A bar chart representing the start and finish dates of tasks. It shows:
 Task duration
 Overlapping tasks
 Sequence of activities
 Overall project timeline
2. PERT (Program Evaluation and Review Technique)
Used when activity time is uncertain.
Uses three time estimates:
 Optimistic
  Most likely
 Pessimistic
Helpful in research and development projects.
3. CPM (Critical Path Method)
Used when task time is predictable.
Identifies the longest path in the project network diagram.
Critical path = minimum time needed to complete the project.
4. Network Diagrams (AOA / AON)
Flow diagrams showing sequence and dependencies of tasks.

5. Steps in Project Scheduling

1. Identify activities
2. Define sequence and dependencies
3. Estimate time and resources
4. Develop the schedule using Gantt, CPM, or PERT
5. Identify critical path
6. Allocate resources
7. Monitor and control the schedule continuously

6. Importance of Project Scheduling

 Prevents project delays
 Helps in cost control
 Improves team coordination
 Enhances resource utilization
 Facilitates progress tracking
 Increases project predictability and reliability

7. Common Scheduling Problems

 Inaccurate time estimation
 Resource overallocation
 Unexpected changes or risks
 Poor communication
 Overdependence between tasks
People’s Efforts – Concepts in Project Management (UNIT 3)
In any project, people are the most important resource. Successful project completion depends on how
effectively team members work, communicate, coordinate, and contribute their skills.
The term “People's Efforts” refers to the human role, skill, motivation, and teamwork needed to
complete a project.

1. Meaning of People’s Efforts

People’s efforts include the knowledge, skills, behavior, communication, creativity, and teamwork of
all individuals involved in the project.
These efforts directly influence:
 Project quality
 Project productivity
 Project cost
 Project completion time

2. Importance of People’s Efforts

People’s efforts are important because:
 Software engineering is a human-centered activity.
 No matter how good the tools or technology are, the project succeeds only when people perform
effectively.
 Good teamwork leads to faster problem-solving and higher efficiency.
 Motivated and skilled people reduce errors, delays, and project risks.

3. Key Aspects of People’s Efforts

a) Skills and Expertise
The team must have proper technical and managerial skills:
 Programming
 Testing
 Documentation
 Designing
 Project planning
b) Communication
Effective communication ensures:
 Clear understanding of requirements
 Smooth coordination
 Faster issue resolution
 Reduced conflicts
c) Motivation
Motivated team members:
 Work with dedication
 Produce higher-quality output
 Take initiative
 Support each other in challenges
d) Teamwork
Team efforts include:
 Dividing tasks
 Helping each other
 Sharing knowledge
 Maintaining collaboration
Task Set, Task Network, and Scheduling (UNIT 3)
1. Task Set
Definition
A task set is the complete collection of tasks, activities, and work products required to complete a
particular project phase or the entire project.
It defines what work needs to be done.
Characteristics
 Depends on project type (e.g., web app, mobile app, system software)
 Depends on project size, complexity and development model
 Includes both technical tasks and managerial tasks
Typical Task Set in Software Engineering
1. Communication Tasks
→ Requirement gathering, meetings, client discussion
2. Planning Tasks
→ Estimation, scheduling, resource allocation
3. Modeling Tasks
→ Analysis, design (DFDs, UML diagrams)
4. Construction Tasks
→ Coding, testing
5. Deployment Tasks
→ Delivery, maintenance, training
Task sets help in process tailoring — choosing tasks suitable for a project.

2. Task Network
Definition
A task network (activity network) is a graphical representation showing:
 The tasks of the project
 The sequence in which they must be performed
 The dependencies among tasks
It is usually drawn using PERT/CPM network diagrams.
Purpose
 To visualize task flow
 To identify task dependencies
 To detect the critical path
 To help in scheduling and avoiding delays
Components of a Task Network
 Nodes → Represent tasks/activities
 Arrows → Represent task sequence & dependency
 Start & End nodes → Define project boundaries
Types of Dependencies
1. Finish-to-Start (FS) – Most common
2. Start-to-Start (SS)
3. Finish-to-Finish (FF)
4. Start-to-Finish (SF)
Example (Simple Task Network)
Requirement → Design → Coding → Testing → Deployment
(Each task depends on completion of the previous one)
Scheduling (UNIT 3)
Scheduling is the process of allocating time and resources to tasks and arranging them in a timeline to
complete the project within deadline.
Scheduling answers:
 What tasks to do?
 When to do them?
 Who will do them?
 How long will they take?
Goals of Scheduling
 Complete project on time
 Use resources efficiently
 Avoid resource conflicts
 Reduce costs
 Identify critical tasks
 Track progress systematically
Steps in Scheduling
1. Identify all tasks (Task Set)
2. Arrange them in sequence (Task Network)
3. Estimate time & resources for each task
4. Identify the critical path
5. Create the schedule using:
o Gantt Chart
o PERT/CPM
o Resource charts
6. Monitor progress and update schedule regularly

Relationship Between Task Set, Task Network & Scheduling

Concept Meaning Purpose

Task Set List of all tasks Defines what work must be done

Task Network Graphical flow of tasks with dependencies Shows order & relationship between tasks

Scheduling Timeline and resource allocation Decides when and who will do tasks

Flow:
Task Set → Task Network → Scheduling
Earned Value (EV) Analysis (UNIT 3)
EV Analysis (Earned Value Analysis) is a project performance measurement technique used to
compare the planned progress of a project with the actual progress.
It integrates scope, time, and cost to measure project performance accurately.
It tells the project manager:
 How much work is actually completed?
 Are we ahead or behind schedule?
 Are we under or over the budget?

1. Key Terms in EV Analysis

1. Planned Value (PV)
Also called Budgeted Cost of Work Scheduled (BCWS).
This is the budgeted cost of the work planned to be completed by a certain time.

2. Earned Value (EV)

Also called Budgeted Cost of Work Performed (BCWP).
This is the budgeted cost of the actual work that has been completed.

3. Actual Cost (AC)

Also called Actual Cost of Work Performed (ACWP).
This is the actual money spent to complete the work.

2. Important EV Analysis Formulas

A) Schedule Variance (SV)
SV = EV – PV
 SV > 0 → Ahead of schedule
 SV < 0 → Behind schedule

B) Cost Variance (CV)

CV = EV – AC
 CV > 0 → Under budget
 CV < 0 → Over budget

C) Schedule Performance Index (SPI)

SPI = EV / PV
 SPI = 1 → On schedule
 SPI > 1 → Ahead
 SPI < 1 → Behind

D) Cost Performance Index (CPI)

CPI = EV / AC
 CPI = 1 → On budget
 CPI > 1 → Under budget
 CPI < 1 → Over budget
Software Quality Concepts (UNIT 3)
Software quality refers to the degree to which a software product satisfies customer requirements,
performs reliably, and is free from defects. It ensures that the software meets both functional and non-
functional expectations.
Software quality is not only about “working software” but about correctness, usability, performance,
security, maintainability, and reliability.

1. Definition of Software Quality

Software quality is the conformance of software to its requirements and standards.
High-quality software:
 Works as expected,
 Contains few or no defects,
 Is easy to use and maintain,
 Performs efficiently,
 Is secure and reliable.

2. Two Dimensions of Software Quality

A) Product Quality
Refers to how good the software product is.
Includes qualities like reliability, correctness, usability, efficiency, maintainability, etc.
B) Process Quality
Refers to how good the development process is.
Better processes → fewer defects → higher quality product.

3. Software Quality Attributes (McCall’s / ISO 9126)

1. Functionality
 The software must meet the required functions.
 Includes suitability, accuracy, security.
2. Reliability
 Ability to perform consistently without failure.
 Includes fault tolerance, recoverability.
3. Usability
 Ease of learning and using the software.
 Good UI, help systems, documentation.
4. Efficiency
 Optimal use of resources (CPU, memory, time).
5. Maintainability
 Ease of correcting, updating, and improving software.
6. Portability
 Ability to run on different platforms with minimal changes.

4. Software Quality Measures

1. Quality Control (QC)
 Activities performed to check the quality of the final product.
 Includes testing, defect identification, inspection.
2. Quality Assurance (QA)
 Activities focused on improving the process of development.
 Prevents defects by defining standards, reviews, audits.
3. Metrics
Used to measure quality quantitatively:
 Defect density
Software Quality Assurance (SQA) (UNIT 3)
Software Quality Assurance (SQA) is a set of systematic activities carried out to ensure the quality of
software processes and products.
SQA focuses on preventing defects, improving processes, and ensuring that the software developed
meets the standards, requirements, and quality expectations.

1. Definition of SQA
Software Quality Assurance is a planned and systematic set of activities applied to the software
engineering process to ensure that the resulting product meets established technical standards and
customer requirements.
In simple words:
SQA ensures “quality is built into the product,” not just tested at the end.

2. Goals of SQA
 Ensure the software meets required quality standards
 Prevent defects during development
 Improve development processes
 Increase reliability, maintainability, and performance
 Ensure compliance with organizational and industry standards
 Provide confidence to customers and stakeholders

3. Activities of Software Quality Assurance 4. Testing

1. Standards and Procedures Although SQA focuses on processes, testing is a
Defining and enforcing: major part of QC:
 Coding standards  Unit testing
 Documentation standards  Integration testing
 Testing standards  System testing
 Design guidelines  Acceptance testing
2. SQA Plan 5. Verification and Validation (V&V)
A document that describes:  Verification – “Are we building the
 Quality goals product right?”
 Responsibilities  Validation – “Are we building the right
 Procedures product?”
 Tools and methods 6. Error and Defect Tracking
 Reviews and audits Using tools and logs to identify error sources
3. Reviews and Inspections and prevent recurrence.
 Technical reviews 7. Process Monitoring and Improvement
 Walkthroughs Ensures that development follows defined
 Code inspections processes; improves them using:
Used to detect defects early (before  Capability Maturity Model (CMM)
testing).  ISO 9001 standards

4. SQA Activities Across Development Life Cycle

Phase SQA Activity
Requirement Requirement review, validation
Design Design reviews, standards checking
Coding Code reviews, inspections
Testing Test planning, test-case evaluation
Maintenance Change control, regression testing
Software Reviews (UNIT 3)
Software reviews are a formal process of examining software artifacts (requirements, design, code, test
plans, etc.) to find errors early, ensure quality, and improve the software development process.
Reviews are an essential part of Software Quality Assurance (SQA).

1. Definition of Software Reviews

A software review is a systematic examination of software documents or code to detect defects, verify
quality, and ensure that the software meets requirements and standards.
Reviews are conducted before testing, so they help find errors early and cheaply.

2. Objectives of Software Reviews

 Detect errors early (before coding/testing)
 Ensure compliance with standards
 Improve the quality of documents (SRS, design, code)
 Reduce development cost and time
 Improve team communication
 Enhance maintainability and reliability of the software

3. Types of Software Reviews

Reviews are mainly three types:

1. Peer Review (Informal Review)

An informal meeting where team members check each other’s work.
Used in:
 Requirement documents
 Design documents
 Code
 Test cases
It is simple and fast but not very structured.

2. Walkthrough
A walkthrough is a semi-formal review where the author of the document leads the meeting and explains
the content step-by-step.
Characteristics
 Conducted by the author
 Team asks questions and finds defects
 No formal preparation needed
 Used for: requirements, design, algorithms, code
Purpose
 Educate team members
 Identify defects
 Improve understanding

3. Technical Review
A formal, structured review conducted by technical experts.
Features
 Performed by peers and experts
 Checks technical correctness
 Ensures the design or code meets requirements
 Detailed review checklist used
Used For
 SRS review
 System and software design
 Algorithms
 Test plans

4. Inspection
The most formal and rigorous type of software review.
Characteristics
 Planned and documented
 Led by a trained moderator
 Uses entry and exit criteria
 Based on reading techniques
 Produces formal reports and defect logs
Purpose
 Detect defects precisely
 Ensure standards compliance
 Improve product quality
Stages
1. Planning
2. Preparation
3. Inspection meeting
4. Rework
5. Follow-up

4. Software Artifacts Reviewed

Software reviews may be done on:
 Software Requirement Specification (SRS)
 Design documents (UML diagrams, DFDs, architecture)
 Source code
 Test plans and test cases
 User manuals and documentation
 Maintenance plans

5. Benefits of Software Reviews

 Early detection of errors (before testing)
 Reduces total cost of software development
 Improves software reliability and performance
 Enhances team communication and knowledge sharing
 Helps produce better documentation
 Reduces rework in later stages
 Improves overall software quality

6. Reviews vs Testing
Aspect Software Reviews Software Testing
Purpose Find defects in documents/code early Find defects by executing program
Timing Before coding/testing After coding
Cost impact Very low High
Type Static technique Dynamic technique
Technical Reviews – (UNIT 3)
A technical review is a formal, structured review process in software engineering where a team of
qualified and experienced technical personnel examines a software product to identify defects, check
quality, and ensure technical correctness.
Technical reviews focus on the technical aspects of software such as algorithms, logic, design, coding
style, performance, and compliance with standards.

1. Definition of Technical Review

A technical review is a formal evaluation conducted by a team of technical experts to verify that the
software artifact (SRS, design, code, test cases, etc.) is complete, consistent, and technically sound.
It ensures that the product meets technical requirements and follows industry or organizational
standards.

2. Objectives of Technical Reviews

 To detect technical defects early in development
 To verify compliance with standards and specifications
 To improve quality of technical documents and code
 To ensure correctness, consistency, and completeness
 To reduce development time and cost
 To increase team knowledge and communication

3. Inputs to a Technical Review

Before the review, the following documents must be ready:
 The artifact to be reviewed (SRS, design document, code, test plan)
 Review checklist
 Standards and guidelines
 Background documents or requirements

4. Participants in a Technical Review

1. Author – Creates the document/software being reviewed.
2. Moderator – Leads the review meeting and ensures discipline.
3. Technical Experts / Reviewers – Domain specialists who analyze technical content.
4. Recorder / Scribe – Notes defects and issues during the meeting.

5. Activities in a Technical Review (Process)

1. Planning
 Moderator schedules meeting
 Selects reviewers
 Distributes documents
2. Preparation
 Reviewers study the material individually
 Identify potential defects using a checklist
3. Review Meeting
 Moderator leads structured discussion
 Author explains the document
 Reviewers discuss defects, inconsistencies, and improvements
 Issues are logged; no fixing happens here
4. Rework
 Author corrects the defects found
 Updates the document or code
5. Follow-up
 Moderator checks if defects are resolved
 Review is officially closed

6. What Technical Reviews Check

Technical reviews evaluate:
A) Software Requirements (SRS)
 Completeness
 Correctness
 Consistency
 Feasibility
B) Design Documents
 Architecture correctness
 Interface definitions
 Dataflow and control flow
 Performance considerations
C) Code
 Logic and algorithms
 Coding standards
 Error handling
 Maintainability
D) Test Documents
 Test coverage
 Test-case correctness
 Traceability to requirements

7. Advantages of Technical Reviews

 Detect errors early and reduce rework
 Improve product quality significantly
 Ensure standards compliance
 Improve communication among developers
 Enhance maintainability and reliability
 Reduce testing time and cost

8. Technical Review vs Walkthrough

Feature Technical Review Walkthrough
Type Formal Semi-formal
Led by Moderator Author
Focus Technical correctness Understanding & learning
Preparation Required Limited
Participants Experts Team members / stakeholders
Software Reliability (UNIT 3)
is one of the most important quality attributes. It refers to the probability that software will operate
without failure for a specified time under specified conditions.

1. Definition of Software Reliability

Software reliability is the ability of software to perform its required functions without failure for a
given period in a given environment.
In simple terms:
How dependable the software is during its operation.

2. Characteristics of Software Reliability

 Indicates stability of software
 Measures how often failures occur
 Dependent on the number of defects and how severe they are
 Improves with testing, reviews, and maintenance
 Unlike hardware, software does not wear out, but design and coding errors cause failures

3. Factors Affecting Software Reliability

1. Complexity
Higher complexity → more chances of defects.
2. Development Process Quality
Good processes and standards increase reliability.
3. Testing Quality
Comprehensive testing reduces undetected defects.
4. Human Factors
Developer skill, experience, and communication affect reliability.
5. Operational Environment
Different environments (OS, loads, hardware) may affect failure rate.

4. Software Reliability Metrics

1. MTTF (Mean Time To Failure)
Average time the software operates before a failure occurs.
Higher MTTF = higher reliability.
2. MTTR (Mean Time To Repair)
Average time to fix a failure.
3. MTBF (Mean Time Between Failures)
MTBF = MTTF + MTTR
4. Failure Intensity (λ)
Number of failures per unit time.
5. Availability
Probability that software is operational at a given time.
Availability = MTBF / (MTBF + MTTR)

5. Software Reliability Models

Used to predict and measure reliability:
1. Jelinski–Moranda Model
Assumes fixed number of bugs; failures occur based on remaining defects.
2. Musa Model (Execution Time Model)
Relates reliability to execution time instead of calendar time.
3. Goel–Okumoto Model
Popular model based on Poisson failure distribution.
 ISO 9001 (Software Quality Standard) (UNIT 3)
ISO 9001 is an international standard for Quality Management Systems (QMS).
It provides a framework and guidelines to ensure organizations consistently deliver products and
services that meet customer expectations and regulatory requirements.
In software engineering, ISO 9001 helps to standardize processes, improve quality, and reduce
defects.

Key Principles of ISO 9001

1. Customer Focus
Understanding customer needs and delivering software that meets or exceeds expectations.
2. Leadership
Management must create a clear vision and support quality initiatives.
3. Engagement of People
Skilled and motivated employees improve quality and productivity.
4. Process Approach
Software development is managed as a set of defined, controlled processes.
5. Continual Improvement
Quality must be improved continuously (Kaizen approach).
6. Evidence-Based Decision Making
Decisions are made using data (metrics, reviews, audits).
7. Relationship Management
Maintaining good relationships with stakeholders, suppliers, and customers.

ISO 9001 Documentation Includes Benefits of ISO 9001 in Software

 Quality manual  Improves software process quality
 Procedure manuals  Reduces defects and rework
 Work instructions  Ensures customer satisfaction
 Forms and records  Provides international recognition
 Internal audit reports  Helps in meeting tender or client
requirements

2. SQA Plan (Software Quality Assurance Plan)

The SQA Plan is a formal document that outlines how quality will be ensured throughout the software
development lifecycle.
It describes:
 What quality activities will be performed
 Who will perform them
 How they will be performed

Contents of an SQA Plan

1. Purpose and Scope  Developers
Defines the objective of the SQA plan and what  Testers
parts of the system it covers.  Project managers
2. Software Standards to Be Followed 4. Review and Audit Procedures
 Coding standards Includes:
 Documentation standards  Requirements review
 Testing standards  Design review
 ISO 9001, IEEE standards  Code inspection
3. SQA Responsibilities  SQA audits
Assigning roles:  User manual
 SQA team
Version Control – (UNIT 3)
Version Control (also called Revision Control) is a system that records changes to files over time so
that you can recall specific versions later.
It is an essential part of Software Configuration Management (SCM).
Version Control helps software teams manage multiple versions of source code, documents, and
configuration files efficiently.

1. Definition of Version Control

Version control is the process of tracking and managing changes to software artifacts such as code,
documents, and configurations.
It allows multiple developers to work together without conflicting with each other’s changes.
In simple words:
It keeps a history of changes and allows restoring any previous version.

2. Objectives of Version Control

 Maintain history of all changes
 Allow multiple developers to work simultaneously
 Recover old versions when needed
 Prevent code conflicts and overwriting
 Help in tracking bugs by checking when changes were made
 Improve coordination and productivity

3. Types of Version Control Systems

1. Local Version Control
 Simple database on a local machine
 Tracks changes to files stored on that machine
 Example: RCS (Revision Control System)
Limitation:
Not suitable for team collaboration.

2. Centralized Version Control (CVCS)

 Uses a central server that stores all versions
 Developers check out files, make changes, and commit to the central repo
 Popular examples: Subversion (SVN), CVS
Advantages:
 Easy administration
 Controlled access
Disadvantages:
 If the central server fails → entire system is down
 Requires network connection

3. Distributed Version Control (DVCS)

 Every developer has a complete copy of the repository
 Allows offline work and faster operations
 Examples: Git, Mercurial
Advantages:
 No single point of failure
 Better performance
 Excellent branching and merging
 More secure
SCM Standards – (UNIT 3)
Software Configuration Management (SCM) standards provide guidelines, rules, and best practices
for controlling changes in software projects.
They help ensure that software products are built in a consistent, controlled, and traceable manner.
SCM standards define what activities must be performed, how to document them, and how to
maintain quality during the entire software development lifecycle.

1. What Are SCM Standards?

SCM standards are formal guidelines that define:
 How software configurations will be identified
 How changes will be controlled
 How versions will be stored
 How status will be reported
 How audits will be conducted
These standards ensure that software development is organized, traceable, and repeatable, especially in
large and complex projects.

2. Important SCM Standards

A) IEEE 828 – Software Configuration Management Plan Standard
One of the most widely used SCM standards.
Purpose
Defines the content and requirements for the Software Configuration Management Plan (SCMP).
Key Elements of IEEE 828
1. Configuration Identification
2. Configuration Control
3. Configuration Status Accounting
4. Configuration Audits
5. Roles and Responsibilities
6. Tools, Techniques, and Resources
Why It Is Important?
Ensures all configuration items (CI) are properly managed and documented.

B) ISO/IEC 12207 – Software Lifecycle Processes

Defines processes for complete software development and maintenance, including SCM.
SCM Activities in ISO 12207
 Configuration identification
 Change control
 Status accounting
 Configuration audits
 Release management
ISO 12207 ensures consistency across the entire development lifecycle.

C) ISO 9001 – Quality Management Standard

Though not specifically for SCM, it influences SCM practices.
Relevance to SCM
 Requires documented procedures and records
 Ensures version control for documents and code
 Supports traceability and change management

D) Capability Maturity Model Integration (CMMI)

A framework for improving software development processes.
SCM in CMMI (UNIT 3)
SCM is a Process Area (PA).
Includes:
 Establishing baselines
 Tracking and controlling changes
 Maintaining integrity of configuration items
CMMI helps organizations achieve mature, stable SCM processes.

3. SCM Activities Defined by Standards

1. Configuration Identification
 Identifying configuration items (CI) such as code, documents, test cases, etc.
 Assigning unique names and version numbers.
2. Configuration Control
 Managing and approving changes.
 Using Change Control Boards (CCB).
3. Configuration Status Accounting
 Recording the history of changes.
 Providing reports on version status.
4. Configuration Audits
 Verification that all changes have been applied correctly.
 Ensures completeness and consistency.
5. Release Management
 Preparing software for delivery.
 Proper versioning and packaging.

4. Benefits of Using SCM Standards

 Ensures consistency in software builds
 Provides traceability of all versions
 Reduces errors due to uncontrolled changes
 Improves productivity and coordination
 Ensures compliance with quality requirements
 Helps in auditing and certification
 Supports team collaboration and version management

5. Summary Table
Standard Purpose
IEEE 828 Defines SCM Plan and processes
ISO 12207 Defines SCM across software lifecycle
ISO 9001 Quality management; supports version and document control
CMMI Defines maturity and process improvement for SCM
System Engineering: Hierarchy (UNIT 4)
System Engineering is a multidisciplinary approach used to design, develop, and manage complex
systems such as software, hardware, networks, and large integrated solutions.
To manage this complexity, system engineering uses a hierarchical structure that breaks the system into
manageable levels.
This hierarchy helps engineers understand the system from top level (overall system) to lower levels
(components and units).

1. What is System Engineering Hierarchy?

The System Engineering Hierarchy is a layered model that organizes a system into different levels,
each representing a degree of detail.
It begins with the system as a whole, followed by subsystems, components, and units.
It ensures:
 Clear understanding of requirements
 Proper division of work
 Better communication
 Easier design, testing, and maintenance

2. Levels in the System Engineering Hierarchy

Level 1: System Level
 Represents the entire system.
 Defines overall goals, requirements, and functionalities.
 Example: Complete Banking System, Air Traffic Control System.
Activities:
 Requirement analysis
 System architecture definition
 High-level design

Level 2: Subsystem Level

 The system is divided into major functional parts.
 Each subsystem performs a specific major function.
Examples of subsystems in a banking system:
 Account management subsystem
 Transaction processing subsystem
 Security subsystem
 Reporting subsystem
Purpose:
 Divide system into logical modules
 Make development and testing easier

Level 3: Components Level

 Subsystems are further divided into components.
 Components implement smaller functions.
Example:
Transaction Processing Subsystem →
 Fund Transfer Component
 Cash Withdrawal Component
 Deposit Component
Purpose:
 Increase modularity
 Assign specific responsibilities
Level 4: Modules / Units Level
 Lowest level of abstraction.
 Represents actual code modules, classes, or functions.
Example:
Fund Transfer Component →
 ValidateAccount()
 CheckBalance()
 UpdateLedger()
Activities at this level:
 Coding
 Unit testing
 Documentation

3. Why Use a Hierarchy in System Engineering?

1. Manage Complexity
Breaking a large system into smaller modules makes it easier to understand and manage.
2. Better Planning
Helps in resource allocation, scheduling, and dividing development tasks.
3. Improved Communication
Each team understands its own subsystem/component clearly.
4. Efficient Testing
Testing can be performed at multiple levels:
 Unit testing
 Component testing
 Subsystem testing
 System testing
5. Easier Maintenance
Changes in one component do not affect the entire system.

4. System Engineering Hierarchy Diagram (Conceptual)

SYSTEM
|
-------------------
| | |
Subsystem Subsystem Subsystem
| |
Components Components
| |
Units Units

5. Summary Table
Level Description Example
System Complete product Entire Banking Software
Subsystem Major functional sections Transaction subsystem
Component Smaller functional units Fund transfer module
Unit/Module Lowest-level functions Code functions or classes
Business Process Engineering (BPE) – (UNIT 4)
Business Process Engineering (BPE) is the activity of analyzing, redesigning, and improving
business processes to make an organization more efficient, productive, and customer-focused.
It aims to understand “how the business works” and redesign processes for better performance.

1. Definition
BPE is the systematic analysis and redesign of workflows and processes within an organization to
achieve significant improvement in:
 Productivity
 Quality
 Speed
 Cost efficiency
It focuses on business functions such as sales, finance, customer service, HR, etc.

2. Objectives of BPE
 Reduce process delays
 Eliminate unnecessary steps
 Improve workflow efficiency
 Align processes with business goals
 Improve customer satisfaction
 Reduce operational cost

3. Activities in Business Process Engineering

1. Business Process Identification
Identify existing processes (AS-IS model).
2. Business Process Analysis
Study workflows, bottlenecks, inefficiencies.
3. Process Redesign (TO-BE model)
Redesign process for:
 Low cost
 High speed
 Better quality
4. Technology Integration
Use IT systems, automation, databases, ERP systems.
5. Evaluation and Monitoring
Measure performance improvements.

4. Importance of BPE
 Helps organizations become more competitive
 Enables digital transformation
 Reduces redundancy and waste
 Improves internal and external communication
 Supports automation and modernization
Product Engineering (PE) – Overview (UNIT 4)
Product Engineering is the process of designing, developing, testing, deploying, and maintaining a
software product.
It focuses on converting customer needs into a high-quality, reliable product.
This engineering approach is used in:
 Mobile apps
 Web applications
 Enterprise software
 Commercial products

1. Definition
Product Engineering is the set of activities required to analyze customer requirements, design the
product architecture, develop, test, and deploy software using engineering principles.
It focuses on building a high-quality product that meets customer and market needs.

2. Objectives of Product Engineering

 Convert requirements into a working product
 Ensure high quality, reliability, and performance
 Optimize cost and time to market
 Provide scalability, usability, and maintainability
 Support continuous improvement

3. Activities in Product Engineering

1. Requirement Engineering
Gathering functional and non-functional requirements.
2. Product Architecture Design
Creating technical blueprint (UML diagrams, architecture model).
3. Development
Coding, integration, and component building.
4. Testing
Unit, integration, system, performance, security testing.
5. Deployment
Delivering the product to the market or customer.
6. Maintenance & Enhancement
Bug fixing, updates, new features.

4. Importance of Product Engineering

 Ensures well-designed and reliable software
 Reduces development cost and time
 Improves product quality and market value
 Enables continuous upgrades
 Enhances customer satisfaction

Difference Between Business Process Engineering & Product Engineering

Aspect Business Process Engineering Product Engineering
Focus Improving business processes Developing software products
Purpose Efficiency, cost reduction, workflow improvement Build high-quality software
Output Optimized business process Software product/system
Activities Process analysis, redesign Requirement → design → coding → testing
Requirement Engineering – (UNIT 4)
Requirement Engineering (RE) is a systematic process used in software engineering to identify,
analyze, document, validate, and manage the requirements of a software system.
It ensures that the final software meets the needs and expectations of users and stakeholders.

1. Definition of Requirement Engineering

Requirement Engineering is the process of gathering, analyzing, specifying, validating, and managing
requirements during the software development lifecycle.
In simple terms:
It defines what the system should do (functional requirements) and how well it should perform
(non-functional requirements).

2. Objectives of Requirement Engineering

 Understand customer needs
 Define clear, complete, and consistent requirements
 Avoid misunderstandings between clients and developers
 Provide a basis for system design and testing
 Ensure that the system built matches expectations

3. Requirement Engineering Process

Requirement Engineering consists of 5 major steps:

1. Requirement Elicitation
Process of collecting requirements from stakeholders.
Techniques:
 Interviews
 Questionnaires
 Brainstorming
 Observation
 Document analysis
 Use cases
 Workshops
Goal: Identify needs, expectations, and constraints.

2. Requirement Analysis
Analyzing the collected requirements to resolve:
 Conflicts
 Inconsistencies
 Ambiguities
 Feasibility
Includes:
 Data modeling
 Process modeling (DFD, UML diagrams)
 Prioritization

3. Requirement Specification
Documenting requirements in a clear and structured way.
The main output is the SRS (Software Requirements Specification) document.
SRS Includes:
 Functional requirements
 Non-functional requirements (performance, security, usability)
  Interface requirements
 Constraints and assumptions

4. Requirement Validation  Test-case generation

Checking whether requirements are:
 Complete 5. Requirement Management
 Correct Handling changes to requirements throughout
 Consistent the project.
 Verifiable Includes:
 Feasible  Version control
Techniques:  Traceability
 Reviews  Change control
 Walkthroughs  Impact analysis
 Prototyping

4. Types of Requirements
A) Functional Requirements  Performance (response time < 2 sec)
Describe what the system should do.  Security (encryption, authentication)
Examples:  Reliability
 User login  Usability
 Fund transfer  Maintainability
 Report generation C) User Requirements
B) Non-Functional Requirements High-level descriptions for end-users.
Describe quality attributes. D) System Requirements
Examples: Detailed requirements needed by developers.

5. Importance of Requirement Engineering

 Prevents project failures
 Reduces development cost and rework
 Ensures customer satisfaction
 Improves design and testing quality
 Supports proper project planning

6. Common Problems in Requirement Engineering

 Incomplete requirements
 Ambiguous requirements
 Changing requirements
 Miscommunication between stakeholders and developers
 Lack of domain knowledge

7. Output of Requirement Engineering

 SRS document
 Requirement models (DFDs, UML diagrams)
 Requirement traceability matrix (RTM)
System Modelling – (UNIT 4)
System Modelling is the process of creating abstract representations (models) of a system to
understand, analyze, design, and document its structure and behavior.
These models help stakeholders visualize how the system works, what its components are, and how they
interact.

1. Definition of System Modelling

System Modelling is the activity of developing graphical or mathematical models that describe:
 The structure of a system
 The behavior of a system
 The data used by the system
 The interactions within and outside the system
It is a key part of requirements analysis and system design.

2. Objectives of System Modelling

 Understand user requirements
 Analyze system behavior
 Identify system components and interactions
 Provide a blueprint for design and development
 Improve communication among stakeholders
 Detect errors early in the process

3. Types of System Models (Major Categories)

System models are usually classified into 3 main types:

A) Structural Models
Describe the organization and relationships of system components.
Examples:
 Class Diagram (UML)
 Object Diagram
 Component Diagram
 Deployment Diagram
These models show static aspects of the system.

B) Behavioral Models
Describe how the system behaves over time, including interactions and workflows.
Examples:
 Use Case Diagram
 Sequence Diagram
 Activity Diagram
 State Machine Diagram
These models show dynamic aspects of the system.

C) Data Models
Describe how data is stored, processed, and related.
Examples:
 Entity–Relationship (ER) Diagram
 Data Flow Diagram (DFD)
 Database schema diagram
4. Common System Modelling Techniques
1. Context Model
Shows system boundary and interactions with external entities.
(Also known as Level-0 DFD.)

2. Data Flow Diagram (DFD)

Shows how data flows through processes, data stores, and external entities.
Levels:
 Level 0 (Context)
 Level 1, 2 (Detailed views)

3. UML Diagrams
Unified Modeling Language (UML) provides multiple diagrams:
Structural UML Diagrams
 Class Diagram
 Object Diagram
 Component Diagram
 Deployment Diagram
Behavioral UML Diagrams
 Use Case Diagram
 Sequence Diagram
 Activity Diagram
 State Machine Diagram

4. ER Diagram
Represents data entities, attributes, and relationships.

5. Architectural Models
Describe high-level system structure, such as client-server, layered architecture, etc.

5. Benefits of System Modelling

 Increases system understanding
 Helps validate requirements
 Improves communication between developer and customer
 Detects missing or ambiguous requirements
 Provides a blueprint for coding
 Supports documentation

6. System Modelling Process

1. Understand Requirements
2. Identify system boundaries
3. Select modelling techniques (DFD, UML, ERD, etc.)
4. Create initial models
5. Refine models with feedback
6. Validate with stakeholders
7. Use models as input for design and development

7. Example (Simple)
A library management system can be modeled using:
 Context diagram → shows library and external actors
 DFD → shows issue/return/book search processes
Requirement Analysis – (UNIT 4)
Requirement Analysis is one of the most important phases of the Software Development Life Cycle
(SDLC).
It focuses on understanding, refining, and detailing the requirements gathered from customers and
stakeholders.
It ensures that the development team clearly understands what the user wants, what constraints exist,
and how the system should behave.

1. Definition
Requirement Analysis is the process of examining, classifying, prioritizing, and refining requirements
collected during elicitation to remove ambiguities, conflicts, and inconsistencies.
It converts raw user needs into clear, precise, and complete requirements.

2. Objectives of Requirement Analysis

 Understand user needs correctly
 Detect missing, conflicting, or incomplete requirements
 Convert vague requirements into structured form
 Prioritize requirements
 Establish a foundation for system design
 Ensure feasibility from technical, economic, and operational perspectives

3. Steps in Requirement Analysis

1. Requirement Classification
Categorizing requirements into:
 Functional requirements
 Non-functional requirements
 User requirements
 System requirements
 Domain requirements

2. Requirement Prioritization  Ranking

Determining which requirements are most  Pairwise comparison
important, based on:
 Customer needs 3. Requirement Feasibility Analysis
 Cost Checking feasibility from:
 Business value  Technical feasibility
 Technical difficulty  Economic feasibility
Common techniques:  Operational feasibility
 MoSCoW (Must, Should, Could, Won’t)  Legal and schedule feasibility

4. Requirement Modeling
Using diagrams and models to understand the system clearly.
Common modeling techniques:
Functional Modeling
 Data Flow Diagrams (DFD)
 Use Case diagrams
Data Modeling
 ER diagrams
 Class diagrams
Behavioral Modeling
 Sequence diagrams
Requirement Specification (UNIT 4)
Preparing SRS (Software Requirement Specification) document.
Requirements must be:
 Complete
 Unambiguous
 Consistent
 Verifiable
 Traceable

6. Requirement Validation
Confirming that requirements are:
 Correct
 Complete
 Consistent
 Realistic
 Testable
Techniques:
 Reviews
 Walkthroughs
 Prototyping
 Test-case derivation

4. Techniques Used in Requirement Analysis

1. Interviews
Stakeholders clarify needs and expectations.
2. Prototyping
Creates a working model to understand missing requirements.
3. Observation
Analysts observe current processes to derive requirements.
4. Workshops / JAD
Joint Application Development sessions.
5. Document Analysis
Study existing process documents, manuals, etc.

5. Importance of Requirement Analysis

 Prevents misunderstandings between client and developers
 Reduces rework and development cost
 Provides accurate input to system design
 Ensures system meets user goals
 Helps in planning, scheduling, and budgeting
 Improves software quality

6. Common Problems in Requirement Analysis

 Ambiguous requirements
 Conflicting stakeholder interests
 Changing requirements
 Incomplete understanding of domain
 Poor communication

7. Output of Requirement Analysis

 Refined and structured requirements
Design Principles & Concepts – (UNIT 4)
Software design is the process of transforming requirements into a blueprint for building the system.
Design Principles and Concepts help developers create structured, maintainable, efficient, and high-
quality software systems.

1. Software Design Concepts

These are the fundamental ideas used to structure and develop system design:

1. Abstraction
Abstraction hides unnecessary details and shows only essential information.
Types:
 Functional abstraction (functions/processes)
 Data abstraction (data structures)
 Control abstraction (control structures)
Benefits: reduces complexity, improves clarity.

2. Modularity
Dividing the system into independent modules that can be developed and tested separately.
Benefits: easier maintenance, better reuse, faster development.

3. Information Hiding
Each module hides its internal details and exposes only necessary interfaces.
Benefits: reduces coupling, increases reliability.

4. Cohesion
Cohesion measures how closely related the tasks 5. Coupling
of a module are. Coupling refers to the degree of
Types of Cohesion (from best to worst): interdependence between modules.
 Functional Types of Coupling (from best to worst):
 Sequential  Data coupling
 Communicational  Stamp (structured) coupling
 Procedural  Control coupling
 Temporal  External coupling
 Logical  Common coupling
 Coincidental  Content coupling
Higher cohesion → better design. Lower coupling → better design.

6. Refinement
A top-down design technique.
Start with a high-level concept and break it into smaller details.

7. Architecture
Architectural design defines:
 Major components
 Their relationships
 System structure
 Interfaces
Examples: layered architecture, client-server, microservices.
Software Design Principles (UNIT 4)
These principles help improve the quality of design:

1. Keep It Simple (KISS)

Design should be simple and easy to understand.
Avoid unnecessary complexity.

2. DRY (Don’t Repeat Yourself)

Avoid duplication of code or logic.
Promotes reusability and reduces errors.

3. Single Responsibility Principle (SRP)

Each module/class should have one and only one responsibility.

4. Open/Closed Principle (OCP)

Software components should be:
 Open for extension
 Closed for modification
Enhances maintainability and flexibility.

5. Liskov Substitution Principle (LSP)

Subclasses should be replaceable with their parent classes without breaking functionality.

6. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

7. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules.
Both should depend on abstractions.

8. Separation of Concerns
Different concerns (UI, business logic, data access) should be separated into different modules.

9. Consistency
Naming conventions, coding style, and design structure must remain uniform.

10. Understandability
Design should be clear enough for developers to easily understand and maintain the system.

3. Importance of Design Principles & Concepts

 Helps manage complexity
 Improves maintainability
 Reduces development effort and cost
 Enhances reusability of modules
 Minimizes defects
 Supports reliability and scalability
 Provides a clear roadmap for coding and testing

4. Example (Simple Illustration)

A Library Management System can be designed using:
 Modularization: separate modules (Issue, Return, Search)
Design Model & Documentation – (UNIT 4)
Software design transforms the requirements (SRS) into a structured blueprint for implementation.
This is done through design models and supported by proper documentation so developers, testers, and
stakeholders clearly understand the system.

1. Design Model
A design model is a set of diagrams, representations, and specifications that describe:
 Architecture of the system
 Components and their relationships
 Data structures
 Interfaces
 Behavior of the system
It acts as a bridge between requirement analysis and coding.

Types of Design Models

Design models are generally divided into Architectural Design, Interface Design, Component Design,
and Data Design.

1. Architectural Design Model

Defines the overall structure of the system.
Includes:
 System architecture
 Major subsystems
 Communication between subsystems
 Deployment structure
Diagrams:
 Component diagram
 Deployment diagram
 Package diagram
 Layered architecture diagram

2. Data Design Model

Shows how data is organized, stored, and accessed.
Includes:
 Data structures
 Database schema
 Data dictionaries
Diagrams:
 ER diagram
 Class diagram (attributes)

3. Interface Design Model

Specifies how:
 System components interact
 User interacts with the system
Includes:
 User Interface (UI) mockups
 API specifications
 External interfaces
 Input/output formats
Diagrams:
  Use case diagram
 Sequence diagram
 State machine diagram

4. Component-Level Design Model

Defines the internal structure of each module or class.
Includes:
 Algorithms
 Methods and attributes
 Control structures
Diagrams:
 Class diagrams
 Activity diagrams
 Detailed pseudo-code

2. Characteristics of a Good Design Model

 Correct — satisfies requirements
 Complete — includes all major components
 Consistent — no logical conflicts
 Readable — easy to understand
 Modular — divided into meaningful components
 Maintainable — easy to modify

3. Design Documentation
Design documentation is the process of recording the design model so developers and stakeholders have
a clear reference for implementation.
This is typically delivered in the form of an SDD (Software Design Document).

4. Contents of Design Documentation

1. Introduction
 Purpose of the design
 Scope
 References

2. System Overview
 High-level description
 Architectural style (layered, client-server, microservices)

3. Architectural Design
 System components
 Subsystems
 Component interaction
 Deployment diagram

4. Data Design
 Database schema
 ER diagrams
 Data dictionaries

5. Interface Design
 User interface structures
  API designs
 External system interfaces

6. Component Design
 Class diagrams
 Algorithms
 Activity diagrams
 Component-level specifications

7. Behavior Models
 Sequence diagrams
 Use case realizations
 State transition diagrams

8. Non-functional Requirements Traceability

How design satisfies:
 Performance
 Security
 Reliability
 Scalability

9. Constraints & Assumptions

Any limitations or dependencies.

5. Importance of Design Documentation

 Provides clear guidance for developers
 Ensures consistency in implementation
 Helps testers create test cases
 Useful during maintenance and future enhancements
 Reduces ambiguity
 Ensures traceability from requirements to design
 Helps new team members understand the system

6. Design Model vs Design Documentation

Aspect Design Model Design Documentation
Meaning Graphical/structured representation of system design Written document describing the design
Purpose Visualize and plan design Record design decisions for reference
Output Diagrams, models SDD (Software Design Document)
Focus Architecture, data, interfaces, components Explanation, details, justification
Q1)Software Architecture (UNIT 5)
The architecture of a system describes its major components, their relationships (structures), and how
they interact with each other. Software architecture and design includes several contributory factors
such as Business strategy, quality attributes, human dynamics, design, and IT environment.

We can segregate Software Architecture and Design into two distinct phases: Software Architecture
and Software Design. In Architecture, nonfunctional decisions are cast and separated by the
functional requirements. In Design, functional requirements are accomplished.
Software Architecture
Architecture serves as a blueprint for a system. It provides an abstraction to manage the system
complexity and establish a communication and coordination mechanism among components.
 It defines a structured solution to meet all the technical and operational requirements, while
optimizing the common quality attributes like performance and security.
 Further, it involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the final product. These decisions
comprise of −
o Selection of structural elements and their interfaces by which the system is composed.
o Behavior as specified in collaborations among those elements.
o Composition of these structural and behavioral elements into large subsystem.
o Architectural decisions align with business objectives.
o Architectural styles guide the organization.
Goals of Architecture
The primary goal of the architecture is to identify requirements that affect the structure of the
application. A well-laid architecture reduces the business risks associated with building a technical
solution and builds a bridge between business and technical requirements.
Some of the other goals are as follows −
 Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or system.
Q2)What is architectural style? (UNIT 5)
The architectural style is a set of basic forms and features that are characteristic of buildings of a
certain time and a certain nation, which give us an idea of the building’s purpose, age, regional
context, historical significance, and even the architect. Many factors influence the emergence and
evolution of architectural styles, including climate, religion, culture, and technology. Some styles
develop linearly, while others develop in parallel.

At its core, architectural style is the creation of a coherent and visually striking design that blends into
its environment and serves its purpose. It involves a careful balance of form, function, and aesthetics
to create a structure that is both beautiful and practical.

Architectural style can also be seen as a reflection of the cultural, historical, and social context in
which it was created. For example, classical architecture is often associated with ancient Greece and
Rome, while Gothic architecture is closely associated with the medieval era. In addition, the
architectural style is constantly evolving as new technologies, materials, and design approaches
emerge. Today, architects and designers are creating more sustainable, technologically advanced, and
visually stunning buildings than ever before. Different architectural styles clearly indicate the constant
evolution of human creativity and innovation.

The history of architectural styles is the history of humans evolving

Architecture has always been closely connected with the history of society’s development, its outlook
and ideas, the level of development of construction technology, with the human perception of utility
and beauty. All this influenced the architectural movements.

The architectural style is manifested in the ways of organizing space, the choice of architectural forms,
their proportions, and decorative ornaments typical for this era. Familiarity with different styles of
architecture can tell a lot about a human’s past. Unlike the Greeks, who knew only a column covered
with a beam and rooms with flat ceilings, the Romans developed an arched ceiling and a system of
vaults. Roman vaults impress with their imagery, scale, and a large number of varieties. One of the
most perfect examples of Roman architecture is the Pantheon, the temple of all the gods, built in
Rome in 125 AD. The circular building is covered by a grand dome with a diameter of more than 43
meters.

The history of architecture can be imagined as the history of the development and changes of the so-
called great architecture design styles (world styles): Classicism, Gothic, Romanesque, Renaissance,
Baroque, and Modern. All architectural styles number about 30. Different types of architectural styles
were created over time, by various trends. We have compiled for you a list of architectural styles that
you certainly need to know about.
Q3) Requirements Engineering Process in Software Engineering (UNIT 5)
Requirements engineering is the process of identifying, eliciting, analyzing, specifying, validating, and
managing the needs and expectations of stakeholders for a software system. Steps in Requirements
Engineering Process The requirements engineering process is an iterative process that involves several
steps, including: Requirements Elicitation This is the process of gathering information about the needs
and expectations of stakeholders for the software system. This step involves interviews, surveys,
focus groups, and other techniques to gather information from stakeholders. Requirements Analysis
This step involves analyzing the information gathered in the requirements elicitation step to identify
the high-level goals and objectives of the software system. It also involves identifying any constraints
or limitations that may affect the development of the software system.

Requirements Specification
This step involves documenting the requirements identified in the analysis step in a clear, consistent,
and unambiguous manner. This step also involves prioritizing and grouping the requirements into
manageable chunks.
Requirements Validation
This step involves checking that the requirements are complete, consistent, and accurate. It also
involves checking that the requirements are testable and that they meet the needs and expectations
of stakeholders.
Requirements Management
This step involves managing the requirements throughout the software development life cycle,
including tracking and controlling changes, and ensuring that the requirements are still valid and
relevant.
Requirement Engineering
The Requirements Engineering process is a critical step in the software development life cycle as it
helps to ensure that the software system being developed meets the needs and expectations of
stakeholders, and that it is developed on time, within budget, and to the required quality.
Requirement Engineering is the process of defining, documenting and maintaining the requirements.
It is a process of gathering and defining service provided by the system. it is the disciplined application
of proven principle , methods ,tools and notations to describe a proposed system’s intended
behaviour and its associated constraints.
Tools Involved in Requirement Engineering
observation report
1. Questionnaire ( survey , poll )
2. Use cases
3. User stories
4. Requirement workshop
5. Mind mapping
6. Role playing
Prototyping Requirements Engineering Process Consists of the Following Main Activities
1)Requirements elicitation 2)Requirements specification 3)Requirements verification and validation
4)Requirements management
Q4) Transform mapping (UNIT 5)
Transform mapping is a process used in software engineering to design and implement the
transformation of data between different structures or representations. It involves defining the steps
and rules necessary to convert data from one format to another. Here are the design steps typically
followed in transform mapping:
1)Requirement Analysis:
The first step is to understand the requirements and objectives of the data transformation. This
includes identifying the source data format and structure, the target data format and structure, and
any specific transformation rules or constraints that need to be applied.
2)Source and Target Schema Analysis:
Analyze the source and target schemas or data models to gain a clear understanding of their
structures, attributes, and relationships. This step helps in identifying the mappings and
transformations required to convert the data from the source to the target format.
3)Mapping Specification:
Identify the mapping between the source and target data elements. This involves determining which
source elements correspond to which target elements. It may include one-to-one mappings, one-to-
many mappings, or many-to-one mappings, depending on the data structures and requirements.
4)Transformation Rules:
Define the rules and operations needed to transform the data during the mapping process. These
rules can include data validation, data cleansing, data formatting, calculations, and any other
necessary transformations. It is important to consider any data dependencies and ensure that the
transformation rules are accurate and complete.
5)Data Flow Design:
Design the flow of data from the source to the target, taking into account any intermediate steps or
data structures that may be required. This includes identifying any temporary storage or staging areas
for the data during the transformation process.
Error Handling and Validation:
Define mechanisms to handle and validate data errors or inconsistencies. This may involve defining
error codes, error handling routines, and validation checks to ensure the integrity and quality of the
transformed data.
6)Performance Optimization:
Consider performance optimization techniques to improve the efficiency of the transformation
process. This can include optimizing algorithms, reducing unnecessary data processing, and
parallelizing tasks where possible.
7)Testing and Verification:
Develop test cases and perform testing to ensure the correctness and completeness of the
transformation process. This involves comparing the transformed data against the expected results to
identify any discrepancies or errors.
8)Documentation:
Document the transformation process, including the mapping specifications, transformation rules,
data flow diagrams, and any other relevant information. This documentation helps in maintaining and
understanding the transformation process in the future.
9)Implementation:
Finally, implement the designed transformation process using appropriate programming or scripting
languages, data integration tools, or ETL (Extract, Transform, Load) frameworks, depending on the
specific requirements and technologies involved.
Q5) User Interface AND User Interface Design Golden Rules (UNIT 5)

The user interface is the front-end application view to which the user interacts to use the software.
The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens
Types of User Interface

1) Command Line Interface: The Command Line Interface provides a command prompt, where
the user types the command and feeds it to the system. The user needs to remember the
syntax of the command and its use.

2) Graphical User Interface: Graphical User Interface provides a simple interactive interface to
interact with the system. GUI can be a combination of both hardware and software. Using
GUI, the user interprets the software.

User Interface Design Golden Rules

The following are the golden rules stated by Theo Mandel that must be followed during the design of
the interface. Place the user in control:

1. Define the interaction modes in such a way that does not force the user into unnecessary or
undesired actions: The user should be able to easily enter and exit the mode with little or no
effort.
2. Provide for flexible interaction: Different people will use different interaction mechanisms,
some might use keyboard commands, some might use mouse, some might use touch screen,
etc., Hence all interaction mechanisms should be provided.
3. Allow user interaction to be interruptible and undoable: When a user is doing a sequence of
actions the user must be able to interrupt the sequence to do some other work without losing
the work that had been done. The user should also be able to do undo operation.

4. Streamline interaction as skill level advances and allow the interaction to be customized:
Advanced or highly skilled user should be provided a chance to customize the interface as user
wants which allows different interaction mechanisms so that user doesn’t feel bored while
using the same interaction mechanism.

5. Hide technical internals from casual users: The user should not be aware of the internal
technical details of the system. He should interact with the interface just to do his work.

6. Design for direct interaction with objects that appear on-screen: The user should be able to
use the objects and manipulate the objects that are present on the screen to perform a
necessary task. By this, the user feels easy to control over the screen.
Q6) analysis & modeling (UNIT 5)
Analysis Model is a technical representation of the sys
system.
tem. It acts as a link between the system
description and the design model. In Analysis Modelling, information, behavior, and functions of the
system are defined and translated into the architecture, component, and interface level design in the
design modeling.
Objectives of Analysis Modelling:
 It must establish a way of creating software design.
 It must describe the requirements of the customer.
 It must define a set of requirements that can be validated, once the software is built. Elements of
Analysis Model:

[Link]
Data Dictionary: It is a repository that consists of a description of all data objects used or produced
by the software. It stores the collection of data present in the software. It is a very crucial element of
the analysis model. It acts as a centralized repository and also helps in modeling data objects defined
during software requirements.
[Link]
Entity Relationship Diagram (ERD): It depicts the relationship between data objects and is used in
conducting data modeling activities. The attributes of each object in the Entity-Relationship
Relationship Diagram
can be described using Data object description. It provides the basis for activit
activityy related to data design.
[Link]
Data Flow Diagram (DFD): It depicts the functions that transform data flow, and it also shows how
dataa is transformed when moving from input to output. It provides the additional information which
is used during the analysis of the information domain and serves as a basis for the modeling of
function. It also enables the engineer to develop models of func functional
tional and information domains at the
same time.
[Link]
State Transition Diagram: It shows various modes of behavior (states) of the system and also shows
the transitions from one state to another state in the system. It also provides the details of how the th
system behaves due to the consequences of external events. It represents the behavior of a system by
presenting its states and the events that cause the system to change state. It also describes what
actions are taken due to the occurrence of a particula
particular event.
[Link]
Process Specification: It stores the description of each function present in the data flow diagram. It
describes the input to a function, the algorithm that is applied for the transformation of input, and the
output that is produced. It alsoo shows regulations and barriers imposed on the performance
characteristics that are applicable to the process and layout constraints that could influence the way
in which the process will be implemented.
[Link]
Control Specification: It stores additional information about the control aspects of the software. It
is used to indicate how the software behaves when an event occurs and which processes are invoked
due to the occurrence of the event. It also provides the details of the processes which are executed to
manage events.
[Link]
Data Object Description: It stores and provides complete knowledge about a data object present
and used in the software. It also gives us the details of attributes of the data object present in the
Entity Relationship Diagram. Hence, ce, it incorporates all the data objects and their attributes.
Q8) What Is Component Level Design? (UNIT 5)
Component level design refers to the process of breaking down a system into its constituent parts to
better understand how they interact and connect. In software engineering, it is the phase that focuses
on defining and developing the software components that will be used to build the overall system
architecture.
Component level design has two main goals:
 Identify the components that are needed to build the system. This includes determining the
boundaries of each component and how they relate to one another.
 Define the interfaces between components. This makes the components loosely coupled and
independent, allowing them to be developed and tested separately before being integrated into
the full system.
When designing components, software engineers consider:
 Functionality: What is the purpose of the component? What features will it provide?
 Data: What data does the component need to operate? What data does it produce? How will it
interface with data from other components?
 Dependencies: On what other components does this component rely? How will those
dependencies be handled?
 Reusability: Can this component be reused in other systems? If so, how can its design be made
more generic?
 Scalability: How will this component handle increases in load or volume? Can its performance be
optimized?
Component-level design is a fundamental step in building a robust, modular software architecture. By
determining how to break a complex system into discrete, interconnected parts, software engineers
can create solutions that are flexible, extensible, and resilient to changes in requirements. The end
result is a system that is greater than the sum of its parts.
The Benefits of Component Level Design
Component level design is an essential part of software architecture that provides many
benefits. Include,
 Increased reusability: Well-designed components can be reused in other systems, saving time and
resources. Components are self-contained and independent, so they can function in a variety of
applications.
Q9) Structured Programming (UNIT 5)
In structured programming, we sub-divide the whole program into small modules so that the program
becomes easy to understand. The purpose of structured programming is to linearize control flow
through a computer program so that the execution sequence follows the sequence in which the code
is written. The dynamic structure of the program than resemble the static structure of the program.
This enhances the readability, testability, and modifiability of the program. This linear flow of control
can be managed by restricting the set of allowed applications construct to a single entry, single exit
formats.

Why we use Structured Programming?

We use structured programming because it allows the programmer to understand the program easily.
If a program consists of thousands of instructions and an error occurs then it is complicated to find
that error in the whole program, but in structured programming, we can easily detect the error and
then go to that location and correct it. This saves a lot of time.

These are the following rules in structured programming:

Structured Rule One: Code Block
If the entry conditions are correct, but the exit conditions are wrong, the error must be in the block.
This is not true if the execution is allowed to jump into a block. The error might be anywhere in the
program. Debugging under these circumstances is much harder.

Rule 1 of Structured Programming: A code block is structured, as shown in the figure. In flow-charting
condition, a box with a single entry point and single exit point are structured. Structured programming
is a method of making it evident that the program is correct.

Structure Rule Two: Sequence

A sequence of blocks is correct if the exit conditions of each block match the entry conditions of the
following block. Execution enters each block at the block's entry point and leaves through the block's
exit point. The whole series can be regarded as a single block, with an entry point and an exit point.

Structured Rule Three: Alternation

If-then-else is frequently called alternation (because there are alternative options). In structured
programming, each choice is a code block. If alternation is organized as in the flowchart at right, then
there is one entry point (at the top) and one exit point (at the bottom). The structure should be coded
so that if the entry conditions are fulfilled, then the exit conditions are satisfied (just like a code
block)..

Structured Rule 4: Iteration

Iteration (while-loop) is organized as at right. It also has one entry point and one exit point. The entry
point has conditions that must be satisfied, and the exit point has requirements that will be fulfilled.
There are no jumps into the form from external points of the code.
Q10) Software Engineering-Comparison of Design notation
We presented a number of different techniques for representing a procedural design. A comparison
must be predicated on the premise that any notation for component-level design, if used correctly,
can be an invaluable aid in the design process; conversely, even the best notation, if poorly applied,
adds little to understanding. With this thought in mind, we examine criteria that may be applied to
compare design notation.

Design notation should lead to a procedural representation that is easy to understand and review. In
addition, the notation should enhance "code to" ability so that code does, in fact, become a natural
by-product of design. Finally, the design representation must be easily maintainable so that design
always represents the program correctly.

The following attributes of design notation have been established in the context of the general
characteristics described previously:

Modularity. Design notation should support the development of modular software and provide a
means for interface specification.

Overall simplicity. Design notation should be relatively simple to learn, relatively easy to use, and
generally easy to read.

Ease of editing. The procedural design may require modification as the software process proceeds.
The ease with which a design representation can be edited can help facilitate each software
engineering task.

Machine readability. Notation that can be input directly into a computer-based development system
offers significant benefits
Maintainability. Software maintenance is the most costly phase of the software life cycle.
Maintenance of the software configuration nearly always means maintenance of the procedural
design representation.

Structure enforcement. The benefits of a design approach that uses structured programming concepts
have already been discussed. Design notation that enforces the use of only the structured constructs
promotes good design practice.

Automatic processing. A procedural design contains information that can be processed to give the
designer new or better insights into the correctness and quality of a design. Such insight can be
enhanced with reports provided via software design tools.

Data representation. The ability to represent local and global data is an essential element of
component-level design. Ideally, design notation should represent such data directly.

Logic verification. Automatic verification of design logic is a goal that is paramount during software
testing. Notation that enhances the ability to verify logic greatly improves testing adequacy.
Q1) Fundamentals of Software Testing (UNIT 6)
The process of software development comprises six major steps:
 Gathering project/application requirements
 Analysing these needs
 Designing the software
 Testing and debugging
 Deploying
 Maintaining the project
The testing step is arguably the most crucial part of the procedure. Although the testing stage
follows the design step (which comprises designing, outlining, and implementing the code) in the
cycle, in practice, testing occurs concurrently with code writing.
The fundamentals of software testing involve finding and fixing defects in code. However, a
competent testing methodology can provide additional benefits to a project. Benefits include
improved project performance, user experience, and security.
What is Software Testing?
Software testing is the process of determining software's accuracy by taking into account all of its
properties (reliability, scalability, portability, re-usability, and usability) and analyzing the
execution of software components to uncover software bugs, mistakes, or flaws. The fundamentals
of software testing entail examining code as well as executing code in multiple contexts and
situations. In today's software development scenario, a testing team may be independent of the
development team. Software testing aims to find mistakes, gaps, or missing requirements compared
to the actual needs.
What are the Steps of Software Testing?
Verification and Validation are two major steps in software testing. These steps implement the
fundamentals of software testing.
 In software testing, verification is the process through which your team checks whether the
program, system, or framework is consistent and aligned with the documentation
requirements.
 Validation is the procedure by which your team verifies the system's accuracy. During this
process, you will reflect on the product and the system; and think of what users desire and
what has been developed.
Different Types of Software Testing
Manual Testing
Manual testing is the process of checking the functionality of an application in accordance with the
needs of the client without using automation technologies. We do not need any specific knowledge
of any testing tool to perform manual testing on any application; rather, we need to have a solid
understanding of the product so that we can quickly build the test document. In this case, the tester
assumes the position of an end-user and tests the software for any unusual behavior or bugs. To
ensure the thoroughness of testing, testers employ test plans, test cases, or test scenarios.
Automation Testing
Automation testing is the process of transforming any manual test cases into test scripts with the
help of automation technologies or any programming language. We can increase the speed of our
test execution with the help of automation testing because no human work is required. We'll need to
write test scripts and run them. Automation testing is used to swiftly and repeatedly re-run test
scenarios that were previously done manually in manual testing. Aside from regression testing,
automated testing is used to test the application in terms of load, performance, and stress.
Compared to manual testing, it enhances test coverage, improves accuracy, and saves time and
money.
Q2) Test Case Design Techniques in Software Testing (UNIT 6)
Test case design techniques are the key to planning, designing, and implementing tests for software
applications. These techniques involve various steps that aim to ensure the effectiveness of test cases
in uncovering bugs or other defects in software programs.
Test Case Design Techniques
There are tons of different ways to design your test cases. These techniques help you test all your
software’s features and functions efficiently.
Let’s take an example to understand this concept better.
A basic example of test case design
Let us take an example of any e-commerce app or website(like Amazon or Flipkart)for test case
design. We want to ensure users can quickly checkout and make payments without issues. Here we
test for 1 product in the cart; we will see later that this test case design technique is a boundary value
analysis technique.
Title: Test that user can complete the checkout process when there is 1 item in the card.
Description: Ensure users can checkout and make payments without issues on the website/app
Preconditions: The user is already logged in
Assumptions: They are using a supported device or browser to log in.
Test Steps:

1. Open the app/website. [Link] to 1 product Add the product to the cart. [Link] out the item
in the cart. [Link] address information for 5. delivery Add payment information [Link]
the checkout process.

Expected Result: The checkout process should be complete, and the user should receive
confirmation. What are the types of test case design techniques?
These test case design techniques can be classified into three major groups:

 Specification-based
 Structure-based
 Experience-based

pecification-Based or Black-Box techniques

Specification-based testing, also known as black-box testing, is a testing technique that focuses on
testing the software system based on its functional requirements and specifications without any
knowledge about the underlying code or system structure.
Structure-Based or White-Box techniques

Structure-based testing, also known as white-box testing, is a testing technique that involves the
testing of internal structures or components of software applications. In this approach, the tests
interact with the code directly. These tests are designed to ensure the code works correctly and
efficiently. Specification-Based or Black-Box techniques

Specification-based testing, also known as black-box testing, is a testing technique that

focuses on testing the software system based on its functional
Q3) Specification-Based or Black-Box techniques(UNIT 6)

1. Boundary Value Analysis (BVA) identifies errors at the input domain’s boundary. A simple
example of boundary value analysis would be testing a text box that requires the user to enter
a number between 1 and 10. In this case, the boundary values would be 1 and 10, and we
would test with values that are just above, at, and just below these boundaries.
For example, we would test with 0, 1, 2, 9, 10, and 11. We can expect that errors or defects
are most likely to occur at or near the boundary values. Identifying these issues early can help
prevent them from causing problems later in the software development process.
2. Equivalence Partitioning (EP) is another technique that helps reduce the required test cases.
By partitioning test input data into classes with an equivalent number of data, one can design
test cases for each class or partition. This technique ensures that one thoroughly tests the
software while minimizing the required test cases.
For example, if a program requires an input of numbers between 1 and 100, an EP test would
include a range of values, such as 1-50 and 51-100, and numbers outside that range, such as -1
or 101. Testing one value from each partition is sufficient to test all values within that
partition.
3. Decision Table Testing is a technique that involves designing test cases based on decision
tables formulated using different combinations of inputs and their corresponding outputs
based on various conditions and scenarios sticking to other business rules. This technique
ensures that we test the software thoroughly and accurately.
For example, if a program offers discounts based on the type of customer and the amount
spent, a decision table would list all possible combinations of customer types and the amount
paid to receive a discount. Each cell in the table would specify the value that should be
applied. Testers can ensure the program behaves correctly under various scenarios by testing
all combinations.
4. Developers use State Transition Diagrams(STD) to test software with a finite number of states
of different types. A set of rules that define the response to various inputs guides the
transition from one state to another. This technique is handy for systems with specific
workflows within them.
5. Use Case Testing involves designing test cases to execute different business scenarios and
end-user functionalities.

For example, A use case could be a “student enrolling in a course” on an academic website.
Test cases would simulate the enrollment process and verify the system’s response from a
student’s perspective.
Q4)Structure-Based or White-Box techniques (UNIT 6)

 Statement Testing and Coverage is a technique that involves executing all the executable
statements in the source code at least once. We then calculate the percentage of executable
statements as per the given requirement.

For example, consider code that inputs two numbers and checks if the first number is greater than or
equal to the second. A statement coverage test would verify that both the “greater than” and “equal
to” statements are executed during testing to ensure that all code branches are covered.

 Decision Testing Coverage, also known as branch coverage, validates all the branches in the code by
executing each possible branch from each decision point at least once. This helps ensure that no
branch leads to unexpected application behavior.

For example, if a program requires an input of a number between 1 and 100 and uses an “if/else”
statement to check if the number is even, decision testing coverage would ensure that both the even
and odd outcomes have been tested to confirm all possible scenarios have been checked.

 Condition Testing, also known as Predicate coverage testing. It involves evaluating each Boolean
expression in the code and checking its output values, TRUE or FALSE, against the expected outcomes.
This test checks all outcomes at least once to achieve 100% code coverage. We design test cases that
make it easy to execute the condition outcomes.

For example, if a program determines whether a user is eligible for a discount based on age, condition
testing would verify that the code handles each age group accurately. It would test age values such as
one less than, one more than, and within the age range requirement to evaluate if the code performs
as expected.

 Multiple Condition Testing aims to test different combinations of conditions to achieve 100%
coverage. This technique requires two or more test scripts, which may require more effort.

For example, if a program uses an “if/else” statement to check age and gender to provide a discount,
multiple condition testing would verify that the program handles all possible scenarios correctly. It
would test various age ranges and gender combinations to ensure the code performs accurately for all
possibilities.

 All Path Testing leverages the source code of a program to find every executable path.

For example, if a program asks a user for two inputs (A and B) and has multiple conditions, All Path
Testing would ensure that each condition is tested independently. The technique would test all
combinations of A and B, including zero, negative, and positive Testings, to identify any potential
errors in the code.
Q5) Testing for Specialized Environments (UNIT 6)

The need for specialized testing approaches is becoming mandatory as computer software has
become more complex. The White-box and black box testing methods are applicable across all
environments, architectures and applications, but unique guidelines and approaches to testing are
sometime important. We address the testing guidelines for specialized environments, architectures,
and applications that are commonly encountered by software engineers.
Testing GUIs
The growth of Graphical User Interfaces (GUIs) in various applications has become a challenge for test
engineers. Because of reusable components provided as part of GUI development environments, the
creation of the user interface has become less time consuming and more precise. GUI is becoming
mandatory for any application as users are used to it. Sometime, the user interface may be treated as
a different layer and easily separated from the traditional functional or business layer.

The design and development of user interface layer requires separate design and development
methodology. Here the main problem is to understand the user psychology during the development
time. Due to complexity of GUIs, testing and generating test cases has become more complex and
tedious. Because of modern GUIs standards (same look and feel), common tests can be derived.

2) Testing of Client/Server Architectures

Client/server (C/S) architectures represent a significant challenge for software testers. The distributed
nature of client/server environments, the performance issues associated with transaction processing,
the potential presence of a number of different hardware platforms, the complexities of network
communication, the need to service multiple clients from a centralized (or in some cases, distributed)
database, and the coordination requirements imposed on the server all combine to make testing of
C/S architectures and the software that reside within them considerably more difficult than stand-
alone applications. In fact, recent industry studies indicate a significant increase in testing time and
cost when C/S environments are developed.

3) Testing Documentation and Help Facilities

The term software testing conjures images of large numbers of test cases prepared to exercise
computer programs and the data that they manipulate. It is important to note that testing must also
extend to the third element of the software configuration—documentation.
Errors in documentation can be as devastating to the acceptance of the program as errors in data or
source code. Nothing is more frustrating than following a user guide or an on-line help facility exactly
and getting results or behaviors that do not coincide with those predicted by the documentation. It is
for this reason that that documentation testing should be a meaningful part of every software test
plan.

4)Testing for Real-Time Systems

The time-dependent, asynchronous nature of many real-time applications adds a new and potentially
difficult element to the testing mix—time. Not only does the test case designer have to consider
white- and black-box test cases but also event handling (i.e., interrupt processing), the timing of the
data, and the parallelism of the tasks (processes) that handle the data. In many situations, test data
provided when a real time system is in one state will result in proper processing, while the same data
provided when the system is in a different state may lead to error.
. Q6) How we approach software testing (UNIT 6)
[Link] each software product’s quality standards

Every time we onboard a new client, the first mandatory step we take is understanding the quality
standards that a particular product has to meet. These quality standards are different depending on
the industry vertical, as for example, an HR platform doesn’t need to comply with the same
regulations as a medical or pharmaceutical application, and so how we test each of them will be
different.
Therefore we meet with the client to talk about these standards and specific requirements. And we
put in place a testing process that goes hand in hand with development.

2. Requirements analysis and build test cases

Based on the product’s requirements and the defined acceptance tests, our testers create test
cases and document them with the help of a tool (usually TestRail, Jira or Azure DevOps).
Analyzing the requirements gives us the chance to identify if there are any errors, before developers
start coding, thus enabling us to prevent future bugs. Our testers’ role is to also make sure that the
requirements are clear, complete, and testable, and gather information about the priorities in testing.
Another important task at this stage is reviewing the test cases inside the team - other team members
take a look at the test cases to make sure they are clear and comprehensive.

3. Set up the test environment

The test environment should closely mimic the end-users’ environment in terms of hardware,
software and network configurations, operating system settings, and other characteristics.

For example, for a mobile application, we need to make sure it works the same on all the versions of a
mobile operating system.
4. Test execution
We typically work in an Agile environment, with sprints that take 2 - 3 weeks, having a sprint backlog
of user stories that we need to build.
Right after a feature is developed, testers work with the development team to make sure that the
acceptance tests are passed. Testers and developers work in close cooperation, almost in symbiosis as
we like to say because the goal is to spot any bugs early on and fix those bugs then and there. It’s
easier and faster to fix an error right after developing a feature, rather than later in the future.
Developers themselves are responsible for testing the features they developed, and most of the time
their code is covered by Unit tests (white box testing)
5. Constantly improve the testing process

We view our testing process as ever-evolving and focus on how we can continue to make it better.
The Sprint Retrospective meeting held at the end of each development sprint is a good occasion to
look at how the testing went, what types of bugs were reported, and determine how testing can be
improved.
Q7) Unit Testing (UNIT 6)
Unit testing involves the testing of each unit or an individual component of th the
e software application.
It is the first level of functional testing. The aim behind unit testing is to validate unit components
with its performance.

A unit is a single testable part of a software system and tested during the development phase of the
application software.

The purpose of unit testing is to test the correctness of isolated code. A unit component is an
individual function or code of the application. White box testing approach used for unit testing and
usually done by the developers.

Whenever thehe application is ready and given to the Test engineer, he/she will start checking every
component of the module or module of the application independently or one by one, and this process
is known as Unit testing or components testing
testing.

Why Unit Testing? In a testing level hierarchy, unit testing is the first level of testing done before
integration and other remaining levels of the testing. It uses modules for the testing process which
reduces the dependency of waiting for Unit testing frameworks, stubs, drivers and mock objects are
used for assistance in unit testing.

Generally, the software goes under four level of testing: Unit Testing, In Integration
tegration Testing, System
Testing, and Acceptance Testing but sometimes due to time consumption software testers does
minimal unit testing but skipping of unit testing may lead to higher defects during Integration Testing,
System Testing, and Acceptance Te Testing
sting or even during Beta Testing which takes place after the
completion of software application.

Some crucial reasons are listed below:

o Unit testing helps tester and developers to understand the base of code that makes them able
to change defect causing code
ode quickly.
o Unit testing helps in the documentation.
o Unit testing fixes defects very early in the development phase that's why there is a possibility
to occur a smaller number of defects in upcoming testing levels.
o It helps with code reusability by migrat
migrating code and test cases.
Q8) Integration testing (UNIT 6)

is the process of testing the interface between two software units or modules. It focuses on
determining the correctness of the interface. The purpose of integration testing is to expose faults in
the interaction between integrated units. Once all the modules have been unit-tested, integration
testing is performed. Integration testing is a software testing technique that focuses on verifying the
interactions and data exchange between different components or modules of a software application.
The goal of integration testing is to identify any problems or bugs that arise when different
components are combined and interact with each other. Integration testing is typically performed
after unit testing and before system testing. It helps to identify and resolve integration issues early in
the development cycle, reducing the risk of more severe and costly problems later on. Integration
testing can be done by picking module by module. This can be done so that there should be a proper
sequence to be followed. And also if you don’t want to miss out on any integration scenarios then you
have to follow the proper sequence. Exposing the defects is the major focus of the integration testing
and the time of interaction between the integrated units. Integration test approaches – There are four
types of integration testing approaches. Those approaches are the following:among all the modules.

Guidelines for Integration Testing

o We go for the integration testing only after the functional testing is completed on each
module of the application.
o We always do integration testing by picking module by module so that a proper sequence is
followed, and also we don't miss out on any integration scenarios.
o First, determine the test case strategy through which executable test cases can be prepared
according to test data.
o Examine the structure and architecture of the application and identify the crucial modules to
test them first and also identify all possible scenarios.
o Design test cases to verify each interface in detail.
o Choose input data for test case execution. Input data plays a significant role in testing.
o If we find any bugs then communicate the bug reports to developers and fix defects and
retest.
o Perform positive and negative integration testing.

Advantages: 1. It is convenient for small systems. [Link] and straightforward approach.

[Link] be completed quickly. [Link] not require a lot of planning or coordination. 5. May be
suitable for small systems or projects with a low degree of interdependence between
components.

Disadvantages: [Link] will be quite a lot of delay because you would have to wait for all the
modules to be integrated. [Link]-risk critical modules are not isolated and tested on priority
since all modules are tested at once. 3. Not Good for long projects. 4. High risk of integration
problems that are difficult to identify and diagnose. 5. This can result in long and complex
debugging and troubleshooting efforts
Q10 )Validation testing (UNIT 6)
Validation testing is a complex process that involves finding and testing every user need or
requirement to ensure they function well. Here are the basic phases of validation testing:
1. Design qualification
The process of design qualification, or DQ, includes creating a list of end-user business requirements
and designing a validation testing plan to address them before launching the product. This plan can
also be a useful written record of the design specifications that the developer and consumer desire.
After writing the testing plan, development teams can seek approval from managers or shareholders
before they begin the testing process.
2. Installation qualification
Installation qualification, or IQ, involves installing the software according to the validation testing
plan. Product development teams may ensure that both system hardware and the installation process
itself match the design specifications. This phase also involves ensuring that the test environment is
suitable for product operation and matches the environment in which the product is likely to perform
once the company releases it to the public.
3. Operational qualification
Operational qualification, or OQ, involves testing the product with a variety of testing operations to
ensure the product meets the specified user requirements. Important validation testing techniques
include unit testing, integration testing and system testing. These are all different types of
functionality testing, which can determine if various elements of the software function according to
the user requirements.
Software development teams can follow the plan from the design qualification phase to ensure they
test every product specification in the appropriate environment. It's useful for product development
team members to record these tests carefully to create a written record of the software performance.
They can also record the creation of deliverables and ensure those deliverables are satisfactory
through a deliverable approval process.
4. Performance qualification
Performance qualification, or PQ, testing verifies that a product can perform according to business
needs in the real world. Developers on the internal team can perform alpha testing to assess the
functionality of the software under simulated real-world conditions. After performing their own
testing, a product development team can offer clients the chance to test the product through a
process called beta testing.
In beta testing, an external client can use the product and identify bugs or technical challenges. They
can then report this information back to the development team, allowing them the opportunity to
make changes before releasing the product to the public. After receiving approval from the beta
testers, the product may be ready for production and deployment.
5. Production
After completing all levels of validation testing, a software product may go into production. This
means that the product is ready to be marketed and sold to consumers. The software development
team might help facilitate the deployment and installation process. The company can also offer
technical assistance to individuals experiencing minor technical challenges in the product. If they
discover a major technical bug, the development team can address it by devising a solution and
release a software update.
Q11) Software Metrics
A software metric is a measure of software characteristics which are measurable or countable.
Software metrics are valuable for many reasons, including measuring software performance, planning
work items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected. Software metrics
are similar to the four functions of management: Planning, Organization, Control, or Improvement.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product. The two
important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various characteristics of the software development
process. For example, the efficiency of fault detection. They are used to measure the characteristics of
methods, techniques, and tools that are used for developing software.

Types of Metrics

1) Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to
be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
2)External metrics: External metrics are the metrics used for measuring properties that are viewed to
be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
3)Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics.
For example, cost per FP where FP stands for Function Point Metric.

Advantage of Software Metrics

 Comparative study of various design methodology of software systems.

 For analysis, comparison, and critical study of different programming language concerning
their characteristics.
 In comparing and evaluating the capabilities and productivity of people involved in software
development.
 In the preparation of software quality specifications.
 In the verification of compliance of software systems requirements and specifications.
 In making inference about the effort to be put in the design and development of the software
systems.