0% found this document useful (0 votes)
22 views

Software Engineering Theory (4th Sem) .

Files

Uploaded by

aadarshgupta388
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views

Software Engineering Theory (4th Sem) .

Files

Uploaded by

aadarshgupta388
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

;1

THEORY FILE : SOFTWARE ENGINEERING (FULL NOTES: BY


SAHIL ) .
SUBJECT CODE: UGCA: 1921

BACHELOR OF COMPUTER APPLICATIONS

MAINTAINED BY: TEACHER’S / MAM’S :

IL
Sahil Kumar Dr.

COLLEGE ROLL NO: 226617

UNIVERSITY ROLL NO: 2200315


H
SA

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

BABA BANDA SINGH BAHADUR ENGINEERING

COLLEGE FATEGARH SAHIB


;2



Program BCA


Semester 4th.
Course Name Software Engineering (Theory).

UNIT ➖01
● The Nature of Software ➖
Software is a set of instructions, data, or programs that run on a device to execute specific tasks and
operate computers. It is the opposite of hardware, which describes the physical aspects of a computer.
Here are some characteristics of software:

IL
❖ Functionality: The degree of performance of the software and the set of features and capabilities
that a software program or system provides to its users.

❖ Reliability: A set of attributes that bear on the capability of software.

❖ Efficiency: The ability of the software to use the system.


H
❖ Usability: The extent to which the software can be used with.

❖ Dynamic and Evolving: Software is dynamic and can be easily modified, updated, or extended.
This dynamic nature allows developers to adapt to changing requirements, fix bugs, and enhance
features over time. Continuous improvement is a fundamental characteristic of software.
SA
❖ Algorithmic Logic: At its core, software is based on algorithms and logical instructions that dictate
how a program should behave. Algorithms are step-by-step procedures or formulas for solving
problems, and they form the foundation of software functionality.

❖ Development Process: Software development involves a systematic process that includes stages
such as requirement analysis, design, coding, testing, deployment, and maintenance. Various
methodologies, such as Agile and Waterfall, guide the development process.

❖ Cybersecurity Concerns: The interconnected nature of software also raises cybersecurity concerns.
The potential for vulnerabilities and the need for robust security measures are critical aspects of
software development and usage.

❖ Economic and Social Impact: Software has a profound impact on the economy and society. It
drives innovation, improves efficiency in various sectors, and facilitates communication and
collaboration. The software industry has become a significant driver of economic growth.

Software is also malleable, meaning it is easy to change. Software is often complex, and large pieces of
software are likely to have more errors than small pieces.
;3
Software is intangible because it cannot be directly sensed by the human senses. Work products such as
requirements specifications, design documents, source code, and object code are representations of
software, but they are not the software.
Software is mainly classified into seven categories:
1. System software
2. Application software
3. Engineering/scientific software
4. Embedded software
5. Product line software
6. Web applications
7. Artificial intelligence software.

IL
● Need of Software Engineering
Software engineering is a discipline that focuses on the systematic design, development, testing,
maintenance, and management of software systems. The need for software engineering arises from various
challenges and complexities associated with the development of software. Here are some key reasons why
software engineering is essential:

❖ Complexity of Software Systems: As software systems have grown in size and complexity,
managing the development process without a systematic approach becomes increasingly
H
challenging. Software engineering provides methodologies and best practices to handle the
intricacies of large-scale software projects.

❖ Quality Assurance: Software engineering emphasizes quality throughout the entire development
lifecycle. Proper software engineering practices, including testing and debugging, help ensure that
software meets specified requirements and functions reliably.
SA
❖ Cost-Effectiveness: Adopting software engineering principles can lead to cost-effective solutions.
By following best practices and using efficient development processes, organisations can reduce the
likelihood of errors, enhance productivity, and ultimately save costs.

❖ Efficient Development Process: Software engineering methodologies, such as Agile or Scrum,


provide structured frameworks for managing the software development process. These
methodologies promote iterative development, collaboration, and adaptability, resulting in a more
efficient development cycle.

❖ Project Management and Planning: Software engineering involves effective project management
and planning. It helps in estimating project timelines, allocating resources, and managing risks. This
ensures that projects are completed on time and within budget.

❖ Maintainability and Scalability: Well-engineered software is designed with maintainability and


scalability in mind. This means that it can be easily updated, expanded, and adapted to meet
changing requirements without causing disruptions to the existing system.
;4
❖ Risk Management: Software engineering incorporates risk management strategies to identify and
address potential issues early in the development process. This proactive approach helps minimize
the impact of unforeseen challenges on project timelines and outcomes.

❖ User Satisfaction: Software engineering practices prioritise user experience and satisfaction. By
incorporating user feedback and focusing on usability, software engineers ensure that the end
product meets the needs and expectations of its intended users.

❖ Compliance and Standards: Many industries and applications have specific regulations and
standards that must be adhered to. Software engineering helps in ensuring compliance with these
standards, such as safety standards in critical systems or privacy regulations in data-driven
applications.

IL
❖ Global Collaboration: In today's interconnected world, software development often involves global
collaboration. Software engineering practices provide a common framework and language for teams
to collaborate effectively, even when geographically dispersed.

❖ Continuous Improvement: Software engineering encourages a culture of continuous improvement.


Teams learn from past projects, adopt new technologies and methodologies, and strive to enhance
their processes over time.
H
● Prescriptive Process Models ➖
Prescriptive process models in software engineering provide a structured framework with a set of defined
activities, tasks, and milestones that teams should follow to develop software. These models prescribe a
specific sequence of steps to be taken during the software development lifecycle. Unlike descriptive
models that describe how software development is often done, prescriptive models dictate how it should be
SA
done for optimal results. Here are some common prescriptive process models:

1. Waterfall Model: ➖
A. Description: The Waterfall Model follows a linear sequential flow, where progress is seen as
flowing steadily downwards through phases such as requirements, design, implementation, testing,
deployment, and maintenance.
B. Advantages: Simple and easy to understand, well-suited for small projects with clear and stable
requirements.
C. Disadvantages: Lack of flexibility, difficulties in accommodating changes after the project has
started.

2. V-Model (Verification and Validation Model): ➖


