CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Syllabus

Introduction to System Concepts: Definition, Elements of System, Characteristics of System, Types of System,
System Concepts.
Introduction to Software Engineering: Definition, Need for software Engineering, Software Characteristics,
Software Qualities (McCall’s Quality Factors)
Software Development Methodologies: SDLC (System Development Life Cycle), Waterfall Model, Spiral Model,
Prototyping Model.
Requirement Analysis: Definition of System Analysis, Requirement Anticipation, Knowledge and Qualities of
System Analyst, Role of a System Analyst, Feasibility Study And It’s Types, User Transaction Requirement, User
design Requirements, SRS(System Requirement Specification)
Analysis and Design Tools: Entity Relationship Diagrams, Data Flow Diagrams (DFD), Data Dictionary & Elements of
Data Dictionary, Pseudo code, Input and Output Design.
Structured System Design: Modules Concepts and Types of Modules, Structured Chart, Qualities of Good Design,
Coupling, Types of Coupling, Cohesion, Types of Cohesion.
Software Testing: Definition, Test characteristics, Types of testing - BlackBox Testing, White-Box Testing, Stress
Testing, Performance Testing.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Assessment Plan
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Reference Books:
1. R. S. Pressman, Software Engineering, (5e), Tata McGraw Hills, 2009.
2. I. Sommerville, Software Engineering, (6e), Pearson Education Asia, 2005.
3. P. Jalote, An Integrated Approach to Software Engineering, (3e), Narosa, 2010.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Introduction to System Concepts

• Definition
• Elements of System
• Characteristics of System
• Types of System
 Introduction to System Concepts

Definition

➢ A system is a collection of interrelated components or elements that work together to achieve a specific
goal or purpose.
➢ It can be as simple as a mechanical system or as complex as an ecosystem or information system.
➢ A system is basically a group of things or parts that work together in an organized way to achieve a
common goal. Think of it like a team where each member has a specific role, and everyone works
together to get the job done.
➢ It operates through a network of relationships, exchanges, and processes, where each component
plays a unique role in contributing to the overall operation.
➢ A system can exist in various forms—natural, artificial, physical, abstract, or a combination of these—
and interacts with its surroundings, known as the environment
➢ The goal of the system is to achieve something, like solving a problem, creating a product, or
maintaining balance.
 Introduction to System Concepts

Elements of a System

The important elements of a system are:

1.Output and Inputs
2.Processor(s)
3.Control
4.Feedback
5.Environment
6.Boundaries and Interface
 Introduction to System Concepts

A system is made up of several key elements or components that work together to achieve the
system's goal. Here are the main elements of a system:
1. Input and Output
These are the resources (such as data, materials, energy, or information) that are put into a
system to be processed.
The result or product that is produced after the input has been processed by the system.

2. Process
The actions or operations that are performed on the input to transform it into an output.

3. Control
The control element guides the system. It is the decision—making sub-system that controls the pattern
of activities governing input, processing and output. (Example Project Manager)
 Introduction to System Concepts

4. Feedback
Feedback is information about the output that helps the system adjust its behavior or
performance. It can be used to maintain or improve the system's functioning.

5. Environment
The external factors that influence the system but are not part of it. The environment interacts
with the system, and the system responds to these external factors. The software environment,
consisting of vendors, users, competitions and others, may provide constraints and
consequently influence the actual performance of software.

6. Boundary
The boundary defines the limits of the system, distinguishing it from the environment. It shows
what is included in the system and what is not.
 Introduction to System Concepts

7. Subsystems
These are smaller systems that exist within a larger system. They may function
independently but also interact with the larger system.
 Introduction to System Concepts

Characteristics of System
➢ Organization : Organization implies structure and order. It is the arrangement of components that helps to
achieve objectives. Hierarchical relationship starting with the president on top and leading downward to the blue
collar worker represent the organization structure.

➢ Interaction : Interaction refers to the manner in which each component interact with other components of the
system. In an organization, for example purchasing must interact with production, advertising with sales and
payroll with personnel.

➢ Interdependence : Independence means that parts of the organization or computer system depend on one
another. They are coordinated and linked together according to a plan. One subsystem depends on the input of
another subsystem for proper functioning; that is, the output of one subsystem is the required input for another
subsystem.

➢ Integration : Integration refers to the holism of system. Synthesis follows analysis to achieve the central objective
of the organization. Integration is concerned with how a system is tied together. It is more than sharing a physical
part or a location. It means that parts of the system work together within the system even though each part
performs a unique function.

➢ Central Objectives: Then objective of the system must be a common objective. Every system exists to achieve a
defined purpose or objective. Example: A transportation system aims to move people and goods efficiently.
Introduction to System Concepts

Types of Systems

➢ Physical : Physical systems are tangible entities that may be static or dynamic in operation (example Computer
system). The physical part of the computer center are desk and chair is static. The computer is a dynamic system in
which programs, data and applications can change according to the users need. Example solar systems.

➢ Abstract systems are conceptual or non-physical entities which may be as straightforward as formulas of relationships
among sets of variables or models – the abstract conceptualization of physical situations. (Example: system layout,
diagram, formulas, operating system, economic systems.

➢ Open : An open system continually interacts with its environments. It receives inputs from and delivers output to the
outside. Example: A user comes to a company tells the requirement of software and the company delivers it. It adapt
to the changing demands of the user.

➢ Closed Systems: In contrast, a closed system is isolated from environmental influences. In reality, completely closed
systems are rare. No dynamic nature in closed system.

➢ Adaptive System: Adaptive system responds to the change in the environment in a way to improve their performance
and to survive. (Change according to demand and need. A software company teach new languages to employes.)

➢ Non- Adaptive system is the system which does not respond to environment changes. For example : Machines, maps.
Introduction to System Concepts Types of Systems

➢ Temporary systems: Made for specific duration of time for specific use and after that they are demolished. Example
event management systems, construction sites, election systems.

➢ Permanent System: persist for longer duration for long goals. Example Power supply grid, banking system, education
system.

➢ Deterministic Systems: A deterministic system is one in which the occurrence of all events is perfectly determined or
fixed. If we get the description of the system state at a particular time, the next state can be easily described. Example
Algebras laws, Mathematics equations.

➢ Probabilistic system is one in which the occurrence of events cannot be perfectly predicted. Example weather
forecast, stock prediction.
Introduction to Software Engineering

What is Software Engineering?

➢ Software engineering is the discipline of designing, developing, testing, and maintaining software systems using
systematic, structured, and well-defined methods.

➢ It involves applying engineering principles to the entire software development life cycle to create software that is
reliable, efficient, maintainable, and meets the needs of users.

➢ In simple terms, software engineering is the process of building software in a planned and organized way, much
like how engineers design and build bridges or buildings.

➢ The goal is to produce high-quality software that works as expected and is easy to maintain over time.

➢ Software engineers apply engineering principles and knowledge of programming languages to build software
solutions for end users.
Introduction to Software Engineering

➢ Software engineering includes a variety of techniques, tools, and methodologies, including

requirements analysis, design, testing, and maintenance.
➢ It is a rapidly evolving field, and new tools and technologies are constantly being developed to
improve the software development process.
➢ By following the principles of software engineering and using the appropriate tools and
methodologies, software developers can create high-quality, reliable, and maintainable software
that meets the needs of its users.
➢ Software Engineering is mainly used for large projects based on software systems rather than
single programs or applications.
➢ The main goal of Software Engineering is to develop software applications for improving
quality, budget, and time efficiency.
➢ Software Engineering ensures that the software that must be consistent, correct, also on budget,
on time, and within the required requirements.
Introduction to Software Engineering

Need of Software Engineering

The need for software engineering arises due to the increasing complexity, scale, and impact of modern
software systems. Here are some key reasons why software engineering is essential:

1. Complexity of Software Systems

•Software systems have grown in size and functionality, requiring systematic methods to manage their
design, development, and maintenance.
•Without proper engineering principles, managing large systems becomes error-prone and inefficient.

2. Demand for High Quality

•Software must meet high standards of reliability, performance, scalability, and usability.
•Software engineering practices help ensure that systems meet these quality attributes through rigorous
testing, validation, and documentation.

3. Efficient Resource Utilization

•Optimizing time, money, and human resources is critical in software projects.
•Software engineering provides frameworks and methodologies that streamline development processes,
reducing wastage.
Introduction to Software Engineering

4. Rapid Technological Advancements

•With constantly evolving technology, software needs to adapt quickly.
•Engineering principles enable the design of flexible and maintainable software that can evolve over
time.

5. Team Collaboration
•Modern software development involves large, often geographically distributed teams.

6. Safety and Security

•Many systems operate in critical domains like healthcare, finance, and transportation, where errors
can have severe consequences.
•Software engineering incorporates practices to ensure systems are secure, reliable, and fail-safe.

7. Meeting Customer Expectations

•Users expect software to function seamlessly and provide value.
•Software engineering processes focus on gathering requirements, prototyping, and iterative
development to align with customer needs.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Key Principles of Software Engineering

➢ Modularity: Breaking the software into smaller, reusable components that can be developed and tested
independently.

➢ Abstraction: Hiding the implementation details of a component and exposing only the necessary functionality
to other parts of the software.

➢ Encapsulation: Wrapping up the data and functions of an object into a single unit, and protecting the internal
state of an object from external modifications.

➢ Reusability: Creating components that can be used in multiple projects, which can save time and resources.

➢ Maintenance: Regularly updating and improving the software to fix bugs, add new features, and address
security.

➢ Testing: Verifying that the software meets its requirements and is free of bugs.

➢ Design Patterns: Solving recurring problems in software design by providing templates for solving them.

➢ Agile methodologies: Using incremental development processes that focus on customer satisfaction, rapid
delivery, and flexibility.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

McCall's Quality Model is a software quality model introduced by James McCall in the early 1970s. It
focuses on identifying and improving the key factors that determine the quality of software products.
Introduction to Software Engineering

Product Operation Factors

These factors are related to the operational aspects of the software and how it performs in a
production environment:

•Correctness: The extent to which the software satisfies the specified requirements.

•Reliability: The ability of the software to perform its required functions under specified
conditions for a specified period.

•Efficiency: The software's ability to perform its functions with optimal use of resources (e.g.,
time, memory).

