Upload
brianna-tate
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
Personal
• Chitra Chandavarkar
• 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”