Software Engineering

Software is a program or set of programs containing instructions that provide desired functionality. And
Engineering is the process of designing and building something that serves a particular purpose and finds
a cost-effective solution to problems.
Software engineering is the process of designing, developing, testing, and maintaining software. It is a
systematic and disciplined approach to software development that aims to create high-quality, reliable,
and maintainable software. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and maintenance.
Software Engineering is a systematic, disciplined, quantifiable study and approach to the
design, development, operation, and maintenance of a software system.

Layered Technology in Software Engineering

Software engineering is a fully layered technology, to develop software we need to go from one layer to
another. All the layers are connected and each layer demands the fulfillment of the previous layer.

Fig: The diagram shows the layers of software development

Layered technology is divided into four parts:

1. A quality focus: It defines the continuous process improvement principles of software. It provides
integrity that means providing security to the software so that data can be accessed by only an authorized
person, no outsider can access the data. It also focuses on maintainability and usability.

2. Process: It is the foundation or base layer of software engineering. It is key that binds all the layers
together which enables the development of software before the deadline or on time. Process defines a
framework that must be established for the effective delivery of software engineering technology. The
software process covers all the activities, actions, and tasks required to be carried out for software
development.
Process activities are listed below:-
 Communication: It is the first and foremost thing for the development of software. Communication is
necessary to know the actual demand of the client.
 Planning: It basically means drawing a map for reduced the complication of development.
 Modeling: In this process, a model is created according to the client for better understanding.
 Construction: It includes the coding and testing of the problem.
 Deployment:- It includes the delivery of software to the client for evaluation and feedback.

3. Method: During the process of software development the answers to all “how-to-do” questions are given
by method. It has the information of all the tasks which includes communication, requirement analysis,
design modeling, program construction, testing, and support.

4. Tools: Software engineering tools provide a self-operating system for processes and methods. Tools
are integrated which means information created by one tool can be used by another.

Importance of Software Engineering

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and challenging to progress. Software
engineering has a great solution to reduce the complication of any project. Software engineering divides
big problems into various small issues. And then start solving each small issue one by one. All these small
problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hardwork and software engineers are highly paid
experts. A lot of manpower is required to develop software with a large number of codes. But in software
engineering, programmers project everything and decrease all those things that are not needed. In turn,
 the cost for software productions becomes less as compared to any software that does not use software
engineering method.
3. To decrease time: Anything that is not made according to the project always wastes time. And if you are
making great software, then you may need to run many codes to get the definitive running code. This is a
very time-consuming procedure, and if it is not well handled, then this can take a lot of time. So if you are
making your software according to the software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and they need lots of patience,
planning, and management. And to invest six and seven months of any company, it requires heaps of
planning, direction, testing, and maintenance. No one can say that he has given four months of a company
to the task, and the project is still in its first stage. Because the company has provided many resources to
the plan and it should be completed. So to handle a big project without any problem, the company has to
go for a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered the software, then it should
work for at least its given time or subscription. And if any bugs come in the software, the company is
responsible for solving all these bugs. Because in software engineering, testing and maintenance are given,
so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the standards. Software standards
are the big target of companies to make it more effective. So Software becomes more effective in the act
with the help of software engineering.

Software Myths
Software myths are misconceptions about software and its development that people believe
to be true. The software myths that have persisted over time have now been identified by
professionals in software engineering.
Managers and programmers are well-versed in these fallacies. However, it may be difficult to
alter old habits.
Types of Software Myths
Here are some common types of software myths:

1. Myths about the ease of software development: This type of myth suggests that anyone can develop
software, or that software development is a simple and easy process.
2. Myths about software testing: This type of myth suggests that software testing is a one-time event, or
that it's possible to create bug-free software.
3. Myths about software development methodologies: This type of myth suggests that one particular
software development methodology (e.g., Agile, Waterfall) is the best or the only way to develop
software.
4. Myths about software quality: This type of myth suggests that the cost of software is directly
proportional to its quality or that more features necessarily mean better software.
5. Myths about the role of the software developer: This type of myth suggests that software developers
work alone or they have all the skills and knowledge required to develop software.
6. Myths about software maintenance: This type of myth suggests that software maintenance is not
necessary, or it's easy to maintain software without any additional effort.
 7. Myths about software customization: This type of myth suggests that it's easy to customize software to
meet specific needs, or customization does not have any negative impacts on software performance.

Software paradigm
Software paradigm refers to method and steps, which are taken while designing the software.
Programming paradigm is a subset of software design paradigm which is future for other a
subset of software development paradigm. Software is considered to be a collection of
executable programming code, associated libraries, and documentation. Software development
paradigm is also known as software engineering, all the engineering concepts pertaining to
developments software applied. It consists of the following parts as Requirement Gathering,
Software design, Programming, etc. The software design paradigm is a part of software
development. It includes design, maintenance, programming.
Software paradigm is a theoretical framework that serves as a guide for the development
and structure of a software system. There are several software paradigms, including:
 Imperative paradigm: This is the most common paradigm and is based on the idea that
a program is a set of instructions that tell a computer what to do. It is often used in
languages such as C and C++.
 Object-oriented paradigm: This paradigm is based on the idea of objects, which are
self-contained units that contain both data and behavior. It is often used in languages
such as Java, C#, and Python.
 Functional paradigm: This paradigm is based on the idea that a program is a set of
mathematical functions that transform inputs into outputs. It is often used in languages
such as Haskell, Lisp, and ML.
 Logic paradigm: This paradigm is based on the idea that a program is a set of logical
statements that can be used to infer new information. It is often used in languages such
as Prolog and Mercury.
 The Software Development Life Cycle (SDLC) is a process that software developers
use to plan, design, develop, test, deploy, and maintain software systems. The most
common SDLC models include:
 Waterfall model: This model is based on the idea that software development is a linear
process, with each phase building on the previous one.
 Agile model: This model is based on the idea that software development is an iterative
process, with small

SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management that defines the
stages include in an information system development project, from an initial feasibility study to the
maintenance of the completed application.
There are different software development life cycle models specify and design, which are followed during
the software development phase. These models are also called "Software Development Process
Models." Each process model follows a series of phase unique to its type to ensure success in the step of
software development.

Here, are some important phases of SDLC life cycle:

Waterfall model
Winston Royce introduced the Waterfall Model in [Link] model has five phases: Requirements analysis
and specification, design, implementation, and unit testing, integration and system testing, and operation
and maintenance. The steps always follow in this order and do not overlap. The developer must complete
every phase before the next phase begins. This model is named "Waterfall Model", because its
diagrammatic representation resembles a cascade of waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand the exact
requirements of the customer and to document them properly. Both the customer and the software
developer work together so as to document all the functions, performance, and interfacing requirement
of the software. It describes the "what" of the system to be produced and not "how."In this phase, a large
document called Software Requirement Specification (SRS) document is created which contained a
detailed description of what the system will do in the common language.
2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a suitable form
which permits further coding in a programming language. It defines the overall software architecture
together with high level and detailed design. All this work is documented as a Software Design Document
(SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the SDD is complete,
the implementation or coding phase proceeds smoothly, because all the information needed by software
developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in isolation
initially. After that these modules are tested by writing some overhead code to check the interaction
between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end product is
determined by the effectiveness of the testing carried out. The better output will lead to satisfied
customers, lower maintenance costs, and accurate results. Unit testing determines the efficiency of
individual modules. However, in this phase, the modules are tested for their interactions with each other
and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once the
software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.
Advantages of Waterfall model
 This model is simple to implement also the number of resources that are required for it is minimal.
 The requirements are simple and explicitly declared; they remain unchanged during the entire project
development.
 The start and end points for each phase is fixed, which makes it easy to cover progress.
 The release date for the complete product, as well as its final cost, can be determined before
development.
 It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

 In this model, the risk factor is higher, so this model is not suitable for more significant and complex
projects.
 This model cannot accept the changes in requirements during development.
 It becomes tough to go back to the phase. For example, if the application has now shifted to the coding
phase, and there is a change in requirement, It becomes tough to go back and change it.
 Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier
phase, so the risk reduction strategy is difficult to prepare.

Prototype Model
The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built. A prototype is a toy implementation of the system. A prototype
usually turns out to be a very crude version of the actual system, possible exhibiting limited functional
capabilities, low reliability, and inefficient performance as compared to actual software. In many instances,
the client only has a general view of what is expected from the software product. In such a scenario where
there is an absence of detailed information regarding the input to the system, the processing needs, and
the output requirement, the prototyping model may be employed.
Steps of Prototype Model
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.
2. Require extensive customer collaboration

 Costs customer money

 Needs committed customer
  Difficult to finish if customer withdraw
 May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation,
and feedback.
5. Prototyping tools are expensive.

RAD (Rapid Application Development) Model

RAD is a linear sequential software development process model that emphasizes a concise development
cycle using an element based construction approach. If the requirements are well understood and
described, and the project scope is a constraint, the RAD process enables a development team to create
a fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be developed faster and of higher
quality through:

 Gathering requirements using workshops or focus groups

 Prototyping and early, reiterative user testing of designs
 The re-use of software components
 A rigidly paced schedule that refers design improvements to the next product version
 Less formality in reviews and other team communication
The various phases of RAD are as follows:
[Link] Modelling: The information flow among business functions is defined by answering questions
like what data drives the business process, what data is generated, who generates it, where does the
information go, who process it and so on.

2. Data Modelling: The data collected from business modeling is refined into a set of data objects
(entities) that are needed to support the business. The attributes (character of each entity) are identified,
and the relation between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data modeling phase are transformed to
achieve the data flow necessary to implement a business function. Processing descriptions are created
for adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software; even
they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested since RAD
emphasis reuse. This reduces the overall testing time. But the new part must be tested, and all interfaces
must be fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a short span time (2-3 months).
o When the requirements are well-known.
o When the technical risk is limited.
o When there's a necessity to make a system, which modularized in 2-3 months of period.
o It should be used only if the budget allows the use of automatic code generating tools.

Advantage of RAD Model

 This model is flexible for change.
 In this model, changes are adoptable.
 Each phase in RAD brings highest priority functionality to the customer.
 It reduced development time.
 It increases the reusability of features.

Disadvantage of RAD Model

 It required highly skilled designers.
 All application is not compatible with RAD.
 For smaller projects, we cannot use the RAD model.
 On the high technical risk, it's not suitable.
 Required user involvement.
Evolutionary Process Model
Evolutionary process model resembles the iterative enhancement model. The same phases are defined
for the waterfall model occurs here in a cyclical fashion. This model differs from the iterative enhancement
model in the sense that this does not require a useful product at the end of each cycle. In evolutionary
development, requirements are implemented by category rather than by priority.

For example, in a simple database application, one cycle might implement the graphical user Interface
(GUI), another file manipulation, another queries and another updates. All four cycles must complete
before there is a working product available. GUI allows the users to interact with the system, file
manipulation allow the data to be saved and retrieved, queries allow user to get out of the system, and
updates allows users to put data into the system.

Benefits of Evolutionary Process Model

 Use of EVO brings a significant reduction in risk for software projects.
 EVO can reduce costs by providing a structured, disciplined avenue for experimentation.
 EVO allows the marketing department access to early deliveries, facilitating the development of
documentation and demonstration.
 Better fit the product to user needs and market requirements.
 Manage project risk with the definition of early cycle content.
 Uncover key issues early and focus attention appropriately.
 Increase the opportunity to hit market windows.
 Accelerate sales cycles with early customer exposure.
 Increase management visibility of project progress.
 Increase product team productivity and motivations.

Incremental Model
Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every subsequent release of the module adds
function to the previous release. The process continues until the complete system achieved.
The various phases of incremental model are as follows:
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by the requirement
analysis team. To develop the software under the incremental model, this phase performs a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system
functionality and the development method are finished with success. When software develops new
practicality, the incremental model uses style and development phase.

3. Testing: In the incremental model, the testing phase checks the performance of each existing function
as well as additional functionality. In the testing phase, the various methods are used to test the behavior
of each task.

4. Implementation: Implementation phase enables the coding phase of the development system. It
involves the final coding that design in the designing and development phase and tests the functionality
in the testing phase. After completion of this phase, the number of the product working is enhanced and
upgraded up to the final system product

When we use the Incremental Model?

 When the requirements are superior.
 A project has a lengthy development schedule.
 When Software team are not very well skilled or trained.
 When the customer demands a quick release of the product.
 You can develop prioritized requirements first.

Advantage of Incremental Model

 Errors are easy to be recognized.
 Easier to test and debug
 More flexible.
 Simple to manage risk because it handled during its iteration.
 The Client gets important functionality early.
Disadvantage of Incremental Model
 Need for good planning
 Total Cost is high.
 Well defined module interfaces are needed.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples
the iterative feature of prototyping with the controlled and systematic aspects of the linear sequential
model. It implements the potential for rapid development of new versions of the software. Using the
spiral model, the software is developed in a series of incremental releases. During the early iterations, the
additional release may be a paper model or prototype. During later iterations, more and more complete
versions of the engineered system are produced.

The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts :

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the
various alternatives that are possible for achieving the targets, and the constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives
based on the goals and constraints. The focus of evaluation in this stage is located on the risk perception
for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties and
risks. This process may include activities such as benchmarking, simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next
step of the project.

The development phase depends on the remaining risks. For example, if performance or user-interface
risks are treated more essential than the program development risks, the next phase may be an
evolutionary development that includes developing a more detailed prototype for solving the risks.
The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element of
the model is that each period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral model works for development
as well as enhancement projects.

When to use Spiral Model?

 When deliverance is required to be frequent.
 When the project is large
 When requirements are unclear and complex
 When changes may require at any time
 Large and high budget projects

Advantages
 High amount of risk analysis
 Useful for large and mission-critical projects.

Disadvantages
 Can be a costly model to use.
 Risk analysis needed highly particular expertise
 Doesn't work well for smaller projects.

Component Based Model (CBM)

The component-based assembly model uses object-oriented technologies. In object-oriented
technologies, the emphasis is on the creation of classes. Classes are the entities that encapsulate data
and algorithms. In component-based architecture, classes (i.e., components required to build application)
can be uses as reusable components. This model uses various characteristics of spiral model. This model
is evolutionary by nature. Hence, software development can be done using iterative approach. In CBD
model, multiple classes can be used. These classes are basically the prepackaged components. The model
works in following manner:

 Step-1: First identify all the required candidate components, i.e., classes with the help of application
data and algorithms.
 Step-2: If these candidate components are used in previous software projects then they must be
present in the library.
 Step-3: Such preexisting components can be excited from the library and used for further
development.
 Step-4: But if the required component is not present in the library then build or create the component
as per requirement.
 Step-5: Place this newly created component in the library. This makes one iteration of the system.
 Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of iterations required
to develop the complete application.
Characteristics of Component Assembly Model:
 Uses object-oriented technology.
 Components and classes encapsulate both data and algorithms.
 Components are developed to be reusable.
 Paradigm similar to spiral model, but engineering activity involves components.
 The system produced by assembling the correct components.

Formal Methods Model

The formal methods model is concerned with the application of a mathematical technique to design
and implement the software. This model lays the foundation for developing a complex system and
supporting the program development. The formal methods used during the development process
provide a mechanism for eliminating problems, which are difficult to overcome using other software
process models. The software engineer creates formal specifications for this model. These methods
minimize specification errors and this result in fewer errors when the user begins using the system.
Formal methods comprise formal specification using mathematics to specify the desired properties of
the system. Formal specification is expressed in a language whose syntax and semantics are formally
defined. This language comprises a syntax that defines specific notation used for specification
representation; semantic, which uses objects to describe the system; and a set of relations, which uses
rules to indicate the objects for satisfying the specification.

Generally, the formal method comprises two approaches, namely, property based and model-
based. The property-based specification describes the operations performed on the system. In
addition, it describes the relationship that exists among these operations. A property-based specification
consists of two parts: signatures, which determine the syntax of operations and an equation, which
defines the semantics of the operations through a set of equations known as axioms. The model-based
specification utilizes the tools of set theory, function theory, and logic to develop an abstract model of
the system. In addition, it specifies the operations performed on the abstract model. The model thus
developed is of a high level and idealized. A model-based specification comprises a definition of the set
of states of the system and definitions of the legal operations performed on the system to indicate how
these legal operations change the current state.
Various advantages and disadvantages associated with a formal method model are listed in Table.
Table Advantages and Disadvantages of Formal Methods Model
 Advantages Disadvantages
 Discovers ambiguity, incompleteness, and  Time consuming and expensive.
inconsistency in the software.  Difficult to use this model as a communication
 Offers defect-free software. mechanism for non technical personnel.
 Incrementally grows in effective solution after  Extensive training is required since only few
each iteration. developers have the essential knowledge to
 This model does not involve high complexity implement this model.
rate.
 Formal specification language semantics verify
self-consistency.

4th Generation Techniques in Software Engineering

Implementation using a 4GL(4th Generation Techniques) enables the software developer to

represent desired results in a manner that leads to automatic generation of code to create those results.
Obviously, a data structure with relevant information must exist and be readily accessible by the 4GL. To
transform a 4GT implementation into a product, the developer must conduct thorough testing, develop
meaningful documentation, and perform all other solution integration activities that are required in
other software engineering paradigms. In addition, the 4GT developed software must be built in a
manner that enables maintenance to be performed expeditiously.

Software development environment that supports the 4GT paradigm includes

some or all of the following tools:
1) Non-procedural languages for database query
2) Report generation
3) Data manipulation
4) Screen interaction and definition
5) Code generation and High-level graphics capability
6) Spreadsheet capability
7) Automated generation of HTML and similar languages used for Web-site creation using advanced software
tools.

