Unit 1 : Introduction to Software Engineer

Definition of Software engineering

Software engineering is the systematic application of engineering principles to the
design, development, testing, deployment, and maintenance of software. It involves
using structured methodologies, tools, and best practices to create reliable, efficient,
and scalable software solutions. The goal of software engineering is to build high-
quality software that meets user requirements while being maintainable and cost-
effective.

Characteristics of software
Software has several key characteristics that define its nature and quality:
Intangibility – Unlike hardware, software has no physical form; it exists as code
and instructions executed by a computer.
Functionality – Software is designed to perform specific tasks, whether it's
processing data, managing systems, or enabling user interactions.
Scalability – Well-designed software can handle increased loads, users, or data
without significant performance degradation.
Maintainability – Software should be easy to modify, debug, and update to adapt
to changing requirements or fix issues.
Reliability – It must function correctly under defined conditions for a specified
period, minimizing failures and errors.
Efficiency – Software should use system resources (CPU, memory, storage)
optimally to deliver high performance.
Portability – Good software can run across different operating systems or
environments with minimal changes.
Reusability – Components of the software can be reused in other projects to save
time and effort.
Security – It must protect data and operations against unauthorized access, threats,
and vulnerabilities.
User-Friendliness – Software should be intuitive and easy to use, enhancing user
experience and productivity.

Qualities of Software

In software engineering, software quality is determined by several key attributes that define
how well a software system meets requirements and expectations. These qualities are often
categorized into functional and non-functional aspects.

Key Qualities of Software:

1. Functional Qualities

These are related to the correctness and completeness of the software in fulfilling its
intended purpose.

 Correctness – The software produces accurate and expected results.

 Completeness – All required functionalities are implemented.
 Compliance – Adherence to industry standards, legal regulations, and best practices.

2. Non-Functional Qualities

These attributes impact the overall user experience and performance of the software.

A. Reliability & Maintainability

 Reliability – The software functions correctly over time without failures.

 Availability – The software is operational and accessible when needed.
 Maintainability – The ease with which the software can be updated or modified.
 Testability – How easily the software can be tested for defects.

B. Performance & Efficiency

 Performance – Speed and responsiveness under different conditions.

 Scalability – Ability to handle growth (more users, data, or requests).
 Efficiency – Optimal use of system resources (CPU, memory, bandwidth).

C. Usability & Accessibility

 Usability – The ease with which users can learn and interact with the system.
 Accessibility – The software is usable by people with disabilities.
 D. Security & Safety

 Security – Protection against cyber threats, unauthorized access, and data breaches.
 Data Integrity – Ensuring the accuracy and consistency of stored data.
 Safety – Preventing hazards in critical systems (e.g., medical or aviation software).

E. Portability & Interoperability

 Portability – The ability to run on different devices and platforms.

 Interoperability – The ability to integrate with other systems or software.

F. Extensibility & Reusability

 Extensibility – Ability to add new features without major redesigns.

 Reusability – Code components can be reused in other applications.

System Analysis and the Role of a System Analyst What

is System Analysis?

System analysis is the process of studying, evaluating, and designing information systems to
improve efficiency and effectiveness. It involves examining the components, processes, and
interactions within a system to understand its objectives and functionality. The primary goal is
to identify problems, define requirements, and propose solutions that enhance the system's
performance.

Key Phases of System Analysis

1. Problem Identification – Understanding the issues or inefficiencies in the current

system.
2. Feasibility Study – Assessing whether the new system is financially, technically,
and operationally viable.
3. Requirement Gathering – Collecting information from stakeholders to determine
system needs.
4. Data Flow and Process Modeling – Creating diagrams like DFDs (Data Flow
Diagrams) and ERDs (Entity Relationship Diagrams) to visualize system
components.
5. System Design Proposal – Developing specifications and design models for the new or
improved system.
6. Implementation Planning – Outlining steps for deploying and integrating the system.
Role of a System Analyst

A System Analyst acts as a bridge between business needs and technological solutions. They
analyze business problems, design solutions, and ensure system functionality aligns with
organizational goals.

Key Responsibilities

1. Requirement Analysis – Gather and document user needs and expectations.

2. System Design & Modeling – Create system architecture, flowcharts, and database
models.
3. Feasibility Analysis – Evaluate economic, technical, and operational feasibility.
4. Interfacing Between Stakeholders – Communicate with management, developers, and
end-users.
5. Process Optimization – Identify inefficiencies and recommend improvements.
6. Testing and Validation – Ensure the system meets requirements and performs
effectively.
7. Documentation & Training – Prepare system documentation and user manuals.

