1. CSE Senior Design I Critical Topic Review Instructor: Manfred Huber This presentations was adapted in part from Mike O’Dell.

2. CSE Senior Design I Classic Mistakes

3. 1 3 Why Projects Fail - Overview  Five main reasons:  Failing to communicate  Failing to create a realistic plan  Lack of buy-in  Allowing scope/feature creep  Throwing resources at a problem

4. 1 4 Categories of Classic Mistakes  People-related  Process-related  Product-related  Technology-related

5. 1 5 Classic Mistakes Enumerated 1. Undermined motivation: The Big One - Probably the largest single factor in poor productivity Motivation must come from within 2. Weak personnel: The right people in the right roles 3. Uncontrolled problem employees: Problem people (or just one person) can kill a team and doom a project The team must take action… early Consider the Welch Grid

6. 1 6 Classic Mistakes Enumerated 4. Heroics: Heroics seldom work to your advantage empty “can-do” Honesty is better than empty “can-do” 5. Adding people to a late project: Productivity killer Productivity killer Throwing people at a problem seldom helps 6. Noisy, crowded offices: environment is important Work environment is important to productivity Noisy, crowded conditions lengthen schedules

7. 1 7 Classic Mistakes Enumerated 7. Friction between developers and customers: Cooperation Cooperation is the key participation Encourage participation in the process 8. Unrealistic expectations: Avoid seat-of-the-pants commitments TOP 5 issue Realistic expectations is a TOP 5 issue 9. Lack of effective project sponsorship: Management must buy-in Management must buy-in and provide support Potential morale killer Potential morale killer

8. 1 8 Classic Mistakes Enumerated 10. Lack of stakeholder buy-in: Team members, end-users, customers, management, etc. cooperation Buy-in engenders cooperation at all levels 11. Lack of user input: You can’t build what you don’t understand feature creep Early input is critical to avoid feature creep 12. Politics placed over substance: Being well regarded by management will not make your project successful

9. 1 9 Classic Mistakes Enumerated 13. Wishful thinking: Not the same as optimism luck Don’t plan on good luck! root cause May be the root cause of many other mistakes 14. Overly optimistic schedules: Wishful thinking? 15. Insufficient risk management: Identify unique risks and develop a plan to eliminate them “spiral” Consider a “spiral” approach for larger risks

10. 1 10 Classic Mistakes Enumerated 16. Contractor failure: Relationship/cooperation/clear SOW 17. Insufficient planning: If you can’t plan it… you can’t do it! 18. Abandonment of planning under pressure: Path to failure Code-and-fix Code-and-fix mentality takes over… and will fail

11. 1 11 Classic Mistakes Enumerated 19. Wasted time during fuzzy front end: now That would be now! Almost always cheaper and faster to spend time upfront working/refining the plan 20. Shortchanged upstream activities: up front See above… do the work up front! Avoid the “jump to coding” mentality 21. Inadequate design: up front See above… do the required work up front!

12. 1 12 Classic Mistakes Enumerated 22. Shortchanged quality assurance: Test planning is a critical part of every plan Shortcutting Shortcutting 1 day early on will likely cost you 3- 10 days later QA me now, or pay me later! 23. Insufficient management controls: cooperation Buy-in implies participation & cooperation 24. Premature or overly frequent convergence: It’s not done until it’s done!

13. 1 13 Classic Mistakes Enumerated 25. Omitting necessary tasks from estimates: Can add 20-30% to your schedule small stuff! Don’t sweat the small stuff! 26. Planning to catch up later: Schedule adjustments WILL be necessary cannot be made up A month lost early on probably cannot be made up later 27. Code-like-hell programming: The fast, loose, “entrepreneurial” approach This is simply… Code-and-Fix. Don’t!

14. 1 14 Classic Mistakes Enumerated 28. Requirements gold-plating: Avoid complex, difficult to implement features add disproportionately Often, they add disproportionately to schedule 29. Feature creep: The average project experiences 25% change killer Another killer mistake! 30. Developer gold-plating: proven stuff Use proven stuff to do your job hottest new tools Avoid dependence on the hottest new tools cool new features Avoid implementing all the cool new features

