Software Engineering Dr. K. T. Tsang - PowerPoint PPT Presentation

1 / 70
About This Presentation
Title:

Software Engineering Dr. K. T. Tsang

Description:

1995/6: Formation, NJ to develop stopgap system ... Noble Delusions (Princeton University Press, Princeton, NJ, 1991) ... makes delegation and teamwork possible ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 71
Provided by: UIC1
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering Dr. K. T. Tsang


1
Software EngineeringDr. K. T. Tsang
  • Lecture 1
  • Introduction to SW Engineering
  • http//www.uic.edu.hk/kentsang/SWE/SWE.htm

2
Textbook general
  • Software Engineering 8th Edition
  • By Ian Sommerville
  • Pearson Education Limited, 2007
  • ISBN 7-111-19770-4
  • This book is thick contains many useful
    material, a good reference for your future SW
    career as well. It is nice to have it handy but
    doesnt necessary have to own it now.

3
Textbook Object Orientated
  • Object oriented modeling and design with UML, 2nd
    edition
  • By Michael Blaha James Rumbaugh
  • Pearson Education, Inc., 2005
  • ISBN 7-115-14076-6
  • This book is concise and unintimidating, a bible
    for OO approach. You should own and read it
    carefully for this class.

4
Supplementary materials
  • MIT OpenCourseWare Software Engineering
  • http//ocw.mit.edu/OcwWeb/Electrical-Engineering-a
    nd-Computer-Science/6-171Fall2003/CourseHome/index
    .htm
  • Plus other materials available on the web

5
Requirements for this Class
  • You are proficient in a programming language, but
    you have no experience in analysis or design of a
    system
  • You want to learn more about the technical
    aspects of analysis and design of complex
    software systems

6
Objectives of the Class
  • Appreciate Software Engineering
  • Build complex software systems that are easy to
    maintain
  • Understand how to
  • produce high quality software system within time
    limit
  • while dealing with complexity and changes
  • Acquire technical knowledge (main emphasis)
  • Acquire managerial knowledge

7
Acquire Technical Knowledge
  • Understand System Modeling
  • Learn UML (Unified Modeling Language)
  • Learn different modeling methods
  • Use Case modeling
  • Object Modeling
  • Dynamic Modeling
  • Issue Modeling
  • Learn how to use Tools
  • CASE (Computer Aided Software Engineering)
  • Component-Based Software Engineering
  • Learn how to use Design Patterns and Frameworks

8
Acquire Managerial Knowledge
  • Understand the Software Lifecycle
  • Process vs Product
  • Learn about different software lifecycles
  • Greenfield Engineering, Interface Engineering,
    Reengineering

9
How to learn from this Course
Readings textbook and Readings files on the Web
site I will direct you later. Technical
writing use the project documentation to
improve your technical writing skill.
10
Grading (Subject to Change)
FINAL 20??
11
Projects
A large part of the course is built around the
projects Preferably real project for real
client. Select your own project, but I will
give my suggestions. Project teams, about 5
people each. Feasibility study and plan due
?? Three group presentations and written
reports either requirements, design,
final or 1st iteration, 2nd iteration,
final The tutorials will be used to discuss the
projects.
12
Now, let us start the fun!
13
What is software?
  • More than just computer programs, including all
    documentation and the configuration (operating
    environment)
  • Generic products developed by software
    company/organization, sold to any customer
  • Customized products commissioned by customer,
    developed by software contractor

14
Why does SW matters?
  • SWs contribution to US economy (1996)
  • Greatest trade surplus of export
  • 24B software exported, 4B imported
  • Compare agriculture 26 -14, aerospace 11 -3,
    chemicals 26 -19, vehicles 21 -43, manufactured
    goods 200 -265
  • Role in infrastructure
  • Not just the Internet
  • Transportation, energy, medicine, finance

15
What is software engineering?
  • Engineering the discipline to build things
    (systems) that works, applying theories, methods
    and tools available
  • Software engineering the entire technical
    process of software development, and the
    management of the whole process