•Integrity: The ability to protect the software from unauthorized access and ensure data
security.

•Usability: The ease with which the software can be used by its intended users.
Introduction to Software Engineering

Product Revision Factors

These factors pertain to the software's maintainability and adaptability over time:

•Maintainability: The ease with which the software can be modified to correct
defects, improve performance, or adapt to new requirements.

•Flexibility: The ability of the software to accommodate changes and new features
with minimal effort.

•Testability: The ease with which the software can be tested to ensure it is working
as expected.

•Portability: The ability to adapt the software to different environments, such as

hardware platforms or operating systems.
Introduction to Software Engineering

Product Transition Factors

These factors focus on how the software can be transferred or adapted for use in
different environments or systems:

•Reusability: The ability of the software components to be reused in different systems or

applications.

•Interoperability: The ability of the software to interact and work with other systems or
software without issues.

•Portability: The effort required to transfer a program from one platform to another.
Introduction to Software Engineering

McCall's Quality Model in Use:

•The model provides a framework for evaluating software quality from different
perspectives.

•It helps to define and measure quality attributes that should be prioritized during the
software development lifecycle.

•By assessing these factors, developers can make informed decisions about improving
various aspects of software quality.

In essence, McCall’s model emphasizes that quality is a multidimensional concept

that involves various considerations beyond just functionality, including ease of
maintenance, security, and adaptability.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Development Methodologies: SDLC (Software

Development Life Cycle), Waterfall Model, Spiral Model,
Prototyping Model.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Development Life Cycle (SDLC)

• SDLC is a process followed for software building within a software organization.

• SDLC consists of a precise plan that describes how to develop, maintain, replace, and enhance specific
software.
• The life cycle defines a method for improving the quality of software and the all-around development
process.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Stages of the Software Development Life Cycle

• SDLC specifies the task(s) to be performed at various stages by a software engineer or developer.
• It ensures that the end product is able to meet the customer’s expectations and fits within the overall
budget.
• Hence, it’s vital for a software developer to have prior knowledge of this software development
process. SDLC is a collection of these six stages, and the stages of SDLC are as follows:
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Stage-1: Planning and Requirement Analysis

• It is the first phase in most Software Development Life Cycle (SDLC) models. It involves understanding what
the system is supposed to do, analyzing the project's feasibility, and planning its execution.
• This phase ensures that the development team clearly understands the requirements and prepares
adequately before proceeding.
• The information from this analysis forms the building blocks of a basic project.

Stage-2: Defining Requirements

• Defining requirements is a critical phase in the Software Development Life Cycle (SDLC).
• It involves gathering, analyzing, and documenting the needs and expectations of stakeholders to provide a
clear understanding of what the software system should achieve.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Stage-3: Designing Architecture

• In the Software Development Life Cycle (SDLC), designing the architecture is a crucial phase where
the structure of the system is planned, which includes defining the high-level components, modules,
interfaces, and data flows.
• This phase ensures that the software is built on a solid foundation, supporting both functional and non-
functional requirements.
• The architecture design phase can vary depending on the SDLC model used.

Stage-4: Developing Product

• Developing Product (also known as the Development Phase) follows the planning and design phases
and focuses on the actual creation of the software product.
• It is the phase where the development team writes the code to build the system based on the design
specifications.
• Some popular languages like C/C++, Python, Java, etc. are put into use as per the software
regulations.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Stage-5: Product Testing and Integration

• Product testing and integration are two crucial phases in the Software Development Life Cycle (SDLC) that
focus on ensuring the product functions as intended and works seamlessly with other components or
systems..
• Product testing is the process of validating and verifying the software product to ensure it meets the defined
requirements and works as expected in different environments.
• Integration in SDLC refers to the phase where different software modules, components, or systems are
combined and tested together to ensure they work seamlessly.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Stage-6: Deployment and Maintenance of Products

• In the Software Development Life Cycle (SDLC), Deployment and Maintenance are two critical stages that
occur after the development and testing phases.
• These stages ensure that the product is successfully delivered to end-users and continues to perform
effectively over time.
• Deployment refers to the process of delivering the software to the production environment, making it
available for use by end-users. This step involves the installation, configuration, and launch of the application
in the target environment.
• Maintenance involves all activities required to keep the software operational and effective after its initial
release. This stage includes fixing defects, updating the software to address user feedback, and ensuring the
product continues to meet business and user needs over time.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Waterfall Model
• The Waterfall Model is a traditional
Software Development Life Cycle
(SDLC) model that follows a linear and
sequential approach to software
development.
• It was one of the earliest SDLC models,
first introduced by Dr. Winston W. in
1970.
• The waterfall model is useful in
situations where the project
requirements are well-defined and the
project goals are clear.
• It is often used for large-scale projects
with long timelines, where there is little
room for error and the project
stakeholders need to have a high level of
confidence in the outcome.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Features of Waterfall Model

Following are the features of the waterfall model:
1.Sequential Approach: The waterfall model involves a sequential approach to software development,
where each phase of the project is completed before moving on to the next one.

2.Document-Driven: The waterfall model depended on documentation to ensure that the project is well-
defined and the project team is working towards a clear set of goals.

3.Quality Control: The waterfall model places a high emphasis on quality control and testing at each
phase of the project, to ensure that the final product meets the requirements and expectations of the
stakeholders.

4.Rigorous Planning: The waterfall model involves a careful planning process, where the project scope,
timelines, and deliverables are carefully defined and monitored throughout the project lifecycle.

Overall, the waterfall model is used in situations where there is a need for a highly structured and
systematic approach to software development. It can be effective in ensuring that large, complex
projects are completed on time and within budget, with a high level of quality and customer satisfaction.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Phases of Waterfall Model

1. Requirement Analysis:
▪ In this phase, all the requirements of the system to be developed are gathered and documented.
▪ Stakeholders, end-users, and business analysts collaborate to define detailed software requirements.
▪ The goal is to ensure that the project has clear and complete requirements before development begins.

