0% found this document useful (0 votes)
11 views74 pages

CHAPTER 1 Introduction SWE

Uploaded by

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

CHAPTER 1 Introduction SWE

Uploaded by

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

CHAPTER ONE

INTRODUCTION

1
Introduction to Software Engineering

Software, like all capital, is embodied knowledge,


and because that knowledge is initially dispersed,
tacit, latent, and incomplete in large measure,
software development is a social learning process.
The process is a dialogue in which the knowledge
that must become the software is brought together
and embodied in the software.
 The process provides interaction between users
and designers, between users and evolving tools,
and between designers and evolving tools
[technology].
2
Introduction…
Indeed, building computer software is an iterative
learning process, and the outcome is an embodiment
of knowledge collected, distilled, and organized as
the process is conducted.
When you build a product or system, it is important
to go through a series of predictable steps; a road
map that helps you create a timely, high-quality result.
The road map that you follow is called a software
process.
Software engineers and their managers adapt the
process to their needs and then follow it.
3
Introduction…
Software Engineering is the application of a
systematic, disciplined, quantifiable approach
to the development, operation, and maintenance
of software; that is, the application of
engineering to software and the study of
approaches.

4
Layered Technology in 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.

5
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.
6
Process activities for soft ware
development are listed below:-

7
Process activities…
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.
8
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.

9
Process, Methods, and Tools
To engineer software adequately, a software
engineering process must be defined.

10
Basic Phases
The work associated with software engineering can be
categorized into three generic phases, regardless of
application area, project size, or complexity.
1) The definition phase focuses on what.
During definition, the software engineer attempts to
identify
 what information is to be processed
 what function and performance are desired
 what system behavior can be expected
 what interfaces are to be established
 what design constraints exist and
 what validation criteria are required to define a successful
system. 11
Phases…
2) The development phase focuses on how.
During development, a software engineer attempts to
define
 how data are to be structured
 how function is to be implemented within a
software architecture
 how procedural details are to be implemented
 how interfaces are to be characterized
 how the design will be translated into a
programming language (or nonprocedural
language), and how testing will be performed.
12
Phases…
3) The support phase focuses on
 change associated with error correction,
adaptations required as the software's
environment evolves, and changes due to
enhancements brought about by changing
customer requirements.

13
Phases…
Types of Maintenance in support Phase:
Corrective maintenance
Adaptive maintenance
Perfective maintenance
preventive maintenance

14
Corrective maintenance
• is maintenance strategy that is used to correct something in its normal
working condition. Whenever any equipment or asset gets failed, one needs to
identify main problem and then make decision regarding whether particular
equipment should require either repair or replacement.

• is generally required when an asset working or gets damaged, simply to bring


assets back to their normal working condition.

• An asset can be corrected either by replacing it or repairing it.

• Its main aim is generally to restore broken assets or equipment. One can say
that it is basically a rectification process that is mainly implemented after
occurrence of failure or breakdown.

• to restore a system, machine, or software to its optimal working condition


after a failure or malfunction has occurred. 15
• Unlike preventive maintenance, which aims to prevent issues before they
happen, Corrective Maintenance focuses on identifying, isolating, and
repairing faults or defects once they are detected.

• This approach is crucial in ensuring that operations resume quickly and


efficiently, minimizing downtime and maintaining productivity.

• In the context of software development, Corrective Maintenance involves


fixing bugs or errors that are discovered during the use of the software,
ensuring that the system remains functional and reliable.

• Correct software maintenance addresses the errors and faults within


software applications that could impact various parts of your software,
including the design, logic, and code.

• These corrections usually come from bug reports that were created by users
or customers – but corrective software maintenance can help to spot them
before your customers do, which can help your brand’s reputation. 16
Examples of Corrective Maintenance

Some of examples of corrective maintenance in


software are:
– Fixing a Software Bug
– Patching Security Vulnerabilities
– Resolving Compatibility Issues
– Restoring Lost Data
– Repairing a Feature That Stopped Working

17
Adaptive Software Maintenance
• It is becomes important when the environment of your
software changes.
• This can be brought on by changes to the operating
system, hardware, software dependencies, Cloud storage,
or even changes within the operating system.
• Sometimes, adaptive software maintenance reflects
organizational policies or rules as well.
• Updating services, making modifications to vendors, or
changing payment processors can all necessitate adaptive
software maintenance.
• Example: modifying software for changing environments,
including legal/regulatory updates and evolving business
needs. 18
Perfective Software Maintenance
• focuses on the evolution of requirements and
features that existing in your system.

• It takes over some of the work, both adding features


