cse senior design i critical topic review instructor: manfred huber this presentations was adapted...

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.


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


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


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


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


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


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


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


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


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


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


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


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…


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.


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

cse senior design i critical topic review instructor: manfred huber this presentations was adapted...

Documents