The document provides an overview of software engineering, detailing the software development life cycle (SDLC) models such as the classical waterfall, iterative waterfall, prototyping, and spiral models. It also discusses essential concepts like software design principles, coupling and cohesion, UML diagrams, coding standards, and various types of software testing, including manual and automation testing. Finally, it outlines the different levels of software testing, ensuring software quality and customer satisfaction.

1. NAME :SAYAN GHOSH
ROLL:14400120032
SUBJECT :SOFTWARE
ENGINEERING
SUBJECT CODE :ESC 501
1

2. INTRODUCTION TO SOFTWARE ENGINEERING
Software engineering is the study of and practice of engineering to build, design, develop,
maintain, and retire software.
● Examples are: computer language programming and coding, software
testing, debugging, OOD, database management, etc.
2

3. SOFTWARE DEVELOPMENT LIFE CYCLE MODELS
SDLC is a process that defines the various stages involved in the development of software for
delivering a high-quality product. SDLC stages cover the complete life cycle of a software i.e. from
inception to retirement of the product.
Adhering to the SDLC process leads to the development of the software in a systematic and
disciplined manner.
Types of Software developing life cycles (SDLC) :
1. Classical Waterfall Model
2. Iterative Waterfall Model
3. Prototyping Model
4. Evolutionary Model
5. Spiral Model
3

4. ● CLASSIC WATERFALL MODEL
The classical Waterfall Model was the first Process Model. It is also known as a linear-sequential
life cycle model. It is very simple to understand and use.
Classical waterfall model is the earliest, best known and most commonly used methodology. It is a
sequential lifecycle that is simple to understand and use each phase has to be completed finished
before another start which means no overlapping is allowed.
• Feasibility study
• Requirements analysis and specifications
• Design
• Coding and unit testing
• Integration and system testing
• Maintenance
4

5. ● ITERATIVE WATERFALL MODEL
Iterative Waterfall Model is the extension of the Waterfall model. This model is almost same as the
waterfall model except some modifications are made to improve the performance of the software
development. The iterative waterfall model provides customer’s feedback paths from each phase to
its previous phases.
Iterative Waterfall Model strengths
❏ Easy to understand, easy to use.
❏ Provides a reference for inexperienced staff.
❏ Milestones are well understood by the team.
❏ It provides requirements stability.
❏ Facilitates strong management controls.
5

6. ● PROTOTYPING MODEL
The prototyping model is applied when detailed information related to input and
output requirements of the system is not available. In this model, it is assumed that
all the requirements may not be known at the start of the development of the
system. This model allows the users to interact and experiment with a working
model of the system known as prototype. The prototype gives the user an actual
feel of the system.
Types of PrototypingModels
❏ Rapid Throwaway prototypes
❏ Evolutionary prototype
❏ Incremental prototype
❏ Extreme prototype
6

7. ● SPIRAL MODEL
The spiral model is an SDLC model that combines elements of an iterative
software development model with a waterfall model. It is advisable to use this
model for expensive, large and complex projects.
Stages of SpiralModel
It has four stages
❏ Determineobjectivesandidentifyalternativesolutions
❏ Identifyandresolverisks
❏ Developnextleveloftheproduct
❏ Reviewandplanforthenextphase
7

8. SOFTWAREDESIGN
Software engineering is the process of analyzing user needs and designing,
constructing, and testing end-user applications that will satisfy these needs through
the use of software programming languages. It is the application of engineering
principles to software development.
● COUPLING:Coupling in software engineering is the inter-dependency or degree of
relationship between multiple modules/packages/components. Coupling is also called
Inter-Module Binding.
● COHESION :Cohesion refers to what module can do, internally. It is also called Intra-Module
binding as it measures the strength of relationship of functionalities inside a
module/package/component. Cohesion should always be high means that a
module/package/component is focused on what it should be doing, i.e. only methods relating to
the intention of the class.
8

9. TYPES OF COUPLING
1. DataCoupling:When modules shared primitive data between them.
2. StampCoupling:When modules shared composite or structural data between them and It must be a non-
global data structure. for example, Passing object or structure variable in react components.
3. ControlCoupling:When data from one module is used to direct the structure of instruction execution in
another.
4. ExternalCoupling:When two modules shared externally imposed data type that is external to the
software like communication protocols, device interfaces.
5. CommonCoupling:When two modules shared the same global data & dependent on them, like state
management in JavaScript frameworks.
6. ContentCoupling:When two modules shared code and can modify the data of another module, which is the
worst coupling and should be avoided.
9

10. TYPES OF COHESION
1. FunctionalCohesion:The execution of the task related to the problem is the only concern
from all the elements inside the module.
2. SequentialCohesion:The output of an element is the input of other element in a module i.e.,
data flow between the parts.
3. CommunicationalCohesion:Multiple elements in a module operate on same input data and
produce same output data.
4. ProceduralCohesion:The activities in module are related by sequence, otherwise they are not
related.
5. CoincidentalCohesion:The activities with meaningless relationship with one another are
contributed by the elements in the module
10

11. UMLDIAGRAM
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object
interactions and also depicts the flow between various use case elements of a system. In simple
words, it shows how objects interact with each other and how the data flows within them. Today,
UML is accepted by the Object Management Group (OMG) as the standard
for modeling software development.
The key to making a UML diagram is connecting shapes that represent
an object or class with other shapes to illustrate relationships and the
flow of information and data.
11