15. 1 15 Classic Mistakes Enumerated 31. Push-me, pull-me negotiation: Schedule slip = feature addition 32. Research-oriented development: theoretical Software research schedules are theoretical, at best push the envelop Try not to push the envelop unless you allow for frequent schedule revisions If you push the state of the art… it will push back! 33. Silver-bullet syndrome: no magic There is no magic in product development Don’t plan on some new whiz-bang thing to save your bacon (i.e., your schedule)

16. 1 16 Classic Mistakes Enumerated 34. Overestimated savings from new tools or methods: Silver bullets probably won’t improve your schedule… don’t overestimate their value 35. Switching tools in the middle of the project: Version 3.1…version 3.2… version 4.0! Learning curve, rework inevitable 36. Lack of automated source control: Stuff happens… enough said!

17. 1 17 Recommendation: Develop a Disaster Avoidance Plan list of “worst practices”  Get together as a team sometime soon and make a list of “worst practices” that you should avoid in your project. your team  Include specific mistakes that you think could/will be made by your team  Post this  Post this list on the wall in your lab space or where ever it will be visible and prominent on a daily basis  Refer avoid these mistakes  Refer to it frequently and talk about how you will avoid these mistakes

18. CSE Senior Design I Your Plan: Estimation

19. 1 19 The Software-Estimation Story  Software/System development, and thus estimation, is a process of gradual refinement.  Can you build a 3-bedroom house for $100,000? (Answer: It depends!)  Some organizations want cost estimates to within ± 10% before they’ll fund work on requirements definition. (Is this possible?)  Present your estimate as a range instead of a “single point in time” estimate.  The tendency of most developers is to under- estimate and over-commit!

20. 1 20 Estimate-Convergence Graph Initial product definition Approved product definition Requirements specification Product design specification Detailed design specification Product complete 1.0  0.25  44 22 0.5  1.5  0.67  1.25  0.8  1.0  0.6  1.6  1.25  0.8  1.15  0.85  1.1  0.9  Project Cost (effort and size) Project Schedule High Estimate Low Estimate

21. 1 21 Estimation tips  Avoid off-the-cuff estimates  Allow time for the estimate (do it right!)  Use data from previous projects  Use developer-based estimates  Estimate by walk-through  Estimate by categories  Estimate at a low-level of detail  Don’t forget/omit common tasks  Use software estimation tools  Use several different techniques, and compare the results  Evolve estimation practices as the project progresses

22. 1 22 Function-Point Estimation  Based on number of  Inputs (screens, dialogs, controls, messages)  Outputs (screens, reports, graphs, messages)  Inquiries (I/O resulting in a simple, immediate output)  Logical internal files (Major logical groups of end-user data, controlled by program)  External interface files (Files controlled by other programs that this program uses. Includes logical data that enters/leaves program)

23. 1 23 Function-Point Multipliers Function Points ProgramLowMediumHigh CharacteristicComplexityComplexityComplexity Number of inputs  3  4  6 Number of outputs  4  5  7 Inquiries  3  4  6 Logical internal files  7  10  15 External interface files  5  7  10 Sum these to get an “unadjusted function-point total” Multiply this by an “influence multiplier” (0.65 to 1.35), based on 14 factors from data communication to ease of installation. All of this gives a total function-point count. Use this with Jones’ First-Order Estimation Practice, or compare to previous projects for an estimate

24. 1 24 Estimate Presentation Styles  Plus-or-minus qualifiers “6 months, +3 months, -2 months”  Ranges “5-9 months”  Risk quantification “6 months... +1 month for late subcontractor, +0.5 month for staff sickness, etc...”  Cases Best caseApril 1 Planned caseMay 15 Current caseMay 30 Worst caseJuly 15  Coarse dates and time periods “3rd quarter 97”  Confidence factors April 15% May 1550% July 195%

25. 1 25 Schedule Estimation  Rule-of-thumb equation  schedule in months = 3.0 * man-months 1/3 This equation implies an optimal team size.  Use estimation software to compute the schedule from your size and effort estimates  Use historical data from your organization  Use McConnell’s Tables 8-8 through 8-10 to look up a schedule estimate based on the size estimate  Use the schedule estimation step from one of the algorithmic approaches (e.g., COCOMO) to get a more fine tunes estimate than the “Rule of thumb” equation.

