Software Engineering & Project Management

(21CS61)

Department: CSE

1
 Text Book Details
1. Roger S. Pressman: Software Engineering-A Practitioners
approach, 7th Edition, Tata McGraw Hill.

M 2.Bob Hughes, Mike Cotterell, Rajib Mall: Software Project

O
D
U
Management, 6th Edition, McGraw Hill Education, 2018.
L
E
Reference:
1

1. Pankaj Jalote: An Integrated Approach to Software Engineering,

Wiley India.

SE&PM 2
 Weblinks and Video Lectures (e-
Resources)

1. https://onlinecourses.nptel.ac.in/noc20_cs68/preview

M 2. https://www.youtube.com/watch?v=WxkP5KR_Emk&list=PLrjkTql3jnm9b5nrggx7Pt1G4UAHeFlJ
O
D
U 3. http://elearning.vtu.ac.in/econtent/CSE.php
L
E 4. http://elearning.vtu.ac.in/econtent/courses/video/CSE/15CS42.html
1
5. https://nptel.ac.in/courses/128/106/128106012/ (DevOps)

SE&PM 3
 Course Learning Objectives
CLO 1. Outline software engineering principles and activities involved in
building large software programs. Identify ethical and professional issues and
explain why they are of concern to Software Engineers.
M
O
D CLO 2. Describe the process of requirement gathering, requirement
U
L classification, requirement specification and requirements validation.
E

1
CLO 3. Understand the need for Agile method and tools over the traditional
method of software development methods.

CLO 4. Discuss various types of software testing practices and software

evolution processes.
SE&PM 4
 Course Learning Objectives
CLO 5. Recognize the importance Project Management with its
methods and methodologies

M CLO 6. Identify software quality parameters and quantify software

O
D
U
using measurements and metrics. List software quality standards and
L
E outline the practices involved
1

SE&PM 5
 Assessment Details

M
O
D
U
L
E

SE&PM 6
 Course Outcomes
CO 1. Understand the activities involved in software engineering and analyze
the role of various process models.

CO 2. Explain the necessity of knowing the requirements, then analyze and

M
O design the software.
D
U
L CO 3. Understand the agile development methods used in developing software.
E

1
CO 4. Illustrate the role of project planning and management of the project in
software development

CO 5. Understand the importance of quality management methods in software

engineering.

SE&PM 7
 MODULE 1

Syllabus:
--Software and Software Engineering: The nature of Software,
M
O The unique nature of WebApps, Software Engineering, The
D
U
L
software Process, The software Engineering practice, The
E

1
software myths, How it all starts

Textbook 1: Chapter 1: 1.1 to 1.7

SE&PM 8
 MODULE 1

Syllabus:
Process Models: A generic process model, Process
M
O
D
assessment and improvement, Prescriptive process models,
U
L
E
Waterfall model, Incremental process models, Evolutionary
1
process models, Concurrent models, Specialized process
models.

Textbook 1: Chapter 2: 2.1 to 2.4

SE&PM 9
 MODULE 1

M
O
D
U
L
E

SE&PM 10
 What is SOFTWARE ENGINEERING?

Software Engineering is defined as a process of :

✓ Analyzing user requirements

M
O
D
U
✓ Designing
L
E

1
✓ Developing

✓ Testing

✓ Maintenance of the Software

SE&PM 11
 1.1 THE NATURE OF SOFTWARE[1]
• Software’s Dual Role
• Software as a Product
✓ Transforms Information – produces, manages, acquires, modifies, displays, or
transmits information.

M
O ✓ Delivers computing potential of hardware and networks.
D
U
L
E • Software is a Vehicle for delivering a product
1 ✓Controls other programs ( Operating Systems )

✓ Effects Communications ( Networking Software )

✓ Helps build other software ( Software Tools & Environments )

SE&PM 12
 1.1.1 Defining Software
• Same set of questions were still asked to both Lone Programmers and even
now, such as

M ▪ Why does it take so long to get software finished ?

O
D
U ▪ Why are development costs so high ?
L
E

1 ▪ Why cant we find all errors before we give the software to our customer ?

▪ Why do we spend so much time and effort maintaining existing programs ?

