CSE Senior Design ICSE Senior Design I
Critical Topic ReviewCritical Topic Review
Instructor: Manfred HuberInstructor: Manfred Huber
This presentations was adapted in part from Mike O’Dell. This presentations was adapted in part from Mike O’Dell.
CSE Senior Design ICSE Senior Design I
Classic MistakesClassic Mistakes
1
3
Why Projects Fail - OverviewWhy 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
1
4
Categories of Classic MistakesCategories of Classic Mistakes
People-relatedProcess-relatedProduct-relatedTechnology-related
1
5
Classic Mistakes EnumeratedClassic 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
1
6
Classic Mistakes EnumeratedClassic Mistakes Enumerated
4. Heroics: Heroics seldom work to your advantage Honesty is better than empty empty ““can-docan-do””
5. Adding people to a late project: Productivity killerProductivity killer Throwing people at a problem seldom helps
6. Noisy, crowded offices: Work environment is importantenvironment is important to productivity Noisy, crowded conditions lengthen schedules
1
7
Classic Mistakes EnumeratedClassic Mistakes Enumerated
7. Friction between developers and customers: Cooperation Cooperation is the key Encourage participationparticipation in the process
8. Unrealistic expectations: Avoid seat-of-the-pants commitments Realistic expectations is a TOP 5 issueTOP 5 issue
9. Lack of effective project sponsorship: Management must buy-inManagement must buy-in and provide support Potential morale killerPotential morale killer
1
8
Classic Mistakes EnumeratedClassic Mistakes Enumerated
10. Lack of stakeholder buy-in: Team members, end-users, customers,
management, etc. Buy-in engenders cooperationcooperation at all levels
11. Lack of user input: You can’t build what you don’t understand Early input is critical to avoid feature creepfeature creep
12. Politics placed over substance: Being well regarded by management will not make
your project successful
1
9
Classic Mistakes EnumeratedClassic Mistakes Enumerated
13. Wishful thinking: Not the same as optimism Don’t plan on good luckluck! May be the root causeroot 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 Consider a ““spiralspiral”” approach for larger risks
1
10
Classic Mistakes EnumeratedClassic 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-fixCode-and-fix mentality takes over… and will fail
1
11
Classic Mistakes EnumeratedClassic Mistakes Enumerated
19. Wasted time during fuzzy front end: That would be nownow! Almost always cheaper and faster to spend time
upfront working/refining the plan
20. Shortchanged upstream activities: See above… do the work up frontup front! Avoid the “jump to coding” mentality
21. Inadequate design: See above… do the required work up frontup front!
1
12
Classic Mistakes EnumeratedClassic Mistakes Enumerated
22. Shortchanged quality assurance: Test planning is a critical part of every plan ShortcuttingShortcutting 1 day early on will likely cost you 3-
10 days later QA me now, or pay me later!
23. Insufficient management controls: Buy-in implies participation & cooperationcooperation
24. Premature or overly frequent convergence:
It’s not done until it’s done!
1
13
Classic Mistakes EnumeratedClassic Mistakes Enumerated
25. Omitting necessary tasks from estimates: Can add 20-30% to your schedule Don’t sweat the small stuffsmall stuff!!
26. Planning to catch up later: Schedule adjustments WILL be necessary A month lost early on probably cannot be made upcannot be made up
later
27. Code-like-hell programming: The fast, loose, “entrepreneurial” approach This is simply… Code-and-Fix. Don’t!
1
14
Classic Mistakes EnumeratedClassic Mistakes Enumerated
28. Requirements gold-plating: Avoid complex, difficult to implement features Often, they add disproportionatelyadd disproportionately to schedule
29. Feature creep: The average project experiences 25% change Another killerkiller mistake!
30. Developer gold-plating: Use proven stuffproven stuff to do your job Avoid dependence on the hottest new toolshottest new tools Avoid implementing all the cool new featurescool new features
1
15
Classic Mistakes EnumeratedClassic Mistakes Enumerated31. Push-me, pull-me negotiation:
Schedule slip = feature addition
32. Research-oriented development: Software research schedules are theoreticaltheoretical, at best Try not to push the enveloppush 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: There is no magicno magic in product development Don’t plan on some new whiz-bang thing to save your
bacon (i.e., your schedule)
1
16
Classic Mistakes EnumeratedClassic 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!
1
17
Recommendation: Develop a Disaster Recommendation: Develop a Disaster Avoidance PlanAvoidance Plan
Get together as a team sometime soon and make a list of list of ““worst practicesworst practices”” that you should avoid in your project.
Include specific mistakes that you think could/will be made by your teamyour team
Post thisPost this list on the wall in your lab space or where ever it will be visible and prominent on a daily basis
ReferRefer to it frequently and talk about how you will avoid these mistakesavoid these mistakes
CSE Senior Design ICSE Senior Design I
Your Plan: EstimationYour Plan: Estimation
1
19
The Software-Estimation StoryThe Software-Estimation StorySoftware/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!
1
20
Estimate-Convergence GraphEstimate-Convergence Graph
Initialproduct
definition
Approvedproduct
definition
Requirementsspecification
Productdesign
specification
Detaileddesign
specification
Productcomplete
1.0
0.25
4
2
0.5
1.5
0.67
1.25
0.81.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
High Estimate
Low Estimate
Low Estimate
1
21
Estimation tipsEstimation 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
1
22
Function-Point EstimationFunction-Point EstimationBased 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)
1
23
Function-Point MultipliersFunction-Point MultipliersFunction Points
Program Low Medium HighCharacteristic Complexity Complexity ComplexityNumber of inputs 3 4 6Number of outputs 4 5 7Inquiries 3 4 6Logical internal files 7 10 15External 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 ofinstallation.
All of this gives a total function-point count.Use this with Jones’ First-Order Estimation Practice, orcompare to previous projects for an estimate
1
24
Estimate Presentation StylesEstimate 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...”
CasesBest case April 1Planned case May 15Current case May 30Worst case July
15
Coarse dates and time periods“3rd quarter 97”
Confidence factorsApril 1 5%
May 15 50%
July 1 95%
1
25
Schedule EstimationSchedule 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.
1
26
Shortest Possible ScheduleShortest Possible Schedule
Probability ofCompleting
Exactly on theScheduled Date
Scheduled Completion Date
Shortestpossible
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.8Table 8.8High Risk of late High Risk of late
completion.completion.
1
27
Efficient Schedules (Table 8-9)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”
1
28
Nominal Schedules (Table 8-10)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.
1
29
Estimate RefinementEstimate 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 increasesWhen estimate ranges decrease as the project
progresses, customer confidence is built-up.
1
30
ConclusionsConclusions
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…
CSE Senior Design ICSE Senior Design I
Feature-Set ControlFeature-Set Control
1
32
The ProblemThe Problem
Products are initially stuffedinitially stuffed with more features (requirements) than can be reasonably accommodated
Features continue to be addedadded as the project progresses (“Feature-Creep”)
Features must be removed/reducedremoved/reduced or significantly changed late in a project
1
33
Sources of ChangeSources of Change
End-usersEnd-users: driven by the “need” for additional or different functionality
MarketersMarketers: driven by the fact that markets and customer perspectives on requirements change (“latest and greatest” syndrome)
DevelopersDevelopers: driven by emotional/ intellectual desire to build the “best” widget
1
34
Effects of ChangeEffects of Change
Impact in every phaseevery phase: design, code, test, documentation, support, training, people, planning, tracking, etc.
Visible effectsVisible effects: schedule, budget, product quality Hidden effectsHidden 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
1
35
Change ControlChange ControlGoals:
Allow change that results in the best possible best possible product in the time availableproduct in the time available. Disallow all other changes
Allow everyone affected by a proposed change to participateparticipate in assessing the impact
Broadly communicatecommunicate proposed changes and their impact
Provide an audit trailaudit trail for all decisions (i.e., document them well)
A process to accomplish the above as efficientlyefficiently as possible
1
36
Late Project Feature CutsLate Project Feature CutsGoal: Eliminate features in an effort save the save the
projectproject’’s schedules scheduleFact: Project may (will) fall behind for many
reasons other than feature-set controlFact: Removing features too late incurs
additional costs and schedule impactadditional costs and schedule impactApproach: analyzeanalyze the cost of removal and
reusability, then strip out unused code, remove documentation, eliminate test cases, etc.
CSE Senior Design ICSE Senior Design I
Risk ManagementRisk Management
1
38
Why Do Projects Fail?Why Do Projects Fail?
Generally, from poor risk managementpoor 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)
1
39
Elements of Risk ManagementElements of Risk Management Managing risk consists of: identifying, addressing
and eliminating risks When does this occur?
WORST – Crisis management/Fire fighting Crisis management/Fire fighting : addressing risk after they present a big problem
BAD – Fix on failure Fix on failure : finding and addressing as the occur.OKAY – Risk Mitigation Risk Mitigation : plan ahead and allocate resources to
address risk that occur, but don’t try to eliminate them before they occur
GOOD – Prevention Prevention : part of the plan to identify and prevent risks before they become problems
BEST – Eliminate Root Causes Eliminate Root Causes : part of the plan to identify and eliminate the factors that make specific risks possible
1
40
Elements of Risk ManagementElements of Risk Management
Effective Risk Management is made up of: Risk Assessment: identify, analyze, prioritize Risk Control: planning, resolution, monitoring
RISK RISK
MANAGEMENTMANAGEMENT
RISK RISK
CONTROLCONTROL
RISK RISK
ASSESSMENTASSESSMENT
IDENTIFICATIONIDENTIFICATION
ANALYSISANALYSIS
PLANNINGPLANNING
PRIORITIZATIONPRIORITIZATION
RESOLUIONRESOLUION
MONITORINGMONITORING
1
41
Risk MonitoringRisk Monitoring
Risks and potential impact will changewill change throughout the course of a project
Keep an evolving ““TOP 10 RISKSTOP 10 RISKS”” list list See Table 5-7 for an example Review the list frequently Refine… Refine… Refine…Refine… Refine… Refine…
Put someone in chargePut someone in charge of monitoring risksMake it a part of your process & project planpart of your process & project plan
CSE Senior Design ICSE Senior Design IOverview:Overview:
Software System ArchitectureSoftware System ArchitectureSoftware System TestSoftware System Test
1
CSE 4317 43
What is System Design?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)
1
CSE 4317 44
What is Software Architecture?What is Software Architecture?
A critical bridgebridge between whatwhat a system will do/look like, and howhow it will be constructed
A blueprint for a software system and howhow it will be built
An abstractionabstraction: a conceptual model of what must be done to construct the software system It is NOT a specification of the details of the
construction
1
CSE 4317 45
What is Software Architecture?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)
1
CSE 4317 46
System Architecture Design System Architecture Design ProcessProcess
Define guiding principles/rules for designDefine 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
1
1: Introduction47
Layer Example: The Internet Layer Example: The Internet Protocol Stack ArchitectureProtocol 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
1
4: Network Layer4b-48
Subsystem Example: The Internet Subsystem Example: The Internet Network LayerNetwork Layer
routingtable
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
Networklayer
1
CSE 4317 49
Criteria for a Good ArchitectureCriteria for a Good Architecture(The Four I(The Four I’’s) 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.
1
CSE 4317 50
How do you Document a Software How do you Document a Software Architecture?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)
1
CSE 4317 51
How do you Document a Software How do you Document a Software Architecture?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
1
CSE 4317 52
Final Thoughts – VerificationFinal Thoughts – Verification
SRD: System Requirements
ADS: ArchitectureSpecification
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 SpecifiedRequirements
MAP:All ModuleInterfaces &Interactions
MAP:All Modules
MAP:All Subsystem & LayerInterfaces &Interactions
1 Final Thoughts – VerificationFinal 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