SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
COURSE CODE BCS501

CREDITS 4

SEMESTER V

CIE , SIE 50, 50

COURSE INSTRUCTOR DR.MA.DORAIRANGASWAMY

drdorairs@gmail.com
9940345654
 SOFTWARE ENGINEERING AND
PROJECT MANAGEMENT
COURSE OBJECTIVES:
This course will enable students to,
•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
•Describe the process of requirement gathering, requirement
classification, requirement specification and requirements validation
•Recognize the importance of Project Management with its methods
and methodologies
•Identify software quality parameters and quantify using
measurements and metric . List software quality standards and outline
the practices involved.
 SOFTWARE ENGINEERING AND
PROJECT MANAGEMENT
COURSE OUTCOMES:
At the end of the course, the students will be able to
CO501.1 – DIFFERENTIATE process models to judge which process
model has to be adopted for the given scenarios.
CO501.2 – DERIVE both functional and nonfunctional requirements
from the case study
CO501.3 – ANALYZE the importance of various software testing
methods and agile methodology
CO501.4 – ILLUSTRATE the role of project planning and quality
management in software development
CO501.5 – IDENTIFY appropriate techniques to enhance software
quality.
 SOFTWARE ENGINEERING AND
PROJECT MANAGEMENT
CO – PO MAPPING

PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO PO PO

10 11 12
CO1 2 1 1 - - - 1 - 2 1 1
CO2 2 3 2 2 - 2 1 3 2 3 2 2
CO3 2 3 2 3 3 2 3 3 3 3 3 3
CO4 2 3 2 - 2 3 3 3 3 3 3 3
CO5 2 3 2 - 2 3 3 3 3 3 3 3
SOFTWARE ENGINEERING AND
PROJECT MANAGEMENT
CO – PSO MAPPING

PSO1 PSO2 PSO3

CO1 2 1 3
CO2 2 2 3
CO3 2 3 3
CO4 2 3 3
CO5 2 3 3
 UNIT I
Chapter 1
Software and Software Engineering
- The nature of Software
- The unique nature of Web apps
- Software Engineering
- The Software process
-Software Engineering Practice
-Software Myths

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

 The Nature of Software
Dual Role of Software
Both a product and a vehicle for delivering a product
– Product
• Delivers computing potential
• Produces, manages, acquires, modifies, display, or
transmits information
– Vehicle
• Supports or directly provides system functionality
• Controls other programs (e.g., operating systems)
• Effects communications (e.g., networking software)
• Helps build other software (e.g., software tools)
7
Questions About Software Haven't Changed Over
the Decades
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can't we find all errors before we give the
software to our customers?
• 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?
8
 A Definition of Software

• Instructions (computer programs) that when

executed provide desired features, function,
and performance
• Data structures that enable the programs to
adequately manipulate information
• Documents that describe the operation and
use of the programs
9
 Differences between Software and Hardware
• Software is developed or engineered; it is not
manufactured in the classical sense
– Impacts the management of software projects
• Software doesn't wear out, but it does deteriorate.

• Although the industry is moving toward

component-based construction, most software
continues to be custom built (it is still complex to
build but reusable)

10
 Changing Nature of Software
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software (e.g., inventory control, word processing,
multimedia)
• Web applications
• Artificial intelligence software
• Ubiquitous computing (small, wireless devices)
• Netsourcing (net-wide computing)
• Open source (operating systems, databases, development environments)
• The ".com" marketing applications

11
 Legacy Software - Characteristics
• Support core business functions
• Have longevity and business criticality
• Exhibit poor quality
– Convoluted code, poor documentation, poor testing, poor change management
Do Nothing at least the legacy system must undergo significant change.
Legacy systems evolve for
 The software must be adapted to meet the needs of new computing
environment or technology
 The software must be enhanced to implement new business requirements
 The software must be extended to make it interoperable with other more
modern systems or data bases
 The software must be re-architected to make it viable within a network
environment

12
Reasons for Evolving the Legacy Software
• (Adaptive) Must be adapted to meet the needs
of new computing environments or more
modern systems, databases, or networks
• (Perfective) Must be enhanced to implement
new business requirements
• (Corrective) Must be changed because of
errors found in the specification, design, or
implementation
(Note: These are also the three major reasons for any software maintenance)
13
 The unique nature of Web apps
Web Apps have evolved into a sophisticated
computing tools that provide stand alone function
the end user and also have been integrated with
corporate databases and business application.

Attributes encountered in major webapps are

Network intensiveness, Concurrency, Unpredictable
load, Performance, Availability,
Data driven, content sensitive, continuous evolution,
Immediacy, Security, Aesthetics 14
 Software Engineering
SE – 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
2. The study of approaches as in 1

Layers of Software Engineering:-

Process – The foundation for software engineering. Holds technology layers
together and enables development of computer software.
Basis for management control of software projects, work products, models,
documents, data, reports, forms, ensure quality, manage changes

Methods – Provides the technical how to for building software.

Communication, requirements analysis, design modeling, program construction,
testing and support

Tools – provide automated or semiautomated support for the process and methods.
Integrated tools are called Computer aided software engineering.
15
 The Software Process
The FIVE activities of the process framework for software engineering are
1.Communication
2. Planning
3. Modelling
4.Construction
5.Deployment
These activities are complimented by a number of umbrella activities like
•Software project tracking and control
•Risk management
•Software quality assurance
•Technical reviews
•Measurement
•Software configuration management
•Reusability management
•Work product preparation and production

16
 Software Engineering Practice
The essence of Engineering practice are
1.Understand the problem – Communication
and analysis
2.Plan a solution – modeling and software
design
3.Carry out the plan – code generation
4.Examine the result for accuracy – testing and
quality assurance

17
 Software Myths - Management
• "We already have a book that is full of standards and
procedures for building software. Won't that provide my
people with everything they need to know?"
– Not used, not up to date, not complete, not focused on
quality, time, and money
• "If we get behind, we can add more programmers and
catch up"
– Adding people to a late software project makes it later
– Training time, increased communication lines
• "If I decide to outsource the software project to a third
party, I can just relax and let that firm build it"
– Software projects need to be controlled and managed
18
 Software Myths - Customer
• "A general statement of objectives is sufficient to
begin writing programs – we can fill in the details
later"
– Ambiguous statement of objectives spells
disaster
• "Project requirements continually change, but
change can be easily accommodated because
software is flexible"
– Impact of change depends on where and when it
occurs in the software life cycle (requirements
analysis, design, code, test)
19
 Software Myths - Practitioner
• "Once we write the program and get it to work, our job is done"
– 60% to 80% of all effort expended on software occurs after it is
delivered
• "Until I get the program running, I have no way of assessing its
quality
– Formal technical reviews of requirements analysis documents,
design documents, and source code (more effective than actual
testing)
• "The only deliverable work product for a successful project is the
working program"
– Software, documentation, test drivers, test results
• "Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us down"
– Creates quality, not documents; quality reduces rework and
provides software on time and within the budget 20