Advantages:
 Simplified the programming process.

 Use non-procedural languages that encourage users and programmers to specify the results they want,
while the computers determines the sequence of instruction that will accomplish those results.

 Use natural languages that impose no rigid grammatical rules.

Disadvantages:
 Less flexible that other languages

 Programs written in 4GLs are generally far less efficient during program execution that programs in
high-level languages.
# Analysis Concepts and Principles
Analysis concepts and principles refer to fundamental ideas and guidelines that are applied
when conducting various types of analysis across different fields. Some key analysis
concepts and principles:
1. Purpose Clarity: Clearly define the purpose and objective of the analysis. Understand
what questions you are trying to answer and what problems you aim to solve. A well-
defined purpose ensures the analysis remains focused and relevant.
2. Data Quality: Ensure that the data used for analysis is accurate, reliable, and
relevant. Poor-quality data can lead to inaccurate conclusions and misleading
insights.
3. Data Pre-processing: This involves cleaning and transforming raw data into a suitable
format for analysis. Data pre-processing may include handling missing values, outlier
detection, normalization, and feature engineering.
4. Exploratory Data Analysis (EDA): Before diving into complex models or advanced
analysis, it's essential to explore the data visually and statistically. EDA helps in
understanding the distribution, patterns, and relationships within the data.
5. Hypothesis Testing: In inferential statistics, hypothesis testing is used to make
inferences about a population based on a sample of data. It involves formulating null
and alternative hypotheses and testing them using statistical methods.
6. Correlation vs. Causation: Understanding the difference between correlation (a
statistical relationship) and causation (a cause-and-effect relationship) is crucial.
Correlation does not necessarily imply causation, and causation requires more
rigorous evidence.
7. Model Selection: When using predictive models or statistical methods, selecting an
appropriate model is essential. Consider factors such as model accuracy, complexity,
interpretability, and generalizability.
8. Bias and Fairness: Be mindful of potential biases in the data and analysis. Analyzing
data with biases may lead to discriminatory or unfair decisions. Strive for fairness and
consider mitigating biases during the analysis.
9. Interpretability: Aim for models and analysis that are interpretable and explainable.
Complex models may provide accurate predictions, but understanding their decision-
making process is equally important, especially in critical applications.
[Link] and Testing: Validate the analysis results and models using appropriate
evaluation metrics and testing methodologies. Cross-validation and hold-out testing
are commonly used techniques.
 [Link] Analysis: Assess the sensitivity of analysis results to changes in input
parameters and assumptions. Sensitivity analysis helps understand the robustness of
findings.
[Link] Making: Present the analysis results in a clear and actionable manner.
Effective communication is vital for decision-makers to understand and use the
insights effectively.
[Link] Improvement: Analysis is an iterative process. Continuously reassess and
improve the analysis approach based on feedback, new data, or changes in the
problem domain.

# Elements of the Analysis Model Data

An analysis model represents the structure and relationships of the data relevant to the
analysis. It is a conceptual representation that aids in understanding the data and its
attributes in the context of the analysis. The elements of the analysis model data typically
include:
1. Data Source: The origin or location from which the data is collected. This could be
databases, files, APIs, or other data repositories.
2. Data Variables: These are the individual attributes or features that describe the data.
For example, in a sales analysis, variables might include "product name," "sales
quantity," "sales revenue," "customer demographics," etc.
3. Data Relationships: The associations or connections between different data
variables. This includes identifying dependent and independent variables and
understanding how they influence each other.
4. Data Format: The structure in which the data is stored, which can be tabular (e.g.,
CSV, Excel), hierarchical (e.g., JSON, XML), or relational (e.g., databases with tables
and columns).
5. Data Units: The units or scale of measurement for each data variable. This could be
numerical (e.g., temperature in degrees Celsius), categorical (e.g., product
categories), or ordinal (e.g., rating scales).
6. Data Granularity: The level of detail at which the data is recorded. This could be
individual transactions, aggregated values, or summarized data.
7. Data Distribution: The pattern of data spread across different values of a variable.
Understanding the distribution helps identify outliers and anomalies.
 8. Data Transformations: Any modifications or preprocessing steps applied to the raw
data to make it suitable for analysis. This could involve normalization, scaling, or
feature engineering.
9. Data Timeframe: The time period covered by the data. It could be historical data or
data collected in real-time.
[Link]: Information about the data itself, including data source, data dictionary,
data version, and any relevant data constraints.

# Modifying the Analysis Model Data:

The analysis model data can be modified throughout the analysis process. Modifications
might include:
1. Data Cleaning: Removing or correcting inaccuracies, duplicates, or missing data to
improve data quality.
2. Feature Engineering: Creating new features or variables derived from existing data to
enhance the analysis.
3. Data Aggregation: Summarizing data to a higher level of granularity for broader
insights.
4. Data Reduction: Selecting a subset of relevant variables to simplify the analysis.
5. Data Integration: Combining data from multiple sources to create a more
comprehensive dataset.
6. Data Sampling: Using a subset of data for analysis, especially in cases of large
datasets to save computational resources.
7. Data Imputation: Filling in missing data points using statistical methods or
imputation techniques.
8. Data Scaling: Scaling numerical variables to bring them to a common scale for certain
types of analyses, like machine learning algorithms.
9. Data Filtering: Applying filters to focus the analysis on specific segments or time
periods.
[Link] Transformation: Applying mathematical or statistical transformations to the
data, like log transformations or power transformations.
It's important to document all modifications made to the analysis model data and consider
the implications of these changes on the final analysis results
# Functional Modeling
Functional modeling is a technique used in systems engineering, software engineering, and
business analysis to represent the functional aspects of a system or process. It aims to
describe the functions or activities performed by the system, their interactions, and the
flow of data or information between them. Functional modeling is essential for
understanding the requirements of a system and for designing or optimizing its
functionality. There are several types of functional modeling techniques, some of which
are:
1. Data Flow Diagrams (DFDs): DFDs represent the flow of data within a system or
process. They consist of processes (functions), data stores (repositories for data),
data flows (movement of data between processes and data stores), and external
entities (sources or sinks of data). DFDs provide a visual representation of how data
moves through the system, helping to identify inputs, outputs, and the relationship
between different components.
2. Functional Flow Block Diagrams (FFBDs): FFBDs illustrate the functional relationships
and hierarchy of components in a system. Each block represents a function or task,
and arrows indicate the flow of data or control between these functions. FFBDs are
commonly used in systems engineering to model the decomposition of complex
systems into subsystems and their interactions.
3. Activity Diagrams: Activity diagrams, part of UML (Unified Modeling Language),
represent the flow of activities or processes in a system. They depict the sequence of
actions, decision points, and concurrency in a process. Activity diagrams are
particularly useful for modeling business processes and software workflows.
4. Business Process Modeling (BPM): BPM is a broader approach that includes various
techniques like flowcharts, process maps, and BPMN (Business Process Model and
Notation) diagrams. BPM aims to model the sequence of activities, decisions, and
interactions within a business process to improve efficiency and identify bottlenecks.
5. Use Case Diagrams: Use case diagrams, another part of UML, illustrate the
interactions between actors (users or external systems) and the system's functions.
They are primarily used for requirements analysis and understanding the system's
behaviour from an end-user perspective.

# Information Flow
Information flow in software engineering refers to the movement of data, information, or
signals within a software system. It involves the understanding and analysis of how data is
generated, processed, and communicated between different components or modules of
the software. Proper management and control of information flow are crucial for ensuring
the correctness, security, and efficiency of software systems.