2. System Design:
▪ Based on the requirements gathered in the first phase, the system’s architecture and design are created.
▪ This phase includes:
▪ High-Level Design (HLD): The system architecture, components, modules, and their connections.
▪ Low-Level Design (LLD): Detailed design for each module, including data flow diagrams, algorithms,
and interface details.

3. Implementation (Coding):
▪ The actual coding of the system takes place in this phase.
▪ Developers write code based on the design documents.
▪ The coding is done in programming languages and follows the coding guidelines, standards, and best
practices.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Phases of Waterfall Model

4. . Integration and Testing (Verification):

▪ Once coding is complete, the system undergoes thorough testing to identify bugs, errors, and
inconsistencies.
▪ The product is tested against the initial requirements to ensure it meets the expected outcomes.

5. Deployment (Installation):
▪ After successful testing, the software is deployed in the production environment.
▪ It is installed, configured, and made operational for end-users.
▪ Documentation and user manuals are typically provided to users for better understanding and use.

6. Maintenance:
▪ Post-deployment, the software enters the maintenance phase, which involves fixing issues, addressing
bugs, and making updates or improvements.
▪ Maintenance continues as long as the software is in use and requires periodic updates, support, or scaling.
SDLC models

Iterative Model

➢ The iterative model is a software development approach that breaks down projects into
smaller, manageable chunks called iterations.
➢ Each iteration involves planning, analysis, design, development, testing, and
deployment.
➢ It strongly focuses on collaboration, which involves regular meetings and feedback
sessions between the development team and customers.
➢ Each iteration builds upon the last, integrating new feedback.
➢ Issues are spotted early, minimizing future problems.
➢ Maintains clarity of project objectives among all parties.
➢ The iterative model is an improvement over the waterfall model. The waterfall model
is linear, while the iterative model is cyclical.
➢ This model is particularly useful in projects where the end product is not fully defined
or when there is a need for frequent feedback and continuous improvement.
SDLC models

Iterative Model

•The basic concept of Iterative model

is that the software should be
developed through repeated cycles
or what we also call iteration and
only a small part of it should be
developed at a time.

•This model was developed to

overcome the drawbacks of the
classical waterfall model.
SDLC models

Iterative Model

➢ In the iterative model, an initial base software is created using the set of requirements.
➢ Then features are constantly added to this base product in successive iterations until we
have a final product satisfying all requirements.
➢ We build and improve the product step by step.
➢ The functionality of the software product boosts incrementally as we progress through
various iterations.
➢ Following the initial phase, some phases repeatedly occur, expecting some improvement
with the fulfillment of each phase.
➢ Customer feedback can be incorporated easily into this model.
➢ Since there are no feedback pathways in the standard waterfall model, there is no
mechanism for error correction.
SDLC models

Iterative Model

1. Requirement Gathering & Analysis

➢ The business requirements are gathered during this phase of the iterative model.
➢ Then, an analyst determines whether they can be met within the financial constraints.
➢ This phase details the business needs, and system information (hardware or software) is
acquired.
2. Design
➢ During this phase of the iterative model, the project team receives the complete list of
criteria for starting work in a specific direction.
➢ Then, they use various diagrams, like a data flow diagram, class diagram, activity
diagram, state transition diagram, and so on, to gain explicit knowledge of the program
design and to help them progress with development.
➢ Based on their investigation, developers provide viable solutions.
SDLC models

Iterative Model
3. Implementation
➢ All needs, planning, and design plans have been carried out.
➢ The chosen design will be implemented by the developer using predefined coding and metrics
standards.
➢ They must implement a unit test at each stage of code development and should strive to produce a
fully functional, testable system for that iteration.
4. Testing
➢ This stage entails comparing the current build iteration to a set of rules and norms to determine
whether or not it fits them.
➢ This sort of testing includes performance testing, security testing, requirements testing, system
testing , usability testing, and so on.
➢ We can also check in with the project stakeholders to perform some tests and get their input.
➢ A developer or tester must guarantee that correcting one bug does not result in the appearance of
new bugs in the system.
SDLC models

Iterative Model

5. Deployment
➢ After completing all the phases, the software is deployed to its work environment.

6. Review
➢ In this phase, after the product deployment, we check the behavior and validity of the deployed product.
➢ If any errors are found, the process starts again.
7. Maintenance
➢ In the maintenance phase, after software deployment in the working environment, there may be some bug
fixes or new updates required.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Spiral Model
• The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic and
iterative approach to software development.
• The Spiral Model is a combination of the waterfall model and the iterative model. It provides support for Risk
Handling.
• In its diagrammatic representation, looks like a spiral with many loops.
• The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the
spiral is called a phase of the software development process.
Some Key Points regarding the phase of a Spiral Model:
1.The exact number of phases needed to develop the product can be varied by the project manager depending
upon the project risks.

2.As the project manager dynamically determines the number of phases, the project manager has an important
role in developing a product using the spiral model.

3.It is based on the idea of a spiral, with each iteration of the spiral representing a complete software development
cycle, from requirements gathering and analysis to design, implementation, testing, and maintenance.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Phases of the Spiral Model

The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through multiple
iterations of the software development process. It consists of the following phases:
1.Objectives Defined: The first phase of spiral model clarify what the project aims to achieve, including
functional and non-functional requirements.

2.Risk Analysis: In the risk analysis phase, the risks associated with the project are identified and evaluated.

3.Engineering: In the engineering phase, the software is developed based on the requirements gathered in
the previous iteration.

4.Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the customer’s
requirements and if it is of high quality.

5.Planning: The next iteration of the spiral begins with a new planning phase, based on the results of the
evaluation.

➢ The Spiral Model is often used for complex and large software development projects, as it allows for a
more flexible and adaptable approach to software development. It is also well-suited to projects with
significant uncertainty or high levels of risk.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The
functions of these four quadrants are discussed below:
1.Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.

2.Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select
the best possible solution. Then the risks associated with that solution are identified and the risks are
resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best
possible solution.

3.Develop the next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the software is
available.

4.Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-far
developed version of the software. In the end, planning for the next phase is started.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Incremental Process Model

• First, a simple working system implementing only a

few basic features is built and then that is delivered
to the customer.
• Then thereafter many successive iterations/ versions
are implemented and delivered to the customer until
the desired system is released.

• A, B, and C are modules of Software Products that

are incrementally developed and delivered.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

1.Requirement analysis: In Requirement Analysis At any time, the plan is made just for the next increment
and not for any kind of long-term plan. Therefore, it is easier to modify the version as per the needs of the
customer.

2.Design & Development: The Development Team first undertakes to develop core features (these do not
need services from other features) of the system. Once the core features are fully developed, then these are
refined to increase levels of capabilities by adding new functions in Successive versions. Each incremental
version is usually developed using an iterative waterfall model of development.

3.Deployment and Testing: After Requirements gathering and specification, requirements are then split into
several different versions starting with version 1, in each successive increment, the next version is
constructed and then deployed at the customer site. in development and Testing the product is checked and
tested for the actual process of the model.

4.Implementation: In implementation After the last version (version n), it is now deployed at the client site.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Prototyping Model

• The Prototyping Model is one of the most popularly used Software Development Life Cycle Models (SDLC
models).
• This model is used when the customers do not know the exact project requirements beforehand.
• In this model, a prototype of the end product is first developed, tested, and refined as per customer feedback
repeatedly till a final acceptable prototype is achieved which forms the basis for developing the final product.
• In this process model, the system is partially implemented before or during the analysis phase thereby
allowing the customers to see the product early in the life cycle.
• The process starts by interviewing the customers and developing the incomplete high-level paper model.
• This document is used to build the initial prototype supporting only the basic functionality as desired by the
customer.
• Once the customer figures out the problems, the prototype is further refined to eliminate them.
• The process continues until the user approves the prototype and finds the working model to be satisfactory.