A. Description: The V-Model is an extension of the waterfall model, associating testing with each
development stage. It emphasises the relationship between each development stage and its
associated testing phase.
B. Advantages: Clear mapping between development phases and testing phases, early detection of
defects.
C. Disadvantages: Limited flexibility, challenges in accommodating changes.

;5
3. Incremental Model:
A. Description: The Incremental Model divides the project into smaller parts or increments, and each
increment delivers a portion of the functionality. New increments are added to the existing system
until it is complete.
B. Advantages: Flexibility to accommodate changes, partial implementation of the system is available
early in the development process.
C. Disadvantages: Requires good planning and design, potential integration issues.

4. Spiral Model: ➖
A. Description: The Spiral Model combines elements of the waterfall model and prototyping. It
involves iterative development with cycles or spirals, each representing a phase in the software
development process.

IL
B. Advantages: Incorporates risk analysis, accommodates changes, and allows for the incremental
release of the product.
C. Disadvantages: Complex and can be difficult to manage, requires expertise in risk assessment.

5. Iterative Model: ➖
A. Description: The Iterative Model involves repeating cycles of the development process, refining the
system with each iteration. Each iteration results in a more complete and improved version of the
software.
H
B. Advantages: Allows for flexibility and improvements over time, accommodates changes easily.
C. Disadvantages: Requires a well-defined and stable architecture, may face challenges with
large-scale projects.

6. Agile Model: ➖
A. Description: Agile is an iterative and incremental approach that focuses on collaboration, customer
SA
feedback, and the ability to respond to changes quickly. It involves short development cycles known
as sprints.
B. Advantages: Highly flexible and adaptive, encourages customer involvement throughout the
development process.
C. Disadvantages: Requires a high level of collaboration and communication, may be challenging for
large and complex projects.

● Specialised Process Models ➖


Specialised process models in software engineering are tailored approaches to software development that
address specific challenges or requirements. These models deviate from generic and widely-used
methodologies to provide a more focused and specialized solution. Here are some examples of specialized
process models:

1. Extreme Programming (XP): ➖


Description: Extreme Programming is an agile software development methodology that emphasizes
flexibility, collaboration, and customer satisfaction. It involves continuous feedback, frequent releases, and
close customer involvement throughout the development process. XP practices include pair programming,
test-driven development, and continuous integration.

;6
2. Scrum:
Description: Scrum is an agile framework that focuses on iterative development and product increments.
It divides the development process into short time frames called sprints, typically lasting two to four
weeks. Scrum includes roles such as Scrum Master, Product Owner, and Development Team, and uses


ceremonies like Sprint Planning and Daily Standups to facilitate collaboration and communication.
3. Feature-Driven Development (FDD):
Description: Feature-Driven Development is an iterative and incremental software development
methodology that is particularly effective for larger projects. It focuses on building features incrementally,
and the development process is guided by domain object modeling. FDD places a strong emphasis on
regular inspection and adaptation through progress reporting and feature completion milestones.

4. Rapid Application Development (RAD): ➖

IL
Description: Rapid Application Development is a model that prioritises quick development and iteration.
RAD involves user feedback, prototyping, and iterative development cycles. It aims to reduce the time it
takes to develop a product and involves close collaboration between developers and end-users.

5. DevOps: ➖
Description: DevOps is not a traditional software development model, but rather a set of practices that
aim to integrate development and operations teams. DevOps focuses on automation, collaboration, and
communication between development and operations to improve efficiency, speed up delivery, and

6. Big Bang Model:


H
enhance product quality.


Description: The Big Bang Model is an unconventional approach where there is minimal planning and
documentation upfront. Development begins without a specific process, and features are added and
modified as the project progresses. This model is suitable for small projects or proof-of-concept efforts.
SA
7. Incremental Build Model: ➖
Description: The Incremental Build Model is similar to the incremental model but focuses on delivering
fully functional subsystems in increments. Each increment builds upon the previous one, and the final
product is achieved through the integration of these incremental subsystems.

8. Synchronise-and-Stabilise Model: ➖
Description: This model is often used in large-scale and distributed software development projects.
Development teams work independently on separate components, synchronise their work at intervals, and
then stabilise the system to ensure compatibility and integration.

These specialised process models cater to specific project requirements, team structures, and development
goals. The choice of a specialized model depends on factors such as project size, complexity, time
constraints, and the organisation's specific needs and preferences. Teams may also adopt a hybrid
approach, combining elements from different models to create a customised process that suits their unique
circumstances.

;7
● The Unified Process
The Unified Process (UP) is a software development framework that uses object-oriented modelling. It's
also known as the Rational Unified Process (RUP) and the Open Unified Process (Open UP).

IL
H
The Unified Process is an iterative and incremental development process. It's based on the refinement and
enlargement of a system through multiple iterations, with cyclic feedback and adaptation. The system is
developed incrementally over time, iteration by iteration.

The Unified Process model consists of four phases: Inception, Elaboration, Construction, Transition.
SA
Each of these phases consists of several iterations. The elaboration, construction, and transition phases are
divided into a series of timeboxed iterations.

The Unified Process recognizes the importance of customer communication and streamlined methods for
describing the customer's view of a system. It emphasises the important role of software architecture and
helps the architect focus on the right goals.
;8

UNIT ➖ 02
● Role of a system analyst ➖
A System Analyst plays a crucial role in the field of software engineering, acting as a liaison between
business stakeholders and the development team. The primary responsibility of a System Analyst is to
analyse, design, and specify information systems to meet the needs of an organisation. Here are the key
roles and responsibilities of a System Analyst in software engineering:

1. Requirement Analysis: ➖
Collaborate with business stakeholders to gather and understand their requirements for a software system.
Analyse and document business processes, workflows, and user needs.

IL
Elicit, clarify, and prioritise functional and non-functional requirements.

2. Feasibility Studies: ➖
Conduct feasibility studies to assess the viability of proposed projects.
Evaluate technical, operational, and economic aspects to determine if the project aligns with organisational
goals and constraints.

3. System Design: ➖
H
Translate business requirements into detailed system specifications.
Develop system design documents, including data models, process flows, and system architecture.
Collaborate with software architects and designers to ensure the proposed solution aligns with technical
standards and best practices.

4. Prototyping: ➖
Create prototypes or mock-ups to provide stakeholders with a visual representation of the proposed system.
SA
Gather feedback from users and incorporate changes into the design.

