Introduction to Software Engineering for the course of Structured System Analysis and Design

1. 1
Introduction to Software Engineering
Preeti Mishra
Course Instructor

2. Basics:
Software & Software Engineering

3. What is
Software?
The product that software professionals build and then support
over the long term.
Software encompasses:
(1) instructions (computer programs) that when executed provide
desired features, function, and performance;
(2) data structures that enable the programs to adequately store and
manipulate information and
(3) documentation that describes the operation and use of the
programs.

4. Software products
• Generic products
– Stand-alone systems that are
marketed and sold to any customer
who wishes to buy them.
– Examples – PC software such as
editing, graphics programs, project
management tools
• Customized products
– Software that is commissioned by a
specific customer to meet their own
needs.
– Examples – embedded control
systems, air traffic control software,
traffic monitoring systems.

5. Software Categories
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number
crunching”algorithms. such as automotive stress analysis, molecular biology,
orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass
consumer market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges,
more sophisticated computing environments is supported integrated with remote
database and business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem.
Robotics, expert system, pattern recognition game playing

6. Software—New Categories
• Open world computing—pervasive, ubiquitous, distributed computing
due to wireless networking. How to allow mobile devices, personal
computer, enterprise system to communicate across vast network.
• Netsourcing—the Web as a computing engine. How to architect simple
and sophisticated applications to target end-users worldwide.
• Open source—”free” source code open to the computing community (a
blessing, but also a potential curse!)
• Also … (see Chapter 31)
– Data mining
– Grid computing
– Cognitive machines
– Software for nanotechnologies

7. Why Software is Important?
• The economies of ALL developed nations
are dependent on software.
• More and more systems are software
controlled ( transportation, medical,
telecommunications, military, industrial,
entertainment,)
• Software engineering is concerned with
theories, methods and tools for
professional software development.
• Expenditure on software represents a
significant fraction of GNP in all developed
countries.

8. Software costs
• Software costs often dominate computer system costs.
The costs of software on a PC are often greater than the
hardware cost.
• Software costs more to maintain than it does to
develop. For systems with a long life, maintenance costs
may be several times development costs.
• Software engineering is concerned with cost-effective
software development.