• A classic example of a prototype model in SDLC would be developing a basic, interactive version of an online shopping
website.
• Where users can browse product categories, add items to a cart, and proceed to a checkout page, allowing customers
to provide feedback on the layout, navigation, and functionality before building the full-fledged website.
• This allows for adjustments to the design based on user experience before committing to a final product.
 CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Steps of Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in
designing a prototype model. In this phase, users are asked about what they
expect or what they want from the system.
Step 2: Quick Design: This is the second step in the Prototyping Model. This
model covers the basic design of the requirement through which a quick
overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype
from the knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing
where the investigation of the performance model occurs, as the customer
will tell the strengths and weaknesses of the design, which was sent to the
developer.
Step 5: Refining Prototype: If any feedback is given by the user, then
improving the client’s response to feedback and suggestions, the final
system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase
of the Prototyping Model where the final system is tested and distributed to
production, here the program is run regularly to prevent failures.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Rapid Application Development Model

(RAD)
• IBM first proposed the Rapid Application Development or RAD Model in the 1980s.
• The RAD model or Rapid Application Development model is a type of software development methodology
that emphasizes quick and iterative release cycles,
• It primarily focusing on delivering working software in shorter timelines.
• The RAD model is used when the requirements are fully understood, and the component-based construction
approach is adopted.
• Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build or Construction,
and finally Deployment.
• A software project can be implemented using this model if the project can be broken down into small
modules wherein each module can be assigned independently to separate teams.
• These modules can finally be combined to form the final product.
• Development of each module involves the various basic steps as in the waterfall model i.e. analyzing,
designing, coding, and then testing, etc.
• Another striking feature of this model is a short period i.e. the time frame for delivery(time-box) is generally
60-90 days.
• Multiple teams work on developing the software system using the RAD model parallelly.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

This model consists of 4 basic phases:

1.Requirements Planning – This involves the use of various techniques used in requirements like
brainstorming, task analysis, form analysis, user scenarios, etc. It also consists of the entire structured plan
describing the critical data, methods to obtain it, and then processing it to form a final refined model.

2.User Description – This phase consists of taking user feedback and building the prototype using
developer tools. In other words, it includes re-examination and validation of the data collected in the first
phase. The dataset attributes are also identified and explained in this phase.

3.Construction – In this phase, refinement of the prototype and delivery takes place. It includes the actual
use of powerful automated tools to transform processes and data models into the final working product.
All the required modifications and enhancements are to be done in this phase.

4.Cutover – All the interfaces between the independent modules developed by separate teams have to
be tested properly. The use of powerfully automated tools and subparts makes testing easier. This is
followed by acceptance testing by the user.

For example, the popular ride-sharing app, Uber, employed the RAD model to quickly release its initial product,
facilitating user feedback and accelerating improvements.
As a result, Uber was able to gain a significant market share in a short time and revolutionised the transportation
industry.
Requirement Analysis

Requirement Analysis: Definition of System Analysis, Requirement Anticipation,

Knowledge and Qualities of System Analyst, Role of a System Analyst, Feasibility Study
And It’s Types, User Transaction Requirement, User design Requirements, SRS(System
Requirement Specification)
System Analysis

System analysis is the process of studying a system to identify its goals, and then designing and implementing
solutions to achieve those goals.
It's a problem-solving technique that involves breaking down a system into its components and analyzing how
they work together.
What does system analysis involve?
Gathering data
Interpreting information
Identifying issues
Designing a system
Testing the system
Evaluating the system
Putting the system into action
Maintaining the system
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Requirements Analysis

• Requirement analysis is significant and essential activity after induction.

• We analyze, refine, and scrutinize the gathered requirements to make consistent and
unambiguous requirements.
• This activity reviews all requirements and may provide a graphical view of the entire
system.
• After the completion of the analysis, it is expected that the understandability of the
project may improve significantly.
• Here, we may also use the interaction with the customer to clarify points of confusion
and to understand which requirements are more important than others.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

System Analysis
It is the very first step in any system development and the critical phase where developers come together to
understand the problem, needs, and objectives of the project.
Some of the key aspects of system analysis are:
1.Problem Identification: It involves identifying the issues that the system is aiming to address. Whether it is
automating a business process, improving data management, or improving the user experience, understanding
the problem is the first and most important step.

2.Requirements Gathering: Once the problem is identified, the next step is to gather and write down the
requirements. This involves communicating with the customer and developer to gather information about how
the system is to be designed.

3.Feasibility study: Before going into development, it is important to check the feasibility of the project. This
includes the evaluation of technical, operational, and financial aspects to determine the feasibility of the
proposed solution.

4.Analysis and modeling: To get a deep insight into the system, analysts develop various models, such as Data
Flow Diagrams(DFD), Use Cases, and Entity-Relationship(ER) diagrams. These models help the customer to
visualize the system and its interactions.

5.Scope Definition: Defining the scope of the system is important to prevent adding excessive features to the
system and ensure that the project stays within its limits. It identifies what is part of the system and what is not.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

What is the role of a systems analyst?

The Systems analyst performs the following roles during various phases of SDLC. He works as a:
•Problem Investigator: The analyst studies the problems and needs of an organization during feasibility and
requirements analysis phases of SDLC. He visits the various departments of the organization and interviews the
users. He analyses the problems of the current system and collects their new requirements.
•Problem Solver: The analyst solves the problems of the current system faced by the users. He determines how
people, method and technology can improve the current system. After feasibility analysis, he presents the system
proposal to the management.
•Motivator: The analyst motivates users to participate in development and implementation of the proposed
system. This helps to understands user’s feelings about the proposed system. The analyst interprets the thoughts
of users and hence, draws conclusions.
•Project Manager: The analyst monitors the development and implementation of software in relation to quality,
cost and time. He works with the project leader for managing the project properly.
•Systems Designer : The analyst creates a detailed logical (proposed) design of the system.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Qualities of Systems Analyst

Success in systems analysis requires interpersonal and technical skills of the analyst. The systems analyst is
expected to possess the following qualities:
•Qualified: The analyst must be highly qualified in software technology. Besides software, he should have a good
knowledge of hardware and latest communication and networking technology. He must have a thorough awareness
about the working (manual and computerized) of financial accounting, sales and marketing, invoicing, inventory
control, production and other information systems of different organization.

•Analytical Thinker: The analyst must be capable to extract real problems of the users by analyzing the existing
system. He is expected to provide the best solutions to the problems. He should be able to provide more than one
solution to a single problem so that the users can select the best one. The systems analyst must be capable of
tackling any problem of the user. He must be a problem solver and not a problem creator.

•Good Communicator: The analyst must have a good communication and presentation skills. He must have an
excellent command on the language which the user can understand. There should not be any communication gap
between the systems analyst and users.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

•Experienced: The analyst should be experienced in both information and management technologies. He
should be associated with all types of business concerns ( viz., Manufacturing, Trading, Financial, etc.). The
present day systems analysts are expected to possess a good experience in development of software using
4GLS (such as Oracle, Sybase, etc.) and object-oriented languages (such as C++).

•Creator: The analyst should possess excellent creativity skills that help to convert ideas of the users into
concrete plans. He/she should be capable of creating plans and designing systems by drawing diagrams,
charts and other illustrations.

•Trainer: The analyst should be a good teacher for educating and training users in computer based information
systems.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Feasibility Study And It’s Types

• A feasibility study, is designed to reveal whether a project/plan is feasible.

• The process of conducting a feasibility study in software engineering involves analyzing all
aspects of the project when planning it before starting it.
• The process involves collecting data and evaluating different aspects of the project based
on specific parameters such as time and budget constraints.
• After analyzing all factors involved in planning the project, participants will reach a
consensus regarding whether or not it is feasible to complete this project within the given
time frame and budget constraints.
• After determining if this project is feasible, participants will plan how to complete this
project by creating documentation for each phase of this process using DFD- modeling
techniques for designing software systems- dynamic flow mapping for designing flow in
computer applications, etc.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Types of Feasibility Study

CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Technical feasibility