Skills Required

 Strong analytical and problem-solving abilities

 Knowledge of system development life cycle (SDLC)
 Proficiency in programming languages, databases, and modeling tools
 Communication and interpersonal skills
 Understanding of business processes

A system analyst plays a crucial role in developing efficient, scalable, and cost-effective
information systems tailored to an organization's needs.

System Development Life Cycle (SDLC)-

The System Development Life Cycle (SDLC) is a structured process used for planning,
creating, testing, deploying, and maintaining information systems. It ensures high-quality
software development while minimizing risks and costs.

Phases of SDLC:
1. Planning – Identify project scope, objectives, and feasibility.
2. Requirement Analysis – Gather and document user and system requirements.
3. Design – Create system architecture, UI design, and database models.
4. Development – Write code and build the system based on design specifications.
5. Testing – Identify and fix bugs to ensure functionality and performance.
6. Deployment – Release the system for users (pilot, phased, or full rollout).
7. Maintenance – Monitor, update, and improve the system post-deployment.
Software Development Life Cycle (SDLC) models provide structured approaches to software
development. Here are the main types:

1. Waterfall Model

 Sequential and linear approach.

 Each phase (Requirement, Design, Implementation (coding), Testing, Deployment,
Maintenance) must be completed before moving to the next.
 Best for small, well-defined projects.
 The waterfall is a universally accepted SDLC model. In this method, the whole process of
software development is divided into various phases.
 The waterfall model is a continuous software development model in which development
is seen as flowing steadily downwards (like a waterfall) through the steps of requirements
analysis, design, implementation, testing (validation), integration, and maintenance.
 Linear ordering of activities has some significant consequences. First, to identify the end
of a phase and the beginning of the next, some certification techniques have to be
employed at the end of each step. Some verification and validation usually do this mean
that will ensure that the output of the stage is consistent with its input (which is the
output of the previous step), and that the output of the stage is consistent with the overall
requirements of the system.

Advantages:

1. Simple and easy to design

2. easy to manage

3. best for small projects

4. stages are clearly defined

5. In this model once a phase is successfully completed then only we can move to the
next phase. So there is no overlapping between the phases.

Disadvantages:

1. Not good for complex Projects and large projects

2.difficult to measure progress within the stages

3.poor model for long and on going projects

2. Spiral Model

 Combines iterative and Waterfall approaches with risk assessment.

 Spiral model was developed by "Barry Bohem" in the year 1986 as a par of SEI
(Software Engineering Institute)
 It is called meta model (model about model) because it contains all the life cycle model.
 The main purpose of spiral model to reduce the risk in the project spiral model has been
introduced.
 Divides the project into loops (phases) that involve risk analysis and refinement.
 Suitable for complex and high-risk projects.
 The spiral model is a risk-driven process model. This SDLC model helps the group to
adopt elements of one or more process models like a waterfall, incremental, etc. The
spiral technique is a combination of rapid prototyping and concurrency in design and
development activities.
 Each cycle in the spiral begins with the identification of objectives for that cycle, the
different alternatives that are possible for achieving the goals, and the constraints that
exist. This is the first quadrant of the cycle (upper-left quadrant).
 The next step in the cycle is to evaluate these different alternatives based on the
objectives and constraints. The focus of evaluation in this step is based on the risk
perception for the project.
 The next step is to develop strategies that solve uncertainties and risks. This step may
involve activities such as benchmarking, simulation, and prototyping.

Advantages of Spiral Model

These are following advantages of using the spiral model:

1. Software is produced early in the software life cycle.
 2. Risk handling is one of important advantages of the Spiral model, it is best development
model to follow due to the risk analysis and risk handling at every phase.
3. Flexibility in requirements. In this model, we can easily change requirements at later
phases and can be incorporated accurately. Also, additional Functionality can be added
at a later date.
4. It is good for large and complex projects.
5. It is good for customer satisfaction. We can involve customers in the development of
products at early phase of the software development. Also, software is produced early in
the software life cycle.

Disadvantages:

1. It is not suitable for small projects as it is expensive.

2. It is much more complex than other SDLC models.
3. Too much dependable on risk analysis and requires highly specific expertise.
4. Difficulty in time management. As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
5. Spiral may go on indefinitely.