5. Communication Bridge: ➖
Act as a communication bridge between business stakeholders and the development team.
Ensure that requirements are clearly understood by both parties and that the final system meets user
expectations.

6. Requirements Management: ➖
Manage and maintain requirements throughout the software development lifecycle.
Handle changes to requirements and assess their impact on the project.
Ensure traceability between requirements and design elements.

7. Collaboration with Development Team: ➖


Work closely with software developers, testers, and other members of the development team.
Provide clarifications on requirements, assist in problem-solving, and facilitate communication within the
team.

;9
8. Quality Assurance:
Participate in quality assurance activities by reviewing deliverables, conducting inspections, and ensuring
compliance with specifications.
Verify that the developed software meets the defined requirements and standards.

9. User Training and Support: ➖


Develop training materials and conduct training sessions for end-users.
Provide support during the implementation and deployment of the software.

10. Risk Management: ➖


Identify potential risks and challenges associated with the project.
Work on risk mitigation strategies and contingency plans.

IL
11. Documentation: ➖
Maintain accurate and up-to-date documentation throughout the project lifecycle.
Document decisions, changes, and rationales for future reference.

12. Continuous Improvement: ➖


Contribute to the continuous improvement of processes and methodologies used in software development.
Learn and incorporate industry best practices into the analysis and design processes.
H
SA

The role of a System Analyst is dynamic and requires a combination of technical expertise, communication
skills, and a deep understanding of business processes. By effectively gathering and translating
requirements, collaborating with stakeholders, and ensuring the alignment of the proposed solution with
business objectives, a System Analyst plays a key role in the success of software development projects.

● SRS ➖
SRS, or Software Requirements Specification, is a crucial document in software engineering that serves as
a foundation for the entire software development process. It outlines the detailed requirements for a
software system, providing a clear and unambiguous description of what the system is expected to do. The
;10
Software Requirements Specification document is typically created during the early stages of the software
development life cycle, and it serves as a reference for all stakeholders involved in the project. Here are the
key components and purposes of an SRS:

Components of an SRS:

1. Introduction: ➖
Provides an overview of the document, including the purpose, scope, and objectives of the software
project.
Identifies the stakeholders involved in the project.

2. Overall Description: ➖

IL
Presents a high-level description of the software system.
Defines the context of the system, including external interfaces, user characteristics, and constraints.
Describes the intended features and functions of the system.

3. Specific Requirements: ➖
Offers a detailed breakdown of functional and non-functional requirements.
Describes the system's features and capabilities, often using use cases, scenarios, and user stories.
Specifies input and output requirements, as well as data processing and storage.
H
4. External Interface Requirements: ➖
Defines the system's interactions with external entities, such as users, hardware, software, and other
systems.
Describes input/output formats, data transfer methods, and communication protocols.


SA
5. Performance Requirements:
Outlines the performance criteria that the system must meet, including response times, throughput, and
capacity.
Specifies any constraints related to performance.

6. System Design Constraints: ➖


Identifies constraints that may affect the design and implementation of the system.
Includes limitations related to hardware, software, regulations, and other factors.

7. Software System Attributes: ➖


Describes the quality attributes of the software, such as reliability, maintainability, usability, and security.
Specifies any design and implementation constraints that impact these attributes.

8. Other Non-functional Requirements: ➖


Captures non-functional aspects of the system, such as usability, reliability, and security.
Specifies requirements related to system documentation, training, and support.

;11
9. Appendix:
May include additional information, such as glossary, references, or supplementary details that support the
understanding of the document.

Purposes of an SRS:

1. Communication: ➖
Provides a common understanding of the system's requirements among all stakeholders, including
developers, testers, project managers, and clients.

2. Basis for Agreement: ➖


Serves as a contract between the development team and the client or stakeholders, ensuring that everyone

IL
agrees on what the system is expected to deliver.

3. Guidance for Development: ➖


Guides the development team in building the software by providing a comprehensive reference for the
system's features, functionalities, and constraints.

4. Basis for Testing: ➖


Forms the basis for the creation of test cases and testing procedures to ensure that the software meets the
specified requirements.
H
5. Project Management: ➖
Aids project managers in planning and tracking progress by defining the scope and objectives of the
project


.
SA
6. Documentation:
Serves as a foundational document for creating other project-related documentation, such as design
documents, test plans, and user manuals.

Creating a well-structured and detailed SRS is essential for the success of a software development project.
It helps prevent misunderstandings, reduces the risk of scope creep, and provides a roadmap for the entire
development team.

● Properties of a good SRS document ➖


A Software Requirements Specification (SRS) document is a critical deliverable in software engineering,
and its quality greatly influences the success of a software development project. A good SRS document


should possess several key properties to ensure clarity, completeness, and effectiveness.
Here are some essential properties of a good SRS document:

1. Clear and Concise Language: ➖


Use clear and unambiguous language to avoid misunderstandings. Avoid jargon or technical terms that may
be unclear to stakeholders who do not have a technical background.

;12
2. Correctness:
Ensure that the information in the document is accurate, reflecting the actual requirements of the system.
All requirements should be factually correct and aligned with the project's goals.

3. Completeness: ➖
The SRS should provide a comprehensive and exhaustive description of all functional and non-functional
requirements. It should leave no ambiguity or gaps in terms of what the system is expected to achieve.

4. Consistency: ➖
Ensure consistency throughout the document. There should be no conflicting or contradictory information.
All requirements should align with each other and with the project's objectives.

IL
5. Traceability:
Establish traceability links between different levels of requirements, such as high-level system
requirements to detailed software requirements and design elements. This makes it easier to track the
impact of changes and ensures that each requirement is addressed in the implementation.

6. Verifiable: ➖
Specify criteria for verifying and validating each requirement. This makes it possible to conduct tests and
assessments to ensure that the system meets the specified requirements.

7. Prioritisation:
H

Clearly indicate the priority of each requirement, distinguishing between "must-have" and "nice-to-have"
features. This helps in case trade-offs need to be made during the development process.

8. Testability: ➖
SA
Ensure that each requirement is testable. This means that there should be a way to objectively determine
whether the system satisfies each requirement through testing and verification.