• Technical Feasibility analyzes/evaluates current resources for hardware, software, and technology
needed to develop the project.
• This technical feasibility study provides information on whether the appropriate resources and
technology required for use in project development are in place.
• In addition, the feasibility study also analyzes the technical strength and capabilities of the technical
team, whether existing technology can be used, and whether the selected technology is easy to
maintain and upgrade.
• Analyze the technical skills and capabilities of software development team members.
• Determine if the relevant technology is stable and established.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Operational Feasibility

• Operational feasibility is a measure of how well a proposed system can solve problems and meet
requirements.
• It's a part of a feasibility study that assesses an organization's ability to complete a project.
• Along with these other operational areas, it determines the product’s usability, whether the software
development team’s decisions for the proposed solution are acceptable, and so on.
• Determine if the expected issue in the user request is a high priority.
• Determine if the organization is satisfied with alternative solutions proposed by the software
development team.
• Determine if the solution proposed by the software development team is acceptable.
• Analyze whether users are comfortable with new software.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Economic feasibility

• Project costs and benefits are analyzed in a profitability study. This means that as part of this
feasibility study, a detailed analysis of the costs of the development project will be made.
• This includes all costs necessary for the final development, such as hardware and software
resources required, design and development costs, operating costs, etc.
• It is then analyzed whether the project is financially beneficial to the organization.
• The costs incurred in software development generate long-term benefits for an organization.
• Costs required to conduct a complete software study (e.g., requirements extraction and
requirements analysis).
• Hardware, software, development team, and training costs.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Legal Feasibility

• In a legal feasibility study, the project is analyzed from the view of legality.
• This includes analysis of obstacles in the legal implementation of the project, data protection or
social media laws, project certificates, licenses, copyrights, etc.
• Overall, a legal feasibility study is a study to determine whether a proposed project meets legal and
ethical requirements.

Schedule Feasibility

• A schedule feasibility study mainly analyzes the proposed project deadlines/deadlines,

including the time it will take the team to complete the final project.
• This has a significant impact on the organization as the project’s purpose may fail if it is not
completed on time.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

User transaction requirements

• “User transaction requirements" refer to the specific actions or steps a user needs to perform
within a system to complete a task.
• It gives the expected inputs, processes, and outputs from the user's perspective, essentially
detailing what the user needs to do to interact with the system to achieve a desired outcome.
• These requirements are crucial for designing user interfaces and functionalities that align with user
expectations and needs.
Example of a user transaction requirement:

•"A customer should be able to search for products by name, category, or price range, select desired
items, add them to their shopping cart, review the order summary, and proceed to checkout with
secure payment options."
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Key points about user transaction requirements:

A User Transaction Requirement defines what actions a user should be able to do in a system. It
specifies the steps a user follows to complete a task, like:
•Logging in
•Uploading or entering data
•Processing a request (e.g., making a payment, recognizing a license plate)
•Getting a result (e.g., confirmation, report, or notification)

Key Points in Simple Terms

•Users should be able to perform actions like adding, updating, or deleting data.
•The system must keep data accurate and prevent errors.
•Multiple users can use the system at the same time without issues.
•Security measures like login and permissions should be in place.
•If something goes wrong, the system should recover smoothly.
•The process should be user-friendly and fast.
•The system should handle large numbers of users efficiently.
•All transactions should be tracked for security and troubleshooting.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

User Transaction: Automatic License Plate Recognition (ALPR) for Parking Entry
1. User Action:
•A vehicle approaches the parking entry gate.
•The camera captures the license plate image.
•The system processes the image to recognize the license plate number.
•If the plate is valid, the gate opens.
•The system logs the entry time and stores vehicle details.
2. System Requirements for This Transaction:
Functional Requirements
•Capture and process the license plate image.
•Extract and match the plate number with the database.
•Grant or deny access based on the result.
Data Integrity & Security
•Ensure the recognized number is stored correctly.
•Protect vehicle data from unauthorized access.
Error Handling
•If recognition fails, retry or request manual entry.
•Log errors for future analysis.
Performance & Scalability
•Process transactions within 2 seconds.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Requirements

• A Software Requirement is a documented that a particular software service or product

needs to meet, to consider the software as complete.
• These particular requirements are mostly derived from the stakeholder’s and customer's
needs.
• Software requirements, including requirements engineering, guide planning, designing,
implementation, testing, and maintenance stages, acting as a critical link among all
aspects of the project.
• Software requirements can be broadly classified into three main categories:
Functional, Non-Functional Requirements and Domain Requirements.

Software Requirements are mainly classified into three types:

•Functional requirements

•Non-functional requirements

•Domain requirements
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Functional Requirements

Definition: Functional requirements describe what the software should do. Functional
requirements define all specific features and functionalities that a system must offer. These
are directly visible in the final product.
Examples:
•User Authentication: The system must allow users to log in using a username and password.

•Search Functionality: The software should enable users to search for products by name or
category.

•Report Generation: The system should be able to generate sales reports for a specified date
range.

•Measurable: the requirements can be verified through testing

Explanation: Functional requirements specify the actions that the software needs to perform.
These are the basic features and functionalities that users expect from the software.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Non-functional Requirements

Definition: Non-functional requirements focus on quality attributes and constraints rather than
specific functionalities. It specifies how the system performs a particular function, rather than what
the system performs. These requirements are concerned with the quality of the system.
Examples:
1)Security: Authorization, authentication and confidentiality.

2) Performance: Response time and resource usage.

3) Usability: User interface design, accessibility, user experience.

4) Reliability: Availability, error handling, recoverability.

5) Maintainability: Modifiability, testability, scalability.

6) Portability: Transferability to different environments.

Explanation: Non-functional requirements are about the system’s behavior, quality, and constraints. They
ensure that the software meets certain standards of performance, usability, reliability, and security.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Domain Requirements

Definition: Domain requirements are specific to the domain or industry in which the software
operates. They include terminology, rules, and standards relevant to that particular domain.
Examples:
•Healthcare: The software must comply with WHO regulations for handling patient data.

•Finance: The system should adhere to GAAP standards for financial reporting.

•E-commerce: The software should support various payment gateways like PayPal, Stripe,
and credit cards.

Explanation: Domain requirements reflect the unique needs and constraints of a particular
industry. They ensure that the software is relevant and compliant with industry-specific
regulations and standards.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

SRS(System Requirement Specification)

• A software requirement specifications (SRS)

document lists the requirements,
expectations, design, and standards for a
future project.
• These include the high-level business
requirements dictating the goal of the
project, end-user requirements and needs,
and the product’s functionality in technical
terms.
• To put it simply, an SRS provides a detailed
description of how a software product
should work and how your development
team should make it work.
• A basic SRS document outline has four parts:
an introduction, system and functional
requirements, external interface
requirements, and non-functional
requirements.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Requirement Specification (SRS)

Depending upon information gathered after interaction, SRS is developed which describes requirements of
software that may include changes and modifications that is needed to be done to increase quality of product
and to satisfy customer’s demand.

• Introduction

➢ Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of
document is explained and described.

➢ Scope of this document – In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of development cost and time
required.

➢ Overview – In this, description of product is explained. It’s simply summary or overall review of product.

• General description
In this, general functions of product which includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of user community.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

• Functional Requirements
In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed in a
ranked order. Functional requirements specify the expected behavior of the system-which outputs should be
produced from the given inputs. They describe the relationship between the input and output of the system. For
each functional requirement, detailed description all the data inputs and their source, the units of measure, and
the range of valid inputs must be specified.
• Interface Requirements
In this, software interfaces which mean how the system interacts with external entities such as hardware,
software, users, and other systems. These requirements ensure compatibility, communication, and integration
between different components of the system.
• Performance Requirements
In this, how a software system performs desired functions under specific condition is explained. It also explains
required time, required memory, maximum error rate, etc. The performance requirements part of an SRS specifies
the performance constraints on the software system. All the requirements relating to the performance
characteristics of the system must be clearly specified. There are two types of performance requirements: static
and dynamic. Static performance refers to the system’s performance under a predefined, fixed workload or
resource conditions. Dynamic performance refers to the system’s ability to handle changing conditions such as
variable workloads, user interactions, and resource demands.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