3. RAD (Rapid Application Development) Model

 Prioritizes rapid prototyping over detailed planning.

 Focuses on user feedback and fast iterations.
 Suitable for projects with tight deadlines.

RAD or Rapid Application Development process is an adoption of the waterfall model; it

targets developing software in a short period. The RAD model is based on the concept
that a better system can be developed in lesser time by using focus groups to gather
system requirements. IBM first proposed the Rapid Application Development or RAD
Model in the 1980s. The RAD model is a type of incremental process model in which
there is a concise development cycle. 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.

The critical feature of this model is the use of powerful development tools and
techniques. 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. as shown in the figure. Another
striking feature of this model is a short period i.e. the time frame for delivery(time-box) is
generally 60-90 days.
 Phases in RAD:

1. Business Modeling-Requirement Analysis or planning

2. Data Modeling-database schema
3. Process Modeling-design or flow of system
4. Application Modeling-platform, cloud services
5. Testing and Turnover-integrate all modules in the system

Advantages:

1. The use of reusable components helps to reduce the cycle time of the project.
2. Feedback from the customer is available at the initial stages.
3. Reduced costs as fewer developers are required.
4. The use of powerful development tools results in better quality products in
comparatively shorter periods.
5. The progress and development of the project can be measured through the various
stages.

Disadvantages:

1. The use of powerful and efficient tools requires highly skilled professionals.
2. The absence of reusable components can lead to the failure of the project.
 3. The team leader must work closely with the developers and customers to close the
project on time.
4. The systems which cannot be modularized suitably cannot use this model.
5. Customer involvement is required throughout the life cycle.

4. Prototype Model

 Builds an early prototype of the software to gather feedback.

 Helps refine requirements before full-scale development.
 Reduces risks and misunderstandings.
 The prototyping model starts with the requirements gathering. The developer and the user
meet and define the purpose of the software, identify the needs, etc.
 A 'quick design' is then created. This design focuses on those aspects of the software that
will be visible to the user. It then leads to the development of a prototype. The customer
then checks the prototype, and any modifications or changes that are needed are made to
the prototype.
 Looping takes place in this step, and better versions of the prototype are created. These
are continuously shown to the user so that any new changes can be updated in the
prototype. This process continue until the customer is satisfied with the system. Once a
user is satisfied, the prototype is converted to the actual system with all considerations
for quality and security.

Advantages:

1. Users are not Satisfied with the prototype, then a new prototype is created again.
2. Customer feedback is available for better system.
 3. It takes less time to make this project because once we have done the
requirement analysis from the customer, then it will take less time to develop the
project.
4. Error can be tested at earlier stage.

Disadvantages:

1. Total dependency on prototype.

2. Sometimes it takes very long time to develop the prototype based on the
user requirement.
3. The developer can try to reuse the prototype in another project even the project is
not feasible.

Each SDLC model has its strengths and is chosen based on project complexity, budget, and
flexibility needs.

Need of Fact Finding Techniques-

Fact-finding techniques are essential in software engineering because they help gather accurate and complete
information about user requirements, system constraints, and operational environments. This information is
critical for developing software that meets user expectations, functions correctly, and is delivered on time and
within budget.

Why Fact-Finding Techniques Are Needed:

1. Understanding Requirements:
o
To identify what the users need from the system.
o
To define functional and non-functional (security, flexibility, portability) requirements
accurately.
2. Reducing Ambiguity:
o
To avoid misunderstandings and misinterpretations between stakeholders and developers.
3. Ensuring Completeness and Accuracy:
o
To gather comprehensive (understandable) information and avoid missing critical requirements.
4. Improving Communication:
o
To create a common understanding between clients, developers, and project teams.
5. Validating Assumptions:
o
To confirm that the initial assumptions about the system are correct.
6. Identifying Constraints and Limitations:
o
To discover technical, financial, and operational constraints early in the development process.
7. Supporting Better Decision-Making:
o
To provide a solid foundation for design, development, and testing decisions.
8. Enhancing User Satisfaction:
o
To develop a system that meets the actual needs of users and improves user experience.

Common Fact-Finding Techniques:

1. Interviews – Direct conversations with stakeholders to gather insights.

2. Questionnaires/Surveys – Structured forms to collect data from a large audience.
 3. Observation – Watching how users interact with the current system.
4. Document Review – Analyzing existing documentation (e.g., reports, manuals).
5. Prototyping – Building a model of the system to validate requirements.
6. Brainstorming – Group discussions to generate ideas and explore solutions.
7. Joint Application Development (JAD) – Workshops involving users and developers to define
requirements collaboratively.

