Software Engineering

Software Engineering EECE 351 Spring 2000 Lecture # 8 How many Microsoft employees does it take to change a light bulb? None – the company just declares darkness to be a standard. [Unknown] EECE 351 – Lecture 8

Overview • Introduction • const • Review of material covered in class • Mythical Man Month 1 – 7 • What we know • Where we are going EECE 351 – Lecture 8

Introduction • As mentioned before, this class is about Software Engineering, NOT programming. • This lecture will introduce some Software Engineering aspects and help you improve your knowledge in this area. EECE 351 – Lecture 8

const • The keyword const is a special keyword to Software Engineers. We ♡ it! • The const keyword specifies that a variable's value is constant and tells the compiler to prevent the programmer from modifying it. • Trying to change a constant variable results in a syntax error. • const enforces the principal of least privilege. GOOD THING!!! EECE 351 – Lecture 8

const (cont.) • Array names are constant. You cannot make an array point to another section of memory. • In functions, you can specify an input parameter as const to ensure the function does not alter the original variable. • Use with call by reference to get the speed, but lose the side affects. • Combine with pointers… EECE 351 – Lecture 8

const & pointers • Pointers and the keyword const can be in any of the following combinations: EECE 351 – Lecture 8

const • We will come back to const and its ++ later in the semester. • The compiler loves constmore than we do (especially VC 6.0). • Optimization techniques work a lot faster/better!!! EECE 351 – Lecture 8

SE Review Error Life Cycle EECE 351 – Lecture 8

SE Review Error Cost to Fix EECE 351 – Lecture 8

SE ReviewThe Pie Where the programming effort goes: The reason why this is so big is because this is so small. The more tests you run, the less maintenance you’ll need to perform. CATCH THE BUGS AS SOON AS YOU CAN! EECE 351 – Lecture 8

Mythical Man MonthThe Tar Pit • Software engineering is the practice of producing quality software that meets or exceeds customer requirements. • The diagram at left is very important • The point is that it’s much more difficult to produce a programming systems product than a program. (x10) EECE 351 – Lecture 8

Mythical Man MonthThe Tar Pit – Joys & Sorrows • The God-Like Act of Creation • Making Something for Others • Solving Intricate Puzzles • Learning • Tractable Medium Joys • Perform Perfectly • Reliance on Others • Grinding Through Debugging • Testing (Are you sick of it yet?) • Obsolescence Sorrows EECE 351 – Lecture 8

Mythical Man Month MMM – Optimism • This is what kills most SEs • “This is the last bug. It will work this time.” • Creative Activity is divided into 3 stages: • Idea – complete only in the mind • Implementation – building it • Interaction – customers getting their money’s worth • Programming creates with an exceeding tractable medium. • Built from pure thought-stuff: concepts and very flexible representations thereof. EECE 351 – Lecture 8

Mythical Man Month MMM – The Man Month • Men are NOT equal to months. • Progress only benefits when the job is partitionable with NO communication between workers. • Added burden of communication has 2 parts: • Training (tech., goals, strategy, & plan) • Intercommunication (n(n-1)/2) • Adding more men lengthens, not shortens, the schedule. EECE 351 – Lecture 8

Mythical Man Month MMM – Systems Test • Debugging and Systems affected most by sequential constraints. • Time required depends on the number and subtlety of errors encountered. • Devote the most time to testing. • Failure to do so causes problems. • Bad news, late & without warning. • Already fully staffed, $/day already at max. • Product is being used to assist other costs. EECE 351 – Lecture 8

Mythical Man Month MMM – G E & R S D • Don’t just say “Yeah, I can do that!” • You probably won’t be able to. • Develop & publicize-- Productivity figures, Bug-Incidence Figures, Estimating Rules, etc. Sounds like a T&D sheet! • What do you do when schedule won’t be met? • Take no small steps. • Reschedule ENTIRE task. • Add manpower? EECE 351 – Lecture 8

Mythical Man Month MMM – Brooke’s Law • Brooke’s Law: • Adding manpower to a late software project makes it LATER! • Why Do So Many Software Developers Fail to Honor Their Schedule Commitments? • Poor Estimating Techniques Coupled with Optimism • Confusion of Effort with Progress • Gutless Estimating • Poor Schedule Monitoring • Adding Late Staffing • Dishonesty and a Lack of Integrity EECE 351 – Lecture 8