9. Modularity: ➖
Organise the document in a modular fashion, dividing it into sections that address different aspects of the
system. This helps in easy navigation and comprehension.

● functional and non-functional requirements ➖


Functional and non-functional requirements are two fundamental types of requirements in software
engineering that define what a software system must do and how it must perform. These requirements play
a crucial role in shaping the design, development, and testing of software. Let's explore each type:

1. Functional Requirements: ➖
Functional requirements describe the specific features, capabilities, and functionalities that a software
system must provide. They define the behaviour of the system and the interactions with its users.
Functional requirements are typically expressed as statements of what the system is expected to do.
Examples include:

;13
a. User Authentication:
"The system must allow users to log in with a valid username and password."

b. Data Entry: ➖
"The system must provide a form for users to enter their personal information, including name, address,
and contact details."

c. Search Functionality: ➖
"The system must allow users to search for products by name, category, or other relevant criteria."

d. Transaction Processing: ➖
"The system must support online payment processing for customer orders."

IL
e. Reporting: ➖
"The system must generate monthly sales reports for the management team."

f. Notifications: ➖
"The system must send email notifications to users when a new message is received."
Functional requirements are directly related to the system's features and capabilities, and they can be
validated through testing to ensure that the system functions as intended.
H
2. Non-Functional Requirements: ➖
Non-functional requirements define the characteristics and qualities that describe how the system should
perform, rather than what it should do. They are often constraints or quality attributes that specify criteria
related to performance, reliability, security, usability, and other aspects. Examples include:


SA
g. Performance:
"The system must respond to user queries within 2 seconds under normal operating conditions."

h. Reliability: ➖
"The system must have an uptime of at least 99.9%."

i. Scalability: ➖
"The system must support a minimum of 10,000 concurrent users without degradation of performance."

j. Security: ➖
"The system must encrypt sensitive user data during transmission over the network."

k. Usability: ➖
"The system must provide a user-friendly interface with intuitive navigation."

l. Availability: ➖
"The system must be available 24/7, except during scheduled maintenance windows."

;14
m. Maintainability:
"The system must be easily maintainable, with updates and patches applied without significant downtime."
Non-functional requirements are critical for ensuring the overall success and quality of the system. While
functional requirements address the "what" of the system, non-functional requirements focus on the "how"
and the overall user experience.

Both types of requirements are essential for creating a comprehensive and well-defined specification for a
software project. It's crucial for development teams to carefully gather, document, and prioritise both
functional and non-functional requirements to guide the design and development processes effectively.

● Decision tree and Decision table ➖


Decision trees and decision tables are modelling techniques in software engineering used for representing

IL
complex business logic and decision-making processes. These tools help in visualising and organising the
various conditions and actions associated with decision points within a system. Let's explore each of them:

1. Decision Tree: ➖
A decision tree is a hierarchical structure that represents a series of decisions and their possible
consequences. It is particularly useful for modeling conditions and actions in a sequential manner. The tree
structure consists of nodes, where each node represents a decision or a test condition. The branches
emanating from each node represent possible outcomes or actions based on the decision or condition.
H
Components of a Decision Tree:

A. Root Node: ➖
Represents the initial decision or condition that needs to be evaluated.


SA
B. Decision Nodes:
Represent intermediate decisions or conditions in the process.

C. Leaf Nodes: ➖
Represent the final outcomes or actions based on the decisions and conditions.

D. Branches: ➖

Connect nodes and represent the possible paths or outcomes.
E. Example:
Consider a decision tree for determining if a person is eligible for a discount:
Age >= 18?
/ \
Yes / \ No
/ \
Discount No Discount
In this example, the root node checks if the person's age is greater than or equal to 18. Based on the
outcome, the decision tree branches into two paths, leading to either a "Discount" or "No Discount."

;15
2. Decision Table:
A decision table is a tabular representation of decision logic, capturing different combinations of
conditions and corresponding actions or outcomes. It is particularly useful when there are multiple
conditions with various possible combinations that lead to different decisions.

Components of a Decision Table:

A. Conditions: ➖
Represent the different factors or criteria that need to be considered.

B. Rules: ➖
Represent combinations of conditions and the corresponding actions or outcomes.

IL
C. Actions or Outcomes: ➖
Specify the results or decisions associated with each rule.
Example:
Consider a decision table for determining shipping costs based on the weight and destination of a
package:

Weight

Light
H Destination

Domestic
Shipping Cost

$5

Light International $15

Heavy Domestic $10


SA
Heavy International $25



Comparison:
Use Case:
Decision trees are suitable for representing sequential decision-making processes, especially when there is
a clear order of conditions.
Decision tables are effective for handling complex combinations of conditions and providing a structured
overview of decision logic.

Complexity: ➖
Decision trees may become complex when there are numerous decision points and conditions.
Decision tables can handle a higher level of complexity, as they provide a structured way to organize and
present multiple conditions and outcomes.

Readability: ➖
Decision trees are visually intuitive and easy to understand for simpler decision structures.
Decision tables are more systematic and may offer better readability for complex decision logic.

;16
● Formal Requirements Specification
A formal specification in software engineering is a specification written in a language with a formal
definition of its vocabulary, syntax, and semantics. The specification languages must be based on
mathematical concepts with well-understood properties.

Formal specifications can help achieve clarity and precision in software requirements. Natural language
requirements can be ambiguous, which can lead to misinterpretations among developers, designers, and
stakeholders.

A software requirements specification (SRS) is a formal document that describes what the software will do
and how it will perform. It also describes the functionality the product needs to fulfil the needs of all
stakeholders. The SRS is a communication medium between the customers and the developer.

IL
● Software Cost Estimation ➖
Software cost estimation is the process of predicting the effort required to develop a software system. It
involves estimating the effort, development time, and resources needed to complete a software project.

Here are some steps for accurately estimating software development costs: ➖
1. Create a project brief and high-level modules map
2. Research and select technologies
H
3. Draft a software requirements specification (SRS) document
4. Create low-fidelity UI wireframes
5. Design a high fidelity UI prototype
6. Create a work breakdown structure (WBS) .

Software cost estimation models view the estimation process as a function, which is computed from cost
SA
drivers. Cost drivers include:

Design methodology, Risk assessment, Skill levels, Programming language, System complexity, Personal
experiences.

