1

Software Engineering--Introduction

Software Engineering--Introduction

2

1. Syllabus, grading, schedule--class + lab--will all be on www.ece.uc.edu/~cpurdy

2. Contact information: C. Purdy: on syllabus

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 assignment.

Course Administration

3

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.

Course Themes

4

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

5

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).

6

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

7

Software Life Cycle "software life cycle":easier specify requirements(cheaper) (levels:1. functionalto fix 2. performancemistakes (time/space)

3. implementation4. use5. maintenance)

analyze requirementsdesignimplement

harder to fix testmistakes maintain

these steps are not independent; process isnot "linear"--we will look at some "processmodels" for this cycle

8

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 Writer Documentation, manuals

Goals / Functions – conflicts?

9

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?

10

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.)

11

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

Dilbert

12

Dilbert – Powerpoint Poisoning

13

Mythical Man-month

14

La Brea Tar Pits

15

“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

16

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"

17

System Architect

what are these propositions? (excerpts):

I. Architect --conceptual integrity

II. Process Model --have a plan and follow it

III. Productivity – develop strategies that enhance productivity

18

System Architect

what are these propositions? (excerpts):

I. Architect:

conceptual integrity of the product isparamount; "the product must beconceptually coherent to the single mind ofthe user and at the same time designed bymany minds"

most important is "the commissioning ofsome one mind to be the product's architect,. . . responsible for the conceptual integrityof all aspects of the product perceivable bythe user"

19

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

20

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

21

Productivity

III. Productivity:

information hiding is the way to go (achanged opinion from edition 1)

the "man-month" really is mythical (Brooks'Law is "true")

people are (almost) everything in softwareproductivity

22

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