that can enhance user experience and removing
features that are not effective and functional. This
can include features that are not used or those that
do not help you to meet your end goals.

• Examples
– Re-organizing data sets within a
19
Preventive Software Maintenance
• Preventative Software Maintenance helps to make changes and
adaptations to your software so that it can work for a longer period
of time. The focus of the type of maintenance is to prevent the
deterioration of your software as it continues to adapt and change.

• These services can include optimizing code and updating


documentation as needed.

• It helps to reduce the risk associated with operating software for a


long time, helping it to become more stable, understandable, and
maintainable.

• Example
– Regular cleaning, replacing of parts and equipment repairs
20
• Corrective maintenance is about correcting software
defects, errors and faults.
• Corrective maintenance is performed after equipment
failure, while preventive maintenance involves
scheduled activities prior to any breakdown.
• Perfective software maintenance focuses on features
that improve the user experience through functional
enhancements.
• Preventive software is about future-proofing its
longevity and efficiency by implementing good practices
for long-term gain..
21
The software crisis
Organizations are spending larger and larger
portions of their budget on software.
Not only are the software products turning out
to be more expensive than hardware, but they
also present a host of other problems to the
customers.

22
The software crisis
Software products are
Difficult to alter, debug, and enhance;
Use resources non-optimally;
Often fail to meet the user requirements;
are far from being reliable;
frequently crash; and
are often delivered late.

23
The software crisis
The trend of increasing software costs is
probably the most important symptom of the
present software crisis.
Note that the cost we are talking of here is not
on account of increased features, but due to
ineffective development of the product
characterized by inefficient resource usage, and
time and cost over-runs.

24
The software crisis
There are many factors that have contributed to
the making of the present software crisis.
Factors are:
 larger problem sizes,
lack of adequate training in software
engineering,
increasing skill shortage, and
low productivity improvements.

25
The software crisis
The only satisfactory solution to the present
software crisis can possibly come from a spread
of software engineering practices among the
engineers.

26
Software life cycle models
A software life cycle model (process model) is a
descriptive and diagrammatic representation of the
software life cycle.
A life cycle model represents all the activities
required to make a software product transit through
its life cycle phases.
It also captures the order in which these activities
are to be undertaken.
In other words, a life cycle model maps the
different activities performed on a software product
from its inception to retirement.
27
Software life cycle models
Different life cycle models may map the basic
development activities to phases in different
ways.
Thus, no matter which life cycle model is
followed, the basic activities are included in all
life cycle models though the activities may be
carried out in different orders in different life
cycle models.
During any life cycle phase, more than one
activity may also be carried out.
28
Different software life cycle models

A few important and commonly used life cycle models are as follows:
 Waterfall Model
 Classical
 Iterative
 The RAD Model
 Prototyping Model
 Evolutionary Model
 Incremental
 Spiral Model
 WinWin Spiral Model
 The Concurrent Development Model/Pipeline
 Fourth Generation Techniques(4GT)
 Component-Based Development/ OO-based>>classes

29
1) Classical Waterfall Model

Though the classical waterfall model is elegant


and intuitively obvious, it is not a practical
model in the sense that it can not be used in
actual software development projects.
Thus, this model can be considered to be a
theoretical way of developing software.
But all other life cycle models are essentially
derived from the classical waterfall model.

30
Classical waterfall model
Classical waterfall model divides the life cycle
into the following phases:
Feasibility Study
Requirements Analysis and Specification
Design
Coding and Unit Testing
Integration and System Testing
Maintenance

31
32
Waterfall Model..
Activities undertaken during feasibility study:
 The main aim of feasibility study is to determine whether it
would be financially and technically feasible to develop
the product.
 At first project managers or team leaders try to have a
rough understanding of what is required to be done by
visiting the client side.
 They study different input data to the system and output
data to be produced by the system.
 They study what kind of processing is needed to be done
on these data and they look at the various constraints on
the behavior of the system. 33
Waterfall Model …
 After they have an overall understanding of the
problem they investigate the different solutions that
are possible.

 Then they examine each of the solutions in terms of

 what kind of resources required,


 what would be the cost of development and
 what would be the development time for each solution.

34
Waterfall Model …
Activities undertaken during requirements analysis
and specification:
 The aim of the requirements analysis and
specification phase is to understand the exact
requirements of the customer and to document them
properly.

 This phase consists of two distinct activities, namely


 Requirements gathering and analysis, and
 Requirements specification
35
Waterfall Model …
 The goal of the requirements gathering activity is to collect
all relevant information from the customer regarding the
product to be developed.
 This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies
are removed.
 After all ambiguities, inconsistencies, and incompleteness