Conclusion:

Fact-finding techniques help ensure that the software development process starts with a clear and complete
understanding of requirements. This reduces the risk of rework, cost overruns, and user dissatisfaction, leading
to a more successful project outcome.
 Unit 2: System Analysis & Design Tools, Software Testing

Decision Tree: A Decision Tree in software engineering is a graphical tool used for decision-making and problem-
solving. It represents different possible choices and their outcomes in a tree-like structure, helping teams analyze
options, risks, and consequences.

Key Aspects of Decision Trees in Software Engineering

1. Definition & Structure

A decision tree consists of:

 Root Node: The starting point of the decision-making process.

 Decision Nodes: Represent choices or actions available.
 Chance Nodes: Represent uncertain outcomes.
 Leaf Nodes: Represent final outcomes or solutions.

2. Applications in Software Engineering

 Project Management: Helps in selecting the best development methodology (Agile, Waterfall, etc.).
 Software Testing: Aids in test case selection based on conditions.
 Risk Assessment: Evaluates potential risks and their impact.
 Requirement Analysis: Determines feature prioritization and feasibility.
 Algorithm & AI Development: Used in machine learning for classification problems.

3. Example Scenario

Suppose a software team needs to decide whether to build a mobile app as a native, hybrid, or web app. A decision tree
can help by:

 Evaluating performance, cost, and user experience factors.

 Mapping out different technical approaches and their expected outcomes.

4. Advantages of Decision Trees

Simple to understand and interpret (meaning).

Helps break down complex decisions into manageable parts.
Facilitates structured decision-making.
Can be automated using algorithms for AI and data analysis.

5. Limitations

Can become overly complex for large-scale decisions.

Prone to bias if input data is incorrect.
Doesn’t handle uncertainty well without probabilistic extensions.
Example

Imagine you’re deciding how to implement a login system:

 Root: "How should we handle user authentication?"

 Branches:
1. "Build custom solution"
2. "Use third-party service (e.g., OAuth)"
 Internal Nodes:

o
For custom: "Do we have time to secure it?" (Yes/No)
o
For third-party: "Does it integrate with our stack?" (Yes/No)
Leaves:
o
Custom + Yes = "Secure, tailored solution"
o
Custom + No = "Vulnerable system"
o
Third-party + Yes = "Fast, reliable deployment"
o
Third-party + No = "Integration headaches"

Entity Relation Diagrams (ERD):

What is an ERD?

An Entity-Relationship Diagram (ERD) is a visual representation of data and its relationships in a system. It
is widely used in database design and software engineering to model the structure of data before implementing
a database.

Key Components of an ERD

1. Entities
o
Represent real-world objects (e.g., Customer, Order, Product).
o
Depicted as rectangles in an ERD.
o
Entities can be classified as:
 Strong Entities (exist independently)
 Weak Entities (depend on another entity)
2. Attributes
o
Characteristics of an entity (e.g., Customer Name, Product Price).
o
Represented as ellipses (ovals) connected to entities.
o
Types:
 Primary Key (PK): Unique identifier for an entity (e.g., Customer ID)
 Composite Attributes: Made up of multiple attributes (e.g., Full Name → First Name
+ Last Name)
 Derived Attributes: Can be calculated (e.g., Age from Date of Birth)
 Multivalued Attributes: Can have multiple values (e.g., Phone Numbers)
3. Relationships
o
Show associations between entities (e.g., Customer places Order).
o
Represented as diamonds (rhombus) connecting entities.
o
Types of relationships:
 One-to-One (1:1) (e.g., One person has one passport)
One-to-Many (1:M) (e.g., One customer can place many orders)
Many-to-Many (M:N) (e.g., Students enroll in multiple courses, and each course has
multiple students)
4. Cardinality & Participation
o
Cardinality defines the number of instances in a relationship (e.g., 1:1, 1:M, M:N).
o
Participation determines whether all entities are required in a relationship (Total or Partial).

Benefits of ER Diagrams

 Clarifies Database Structure before implementation.

 Improves Communication between stakeholders.
 Reduces Errors in database design.
 Helps in Normalization and avoiding redundancy.

Example ER Diagram

+------------+ Places +-----------+

| Customer |------------->| Order |
+------------+ +-----------+
| |
| Has | Contains
v v
+------------+ +-----------+
| Wishlist | | Product |
+------------+ +-----------+
 Normalization:
Normalization in software engineering usually refers to the process of organizing data in a database to reduce
redundancy and improve data integrity. It’s a concept most closely tied to relational database design.
Normalization is a method to breaking down on a large, complex tables into smaller tables, related tables and
defines relationship between them.

It reduces the relationship (duplicity) of data in a table; it also remove inconsistency problem and unwanted
risk.

Advantage:

1) It maintains data integrity (PK and FK).

2) It reduces the structure of table.
3) It avoids null values.
4) Structuring of data, show that model is flexible and easy to use.

Types:
1NF
2NF
3NF
BCNF
4NF
5NF

Core Idea:

Normalization is about structuring a database in a way that each piece of information is stored once, in the right
place, and in a way that makes it easy to update and maintain.

Why Normalize?

 Eliminate duplicate data

 Ensure data dependencies make sense
 Make the database easier to maintain and scale

The Normal Forms:

There are several “normal forms” (NF), each with a set of rules. The most commonly used ones are:

1. First Normal Form (1NF):

o
Eliminate repeating groups in individual tables.
o
Create separate tables for each group of related data.
o
Identify each row with a primary key.
 Data must be stored in a table with rows and column and column should contain individual values.

Project Table:

Sroll Sname Course Teacher

1 Ankit C,C++ Mr.A, Mr.B
2 Hemant Java, C Mr.C,Mr.A
3 Neha C++, Java Mr.B, Mr.C

After 1NF:

Sroll Sname Course Teacher

1 Ankit C Mr.A
1 Ankit C++ Mr.B
2 Hemant Java Mr.C
2 Hemant C Mr.A
3 Neha C++ Mr.B
3 Neha Java Mr.C

2. Second Normal Form (2NF):

o
Meet all requirements of 1NF.
o
Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
o
Create relationships between these new tables and their predecessors using foreign keys.
o
All non key attributes should be fully dependent on the primary key.(No Partial dependencies)

Project Table:

Sroll Sname Course Teacher

1 Ankit C,C++ Mr.A, Mr.B
2 Hemant Java, C Mr.C,Mr.A
3 Neha C++, Java Mr.B, Mr.C

After 1NF:

Sroll Sname Course Teacher

1 Ankit C Mr.A
1 Ankit C++ Mr.B
2 Hemant Java Mr.C
2 Hemant C Mr.A
3 Neha C++ Mr.B
3 Neha Java Mr.C

After 2NF: Table

1:Student

Sroll Sname
1 Ankit
2 Hemant
3 Neha
 Table 2: Enrollement

Sroll Course Teacher

1 C Mr.A
1 C++ Mr.B
2 Java Mr.C
2 C Mr.A
3 C++ Mr.B
3 Java Mr.C

3. Third Normal Form (3NF):

o
Meet all requirements of 2NF.
o
Remove columns that are not dependent upon the primary key.
o
Non key attributes should not depend on other non-key attributes.

Table 1:Student (Same as 2NF)

Sroll(PK) Sname
1 Ankit
2 Hemant
3 Neha

Table 2: Courses

Course(FK) Teacher (Non key)

C Mr.A
C++ Mr.B
Java Mr.C

Table 3: Enrollment

Sroll(PK) Course(FK)
1 C
1 C++
2 Java
2 C
3 C++
3 Java
Data Flow Diagram (DFD):
A Data Flow Diagram (DFD) is a visual representation used in software engineering to show how data moves
through a system. It illustrates the flow of data between processes, data stores, external entities, and data
inputs/outputs, helping in analyzing and designing information systems. It is also known as “Bubble Chart”
through which we can represent the flow of data graphically in an information system.

By using DFD we can easily understand the overall functionality of system because diagram represents the
incoming dataflow, outgoing data flow and stored data in a graphical form.

It describes how data is processed in a system in term of input and output. A DFD Model uses a no. of notations
or symbol to represent flow of data.

Key Components of a DFD:

1. Processes (Circles or rounded rectangles):

Represent functions or activities that transform data.
Example: Process Order, Validate Login
2. Data Stores (Open-ended rectangles or two parallel lines):
Show where data is stored for use later.
Example: Customer Database, Transaction Records
3. External Entities (Squares or rectangles):
Sources or destinations of data outside the system.
Example: Customer, Bank, Supplier
4. Data Flows (Arrows):
Indicate how data moves between the entities, processes, and data stores.
Example: Order Details, Login Info