26. 1 26 Shortest Possible Schedule Probability of Completing Exactly on the Scheduled Date Scheduled Completion Date Shortest possible schedule Impossible schedule This tables assumes: - Top 10% of talent pool, all motivated, no turnover - entire staff starts working on Day 1, & continue until project released - advanced tools available to everyone - most time-efficient development methods used - requirements completely known, and do not change Table 8.8 High Risk of late completion.

27. 1 27 Efficient Schedules (Table 8-9)  This table assumes:  Top 25% of talent pool  Turnover < 6% per year  No significant personnel conflicts  Using efficient development practices from Chap 1-5  Note that less effort required on efficient schedule tables  For most projects, the efficient schedules represent “best-case”

28. 1 28 Nominal Schedules (Table 8-10)  This table assumes:  Top 50% of talent pool  Turnover 10-12% per year  Risk-management less than ideal  Office environment only adequate  Sporadic use of efficient development practices  Achieving nominal schedule may be a 50/50 bet.

29. 1 29 Estimate Refinement  Estimate can be refined only with a more refined definition of the software product  Developers often let themselves get trapped by a “single-point” estimate, and are held to it (Case study 1-1)  Impression of a slip over budget is created when the estimate increases  When estimate ranges decrease as the project progresses, customer confidence is built-up.

30. 1 30 Conclusions  Estimate accuracy is directly proportional to product definition.  Before requirements specification, product is very vaguely defined  Use ranges for estimates and gradually refine (tighten) them as the project progresses.  Measure progress and compare to your historical data  Refine… Refine… Refine…

31. CSE Senior Design I Feature-Set Control

32. 1 32 The Problem initially stuffed  Products are initially stuffed with more features (requirements) than can be reasonably accommodated added  Features continue to be added as the project progresses (“Feature-Creep”) removed/reduced  Features must be removed/reduced or significantly changed late in a project

33. 1 33 Sources of Change  End-users  End-users: driven by the “need” for additional or different functionality  Marketers  Marketers: driven by the fact that markets and customer perspectives on requirements change (“latest and greatest” syndrome)  Developers  Developers: driven by emotional/ intellectual desire to build the “best” widget

34. 1 34 Effects of Change every phase  Impact in every phase: design, code, test, documentation, support, training, people, planning, tracking, etc.  Visible effects  Visible effects: schedule, budget, product quality  Hidden effects  Hidden effects: morale, pay, promotion, etc.  Costs are typically 50 -200 times less if changes are made during requirements phase, than if you discover them during implementation

35. 1 35 Change Control  Goals: best possible product in the time available  Allow change that results in the best possible product in the time available. Disallow all other changes participate  Allow everyone affected by a proposed change to participate in assessing the impact communicate  Broadly communicate proposed changes and their impact audit trail  Provide an audit trail for all decisions (i.e., document them well) efficiently  A process to accomplish the above as efficiently as possible

36. 1 36 Late Project Feature Cuts save the project’s schedule  Goal: Eliminate features in an effort save the project’s schedule  Fact: Project may (will) fall behind for many reasons other than feature-set control additional costs and schedule impact  Fact: Removing features too late incurs additional costs and schedule impact analyze  Approach: analyze the cost of removal and reusability, then strip out unused code, remove documentation, eliminate test cases, etc.

37. CSE Senior Design I Risk Management

38. 1 38 Why Do Projects Fail? poor risk management  Generally, from poor risk management  Failure to identify risks  Failure to actively/aggressively plan for, attack and eliminate “project killing” risks  Risk comes in different shapes and sizes  Schedule risks (short to long)  Cost risks (small to large)  Technology risks (probable to impossible)

39. 1 39 Elements of Risk Management  Managing risk consists of: identifying, addressing and eliminating risks  When does this occur? Crisis management/Fire fighting WORST – Crisis management/Fire fighting : addressing risk after they present a big problem Fix on failure BAD – Fix on failure : finding and addressing as the occur. Risk Mitigation OKAY – Risk Mitigation : plan ahead and allocate resources to address risk that occur, but don’t try to eliminate them before they occur Prevention GOOD – Prevention : part of the plan to identify and prevent risks before they become problems Eliminate Root Causes BEST – Eliminate Root Causes : part of the plan to identify and eliminate the factors that make specific risks possible