# Behaviour Modeling
Behaviour modeling refers to the process of representing the behaviour or functionality of
a system or software application. It involves creating models that describe how the system
behaves under various conditions, interactions, and events. Behaviour models help
stakeholders understand how the system will respond to different inputs and scenarios,
leading to better decision-making and system design. There are several commonly used
behaviour modeling techniques in software engineering:
1. Use Case Diagrams: Use case diagrams are part of the Unified Modeling Language
(UML) and represent the interactions between actors (users or external systems) and
the system's functions. They illustrate the various use cases or scenarios in which the
system is used and provide a high-level overview of system behaviour from an end-
user perspective.
2. Activity Diagrams: Activity diagrams in UML depict the flow of activities or processes
in a system. They show the sequence of actions, decision points, and concurrency in a
process, making them useful for modeling business processes and software
workflows.
3. State Transition Diagrams (STDs): STDs model the transitions between different
states of a system or an object. They are particularly useful for systems with discrete
states and events, such as state machines or embedded systems.
4. Sequence Diagrams: Sequence diagrams in UML show the interactions between
different components or objects over time. They illustrate the flow of messages or
method calls between objects and help understand the dynamic behaviour of the
system.
5. Collaboration Diagrams (also known as Communication Diagrams): Collaboration
diagrams visualize the interactions between objects or components in a system. They
emphasize the structural relationships between objects and the messages exchanged
between them.
6. State charts: State charts are an extension of state transition diagrams and provide a
more expressive way to model complex system behaviour. They allow for hierarchical
states, concurrent states, and actions associated with state transitions.
 7. Entity-Relationship Diagrams (ERDs): ERDs model the relationships between entities
(objects or tables) in a database. While primarily used for database design, ERDs can
also capture the behaviour of the system related to data management and data flow.
8. Process Flow Diagrams: Process flow diagrams show the sequence of steps and
decision points in a process or workflow. They are commonly used to model business
processes and illustrate the behaviour of systems that involve multiple steps or
stages.

# Mechanics of Structured Analysis

Structured Analysis is a software engineering technique used to analyse, design, and
document software systems. It focuses on breaking down a complex system into smaller,
manageable modules and defining the relationships and interactions between them. The
mechanics of structured analysis involve a set of principles, techniques, and tools that aid in
understanding and representing the structure and behaviour of the system. Here are the
key mechanics of structured analysis:
1. Data Flow Diagrams (DFDs): DFDs are the central modeling technique in structured
analysis. They represent the flow of data within the system and show how data
moves from one process to another. They provide a clear visual representation of
data movement and processing, helping stakeholders understand the system's
functional requirements.
2. Data Dictionary: The data dictionary is a repository that defines all data elements
used in the system. It provides a detailed description of each data item, including its
name, data type, length, source, and usage. The data dictionary ensures consistency
in data definitions throughout the project and is essential for maintaining data
integrity.
3. Process Specification: Each process in the DFD is further detailed using process
specifications. These specifications describe the logic and algorithms of the
processes. They define the input data, processing steps, and output data for each
process. Process specifications serve as a bridge between the high-level DFDs and the
low-level design.
4. Entity-Relationship Diagrams (ERDs): ERDs are used to model the relationships
between entities (objects or tables) in the system's data. ERDs are especially useful
when designing the database schema and understanding data relationships and
constraints.
 5. Control Specifications: Control specifications describe the control logic within the
system, including decision points and conditions. They represent the decision-making
aspects of the system and help understand the flow of control between different
processes.
6. Modularity: Structured analysis emphasizes the modular decomposition of a system,
dividing it into smaller, independent modules. Modularity helps manage complexity,
allows parallel development, and facilitates maintenance and updates.
7. Hierarchical Structure: The analysis model is organized hierarchically, with the main
DFD representing the entire system and successive levels of DFDs breaking down
processes into finer details. This hierarchical approach simplifies understanding and
managing complex systems.
8. Top-Down Development: Structured analysis follows a top-down development
approach. The high-level requirements and system overview are captured first,
followed by progressively detailed specifications and designs.
9. Functional Decomposition: Functional decomposition involves breaking down the
system's functionality into smaller functional units. Each unit performs a specific task
and contributes to the overall system behaviour.
[Link]: Structured analysis emphasizes comprehensive documentation. This
documentation ensures that all aspects of the analysis, design, and requirements are
clearly documented, making it easier for developers, testers, and stakeholders to
collaborate.

# Data Dictionary
A Data Dictionary is a structured repository that provides a comprehensive description of
the data elements used in a software system or database. It serves as a reference guide for
all data-related information, including data names, definitions, data types, lengths,
allowable values, and relationships between data elements. The Data Dictionary plays a
crucial role in ensuring consistency, accuracy, and clarity in data management,
documentation, and communication across the entire software development lifecycle
Benefits of a Data Dictionary:
1. Consistency: The Data Dictionary ensures that data elements are consistently defined
and used throughout the system, reducing the risk of data redundancy and
ambiguity.
2. Documentation: It serves as a central repository for data-related information,
making it easier for developers, testers, and stakeholders to understand the data
structure and usage.
 3. Collaboration: The Data Dictionary fosters collaboration among project team
members by providing a common understanding of data elements and their
characteristics.
4. Data Integrity: By defining data constraints and allowable values, the Data Dictionary
helps maintain data integrity and accuracy.
5. Efficiency: Having a comprehensive reference for data elements saves time and
effort in understanding data definitions and reduces errors due to misinterpretation.
6. System Maintenance: The Data Dictionary aids in maintaining the system by
providing valuable insights into the data elements affected by changes or updates.
7. Data Security and Privacy: It facilitates the identification of sensitive data elements,
helping enforce proper data security and privacy measures.

# Requirement analysis
Requirements analysis (requirements engineering) is the process of determining user
expectations for a new or modified product. It is usually a team effort and demands a
variety of human soft skills, such as critical thinking, communication and judgment.
Requirements analysis is a common and essential concept in software development and
software project management. At the start of every software project, the project team
must understand, finalize and document the features and functionalities required of the
end product. These required features and functionalities are often called functional
specifications, and the process of determining and understanding them is
called requirements gathering and analysis.
Requirements analysis process
Requirements analysis is a multistage process that involves the following steps.
1. Understand the key stakeholders and end users
In any project, the key stakeholders, including end users, generally have final say on the
project scope. Project teams should identify them early and involve them in the
requirements gathering process from the beginning.
2. Understand the project goal
To capture all necessary requirements, project teams must first understand the project's
objective. What business need drives the project? What problem is the product meant to
solve? By understanding the desired end, the project team can define the problem
statement and have more productive discussions when gathering requirements.
3. Capture requirements
At this stage, all relevant stakeholders provide requirements. This can be done through
one-on-one interviews, focus groups or consideration of use cases. Project teams gather
stakeholder feedback and incorporate it into requirements.
4. Categorize requirements
Categorization of requirements can help with prioritization, impact analysis, feasibility
analysis and conflict resolution. Four common requirements categories are the following:
1. Functional requirements.
2. Technical requirements.
3. Transitional requirements.
4. Operational requirements.
5. Interpret and document requirements
Post-categorization, the project team should analyse its set of requirements to determine
which ones are feasible. Interpretation and analysis are easier when requirements are well
defined and clearly worded. Each requirement should have a clear and understood impact
on the end product and the project plan. After all the requirements have been identified,
prioritized and analysed, project teams should document them in the software
requirements specification (SRS).
6. Finalize SRS and get sign-off on requirements
The SRS should be shared with key stakeholders for sign-off to ensure that they agree with
the requirements. This helps prevent conflicts or disagreements later. Feedback, if any,
should be incorporated. The SRS can then be finalized and made available to the entire
development team. This document provides the foundation for the project's scope and
guides other steps during the software development lifecycle (SDLC), including
development and testing.

# tasks
# analyst
In a software development team, a software analyst is the person who monitors
the software development process, performs configuration management, identifies safety,
performance, and compliance issues, and prepares
software requirements and specification (Software Requirements Specification) documents.

# software prototyping
Software prototyping is an iterative development approach used in software engineering to
create a preliminary version of a software application quickly. The primary purpose of
software prototyping is to gather user feedback early in the development process, allowing
stakeholders to visualize and interact with a working model of the software before
proceeding with full-scale development. Prototyping is particularly useful when
requirements are unclear, complex, or subject to frequent changes. Here are the key
characteristics and benefits of software prototyping:
Characteristics of Software Prototyping:
1. Rapid Development: Prototypes are developed quickly, often using tools that enable
fast and iterative development.
2. User Involvement: Prototypes involve active user participation. Users can interact
with the prototype and provide feedback, which helps refine the requirements.
3. Evolutionary Nature: Prototypes are continuously refined and improved throughout
the development process based on user feedback and changing requirements.
4. Partial Functionality: Prototypes typically focus on key features or specific areas of
the software application, rather than implementing the entire system.
5. Low Fidelity: Prototypes may not have all the bells and whistles of the final product
but serve to demonstrate core functionality.
6. Temporary Solution: Prototypes are not intended for production use but rather as a
means of experimentation and learning.
# specification principles
Specification principles are guidelines and best practices that help ensure the effectiveness,
clarity, and completeness of requirements specifications in software development or any
other engineering domain. Well-defined specifications are crucial for successful project
outcomes, as they serve as a foundation for system design, development, testing, and
verification. Here are some key specification principles:
1. Clarity: Specifications should be clear, concise, and unambiguous. Avoid using vague
language or technical jargon that may lead to misinterpretation.
2. Completeness: Ensure that all relevant requirements are captured in the
specification. Requirements should cover both functional and non-functional aspects
of the system.
3. Consistency: Eliminate conflicts or contradictions within the specifications. Ensure
that the requirements do not contradict each other.
4. Traceability: Establish traceability between requirements and design,
implementation, and test cases. This ensures that each requirement is addressed and
tested appropriately.
5. Verifiability: Make sure that each requirement can be verified through testing or
inspection. Clearly define the criteria for validating each requirement.
6. Feasibility: Ensure that the specified requirements are achievable within the project's
constraints, such as budget, schedule, and available resources.
7. Modularity: Organize requirements into manageable and independent modules or
sections, making it easier to manage and understand the specification.
8. Prioritization: Rank requirements based on their importance and criticality.
Distinguish between "must-have" requirements and "nice-to-have" features.
9. Singular Responsibility: Assign a single owner or stakeholder to each requirement.
This ensures accountability and clear ownership of specific requirements.
[Link]: Identify common requirements that can be reused across different
projects or parts of the system to improve efficiency.
[Link] Control: Maintain version control of the specifications to track changes and
updates throughout the project lifecycle.
[Link] with Stakeholders: Involve stakeholders, including end-users and clients,
in validating and reviewing the specifications to ensure they meet their needs and
expectations.
 [Link] Implementation Details: Keep the focus of the specification on the "what"
rather than the "how." Avoid specifying implementation details that may limit the
creativity of developers.
[Link]: Be prepared for changes in requirements. Use flexible and adaptive
approaches that can accommodate evolving project needs.
[Link] of Formal Methods (if appropriate): In critical or safety-critical systems, consider
using formal methods to mathematically verify the correctness of the specifications.

# representation

# the software requirements specification

A Software Requirements Specification (SRS) is a comprehensive document that serves as a
blueprint for software development. It outlines the functional and non-functional
requirements of the software system to be built, providing a clear and unambiguous
description of what the software should accomplish and how it should behave. The SRS is
typically created during the early stages of the software development process and serves as
a reference throughout the project lifecycle. Here are the key components of a software
requirements specification:
1. Introduction: Provides an overview of the document, including the purpose, scope,
and intended audience of the SRS.
2. Project Overview: Describes the background and context of the software project,
including any existing systems and the need for the new software.
3. Functional Requirements: Describes the specific features and functionalities the
software must have to meet user needs. Each requirement is listed with a unique
identifier and a detailed description of the desired behaviour.
4. Non-Functional Requirements: Specifies the quality attributes and constraints of the
software, such as performance, scalability, security, usability, and regulatory
compliance.
5. User Interfaces: Describes the graphical user interfaces (GUIs) and how users will
interact with the software.
6. Data Requirements: Outlines the data elements, data types, data formats, and data
processing requirements of the software.
7. System Architecture: Provides a high-level overview of the system's architecture,
including the major components and their interactions.
 8. External Interfaces: Describes how the software will interact with external systems,