1. External Entity

Input Output

2. Data flow

3. Process or Bubble

4. Data Store

Or
Rules for DFD-

1. Each Process should have at least one input and one Output.

Input Output

Process

2. Each data store should have at least one data flow in and one data flow out.

Output
Input

Data Store

3. All process in a DFD go to either another process or data store.

Process2
Data

Data
or

Process1
Data Store

4. All the External Entities must be connected through a process and entity can provide something
to the software as well as the entity can consume some data from the software.
Input Software

Entity

Output
 Level of DFD:

1. Logical-The flow of Logical Data components between logical DFD.

2. Physical- Flow of logical data components between physical operations in systems.

Levels of DFD:

1. Level 0 (Context Diagram)

o
It is a diagram which provides the entire systems Data flows and processing with a single process
(bubble) is called as context. Sometimes it is called as Context Level DFD.
o
The highest abstraction level.
o
It shows the system as a single process and its interaction with external entities.

Output
External Entity

External Entity

2. Level 1
o
Breaks the main process into sub-processes.
o
Shows data flow between sub-processes and external entities.
o
This is a more detailed version of the Previous level that includes all the database and various
important units.

External Entity
Process1
Output

Process2

Data Store

3. Level 2 (and beyond)

o
Further breakdown of Level 1 processes into more detailed sub-processes.

External Entity Process1.2 External Entity

Process1.1
 Benefits of Using DFD:

 Clarifies how data is handled within a system

 Helps stakeholders understand system functions
 Assists in identifying inefficiencies or missing components
 Useful for both analysis and design phases

Context Level DFD for a Railway Reservation System

External Entities:

1. Passenger – A user who books, cancels, or inquires about tickets.

2. Admin – Manages train schedules, fares, and system maintenance.
3. Bank System / Payment Gateway – Handles payment processing.

Single Process:

 Railway Reservation System – The main system managing reservations, cancellations, train details,
and payments.

Data Flows:

 From Passenger:
o
Reservation Request
o
Cancellation Request
o
Inquiry Request
o
Payment Details
 To Passenger:
o
Ticket Details
o
Booking Confirmation
o
Cancellation Confirmation
o
Train Information
 From Admin:
o
Train Schedule Updates
o
Fare Updates
 To Admin:
o
Reports
o
System Logs
 To/From Bank System:
o
Payment Request
o
Payment Confirmation / Failure
Processes in Level 1 DFD

1. 1.0 Handle Reservation

2. 2.0 Handle Cancellation
3. 3.0 Provide Train Information
4. 4.0 Manage Payments
5. 5.0 Admin Management

Data Stores

 D1: Reservation Database

 D2: Train Schedule Database
 D3: Payment Records
 D4: User Database

External Entities

 Passenger
 Admin
 Bank System / Payment Gateway

Data Flows (Examples)

 Passenger → Reservation Details → Handle Reservation

 Handle Reservation → Reservation Database → Store Ticket
 Passenger → Cancellation Request → Handle Cancellation
 Handle Cancellation → Reservation Database → Cancel Ticket
 Admin → Update Train Info → Admin Management → Train Schedule Database
 Handle Payment ↔ Bank System ↔ Payment Confirmation
Processes in Level 2 DFD

Sub-Processes of 1.0 Handle Reservation

1. 1.1 Collect Passenger Details

2. 1.2 Check Train Availability
3. 1.3 Reserve Seat
4. 1.4 Generate Ticket
5. 1.5 Send Confirmation

Data Stores Involved

 D1: Reservation Database

 D2: Train Schedule Database
 D4: User Database

External Entity

 Passenger

Data Flows

 Passenger → Passenger Details → 1.1

 1.1 → Store/Update → User Database
 1.2 → Read → Train Schedule Database
 1.2 → Availability → 1.3
 1.3 → Reservation Info → Reservation Database
 1.4 → Booking ID + Details → Ticket
 1.5 → Send Ticket → Passenger
 Data Dictionary:
In software engineering, a data dictionary is a centralized repository (Collection) of information about data, such
as meaning, relationships to other data, origin, usage, and format. It plays a crucial role in database design,
system analysis, and development.

What is a Data Dictionary?

A data dictionary defines and describes:

 The structure of database tables

 Fields/columns in those tables
 Data types and constraints
 Relationships between data
 Allowed values (domains)
 Default values
 Business rules
 Key Components of a Data Dictionary

