Software Engineering--Introduction
Software Engineering--Introduction
1
Course Administration
1.
Syllabus, grading, schedule--class + lab--will all be on www.ece.uc.edu/~cpurdy
2.
Contact information: C. Purdy / Tao Ma (TA)
3. Java--to be learned in lab--you will develop basic skills, “expert” status not
required
4. teams--3-4 per team (TURN IN SURVEY please)
5. project--most will be done in lab
6. passing 493/495: you must pass both classes; if you fail one, you will receive an F
in both; otherwise you will receive a separate grade in each of these classes
7. grading: 493 | 495—explained on web pages
8. cell phones--for each call you get in class, you lose 3 points on your final grade
9. Electronic communication (text messages, laptops, etc.):
NOT ALLOWED in lecture as these distract from class discussions
10. Reading assignments: please read BEFORE class & be ready to discuss in class
(there may be quizzes for these)
11. Group work / individual work: we will do a lot of each--follow rules for each
2
assignment.
Course Themes
The lectures and assignments in this course will focus on
developing knowledge and skills for:
• effective teamwork
• project management
• software development
• "lifelong learning"
In this course we will be concentrating on the process of
developing software, not on technical skills in specialized areas
such as database management, wireless computing, etc.
The skills we will learn can also be applied to hardware projects
and to mixed hardware / software projects.
3
People, Product, Process--> Project
what is "software engineering"?: the "art" of building and
maintaining software systems
"…software engineering is a discipline whose aim is the
production of fault-free software, delivered on time and
within budget, that satisfies the user’s needs.”
Schach, Object-Oriented and Classical Software
Engineering, 5th ed., Mc-Graw-Hill 2002, p. 4
4
People, Product, Process--> Project
Importance of “fault-free” … Software bugs can be lethal.
• The 2003 North America blackout was triggered by a local
outage that went undetected due to a race condition
– 55 million people were without power
• Smart ship USS Yorktown was left dead in the water in 1997
for nearly 3 hours after a divide by zero error
• Y2K problem … similarly 2038 problem …
many Unix systems calculate the time in seconds since 1
January 1970, and store this figure as a 32-bit signed integer,
for which the maximum possible value is 231-1
(2,147,483,647).
5
People, Product, Process--> Project
"…software engineering is a discipline whose aim is the production of fault-free
software, delivered on time and within budget, that satisfies the user’s needs.”
Schach, Object-Oriented and Classical Software
Engineering, 5th ed., Mc-Graw-Hill 2002, p. 4
components of software system construction (“4 P’s”):
people
• product
• process
• project
•
6
Software Life Cycle
"software life cycle":
easier
specify requirements
(cheaper)
(levels:1. functional
to fix
2. performance
mistakes
(time/space)
3. implementation
4. use
5. maintenance)
analyze requirements
design
implement
harder to fix test
mistakes
maintain
these steps are not independent; process is
not "linear"--we will look at some "process
models" for this cycle
7
People (Stakeholders)—Roles, Goals, Functions
Role
Responsibility
Customer
High level requirements, project scope
User
What tasks must system carry out?
What is level of expertise?
Software salesperson
Get requirements; delivery dates, cost
Business Manager
Organize, track work
Technical Manager
Manage technical issues
Developer
Design, implement, test
Technical WriterDocumentation, manuals
Goals / Functions – conflicts?
8
Questions to Think About
some points to ponder:
•"software crisis"--systems become more and more complex:
--what can we automate?
--how can we verify/ test such complex systems?
•"hardware/software" boundary
--how can we do "co-design"?
--where is the boundary?
•types of software systems
--how do important application-specific systems differ?
--what impact do differences have on development?
--which systems will be most important in the coming years?
9
Important System Types
Some Common System Types—what is the same/different?
•Databases
•Communication systems
•Entertainment systems
•Web-based applications
•Medical systems
•Manufacturing / transportation systems
•Simulation programs to support engineering and science
•Parallel/distributed applications
•Embedded systems
•Intelligent systems / robots http://www.youtube.com/watch?v=7fYMxaBTqls
•Utility software for computer systems (compilers, e.g.)
•Utility software for general users (spreadsheets, e.g.)
10
References
some references:
1. Fred Brooks, The Mythical Man-Month,
Addison-Wesley, 1995 edition (this is THE
classic reference on software engineering;
first edition was published in 1974)
2. Scott Adams, Dilbert--sometimes cynical
but often insightful perspective (e.g., the
COBOL dinosaur; "Powerpoint poisoning")
3. Ed Yourdon, Death March, The
Complete Software Developer's Guide to
Surviving "Mission Impossible" Projects,
Prentice-Hall, 1997.
4. Tom DeMarco, The Deadline, Dorset
House Publishing, 1997--"Mr. Tompkins"
for software
11
Dilbert
12
Dilbert – Powerpoint Poisoning
13
Mythical Man-month
14
“Mythical Man-Month”
Some comments on Brooks' The Mythical
Man-Month:
Who is Fred Brooks?
IBM architect, system developer; led
OS/360 development
Turing Award winner
"Brooks' Law": adding manpower to a late
software project makes it later
updated Brooks' Law: adding personnel to a
late software project makes it later
15
Why is Managing Programming Hard?
Brooks attempts to answer the question:
"why is programming so hard to manage?"
brief answer:
large programming projects suffer
management problems different in kind
from small ones, due to division of labor
critical need: preserve the conceptual
integrity of the product itself
In 1995 edition Brooks asserts:
"I was struck by how few of the
propositions asserted in it have been
critiqued, proven, or disproven by ongoing
software engineering research and
experience"
16
System Architect
what are these propositions? (excerpts):
I. Architect:
conceptual integrity of the product is
paramount; "the product must be
conceptually coherent to the single mind of
the user and at the same time designed by
many minds"
most important is "the commissioning of
some one mind to be the product's architect,
. . . responsible for the conceptual integrity
of all aspects of the product perceivable by
the user"
17
Separate Architecture, Implementation
except in very small projects, architect
cannot also be manager
architect  director
manager  producer
architecture and implementation must be
separated
large systems need subsystems with
subarchitects
18
Process Model
II. Process model:
"Don't build one to throw away--the
waterfall model is wrong"
incremental build, progressive refinement
are more productive techniques
19
Productivity
III. Productivity:
information hiding is the way to go (a
changed opinion from edition 1)
the "man-month" really is mythical (Brooks'
Law is "true")
people are (almost) everything in software
productivity
20
What did we do today?
•Welcome to class – (and… turn in your surveys!)
•It’s a “process course” -- teamwork, methodology, lifelong
learning ALL in the context of good code development
•The 4 P’s -- people, product , process, project
•Plethora of models … plan, do, fix
•Fred Brooks , et. al – Mythical Man Month
21