databases, or third-party components.
9. Assumptions and Dependencies: Lists any assumptions made during the
requirement analysis and the external dependencies that may impact the software.
[Link]: Identifies any limitations or restrictions that may influence the design or
implementation of the software.
[Link] Cases (optional): If use case diagrams are used, this section provides detailed
descriptions of each use case, including preconditions, main flow, alternate flows,
and post-conditions.
[Link]: Includes a glossary of terms and acronyms used in the document to ensure
a common understanding among stakeholders.
[Link] (optional): May include additional information, such as mockups,
diagrams, or reference materials, to support the requirements.
A well-crafted SRS is essential for successful software development as it serves as a contract
between stakeholders and the development team, ensuring that everyone has a shared
understanding of the software's objectives and functionalities. The SRS also provides a basis
for validation and verification activities, guiding testing efforts and ensuring that the final
software meets the specified requirements.
Software Project Planning

A Software Project is the complete methodology of programming advancement from

requirement gathering to testing and support, completed by the execution procedures, in a
specified period to achieve intended software product.

Need of Software Project Management

Software development is a sort of all new streams in world business, and there's next to no
involvement in structure programming items. Most programming items are customized to
accommodate customer's necessities. The most significant is that the underlying technology
changes and advances so generally and rapidly that experience of one element may not be
connected to the other one. All such business and ecological imperatives bring risk in software
development; hence, it is fundamental to manage software projects efficiently.

Software Project Manager

Software manager is responsible for planning and scheduling project development. They manage
the work to ensure that it is completed to the required standard. They monitor the progress to
check that the event is on time and within budget. The project planning must incorporate the
major issues like size & cost estimation scheduling, project monitoring, personnel selection
evaluation & risk management. To plan a successful software project, we must understand:

o Scope of work to be completed

o Risk analysis
o The resources mandatory
o The project to be accomplished
o Record of being followed

Software Project planning starts before technical work start. The various steps of planning
activities are:
Size Estimation

The size is the crucial parameter for the estimation of other activities. Resources requirement are
required based on cost and development time. Project schedule may prove to be very useful for
controlling and monitoring the progress of the project. This is dependent on resources &
development time.

Software Cost Estimation

For any new software project, it is necessary to know how much it will cost to develop and how
much development time will it take. These estimates are needed before development is initiated,
but how is this done? Several estimation procedures have been developed and are having the
following attributes in common.

1. Project scope must be established in advanced.

2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule estimates.
6. Acquire one or more automated estimation tools.

Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers are required for the
project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models

A model may be static or dynamic. In a static model, a single variable is taken as a key element
for calculating cost and time. In a dynamic model, all variable are interdependent, and there is no
basic variable.
Static, Single Variable Models: When a model makes use of single variables to calculate desired
values such as cost, time, efforts, etc. is said to be a single variable model. The most common
equation is:

C=aLb

Where C = Costs
L= size
a and b are constants

The Software Engineering Laboratory established a model called SEL model, for estimating its
software production. This model is an example of the static, single variable model.

E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26

Where E= Efforts (Person Per Month)

DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code

Static, Multivariable Models: These models are based on method (1), they depend on several
variables describing various aspects of the software development environment. In some model,
several variables are needed to describe the software development process, and selected
equation combined these variables to give the estimate of time & cost. These models are called
multivariable models.

WALSTON and FELIX develop the models at IBM provide the following equation gives a
relationship between lines of source code and effort:

E=5.2L0.91

In the same manner duration of development is given by

D=4.1L0.36

The productivity index uses 29 variables which are found to be highly correlated productivity as
follows:

Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the estimator gives Xione of
the values -1, 0 or +1 depending on the variable decreases, has no effect or increases the
productivity.
COCOMO Model
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of
Code. It is a procedural cost estimate model for software projects and is often used as a process
of reliably predicting the various parameters associated with making a project such as size,
effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the
study of 63 projects,

The key parameters

• Effort: Amount of labor that will be required to complete a task. It is measured in

person-months units.
• Schedule: Simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of time
such as weeks, and months.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also
the team members have a nominal experience regarding the problem.

Examples of this type of projects are simple business systems, simple inventory
management systems, and data processing systems.

2. Semi-detached – A software project is said to be a Semi-detached type if the vital

characteristics such as team size, experience, and knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic ones
and require more experience and better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered Semi-Detached types.

Example of Semidetached system includes developing a new operating system (OS), a

Database Management System (DBMS), and complex inventory management system.

3. Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than
the other two models and also the developers need to be sufficiently experienced and creative to
develop such complex models. For Example: ATM, Air Traffic control.
According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project
parameters. The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC)a2 PM
Tdev= b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person months
(PMs).

Estimation of development effort

Software Projects Estimation of development effort Estimation of development time

Organic 2.4 1.05 per month 2.5 0.38 per month

Semi-Detached 3.0 1.12 per month 2.5 0.35 per month

Embedded 3.6 1.20 per month 2.5 0.32 per month

2. Intermediate Model – The basic Cocomo model assumes that the effort is only a function
of the number of lines of code and some constants evaluated according to the different
software systems. However, in reality, no system’s effort and schedule can be solely
calculated on the basis of Lines of Code. For that, various other factors such as reliability,
experience, and Capability. These factors are known as Cost Drivers and the Intermediate
Model utilizes 15 such drivers for cost estimation. Classification of Cost Drivers and their
Attributes:

(i) Product attributes -

o Required software reliability extent

 o Size of the application database
o The complexity of the product

Hardware attributes -

o Run-time performance constraints

o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

3. Detailed Model – Detailed COCOMO incorporates all characteristics of the intermediate

version with an assessment of the cost driver’s impact on each step of the software engineering
process. The detailed model uses different effort multipliers for each cost driver attribute. In
detailed cocomo, the whole software is divided into different modules and then we apply
COCOMO in different modules to estimate effort and then sum the effort. The Six phases of
detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
Advantages of the COCOMO model:

1. Provides a systematic way to estimate the cost and effort of a software project.
2. Can be used to estimate the cost and effort of a software project at different stages of the
development process.
3. Helps in identifying the factors that have the greatest impact on the cost and effort of a
software project.
 4. Can be used to evaluate the feasibility of a software project by estimating the cost and
effort required to complete it.

Disadvantages of the COCOMO model:

1. Assumes that the size of the software is the main factor that determines the cost and effort
of a software project, which may not always be the case.
2. Does not take into account the specific characteristics of the development team, which can
have a significant impact on the cost and effort of a software project.
3. Does not provide a precise estimate of the cost and effort of a software project, as it is
based on assumptions and averages

Putnam Resource Allocation Model

The Lawrence Putnam model describes the time and effort requires finishing a software project of
a specified size. Putnam makes a use of a so-called The Norden/Rayleigh Curve to estimate
project effort, schedule & defect rate as shown in fig:

Putnam noticed that software staffing profiles followed the well known Rayleigh distribution.
Putnam used his observation about productivity levels to derive the software equation:
The various terms of this expression are as follows:

K is the total effort expended (in PM) in product development, and L is the product estimate
in KLOC .

td correlate to the time of system and integration testing. Therefore, td can be relatively
considered as the time required for developing the product.

Ck Is the state of technology constant and reflects requirements that impede the development of
the program.

Typical values of Ck = 2 for poor development environment

Ck= 8 for good software development environment

Ck = 11 for an excellent environment (in addition to following software engineering principles,

automated tools and techniques are used).

The exact value of Ck for a specific task can be computed from the historical data of the
organization developing it.

Effect of a Schedule change on Cost

Now by using the above expression, it is obtained that,

For the same product size, C =L3 / Ck3 is a constant.

(As project development effort is equally proportional to project development cost)

From the above expression, it can be easily observed that when the schedule of a project is
compressed, the required development effort as well as project development cost increases in
proportion to the fourth power of the degree of compression. It means that a relatively small
compression in delivery schedule can result in a substantial penalty of human effort as well as
development cost.
For example, if the estimated development time is 1 year, then to develop the product in 6
months, the total effort required to develop the product (and hence the project cost) increases 16
times.

Risk Identification and Projection

Risk Management is an important part of project planning activities. It involves identifying and
estimating the probability of risks with their order of impact on the project.
Risk Management Steps:
There are some steps that need to be followed in order to reduce risk. These steps are as
follows:
1. Risk Identification:
Risk identification involves brainstorming activities. it also involves the preparation of a risk list.
Brainstorming is a group discussion technique where all the stakeholders meet together. this
technique produces new ideas and promotes creative thinking.
Preparation of risk list involves identification of risks that are occurring continuously in previous
software projects.
2. Risk Analysis and Prioritization:
It is a process that consists of the following steps:

• Identifying the problems causing risk in projects

• Identifying the probability of occurrence of problem
• Identifying the impact of problem
• Assigning values to step 2 and step 3 in the range of 1 to 10
• Calculate the risk exposure factor which is the product of values of step 2 and step 3
• Prepare a table consisting of all the values and order risk on the basis of risk exposure
factor
3. Risk Avoidance and Mitigation:
The purpose of this technique is to altogether eliminate the occurrence of risks. so the method
to avoid risks is to reduce the scope of projects by removing non-essential requirements.
4. Risk Monitoring:
In this technique, the risk is monitored continuously by reevaluating the risks, the impact of risk,
and the probability of occurrence of the risk.
This ensures that:

• Risk has been reduced

• New risks are discovered
• Impact and magnitude of risk are measured
Risk Mitigation, Monitoring, and Management (RMMM) plan

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

Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is done by Project
manager when risk becomes reality and causes severe problems. If the project manager
effectively uses project mitigation to remove risks successfully then it is easier to manage the
risks. This shows that the response that will be taken for each risk by a manager. The main
objective of the risk management plan is the risk register. This risk register describes and
focuses on the predicted threats to a software project.

Drawbacks of RMMM:
• It incurs additional project costs.
• It takes additional time.
• For larger projects, implementing an RMMM may itself turn out to be another tedious
project.
• RMMM does not guarantee a risk-free project, infact, risks may also come up after the
project is delivered.
Project Scheduling

Project-task scheduling is a significant project planning activity. It comprises deciding which

functions would be taken up when. To schedule the project plan, a software project manager wants
to do the following:

1. Identify all the functions required to complete the project.

2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
 5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the duration
of the project.

-For long question type answer-

1. Project Initiation:

• Define the project scope and objectives, including the software product's features and
functionalities.
• Identify the stakeholders, project team members, and their roles and responsibilities.
• Establish a clear understanding of the project's constraints, such as budget, time, and
resources.

2. Work Breakdown Structure (WBS):

• Decompose the project into smaller, manageable tasks and create a hierarchical structure
called the Work Breakdown Structure (WBS).
• Each task in the WBS should be well-defined, specific, and achievable.

3. Task Estimation:

• Assign time and effort estimates to each task. Use historical data, expert judgment, and
other estimation techniques like analogies or parametric models to derive these estimates.

4. Task Sequencing:

• Determine the dependencies among tasks. Some tasks might be sequential, where one
task must finish before another starts, while others may be concurrent, allowing for parallel
execution.

5. Network Diagram:

• Create a network diagram (e.g., PERT chart or Gantt chart) that visually represents the
sequence and dependencies of tasks. This helps in understanding the project's critical path
and identifying potential bottlenecks.

6. Resource Allocation:

• Allocate the necessary resources (e.g., developers, testers, equipment) to each task based
on their availability and skillsets.

7. Project Schedule:
 • Generate a project schedule that includes start and end dates for each task, resource
assignments, and milestones.

8. Risk Management:

• Identify potential risks and plan mitigation strategies. Unforeseen risks can affect the
project schedule, so it's crucial to be prepared.

9. Execution and Tracking:

• As the project progresses, update the project schedule with the actual start and finish
dates of completed tasks.
• Track the progress of each task, comparing actual progress against the planned schedule.
• Identify any deviations and take corrective actions as needed.

10. Communication and Reporting:

• Regularly communicate the project status to stakeholders, team members, and

management.
• Provide reports and visualizations (e.g., burndown charts, progress graphs) to keep
everyone informed about the project's health.

11. Change Management:

• Be prepared for changes in project scope or requirements. Evaluate the impact of changes
on the schedule, budget, and resources before incorporating them.

12. Project Closure:

• Once all tasks are completed, conduct a project review to learn from successes and
challenges for future projects.
• Celebrate the team's achievements and close out any administrative tasks.

Software Design Process

In software development, tools such as project management software, version control systems,
and collaboration platforms are often used to aid in project scheduling and tracking. These tools
help streamline communication, manage tasks, and provide real-time updates on project
progress.

The design phase of software development deals with transforming the customer requirements
as described in the SRS documents into a form implementable using a programming language.
The software design process can be divided into the following three levels of phases of design:
 1. Interface Design
2. Architectural Design
3. Detailed Design