▪ Why do we continue to have difficulty in measuring progress as software is being

developed and maintained ?

SE&PM 13
 1.1 THE NATURE OF SOFTWARE[3]
• Software is defined as:

- Instructions (computer programs) that when

executed provide desired features, function and
M performance.
O
D
U
L -Data structures that enable the programs to
E
adequately manipulate information.
1

- Descriptive information in both hard copy and

virtual forms that describes the operation and use of the
programs.

SE&PM 14
 Characteristics of Software[1]
• 1.Software is a Logical element rather than a Physical System
element.
✓ Software is developed or engineered; it is not manufactured in
the classical sense.
M ✓ 2.Software doesn’t “Wear Out”.
O
D
U ❖ This indicates that Hardware exhibits relatively
L high failure rates early in its life (due to design or
E
manufacturing defects)
1
❖ Defects are then corrected and failure rate drops
to steady state for some period of time.
❖ As time passes, failure rate rises again as
hardware components can fail to work.

SE&PM 15
 Characteristics of Software[2]
• The below figure depicts the Failure curve for Software
• 3.Although the industry is moving toward component-based
construction, most software continue to be custom built.

M
O
D
U
L
❖ Undiscovered defects will cause high
E failure rates in the life of a program.
1
❖ Later they are corrected and the
curve flattens.

SE&PM 16
 1.1.2 Software Application Domains[1]
• There are now 7 broad categories of computer Software that continue
giving challenges to Software Engineers

M 1. System Software
O
D 2. Application Software
U
L
E
3. Engineering/Scientific Software
1 4. Embedded Software
5. Product-Line Software
6. Web-Applications
7. Artificial Intelligence Software

SE&PM 17
 1.1.2 Software Application Domains[2]
• System software:
• a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities)
M processes complex, but determinate, information structures.
O
D
U • the systems software area is characterized by heavy interaction with
L
E
computer hardware
1

SE&PM 18
 1.1.2 Software Application Domains[3]
Application software:

-stand-alone programs that solve a specific business need. Application

M
s in this area process business or technical data in a way that facilitates
O
D business operations or management/technical decision making.
U
L
E -In addition to conventional data processing applications, application
1
software is used to control business functions in real time

SE&PM 19
 1.1.2 Software Application Domains[3]
Type of Software Description
System Software ➔ System software is a collection of programs written to service other
programs
➔ Example: Compilers, Editors, File management utilities
Application Software ➔ consists of standalone programs that solve a specific business need.
M
O
➔ process Business or Technical data
D Engineering/Scientific ➔ Range from Astronomy to Volcanology, Automotive to Space, etc..
U
L Software ➔ Nowadays to handle real time data, we have Computer-Aided Deisgn,
E System Simulation etc.
1 Embedded Software ➔ resides within a product or system
➔ Example: Digital functions in an automobile such as Fuel Control, Braking
systems etc
Product-Line Software ➔ Can focus on limited and specific marketplace products
➔ Example: Word processing, multimedia, entertainment etc.
Web-Applications ➔ “WebApps” span a wide variety of applications used over a Network
Artificial Intelligence Software ➔ Makes use of non-numerical algorithms to solve complex problems
➔ Applications within
SE&PM this area includes Robotics, Expert Systems, Pattern 20
 Recap Lecture1
• Software Engineering

• Nature of Software Engineering

M • Domains of Software Engineering

O
D
U
L
E

SE&PM 21
 Lecture 2
• Legacy software

• Unique nature of Webapps

M
O
D
U
L
E

SE&PM 22
 Legacy software[1]
• Very old Software

• Developed Decades ago

M • Inextendible Design
O
D
U • No documentation
L
E
• Can’t meet the needs of new technologies
1

SE&PM 23
 Legacy software[2]
➢ Legacy software systems were developed decades ago and have been
continually modified to meet changes in business requirements and
computing platforms.
M
O ➢ The proliferation of such systems is causing headaches for large
D
U
L
organizations who find them costly to maintain and risky to evolve.
E

1
➢ Many legacy systems remain supportive to core business functions
and are ‘indispensable’ to the business.”

➢ Unfortunately, there is sometimes one additional characteristic that is

present in legacy software—poor quality.
SE&PM 24
 Legacy software[3]