9. Features of Software?
• Its characteristics that make it different
from other things human being build.
Features of such logical system:
• Software is developed or engineered, it is
not manufactured in the classical sense
which has quality problem.
• Software doesn't "wear out.” but it
deteriorates (due to change). Hardware has
bathtub curve of failure rate ( high failure rate
in the beginning, then drop to steady state, then
cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward
component-based construction, most
software continues to be custom-built.
• Modern reusable components
encapsulate data and processing into
software parts to be reused by different
programs. E.g. graphical user interface,
window, pull-down menus in library etc.

10. Wear vs. Deterioration
10
idealizedcurve
change
actualcurve
Failure
rate
Time
increasedfailure
rate due toside effects

11. The IEEE definition:
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.
(2) The study of approaches as in (1).
The seminal definition:
[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.
Software Engineering Definition

12. Importance of Software Engineering
• More and more, individuals and society rely on advanced software
systems. We need to be able to produce reliable and trustworthy
systems economically and quickly.
• It is usually cheaper, in the long run, to use software engineering
methods and techniques for software systems rather than just write
the programs as if it was a personal programming project. For most
types of system, the majority of costs are the costs of changing the
software after it has gone into use.

13. FAQ about software engineering
Question Answer
What is software? Computer programs, data structures and associated
documentation. Software products may be developed for
a particular customer or may be developed for a general
market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software
engineering and system engineering?
System engineering is concerned with all aspects of
computer-based systems development including
hardware, software and process engineering. Software
engineering is part of this more general process.

14. Essential attributes of good
software
Product characteristic Description
Maintainability • Software should be written in such a way so that it can evolve to meet the
changing needs of customers.
• This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
Dependability and security • Software dependability includes a range of characteristics including
• reliability,
• security and
• safety.
• Dependable software should not cause physical or economic damage in the
event of system failure.
• Malicious users should not be able to access or damage the system.
Efficiency • Software should not make wasteful use of system resources such as memory
and processor cycles.
• Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.
Acceptability • Software must be acceptable to the type of users for which it is designed.
• This means that it must be understandable, usable and compatible with other
systems that they use.

16. Questions!!

17. Software Process

18. A Layered Technology
aa “quality” focus“quality” focus
process modelprocess model
methodsmethods
toolstools
 Any engineering approach must rest on organizational commitment to quality which fosters a
continuous process improvement culture.
 Process
 Method
 Tools

19. Process, Methods, and Tools
• Process
– Provides the glue that holds the layers together; enables rational and
timely development; provides a framework for effective delivery of
technology; forms the basis for management; provides the context
for technical methods, work products, milestones, quality measures,
and change management
• Methods
– Provide the technical "how to" for building software; rely on a set of
basic principles; encompass a broad array of tasks; include modeling
activities
• Tools
– Provide automated or semi-automated support for the process and
methods (i.e., CASE tools)

20. Process??
• (Webster) A system of operations in producing
something; a series of actions, changes, or functions
that achieve an end or a result
• (IEEE) A sequence of steps performed for a given
purpose

21. What is a Software Process?
• (SEI) A set of activities, methods, practices, and
transformations that people use to develop and maintain
software and the associated products (e.g., project plans,
design documents, code, test cases, and user manuals)
• As an organization matures, the software process becomes
better defined and more consistently implemented throughout
the organization
• Software process maturity is the extent to which a specific
process is explicitly defined, managed, measured, controlled,
and effective

22. Five Activities of a Generic Process
framework
• Communication: communicate with customer to understand objectives
and gather requirements
• Planning: creates a “map” defines the work by describing the tasks, risks
and resources, work products and work schedule.
• Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
• Construction: code generation and the testing.
• Deployment: Delivered to the customer who evaluates the products and
provides feedback based on the evaluation.
• These five framework activities can be used to all software development
regardless of the application domain, size of the project, complexity of
the efforts etc, though the details will be different in each case.
• For many software projects, these framework activities are applied
iteratively as a project progresses. Each iteration produces a software
increment that provides a subset of overall software features and
functionality.

23. Umbrella Activities
Complement the five process framework activities and help team manage and
control progress, quality, change, and risk.
1. Software project tracking and control: assess progress against the plan and
take actions to maintain the schedule.
2. Risk management: assesses risks that may affect the outcome and quality.
3. Software quality assurance: defines and conduct activities to ensure quality.
4. Technical reviews: assesses work products to uncover and remove errors
before going to the next activity.
5. Measurement: define and collects process, project, and product measures
to ensure stakeholder’s needs are met.
6. Software configuration management: manage the effects of change
throughout the software process.
7. Reusability management: defines criteria for work product reuse and
establishes mechanism to achieve reusable components.
8. Work product preparation and production: create work products such as
models, documents, logs, forms and lists.

24. Software Myths

25. Software Myths
Erroneous beliefs about software and the process that is used
to build it.
•Affect managers, customers (and other non-technical
stakeholders) and practitioners
•Many people recognize the fallacy of the myths. Regrettably,
habitual attitudes and methods
•Poor management and technical practices, even when reality
dictates a better approach.

26. Management Myths
• We already have standards and procedures for building software;
isn’t that enough?
– How widely used is it?
– How relevant to the team?
– How useful to the project?
• If we’re behind schedule, we’ll just add more programmers to
catch up
– “Adding people to a late project makes it later” [Brooks]
– Ramp-up time
– Interference
• If I outsource a project, I can just relax
– Management issues are much more difficult, and if not
understood, will sink the project

27. Customer Myths
• A general statement of work is sufficient to kick off the
project, and we can fill in the details later
• Requirements can change, and that’s OK because software is so
flexible
-Most software project failures can be traced to inadequacy of
requirement specifications

28. Software Engineers’ Myths
• Once the program is written, I’m done
– Between 60-80% of effort expended after
delivery
• Until the program is written, quality is
uncertain
– Formal design reviews
– Formal code reviews
– Test-first approaches
– Prototyping to verify design and structure
– Prototyping to validate requirements
• The only deliverable is the program itself
– Lots of documentation: installation guides,
usage guides, maintenance guides, API
defintions and examples

29. Software Engineers’ Myths
• Documentation is Software-Engineering busy work
– Focus is on quality, not quantity
– Documentation can be hard for engineers to write, just as
C++ may be difficult for poets.

30. Legacy Software

31. What is Legacy System
• In computing, a legacy system is an old method, technology,
computer system, or application program, "of, relating to, or
being a previous or outdated computer system.“
• Often a pejorative term, referencing a system as "legacy" often
implies that the system is out of date or in need of replacement.

32. Legacy Software -
Characteristics
• Support core business functions
• Have longevity and business criticality
• Exhibit poor quality
– Convoluted code, poor documentation, poor testing, poor change
management

33. Why Organizations can have compelling reasons for keeping a legacy
S/W
• The system works satisfactorily, and the owner sees no reason to change it.
• The costs of redesigning or replacing the system are prohibitive because it
is large, monolithic, and/or complex.
• Retraining on a new system would be costly in lost time and money,
compared to the anticipated appreciable benefits of replacing it
• The system requires near-constant availability, so it cannot be taken out of
service, and the cost of designing a new system
• The user expects that the system can easily be replaced when this becomes
necessary.
• Newer systems perform undesirable (especially for individual or non-
institutional users)

34. Problems posed by legacy Software
• If legacy software runs on only antiquated hardware, the cost of maintaining
the system may eventually outweigh the cost of replacing both the software
and hardware unless
• These systems can be hard to maintain, improve, and expand because
there is a general lack of understanding of the system; the staff who were
experts on it have retired or forgotten what they knew about it, and staff who
entered the field after it became "legacy" never learned about it in the first
place. This can be worsened by lack or loss of documentation.
• Legacy systems may have vulnerabilities in older operating systems or
applications due to lack of security patches being available or applied.
• Integration with newer systems may also be difficult because new software
may use completely different technologies.

35. 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

36. Software Project Planning
The act or process of making a plan or plans.

37. Task Set for Project Planning
1) Establish project scope
2) Determine feasibility
3) Analyze risks
4) Define required resources
a) Determine human resources required
b) Define reusable software resources
c) Identify environmental resources
5) Estimate cost and effort
a) Decompose the problem
b) Develop two or more estimates using different approaches
c) Reconcile the estimates
6) Develop a project schedule
a) Establish a meaningful task set
b) Define a task network
c) Use scheduling tools to develop a timeline chart
d) Define schedule tracking mechanisms