• Design Constraints
Design Constraints in a Software Requirements Specification (SRS) define the limitations and restrictions
that impact the system’s architecture, development, and implementation. These constraints ensure the
system meets regulatory, technical, and business requirements while maintaining feasibility. Example:
Ram, Memory, Operating system, database usage.
• Non-Functional Attributes
In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
• Preliminary Schedule and Budget
In this, initial version and budget of project plan are explained which include overall time duration
required and overall cost required for development of project.
• Appendices
In this, additional information like references from where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are given and explained.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Characteristics of good SRS

1. Correctness: User review is used to provide the accuracy of requirements stated in

the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
• All essential requirements, whether relating to functionality, performance, design,
constraints, attributes, or external interfaces.
• Definition of their responses of the software to all realizable classes of input data in
all available categories of situations.
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Characteristics of good SRS

5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance
or stability of that particular requirement.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be
perfectly indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear
and if it facilitates the referencing of each condition in future development or
enhancement documentation.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Analysis and Design Tools: Entity Relationship Diagrams,

Data Flow Diagrams (DFD), Data Dictionary & Elements of
Data Dictionary, Pseudo code, Input and Output Design.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Data Flow Diagram (DFD)

• A Data Flow Diagram (DFD) is a graphical representation of the flow of data within a
system, commonly used in software engineering for system analysis and design.
• A Data Flow Diagram (DFD) is a structured analysis tool used to visualize how data
moves through a system.
• It helps in understanding the flow of information, inputs, processes, outputs, and
data storage.

Importance in Software Engineering

•Provides clear visualization of data movement.
•Helps in system analysis and design.
•Facilitates communication between developers, designers, and stakeholders.
•Supports modular development, making it easier to manage complex systems.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

3. Components of DFD

1.External Entities – an outside system that sends or receives data, communicating with
the system being diagrammed. They are the sources and destinations of information
entering or leaving the system.
2.Processes – any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business
rules. A short label is used to describe the process, such as “Submit payment.”
3.Data Stores – files or repositories that hold information for later use, such as a
database table or a membership form. Each data store receives a simple label, such as
“Orders.”
4.Data Flows – the route that data takes between the external entities, processes and
data stores. It portrays the interface between the other components and is shown with
arrows, typically labeled with a short data name, like “Billing details.”
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

symbols and notations are used to represent Components of DFD

Processes (Circles or Ovals)

Represent actions or transformations that occur in the
system.
Each process has an input and output.
Data Stores (Open-ended rectangles)
Represent data repositories where information is stored
for future use.
Data can be retrieved from or written to these stores.
External Entities (Squares or Rectangles)
Represent sources or destinations of data external to the
system (e.g., users, other systems).
Data Flows (Arrows)
Indicate the movement of data between processes, data
stores, and external entities.
Each arrow is labeled to describe the type of data being
transferred.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

0-level DFD
• It is also known as a context diagram.
• It’s designed to be an abstraction view.
• It’s a basic overview of the whole system or process being analyzed or modeled.
• It’s designed to be an at-a-glance view, showing the system as a single high-level process, with its relationship
to external entities.
• It should be easily understood by a wide audience, including stakeholders, business analysts, data analysts
and developers.
• It represents the entire system as a single bubble with input and output data indicated by
incoming/outgoing arrows.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

DFD Level 1
•DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram.
•This level provides a more detailed view of the system by breaking down the major processes identified
in the level 0 DFD into sub-processes.
•Each sub-process is depicted as a separate process on the level 1 DFD.
•The data flows and data stores associated with each sub-process are also shown.
•In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
•In this level, we highlight the main functions of the system and breakdown the high-level process of 0-
level DFD into subprocesses.

2-level DFD

• This level provides an even more detailed view of the system by breaking down the sub-processes
identified in the level 1 DFD into further sub-processes.
• Each sub-process is depicted as a separate process on the level 2 DFD.
• The data flows and data stores associated with each sub-process are also shown.
Level 1 DFD
Level 2 DFD
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Data Dictionary

• A data dictionary is a centralized repository that contains information about the data in a
database.
• It serves as a detailed reference that describes each data element, including its structure,
purpose, and usage.
• In database design, a data dictionary helps ensure data consistency, integrity, and proper
documentation, making it a vital tool for developers, analysts, and administrators.

• Purpose of a Data Dictionary

•Improved Data Management: Ensures everyone understands the data’s structure and
purpose.
•Enhanced Data Integrity: Maintains consistency by defining data types, formats, and
constraints.
•Facilitates Communication: Acts as a shared reference for developers, designers, and
users.
•Easier Maintenance: Helps in troubleshooting and updating databases.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Elements of a Data Dictionary

A comprehensive data dictionary typically includes the following key elements:

CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Notation Used to Show Structural Relationships in Data

SYMBOL MEANING EXPLANATION USE

= Is equivalent to Alias Denotes synonyms
+ and Concatenation defines Denotes sequence relationship
components always included in a
particular data structure
[] Either/or Defines alternate components o a Denote selection relationship
data structure

{} Iteration of Defines the repetition of a Denote iteration relationship

component in a data structure

() Optional Defines iteration that occurs only Denote optional relationship

0 or 1 items
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Data Descriptions and Notation

Invoice = Payment request

Payment voucher = Invoice package + payment approval

Invoice receipt = Signed invoice

Audit approval = Audited invoice

Purchase authorization Purchase order number

Manager approval
Item details = Item number + item description + item cost

Amount of invoice = {Item extension} + shipping amount ( + sales tax)

Vendor balance = Beginning balance + {purchase} + {payments} + {credits}

Beginning balance = Vendor balance *sets up next month cycle*

Symbols : = is equivalent to
= and
[ ] either/or
{ } iterations of
( ) optional
* Encloses annotation
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Pseudo Code

Pseudo code is a simplified, informal way of describing a program’s logic using plain language. It is not
written in any specific programming syntax but rather outlines the steps a program should follow. Pseudo
code is widely used in algorithm design before actual coding begins.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Structured System Design: Modules Concepts and Types of

Modules, Structured Chart, Qualities of Good Design,
Coupling, Types of Coupling, Cohesion, Types of Cohesion.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Concept of Modules
• A module is an independent unit of code that performs a specific function or set of related
functions.
• In software development, modular design breaks a large system into smaller, manageable
parts called modules.
• Each module typically has its own functionality, making the system easier to build,
maintain, and test.

Key Characteristics of a Module

• Independent Functionality: Each module focuses on a specific task.
• Reusability: Well-designed modules can be reused in multiple projects.
• Interchangeability: Modules can be updated or replaced without affecting the entire
system.
• Maintainability: Isolating functionality simplifies bug fixes and enhancements.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Types of Modules
Modules are categorized based on their design, purpose, and role in a system.
1. Functional Modules: Focus on specific business logic or functional requirements. Example: A
PaymentProcessing module for handling transactions.
2. Data Modules: Handle data storage, retrieval, and management. Example: A Database Connector module
that interacts with a database.
3. Control Modules: Manage the flow of data and coordinate other modules. Example: A Workflow Controller
that guides the sequence of tasks.
4. Utility Modules: Provide reusable helper functions or general-purpose features. Example: A String Utils
module for text processing.
5. Service Modules: Offer specialized services via APIs or web interfaces. Example: An Email Service module
for sending automated emails.
6. UI/Presentation Modules: Handle user interface elements, such as web pages or app screens. Example:
A LoginScreen module with form design and input validation.
7. Security Modules: Ensure system protection through encryption, authentication, or authorization.
Example: An authorized Module for managing user logins and permissions.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Structure Charts (SC)

• A Structure Chart (SC) is a graphical representation of a software system’s modular structure.

• It illustrates the hierarchical organization of various modules in the system, showing how they
interact and communicate with each other.
• Structure charts are commonly used in top-down design and modular programming to break
down complex systems into manageable components.

Benefits of Structure Charts

• Clear Visual Representation: Shows system flow, making complex designs easier to
understand.
• Improved Modularity: Encourages dividing software into independent modules.
• Enhanced Maintainability: Easier to modify or replace individual modules.
• Better Testing: Each module can be tested independently.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Design

• Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
• Software design is the process of defining the architecture, components, interfaces, and other
characteristics of a software system. It involves planning how the software will meet specified
requirements and ensuring its structure is efficient, maintainable, and scalable.
• McGlaughlin suggests three characteristics that serve as a guide for the evaluation of a good
design:
➢ The design must implement all of the explicit requirements contained in the analysis model,
and it must accommodate all of the implicit requirements desired by the customer.
➢ The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.
➢ The design should provide a complete picture of the software, addressing the data, functional,
and behavioural domains from an implementation perspective.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Design Principles

• The design process should not suffer from “tunnel vision.”

Tunnel vision refers to an overly narrow focus on a single aspect of design, often ignoring
alternative approaches, potential risks, or broader system requirements. This can lead to:
•Overly rigid designs that lack flexibility.
•Missed opportunities for innovation or improvement.
•Ignoring scalability or future growth needs.
•Increased technical debt due to short-sighted decisions.
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel: Instead of building something from scratch, you should
utilize existing resources to save time, reduce errors, and improve the overall quality of the
software.
• The design should exhibit uniformity and integration: a software system should maintain a
consistent structure, style, and behavior across all its components while ensuring seamless
interaction between those components.
• The design should be structured to accommodate change.
• The design should be reviewed to minimize conceptual errors.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Design Concepts

• software design concepts provide the necessary framework

for "getting it right.“
• Abstraction
• Refinement
• Modularity
• Software Architecture
• Control Hierarchy
• Structural Partitioning
• Data Structures
• Software Procedures
• Information Hiding
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Design Concepts
1. Abstraction: Hides complex implementation details and exposes only essential features.
• Purpose: Simplifies design by focusing on high-level functionality.
• Example: A Car class with methods like start(), stop(), and drive() without exposing internal engine
mechanics.
2. Refinement: Gradually elaborating the system design by breaking high-level tasks into detailed steps.
• Purpose: Progressively narrows the focus from general to specific.
• Example: Starting with a broad plan for license plate recognition, then refining steps into detection,
dehazing, and text extraction.
3. Modularity: Divides the system into independent, interchangeable modules.
• Purpose: Enhances maintainability, reusability, and scalability.
• Example: Separating your Admission model, Finance detection, and Result into distinct modules.
4. Software Architecture: Describes the overall structure, components, and interactions of the system.
• Purpose: Provides a blueprint for software design.
• Example: Using Layered Architecture for better separation of concerns.
5. Control Hierarchy (Program Structure)
• Definition: Defines the flow of control between modules or components.
• Purpose: Ensures clear communication and minimizes dependency issues.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

6. Structural Partitioning: Divides the system structure based on functionality.

• Purpose: Improves flexibility and scalability.
• Example: A web application split into Frontend, Backend, and Database layers.
7. Data Structures: Organizes and manages data efficiently for improved performance.
• Purpose: Ensures optimal data storage, access, and manipulation.
• Example: Using hash tables for student enrollment lookup.
8. Software Procedures (Algorithms) : Defines step-by-step instructions to achieve a task.
• Purpose: Provides clear logic for tasks like image enhancement or data processing.
• Example: Implementing a filter for noise reduction in noisy images.
9. Information Hiding: Conceals internal implementation details from external access.
• Purpose: Improves security, reduces complexity, and minimizes the impact of changes.
• Example: Hiding the internal logic of code
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Cohesion

• Cohesion refers to the degree to which the elements within a module or component
are related and work together to achieve a single, well-defined purpose.
• In simpler terms, it measures how well the parts of a module work together to
achieve a single purpose.
• Think of a module as a team — if all team members are working toward the same
goal, the team is cohesive. If everyone is doing unrelated tasks, the team lacks
cohesion.
• A cohesive software module should focus on just one task or purpose.
Why Cohesion Matters
High cohesion leads to:
•Better maintainability
•Improved readability
•Enhanced reusability
•Easier testing and debugging
CA2203: SOFTWARE ENGINEERING [3 1 0 4]
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Types of Cohesion (From Weakest to Strongest)

1. Coincidental Cohesion (Weakest) : Elements are grouped randomly with no meaningful connection.
• Example: A module that handles file I/O, database updates, and error logging.
• Impact: Leads to poor maintainability and high complexity.
2. Logical Cohesion: Elements perform similar types of functions but are invoked based on a control flag or
condition.
• Example: A function handling multiple formats like .jpg, .png, or .bmp using a switch-case structure.
• Impact: Difficult to test and extend.
3. Temporal Cohesion: Elements are related only because they are executed at the same time.
• Example: A startup routine that initializes database connections, logs, and UI.
• Impact: Reduces flexibility and maintainability.
4. Procedural Cohesion: Elements are grouped because they follow a specific sequence of execution.
• Example: A module that reads data, processes it, and then writes the output.
• Impact: Better than temporal cohesion but still lacks independence.
5. Communicational Cohesion: Elements operate on the same data or contribute to the same output.
• Example: A function that collects sensor data, processes it, and updates a dashboard.
• Impact: Improves modularity but may require careful data management.
6. Sequential Cohesion: The output of one element becomes the input for another.
• Example: An enhancement module feeding processed images directly into a vehicle detection model.
• Impact: Improves clarity and purpose but still creates dependencies.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Coupling

• Coupling refers to the degree of dependency between software modules.

• It measures how much one module relies on another to function correctly.
• If two modules are tightly coupled, they are closely linked and changes in one can
heavily impact the other.
• Conversely, if they are loosely coupled, they are more independent, making the
system easier to maintain and extend.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Types of Coupling

1. Content Coupling :One module directly modifies or relies on the internal details of another.
Example: Module A directly accesses or changes variables in Module B.
2. Common Coupling: Multiple modules share a global variable.
Example: Modules A and B both read/write data from a shared global file.
3. External Coupling: Modules depend on external systems or hardware interfaces.
Example: A module that requires a specific database schema or API format.
4. Control Coupling: One module controls another’s behavior by passing control flags or
conditions.
Example: Passing a mode flag 'train' or 'test'.
5. Stamp Coupling: Modules pass complex data structures rather than specific data items.
Example: Sending an entire image object when only image_size is needed
6. Data Coupling :Modules share only necessary data via parameters.
Example: A vehicle detection module calls a image enhancement function by passing
only image_data.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Structure Charts (SC)

• SC shows the static structure, not the logic and different from flow charts.
• Structure is decided during design.
• SC represents modules and interconnections
• Each module is represented by a box
• If A invokes B, an arrow is drawn from A to B
• Arrows are labeled by data items
• Different types of modules in a SC exist such as Input, output, transform,
coordinate and composite modules.
• Implementation does not change structure and structure affects
maintainability.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Different Types of modules

CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Iteration and decision

CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Structured Design Methodology

• SDM views software as a
transformation function
that converts given inputs
to desired outputs.
• The focus of SD is the
transformation function. Input Transformation Output
• Uses functional functions
abstraction.
• Specify functional modules
and connections.
• Low coupling and high
cohesion is the objective
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Steps of SDM
1. Identify most abstract inputs and most
abstract outputs in a DFD
2. First level factoring
3. Factoring of input, output, transform
modules
4. Improving the structure
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Step 1
Most abstract inputs:
• data elements in DFD that are furthest from the actual
inputs, but can still be considered as incoming. These are
logical data items for the transformation.
• Travel from physical inputs towards outputs until data can
no longer be considered incoming.
• Go as far as possible, without loosing the incoming nature.
Most abstract outputs:
• Similar as of most abstract inputs.
• Represents a value judgment, but choice is often obvious.
Bubbles between mai and mao: central transforms
• These transforms perform the basic transformation
• With mai and mao the central transforms can concentrate
on the transformation
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Example – counting the no of different

words in a file
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Step 2: First Level Factoring

