Personal Chitra Chandavarkar chandava@clunet.edu Office: D5 Office Hours: T 4:30-5:30 chandava

Personal

• Chitra Chandavarkar

• chandava@clunet.edu

• Office: D5

• Office Hours: T 4:30-5:30• http://public.clunet.edu/~chandava

Course Requirements

• Homework– Question/Answers (written)– Design documents– Not going to do any programming

• Exams (midterm and a final)• In Class Assignments & Participation

– Classroom discussions are a great teaching/learning tool and communication will be critical to your success in industry

• Project

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, …)

Why Do We Study Software Engineering?

Chapter 1

Examples of Software failures

• Air traffic control System by FAA– $2.3 Billion spent without any usable

deliverable

• Mars Climate Orbiter– Crashes into surface of Mars

• Travel reservation system CONFIRM– is cancelled after the investment of $125m

Examples of Software failures

• Faye receives an electric bill for $6.3 m instead of $63– Error in data input

• Credit card denial– Credit history of two individuals with same

name were merged

Why Do Software Systems Fail?

• System Complexity

• Communication

• Management

• People(users, developers, management)

• Maintenance

Sources of Complexity in Software Development• Non linear (multithread) nature

• Technical staff lacks expertise in the complex application domain

• Difficulty of mentally grasping and coordinating the details of a large-scale development project

Why Inter-personal Communication is Difficult• Impedance mismatch

– Technical staff often do not possess the vocabulary used in the application domain

– Technical staff and end users have different background knowledge

– System knowledge resides in domain expert– Implementation knowledge resides in software expert

• End users frequently do not understand how to effectively express their needs and goals, in terms that are clear to systems developers.

Problems Aren’t Always Due to the Software Engineers• Project Manager

– Unrealistic expectations (technical and/or scheduling)

Limitations of People

• People– Bad decisions– Ego– Stress– Reluctance to admit to mistakes– Fear of losing job/livelihood– Incompetence

Maintaining Software Systems

• Inevitable aspect of software development• evolves with an organization• Too often too many resources are directed

to maintenance and away from new development

• Poorly structured Software requires excessive maintenance

Why Engineer Software?

• Enormous social cost of NOT engineering software

• Too many large-scale software development failures for too many decades

• Software development initiatives fail for many different reasons, most of which can be addressed by good software engineering practices

How Can Software Fail?

• Non-functioning software– “it doesn’t work”

• Software that doesn’t do what it’s supposed to do– “right answer, wrong problem”

• Incorrect implementation– “right problem, wrong answer”

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 is obsolete before it’s

finished

How Do We Address These Problems?

• Address the “impedance mismatch” situation– Being a good programmer isn’t 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,…)

How Do We Address These Problems? (cont.)• Continuously consult the domain expert(s)• Continuously consult the customer

– “Classical” software engineering methodologies don’t 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”)

How Do We Address Maintenance Issues?

• Clear/concise designs

• Well documentation implementations

• Code reuse wherever possible

• Organization

• Software EngineeringIt is better to invest in well-structured software up front then to

invest excessively in maintenance later

Elements of a Software Development Paradigm

• Conceptualization– What elements are instrumental in how the

developers think about the software system?

• Representation– Must convey what the software project is all

about– Most effectively done with a software

modeling notation

• Implementation – Addresses how the source code is structured

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

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

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 (don’t 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

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

Elements of a Software Engineering Paradigm (cont.)

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

A Brief History of Software Engineering Techniques• Structured Programming

– No gotos

• Functional Decomposition – Top-down organization of subprograms

• Structured Analysis– Recognition that analyzing the problem

statement has critical influence on the success of the overall project

– Formal modeling of subprogram interaction with dataflow diagrams

More History of SE Methodologies

• Data-centered analysis– Uses techniques developed in structured

analysis– Data modeling occurs using entity

relationship diagrams before functional modeling

• Object-oriented analysis– No longer segregates the modeling of

functions and data– Objects aggregate data with functions that

operate on the data

Sample Dataflow Diagram

Check for overdue books

Check-outbooks

Read Patronrecord

Change bookstatus

Read book record

Write book record

Patron ID

True/false

Patron IDPatron recordor null

Book ID, out

Book ID

Book recordBook record

Sample Entity Relationship Diagram

Checks out

LibraryPatron Address

Book Publisher

Requests

1:M 1:M

Has-a

Has-a

Has-a

Principles of the Object-Oriented Paradigm• Abstraction

• Modularity

• Modeling

• Inheritance

• Encapsulation(covered in chapter2)

• Polymorphism(covered in Chapter2)

Shared by other paradigms

Abstraction

• Expressing the software requirements in abstract terms, suppressing details so that a comprehensive portrayal can be made

• The abstract representation must then be connected to more detailed expressions, so that no information is lost in modeling the system

• This allows us to reason about the breadth of functionality of the developing system

Modularity

• Breaking a complex software system into smaller modules allows reduces its overall complexity

• Modules should aggregate some coherent aspect of the system

• Modules should present a simple interface• Classes, functions, and abstract data

types are examples of modules.

Abstract Data Type Example

STACK

POP()

PUSH(item)

ISEMPTY()

Interface

Accesses

Implementation Option: Array

12 24 98 33 13

Implementation Option: Linked list

13

98

24

Modeling

• Modeling is the process of use a graphic notation to express properties of the software system

• Models express how the system is built out of modules and how these modules interact

• One objective of modeling is to express characteristics of the software system in an unambiguous manner

Inheritance

• A property distinguishing classes from abstract data types

• Allows characteristics from one class to be passed on its subclasses

• Subclasses may override inherited characteristics

Cost of not Engineering Software

• Need to restructure code

• High maintenance costs

• Software is unacceptable to end users

• Unreliable code

• Need to rewrite code

• Difficulty integrating system modules

• Difficult project management

• Budget and time overruns

Why Software Engineering is not Universal• Understanding software development as

programming only without recognition of importance of analysis and design

• Short-sighted technical management• Pressure of deadlines• Poor project estimation, thus

unreasonable deadlines

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

A Project Done Without Software Engineering

Is this a fact or a myth?…

• Writing new software is easy. – “All I need is a program to…it shouldn’t

take you very long to get that going”

Is this a fact or a myth?…

• Modifying existing software is even easier than writing new software. – “That’s really good…but can you modify it

to do…”

Is this a fact or a myth?…

• Anyone [and therefore, everyone] can write software.– “Since you’re so busy, we’ll get…over in

hardware design to work on this part of the code.”

Is this a fact or a myth?…

• 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…”

Is this a fact or a myth?…

• Software can always be made to run faster.– “Don’t worry about the speed right now.

Just get it working. We’ll make it go faster later.”

Is this a fact or a myth?…

• Assigning more people to write software will linearly reduce the time to completion.– “Two months! We need it in two weeks. But

don’t worry, we’ll get you 3 more programmers.”

Are they“facts” or “myths”?

• Clearly, the previous “facts” are actually “myths”

• More myths...– 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

The real “facts”

• Discipline– Think before you do.

• Organization– Keep records of what you do.

• Tools/techniques – The tools exist to support the development

effort– Don’t utilize the tools just because they exist

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

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”