Software cost estimation is based on a well-defined and efficient cost model of software. It is also based on
a similar project experience database that includes similar processes, relevant technologies, relevant
environments, relevant quality requirements, and all similar people.
➖03
;17

UNIT

● Software design and its activities ➖


Software engineering is a branch of computer science that involves the design, implementation, and
maintenance of complex computer programs. Software engineers develop, design, and test software
applications and apply engineering principles to the process of building software.

IL
H
Here are some activities in software engineering: ➖
1. Testing ➖
SA
An essential activity in software engineering, testing involves observing the execution of a software system
to validate whether it behaves as intended and identify potential malfunctions.

2. Project management ➖
A key discipline of software engineering, project management ensures the development is done in a
reasonable timeframe while guaranteeing quality standards.

3. Waterfall model ➖
A prominent software engineering and product development strategy that takes a continuous, sequential
approach to the software development life cycle (SDLC).

4. Prototyping ➖
A type of software engineering model that can have a complete range of functionalities of the projected
system. In HCI, prototyping is a trial and partial design that helps users in testing design ideas without
executing a complete system.

;18
5. Testing and validation
A well-recognized part of the software engineering process and standard practice for anyone who has to
"prove it works".

6. Measuring and reporting mechanisms ➖


A procedure to ensure compliance with software development standards.

● Preliminary and detailed design activities ➖


In software engineering, the design phase of the software development life cycle (SDLC) encompasses
both preliminary design and detailed design activities. Let's explore each phase and its associated activities:


Preliminary Design Activities:

IL
1. System Architecture: ➖
Objective: Define the high-level structure of the software system.

2. Activities: ➖
● Identify major components and their interactions.
● Choose architectural patterns or styles (e.g., client-server, microservices).
● Define the overall system organisation.
H
3. Subsystem Specification: ➖
● Objective: Break down the system into smaller subsystems or modules.
● Activities:
Specify the responsibilities and functions of each subsystem.
Identify potential interactions between subsystems.
SA
4. Database Design: ➖
● Objective: If applicable, design the structure and organisation of the database.
● Activities:
Identify entities, attributes, and relationships in the data model.
Begin defining the database schema.

5. User Interface (UI) Design: ➖


● Objective: Design the user interface elements and layout.
● Activities:
Create wireframes or mockups to visualise the UI.
Consider user interactions and experience.

6. Hardware/Software Selection: ➖
● Objective: Identify the hardware and software components needed for the system.
● Activities:
Evaluate and select appropriate technology stacks.
Consider hardware requirements and constraints.
;19

7. Risk Analysis: ➖
● Objective: Identify potential risks that could impact the design and implementation.
● Activities:
Assess potential challenges related to technology, resources, or requirements.
Develop mitigation strategies for identified risks.

Detailed Design Activities: ➖


1. Module/Component Design: ➖
● Objective: Specify the internal structure and behaviour of individual modules or components.
● Activities:

IL
Define data structures and algorithms for each module.
Specify the methods and interfaces within each module.

2. Data Structure Design: ➖


● Objective: Design the data structures used within the software.
● Activities:
Select appropriate data structures based on requirements.
H
Specify how data will be organised and accessed.

3. Algorithm Design: ➖
● Objective: Design algorithms for processing and manipulating data.
● Activities:
Specify step-by-step procedures for accomplishing specific tasks.
Optimise algorithms for efficiency.
SA
4. Database Schema Refinement: ➖
● Objective: Refine the database schema based on detailed design requirements.
● Activities:
Normalise the database schema to eliminate redundancy.
Define constraints, indexes, and relationships.

5. Security Design: ➖
● Objective: Integrate security measures into the design to protect against potential threats.
● Activities:
Define access control mechanisms.
Implement encryption for sensitive data.

6. Concurrency Control Design: ➖


● Objective: Manage concurrent access to data in the system.
● Activities:
Specify how the system handles multiple processes or threads.
Design mechanisms for synchronisation.

;20
7. User Interface (UI) Component Design:
● Objective: Specify the detailed design of user interface components.
● Activities:
Design individual screens, forms, or UI elements.
Specify user interactions and navigation.

8. Error Handling and Recovery Design: ➖


● Objective: Design mechanisms to handle errors and ensure system recovery.
● Activities:
Specify error detection and reporting procedures.
Design recovery strategies in case of failures.

IL
9. Test Case Design:
● Objective: Design test cases that will be used to validate the system.
● Activities:
Specify inputs, expected outputs, and conditions for testing.
Consider both functional and non-functional testing requirements.

10. Documentation: ➖
● Activities:
H
● Objective: Document the detailed design decisions and guidelines.

Create detailed design documents.


Add comments within the source code to explain complex sections.

11. Review and Validation: ➖


● Objective: Conduct reviews to ensure the quality and correctness of the detailed design.
SA
● Activities:
Perform peer reviews of design documents and code.
Validate the detailed design against the specified requirements.

● Characteristics of a good software design ➖


A good software design is crucial for the success of a software project. It impacts the quality,
maintainability, and overall success of the software system. Here are some key characteristics of a good
software design in software engineering:

1. Modularity: ➖
● Definition: The system is divided into small, independent modules or components.
● Benefits:
Enhances maintainability and ease of understanding.
Supports parallel development by isolating changes to specific modules.

2. Scalability: ➖
● Definition: The design accommodates future growth and can scale to handle increased loads or
requirements.
;21
● Benefits:
Allows the system to adapt to changing needs and requirements.
Facilitates the addition of new features without significant redesign.

3. Maintainability: ➖
● Definition: The design is easy to understand, modify, and maintain.
● Benefits:
Reduces the cost of future enhancements and updates.
Minimises the risk of introducing errors during maintenance.

4. Flexibility:➖
● Definition: The design allows for changes and adaptations without major modifications.

IL
● Benefits:
Enables the system to evolve in response to changing requirements.
Supports the addition of new features without disrupting existing functionality.

5. Readability and Understandability: ➖


● Definition: The design is clear and easily understandable by developers and other stakeholders.
● Benefits:
H
Facilitates collaboration and communication among team members.
Reduces the likelihood of introducing errors due to misunderstandings.

