Software Engineering Theory (4th Sem) .
Software Engineering Theory (4th Sem) .
IL
Sahil Kumar Dr.
➖
➖
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.
❖ 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.
❖ 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.
❖ 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.
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.
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.
➖
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.
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
➖
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.
IL
11. Documentation: ➖
Maintain accurate and up-to-date documentation throughout the project lifecycle.
Document decisions, changes, and rationales for future reference.
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.
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.
IL
agrees on what the system is expected to deliver.
➖
.
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.
➖
should possess several key properties to ensure clarity, completeness, and effectiveness.
Here are some essential properties of a good SRS document:
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.
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.
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.
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
➖
➖
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
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".
➖
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.
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.
IL
Define data structures and algorithms for each module.
Specify the methods and interfaces within each module.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
user's screen.
Icons Icons different types of information. On some systems, icons represent files. On other
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
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:
● 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.
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.
➖
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.
● 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.
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.
➖
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.
Some software quality factors that require measures include: Correctness, Maintainability,
Integrity, Usability
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.
➖
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.
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.
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.
➖
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.
IL
Software metrics can be used to create software quality requirements. They offer a quantitative
basis for predicting the software development process.
➖
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.
IL
4. Mean time between failure (MTBF)
5. Preventive maintenance compliance (PMC)
6. Effort
7. Output
8. Quality
9. Complexity .