38. Software Scope
• Software scope describes
– The functions and features that are to be delivered to end users
– The data that are input to and output from the system
– The "content" that is presented to users as a consequence of using the software
– The performance, constraints, interfaces, and reliability that bound the system
• Scope can be define using two techniques
– A narrative description of software scope is developed after communication with
all stakeholders
– A set of use cases is developed by end users
• After the scope has been identified, two questions are asked
– Can we build software to meet this scope?
– Is the project feasible?

39. Feasibility
• Software feasibility has four
dimensions
– Technology – Is the project
technically feasible? Is it within the
state of the art? Can defects be
reduced to a level matching the
application's needs?
– Finance – Is financially feasible?
Can development be completed at
a cost that the software
organization, its client, or the
market can afford?
– Time – Will the project's time-to-
market beat the competition?
– Resources – Does the software
organization have the resources
needed to succeed in doing the
project?

40. Software Project Estimation

41. Estimation
• “The single most important task of a project: setting
realistic expectations.
Unrealistic expectations based on inaccurate estimates are
the single largest cause of software failure.”
Futrell, Shafer and Shafer, “Quality Software Project Management”

42. Why its important to you!
• Program development of large software systems normally
experience 200-300% cost overruns and a 100% schedule
slip
• 15% of large projects deliver…NOTHING!
• Key reasons…poor management and inaccurate estimations
of development cost and schedule
• If not meeting schedules, developers often pay the price!

43. The Problems
• Predicting software cost
• Predicting software schedule
• Controlling software risk
• Managing/tracking project as it progresses

44. Resource Estimation
• Three major categories of software engineering resources
– People
– Development environment
– Reusable software components
• Often neglected during planning but become a paramount concern
during the construction phase of the software process
• Each resource is specified with
– A description of the resource
– A statement of availability
– The time when the resource will be required
– The duration of time that the resource will be applied
Time window

45. Categories of Resources
People
- Number required
- Skills required
- Geographical location
Development Environment
- Software tools
- Computer hardware
- Network resources
Reusable Software Components
- Off-the-shelf components
- Full-experience components
- Partial-experience components
- New components
The
Project

46. Estimation of Project Cost and
Effort

49. Factors Affecting Project Estimation
• The accuracy of a software project estimate is predicated on
– The degree to which the planner has properly estimated the of the product to be
built
– The ability to translate the size estimate into human effort, calendar time, and
money
– The degree to which the project plan reflects the abilities of the software team
– The stability of both the product requirements and the environment that supports
the software engineering effort