➢ The only reasonable answer may be: Do nothing, at least until the legacy system
must undergo some significant change.
➢ If the legacy software meets the needs of its users and runs reliably, it isn’t broken
and does not need to be fixed.
However, as time passes, legacy systems often evolve for one or more of the following
M reasons:
O
D • The software must be adapted to meet the needs of new computing environments
U or technology.
L
E • The software must be enhanced to implement new business requirements.
1 • The software must be extended to make it interoperable with other more modern
systems or databases.
• The software must be re-architected to make it viable within a network
environment.
When these modes of evolution occur, a legacy system must be reengineered so that it
remains viable into the future.
SE&PM 25
 1.2 The unique nature of webApps[1]

M
O
D
U
L
E

SE&PM 26
 1.2 The unique nature of webApps[2]
➢ Today, WebApps have evolved into sophisticated computing tools that
not only provide stand-alone function to the end user, but also have
been integrated with corporate databases and business applications.
M
O
D ➢ Web-based systems and applications “involve a mixture between
U
L
E
print publishing and software development, between marketing and
1 computing, between internal communications and external relations,
and between art and technology.”

SE&PM 27
 1.2 The unique nature of webApps[3]
Attributes of WebApps:
• Network intensiveness
• Concurrency
• Unpredictable load
M
O
• Performance
D
U
• Availability
L
E
• Data driven
1
• Content sensitive
• Continuous evolution
• Immediacy
• Security
• Aesthetics(Look & feel)
SE&PM 28
 Recap Lecture 2
• Legacy software

• Unique nature of Webapps

M
O
D
U
L
E

SE&PM 29
 Lecture 3
• Software Engieering

• Software Process

M • Software Myths
O
D
U
L
E

SE&PM 30
 1.3 Software Engineering[1]
➢ Software has become deeply embedded in virtually every aspect of
our lives, and consequently, the number of people who have an
interest in the features and functions provided by a specific
application has grown dramatically.
M
‘’It follows that a concerted effort should be made to understand
O the problem before a software solution is developed.’’
D
U
L
E ➢ The information technology requirements demanded by individuals,
1 businesses, and governments grow increasing complex with each
passing year.
‘’It follows that design becomes a pivotal activity.’’

SE&PM 31
 1.3 Software Engineering[2]
➢ Individuals, businesses, and governments increasingly rely on
software for strategic and tactical decision making as well as day-to-
day operations and control.
M
O
D ‘’It follows that software should exhibit high quality.’’
U
L
E ➢ As the perceived value of a specific application grows, the likelihood
1
is that its user base and longevity will also grow.

‘’It follows that software should be maintainable.’’

SE&PM 32
 Software engineering-Definitions[1]