have been resolved and all the requirements properly
understood, the requirements specification activity can
start.
 During this activity, the user requirements are
systematically organized into a Software Requirements
Specification (SRS) document. 36
Waterfall Model …
Activities undertaken during design:
The goal of the design phase is to transform the
requirements specified in the SRS document into
a structure that is suitable for implementation in
some programming language.
Two distinctly different approaches are
available:
1) The traditional design approach and
2) The object-oriented design approach.
37
Waterfall Model …
1) Traditional design approach
Traditional design consists of two different
activities;
• first a structured analysis of the requirements
specification is carried out where the detailed
structure of the problem is examined.
This is followed by a structured design activity.
 During structured design, the results of
structured analysis are transformed into the
software design.
38
Waterfall Model …
2) Object-oriented design approach
In this technique, various objects that occur in the
problem domain and the solution domain are first
identified, and the different relationships that exist
among these objects are identified.

The object structure is further refined to obtain the


detailed design.

39
Waterfall Model …
Software design is actually a multistep process
that focuses on four distinct attributes of a
program:
data structure,
software architecture,
Interface representations, and
procedural (algorithmic) detail.

40
Waterfall Model…
Activities undertaken during coding and unit testing:
The purpose of the coding and unit testing phase
(sometimes called the implementation phase) of
software development is to translate the software design
into source code.
Each component of the design is implemented as a
program module.
The end-product of this phase is a set of program
modules that have been individually tested (Unit
testing).
41
Waterfall Model …
Activities undertaken during integration and
system testing:
Integration of different modules is undertaken once
they have been coded and unit tested.
 During the integration and system testing phase, the
modules are integrated in a planned manner.
Integration is normally carried out incrementally
over a number of steps.
 During each integration step, the partially integrated
system is tested and a set of previously planned
modules are added to it.
42
Waterfall Model …
Finally, when all the modules have been
successfully integrated and tested, system testing
is carried out.
The goal of system testing is to ensure that the
developed system conforms to its requirements
laid out in the SRS document.

43
Waterfall Model …
System testing usually consists of three different
kinds of testing activities:
1) α– testing: It is the system testing performed
by the development team.
2) β– testing: It is the system testing performed
by a friendly set of customers.
3) acceptance testing: It is the system testing
performed by the customer himself after the
product delivery to determine whether to
accept or reject the delivered product.
44
Waterfall Model …
Activities undertaken during maintenance/support:
Maintenance of a typical software product
requires much more than the effort necessary to
develop the product itself.
Many studies carried out in the past confirm
this and indicate that the relative effort of
development of a typical software product to its
maintenance effort is roughly in the 40:60 ratio.

45
Waterfall Model …
Maintenance involves performing any one or more of
the following three kinds of activities:
Correcting errors that were not discovered during the
product development phase. This is called corrective
maintenance.
Improving the implementation of the system, and
enhancing the functionalities of the system according to
the customer’s requirements. This is called perfective
maintenance.
Porting the software to work in a new environment. For
example, porting may be required to get the software to
work on a new computer platform or with a new operating
system. This is called adaptive maintenance.
46
Waterfall Model …
Shortcomings of the classical waterfall model
The classical waterfall model is an idealistic
one since it assumes that no development error
is ever committed by the engineers during any of
the life cycle phases. However, in practical
development environments, the engineers do
commit a large number of errors in almost every
phase of the life cycle.

47
Waterfall Model …
The source of the defects(faults) can be many: oversight, wrong
assumptions, use of inappropriate technology, communication gap
among the project engineers, etc.
These defects usually get detected much later in the life cycle.
Once a defect is detected, the engineers need to go back to the phase
where the defect had occurred and repeat some of the work done
during that phase and the subsequent phases to correct the defect and
its effect on the later phases.
Therefore, in any practical software development work, it is not
possible to strictly follow the classical waterfall model.

 One example of the waterfall methodology is the construction of a building. The


project starts with gathering requirements from the client, followed by the design
phase, where blueprints and plans are created. Then, the construction phase begins,
where the building is constructed according to the design.
48
2) The RAD Model
 Rapid application development (RAD) is an
incremental software development process model that
emphasizes an extremely short development cycle.
 The RAD model is a “high-speed” adaptation of the
linear sequential model in which rapid development is
achieved by using component-based construction.
 If requirements are well understood and project scope is
constrained, the RAD process enables a development
team to create a “fully functional system” within very
short time periods (e.g., 60 to 90 days).