50. Project Estimation Options
• Options for achieving reliable cost and effort estimates
1) Delay estimation until late in the project (we should be able to
achieve 100% accurate estimates after the project is complete)
2) Base estimates on similar projects that have already been
completed
3) Use relatively simple decomposition techniques to generate
project cost and effort estimates
4) Use one or more empirical estimation models for software cost
and effort estimation
• Option #1 is not practical, but results in good numbers
• Option #2 can work reasonably well, but it also relies on other
project influences being roughly equivalent
• Options #3 and #4 can be done in tandem to cross check
each other

51. Project Estimation Approaches
• Decomposition techniques
– These take a "divide and
conquer" approach
– Cost and effort estimation are
performed in a stepwise fashion
by breaking down a project into
major functions and related
software engineering activities
• Empirical estimation models
– Offer a potentially valuable
estimation approach if the
historical data used to seed the
estimate is good

52. Decomposition Techniques
• Before an estimate can be made and decomposition techniques
applied, the planner must
– Understand the scope of the software to be built
– Generate an estimate of the software’s size
• Then one of two approaches are used
– Problem-based estimation
• Based on either source lines of code or function point estimates
– Process-based estimation
• Based on the effort required to accomplish each task

53. Approaches to Software Sizing
• Function point sizing
– Develop estimates of the information domain characteristics (Ch. 15 –
Product Metrics for Software)
• Standard component sizing
– Estimate the number of occurrences of each standard component
– Use historical project data to determine the delivered LOC size per standard
component
• Change sizing
– Used when changes are being made to existing software
– Estimate the number and type of modifications that must be accomplished
– Types of modifications include reuse, adding code, changing code, and
deleting code
– An effort ratio is then used to estimate each type of change and the size of
the change

54. Problem-Based Estimation
1) Start with a bounded statement of scope
2) Decompose the software into problem functions that can each
be estimated individually
3) Compute an LOC or FP value for each function
4) Derive cost or effort estimates by applying the LOC or FP
values to your baseline productivity metrics (e.g.,
LOC/person-month or FP/person-month)
5) Combine function estimates to produce an overall estimate
for the entire project

55. Process-Based Estimation
1) Identify the set of functions that the software needs to perform as
obtained from the project scope
2) Identify the series of framework activities that need to be performed for
each function
3) Estimate the effort (in person months) that will be required to accomplish
each software process activity for each function
4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for
each process activity
5) Compute the total cost and effort for each function and each framework
activity
6) Compare the resulting values to those obtained by way of the LOC and
FP estimates
• If both sets of estimates agree, then your numbers are highly reliable
• Otherwise, conduct further investigation and analysis concerning the function
and activity breakdown

56. Reconciling Estimates
• The results gathered from the various estimation techniques
must be reconciled to produce a single estimate of effort, project
duration, and cost
• If widely divergent estimates occur, investigate the following
causes
– The scope of the project is not adequately understood or has been
misinterpreted by the planner
– Productivity data used for problem-based estimation techniques is
inappropriate for the application, obsolete (i.e., outdated for the
current organization), or has been misapplied
• The planner must determine the cause of divergence and then
reconcile the estimates

57. Empirical Estimation Models
• Estimation models for computer software use empirically derived formulas to
predict effort as a function of LOC or FP
• Resultant values computed for LOC or FP are entered into an estimation
model
• The empirical data for these models are derived from a limited sample of
projects
– Consequently, the models should be calibrated to reflect local software
development conditions

58. COCOMO
• Stands for COnstructive COst MOdel
• Introduced by Barry Boehm in 1981 in his book “Software
Engineering Economics”
• Became one of the well-known and widely-used estimation
models in the industry
• It has evolved into a more comprehensive estimation model
called COCOMO II
• COCOMO II is actually a hierarchy of three estimation models
• As with all estimation models, it requires sizing information and
accepts it in three forms: object points, function points, and lines
of source code

59. COCOMO Models
• Application composition model - Used during the early
stages of software engineering when the following are important
– Prototyping of user interfaces
– Consideration of software and system interaction
– Assessment of performance
– Evaluation of technology maturity
• Early design stage model – Used once requirements have
been stabilized and basic software architecture has been
established
• Post-architecture stage model – Used during the
construction of the software