Element Description
Field Name The name of the data element or column
Data Type Type of data stored (e.g., INTEGER, VARCHAR, DATE)
Size Length or size of the data (e.g., 255 characters)
Constraints Rules applied to the field (e.g., NOT NULL, UNIQUE)
Default Value Predefined value if none is provided
Allowed Values Domain or range of acceptable values
Description Human-readable explanation of the field

Why Use a Data Dictionary?

 Improves data consistency and accuracy

 Enhances communication among stakeholders
 Assists in database design
 Provides documentation for developers and analysts
 Helps in impact analysis when changes are proposed

Example Entry

Field Name Data Type Size Description Constraints

customer_id INTEGER — Unique ID for customer PRIMARY KEY, NOT NULL
first_name VARCHAR 50 Customer's first name NOT NULL
email VARCHAR 100Customer's email UNIQUE
date_joined DATE — Date of registration DEFAULT = CURRENT_DATE

Key Features of a Data Dictionary

1. Centralized Repository
o
Acts as a single source of truth for data definitions across the system.
2. Standardized Data Definitions
 o
Ensures uniform naming conventions, data types, and formats are used consistently.
3. Metadata Storage
o
Stores information about the data (e.g., type, length, constraints), not the data itself.
4. Data Integrity Support
o
Helps maintain data accuracy and consistency through rules and constraints.
5. Improved Communication
o
Facilitates better understanding between developers, analysts, designers, and stakeholders.

Process Specification Methods

In software engineering, Process Specification Methods are used to define the detailed behavior of processes (or
operations) in a system, especially within structured or formal software development methodologies. These
methods specify what a system or component must do, not how it does it, and they are typically used to describe
functional requirements. Process specification in software engineering involves defining the requirements and
functionality of a software system, acting as a blueprint for design and implementation. It encompasses various
methods like decision tables, structured English, use cases, flowcharts, and more, ensuring clear communication
and verification. The goal is to provide a precise and verifiable description of what the system should do, aiding
designers, developers, and stakeholders throughout the development lifecycle.

Here’s a breakdown of the main types of process specification methods:

1. Structured English

 Description: Uses a limited form of English that follows specific rules and syntax, combining
natural language with programming-like constructs (like IF, THEN, WHILE).
 Example:

IF order_amount > 100

THEN apply 10% discount
ELSE
no discount

2. Decision Tables

 Description: A tabular method for representing complex logic involving multiple conditions and
actions. Each row represents a rule.
 Structure:
o
Conditions: Inputs or tests
o
Actions: Outputs or decisions
o
Rules: Columns that link conditions to actions

3. Decision Trees
  Description: A tree-like structure showing decisions and their possible consequences, including chance
outcomes.
 Features: Easier to understand than tables in some scenarios.

4. Flowcharts

 Description: Diagrams that represent the flow of control in a process using standard symbols.
 Symbols include:
o
Rounded Rectangle: Start/End
o
Parallelogram: Process
o
Diamond: Decision
o
Arrows: Flow direction

5. Pseudocode

 Description: Informal, high-level description of a process using a mixture of natural language and
programming logic.
 Example:

for each item in cart:

if item is on sale:
apply discount
else:
regular price

What is Software Testing?

Software Testing is the process of evaluating and verifying that a software application or system meets the
specified requirements and works as expected. The goal is to find bugs, ensure quality, and improve
performance before releasing software to users.

Types of Software Testing

1. Manual Testing
Testers manually execute test cases without using tools.

2. Automated Testing
Tests are run automatically using tools/scripts (like Selenium, JUnit, TestNG).

Categories of Testing

A. Functional Testing

 Unit Testing: Tests individual units/components.

 Integration Testing: Tests how components work together.
 System Testing: Tests the complete system.
  Acceptance Testing: Verifies system meets business requirements (e.g., UAT).

B. Non-Functional Testing

 Performance Testing: Speed, responsiveness.

 Security Testing: Ensures data protection.
 Usability Testing: User experience.
 Compatibility Testing: Works across devices/browsers.

💻 Implementation Phase

What it is:

The Implementation phase is where the actual coding or programming happens. After the design is complete,
developers start building the system according to specifications.

Key Activities:

1. Code Development: Translating design into source code using programming languages.
2. Integration: Combining modules and ensuring they work together.
3. Unit Testing: Testing individual components for correct functionality.

Output:

A working software system that’s ready for system testing and deployment.

Maintenance Phase

What it is:

Once the software is deployed and in use, it enters the Maintenance phase. This is often the longest phase in the
SDLC.

Types of Maintenance:

1. Corrective Maintenance: Fixing bugs and errors found after release.

2. Adaptive Maintenance: Updating software to work with changes in the environment (OS updates,
hardware, etc.).
3. Perfective Maintenance: Enhancing features or performance based on user feedback.
4. Preventive Maintenance: Improving future maintainability (e.g., code refactoring, documentation).

Tools Often Used:

 Bug Tracking: Jira, Bugzilla

 Monitoring: New Relic, Nagios
 CI/CD Tools: Jenkins, GitHub Actions

Key Goals:
  Keep the system running smoothly.
 Adapt to new requirements.
 Minimize downtime and user disruption.

Quick Example:

Let’s say you build a mobile app.

 During Implementation, you write the code, integrate features, and test the app.
 During Maintenance, you fix bugs users report, add new features, and ensure it works on the latest
iOS/Android versions.

Need of Testing
The need for testing in software engineering is critical for ensuring that a software product is reliable,
functional, and meets user expectations. Here's a breakdown of why testing is necessary:

1. To Identify and Fix Bugs Early

 Testing helps catch bugs and defects before the software goes live.
 Early detection reduces the cost and effort needed to fix issues.

2. To Ensure Software Quality

 Verifies that the software meets the specified requirements.

 Helps maintain performance, usability, security, and reliability standards.

3. To Meet Business Requirements

 Confirms that the software performs the functions that stakeholders expect.
 Helps avoid costly business failures due to unmet requirements.

4. To Ensure Security

 Identifies vulnerabilities that could be exploited by attackers.

 Security testing is essential in today's cyber-threat-heavy environment.

5. To Improve User Experience

 Functional and usability testing ensures that users can interact with the software easily and effectively.
 A good user experience leads to higher user satisfaction and retention.

6. To Reduce Maintenance Costs

 Well-tested software is less likely to break in production.

 Reduces the amount of emergency fixes and support needed after deployment.

7. To Support Continuous Improvement

  Enables iterative development and delivery (especially in Agile/DevOps models).
 Continuous testing allows for faster releases with fewer risks.

8. To Verify Integration and Compatibility

 Ensures that different modules work well together (integration testing).

 Checks the software across different devices, platforms, or browsers (compatibility testing).

White Box Testing and Black Box Testing

Feature White Box Testing Black Box Testing
Testing internal structure, logic, and code of Testing the functionality without looking at
Definition
software internal code
Also Known As Clear Box / Structural / Glass Box Testing Behavioral / Functional Testing
Tester
Requires knowledge of the code Does not require code knowledge
Knowledge
Focus Code structure, logic, paths, and conditions Inputs and outputs, user behavior
Who Performs It Developers or technically skilled testers QA testers or end users
Unit testing, code coverage, path testing, Functional testing, system testing, acceptance
Testing Methods
etc. testing
- Optimizes code - Tests the software from user’s perspective
Advantages
- Finds hidden logical errors - No need to know code
- Time-consuming - Limited by test case coverage
Disadvantages
- Requires skilled testers - Cannot detect hidden code issues

Changeover, Pilot and Parallel

In software engineering, changeover, pilot, and parallel refer to different deployment or system transition
strategies used when implementing a new system to replace an old one. These approaches help manage risk
during software rollouts. Here's a breakdown:

1. Changeover

"Changeover" refers broadly to the transition process from an old system to a new one. The goal is to move
from the existing setup to a new software solution with minimal disruption. There are several types of
changeover strategies — the next two terms (pilot and parallel) are examples.

2. Pilot Changeover

 A pilot changeover is when the new system is introduced to a small group of users or a specific
department first.
  Purpose: To test the new system in a real environment without exposing the entire organization to
potential risks.
 If successful, the system is then rolled out to the rest of the organization.
 Pros: Low risk, manageable feedback, early problem detection.
 Cons: May delay full implementation, requires support for both systems during the pilot.

Example: A university introduces a new grading portal to just the engineering department before expanding to all
faculties.

3. Parallel Changeover

 In a parallel changeover, both the old and new systems run at the same time for a certain period.
 Users input the same data into both systems and compare outputs to ensure consistency.
 Pros: Very safe — if the new system fails, the old one is still functional.
 Cons: Expensive, labor-intensive, and may confuse users.

Example: A bank runs its old transaction system alongside the new one for a month to confirm the new system handles
all operations correctly.