49
3) Prototyping model
A prototype is a toy(model) implementation of the system.
A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient performance
compared to the actual software.
A prototype is usually built using several shortcuts. The
shortcuts might involve using inefficient, inaccurate, or
dummy functions. The shortcut implementation of a
function, for example, may produce the desired results by
using a table look-up instead of performing the actual
computations.
A prototype usually turns out to be a very crude version
of the actual system.
50
Prototyping model …
Need for a prototype in software development:
There are several uses of a prototype. An
important purpose is to illustrate the input data
formats, messages, reports, and the interactive
dialogues to the customer.
This is a valuable mechanism for gaining better
understanding of the customer’s needs:
•how the screens might look like
•how the user interface would behave
•how the system would produce outputs
51
Prototyping model …
Another reason for developing a prototype is
that it is impossible to get the perfect product in
the first attempt.
Many researchers and engineers advocate that
if you want to develop a good product you must
plan to throw away the first version.
The experience gained in developing the
prototype can be used to develop the final
product.

52
Prototyping model …
A prototyping model can be used when technical
solutions are unclear to the development team.
A developed prototype can help engineers to
critically examine the technical issues associated
with the product development.
Often, major design decisions depend on issues
like the response time of a hardware controller, or
the efficiency of a sorting algorithm, etc.
In such circumstances, a prototype may be the
best or the only way to resolve the technical issues.
53
4) EVOLUTIONARY SOFTWARE PROCESS MODELS

There is growing recognition that software,


like all complex systems, evolves over a period
of time.
Business and product requirements often
change as development proceeds, making a
straight path to an end product unrealistic.
But a limited version must be introduced to
meet competitive or business pressure.

54
EVOLUTIONARY MODELS…

The linear sequential model is designed for straight-


line development.
In essence, this waterfall approach assumes that a
complete system will be delivered after the linear
sequence is completed.
The prototyping model is designed to assist the
customer (developer) in understanding requirements. In
general, it is not designed to deliver a production
system.
The evolutionary nature of software is not considered
in either of these classic software engineering paradigms.
55
EVOLUTIONARY MODELS…

Evolutionary models are iterative.


They are characterized in a manner that
enables software engineers to develop
increasingly more complete versions of the
software.

56
4.1) Spiral model
The diagrammatic representation of this model appears
like a spiral with many loops.
The exact number of loops in the spiral is not fixed.
 Each loop of the spiral represents a phase of the
software process.
For example, the innermost loop might be concerned
with feasibility study. The next loop with requirements
specification, the next one with design, and so on. Each
phase in this model is split into four sectors (or
quadrants).
 The following activities are carried out during each
phase of a spiral model.
57
Spiral model…
First quadrant (Objective Setting)
 During the first quadrant, it is needed to identify
the objectives of the phase.
 Examine the risks associated with these
objectives.
 Second Quadrant (Risk Assessment and Reduction)
 A detailed analysis is carried out for each
identified project risk.
 Steps are taken to reduce the risks. For example,
if there is a risk that the requirements are
inappropriate, a prototype system may be developed.
58
Spiral model…

59
Spiral model…
Third Quadrant (Development and Validation)
Develop and validate the next level of the
product after resolving the identified risks.
Fourth Quadrant (Review and Planning)
Review the results achieved so far with the
customer and plan the next iteration around
the spiral.
Progressively more complete version of the
software gets built with each iteration around
the spiral.
60
Spiral model…
Circumstances to use spiral model
The spiral model is called a meta model since it
includes all other life cycle models.
Risk handling is inherently built into this model.
The spiral model is suitable for development of
technically challenging software products that are
prone to several kinds of risks.
However, this model is much more complex than
the other models – this is probably a factor
deterring its use in ordinary projects.
61
4.2) The Incremental Model
The incremental model combines elements of the linear
sequential model with the iterative philosophy of
prototyping.
Each linear sequence produces a deliverable
“increment” of the software.
 For example, word-processing software developed
using the incremental paradigm might deliver basic file
management, editing, and document production functions
in the first increment; more sophisticated editing and
document production capabilities in the second increment;
spelling and grammar checking in the third increment; and
advanced page layout capability in the fourth increment.
62
The Incremental Model…
When an incremental model is used, the first
increment is often a core product.
The core product is used by the customer (or
undergoes detailed review).
 As a result of use and/or evaluation, a plan is
developed for the next increment. The plan addresses
the modification of the core product to better meet the
needs of the customer and the delivery of additional
features and functionality.
 This process is repeated following the delivery of
each increment, until the complete product is produced.
63
The Incremental Model…
• Incremental development is a method of building software products in which a
system is built piece-by-piece.
• The final requirement specification is clear from the beginning, and everyone knows
the end result clearly.
• The system is broken down into small sub-systems which are designed, built and
tested independently.

