Recommended Reading: 1) Chapter 1, Pressman, R.S., Software Engineering: A
Practitioner's Approach, 2nd Edition,. McGraw-Hill, 1987. 2) Winston W. Royce, ...
WHAT IS SOFTWARE ENGINEERING?
1.
Definition
2.
Implications—What is needed?
3.
Classical software lifecycle (and others, e.g., prototyping)
4.
Making judgments in software engineering
5.
Verification at a phase in the lifecycle—it's hard!
6.
Three perspectives on software engineering: technical, managerial, marketing
7.
Software is risky business
8.
Challenges in the field of software engineering
—
Recommended Reading: 1) Chapter 1, Pressman, R.S., Software Engineering: A Practitioner's Approach, 2nd Edition, McGraw-Hill, 1987 2) Winston W. Royce, "Managing the development of large software systems," 1970.
.
What is Software Engineering?
Page 2
WHAT IS SOFTWARE ENGINEERING?
Definition: (F.L Bauer) "Software engineering is the establishment and use of sound engineering principles [methods] in order to obtain economically software that is reliable and works on real machines." implications:
There is a need for
•
Theory (i.e., principles)
•
Experience to establish validity of theory
•
Unambiguous rules for applying theory [methods] to build software
•
Value System for judging soundness, reliability, economy
•
Strategies for managing risks and controlling the process
Software Engineering refers to •
A process ==> a sequence of activities taking place over time
•
An evolving/emerging product ==> "answer" is available only at the end!
•
A series of judgments applied to the process and to the evolving product
The classical water-fall software lifecycle: A View of the process
Classical Water-Fall Software Lifecycle
What is Software Engineering?
Page 3
^
The classical water-fall software lifecycle: A View of the evolving product
Planning • Estimates - size -effort -cost • SW Project Plan
^ Require^ ments • SW Function Description • Dataflow diagrams • Draft User Manual
V Design r • SW Archi tecture • SW Logic • SW Test Plan
_w Iraplem"*" entation
^ Integral' n v Operation r &Test
• Code Units • Unit Test Programs & Results • SW Problem Reports
• Integration Test Suites & Results - SW Problem Reports • SW Product
^ &Maint • SW Problem Reports • SW Change Requests • SW Updates & Releases
Classical Water-Fall Software Lifecycle: Evolving Software Product
MAKING JUDGMENTS ACROSS THE SOFTWARE LIFECYCLE Validation:
"Am I building the right product?"
==> "Have I understood what the customer really wanted?" Verification:
"Am I building the product right?"
==> "Am I applying a sound method correctly?" Validation & Verification Related: •
Verification speaks mostly of the process
•
Validation speaks mostly of the final result, the software product
•
The software process should include "sound engineering principles" which ensure both verification and validation.
What is Software Engineering?
Page 4
A step in the classical water-fall software lif ecycle: A close-up view of the process (rework hop) 1 t -
{ outputs i} r
) PI™ «p i
V
{inputs if
-
1 1
V
i+ll^ pu ,i r ac , 1+1 R£¥IEW {inputs rflflSP
\ \ (j^> \ f
can't automate "equivalence" check
•
Transformation Process PhaseJ: in—>out is not formal.
•
Verification process is itself a fallible, human process
What is Software Engineering?
~* ^ ""*""T-y .- - --, ** -"-" "•_---_
---- . . .- _,.-,.-.-
Po cif* 3 ^ rage
ISSUES FOR PHASES OF LIFECYCLE: • What outputs are produced in this phase? • What inputs are required to produce the outputs? • What engineering techniques can be applied to producing the outputs? • Who works on this phase? What skill level is required? • When is this phase completed? How can one tell? • What value system is used to judge/evaluate the goodnessoi the outputs? • How can one assess whether the project is on schedule or within budget? • What management techniques can be applied to enhance the outputs of this phase, or the eventual success of the project (in terms of schedule and/or cost)? • Where can automation be applied during this phase?
What is Software Engineering?
'-•
&
Page 6
r:
'
THREE PERSPECTIVES ON SOFTWARE ENGINEERING: Technical Perspective Planning
. Require* ments
. * Design
Implementation *
. Integral' i * &Test
Operation ^ &Maint.
• Management Perspective
Viewpoints/Perspectives of the Classical Software Engineering Lifecycle
TECHNICAL-Focus is on sequence of engineering activities. Typically a programmer's viewpoint. Often the concern is the transformation of input work products into output work products, verification that the transformation was carried out correctly, and on the productivity (or rate) with which the transformation was performed. MANAGERIAL- Focus is on progress of the project, as measured against committed resources and scheduled milestones. The goal is to complete the project to the customer's satisfaction while making a prof it for the company. Management oversight is continuous across the lifecycle. Management reviews treat some aspects of validation (satisfaction of customer needs) and verification (correctness of the engineering process); productivity (rate of progress) and quality (whether product can be used satisfactorily by the customer). MARKETING - Focus is on customer needs and satisfaction of those needs. The customer is likely to be involved mostly at the front-end (during requirements identification, analysis and specification) and at the back-end (during system acceptance testing). In both instances, the concern is for validation (e.g., "building the right product") and for the quality of the delivered product. Projects are most often impacted severely by changing or creeping requirements, in which the customer requests or demands capabilities which have not been planned for in advance. — • What is Software Engineering?
Page 7
^
SOFTWARE IS RISKY BUSINESS • Risk of building the wrong product •
Customer needs are misunderstood
•
Customer needs change during project
•
Multiple customers can not agree on what the right product is
• Risk of intractable problem •
Problem solution requires major technology breakthrough
• Risk of developer incompetence •
Developer has bad process (methods, tools inadequate)
•
Developer has too little expertise in application area
•
Developer staff has insufficient skills
•
Application complexity outside developer's capabilities
• Risk of schedule or cost over-runs •
Unrealistic schedule and staffing levels
•
Progress slower, effort higher, than anticipated
•
Evolving product never converges to desired product
• Risk of canceled contract •
Reversal of business decision by customer due to factors beyond developer's control
• Risk of inadequate staffing or turnover • Turnover of key personnel •
Inability to recruit the supermen promised in the proposal
What «j Software Engineering?
:: : His t^teste ~-i-----•"«.;• fc
Page 8
-w*
O
SOFTWARE ENGINEERS ARE CONTINUALLY CHALLENGED TO:
•
Identify and use good process steps
•
Develop sound engineering methods for capturing and describing actual user needs
•
Understand how to control the software engineering process similar to industrial process control (e.g., chemical plant or production line)
•
Understand how to manage risks associated with teams of humans
•
Develop ways of quantitatively describing desirable attributes of software processes and products (e.g.. goodness criteria for work products)
•
Identify indicators of progress for a software engineering activity
•
Understand the impact of making changes to the process and to particular work products
•
Develop ways of capturing and institutionalizing application expertise, making an organization as "smart" as its smartest people
•
Learn how to select methods and tools for an optimal software engineering environment
•
Make software reuse work
•
Improve ability to estimate software project costs and schedules
•
Improve the process
•
Quantify aspects of software products and processes (i.e., metrics)
•
Evaluate and incorporate beneficial software engineering technology
_ .•
What is Software Engineering?