Fritz Bauer [Nau69]:
➢ [Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically software that is
reliable and works efficiently on real machines.
M
O
D IEEE [IEE93a]:
U
L
E
➢ Software Engineering:
1
➢ The application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is,
the application of engineering to software.

SE&PM 33
 Software engineering-Definitions[2]
• Software engineering is a layered technology.

• Software engineering is a quality focus.

M • The foundation for software engineering is the process layer.

O
D
U • The bedrock that supports software engineering is a quality focus.
L
E

SE&PM 34
 Software engineering-Definitions[3]
➢ Process defines a framework that must be established for effective
delivery of software engineering technology.

➢ Software engineering methods provide the technical how-to’s for

M
O building software.
D
U
L ➢ Methods encompass a broad array of tasks that include communication,
E
requirements analysis, design modeling, program construction, testing,
1
and support

➢ Software engineering tools provide automated or semiautomated

support for the process and the methods.

SE&PM 35
 1.4 The software process[1]
➢ A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
➢ An activity strives to achieve a broad objective (e.g., communication with
M stakeholders) and is applied regardless of the application domain, size of
O
D the project, complexity of the effort, or degree of rigor with which
U
L software engineering is to be applied.
E

1 ➢ An action (e.g., architectural design) encompasses a set of tasks that

produce a major work product (e.g., an architectural design model).
➢ A task focuses on a small, but well-defined objective (e.g., conducting a
unit test) that produces a tangible outcome.

SE&PM 36
 1.4 The software process[1]

1.Tasks: They focus on a

small, specific objective.
M
O
2.Action: It is a set of
D
U tasks that produce a major
L
E work product.
1
3.Activities: Activities
are groups of related tasks
and actions for a major
objective.
SE&PM 37
 1.4 The software process[2]
• A process framework establishes the foundation for a complete software
engineering process by identifying a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity.

M A generic process framework for software engineering encompasses five activities:

O
D
U ➢ Communication
L
E ➢ Planning
1
➢ Modeling

➢ Construction

➢ Deployment

SE&PM 38
 1.4 The software process[3]
Software engineering process framework activities are complemented by a number of
umbrella activities. Typical umbrella activities include:

❑ Software project tracking and control

M
O ❑ Risk management
D
U
L
❑ Software quality assurance
E
❑ Technical reviews
1

❑ Measurement

❑ Software configuration management

❑ Reusability management

❑ Work product preparation and production

SE&PM 39
 1.5 SOFTWARE ENGINEERING PRACTICE

• a basic understanding of the generic concepts and principles that apply to

framework activities

• The Essence of Practice

M
O 1. Understand the problem (communication and analysis).
D
U 2. Plan a solution (modeling and software design)
L
E
3. Carry out the plan (code generation).
1
4. Examine the result for accuracy (testing and quality assurance)

SE&PM 40
 1.5.2 General Principles
The dictionary defines the word
• The First Principle: The Reason It All Exists

• The Second Principle: KISS (Keep It Simple, Stupid!)

M
O
D • The Third Principle: Maintain the Vision
U
L
E • The Fourth Principle: What You Produce, Others Will Consume
1
• The Fifth Principle: Be Open to the Future

• The Sixth Principle: Plan Ahead for Reuse

• The Seventh principle: Think!

SE&PM 41
SOFTWARE ENGINEERING PRACTICE
❖General Principles
1. The Reason It All Exists
-A software system exists for one reason: to provide value to
its users . “Does this add real value to the system?” If the
answer is “no,” don’t do it.
2. KISS (Keep It Simple, Stupid!)
All design should be as simple as possible, but no simpler. This
facilitates having a more easily understood and easily
maintained system.
3. Maintain the Vision
A clear vision is essential to the success of a software project
4. What You Produce, Others Will Consume
always specify, design, and implement knowing someone else will have to
understand what you are doing
5. Be Open to the Future
system with a long lifetime has more value. systems must be ready to
adapt to these and other changes. Never design yourself into a corner.
Always ask “what if,” and prepare for all possible answers by creating
systems that solve the general problem.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is arguably
the hardest goal to accomplish in developing a software system.
Planning ahead for reuse reduces the cost and increases the value of
both the reusable components and the systems into which they are
incorporated.
7. Think!
Placing clear, complete thought before action almost always produces
better results. When you think about something, you are more likely to
do it right. You also gain knowledge about how to do it right again
 1.6Software Myths
• erroneous beliefs about software and the process that is used to
build it.
• Myths have number of attributes that causes serious problem on
software.
M
O • Types of Myths:
D • Management myths
U
L • Customer myths
E
• Practitioner’s myths / Developer myths
1

SE&PM 44
 1.6Software Myths

Management myths.

Myth 1: We already have a book that’s full of standards and procedures

M
for building software. Won’t that provide my people with everything
O they need to know?
D
U Myth 2: If we get behind schedule, we can add more programmers and
L
E catch up
1 Myth 3: If I decide to outsource the software project to a third party, I
can just relax and let that firm build it.

SE&PM 45
 1.6Software Myths

Customer myths.

Myth 1: A general statement of objectives is sufficient to begin writing programs—

M we can fill in the details later..
O
D
U
L Myth 2: Software requirements continually change, but change can be easily
E
accommodated because software is flexible.
1

SE&PM 46
 1.6Software Myths
Practitioner’s myths/Developer myths.
Myth 1: Once we write the program and get it to work, our job is done.

M Myth 2: Until I get the program “running” I have no way of assessing its quality
O
D
U
L Myth 3: The only deliverable work product for a successful project is the working
E
Program
1

Myth 4: Software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down

SE&PM 47
End of chapter-01

48