• It is approach breaks the software development process down into small,


manageable portions known as increments. Each increment builds on the previous
version so that improvements are made step by step
• where products are realized in small parts (increments). The goal is to plan a product
in small steps (incrementally) and not as a whole.
• Example: The drawer started from the first iteration and once the module was
completed, the second iteration started which was the other module. Once that was
completed, it was then integrated into the first module. This was done until the
whole product was integrated and ready.
64
The Incremental Model…
• Incremental: Focuses on building and delivering functional parts
of the product in sequence, with the final product completed at
the end.

• Smartphones are an excellent example of incremental innovation

• take the case of the Linux operating system. The Linux kernel,
which is the core of the operating system, was developed using
an incremental approach, with each new version building on the
previous one.

• For example, Coca Cola is constantly innovating incrementally by


launching new tastes to its brand portfolio.
65

The Incremental Model…
Examples of Real-World Incremental Learning Applications
• Autonomous Vehicles. ...
• News Recommendation Systems. ...
• Fraud Detection in Banking. ...
• Stochastic Gradient Descent (SGD) ...
• Online Support Vector Machines (SVM) ...
• Incremental Decision Trees. ...
• Incremental Deep Learning Models.

 Incremental Change Examples From Real-life

Each new iPhone or MacBook iteration often includes minor enhancements and
improvements rather than radical changes. Toyota: The automotive industry is a notable
example of incremental change, with companies like Toyota implementing continuous
improvement practices.

 Microsoft uses Incremental models as they always need their users requirements so that
they update their product… We have many versions of Microsoft Office products which are
66
developed through Incremental model…
The Incremental Model…

67
The Iterative Model
• Iterative: Focuses on refining the product with
continuous feedback and improvements through
repeated cycles.

• Iterative: An iterative model means software


development activities are systematically repeated
in cycles known as iterations.
• A new version of the software is produced after
each iteration until the optimal product is achieved.

68
The Iterative Model….

• What was an iterative loop, again? Recall this definition: Iteration is when the
same procedure is repeated multiple times. Some examples were long division,
the Fibonacci numbers, prime numbers, and the calculator game. Some of
these used recursion as well, but not all of them.

• Example: The video game, on the other hand, may be looked at as an example
of successful iterative product development, beginning as a game about
building bases before pivoting to focus more on large-scale multiplayer combat
and eventually user-generated content.

• other example: a sales team might take an iterative approach to sending cold
emails. They might have their reps send a few different email subject lines and
analyze the results. Then, the team can implement the most successful subject
lines moving forward.
69
• Software Development Life Cycle (SDLC) is a
process of maintaining or building software
applications/services/systems. Generally, it
includes various levels, from initial development
plan and analysis to post-development software
testing and evaluation.
• The Agile SDLC model offers a flexible and
iterative approach to software development,
promoting continuous collaboration, rapid
delivery, and ..

70
• An example of iterative and incremental development in
Agile could be the creation of a new e-commerce
website. The project would be broken down into smaller
increments, such as building a wireframe, uploading
products, and creating advertising copy. As these steps
are unfolding, the software development team would
repeat the cycles of prototyping and testing to make
improvements to the website with each iteration.

• So, Iterative and incremental development models are


complementary in nature, which is why they are often
used together to boost their efficacy and achieve
project deliverables
71
5) FOUR TH GENERATION TECHNIQUES
The term fourth generation techniques (4GT) encompasses
a broad array of software tools that have one thing in
common: each enables the software engineer to specify some
characteristic of software at a high level.
The tool then automatically generates source code based on
the developer's specification.
There is little debate that the higher the level at which
software can be specified to a machine, the faster a program
can be built.
The 4GT paradigm for software engineering focuses on the
ability to specify software using specialized language forms
or a graphic notation that describes the problem to be solved
in terms that the customer can understand.
72
FOUR TH GENERATION TECHNIQUES…

Currently, a software development environment


that supports the 4GT paradigm includes some or all
of the following tools:
nonprocedural languages for database query,
report generation, data manipulation, screen
interaction and definition, code generation;
high-level graphics capability;
spreadsheet capability, and automated
generation of HTML and similar languages used for
Website creation using advanced software tools.

73
The need for a software life cycle model
The development team must identify a suitable
life cycle model for the particular project and
then adhere to it.
Without using of a particular life cycle model
the development of a software product would not
be in a systematic and disciplined manner.

 When a software product is being developed by a


team there must be a clear understanding among
team members about when and what to do.
Otherwise it would lead to chaos and project
failure. 74

You might also like