12. Types of UMLDiagrams
 Structural UMLdiagrams
❖ Class diagram
❖ Package diagram
❖ Object diagram
❖ Component diagram
❖ Composite structure diagram
❖ Deployment diagram
 Behavioral UMLdiagrams
❖ Activity diagram
❖ Sequence diagram
❖ Use case diagram
❖ State diagram
❖ Communication diagram
❖ Interaction overview diagram
❖ Timing diagram
12

13. CODINGSTANDARDS AND GUIDELINES
Codingstandardsare the set of guidelines or norms that are globally set or are set by various
software development organizations (and they hold only to that particular organization) and
these guidelines should be followed by all the developers to produce a good quality software.
There are various benefits of using the coding standards while coding the software like,
● Code understanding becomes easier
● Entire code of the whole software has same format and style of coding
● Encourages good programming skills
Most of the top software developing companies set their codingstandardby their own and
these standards are followed by the developers of that particular organizations only.
However, there are some common representative coding standards and guidelines that are
more overly applicable to all and are mostly followed by every developer or organization.
Following are some of them,
13

14. ❑ Rulesforglobalvariablesdeclaration:
There are rules which define what type of variables can be declared as global and what cannot.
This helps to maintain the confidentiality of the data and is also helpful in cases where the
access rights are to be provided only to the selected group of users.
❑ Namingconventions:
Naming conventions are set for declaring any sort of entity or variable within the software. This
provides a regularity in the structure of the names defined. For example, ‘every button should
have its name in all capitals’ can be a naming convention.
❑ Contents ofheaders:
The data that must be there in the header of each module has a pre-defined format. This usually
includes the name of the module, data of creation, date of approval, developer’s or author’s
name, synopsis, description of the module, description of the variables and functions defined in
the module,etc.
14

15. ❑ Error returnconventions:
There are certain conditions in which the input data is bounded within some range. If in such
cases, the data entered by the user exceeds the particular range, then an error message should
be displayed. The range and criteria for which the error should pop up is defined in the error
return conventions.
❑ Usecodingstyle thatiseasytounderstandandisgloballyaccepted:
It is recommended that the coding style that is being followed must be easy to understand and
should be similar to that which is globally accepted or else it would be difficult for the user to
understand it and also it would take time for the developers to develop a habit of following a
completely new coding format.
❑ Thelengthoffunctionsormethodsshouldbesmall:
It is a good practice to keep the body of the functions small, nearly about 10-12 code lines. This
makes the code readable and easily modifiable.
15

16. ❑ Do not unnecessarily use statements that break the control flow of
statements:
It is advised not to use jump, goto and function calls unnecessarily as it takes extra
time for the processor to break the going flow, search for the mentioned statement,
load those statements, execute them and then return to the previous calling
function. Therefore, try to avoid such situations as much as possible.
❑ Choose identifier names uniquely within the module:
Every identifier at least within the module must have a unique name to avoid
ambiguity.
16

17. SOFTWARE TESTING
Software testing is a process, to evaluate the functionality of a software
application with an intent to find whether the developed software met the
specified requirements or not and to identify the defects to ensure that the
product is defect-free in order to produce a quality product.
Some of the reasons why testing become a very significant and integral part of
the field of information technology are as follows.
❖ Cost-effectiveness
❖ Customer Satisfaction
❖ Security
❖ Product Quality
17

18. DIFFERENT TYPES OF SOFTWARE TESTING
❖ Manual Testing:
 Manual testing is the process of testing the software by hand to learn more about it, to
find what is and isn’t working.
 This usually includes verifying all the features specified in requirements documents, but
often also includes the testers trying the software with the perspective of their end user’s in
mind.
 Manual test plans vary from fully scripted test cases, giving testers detailed steps and
expected results, through to high-level guides that steer exploratory testing sessions.
18

19. ❖ AutomationTesting:
Automation testing is the process of testing the software using an automation
tool to find the defects.
In this process, testers execute the test scripts and generate the test results
automatically by using automation tools.
Some of the famous automation testing tools for functional testing include
Selenium and KatalonStudio.
19

20. SOFTWARETesting Levels:
❖ Unit Testing
❖ Integration Testing
❖ System Testing
❖ Acceptance Testing
20

21. ❖ Unit Testing:
Unit Testing is done to check whether the individual modules of the source code are working properly. i.e.
testing each and every unit of the application separately by the developer in the developer’s environment.
It is AKA Module Testing or Component Testing.
❖ Integration Testing:
Integration Testing is the process of testing the connectivity or data transfer between a couple of unit tested
modules. It is AKA I&T Testing or String Testing. It is subdivided into the Top-Down Approach, Bottom-Up
Approach, and Sandwich Approach (Combination of Top-Down and Bottom-Up).
21

22. ❖ System Testing (End to End Testing):
It’s a black box testing. Testing the fully integrated application is also called as an end to end scenario testing.
To ensure that the software works in all intended target systems. Verify thorough testing of every input in the
application to check for desired outputs.
Testing of the user’s experiences with the application.
❖ Acceptance Testing:
To obtain customer sign-off so that software can be delivered and payments received. Types of Acceptance
Testing are Alpha, Beta & Gamma Testing.
22

23. ThankYou
23