40. 1 40 Elements of Risk Management  Effective Risk Management is made up of:  Risk Assessment: identify, analyze, prioritize  Risk Control: planning, resolution, monitoring RISKMANAGEMENT RISKCONTROL RISKASSESSMENTIDENTIFICATIONANALYSIS PLANNING PRIORITIZATION RESOLUION MONITORING

41. 1 41 Risk Monitoring will change  Risks and potential impact will change throughout the course of a project “TOP 10 RISKS” list  Keep an evolving “TOP 10 RISKS” list  See Table 5-7 for an example  Review the list frequently  Refine… Refine… Refine…  Put someone in charge  Put someone in charge of monitoring risks part of your process & project plan  Make it a part of your process & project plan

42. CSE Senior Design I Overview: Software System Architecture Software System Test

43. 1 CSE 4317 43 What is System Design?  A progressive definition of how a system will be constructed:  Guiding principles/rules for design (Meta- architecture)  Top-level structure, design abstraction (Architecture Design)  Details of all lowest-level design elements (Detailed Design)

44. 1 CSE 4317 44 What is Software Architecture? bridgewhat how  A critical bridge between what a system will do/look like, and how it will be constructed how  A blueprint for a software system and how it will be built abstraction  An abstraction: a conceptual model of what must be done to construct the software system  It is NOT a specification of the details of the construction

45. 1 CSE 4317 45 What is Software Architecture?  The top-level breakdown of how a system will be constructed:  design principles/rules  high-level structural components  high-level data elements (external/internal)  high-level data flows (external/internal)

46. 1 CSE 4317 46 System Architecture Design Process  Define guiding principles/rules for design  Define top-level components of the system structure (“architectural layers”)  Define top-level data elements/flows (external and between layers)  Deconstruct layers into major functional units (“subsystems”)  Translate top-level data elements/flows to subsystems

47. 1 1: Introduction 47 Layer Example: The Internet Protocol Stack Architecture Layers/Services:  application: supporting network applications  ftp, smtp, http  transport: host-host data transfer  tcp, udp  network: routing of datagrams from source to destination  ip, routing protocols  link: data transfer between neighboring network elements  E.g., Ethernet, 802.11 WLAN  physical: bits “on the wire” application transport network link physical

48. 1 4: Network Layer 4b- 48 Subsystem Example: The Internet Network Layer routing table Routing protocols path selection RIP, OSPF, BGP IP protocol addressing conventions datagram format packet handling conventions ICMP protocol error reporting router “signaling” Transport layer: TCP, UDP Link layer Physical layer Network layer

49. 1 CSE 4317 49 Criteria for a Good Architecture (The Four I’s)  Independence – the layers are independent of each other and each layer’s functions are internally-specific and have little reliance on other layers. Changes in the implementation of one layer should not impact other layers.  Interfaces/Interactions – the interfaces and interactions between layers are complete and well- defined, with explicit data flows.  Integrity – the whole thing “hangs together”. It’s complete, consistent, accurate… it works.  Implementable – the approach is feasible, and the specified system can actually be designed and built using this architecture.

50. 1 CSE 4317 50 How do you Document a Software Architecture?  Describe the “rules” : meta-architecture  guiding principles, vision, concepts  key decision criteria  Describe the layers  what they do, how they interact with other layers  what are they composed of (subsystems)

51. 1 CSE 4317 51 How do you Document a Software Architecture?  Describe the data flows between layers  what are the critical data elements  provider subsystems (sources) and consumer subsystems (sinks)  Describe the subsystems within each layer  what does it do  what are its critical interfaces of the subsystem, within and external to its layer  what are its critical interfaces outside the system

52. 1 CSE 4317 52 Final Thoughts – Verification SRD: System Requirements ADS: Architecture Specification DDS: Detailed Design Specification Implementation Integration Test Component Test (a.k.a. Function Test) Unit Test System Validation Test System Verification System Definition MAP: All Specified Requirements MAP: All Module Interfaces & Interactions MAP: All Modules MAP: All Subsystem & Layer Interfaces & Interactions

53. 1 Final Thoughts – Verification  Unit Test: verifies that EVERY module (HW/SW) specified in the DDS operates as specified.  Component/Function Test: verifies integrity of ALL inter-module interfaces and interactions.  Integration Test: verifies integrity of ALL inter- subsystem interfaces and interactions.  System Verification Test: verifies ALL requirements are met. CSE 4317 53