Interface Design: Interface design is the specification of the interaction between a system and
its environment. this phase proceeds at a high level of abstraction with respect to the inner
workings of the system i.e, during interface design, the internal of the systems are completely
ignored and the system is treated as a black box. Attention is focused on the dialogue between
the target system and the users, devices, and other systems with which it interacts. The design
problem statement produced during the problem analysis step should identify the people,
other systems, and devices which are collectively called agents.
Architectural Design: Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the relationships and interactions
between them. In architectural design, the overall structure of the system is chosen, but the
internal details of major components are ignored.

Detailed Design: Design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their algorithms and the data
structures.

Software Design Principles

Software design principles are concerned with providing means to handle the complexity of the
design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant problem, divide
the problems and conquer the problem it means to divide the problem into smaller pieces so that
each piece can be captured separately.

Benefits of Problem Partitioning

Software is easy to understand, becomes simple, easy to test, modify, maintain, and expand.

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing
element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of the
function.

Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

Modularity

Modularity specifies to the division of software into separate modules which are differently named
and addressed and are integrated later on in to obtain the completely functional software. It is the
only property that allows a program to be intellectually manageable. Single large programs are
difficult to understand and read due to a large number of reference variables, control paths, global
variables, etc.

Advantages of Modularity

o It allows large programs to be written by several or different people

o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

Disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system.

Strategy of Design

A good system design strategy is to organize the program modules in such a method that are easy
to develop and latter too, change. Structured design methods help developers to deal with the size
and complexity of programs. Analysts generate instructions for the developers about how code
should be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components and
then decomposing them into their more detailed sub-components.
2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards
up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

Software Design Concepts:

Software design concepts are fundamental principles and guidelines used to create effective,
maintainable, and scalable software systems. Let's explore three essential software design
concepts: Effective Modular Design, Design Heuristics, and Design Documentation.

1. Effective Modular Design: Effective modular design is a design principle that advocates
breaking down a software system into smaller, self-contained modules or components. Each
module should have a specific, well-defined purpose and interface, making it easier to
understand, maintain, and modify the system. Key characteristics of effective modular design
include:

• High Cohesion: Modules should be cohesive, meaning each module should have a single,
well-defined responsibility or function. Cohesion ensures that each module is focused on
performing a specific task, making the code more readable and maintainable.

• Low Coupling: Modules should be loosely coupled, which means they should be relatively
independent of each other. This reduces interdependencies between modules and allows
for easier changes or replacements without affecting other parts of the system.

• Encapsulation: Modules should hide their internal implementation details and expose only
the necessary interfaces. Encapsulation helps to manage complexity and reduces the risk of
unintended side effects when modifying modules.

• Reuse: Modular design promotes code reuse. Well-designed modules can be easily reused
in different parts of the software system, reducing development time and effort.

2. Design Heuristics: Design heuristics are guiding principles and rules of thumb that aid
designers in making informed decisions during the software design process. These heuristics are
not strict rules but rather best practices based on experience and knowledge. Using design
heuristics helps create more maintainable and flexible software systems that can adapt to future
changes and requirements. Some common design heuristics include:
 • Single Responsibility Principle (SRP): A class or module should have only one reason to
change, focusing on a single responsibility or task.

• Open-Closed Principle (OCP): Software entities (classes, modules) should be open for
extension but closed for modification, encouraging the use of inheritance or interfaces to
add new functionality.

• Liskov Substitution Principle (LSP): Objects of a base class should be replaceable with
objects of its derived classes without affecting the correctness of the program.

• Interface Segregation Principle (ISP): Clients should not be forced to depend on

interfaces they do not use, advocating the use of specific, focused interfaces.

• Dependency Inversion Principle (DIP): High-level modules should not depend on low-
level modules. Both should depend on abstractions.

3. Design Documentation: Design documentation is a crucial part of the software development

process. It includes detailed information about the software system's architecture, design
decisions, and implementation. Design documentation can take various forms, such as
architectural diagrams, flowcharts, data flow diagrams, entity-relationship diagrams, and textual
explanations of design decisions.

Design documentation serves several purposes:

• Communication: It allows stakeholders, developers, and team members to understand the

software's structure and design rationale, facilitating collaboration.

• Maintenance: Design documentation aids in maintaining and troubleshooting the system

by providing insights into its design and functionality.

• Knowledge Transfer: When new team members join a project, design documentation
helps them get up to speed quickly.

• Compliance and Standards: Some industries or organizations require formal design

documentation to comply with regulations or standards.

Design Methods:

Data design

Data design is a crucial aspect of software design, focusing on how data is structured, stored, and
accessed within the software application. It involves designing data models, databases, and data
manipulation processes to ensure efficient and reliable data management. Here are some key
aspects of data design:

1. Data Modeling: Data modeling is the process of creating abstract representations of the
data entities, attributes, and relationships within the software system.

2. Database Design: Database design involves designing the physical structure of the
database to efficiently store and retrieve data. Key considerations in database design include:

3. Data Manipulation: Data design involves specifying how data is manipulated and
processed within the software system. This includes defining data validation rules, data
transformation processes, and data storage mechanisms.
4. Data Security: Data design also addresses data security concerns. It involves implementing
access controls, encryption, and other security measures to protect sensitive data from
unauthorized access and manipulation.
5. Data Integration: Data design may also encompass integrating data from various sources or
external systems. This includes defining data mapping and transformation rules to ensure
seamless data exchange between different components.
6. Data Storage and Retrieval: Data design includes decisions about the storage format and
structure of data to optimize storage and retrieval efficiency. This may involve choosing
appropriate data storage technologies and data access methods.
7. Data Backup and Recovery: Designing data backup and recovery mechanisms to safeguard
against data loss in case of hardware failures or other catastrophic events.

Architectural Design-

architectural design as “the process of defining a collection of hardware and software

components and their interfaces to establish the framework for the development of a computer
system.” The software that is built for computer-based systems can exhibit one of these many
architectural styles.

1] Data centered architectures:

• A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete or modify the data present within the store.

• The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach are used to transform the repository into a
blackboard when data related to client or data of interest for the client change the
notifications to client software.

• This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.

• Data can be passed among clients using blackboard mechanism.

2] Data flow architectures:

 • This kind of architecture is used when input data is transformed into output data through a
series of computational manipulative components.

• The figure represents pipe-and-filter architecture since it uses both pipe and filter and it
has a set of components called filters connected by lines.

• Pipes are used to transmitting data from one component to the next.

• Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.

• If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

3] Call and Return architectures: It is used to create a program that is easy to scale and modify.
Many sub-styles exist within this category. Two of them are below.

Remote procedure call architecture

Main program architectures

4] Object Oriented architecture: The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The coordination and communication
between the components are established via the message passing.

5] Layered architecture:

• A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine instruction
set progressively.

• At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS)

• Intermediate layers to utility services and application software functions.

• One common example of this architectural style is OSI-ISO (Open Systems

Interconnection-International Organisation for Standardisation) communication system.

Human Computer Interface Design

User interface is the front-end application view to which user interacts in order to use the
software. The software becomes more popular if its user interface is:

• Attractive

• Simple to use

• Responsive in short time

• Clear to understand

• Consistent on all interface screens

There are two types of User Interface:

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

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

User Interface Design Process:

The analysis and design process of a user interface is iterative and can be represented by a spiral
model. The analysis and design process of user interface consists of four framework activities.

1. User, task, environmental analysis, and modeling: Initially, the focus is based on the
profile of users who will interact with the system, i.e. understanding, skill and knowledge,
type of user, etc, based on the user’s profile users are made into categories. From each
category requirements are gathered. Based on the requirements developer understand
how to develop the interface. Once all the requirements are gathered a detailed analysis is
conducted. In the analysis part, the tasks that the user performs to establish the goals of
the system are identified, described and elaborated. The analysis of the user environment
focuses on the physical work environment. Among the questions to be asked are:

• Where will the interface be located physically?

• Will the user be sitting, standing, or performing other tasks unrelated to the
interface?

• Does the interface hardware accommodate space, light, or noise constraints?

• Are there special human factors considerations driven by environmental factors?

2. Interface Design: The goal of this phase is to define the set of interface objects and
actions i.e. Control mechanisms that enable the user to perform desired tasks. Indicate how
these control mechanisms affect the system. Specify the action sequence of tasks and
subtasks, also called a user scenario. Indicate the state of the system when the user
performs a particular task. Always follow the three golden rules stated by Theo Mandel.
Design issues such as response time, command and action structure, error handling, and
 help facilities are considered as the design model is refined. This phase serves as the
foundation for the implementation phase.

3. Interface construction and implementation: The implementation activity begins with the
creation of prototype (model) that enables usage scenarios to be evaluated. As iterative
design process continues a User Interface toolkit that allows the creation of windows,
menus, device interaction, error messages, commands, and many other elements of an
interactive environment can be used for completing the construction of an interface.

4. Interface Validation: This phase focuses on testing the interface. The interface should be
in such a way that it should be able to perform tasks correctly and it should be able to
handle a variety of tasks. It should achieve all the user’s requirements. It should be easy to
use and easy to learn. Users should accept the interface as a useful one in their work.

Procedural Design

• Procedural design is used to model programs that have an obvious flow of data from input
to output.

• It represents the architecture of a program as a set of interacting processes that pass data
from one to another.

• Procedural design is also called component design. It is completely based on process and
control specifications.

• The “state transition diagram” of the requirements analysis model is also used in
component design.

• Component design is usually done after user interface design.

• The component-level design depicts the software at a level of abstraction that is very close
to the code.

• At the component level, the software engineer must represent data structures, interfaces,
and algorithms in sufficient detail to guide the generation of programming language
source code.

Case Study for Design of any Application Project : Design of an E-Commerce

Application

Case Study: Design of an E-Commerce Application

1. Introduction: In this case study, we will focus on designing the architecture of an e-commerce
application. The goal is to create a scalable, user-friendly, and secure platform for online
shopping.

2. Requirements Analysis: The initial step involves gathering and analyzing the requirements for
the e-commerce application. Key requirements include user registration and authentication,
product browsing, shopping cart functionality, order processing, payment integration, and an
admin panel to manage products and orders.
3. Architectural Design:

a. High-Level Architecture: The e-commerce application will follow a three-tier architecture:

1. Presentation Layer:

• The user interface will be developed using HTML, CSS, and JavaScript, providing a
responsive and intuitive shopping experience.

• User interactions will be handled by a frontend framework like React or Angular.

2. Application Layer:

• The application layer will consist of server-side code responsible for processing requests,
handling business logic, and interacting with the database.

• [Link] or Python with a framework like Express or Django will be used for building the
application layer.

3. Data Layer:

• The data layer will manage the storage and retrieval of data.

• A relational database like MySQL or PostgreSQL will be used to store product details, user
information, and order history.

b. Detailed Component Design:

1. User Authentication Component:

• Responsible for user registration, login, and password recovery.

• Utilizes secure authentication mechanisms like OAuth or JWT (JSON Web Tokens).

• Integrates with the database to store and retrieve user information.

2. Product Catalog Component:

• Manages the catalog of products available for sale.

• Allows users to search, filter, and view product details.

• Connects to the database to fetch product information.

3. Shopping Cart Component:

• Tracks items added by the user for purchase.

• Handles item quantities, updates, and removals.

• Utilizes cookies or local storage to maintain the cart state.

4. Order Processing Component:

• Manages the processing of orders placed by users.

• Handles inventory updates and stock management.

• Sends order confirmation emails to users.

5. Payment Integration Component:

• Integrates with a secure payment gateway (e.g., Stripe, PayPal) to process payments.

• Ensures encryption and security for sensitive user data.

6. Admin Panel Component:

• Provides an admin interface for managing products, orders, and user accounts.

• Requires authentication and authorization for admin users.

4. Security Considerations:

• Secure authentication and authorization mechanisms to prevent unauthorized access.

• Use of HTTPS to secure data transmission.

5. Scalability:

• Use of caching mechanisms to reduce database load and improve performance.

• Horizontal scaling by deploying multiple instances of the application behind a load

balancer.

6. User Experience (UX):

• Intuitive and user-friendly interface for easy navigation and seamless shopping.

• Responsive design to support various devices and screen sizes.

7. Testing Strategy:

• Unit testing for individual components.

• Integration testing to verify interactions between components.

• End-to-end testing to simulate user interactions and scenarios.

8. Design Documentation:

• Detailed architectural diagrams (e.g., high-level architecture, component diagrams).

• API documentation for frontend-backend communication.

• Database schema documentation.

9. Future Enhancements:

• Implementation of recommendation engines based on user behavior.

• Integration with third-party logistics for efficient order fulfillment.