• Divided the problem into three separate
problems
• Each of the three diff. types of modules
can be designed separately
• These modules are independent
• For each most abstract input data item,
specify a subordinate input module
• The purpose of these input modules is
to deliver to main the mai data items
• For each most abstract output data
element, specify an output module
• For each central transform, specify a
subordinate transform module
• Main module is a coordinate module
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Step 3: Factoring Input modules

• The transform that produced the mai data is
treated as the central transform
• Then repeat the process of first level factoring
• Input module being factored becomes the main
module
• A subordinate input module is created for each
data item coming in this new central transform
• A subordinate module is created for the new
central transform
• Generally, there will be no output modules
• The new input modules are factored similarly Till
the physical inputs are reached
• Factoring of the output modules is symmetrical
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Step 3: Factoring Central Transforms

• No rules for factoring the
transform modules
• Top-down refinement process
can be used
• Determine sub-transforms that
will together compose the
transform
• Then repeat the process for newly
found transforms
• Treat the transform as a problem
in its own right
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Step 4
• The above steps should not be followed blindly
• The structure obtained should be modified if needed
• Low coupling, high cohesion being the goal
• Design heuristics used to modify the initial design
• Design heuristics - A set of thumb rules that are generally useful
➢ Module Size: Indication of module complexity Carefully examine modules
less than a few lines or greater than about 100 lines
➢ Fan out: no. of arrows going out of the module, indicating the no. of sub
ordinates of the module
➢ fan in: no. of arrows coming in the module, indicating the no. of super
ordinates of the module
➢ A high fan out is not desired, should not be increased beyond 5 or 6
➢ Fan in should be maximized
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Testing: Definition, Test characteristics, Types of

testing - BlackBox Testing, White-Box Testing, Stress Testing,
Performance Testing.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

• Software Testing is the process of evaluating a software application to

identify and fix defects, ensure it meets specified requirements, and improve
overall quality.

• It involves executing a system or application under controlled conditions to

verify that it behaves as expected.
Objectives of Software Testing:
• Ensure software quality and reliability
• Detect defects and errors
• Validate that software meets user requirements
• Enhance software security and performance
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Characteristics of Software Testing

• Reliability – Ensures that the software performs consistently under specified

conditions.
• Correctness – Verifies that the software functions as intended without any
errors.
• Efficiency – Evaluates the software’s resource utilization (CPU, memory,
bandwidth).
• Maintainability – Determines the ease with which modifications and updates
can be applied.
• Portability – Ensures that the software functions across different
environments and platforms.
• Usability – Tests how user-friendly the software interface is.
• Security – Assesses the software for vulnerabilities and unauthorized access.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Testing Objectives
• Glen Myers states a number of rules that can serve well as
testing objectives:
1. Testing is a process of executing a program with the
intent of finding an error.
2. A good test case is one that has a high probability of
finding an as-yet-undiscovered error.
3. A successful test is one that uncovers an as-yet-
undiscovered error.
• In a word, our objective is to design tests that
systematically uncover different classes of errors and to
do so with a minimum amount of time and effort.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Testing Benefits
1. If testing is conducted successfully, it will uncover errors in
the software.
2. Testing demonstrates that software functions appear to be
working according to specification, that behavioural and
performance requirements appear to have been met.
3. Data collected as testing is conducted to provide a good
indication of software reliability and some indication of
software quality as a whole.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Testing Principles
• All tests should be traceable to customer requirements.
• Tests should be planned long before testing begins.
• The Pareto principle applies to software testing
• Testing should begin “in the small” and progress toward
testing “in the large.”
• Exhaustive testing is not possible.
• To be most effective, testing should be conducted by an
independent third party.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Test Case Design

• Any engineered product (and most other things) can be tested in
one of two ways:
(1) Knowing the specified function that a product has been
designed to perform, tests can be conducted that demonstrate
each function is fully operational while at the same time
searching for errors in each function;
(2) knowing the internal workings of a product, tests can be
conducted to ensure that "all gears mesh," that is, internal
operations are performed according to specifications and all
internal components have been adequately exercised.

The first test approach is called black-box testing and the second,
white-box testing.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

White-Box / Glass-Box Testing

• White-box testing, sometimes called glass-box testing, is a
test case design method that uses the control structure of
the procedural design to derive test cases. Using white-box
testing methods, the software engineer can derive test cases
that
(1) guarantee that all independent paths within a module
have been exercised at least once,
(2) exercise all logical decisions on their true and false sides,
(3) execute all loops at their boundaries and within their
operational bounds, and
(4) exercise internal data structures to ensure their validity.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Black-Box Testing
• Black-box testing, also called behavioural testing, focuses on
the functional requirements of the software. That is, black-box
testing enables the software engineer to derive sets of input
conditions
that will fully exercise all functional requirements for a program.

• Black-box testing attempts to find errors in the following

categories:
(1) incorrect or missing functions,
(2) interface errors,
(3) errors in data structures or external database access,
(4) behaviour or performance errors, and
(5) initialization and termination errors.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Black-box testing purposely disregards control

structure, attention is focused on the information
domain. Tests are designed to answer the following
questions:
• How is functional validity tested?
• How is system behaviour and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input
values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system
tolerate?
• What effect will specific combinations of data have
on system operation?
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Software Testing Strategies

• A strategy for software testing integrates software test case design
methods into a well-planned series of steps that result in the
successful construction of software.
• The strategy provides a road map that describes the steps to be
conducted as part of testing, when these steps are planned and then
undertaken, and how much effort, time, and resources will be
required. Therefore, any testing strategy must incorporate test
planning, test case design, test execution, and resultant data
collection and evaluation.
• A software testing strategy should be flexible enough to promote a
customized testing approach. At the same time, it must be rigid
enough to promote reasonable planning and management tracking as
the project progresses.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

A Strategic Approach to Software Testing

A number of software testing strategies have been proposed. All provide the software
developer with a template for testing and all have the following generic characteristics:
• Testing begins at the component level and works "outward" toward the integration of the
entire computer-based system.
• Different testing techniques are appropriate at different points in time.
• Testing is conducted by the developer of the software and (for large projects) an
independent test group.
• Testing and debugging are different activities, but debugging must be accommodated in
any testing strategy.
• A strategy for software testing must accommodate low-level tests that are necessary to
verify that a small source code segment has been correctly implemented as well as high-
level tests that validate major system functions against customer requirements.
• A strategy must provide guidance for the practitioner and a set milestones for the
manager. Because the steps of the test strategy occur at a time when dead- line pressure
begins to rise, progress must be measurable and problems must surface as early as
possible.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

Verification and Validation

• Software testing is one element of a broader topic that is often referred
to as verification and validation (V&V).
• Verification refers to the set of activities that ensure that software
correctly implements a specific function.
• Validation refers to a different set of activities that ensure that the
software that has been built is traceable to customer requirements.
• Boehm [BOE81] states this another way:
Verification: "Are we building the product right?"
Validation: "Are we building the right product?“
• Verification and validation encompasses a wide array of SQA activities
that include formal technical reviews, quality and configuration audits,
performance monitoring, feasibility study, documentation review,
database review, algorithm analysis.
CA2203: SOFTWARE ENGINEERING [3 1 0 4]

System Testing
• System testing is actually a series of different tests whose primary purpose is to fully
exercise the computer-based system. Although each test has a different purpose, all
work to verify that system elements have been properly integrated and perform
allocated functions.
• Recovery testing is a system test that forces the software to fail in a variety of ways and
verifies that recovery is properly performed. If recovery is automatic (performed by the
system itself), reinitialization, checkpointing mechanisms, data recovery, and restart are
evaluated for correctness.
• Security testing attempts to verify that protection mechanisms built into a system will, in
fact, protect it from improper penetration. During security testing, the tester plays the
role(s) of the individual who desires to penetrate the system.
• Stress testing executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume. For example, (1) special tests may be designed that
generate ten interrupts per second, when one or two is the average rate, (2) input data
rates may be increased by an order of magnitude to determine how input functions will
respond, (3) test cases that require maximum memory or other resources are executed,
Essentially, the tester attempts to break the program.
• Performance testing is designed to test the run-time performance of software within the
context of an integrated system. Performance testing occurs throughout all steps in the
testing process.