16
Software Engineering Definition
  • Software Engineering is a collection of
    techniques, methodologies and tools that help
    with the production of
  • a high quality software system
  • with a given budget
  • before a given deadline
  • while change occurs.

20
17
Why software engineering?
  • Demand for software is growing dramatically
  • Software costs are growing per system
  • Many projects have cost overruns
  • Many projects fail altogether
  • Software engineering seeks to find ways to build
    systems that are on time and within budget

18
Software development costs
Software costs are increasing as hardware costs
continue to decline.
  • Hardware technology has made
  • great advances
  • Simple and well understood tasks are encoded in
    hardware
  • Least understood tasks are encoded in software
  • Demands of software are growing
  • Size of the software applications is also
    increasing
  • Hence the software crisis

Hardware costs vs. Software costs
Hardware costs
Software costs
Time
19
Difference between software engineering
computer science
  • Computer science is the academic study of
    theories and methods underlying computers and
    software systems
  • Software engineering is the practice of producing
    software for specific applications. When the
    problem has no solution in theory, engineers
    often use ad hoc (for this purpose only)
    approaches to develop the software.

20
Scientist vs. Engineer
  • Computer Scientist
  • Proves theorems about algorithms, designs
    languages, defines knowledge representation
    schemes
  • Has infinite time
  • Engineer
  • Develops a solution for an application-specific
    problem for a client
  • Uses computers languages, tools, techniques and
    methods
  • Software Engineer
  • Works in multiple application domains
  • Has only 3 months...
  • while changes occurs in requirements and
    available technology

21
Software engineering system engineering
  • System engineering is concerned with all aspects
    of development and evolution of complex systems
    which often contain hardware as well as software
  • System engineers are involved in specifying the
    system, defining the architecture, and
    integrating the different parts to create the
    finished system

22
Factors affecting the quality of a software system
  • Complexity
  • The system is so complex that no single
    programmer can understand it anymore
  • The introduction of one bug fix causes another
    bug
  • Change
  • The Entropy of a software system increases with
    each change Each implemented change erodes the
    structure of the system which makes the next
    change even more expensive
  • As time goes on, the cost to implement a change
    will be too high, and the system will then be
    unable to support its intended task. This is true
    of all systems, independent of their application
    domain or technological base.

23
How good is our software?
  • Failed developments
  • Accidents
  • Poor quality software

24
A story about- Air Traffic Control
  • FAA awarded IBM Federal Systems contract in 1989
  • Deadline 2001, cost 2.5Billion
  • Constraints 24x7x365, no downtime, 2-3 secs
    response time
  • Budget 80K hardware, 2.5Billion software

25
ATC
  • 1994 Cost estimate gt 5Billion, nothing
    delivered
  • IBM federal systems, bought by Loral, had already
    spent 2.3Billion
  • FAA enquiry
  • Not enough oversight over IBM
  • FAA indecisive over requirements
  • Technology had evolved faster than their ability
    to use it
  • 1995/6 Formation, NJ to develop stopgap system
  • Lockheed Martin bought Loral, then lost most of
    the contract to Raytheon

26
Development failures
  • IBM survey, 1994
  • 55 of systems cost more than expected
  • 68 overran schedules
  • 88 had to be substantially redesigned
  • Advanced Automation System (FAA, 1982-1994)
  • industry average was 100/line, expected to pay
    500/line
  • Ended up paying 700-900/line
  • 6B worth of work discarded
  • Bureau of Labor Statistics (1997)
  • For every 6 new systems put into operation, 2
    cancelled
  • probability of cancellation is about 50 for
    biggest systems
  • average project overshoots schedule by 50
  • 3/4 systems are regarded as operating failures