6. Efficiency: ➖
● Definition: The design optimises resource utilisation, including time, memory, and processing
power.
● Benefits:
SA
Enhances system performance and responsiveness.
Reduces resource wastage and operating costs.

7. Loose Coupling: ➖
● Definition: Modules or components are independent and have minimal interdependencies.
● Benefits:
Allows for changes in one module without affecting others.
Supports better module reusability and maintainability.

8. High Cohesion: ➖
● Definition: Components within a module are highly related and contribute to a specific,
well-defined task.
● Benefits:
Improves the readability and maintainability of the code.
Enhances the module's functionality and reusability.

;22
9. Adherence to Design Principles:
● Definition: The design follows established design principles such as SOLID principles, DRY (Don't
Repeat Yourself), and KISS (Keep It Simple, Stupid).
● Benefits:
Promotes a structured and organised design.
Reduces complexity and makes the system more robust.

10. Consistency: ➖
● Definition: The design maintains a consistent structure, coding style, and use of design patterns.
● Benefits:
Improves the predictability and maintainability of the system.
Facilitates collaboration among team members.

IL
11. Robust Error Handling: ➖
● Definition: The design includes effective mechanisms for detecting, reporting, and handling errors.
● Benefits:
Enhances system reliability and user experience.
Facilitates troubleshooting and debugging.


H
12. Security Considerations:
● Definition: The design incorporates security measures to protect against potential threats and
vulnerabilities.
● Benefits:
Safeguards sensitive data and prevents unauthorised access.
Minimises the risk of security breaches.


SA
13. Documentation:
● Definition: The design is well-documented, including design specifications, code comments, and
other relevant documentation.
● Benefits:
Aids in understanding and maintaining the system.
Facilitates knowledge transfer within the team.

14. Testability:➖
● Definition: The design supports effective testing with well-defined interfaces and modular
components.
● Benefits:
Eases the identification and resolution of defects.
Supports the implementation of comprehensive test suites.

15. Adaptability to Change: ➖


● Definition: The design is resilient to changes in requirements and can be easily adapted.
● Benefits:
;23
Enables the software to evolve over time.
Reduces the impact of changes on existing functionality.

A good software design balances these characteristics to create a system that is not only functional but also
maintainable, scalable, and adaptable to changing needs. It promotes efficient collaboration among team
members and contributes to the long-term success of the software project.

● Features of a design document ➖


A software design document (SDD) typically includes the following features:

1. Title: The project's title


2. Authors and reviewers: The document's authors

IL
3. Introduction: General information about the project and its purpose
4. Roles and responsibilities
5. Overview
6. User interface
7. Functions
8. Scope
The design phase of software engineering is considered the most important phase of the entire process.
This is because the entire product will be built upon decisions made in this phase.
H
SA
;24


Here are some other features of software engineering:
1. Testing
Testing is essential in software engineering because it validates your code's correctness and helps ensure it
is reliable and maintainable.

2. Documentation ➖
Documentation is an important part of Software Engineering.

3. Maintainability ➖
A good software design should be easy to understand, well-organized, and documented to enable
maintenance and modifications.

IL
4. System design
System design is a crucial aspect of software engineering that involves designing and implementing
large-scale systems that can handle complex tasks efficiently.

5. User interface ➖
User interface design is a crucial aspect of software engineering, as it is the means by which users interact
with software applications.


6. Architecture
H
Architectural design is the first stage in the software design process. It is the critical link between design
and requirements engineering, as it identifies the main structural components in a system and the
relationships between them.

● Cohesion and Coupling ➖


SA
In software engineering, cohesion and coupling are concepts that measure the relationship between
elements within a module and between different modules.
;25
Cohesion Measures the degree to which elements within a module work together to fulfill a single,
well-defined purpose.
Coupling Measures the degree to which a software element is connected to other elements.

Here are some types of cohesion: ➖


1. Functional cohesion, Sequential cohesion, Communicational cohesion, Procedural cohesion,
Temporal cohesion, Logical cohesion, Coincidental cohesion.

2. Low coupling means that modules are independent and changes in one module have little impact on
other modules. Low coupling is often thought to be a sign of a well-structured computer system and
a good design.

IL
3. Achieving low coupling and high cohesion promotes maintainable and comprehensible modular
structures. This symbiotic relationship allows developers to navigate complexity that improves
testing, scalability, and teamwork.

● Structured Analysis ➖
Structured analysis is a software engineering technique that uses diagrams to create and present system
specifications. These diagrams describe the steps and data required to meet the design function of a
particular software.
H
Structured analysis is typically used during the early stages of software development. It's a fundamental
tool of systems analysis, developed from classical systems analysis of the 1960s and 1970s.

Structured analysis and design techniques analyse business requirements and develop specifications for
converting practices into computer programs, hardware configurations, and related manual procedures.
SA
Structured analysis uses graphical diagrams to create and present user-friendly system requirements. The
process divides a complex system into more manageable, smaller parts.

Structured analysis and design techniques use diagrams like activity models and the data models as the
modelling language. Structured design converts the data of the structured analysis into a structure chart
which represents the whole architecture of the software.

;26
● Object-Oriented Design
Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The
state is distributed among the objects, and each object handles its state data. For example, in a Library
Automation Software, each library representative may be a separate object with its data and functions to
operate on these data. The tasks defined for one purpose cannot refer or change data of other objects.
Objects have their internal data which represent their state. Similar objects create a class. In other words,
each object is a member of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

IL
H
1. Objects: All entities involved in the solution design are known as objects. For example,
people, banks, companies, and users are considered as objects. Every entity has some
SA
attributes associated with it and has some methods to perform on the attributes.

2. Classes: A class is a generalised description of an object. An object is an instance of a


class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.

3. Messages: Objects communicate by message passing. Messages consist of the integrity


of the target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.

4. Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction


is the removal of the irrelevant and the amplification of the essentials.

5. Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information
of an object together but also restricts access to the data and methods from the outside
world.
;27
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the
lower or sub-classes can import, implement, and re-use allowed variables and functions
from their immediate superclasses.This property of WOOD is called an inheritance. This
makes it easier to define a specific class and to create generalised classes from specific
ones.

7. Polymorphism: OOD languages provide a mechanism where methods performing similar


tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface to perform functions for different types.
Depending upon how the service is invoked, the respective portion of the code gets
executed.

