CS335

1
CS335

• Software Engineering

2
Personal

• Dr. Craig Reinhart
• reinhart_at_clunet.edu
• Office D21
• Office Hours W, Th 430-600
• http//public.clunet.edu/reinhart
• CSC335 ADEP link
• Class notes, handouts, announcements, etc.

3
Course Requirements

• Homework
• Question/Answers (written)
• Design documents
• Not going to do any programming
• Exams (1 or 2 midterms and a final)
• Class Participation
• Classroom discussions are a great
  teaching/learning tool and communication will be
  critical to your success in industry

4
Books

• Required text
• Project-Based Software Engineering An
  Object-Oriented Approach
• References
• There are many books on software engineering
  ranging from general theory to specialty topics
  (object oriented, agile methods, classical, )

5
Why Do We Study Software Engineering?
6
A Project Done Without Software Engineering
7
A Project Done Without Software Engineering
8
A Project Done Without Software Engineering
9
A Project Done Without Software Engineering
10
A Project Done Without Software Engineering
11
A Project Done Without Software Engineering
12
A Project Done Without Software Engineering
13
A Project Done Without Software Engineering
14
A Project Done Without Software Engineering
15
A Project Done Without Software Engineering
16
A few facts about software

• Writing new software is easy.
• All I need is a program toit shouldnt take you
  very long to get that going

17
A few facts about software

• Modifying existing software is even easier than
  writing new software.
• Thats really goodbut can you modify it to do

18
A few facts about software

• Anyone and therefore, everyone can write
  software.
• Since youre so busy, well getover in hardware
  design to work on this part of the code.

19
A few facts about software

• Since software is, by definition, programmable,
  software can be made to do anything.
• Last night I got this great idea. All your
  program has to do is

20
A few facts about software

• Software can always be made to run faster.
• Dont worry about the speed right now. Just get
  it working. Well make it go faster later.

21
A few facts about software

• Assigning more people to write software will
  linearly reduce the time to completion.
• Two months! We need it in two weeks. But dont
  worry, well get you 3 more programmers.

22
Are theyfacts or myths?

• Clearly, the previous facts are actually
  myths
• The myths are hard to break
• Software is often misunderstood by non-software
  people
• Pressure of time/money/etc. causes people to make
  bad decisions and unreasonable demands
• Many tasks are performed easily by people and
  thus assumed to be even easier to carry out by an
  expensive, high powered computer
• Customers are demanding

23
The real facts

• Discipline
• Think before you do.

24
The real facts

• Organization
• Keep records of what you do.

25
The real facts

• DONT PANIC! (ref Hitchhikers Guide To The
  Galaxy.)

26
Software Engineering

• Tools/techniques to deal with the myths.
• But always remember
• The tools exist to support the development effort
• Dont utilize the tools just because they exist

27
When is Software Engineering Important?

• Always (?)
• When designing a complex system (?)
• When more than one person is assigned to work on
  the system (?)
• When designing a system that is mission
  critical (?)
• Software Engineering at some level is always
  important
• The particular project will determine the level

28
What is a mission critical system?

• Air Traffic Control system (as described in the
  book)?
• Medical applications?
• Banking applications?
• Homework?

29
What is a mission critical system? (cont.)

• Any/every system can be viewed as mission
  critical
• It depends on the user
• What is mission critical to some may be
  completely irrelevant and unimportant to others
• You should assume that any system you design is
  mission critical

30
Why Do Software Systems Fail?

• System complexity
• Ambiguous/poorly written specifications

31
Why Do Software Systems Fail? (cont.)

• People
• Bad decisions
• Bad execution (bugs)
• Poor communication
• impedance mismatch
• System knowledge resides in domain expert
• Implementation knowledge resides in software
  expert
• Ego
• Stress
• Reluctance to admit to mistakes
• Fear of losing job/livelihood
• Incompetence

32
Problems Arent Always Due to the Software
Engineers

• Project Manager
• Unrealistic expectations (technical and/or
  scheduling)
• Domain Experts
• Unclear specifications/explanations
• Customer (end user)
• Unclear objectives/goals

33
How Do We Address These Problems?

• Address the impedance mismatch situation
• Being a good programmer isnt enough
• You must be able to understand and extrapolate
  specifications from the domain expert
• This is why CS students take non-CS courses
  (math, science, engineering, language, sociology,
  psychology, history,)

34
impedance mismatch (cont.)

• The software engineer is typically at the end of
  the development chain
• Jobs that involve integration of hardware and
  software are commonly performed by the software
  engineer
• Software engineers are often asked to perform
  tasks to correct hardware errors
• i.e. Software engineers/developers are typically
  asked to do more than engineer/develop software

35
How Do We Address These Problems? (cont.)

• Continuously consult the domain expert(s)
• Continuously consult the customer
• Classical software engineering methodologies
  dont incorporate this very well
• Agile methods make this a central theme
• Continuously monitor progress
• Predict and therefore, avoid disasters
• Software Engineering (as opposed to hacking
  code)

36
How Can Software Fail?

• Non-functioning software
• it doesnt work
• Software that doesnt do what its supposed to do
• right answer, wrong problem
• Incorrect implementation
• right problem, wrong answer

37
How Can Software Fail? (cont.)

• Fragile software
• all I did was enter 1027733 when the program
  asked for a number between 1 and 10
• Software that runs too slow
• Software that runs too fast
• Software that is too big
• Software that is too
• Software that is obsolete before its finished

38
And We Havent Even Mentioned Maintenance!

• Change is inevitable
• All previous observations regarding failing
  software apply
• Original staff is likely to be unavailable for
  implementing change or even for consultation
  regarding change
• People move on for various reasons

39
How Do We Address Maintenance Issues?

• Clear/concise designs
• Well documentation implementations
• Code reuse wherever possible
• Organization
• Software Engineering

40
Elements of a Software Engineering Paradigm

• Conceptualization
• How one looks at the system to be developed
• Process oriented
• Data oriented
• Object oriented
• The choice of conceptualization primitive will
  drive how the implementation approach
• Note that the designers may not be the ones that
  do the implementation

41
Elements of a Software Engineering Paradigm
(cont.)

• Conceptualization (cont.)
• Object-oriented conceptualization is reportedly
  the more intuitive approach
• Less likely to omit a critical process
• More easily understood (conveyed to/extracted
  from) the domain expert

42
Elements of a Software Engineering Paradigm
(cont.)

• Representation
• Writing down (communicating) the
  conceptualization
• Must be concise (want the reviewers to fully
  understand the system)
• Must be efficient (dont want to risk losing the
  audience)
• Must be unambiguous (leave nothing to
  interpretation)
• The set of rules for creating the representation
  is called the notation

43
Elements of a Software Engineering Paradigm
(cont.)

• Implementation
• This is where code development begins
• Process oriented
• Focus is on functions
• Object oriented
• Focus is on class definitions
• May be driven by the representation used for the
  conceptualization

44
Elements of a Software Engineering Paradigm
(cont.)

• Implementation (cont.)
• Choice of programming language
• Coding standards
• Source control
• Version control
• Lots of other headaches

45
Reading/Homework

• Textbook chapters 1 and 2
• Handout Historys Worst Software Bugs
• Homework
• Order the 10 worst software bugs of all time
  from least harmful to most harmful (in your
  opinion)
• Give a brief description of the criteria you
  employed for creating your order
• Due next week