27
State of the SW development practice
What can you infer from this chart?
Estimate
Early
On Time
Delayed
Canceled
13,000
6.06
74.77
11.83
7.33
130,000
1.24
60.76
17.67
20.33
1,300,000
0.14
28.03
23.83
48.00
13,000,000
0.00
13.67
21.33
65.00
Source Patterns of software failures and
successes, Capers Jones, 1996
  • Delays common with mid- to large projects.
  • Majority of the large projects are canceled.

28
Accidents
  • The most likely way for the world to be
    destroyed, most experts agree, is by accident.
    Thats where we come in. Were computer
    professionals. We cause accidents.
  • Nathaniel Borenstein, inventor of MIME
  • Programming as if People Mattered Friendly
    Programs, Software Engineering and Other Noble
    Delusions (Princeton University Press, Princeton,
    NJ, 1991)

29
Accidents Therac-25 (1985-87) A standard case
study in software control of safety-critical
systems health informatics
  • Radiation therapy machine with software
    controller
  • Two modes of operation either low doses electron
    beam mode
  • or high power e-beam with target plate
    intervening to generate X-rays
  • Software failed to detect the target not rotated
    into proper position in the X-ray mode
  • Several deaths due to burning
  • Programmer had no experience with concurrent
    programming

30
Accidents Ariane-5 (June 1996)
  • European Space Agency
  • complete loss of unmanned rocket shortly after
    takeoff
  • due to exception thrown in Ada code
  • faulty code was not even needed after takeoff
  • due to change in physical environment
    undocumented assumptions violated

31
Why is SE difficult? Complexity
  • Application domain is complex
  • Domain experts are not software engineers
  • Difficulty for people with different background,
    knowledge, and vocabularies to communicate
    effectively.
  • Working in large teams is complicated
  • Difficult to grasp the details of large
    development projects
  • Integration
  • Ambiguity of natural language
  • Render the tertiary (3D) structure on the screen
    in such a way that the scientist can manoeuvre
    around the graphic representation

32
Whats the problem?
  • Hacking code isnt all there is to building
    software.
  • In fact, its only a small part of it. Dont
    think of code as part of the solution often its
    part of the problem.
  • We need better ways to talk about software than
    code, that are less cumbersome, more direct, and
    less tied to technology that will rapidly become
    obsolete.

33
Role of design and designers
  • thinking in advance always helps!
  • contrast with reliance on testing more
    effective, much cheaper
  • makes delegation and teamwork possible
  • design flaws affect user incoherent, inflexible
    and hard to use software
  • design flaws affect developer poor interfaces,
    bugs multiply

34
Software process
  • The set of activities that lead to the final
    software product, this includes
  • Specification- engineer customer define the
    requirement
  • Development- design implementation
  • Validation- check to make sure the requirements
    are satisfied
  • Maintenance/evolution- modification to adapt to
    changing customer needs

35
Basic Process Steps in Software Development
  • Feasibility and planning
  • Requirements
  • System and program design
  • Implementation and testing
  • Acceptance testing and release
  • Operation and maintenance
  • It is essential to distinguish among these
    process steps.

36
Process Step Feasibility and Planning
  • A feasibility study precedes the decision to
    begin a project.
  • What is the scope of the proposed project?
  • Is the project technically feasible?
  • What are the projected benefits?
  • What are the costs, timetable?
  • A feasibility study leads to a decision go or
    no-go.

37
Process Step Requirements
  • Requirements define the function of the system
    from the client's viewpoint.
  • The requirements establish the system's
    functionality, constraints and goals by
    consultation with the client and users. They are
    then defined in a manner that is understandable
    by both the client and the development staff.
  • This phase is sometimes divided into
  • Requirements analysis
  • Requirements definition
  • Requirements specification

38
Process Step System and Program Design
  • Design describes the system from the software
    developers' viewpoint
  • System design Match the requirements to
    hardware or software systems. Establishes an
    overall system architecture
  • Program design Represent the software system
    functions in a form that can be transformed into
    one or more executable programs
  • Unified Modeling Language (UML)