60. An Example: COCOMO Model
• We consider the COCOMO (Constructive Cost Model) .
• Decompose the software into small enough units to be able to estimate the LOC.
• Definitions:
– KDSI as kilo delivered source instructions (statements)
• not including comments, test drivers, etc.
– PM - person months
• 3 levels of the Cocomo models: Basic, Intermediate and, Detailed (We will not see
the last one here)
Apply the following formulae to get rough estimates:
– PM = 2.4(KDSI)1.05
– TDEV
= 2.5(PM)0.38
(chronological months)

62. Software Project Management
Project: Planned set of interrelated tasks to be executed
over a fixed period and within certain cost and other
limitations.

63. The Management Spectrum
• Effective software project management
focuses on these items (in this order)
– The people
• Deals with the cultivation of motivated,
highly skilled people
• Consists of the stakeholders, the team
leaders, and the software team
– The product
• Product objectives and scope should be
established before a project can be
planned
– The process
• The software process provides the
framework from which a comprehensive
plan for software development can be
established
– The project
• Planning and controlling a software
project is done for one primary reason…
it is the only known way to manage
complexity

64. People
Product
Process
Project

65. The People: The Stakeholders
• Five categories of stakeholders
– Senior managers – define business issues that often have significant
influence on the project
– Project (technical) managers – plan, motivate, organize, and control
the practitioners who do the work
– Practitioners – deliver the technical skills that are necessary to engineer
a product or application
– Customers – specify the requirements for the software to be engineered
and other stakeholders who have a peripheral interest in the outcome
– End users – interact with the software once it is released for production
use

66. 66
People
Product
Process
Project

67. The Product
• The scope of the software development must be established
and bounded
– Context – How does the software to be built fit into a larger
system, product, or business context, and what constraints are
imposed as a result of the context?
– Information objectives – What customer-visible data objects are
produced as output from the software? What data objects are
required for input?
– Function and performance – What functions does the software
perform to transform input data into output? Are there any special
performance characteristics to be addressed?
• Software project scope must be unambiguous and
understandable at both the managerial and technical levels

68. 68
People
Product
Process
Project

69. The Process
• Getting Started
– The project manager must decide which process model is most
appropriate based on
• The customers who have requested the product and the people who
will do the work
• The characteristics of the product itself
• The project environment in which the software team works
– Once a process model is selected, a preliminary project plan is
established based on the process framework activities
– Process decomposition then begins
– The result is a complete plan reflecting the work tasks required to
populate the framework activities
• Project planning begins as a melding of the product and the
process based on the various framework activities

70. 70
People
Product
Process
Project

71. The Project: A Common Sense Approach
• Start on the right foot
– Understand the problem; set realistic objectives and expectations; form a
good team
• Maintain momentum
– Provide incentives to reduce turnover of people; emphasize quality in every
task; have senior management stay out of the team’s way
• Track progress
– Track the completion of work products; collect software process and project
measures; assess progress against expected averages
• Make smart decisions
– Keep it simple; use COTS or existing software before writing new code;
follow standard approaches; identify and avoid risks; always allocate more
time than you think you need to do complex or risky tasks
• Conduct a post mortem analysis
– Track lessons learned for each project; compare planned and actual
schedules; collect and analyze software project metrics; get feedback from
teams members and customers; record findings in written form

72. The Project: The W5
HH Principle
• Why is the system being developed?
– Assesses the validity of business reasons and justifications
• What will be done?
– Establishes the task set required for the project
• When will it be done?
– Establishes a project schedule
• Who is responsible for a function?
– Defines the role and responsibility of each team member
• Where are they organizationally located?
– Notes the organizational location of team members, customers, and other
stakeholders
• How will the job be done technically and managerially?
– Establishes the management and technical strategy for the project
• How much of each resource is needed?
– Establishes estimates based on the answers to the previous questions
A series of questions that lead to a definition of key project characteristics
and the resultant project plan

73. Summary
People
Product
Process
Project

74. End of Unit 1:
Introduction to Software Engineering

75. FAQ on Unit 1
Type Examples
What/Define Software, Software Engineering, legacy Software,
software process, project planning, estimation,
management…..
list Software Myths, legacy s/w characteristics, generic
process framework activities, umbrella activities,
project management activities, ways to do
estimation, models for estimation emperically…
Reason/ Why Use Software Engg, use process framework, use of
legacy s/w, each s/w myth, why plan a project, why
estimate cost, resources and people, why use
empirical model…
And in the similar way you can think of differences, advantages, limitations,
examples ….. On these topics