Mythical Man Month The Surgical Team • Smaller teams are better!! • Organize team into the following: • Surgeon – chief programmer. Defines specs, designs program, codes, tests, writes documentation. • Copilot – surgeon’s alter ego. Able to do any part, but is less experienced. • Administrator – handles money, people, space, & machines. • Secretary (project correspondences, non-project files) EECE 351 – Lecture 8

Mythical Man Month The Surgical Team (cont.) • Editor – revises drafts. (♡ Angela ♡) • Secretary – helps out • Program clerk – maintains tech records in programming-product library. • Toolsmith – think of tech support. • Tester – thinks of ways to break surgeon’s code. (My favorite part.) • Language lawyer – knows how to code better than the surgeon. Think of a programmer (knows code, but can’t do much else). EECE 351 – Lecture 8

Mythical Man Month Chapter 4 (A, D, & S D) • Conceptual integrity is THE most important consideration in system design. • Conceptual integrity is THE most important consideration in system design. • Conceptual integrity is THE most important consideration in system design. EECE 351 – Lecture 8

Mythical Man Month Chapter 4 (A, D, & S D) (cont.) • How to achieve it? • Make computers easy to use. • Simplicity & straightforwardness • Design must proceed from 1 mind (or small # of agreeing resonant minds). • Someone must control the concepts. • Require that a system reflects a single philosophy and the specs flow from a few minds. • Conceptual integrity determines ease of use. EECE 351 – Lecture 8

Mythical Man Month Chapter 4 (A, D, & S D) (cont.) • Architecture • The complete and detailed specification of the user interface. • Tells what happens. • Implementation • Tells how it is made to happen. • Will not sit idly by. • Serves the architecture. EECE 351 – Lecture 8

Mythical Man Month Second System Effect • What discipline bounds the architect? • Communication between architect and builder • What happens when the builders give too high an estimate? • Architect may eliminate features. • Architect may challenge the estimate. • The architect does not dictate, but only suggests. • The architect must be prepared to propose alternative implementations. • The architect and builder must communicate quietly and privately. • The architect must be ready to give up any and all credit for improvements. • Manipulation: make builders believe it was their idea. EECE 351 – Lecture 8

Mythical Man Month Second System Effect (cont.) • Second system effect: tendency of second system to be over-designed • Fear of unknown helps in first system design. • Experience helps in third, fourth, etc. System design • How to avoid the second system effect: • Planning, self-discipline, experienced architects EECE 351 – Lecture 8

Mythical Man Month Passing the Word • How does communication occur in a system with conceptual integrity? • The written specification (or manual) is an external, user-oriented, document. • Formal definitions (e.g., BNF, lex/yacc, VLSI, etc.) • Simulators or alpha-/beta- designs • Stubbed designs (useful in software, and sometimes hardware) • Meetings • Useful, but entirely too often there are too many. • Remove all chairs. EECE 351 – Lecture 8

Mythical Man Month Passing the Word (cont.) • Telephone log • A much better approach is a moderated/unmoderated discussion group. • Lotus notes, Internet, etc. • Independent product test as the surrogate customer • Many companies now use customers as surrogate customers. EECE 351 – Lecture 8

Mythical Man MonthWhy Did the Tower of Babel Fail? • How should teams communicate with each other? • Informally • Movement toward cubicles (versus labs) makes this difficult. • Meetings • Beware of too much of a good thing. • Workbook • Electronic mechanisms work best; workflow may be the future. • Notice the disagreement with David Parnas (OO methodology). EECE 351 – Lecture 8

Mythical Man Month Why Did the Tower of Babel Fail? (2) • For n Workers, There Are (n2 - n) / 2 Interfaces and Almost 2n Teams. • Use Division of Labor and Specialization of Function to Overcome This • Brooks Advocates Hierarchy: No Two People Serving the Same Master • Each Subtree Must Have • A Mission (A Vision Is Also Good) • A Producer (Management) • A Technical Director/Architect (Leadership) • A Schedule (Milestones) • A Division of Labor (Who Is Going to Do What?) • Interface Definitions Among the Parts (APIs or Object Interface Definitions) EECE 351 – Lecture 8

What we know • Mythical Man Month 1 - 7 • Software Engineering Review • const EECE 351 – Lecture 8

Where we are going • Review • Midterm (Eww!) • Classes • Mandatory Project EECE 351 – Lecture 8

Software Engineering