39
Process Step Implementation and Testing
Implementation (coding) The software design is
realized as a set of programs or program units.
(The software components may be written
specifically, acquired from elsewhere, or
modified.) Testing Individual components are
tested against specifications. The individual
program units are integrated and tested against
the design by the development staff as a complete
system.
40
Process Step Acceptance Testing and Release
Acceptance testing The complete system is tested
against the requirements by the client. Delivery
and release The complete system is delivered to
the client and released into production.
41
Process Step Operation and Maintenance
Operation The system is put into practical
use. Maintenance Errors and problems are
identified and fixed. Evolution The system
evolves over time as requirements change, to add
new functions or adapt the technical
environment. Phase out The system is withdrawn
from service. This is sometimes called the
Software Life Cycle
42
Software Life-Cycle
43
Relative costs to fix errors
Cost
Design
Testing
Maintenance
Requirements
Implementation
Cost to fix an error increases as it is found
later and later in the software lifecycle
44
Sequence of Processes
Every software project will include these basic
processes, in some shape or form, but They
may be formal or informal They may be carried
out in various sequences Major alternatives Sequ
ential Complete each process step before
beginning the next (but see the next few slides).
Waterfall model. Iterative Go quickly through
all process steps to create a rough system, then
repeat them to improve the system. Iterative
refinement.
45
Software process models
  • A simplified description of the software process
    that present one view of the process
  • Some examples are
  • Workflow models the sequence of human activities
    in the process of producing the software
  • Dataflow model more concern with how inputs are
    transformed to outputs in the process
  • Role/action model concerns with the role of
    people involved

46
Most used software process (workflow) models
  • Waterfall approach step-by-step approach from
    specifying requirements, designing, implementing
    to testing of software
  • Iterative approach similar to the Waterfall
    approach, but in each step engineer customer
    will interact to refine or make sure requirements
    will be satisfied
  • Component-based approach many parts of the
    system already exist. The process focuses on
    integrating these parts to form the final system.
  • SCRUM -- http//en.wikipedia.org/wiki/Scrum_(devel
    opment)

47
Waterfall Model
48
Effort involved in the Waterfall Model
49
Waterfall Model
Advantages Process visibility
Separation of tasks Quality control at each
step Cost monitoring at each
step Disadvantages Each stage in the process
reveals new understanding of the previous stages,
that often requires the earlier stages to be
revised.
50
Problem of the waterfall model
  • Due to the inflexible nature of the division of a
    project into separate stages, commitments are
    usually made early on. So it is difficult to
    react to changes in requirements.
  • Waterfall model is likely to be unsuitable if
    requirements are not well understood or are
    likely to change radically in the course of the
    project.

51
Modified Waterfall Model
52
A pure sequential model is impossible
Examples A feasibility study cannot create a
proposed budget and schedule without a
preliminary study of the requirements and a
tentative design. Detailed design or
implementation usually reveals gaps in the
requirements specification. The plan must allow
for some form of iteration.
53
Iterative Development evolutionary/incremental
approach
Concept Initial implementation for client and
user comment, followed by refinement until system
is complete. Vaporware user interface
mock-up Throw-away software components
Dummy modules Rapid prototyping
Successive refinement Get something working as
quickly as possible!
54
Iterative Development
55
(No Transcript)
56
Iterative Model
  • Development process starts with a simple
    implementation of a subset of the software
    requirements.
  • The developer takes advantage of what was being
    learned during this development of the earlier,
    incremental, deliverable version of the system.
    Learning comes from both the development and use
    of the system, where possible.
  • Repeat the first step with a larger subset of the
    software requirements. Iteratively enhance the
    evolving sequence of versions until the full
    system is implemented.
  • At each iteration, design modifications are made
    and new functional capabilities are added.

57
Rational Unified Process (RUP)
  • One of the better known Iterative Process,
    developed by Rational Software (www.rational.com).
  • The early iterations tend to be heavy on the
    requirements end of things (you need to define a
    reasonable amount even to get started), while the
    later iterations have more of their effort in the
    design and build areas.