• Mobile application development to expand the reach to mobile users.

10. Conclusion: In this case study, we designed the architecture for an e-commerce application,
considering scalability, security, and user experience. The implementation of this design will
provide a robust platform for online shopping, meeting the requirements of modern e-commerce
customers.
 Software Testing
Software testing is widely used technology because it is compulsory to test each and every software
before deployment.

Software testing is a process of identifying the correctness of software by considering its all attributes
(Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the execution of software
components to find the software bugs or errors or defects.

Software testing provides an independent view and objective of the software and gives surety of fitness
of the software. It involves testing of all components under the required services to confirm that whether
it is satisfying the specified requirements or not. The process is also providing the client with information
about the quality of the software.

Testing is mandatory because it will be a dangerous situation if the software fails any of time due to lack
of testing. So, without testing software cannot be deployed to the end user.

Type of Software testing

We have various types of testing available in the market, which are used to test the application or the
software.
Manual testing
The process of checking the functionality of an application as per the customer needs without taking any
help of automation tools is known as manual testing. While performing the manual testing on any
application, we do not need any specific knowledge of any testing tool, rather than have a proper
understanding of the product so we can easily prepare the test document.

Manual testing can be further divided into three types of testing, which are as follows:

o White box testing

o Black box testing
o Gray box testing

Automation testing
Automation testing is a process of converting any manual test cases into the test scripts with the help of
automation tools, or any programming language is known as automation testing. With the help of
automation testing, we can enhance the speed of our test execution because here, we do not require any
human efforts. We need to write a test script and execute those scripts.

White box Testing

White box testing techniques analyze the internal structures the used data structures, internal design,
code structure, and the working of the software rather than just the functionality as in black box testing.
It is also called glass box testing or clear box testing or structural testing. White Box Testing is also known
as transparent testing or open box testing.
White box testing is a software testing technique that involves testing the internal structure and workings
of a software application. The tester has access to the source code and uses this knowledge to design
test cases that can verify the correctness of the software at the code level.

White box testing is also known as structural testing or code-based testing, and it is used to test the
software’s internal logic, flow, and structure. The tester creates test cases to examine the code paths and
logic flows to ensure they meet the specified requirements.

Working process of white box testing:

 Input: Requirements, Functional specifications, design documents, source code.
 Processing: Performing risk analysis to guide through the entire process.
 Proper test planning: Designing test cases so as to cover the entire code. Execute rinse-
repeat until error-free software is reached. Also, the results are communicated.
 Output: Preparing final report of the entire testing process.

Testing techniques:
 Statement coverage: In this technique, the aim is to traverse all statements at least once.
Hence, each line of code is tested. In the case of a flowchart, every node must be traversed
at least once. Since all lines of code are covered, helps in pointing out faulty code.

Statement Coverage Example

 Branch Coverage: In this technique, test cases are designed so that each branch from all
decision points is traversed at least once. In a flowchart, all edges must be traversed at least
once.
 4 test cases are required such that all branches of all decisions are covered, i.e, all edges of the flowchart are covered

 Condition Coverage: In this technique, all individual conditions must be covered as shown
in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
4. #TC1 – X = 0, Y = 55
5. #TC2 – X = 5, Y = 0
 Multiple Condition Coverage: In this technique, all the possible combinations of the
possible outcomes of conditions are tested at least once. Let’s consider the following
example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
4. #TC1: X = 0, Y = 0
5. #TC2: X = 0, Y = 5
6. #TC3: X = 55, Y = 0
7. #TC4: X = 55, Y = 5
 Basis Path Testing: In this technique, control flow graphs are made from code or flowchart
and then Cyclomatic complexity is calculated which defines the number of independent
paths so that the minimal number of test cases can be designed for each independent
path. Steps:
1. Make the corresponding control flow graph
2. Calculate the cyclomatic complexity
3. Find the independent paths
4. Design test cases corresponding to each independent path
5. V(G) = P + 1, where P is the number of predicate nodes in the flow graph
6. V(G) = E – N + 2, where E is the number of edges and N is the total number of nodes
 7. V(G) = Number of non-overlapping regions in the graph
8. #P1: 1 – 2 – 4 – 7 – 8
9. #P2: 1 – 2 – 3 – 5 – 7 – 8
10. #P3: 1 – 2 – 3 – 6 – 7 – 8
11. #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8
 Loop Testing: Loops are widely used and these are fundamental to many algorithms hence,
their testing is very important. Errors often occur at the beginnings and ends of loops.
1. Simple loops: For simple loops of size n, test cases are designed that:
 Skip the loop entirely
 Only one pass through the loop
 2 passes
 m passes, where m < n
 n-1 ans n+1 passes
2. Nested loops: For nested loops, all the loops are set to their minimum count and we
start from the innermost loop. Simple loop tests are conducted for the innermost loop
and this is worked outwards till all the loops have been tested.
3. Concatenated loops: Independent loops, one after another. Simple loop tests are
applied for each. If they’re not independent, treat them like nesting.

White Testing is Performed in 2 Steps:

1. Tester should understand the code well
2. Tester should write some code for test cases and execute them

Features of white box testing:

1. Code coverage analysis: White box testing helps to analyze the code coverage of an
application, which helps to identify the areas of the code that are not being tested.
2. Access to the source code: White box testing requires access to the application’s source code,
which makes it possible to test individual functions, methods, and modules.
3. Knowledge of programming languages: Testers performing white box testing must have
knowledge of programming languages like Java, C++, Python, and PHP to understand the
code structure and write tests.
4. Identifying logical errors: White box testing helps to identify logical errors in the code, such
as infinite loops or incorrect conditional statements.
5. Integration testing: White box testing is useful for integration testing, as it allows testers to
verify that the different components of an application are working together as expected.
6. Unit testing: White box testing is also used for unit testing, which involves testing individual
units of code to ensure that they are working correctly.
7. Optimization of code: White box testing can help to optimize the code by identifying any
performance issues, redundant code, or other areas that can be improved.
8. Security testing: White box testing can also be used for security testing, as it allows testers
to identify any vulnerabilities in the application’s code.

Advantages:
1. White box testing is thorough as the entire code and structures are tested.
2. It results in the optimization of code removing errors and helps in removing extra lines of
code.
3. It can start at an earlier stage as it doesn’t require any interface as in the case of black box
testing.
4. Easy to automate.
5. White box testing can be easily started in Software Development Life Cycle.
6. Easy Code Optimization.
Disadvantages:
1. It is very expensive.
2. Redesigning code and rewriting code needs test cases to be written again.
3. Testers are required to have in-depth knowledge of the code and programming language
as opposed to black-box testing.
4. Missing functionalities cannot be detected as the code that exists is tested.
5. Very complex and at times not realistic.
6. Much more chances of Errors in production.

Black box testing

Black-box testing is a type of software testing in which the tester is not concerned with the
internal knowledge or implementation details of the software, but rather focuses on validating
the functionality based on the provided specifications or requirements.

Black box testing can be done in the following ways:

1. Syntax-Driven Testing – This type of testing is applied to systems that can be syntactically
represented by some language. For example- compilers, language that can be represented by
context-free grammar. In this, the test cases are generated so that each grammar rule is used at
least once.
2. Equivalence partitioning – It is often seen that many types of inputs work similarly so instead
of giving all of them separately we can group them and test only one input of each group. The
idea is to partition the input domain of the system into several equivalence classes such that each
member of the class works similarly, i.e., if a test case in one class results in some error, other
members of the class would also result in the same error.
The technique involves two steps:
1. Identification of equivalence class – Partition any input domain into a minimum of two
sets: valid values and invalid values. For example, if the valid range is 0 to 100 then select
one valid input like 49 and one invalid like 104.
2. Generating test cases –
(i) To each valid and invalid class of input assign a unique identification number.
(ii) Write a test case covering all valid and invalid test cases considering that no two invalid
inputs mask each other. To calculate the square root of a number, the equivalence classes
will be (a) Valid inputs:
 The whole number which is a perfect square- output will be an integer.
 The whole number which is not a perfect square- output will be a decimal number.
 Positive decimals
 Negative numbers(integer or decimal).
  Characters other than numbers like “a”,”!”,”;”, etc.
3. Boundary value analysis – Boundaries are very good places for errors to occur. Hence if test
cases are designed for boundary values of the input domain then the efficiency of testing
improves and the probability of finding errors also increases. For example – If the valid range is
10 to 100 then test for 10,100 also apart from valid and invalid inputs.
4. Cause effect Graphing – This technique establishes a relationship between logical input called
causes with corresponding actions called the effect. The causes and effects are represented using
Boolean graphs. The following steps are followed:
1. Identify inputs (causes) and outputs (effect).
2. Develop a cause-effect graph.
3. Transform the graph into a decision table.
4. Convert decision table rules to test cases.
For example, in the following cause-effect graph:

It can be converted into a decision table like:

Each column corresponds to a rule which will become a test case for testing. So there will be 4
test cases.
5. Requirement-based testing – It includes validating the requirements given in the SRS of a
software system.
6. Compatibility testing – The test case result not only depends on the product but is also on
the infrastructure for delivering functionality. When the infrastructure parameters are changed it
is still expected to work properly. Some parameters that generally affect the compatibility of
software are:
1. Processor (Pentium 3, Pentium 4) and several processors.
2. Architecture and characteristics of machine (32-bit or 64-bit).
3. Back-end components such as database servers.
4. Operating System (Windows, Linux, etc).

Black Box Testing Type

The following are the several categories of black box testing:
1. Functional Testing
2. Regression Testing
3. Nonfunctional Testing (NFT)

Functional Testing: It determines the system’s software functional requirements.

Regression Testing: It ensures that the newly added code is compatible with the existing code.
In other words, a new software update has no impact on the functionality of the software. This
is carried out after a system maintenance operation and upgrades.
Nonfunctional Testing: Nonfunctional testing is also known as NFT. This testing is not
functional testing of software. It focuses on the software’s performance, usability, and
scalability.

Features of black box testing:

1. Independent testing: Black box testing is performed by testers who are not involved in the
development of the application, which helps to ensure that testing is unbiased and impartial.
2. Testing from a user’s perspective: Black box testing is conducted from the perspective of
an end user, which helps to ensure that the application meets user requirements and is easy
to use.
3. No knowledge of internal code: Testers performing black box testing do not have access
to the application’s internal code, which allows them to focus on testing the application’s
external behavior and functionality.
4. Requirements-based testing: Black box testing is typically based on the application’s
requirements, which helps to ensure that the application meets the required specifications.
5. Different testing techniques: Black box testing can be performed using various testing
techniques, such as functional testing, usability testing, acceptance testing, and regression
testing.
6. Easy to automate: Black box testing is easy to automate using various automation tools,
which helps to reduce the overall testing time and effort.
7. Scalability: Black box testing can be scaled up or down depending on the size and
complexity of the application being tested.
8. Limited knowledge of application: Testers performing black box testing have limited
knowledge of the application being tested, which helps to ensure that testing is more
representative of how the end users will interact with the application.
Advantages of Black Box Testing:
 The tester does not need to have more functional knowledge or programming skills to
implement the Black Box Testing.
 It is efficient for implementing the tests in the larger system.
 Tests are executed from the user’s or client’s point of view.
 Test cases are easily reproducible.
 It is used in finding the ambiguity and contradictions in the functional specifications.
Disadvantages of Black Box Testing:
 There is a possibility of repeating the same tests while implementing the testing process.
 Without clear functional specifications, test cases are difficult to implement.
 It is difficult to execute the test cases because of complex inputs at different stages of
testing.
 Sometimes, the reason for the test failure cannot be detected.
 Some programs in the application are not tested.
 It does not reveal the errors in the control structure.
 Working with a large sample space of inputs can be exhaustive and consumes a lot of time.

Verification and Validation Testing

Verification testing
Verification testing includes different activities such as business requirements, system requirements,
design review, and code walkthrough while developing a product.

It is also known as static testing, where we are ensuring that "we are developing the right product or
not". And it also checks that the developed application fulfilling all the requirements given by the client.

Validation testing
Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing (UT), Integration Testing (IT) and System Testing (ST),
and non-functional testing includes User acceptance testing (UAT).
Validation testing is also known as dynamic testing, where we are ensuring that "we have developed
the product right." And it also checks that the software meets the business needs of the client.

Difference between verification and validation testing

Verification Validation

We check whether we are developing the right We check whether the developed product is right.
product or not.

Verification is also known as static testing. Validation is also known as dynamic testing.

Verification includes different methods like Validation includes testing like functional testing,
Inspections, Reviews, and Walkthroughs. system testing, integration, and User acceptance
testing.

It is a process of checking the work-products (not the It is a process of checking the software during or at the
final product) of a development cycle to decide end of the development cycle to decide whether the
whether the product meets the specified software follow the specified business requirements.
requirements.

Quality assurance comes under verification testing. Quality control comes under validation testing.

The execution of code does not happen in the In validation testing, the execution of code happens.
verification testing.

In verification testing, we can find the bugs early in In the validation testing, we can find those bugs, which
the development phase of the product. are not caught in the verification process.
 Verification testing is executed by the Quality Validation testing is executed by the testing team to test
assurance team to make sure that the product is the application.
developed according to customers' requirements.

Verification is done before the validation testing. After verification testing, validation testing takes place.

In this type of testing, we can verify that the inputs In this type of testing, we can validate that the user
follow the outputs or not. accepts the product or not.

Test Strategy
A high-level document is used to validate the test types or levels to be executed for the product and
specify the Software Development Life Cycle's testing approach is known as Test strategy document.

Once the test strategy has been written, we cannot modify it, and it is approved by the Project Manager,
development team.

The test strategy also specifies the following details, which are necessary while we write the test
document:
o What is the other procedure having to be used?
o Which module is going to be tested?
o Which entry and exit criteria apply?
o Which type of testing needs to be implemented?

In other words, we can say that it is a document, which expresses how we go about testing the product.
And the approaches can be created with the help of following aspects:
o Automation or not
o Resource point of view

We can write the test strategy based on development design documents.

The development design document includes the following documents:

o System design documents: Primarily, we will use these documents to write the test strategy.
o Design documents: These documents are used to specify the software's functionality to be enabled in the
upcoming release.
o Conceptual design documents: These are the document which we used Infrequently.

Components of Test Strategy Document

We understand that the test strategy document is made during the requirements phase and after the
requirements have been listed.
Like other testing documents, the test strategy document also includes various components, such as:

o Scope and Overview

o Testing Methodology
o Testing Environment Specifications
o Testing Tools
o Release Control
o Risk Analysis
o Review and Approvals

Types of Test Strategies

Here, we are discussing some of the significant types of test strategies document:
 o Methodical strategy
o Reactive strategy
o Analytical strategy
o Standards compliant or Process compliant strategy
o Model-based strategy
o Regression averse strategy
o Consultative strategy

Unit Testing
Unit testing involves the testing of each unit or an individual component of the software application. It is
the first level of functional testing. The aim behind unit testing is to validate unit components with its
performance.

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

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

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

Why Unit Testing?

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

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

Some crucial reasons are listed below:

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

Integration testing
Integration testing is the second level of the software testing process comes after unit testing. In this
testing, units or individual components of the software are tested in a group. The focus of the integration
testing level is to expose defects at the time of interaction between integrated components or units.

Unit testing uses modules for testing purpose, and these modules are combined and tested in integration
testing. The Software is developed with a number of software modules that are coded by different coders
or programmers. The goal of integration testing is to check the correctness of communication among all
the modules.

Once all the components or modules are working independently, then we need to check the data flow
between the dependent modules is known as integration testing.

Guidelines for Integration Testing

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

Reason Behind Integration Testing

Although all modules of software application already tested in unit testing, errors still exist due to the
following reasons:

1. Each module is designed by individual software developer whose programming logic may differ from
developers of other modules so; integration testing becomes essential to determine the working of software
modules.
2. To check the interaction of software modules with the database whether it is an erroneous or not.
3. Requirements can be changed or enhanced at the time of module development. These new requirements
may not be tested at the level of unit testing hence integration testing becomes mandatory.
4. Incompatibility between modules of software could create errors.
5. To test hardware's compatibility with software.
6. If exception handling is inadequate between modules, it can create bugs.

Integration Testing Techniques

Any testing technique (Blackbox, Whitebox, and Greybox) can be used for Integration Testing; some are
listed below:

Black Box Testing

o State Transition technique
o Decision Table Technique
o Boundary Value Analysis
o All-pairs Testing
o Cause and Effect Graph
o Equivalence Partitioning
o Error Guessing
White Box Testing
o Data flow testing
o Control Flow Testing
o Branch Coverage Testing
o Decision Coverage Testing

Types of Integration Testing

Integration testing can be classified into two parts:

o Incremental integration testing

o Non-incremental integration testing

System Testing
System Testing includes testing of a fully integrated software system. Generally, a computer system
consists of a group of software to perform the various tasks, but only software cannot perform the task;
for that software must be interfaced with compatible hardware. System testing is a series of different type
of tests with the purpose to exercise and examine the full working of an integrated software computer
system against requirements.

To check the end-to-end flow of an application or the software as a user is known as System testing. In
this, we navigate (go through) all the necessary modules of an application and check if the end features
or the end business works fine, and test the product as a whole system.

It is end-to-end testing where the testing environment is similar to the production environment.
There are four levels of software testing: unit testing, integration testing, system testing and acceptance
testing, all are used for the testing purpose. Unit Testing used to test a single software; Integration Testing
used to test a group of units of software, System Testing used to test a whole system and Acceptance
Testing used to test the acceptability of business requirements. Here we are discussing system testing
which is the third level of testing levels.

Hierarchy of Testing Levels

System testing falls under Black box testing as it includes testing of the external working of the
software. Testing follows user's perspective to identify minor defects.

System Testing includes the following steps.

o Verification of input functions of the application to test whether it is producing the expected output or not.
o Testing of integrated software by including external peripherals to check the interaction of various
components with each other.
o Testing of the whole system for End to End testing.
o Behavior testing of the application via auser's experience
Types of System Testing
System testing is divided into more than 50 types, but software testing companies typically uses some of
them. These are listed below:

1. Regression Testing
2. Load Testing
3. Functional Testing
4. Recovery Testing
5. Migration Testing
6. Usability Testing
7. Software and Hardware Testing

Debugging

In the development process of any software, the software program is religiously tested, troubleshot, and
maintained for the sake of delivering bug-free products. There is nothing that is error-free in the first go.

So, it's an obvious thing to which everyone will relate that as when the software is created, it contains a
lot of errors; the reason being nobody is perfect and getting error in the code is not an issue, but avoiding
it or not preventing it, is an issue!

All those errors and bugs are discarded regularly, so we can conclude that debugging is nothing but a
process of eradicating or fixing the errors contained in a software program.

Debugging works stepwise, starting from identifying the errors, analyzing followed by removing the
errors. Whenever a software fails to deliver the result, we need the software tester to test the application
and solve it.

Since the errors are resolved at each step of debugging in the software testing, so we can conclude that
it is a tiresome and complex task regardless of how efficient the result was.
Steps involved in Debugging
Following are the different steps that are involved in debugging:

1. Identify the Error: Identifying an error in a wrong may result in the wastage of time. It is very obvious that
the production errors reported by users are hard to interpret, and sometimes the information we receive is
misleading. Thus, it is mandatory to identify the actual error.
2. Find the Error Location: Once the error is correctly discovered, you will be required to thoroughly review
the code repeatedly to locate the position of the error. In general, this step focuses on finding the error
rather than perceiving it.
3. Analyze the Error: The third step comprises error analysis, a bottom-up approach that starts from the
location of the error followed by analyzing the code. This step makes it easier to comprehend the errors.
Mainly error analysis has two significant goals, i.e., evaluation of errors all over again to find existing bugs
and postulating the uncertainty of incoming collateral damage in a fix.
4. Prove the Analysis: After analyzing the primary bugs, it is necessary to look for some extra errors that may
show up on the application. By incorporating the test framework, the fourth step is used to write automated
tests for such areas.
5. Cover Lateral Damage: The fifth phase is about accumulating all of the unit tests for the code that requires
modification. As when you run these unit tests, they must pass.
6. Fix & Validate: The last stage is the fix and validation that emphasizes fixing the bugs followed by running
all the test scripts to check whether they pass.

Software Maintenance
Software Maintenance refers to the process of modifying and updating a software system after it has
been delivered to the customer. This can include fixing bugs, adding new features, improving
performance, or updating the software to work with new hardware or software systems. The goal of
software maintenance is to keep the software system working correctly, efficiently, and securely, and to
ensure that it continues to meet the needs of the users.

Software maintenance is a continuous process that occurs throughout the entire life cycle of the software
system. It is important to have a well-defined maintenance process in place, which includes testing and
validation, version control, and communication with stakeholders.

Several Key Aspects of Software Maintenance

 Bug Fixing: The process of finding and fixing errors and problems in the software.
 Enhancements: The process of adding new features or improving existing features to meet
the evolving needs of the users.
 Performance Optimization: The process of improving the speed, efficiency, and reliability
of the software.
 Porting and Migration: The process of adapting the software to run on new hardware or
software platforms.
 Re-Engineering: The process of improving the design and architecture of the software to
make it more maintainable and scalable.
 Documentation: The process of creating, updating, and maintaining the documentation for
the software, including user manuals, technical specifications, and design documents.

Several Types of Software Maintenance

 Corrective Maintenance: This involves fixing errors and bugs in the software system.
 Patching: It is an emergency fix implemented mainly due to pressure from management.
Patching is done for corrective maintenance but it gives rise to unforeseen future errors
due to lack of proper impact analysis.
 Adaptive Maintenance: This involves modifying the software system to adapt it to
changes in the environment, such as changes in hardware or software, government
policies, and business rules.
 Perfective Maintenance: This involves improving functionality, performance, and
reliability, and restructuring the software system to improve changeability.
 Preventive Maintenance: This involves taking measures to prevent future problems, such
as optimization, updating documentation, reviewing and testing the system, and
implementing preventive measures such as backups.

Characteristics of good Software

Good software is characterized by several key attributes, including:
1. Functionality: The software meets the requirements and specifications that it was
designed for, and it behaves as expected when it is used in its intended environment.
2. Usability: The software is easy to use and understand, and it provides a positive user
experience.
3. Reliability: The software is free of defects and it performs consistently and accurately
under different conditions and scenarios.
4. Performance: The software runs efficiently and quickly, and it can handle large amounts of
data or traffic.
5. Security: The software is protected against unauthorized access and it keeps the data and
functions safe from malicious attacks.
6. Maintainability: The software is easy to change and update, and it is well-documented, so
that it can be understood and modified by other developers.
7. Reusability: The software can be reused in other projects or applications, and it is
designed in a way that promotes code reuse.
8. Scalability: The software can handle an increasing workload and it can be easily extended
to meet the changing requirements.
9. Testability: The software is designed in a way that makes it easy to test and validate, and it
has a comprehensive test coverage.

Test case
It is an in-details document that describes step by step procedure to test an application. It consists of the
complete navigation steps and inputs and all the scenarios that need to be tested for the application. We
will write the test case to maintain the consistency, or every tester will follow the same approach for
organizing the test document.
What is UML
The UML stands for Unified modeling language, is a standardized general-purpose visual modeling
language in the field of Software Engineering. It is used for specifying, visualizing, constructing, and
documenting the primary artifacts of the software system. It helps in designing and characterizing,
especially those software systems that incorporate the concept of Object orientation. It describes
the working of both the software and hardware systems.

Following are some object-oriented concepts that are needed to begin with UML:

o Object: An object is a real world entity. There are many objects present within a single system.
It is a fundamental building block of UML.
o Class: A class is a software blueprint for objects, which means that it defines the variables and
methods common to all the objects of a particular type.
o Abstraction: Abstraction is the process of portraying the essential characteristics of an object
to the users while hiding the irrelevant information. Basically, it is used to envision the
functioning of an object.
o Inheritance: Inheritance is the process of deriving a new class from the existing ones.
o Polymorphism: It is a mechanism of representing objects having multiple forms used for
different purposes.
o Encapsulation: It binds the data and the object together as a single unit, enabling tight
coupling between them.

Basic structures
1. Structural Diagrams
Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure diagrams,
component diagrams, deployment diagrams, object diagrams, and package diagrams. It presents an
outline for the system. It stresses the elements to be present that are to be modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the backbone
of all the object-oriented software systems. It depicts the static structure of the system. It
displays the system's class, attributes, and methods. It is helpful in recognizing the relation
between different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts within the
class. It displays the relationship between the parts and their configuration that ascertain the
behavior of the class. It makes full use of ports, parts, and connectors to portray the internal
structure of a structured classifier. It is similar to class diagrams, just the fact it represents
individual parts in a detailed manner when compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point in time. It
can be used to test the accuracy of class diagrams. It represents distinct instances of classes
and the relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components within the
system. It is used for modeling execution details. It determines whether the desired functional
requirements have been considered by the planned development or not, as it depicts the
structural relationships between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware by telling what the
existing physical components are and what software components are running on them. It
produces information about system software. It is incorporated whenever software is used,
distributed, or deployed across multiple machines with dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are organized.
It shows the dependencies between distinct packages. It manages UML diagrams by making
it easily understandable. It is used for organizing the class and use case diagrams.

Modeling classes
Class Nota�on: Each class is represented by a rectangle that is divided into three
compartments:
• The top compartment contains the class name.
• The middle compartment contains the atributes of the class.
• The botom compartment contains the opera�ons (methods) of the class.
Class Name: The class name should be placed in the top compartment and should
represent the name of the class.
Atributes: The atributes of the class are listed in the middle compartment of the class
rectangle. Atributes represent the proper�es or characteris�cs of the class.
Opera�ons: The opera�ons (methods) of the class are listed in the botom compartment
of the class rectangle. Opera�ons represent the behaviors or ac�ons that the class can
perform.
Mul�plicity: You can also specify the mul�plicity of associa�ons and aggrega�ons to
indicate how many instances of each class are related.
Visibility: The visibility indicators (+, -, #) used for atributes and opera�ons indicate the
access level of these members.
UML-Relationship
Relationships depict a connection between several things, such as structural, behavioral, or grouping
things in the unified modeling language. Since it is termed as a link, it demonstrates how things are
interrelated to each other at the time of system execution. It constitutes four types of relationships,
i.e., dependency, association, generalization, and realization.

Dependency
Whenever there is a change in either the structure or the behavior of the class that affects the other
class, such a relationship is termed as a dependency. Or, simply, we can say a class contained in other
class is known as dependency. It is a unidirectional relationship.

Association
Association is a structural relationship that represents how two entities are linked or connected to
each other within a system. It can form several types of associations, such as one-to-one, one-to-
many, many-to-one, and many-to-many. A ternary association is one that constitutes three links.
It portrays the static relationship between the entities of two classes.

An association can be categorized into four types of associations, i.e., bi-directional, unidirectional,
aggregation (composition aggregation), and reflexive, such that an aggregation is a special form of
association and composition is a special form of aggregation. The mostly used associations are
unidirectional and bi-directional.

Aggregation
An aggregation is a special form of association. It portrays a part-of relationship. It forms a binary
relationship, which means it cannot include more than two classes. It is also known as Has-a
relationship. It specifies the direction of an object contained in another object. In aggregation, a
child can exist independent of the parent.

Composition
In a composition relationship, the child depends on the parent. It forms a two-way relationship. It is
a special case of aggregation. It is known as Part-of relationship.

Generalization
The generalization relationship implements the object-oriented concept called inheritance or is-
a relationship. It exists between two objects (things or entities), such that one entity is a parent
(superclass or base class), and the other one is a child (subclass or derived class). These are
represented in terms of inheritance. Any child can access, update, or inherit the functionality,
structure, and behavior of the parent.
Realization
It is a kind of relationship in which one thing specifies the behavior or a responsibility to be carried
out, and the other thing carries out that behavior. It can be represented on a class diagram or
component diagrams. The realization relationship is constituted between interfaces, classes,
packages, and components to link a client element to the supplier element.

Common mechanisms
1. Inheritance: Allows a class to inherit atributes and behaviors from a superclass,
forming a hierarchical rela�onship.
2. Associa�on: Represents a bi-direc�onal rela�onship between classes, indica�ng a
simple link between objects.
3. Aggrega�on: Represents a "whole-part" rela�onship, where one class is composed of
mul�ple instances of another class.
4. Composi�on: Represents a stronger form of aggrega�on, where the life�me of the
parts is controlled by the whole.
5. Dependency: Represents a rela�onship where one class depends on another class,
o�en shown with a dashed arrow.
6. Encapsula�on: Hides the internal details of an object and exposes only necessary
func�onali�es through methods.
7. Polymorphism: Allows objects of different classes to be treated as objects of a
common superclass.
8. Visibility: Specifies the access level of atributes and methods (public, private,
protected) within a class.

UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects residing
in the system and the relationships between them. A class consists of its objects, and also it may
inherit from other classes. A class diagram is used to visualize, describe, document various different
aspects of the system, and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of the software
system.

components of a Class Diagram

The class diagram is made up of three sections:

o Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations,
and semantics. Some of the following rules that should be taken into account while
representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe the quality of
the class. The attributes have the following characteristics:
a. The attributes are written along with its visibility factors, which are public (+), private
(-), protected (#), and package (~).
b. The accessibility of an attribute class is illustrated by the visibility factors.
c. A meaningful name should be assigned to the attribute, which will explain its usage
inside the class.
o Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It demonstrates
how a class interacts with data.
Advanced structured modeling
Advanced structured modeling in UML involves using various UML diagrams and techniques
to model complex systems with a focus on structural and behavioral aspects. Here are some
advanced UML modeling concepts:
1. Composite Structure Diagram: Used to model complex structures with
interconnected components, showing their internal structure and rela�onships.
2. Component Diagram: Represents the high-level components of a system and their
dependencies, emphasizing the physical or logical organiza�on.
3. Deployment Diagram: Illustrates the hardware and so�ware components in a
distributed system and their rela�onships, aiding in system deployment planning.
4. State Machine Diagram: Models the behavior of an object or system as a state
machine, showing the transi�ons between states based on events and condi�ons.
5. Ac�vity Diagram: Depicts the workflow or business processes of a system, focusing
on the flow of ac�ons and decision points.
6. Interac�on Diagrams: Include Sequence Diagrams and Communica�on Diagrams,
showing the interac�ons between objects and the flow of messages.
7. Package Diagram: Organizes and represents the elements of a system into logical
groups (packages), helping manage complexity.
8. Profile Diagram: Extends UML by defining custom stereotypes, tagged values, and
constraints to tailor UML for specific domains or frameworks.
9. Object Constraint Language (OCL): A textual language used to specify constraints and
expressions that cannot be easily represented in other UML diagrams.
[Link] Case Diagrams with Advanced Rela�onships: Models complex use case
rela�onships like generaliza�on, extension points, and inclusion to capture system
behavior.
advanced classes and relationships
Advanced classes and relationships in UML go beyond the basic associations and inheritance. They
allow for more sophisticated modeling of complex systems. Here are some advanced classes and
relationships in UML:

1. Qualified Association: Allows associating elements with specific qualifiers, such as a map
linking students to their respective grades in a particular subject.
2. Aggregation and Shared Aggregation: Aggregation represents a whole-part relationship,
and shared aggregation indicates parts that can be shared among multiple wholes.
3. Composition and Shared Composition: Similar to aggregation, but with stronger
ownership, where the parts' lifetimes depend on the whole. Shared composition allows parts
to be shared among multiple composites.
4. Constraint: Represents conditions or restrictions on elements, expressed using Object
Constraint Language (OCL) to add precision to the model.
5. Template Class (Parameterized Class): Represents a generic class that can be specialized
for specific data types or constraints.
6. Template Binding: Connects template parameters of template classes to actual classes or
data types.
7. Realization (Interface Realization): Represents the implementation of interfaces by classes.
8. Generalization Sets: Allows grouping of generalization relationships, useful when multiple
classes share the same parent.
9. Association Class: Represents an association with its attributes and operations, treating the
association as a full-fledged class.
10. Directed Association: Indicates a one-way relationship between classes.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It
represents an instance of a class diagram. The objects help in portraying a static view of an object-
oriented system at a specific instant.

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides
an abstract view which comprises of classes and their relationships, whereas the object diagram
represents an instance at a particular point of time.

Example of Object Diagram

Class vs. Object diagram

Serial Class Diagram Object Diagram

No.

1. It depicts the static view of a system. It portrays the real-time behavior of

a system.

2. Dynamic changes are not included in the Dynamic changes are captured in the
class diagram. object diagram.

3. The data values and attributes of an instance It incorporates data values and
are not involved here. attributes of an entity.

4. The object behavior is manipulated in the Objects are the instances of a class.
class diagram.

UML State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which shows the
order of states underwent by an object within the system. It captures the software system's behavior.
It models the behavior of a class, a subsystem, a package, and a complete system.

Following are the types of a state machine diagram that are given below:
1. Behavioral state machine
The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementa�on of a par�cular en�ty. It models the behavior of
the system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the
change in the state of the protocol and parallel changes within the system. But it does
not portray the implementa�on of a par�cular component.

3. Notation of a State Machine Diagram

4. Following are the notations of a state machine diagram enlisted below:
 5.

Types of State
The UML consist of three states:

1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it does not contain more
than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state, but
it can be reused.

UML Interaction Diagram

As the name suggests, the interaction diagram portrays the interactions between distinct entities
present in the model. It amalgamates both the activity and sequence diagrams. The communication
is nothing but units of the behavior of a classifier that provides context for interactions.

A set of messages that are interchanged between the entities to achieve certain specified tasks in
the system is termed as interaction. It may incorporate any feature of the classifier of which it has
access. In the interaction diagram, the critical component is the messages and the lifeline.
Notation of an Interaction Diagram

Use of an Interaction Diagram

The interaction diagram can be used for:

1. The sequence diagram is employed to investigate a new application.

2. The interaction diagram explores and compares the use of the collaboration diagram
sequence diagram and the timing diagram.
3. The interaction diagram represents the interactive (dynamic) behavior of the system.
4. The sequence diagram portrays the order of control flow from one element to the other
elements inside the system, whereas the collaboration diagrams are employed to get an
overview of the object architecture of the system.
5. The interaction diagram models the system as a time-ordered sequence of a system.
6. The interaction diagram models the system as a time-ordered sequence of a system.
7. The interaction diagram systemizes the structure of the interactive elements.

Purpose of an Interaction Diagram

The interaction diagram helps to envision the interactive (dynamic) behavior of any system. It
portrays how objects residing in the system communicates and connects to each other. It also
provides us with a context of communication between the lifelines inside the system.

UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the tasks,
services, and functions required by a system/subsystem of an application. It depicts the high-level
functionality of a system and also tells how the user handles a system.
Purpose of Use Case Diagrams
Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

Object Oriented Metrics

These are used to determine success or failure of a person also to quantify the
improvements in the software throughout its process. These metrics can be used to
reinforce good OO programming technique which lead to more reliable code.

Why are Object-Oriented Software Engineering Metrics Different?

Localization : It is the process of placing items in close physical nearness to each other.
• Functional decomposition processes localize information around functions.
• Data-driven approaches localize information around data.
• Object-oriented approaches localize information around objects.
In object-oriented software , from the name suggests the localization is based on
objects. This means:
• Although we may speak of the functionality provided by an object, atleast
some of our metrics identification and gathering effort must recognize the
“object” as basic unit of software.
• Within systems of objects, localization between functionality and objects is not
one-to-one relationships. For example, there are many objects for one function
and also one object can have many functions.
Encapsulation : It is the packaging of a collection of items.
• Low-level examples of encapsulation include records and arrays.
• Subprograms are mid level mechanisms for encapsulation.
• There are still very long encapsulation mechanisms for the object-oriented
programming languages, e.g., C++’s, classes, Ada’s packages, and Modula 3’s
modules.
• Objects encapsulates:
• Knowledge of state
• Advertised capabilities
• Other objects
• Exceptions
• Constants
• Concepts
Information Hiding: It is the suppression or hiding of the objects.
• We show only the information which is needed to accomplish our goals.
• Degree of information hiding ranges from partially restricted visibility to total
invisibility.
• Encapsulation and information hiding are not same thing e.g., an item can be
encapsulated but still be to totally visible.
It plays a direct role in such metrics as object coupling and the degree of information
hiding.
Inheritance: It is mechanism where one object acquires the characteristics from one, or
more , other objects.
• Some object-oriented languages support only single inheritance.
• Some object-oriented languages support only multiple inheritance.
• Inheritance type and their semantics vary from language to language.
There are many object-oriented software engineering metrics which are based on
inheritance e.g.,
• number of children
• number of parents
• class hierarchy nesting level
Abstraction: It is the mechanism where we focus only on important details of a concept,
while ignoring the in essential details.
• It is a relative concept.
• There are also different categories of abstraction, e.g., functional data, process
and object abstraction.
• Objects are treated as high-level entities in object abstraction.
Classes: There are three commonly used views on the definition for “class”.
• Class as a cookie cutter: For the structurally identically items, a class is a
pattern, template, or a blueprint. The items which can be created using class
are called instances.
• Class as an instance factory: Basically class is a thing which contains both a
pattern and a mechanism for creating items based on that pattern and
instances are like individual items that are “manufactured” by using class
creation mechanism.
• A class is a set of all the items which are created using a specific pattern, i.e.,
the class is the set of all instances of that pattern.