IL
User Interface Design ➖
The visual part of a computer application or operating system through which a client interacts
with a computer or software. It determines how commands are given to the computer or the
program and how data is displayed on the screen.

Types of User Interface ➖


H
There are two main types of User Interface:
● Text-Based User Interface or Command Line Interface
● Graphical User Interface (GUI).

Text-Based User Interface: This method relies primarily on the keyboard. A typical example of
this is UNIX.
SA
Advantages ➖
1. Many and easier customizations options.
2. Typically capable of more important tasks.

Disadvantages ➖
1. Relies heavily on recall rather than recognition.
2. Navigation is often more difficult.

Graphical User Interface (GUI): GUI relies much more heavily on the mouse. A typical example of
this type of interface is any versions of the Windows operating systems.

;28
GUI Characteristics

Characterist Descriptions
ics

Windows Multiple windows allow different information to be displayed simultaneously on the

user's screen.

Icons Icons different types of information. On some systems, icons represent files. On other

icons describe processes.

IL
Menus Commands are selected from a menu rather than typed in a command language.

Pointing A pointing device such as a mouse is used for selecting choices from a menu or

indicating items of interest in a window.

Graphics Graphics elements can be mixed with text or the same display.

UI Design Principles
H
SA
➖ 04.
;29

UNIT

● Testing Fundamentals ➖
Software testing is a fundamental part of the software development life cycle. It's a complex and
resource-intensive process, but it can create business value and utility.

IL
Here are some fundamentals of software testing:

1. Verification: Confirms that the software meets technical requirements


2.
3.
4.
H
Validation: Confirms that the software meets functional and business requirements
Testability: Helps find critical regions where problems are hidden from the tester
Automation: Enables testers to automate repetitive tasks and use the saved time to find
bugs
5. Integration: Integrates and tests software modules to build a complete system
6. Exploratory: Explores the software application to find defects and issues
7. Unit: Verifies the functionality of individual units of code, such as functions, classes, or
SA
modules
8. Acceptance: Tests the system before it is accepted by the user
9. Load: Ensures that software performs to render maximum user satisfaction

Other fundamentals of software testing include: Troubleshooting, Defect detection, Defect


prevention, User satisfaction.

● Unit Testing ➖
Unit testing is a software development process that involves testing the smallest testable parts
of an application. The purpose of unit testing is to ensure that each unit of software code works
as expected.
;30

IL
Here are some tools for unit testing: ➖
1. Unit ➖

A publicly available unit testing framework using Java programming
2. NUnit


H
An open-source unit testing tool similar to JUnit
3. Test NG


An open-source tool exclusively designed for the Java programming language
4. Pytest
A unit testing tool for Python
SA
Here are some steps for unit testing:
1. Write test cases for all functions and methods
2. Run unit tests each time the code is changed
3. Identify quickly whenever a change causes a fault
4. Isolate each unit of the system to identify, analyse, and fix the defects

Unit testing is an integral part of software development. It allows the programmer to refactor
code or upgrade system libraries at a later date, and make sure the module still works correctly.

● Integration Testing ➖
Integration testing in software engineering is the process of testing the interface between two
software units or modules. It aims to identify faults in the interaction between integrated units.

Here are some guidelines for integration testing:


1. Examine the application's structure and architecture
2. Identify the crucial modules to test first
3. Identify all possible scenarios
;31
4. Design test cases to verify each interface in detail
5. Choose input data for test case execution

System integration testing is a type of integration testing that validates the behavior of the whole
system. For example, a commercial bank might have a large system that includes a mainframe
system, online banking system, and credit card access system


Here are some types of integration testing:
1. Big bang approach
This is one of the most common types of integration testing. It involves testing all units at the
same time. This approach is good for small software projects or after other forms of testing have

IL
been done.

2. Regression testing ➖
This is performed during the integration testing phase. It ensures that the integration of the
components has not caused any issues in the previously tested functionality.

Some tools for integration testing include:


1. Protractor: This is an open-source automation framework tool that helps to run instances
H
of applications. It also provides the opportunity to run tests from the user point of view.
2. Rational Integration Tester: This helps to eliminate the bugs that occur during the
integration tests.
3. Citrus: This is an open-source test automation framework that allows you to test complex
messaging scenarios.


SA
● Validation Testing
Validation testing in software engineering is the process of ensuring that a software product
meets the needs of the user or client. It involves assessing a software product to ensure that it
performs as expected and meets the needs of the consumer.

Validation testing can be performed during the development process or at the end of the
process. It involves testing the business requirement logic or scenarios in detail, and testing all
critical functionalities of the application.

Validation testing includes: Smoke testing, Functional testing, Integration testing, Unit testing.
The validation process can also include functionality testing, such as black box, white box, and
grey box testing to find bugs in the product segment.

The validation process involves the following steps:


1. Preparing to conduct validation
2. Conducting planned validation
3. Analysing validation results
4. Preparing a validation report
;32
5. Capturing the validation work products

● System Testing ➖
System testing in software engineering is the process of evaluating an integrated system or
application to ensure that all components work together effectively. It focuses on verifying the
interactions and functionality of the entire system.

IL
H
Here are some types of system testing:
1. Functional testing: Verifies that each function of the software application works in
conformance with the requirement and specification.
SA
2. Load testing: Tests an application's stability and response time by applying load.
3. Regression testing: Also known as sanity testing, it ensures that all changes introduced
into an application or code during system testing haven't caused any new bugs or issues.
4. Usability testing: Checks the product's usability. It aims to test whether or not the system is
easy to use.
5. Scalability testing: Validates the overall performance of a software program.

Other software testing strategies include:


1. Unit testing
2. Integration testing
3. Acceptance/Validation testing

● Maintenance and Reengineering ➖


In software engineering, maintenance and reengineering are two different areas.
Maintenance is the process of updating and modifying a software system after it has been
delivered to the customer. This can include:
1. Fixing bugs
2. Adding new features
;33
3. Improving performance
4. Updating the software to work with new hardware or software systems

Reengineering, also known as reverse engineering or software re-engineering, is the process of


analysing, designing, and modifying existing software systems. This can help improve the quality,
performance, and maintainability of the software.

Here are some differences between maintenance and reengineering:


1. Scope: Reengineering is more challenging and vast than maintenance.
2. Purpose: Maintenance is for running the system until it reaches the end of its life, while
reengineering makes the system new so it can work for another life span.

IL
● Measures ➖
Software engineering metrics are a quantitative way to measure software properties and
attributes. They are a key element of software testing and development, as they help evaluate the
quality and effectiveness of the process.

Here are some types of software metrics:


H
1. Product metrics Used to define product attributes like size, design features, complexity,


performance, and quality.
2. Process metrics Measures of the software development process, used in estimation


techniques and other technical work.


3. Test metrics Measurements that determine the effectiveness of testing strategies.
4. Function point analysis A unique measure for software that can be used to estimate the
SA
cost or effort required to design, code, and test the software.

Software engineering metrics can help software engineers:


1. Assess the quality of the software being developed
2. Track progress
3. Identify areas for improvement
4. Provide trackable data for progress, improvements, and better decision-making

Some software quality factors that require measures include: Correctness, Maintainability,
Integrity, Usability

● Metrics, and Indicators ➖


In software engineering, metrics are quantitative measures used to assess and evaluate the
software development process. They are standards for estimating the quality, progress, and
health of software development activity.
;34

IL
Indicators are metrics or combinations of metrics that provide insight into the software process,
a software project, or the product itself. Indicators can help project managers or software
engineers adjust the process, the project, or the product to make things better.

Some examples of metrics in software engineering include:


H
1. Software testing metrics
These metrics help increase the efficiency and effectiveness of the software testing process.
They also help make better decisions for future testing by providing accurate data about the
testing process.

2. Test economic metrics ➖


These metrics evaluate the estimated amount of testing, with the actual expenditure of money
SA
during the process of testing.

3. Project metrics ➖
These metrics are used by the project manager to check the project's progress. Data from the
past projects are used to collect various metrics, like time and cost.

4. Defect metrics ➖
These metrics measure the productivity and performance of development teams as they work, as
well as the performance of the applications they create.

● Software Measurement ➖
Software measurement is a quantitative measure of a software system's attributes. Software
metrics are used to:
1. Improve the quality of a product or process
2. Anticipate future qualities of a product or process
3. Regulate the state of a project concerning budget and schedule
;35
4. Enable data-driven decision-making in project planning and control
5. Measure the productivity and performance of development teams
6. Measure the performance of the applications they create

Software metrics can help developers understand the accuracy of their software development
process. They can also help analyse the efficiency of software in numerical terms.

Here are some types of software metrics:

1. Manual test metrics ➖


Manual testing is a key aspect of software development and quality assurance. It involves testing

IL
software manually, without the use of automated test tools or scripts. Manual testing is used to
detect any defects, bugs, or gaps in the overall functionality of the application.

2. Defect category ➖
Defect category is calculated by dividing the number of defects belonging to a particular
category by the total number of defects


.
3. Defect severity index
H
Defect severity index is the degree of impact a defect has on the development of an operation or
a component of a software application being tested.

● Metrics for Requirements Model ➖


Software metrics are measurements of a system, product, or process that are used to determine
the degree or units of any attribute. They are used to monitor the product development and
SA
quality.

Here are some metrics for software engineering:

1. Requirements quality metrics ➖


Measures how well the software requirements meet the desired standards and expectations of
the stakeholders. These standards include clarity, completeness, consistency, traceability,


testability, and feasibility.
2. Product metrics
Measures at any phase of its development, from requirements to recognized systems. This
would typically involve adherence to timelines, bugs per cycle, turnaround time, and technical
debt.

3. Architectural design metrics ➖


Measures the characteristics of a software program during the design phase. This includes
measuring complexity for the structure, data components, and the interface design of a software
program.

;36
4. Defect metrics
Assesses defects and vulnerabilities. This includes defect density, defects finding rate, and
defect fixing time.

5. Developer productivity metrics ➖


Also known as operational metrics, these metrics determine how much time and effort an
individual uses to complete their tasks.

6. Software quality metrics ➖


Measures whether software satisfies its requirements.

IL
Software metrics can be used to create software quality requirements. They offer a quantitative
basis for predicting the software development process.

● Metrics for Design Model ➖


Design metrics are a measure of an implementation's features, such as its cost, size, power, and
performance.
H
SA

Here are some other metrics used in software engineering:


1. Productivity metrics Help development managers run projects better. They can be used
to gauge how far along a project is, levels of developer productivity, and the amount of


additional dev time necessary.
2. Complexity metrics Measure software complexity. They can be used to forecast key
information regarding the testability, reliability, and manageability of software systems.

;37
3. Product metrics Help software engineers assess the quality of the design and


construction of the software product being built.
4. Coding metrics Allow developers to track and measure the quality of code they're


creating.
5. Information flow metrics Measure the flow of information in a software system.

Software metrics play a critical role in software engineering. They provide a quantitative way to
measure software attributes and properties. These measurements enable software engineers to
assess the quality of the software being developed, track progress, and identify areas for
improvement.

IL
● Metrics for Testing, Metrics for Maintenance ➖
Software testing metrics are quantitative measures that help estimate the quality and progress of
a software testing process.

H
SA


Here are some software testing metrics:
1. Test team metrics These metrics include test cases allocated per team member,
defects returned, and defects for retest per team member. This data helps to understand
the workload allocated for every team member.


2. Defect metrics These metrics offer insights into the different quality attributes of the
software, such as its functionality, usability, performance, stability, and reliability.


3. Defect density This is considered one of the most efficient testing techniques in the
overall process of the software development process.


4. Defect severity This metric allows the developer to see how the defect will affect the
software's quality.
➖This metric measures how effective test cases are at detecting
;38
5. Test case efficiency
problems.


6. Accepted defects percentage This metric indicates the count of defects that have been
accepted by the development or quality assurance team as valid issues requiring
resolution.

Here are some software maintenance metrics:


1. Planned maintenance percentage (PPC)
2. Overall Equipment Effectiveness (OEE)
3. Mean time to repair (MTTR)

IL
4. Mean time between failure (MTBF)
5. Preventive maintenance compliance (PMC)
6. Effort
7. Output
8. Quality
9. Complexity .

HAPPY ENDING BY SAHIL RAUNIYAR


H
SA

You might also like