58
RUP Iterations can be grouped into phases
  • according to their stage in the overall project.
  • Each phase may have one or more iterations.
  • In the inception phase iterations tend to be
    heavy on the requirements/analysis end, while any
    build activity may be limited to emulation of the
    design within a CASE tool.
  • In the elaboration phase iterations tend to be
    completing the specification of the requirements,
    and starting to focus on the analysis and design,
    and possibly the first real built code.
  • In the construction phase iterations the
    requirements and analysis are more or less
    completed, and the effort is mostly in design and
    build.
  • Finally, in the deployment phase iterations are
    largely about build activity, and in particular
    the testing of the software.

59
Agile software development methods
  • A kind of iterative methods minimizing risk by
    developing software in short amounts of time.
  • Each iteration may last from one to four weeks.
    Each iteration is an entire software project
    including planning, requirements analysis,
    design, coding, testing, and documentation.
  • An iteration may not add enough functionality to
    warrant releasing the product to market but the
    goal is to have an available release at the end
    of each iteration.
  • At the end of each iteration, the team
    re-evaluates project priorities.
  • Most agile methods share other iterative and
    incremental development methods' emphasis on
    building releasable software in short time
    periods.
  • http//en.wikipedia.org/wiki/Agile_software_develo
    pment

60
Mixed Processes Phased Development
  • Combine sequential and iterative elements
  • A simple system with basic functionality is
    brought quickly into production (Phase 1).
  • Subsequent phases are based on experience gained
    from users of each previous phase.
  • Advantages
  • Pay-back on investment begins soon.
  • Requirement are more clearly understood in
    developing subsequent phases

61
What is the primary driver of software costs?
  • Most money and effort spent in testing and
    maintenance
  • But 85 of errors are introduced during
  • requirements analysis and design

62
Costs of software engineering
  • Waterfall model
  • Spec 15
  • Design 25
  • Development 20
  • Integrating testing 40
  • Iterative development
  • Spec 10
  • Iterative development 60
  • System testing 30

63
Software engineering methods
  • Structured analysis function-oriented method,
    focus on identifying the basic functional
    components of the system
  • Object oriented method focus on the object model
    of the system
  • United Modeling Language (UML)

64
CASE Computer Aided Software Engineering
  • Tools supporting requirement analysis, system
    modeling debugging testing
  • Some CASE tools may include automatic code
    generator from the system model

65
Attributes of good software
  • Maintainability- easy to maintain to meet
    changing needs
  • Dependability- reliability, security, safety
  • Efficiency- not wasting system resources
  • Usability- user friendly, good documentation

66
Key challenges SW engineering
  • Heterogeneous systems- in hardware OS, in
    integrating new code with older legacy systems
  • Delivery of quality sw on time
  • Critical sw system must be dependable
    trustworthy

67
Ethical responsibilities of SW engineer
  • Confidentiality
  • Competence
  • Intellectual property rights
  • Computer misuse

68
What software engineering is and is not..
  • Software engineering is concerned with
    engineering software systems, that is,
    building and modifying software systems
  • on time,
  • within budget,
  • meeting quality and performance standards,
  • delivering the features desired/expected by the
    customer.
  • Software engineering is not
  • Just building small or new systems.
  • Hacking or debugging until it works.
  • Easy, simple, boring or even pointless!

69
Summary
  • Critical aspects of our day to day lives depend
    on software, yet software development lacks the
    rigor and discipline of mature engineering
    disciplines
  • Too many projects get delayed, costs and
    schedules slip
  • Software engineering seeks to bring discipline
    and rigor to the building and maintenance of
    software systems
  • Study of software engineering focuses on three
    key elements process, methods and tools
  • Why is important to consider alternative models
    of the software development process?

70
Class web-page
  • http//www.uic.edu.hk/kentsang/SWE/SWE.htm
Write a Comment
User Comments (0)
About PowerShow.com