Methodology for Information System Project Management

Methodology for Information System Project Management

1. Methodology for Information
Systems Project Management
Chapter 4: James R. BurnsChapter 4: James R. Burns

2. Some PM Humor

A badly A badly planned project will take three times will take three times
longer than expected – a well planned project longer than expected – a well planned project
only twice as long as expected. only twice as long as expected.

The more you plan the luckier you get.The more you plan the luckier you get.

At the heart of every large project are At the heart of every large project are
many small projects trying to get out.many small projects trying to get out.

The nice thing about not planning is that The nice thing about not planning is that failure
comes as a complete surprise rather than being comes as a complete surprise rather than being
preceded by a period of worry and depression.
 
preceded by a period of worry and depression.
 

3. The Real Software Development Process
Out of jest and with tongue firmly in cheek, someone suggested the
following software development process:
1. Order the T-shirts for the development team
2. Announce availability of the product (This helps to motivate the team.)
3. Write the code (Let’s get with it!)
4. Write the manual
5. Hire the project manager
6. Spec the software (Writing the specs after the code helps to ensure that
the software meets the specifications.)
7. Ship
8. Test (The customers are a big help with this step.)
9. Identify bugs as potential enhancements
10. Announce the upgrade program (charge customers $ for upgrades)

4. Summary of Today’s Lecture

What do we mean by methodology?What do we mean by methodology?

What are some ‘typical’ IT Project Types?What are some ‘typical’ IT Project Types?

The Generic Lifecycle modelThe Generic Lifecycle model

5. Introduction: The Methodology
Choice Becomes the Process

Indigenous to every project are its Indigenous to every project are its
processes: the methodologies by which the processes: the methodologies by which the
project is brought to fruitionproject is brought to fruition

METHODOLOGY METHODOLOGY becomes thebecomes the PROCESSPROCESS

When implementation and execution of the When implementation and execution of the
methodology beginsmethodology begins

In this chapter we discuss the major phases In this chapter we discuss the major phases
of each project typeof each project type

We do not give you the entire WBS--just We do not give you the entire WBS--just
the top levelsthe top levels

6. What are some IT Project Types??

Enterprise Resource Enterprise Resource
PlanningPlanning

Enterprise Enterprise
Architecture Architecture
DeterminationDetermination

Re-engineering Re-engineering
projectsprojects

Agile Development Agile Development
ProjectsProjects

Product selectionProduct selection

Component configuration Component configuration
projectsprojects

Conversion projectsConversion projects

Maintenance projectsMaintenance projects

Component integration Component integration
projectsprojects

Internet Development Internet Development
projectsprojects

Mobile Application Mobile Application
Development ProjectsDevelopment Projects

Cloud applicationsCloud applications

7. Planning (Development)

Requirements are determinedRequirements are determined

Project team is selectedProject team is selected

Resources are negotiatedResources are negotiated

Team is formed, stormed, normed and Team is formed, stormed, normed and
ready to performready to perform

Formal Project plans are determinedFormal Project plans are determined

Formal Budgets are preparedFormal Budgets are prepared

8. Executing (Implementation)

Where the project ramps upWhere the project ramps up

And begins to fulfill its phasesAnd begins to fulfill its phases

Likened to execution in a sports activityLikened to execution in a sports activity

Produces the project productProduces the project product

Change management becomes especially Change management becomes especially
important hereimportant here

9. Closure and Termination
(Close-out)

Document lessons learnedDocument lessons learned

History databaseHistory database

Postmortem meetingPostmortem meeting

Signature signoffsSignature signoffs

Get paidGet paid

10. Software Development Process
Models--Boehm
WE’RE TALKING ABOUT THE WE’RE TALKING ABOUT THE
EXECUTING STAGE HEREEXECUTING STAGE HERE
Code-and-fix modelCode-and-fix model

Waterfall modelWaterfall model

Evolutionary modelEvolutionary model
Transform modelTransform model

Spiral modelSpiral model

11. Code-and-fix Model

Write some codeWrite some code

Then think about requirements, design, test Then think about requirements, design, test
and maintenance laterand maintenance later

After a number of fixes, code was poorly After a number of fixes, code was poorly
structuredstructured

Used well before structured programming Used well before structured programming
was inventedwas invented

12. Waterfall Model

DefinitionDefinition

If DEFINITION takes 2 months, then the If DEFINITION takes 2 months, then the
project is roughly ___ longproject is roughly ___ long

AnalysisAnalysis

DesignDesign

ConstructionConstruction

TestTest

OperationOperation

MaintenanceMaintenance

13. Following PMBOK

Predictive MethodologiesPredictive Methodologies

WaterfallWaterfall

EvolutionaryEvolutionary

SpiralSpiral

Adaptive MethodologiesAdaptive Methodologies

Agile MethodologiesAgile Methodologies

ScrumScrum

RUPRUP

Extreme ProgrammingExtreme Programming

14. The Waterfall StaircaseDefinition of
Requirements
Design
Acceptance
Testing
Implementation
Operation

15. Waterfall Model

Required in all government software Required in all government software
contractingcontracting

Document-drivenDocument-driven

Good for developing something with fixed Good for developing something with fixed
requirements--a new AI inference engine, a requirements--a new AI inference engine, a
new compiler, a new database enginenew compiler, a new database engine

PROBLEMS: Expensive and time PROBLEMS: Expensive and time
consuming because of its dependence on consuming because of its dependence on
fully elaborated documents, curtails testing fully elaborated documents, curtails testing
until near the enduntil near the end

16. The Standard Waterfall Model

Better than old “CODE AND FIX” Better than old “CODE AND FIX”
approachapproach

A manufacturing model for softwareA manufacturing model for software

CASE tools were developed to support it: CASE tools were developed to support it:
TI’s IEF—sold in 1994 to Sterling SoftwareTI’s IEF—sold in 1994 to Sterling Software

Basis for most software acquisition Basis for most software acquisition
standards in governmentstandards in government

17. The Standard Waterfall Model,
Cont’d

Too expensive for small projectsToo expensive for small projects

Still used for project estimation (cost and Still used for project estimation (cost and
duration) of large projectsduration) of large projects

Doesn’t get used in practice very often any Doesn’t get used in practice very often any
moremore

18. Evolutionary Process Model

Better than WATERFALL for interactive Better than WATERFALL for interactive
end-user software developmentend-user software development

Ideally matched to fourth-generation Ideally matched to fourth-generation
language applicationslanguage applications

Also works well when users say “I can’t tell Also works well when users say “I can’t tell
you what I want, but I’ll know it when I see you what I want, but I’ll know it when I see
it.”it.”

Gives users a rapid initial operational Gives users a rapid initial operational
prototype that they can play with and react prototype that they can play with and react
to, even improve uponto, even improve upon

19. The Evolutionary Process Model

NOT MUCH MORE THAN OLD “CODE NOT MUCH MORE THAN OLD “CODE
AND FIX” APPROACHAND FIX” APPROACH

Assumes Assumes user’s operational system will be user’s operational system will be
flexible enough to accommodate unplanned flexible enough to accommodate unplanned
evolution pathsevolution paths..

The above assumption is bad, because frequently, The above assumption is bad, because frequently,
several independently evolved applications must now several independently evolved applications must now
be integratedbe integrated

Temporary work-arounds for software Temporary work-arounds for software
deficiencies increasingly solidify into deficiencies increasingly solidify into
unchangeable constraints on evolutionunchangeable constraints on evolution

20. Transform Model

Endeavors to address the difficulties associated Endeavors to address the difficulties associated
with the code-and-fix, waterfall, and with the code-and-fix, waterfall, and
evolutionary models.evolutionary models.

Assumes the existence of a software module Assumes the existence of a software module
that can “parse, interpret and compile” written that can “parse, interpret and compile” written
specifications automatically into machine codespecifications automatically into machine code

There is no 3GL code (COBOL, Fortran) or There is no 3GL code (COBOL, Fortran) or
4GL code (visual languages)4GL code (visual languages)

The specifications are transformed directly to The specifications are transformed directly to
machine codemachine code

21. The Transform Model

Steps are:Steps are:

Formal specification of the desired productFormal specification of the desired product

Automatic transformation of the specification Automatic transformation of the specification
into codeinto code

An iterative loop is necessary to improve the An iterative loop is necessary to improve the
performanceperformance

Exercise of the resulting product, andExercise of the resulting product, and

An outer iterative loop to adjust the specification An outer iterative loop to adjust the specification
based on the resulting operational experiencebased on the resulting operational experience

22. The Transform Model, Cont’d

Avoids the difficulty of having to modify Avoids the difficulty of having to modify
code that has become poorly structured code that has become poorly structured
through repeated re-optimization, since the through repeated re-optimization, since the
modifications are made to the specificationmodifications are made to the specification

Avoids the extra time and expense involved Avoids the extra time and expense involved
in intermediate design, code and test in intermediate design, code and test
activitiesactivities

23. A Pervasive Problem

How to enable users to create their own How to enable users to create their own
appsapps

After all, there just aren’t enough After all, there just aren’t enough
developers arounddevelopers around

Ten years ago, the Air Force said it needed Ten years ago, the Air Force said it needed
1 out of every 5 HS graduates just to 1 out of every 5 HS graduates just to
maintain its codesmaintain its codes

SOLUTION: Let users write their own SOLUTION: Let users write their own
specifications and then transform those specifications and then transform those
same specifications directly to codesame specifications directly to code

24. Did it work?

No! Specifications must be carefully No! Specifications must be carefully
written in a compiler-compatible format--written in a compiler-compatible format--
the specifications become the program. the specifications become the program.
Users have to learn a specification Users have to learn a specification
language--same as learning a 3GL.language--same as learning a 3GL.

Like the evolutionary model, it did not Like the evolutionary model, it did not
accommodate unplanned evolutionary paths accommodate unplanned evolutionary paths
well.well.

Won’t work for Large-Scale Development Won’t work for Large-Scale Development

25. The Spiral Model (Boehm, 1988)
Overcomes most of these shortcomings and Overcomes most of these shortcomings and
addresses these questionsaddresses these questions
What shall we do next? What shall we do next?

How long shall we continue doing it?How long shall we continue doing it?
Radial dimension represents the cumulative cost Radial dimension represents the cumulative cost
incurred in accomplishing the steps to dateincurred in accomplishing the steps to date

Angular dimension represents the progress made Angular dimension represents the progress made
in completing each cycle of the spiral.in completing each cycle of the spiral.

26. Spiral Model

Can accommodate most previous Can accommodate most previous
development methodologies as special development methodologies as special
casescases

Is a risk-driven methodology, not a Is a risk-driven methodology, not a
document-driven onedocument-driven one

Endeavors to depict both the passage of Endeavors to depict both the passage of
time and the accumulation of expendituretime and the accumulation of expenditure

27. Spiral Model, Continued

Radial dimension represents the cumulative Radial dimension represents the cumulative
cost incurred in accomplishing the steps to cost incurred in accomplishing the steps to
datedate

Angular dimension represents the progress Angular dimension represents the progress
made in completing each cycle of the spiral.made in completing each cycle of the spiral.

The methodology is dynamic and dependent The methodology is dynamic and dependent
upon the relative risks remainingupon the relative risks remaining

28. Each Loop of the Spiral Model

Identifies the objectives of the product Identifies the objectives of the product
being elaboratedbeing elaborated

Identifies the alternatives to implementationIdentifies the alternatives to implementation

Determines the constraints imposed on the Determines the constraints imposed on the
alternativesalternatives

Evaluates the alternatives relative to the Evaluates the alternatives relative to the
objectives and the constraintsobjectives and the constraints

Dynamically chooses methodological detail Dynamically chooses methodological detail
needed to alleviate perceived sources of riskneeded to alleviate perceived sources of risk

29. How is risk mitigated?

If there is risk associated If there is risk associated
with the specification of with the specification of
the product, then reference the product, then reference
checking, administering checking, administering
user questionnaires, user questionnaires,
analytic modeling, or analytic modeling, or
combinations of these combinations of these
should be used to mitigate should be used to mitigate
the riskthe risk

If there is risk associated If there is risk associated
with the ultimate design with the ultimate design
of the product, then of the product, then
prototyping, simulation, prototyping, simulation,
or benchmarking should or benchmarking should
be utilized to mitigate this be utilized to mitigate this
risk.risk.

30. How is risk mitigated?

If user-interface risks strongly dominate If user-interface risks strongly dominate
product considerations, or there are internal product considerations, or there are internal
interface control risks, then the next step interface control risks, then the next step
may be to use evolutionary developmentmay be to use evolutionary development

31. Figure 2-3. Spiral Model of Software Dev.

32. Advantages of Spiral Model

Applies to maintenance as well as to Applies to maintenance as well as to
developmentdevelopment

Incorporates prototyping as a risk-reduction Incorporates prototyping as a risk-reduction
option at any stageoption at any stage

Accommodates reworks or go-backs to Accommodates reworks or go-backs to
earlier stages earlier stages

Focuses early attention on reuse of existing Focuses early attention on reuse of existing
softwaresoftware

33. More Advantages of the Spiral
Model

Accommodates preparation for life-cycle Accommodates preparation for life-cycle
evolution, growthevolution, growth

Provides a mechanism for incorporating Provides a mechanism for incorporating
software quality objectivessoftware quality objectives

Focuses on eliminating errors and Focuses on eliminating errors and
unattractive alternatives earlyunattractive alternatives early

More adaptable to projects other than More adaptable to projects other than
development than the waterfall model, development than the waterfall model,
which applies only to developmentwhich applies only to development

34. More Advantages of the Spiral
Model

Provides a viable framework for integrating Provides a viable framework for integrating
hardware-software system developmenthardware-software system development

Accommodates CASE and other transform Accommodates CASE and other transform
toolstools

35. Disadvantages of the Spiral Model

Doesn’t work with fixed-price contracts wellDoesn’t work with fixed-price contracts well

Use by outside contractors and system integrators Use by outside contractors and system integrators
is difficult, thereforeis difficult, therefore

Relies on project professionals with risk-Relies on project professionals with risk-
assessment expertiseassessment expertise

If there aren’t any risks, it doesn’t work wellIf there aren’t any risks, it doesn’t work well

36. The Dimensions
High
Ceremony
Low
Ceremony
Waterfall
Iterative

37. Process Map
Waterfall
Iterative
Low CeremonyHigh Ceremony
Little Doc, light
process discipline
Heavy Doc, heavy
process discipline,
CCB
Risk Driven, Continuous integration and testing
Few risks, late integration and testing

38. Project Uncertainty

39. Agile/Adaptive Software Development

Software is developed in increments using an iterative Software is developed in increments using an iterative
approachapproach

Architecture and Backbone firstArchitecture and Backbone first

User interfaces nextUser interfaces next

Important functionality nextImportant functionality next

Less important functionality lastLess important functionality last

Learning takes place all along the wayLearning takes place all along the way

Important components may be improved before less Important components may be improved before less
important components are even startedimportant components are even started

Provides a naive user with an early experience with the Provides a naive user with an early experience with the
software.software.

Endeavors to deliver business value early.Endeavors to deliver business value early.

40. More Agile/Adaptive Software
Development using Scrum

An iteration (sprint) lasts one to four weeksAn iteration (sprint) lasts one to four weeks
Each iteration passes through a full software Each iteration passes through a full software
development cycle including planning, development cycle including planning,
requirements analysis, design, coding, testing, requirements analysis, design, coding, testing,
and documentation. and documentation.
The goal is to have an available release (without The goal is to have an available release (without
bugs) at the end of each iteration. bugs) at the end of each iteration.

At the end of each iteration, the team re-At the end of each iteration, the team re-
evaluates project priorities.evaluates project priorities.
Agile/Adaptive methods emphasize face-to-face Agile/Adaptive methods emphasize face-to-face
communication over written documentation. communication over written documentation.

41. Principles Behind the
Agile/Adaptive Manifesto

Customer satisfaction by rapid, continuous Customer satisfaction by rapid, continuous
delivery of useful software. delivery of useful software.

Working software is delivered frequently (weeks Working software is delivered frequently (weeks
rather than months). rather than months).

Working software is the principal measure of Working software is the principal measure of
progress. progress.

Even late changes in requirements are welcomed. Even late changes in requirements are welcomed.

Close, daily cooperation between business people Close, daily cooperation between business people
and developers is strongly encouraged. and developers is strongly encouraged.

Face-to-face conversation is the best form of Face-to-face conversation is the best form of
communication.communication.

42. More Principles behind
Agile/Adaptive Development

Projects are built around motivated Projects are built around motivated
individuals, who can be trusted.individuals, who can be trusted.

Continuous attention to technical Continuous attention to technical
excellence and good design is required. excellence and good design is required.

Simplicity is a hallmark. Simplicity is a hallmark.

Self organizing teams are always used. Self organizing teams are always used.

Regular adaptation to changing Regular adaptation to changing
circumstances is accommodated. circumstances is accommodated.

43. Iterative, Agile/Adaptive Processes

Rational Unified Process (RUP)Rational Unified Process (RUP)

Dynamic Systems Development Method Dynamic Systems Development Method
(DSDM)(DSDM)

Extreme Programming (XP)Extreme Programming (XP)

CrystalCrystal

ScrumScrum

44. The Home Ground

For Agile/Adaptive software development, the For Agile/Adaptive software development, the
home ground is a culture that thrives on home ground is a culture that thrives on
chaos, low criticality, a small number of chaos, low criticality, a small number of
senior developers are used, and requirements senior developers are used, and requirements
change very often, applications are small. change very often, applications are small.

For plan-driven (Predictive) methods (such as For plan-driven (Predictive) methods (such as
the Waterfall Model), the home ground is high the Waterfall Model), the home ground is high
criticality, junior developers, requirements criticality, junior developers, requirements
don't change, a large number of developers, don't change, a large number of developers,
and a culture that demands order.and a culture that demands order.

45. 
Agile means being able to move quickly and easily, but some Agile means being able to move quickly and easily, but some
people feel that project management, as they have seen it used, people feel that project management, as they have seen it used,
does not allow people to work quickly or easily.does not allow people to work quickly or easily.

Early software development projects often used a waterfall Early software development projects often used a waterfall
approach, as defined earlier in this chapter. As technology and approach, as defined earlier in this chapter. As technology and
businesses became more complex, the approach was often difficult businesses became more complex, the approach was often difficult
to use because requirements were unknown or continuously to use because requirements were unknown or continuously
changing. changing.

Agile today means using a method based on iterative Agile today means using a method based on iterative
and incremental development, in which requirements and incremental development, in which requirements
and solutions evolve through collaboration.and solutions evolve through collaboration.

See the Resources tab from See the Resources tab from www.pmtexts.com for more info for more info
Agile Project Management

46. 
Many seasoned experts in project management Many seasoned experts in project management
warn people not to fall for the hype associated with warn people not to fall for the hype associated with
Agile. Agile.

For example, J. Leroy Ward, Executive Vice For example, J. Leroy Ward, Executive Vice
President at ESI International, said that “Agile will President at ESI International, said that “Agile will
be seen for what it is … and isn’t….Project be seen for what it is … and isn’t….Project
management organizations embracing Agile management organizations embracing Agile
software and product development approaches will software and product development approaches will
continue to grow while being faced with the continue to grow while being faced with the
challenge of demonstrating ROI through Agile challenge of demonstrating ROI through Agile
adoption.”*adoption.”*
Agile Makes Sense for Some
Projects, But Not All
*Agile Manifesto, www.agilemanifesto.org.

47. 
In February 2001, a group of 17 people that called In February 2001, a group of 17 people that called
itself the Agile Alliance developed and agreed on itself the Agile Alliance developed and agreed on
the Manifesto for Agile Software Development, as the Manifesto for Agile Software Development, as
follows:follows:

““We are uncovering better ways of developing We are uncovering better ways of developing
software by doing it and helping others do it. software by doing it and helping others do it.
Through this work we have come to value:Through this work we have come to value:

Individuals and interactions over processes and Individuals and interactions over processes and
toolstools
Manifesto for Agile Software
Development
*Agile Manifesto, www.agilemanifesto.org.

48. Agile Manifesto: We value--

Working software over comprehensive Working software over comprehensive
documentationdocumentation

Customer collaboration over contract Customer collaboration over contract
negotiationnegotiation

Responding to change over following a Responding to change over following a
plan”*plan”*
*Agile Manifesto, www.agilemanifesto.org.

49. 
According to the Scrum Alliance, Scrum is According to the Scrum Alliance, Scrum is
the leading agile development method for the leading agile development method for
completing projects with a complex, completing projects with a complex,
innovative scope of work.innovative scope of work.

The term was coined in 1986 in a Harvard The term was coined in 1986 in a Harvard
Business Review study that compared high-Business Review study that compared high-
performing, cross-functional teams to the performing, cross-functional teams to the
scrum formation used by rugby teams.scrum formation used by rugby teams.
Scrum

50. Fig. 2-6, Schwalbe. Scrum Framework
Information Technology Project Management, Eighth Edition

51. 
Technique that can be used in conjunction Technique that can be used in conjunction
with scrumwith scrum

Developed in Japan by Toyota Motor Developed in Japan by Toyota Motor
CorporationCorporation

Uses visual cues to guide workflowUses visual cues to guide workflow

Kanban cards show new work, work in Kanban cards show new work, work in
progress, and work completedprogress, and work completed
Kanban
51

52. 
The PMBOK® Guide describes best practices for The PMBOK® Guide describes best practices for whatwhat should should
be done to manage projects.be done to manage projects.

Agile is a methodology that describes Agile is a methodology that describes howhow to manage projects. to manage projects.

The Project Management Institute (PMI) The Project Management Institute (PMI)
recognized the increased interest in Agile, and recognized the increased interest in Agile, and
introduced a new certification in 2011 called Agile introduced a new certification in 2011 called Agile
Certified Practitioner (ACP).Certified Practitioner (ACP).

Seasoned project managers understand that they have always Seasoned project managers understand that they have always
had the option of customizing how they run projects, but that had the option of customizing how they run projects, but that
project management is not easy, even when using Agile.project management is not easy, even when using Agile.
Agile, the PMBOK® Guide, and a
New Certification
52

53. Agile Project Management

Is related to the Is related to the rolling wave rolling wave planning planning
and scheduling project methodology.and scheduling project methodology.

Uses iterations (“time boxes”) to develop a Uses iterations (“time boxes”) to develop a
workable product that satisfies the customer and workable product that satisfies the customer and
other key stakeholders.other key stakeholders.

Stakeholders and customers review progress and re-Stakeholders and customers review progress and re-
evaluate priorities to ensure alignment with evaluate priorities to ensure alignment with
customer needs and company goals.customer needs and company goals.

Adjustments are made and a different iterative cycle Adjustments are made and a different iterative cycle
begins that subsumes the work of the previous begins that subsumes the work of the previous
iterations and adds new capabilities to the evolving iterations and adds new capabilities to the evolving
product.product.

54. Iterative, Incremental Product Development

55. Hub Project Management Structure

56. More SCRUM

Scrum is an Agile/Adaptive development Scrum is an Agile/Adaptive development
methodology, implying low ceremony (little methodology, implying low ceremony (little
documentation, face-to-face meetings).documentation, face-to-face meetings).

Scrum is a process skeleton that includes a set of Scrum is a process skeleton that includes a set of
practices and predefined roles. practices and predefined roles.

There are two types of roles used in connection with There are two types of roles used in connection with
Scrum, those who are committed are called ‘pigs’ Scrum, those who are committed are called ‘pigs’
and thoseand those

who are involved who are called ‘chickens.’ who are involved who are called ‘chickens.’
Stakeholders are considered chickens whereas theStakeholders are considered chickens whereas the

project team and Scrum master (project manager) project team and Scrum master (project manager)
are called ‘pigs.’are called ‘pigs.’

57. Still More SCRUM

Scrum consists of a series of sprints. Each Scrum consists of a series of sprints. Each
sprint is a period of 15 to 30 days, during sprint is a period of 15 to 30 days, during
which the team creates a usable module of which the team creates a usable module of
software. software.

Scrum is considered ‘easy to learn’ and Scrum is considered ‘easy to learn’ and
doesn’t require a lot of training to start doesn’t require a lot of training to start
using it.using it.

Sprint periods of 30 days are similar to the Sprint periods of 30 days are similar to the
monthly time-boxes used in RAD. monthly time-boxes used in RAD.

58. SCRUM Meetings

Each day during the sprint, a project status meeting Each day during the sprint, a project status meeting
occurs. This is called a SCRUM Meeting. occurs. This is called a SCRUM Meeting.

The procedure for a SCRUM Meeting is the following :The procedure for a SCRUM Meeting is the following :

1) the meeting starts precisely on time with team-1) the meeting starts precisely on time with team-
decided punishments for tardinessdecided punishments for tardiness

2) all are welcome, but only “pigs” may speak2) all are welcome, but only “pigs” may speak

3) the meeting is time-boxed at fifteen minutes 3) the meeting is time-boxed at fifteen minutes
regardless of the team’s sizeregardless of the team’s size

4) all attendees should stand4) all attendees should stand

5) the meeting should happen at the same location and 5) the meeting should happen at the same location and
same time every daysame time every day

59. SCRUM….In Summary

Scrum is an Agile/Adaptive process to manage and control Scrum is an Agile/Adaptive process to manage and control
development work. development work.

Scrum is a team-based approach to iteratively, incrementally Scrum is a team-based approach to iteratively, incrementally
develop systems and products when requirements are develop systems and products when requirements are
rapidly changing. rapidly changing.

Scrum is a process that controls the chaos of conflicting Scrum is a process that controls the chaos of conflicting
interests and needs. interests and needs.

Scrum is a way to improve communications and maximize Scrum is a way to improve communications and maximize
co-operation. co-operation.

Scrum is a way to detect and cause the removal of anything Scrum is a way to detect and cause the removal of anything
that gets in the way of developing and delivering products. that gets in the way of developing and delivering products.

Scrum is a way to maximize productivity. Scrum is a way to maximize productivity.

Scrum is scalable from single projects to entire Scrum is scalable from single projects to entire
organizations. Scrum has controlled and organized organizations. Scrum has controlled and organized
development and implementation for multiple interrelated development and implementation for multiple interrelated
products and projects with over a thousand developers and products and projects with over a thousand developers and
implementers. implementers.

60. Ignore the HIDDEN slides on the
RUP

61. Another IT Project Type:
Conversion

Slam-dunkSlam-dunk

ParallelParallel

PilotPilot

62. Another IT Project Type:
System Integration and Test

Component selectionComponent selection

Component integration and testingComponent integration and testing

63. Another IT Project Type:
Process Reengineering—Michael
Hammer
1) determine measures of performance
2) install measures of performance
3) delineate entire existing process in
all its gory detail
4) perform process value analysis and
activity-based costing
5) benchmark processes by
comparison with other processes

64. More Process Reengineering
6) design re-invented process
7) simulate re-invented process
8) prepare report with recommendations
9) upgrade the software applications
that support the re-engineered process
10) install re-invented process
11) measure improvements

65. Another IT Project Type:
Enterprise Integration

The ability to read-from and write to all of The ability to read-from and write to all of
the apps and data sources across the the apps and data sources across the
enterpriseenterprise

Application integrationApplication integration

Use a common SOFTWARE BUS to “glue” Use a common SOFTWARE BUS to “glue”
them togetherthem together

Data warehousingData warehousing

66. More Enterprise Integration

Workgroup/Workflow AppsWorkgroup/Workflow Apps

Messaging systemsMessaging systems

Data federationData federation

performs integration while leaving the source performs integration while leaving the source
data in placedata in place

67. Another IT Project Type:
System Maintenance

Can use Spiral model hereCan use Spiral model here

Software doesn’t need to be greased, like Software doesn’t need to be greased, like
something mechanical does, so what do we something mechanical does, so what do we
mean by maintenance of software?mean by maintenance of software?

68. Selection Methodology: For
Software, Processes and Projects

Could use MAUT, as we previously Could use MAUT, as we previously
suggestedsuggested

Could use ROICould use ROI

Could use IRRCould use IRR

69. This is it: no more time….no
more slides in this section….
This year….

70. How do we get applications out
the door in a timely manner?
Reuse as much as possible--data and Reuse as much as possible--data and
presentation componentspresentation components
Intuitive Object-Oriented approach is the Intuitive Object-Oriented approach is the
answeranswer
Use Dupont’s approachUse Dupont’s approach
Calendar-driven developmentCalendar-driven development
Trade time for functionalityTrade time for functionality
Use time boxes (three months, usually)Use time boxes (three months, usually)
can drop low-priority functionalitycan drop low-priority functionality

71. One of our Goals: Flexibility

We want a methodology that is so flexible We want a methodology that is so flexible
that the requirements can change all during that the requirements can change all during
the development process, yet we can still the development process, yet we can still
meet the needs of the end users at the time meet the needs of the end users at the time
of cut-over (i.e., deliver the product on time of cut-over (i.e., deliver the product on time
and within budget)and within budget)

72. User Prototypes

First couple of iterations are really First couple of iterations are really
prototypes--fifth iteration is the final prototypes--fifth iteration is the final
productproduct

Limit cosmetic iterations to just twoLimit cosmetic iterations to just two

MDI frames should not be coupled, should MDI frames should not be coupled, should
possess very low cohesionpossess very low cohesion

73. The Goal
Get the application living quicklyGet the application living quickly

Learn from itLearn from it
Then enhance itThen enhance it

Time is more important than functionalityTime is more important than functionality

Use two three-month time-boxesUse two three-month time-boxes
When the final version of the product is delivered When the final version of the product is delivered
the end of the second three-months, users will the end of the second three-months, users will
have a much greater understanding of their have a much greater understanding of their
requirementsrequirements

74. Creating Object Repositories

Must use the old software factory modelMust use the old software factory model

Deposit well-documented objects, Deposit well-documented objects,
COMPONENTS in the repositoryCOMPONENTS in the repository

Encourage developers to reuse the objects Encourage developers to reuse the objects
by incentive/reward mechanismsby incentive/reward mechanisms

Must avoid re-inventing objects within all Must avoid re-inventing objects within all
the functions of an organizationthe functions of an organization

75. Standards should be devised

Version control--allowing for all versions Version control--allowing for all versions
of the module to be trackedof the module to be tracked

76. Screens/Pages

Each member of the team delivers from 1 to Each member of the team delivers from 1 to
three screens (pages) dailythree screens (pages) daily

A significant release should be forthcoming A significant release should be forthcoming
each weekeach week

Each developer’s assigned tasks should be Each developer’s assigned tasks should be
broken down into chunks of functionality broken down into chunks of functionality
that must be delivered by certain due datesthat must be delivered by certain due dates

77. Selection Methodology: For
Software, Processes and Projects

Define the application to be computerizedDefine the application to be computerized

Develop a list of COTS packages that is available Develop a list of COTS packages that is available
to support the appto support the app

Gather information about the COTS packagesGather information about the COTS packages

Narrow the list of possible choices down to less Narrow the list of possible choices down to less
than a half dozenthan a half dozen

Obtain hands-on demonstrations of the few Obtain hands-on demonstrations of the few
remaining packagesremaining packages

78. Selection Methodology, Cont’d

Of those that remain, perform a final Of those that remain, perform a final
detailed evaluationdetailed evaluation

Make a decisionMake a decision

Purchase the selected COTS packagePurchase the selected COTS package

Learn to use the packageLearn to use the package

Implement the package Implement the package

79. Project Standards

80. Operational Issues -- Brooks

Another Software guru like BoehmAnother Software guru like Boehm

81. Software Development -- Brooks

What is the problem with hiring additional What is the problem with hiring additional
people on a project that is behind schedule?people on a project that is behind schedule?

Under what circumstances are men and Under what circumstances are men and
man-hours interchangeable?man-hours interchangeable?

How much time should be set aside for How much time should be set aside for
testing and integration, according to testing and integration, according to
Brooks?Brooks?

What are some good ways to organize work What are some good ways to organize work
packages to avoid some of the problems packages to avoid some of the problems
Brooks is talking about?Brooks is talking about?

82. Questions

All programmers are ____.All programmers are ____.

When schedule slippage occurs, the natural thing When schedule slippage occurs, the natural thing
is to ____.is to ____.

What are the three stages of creative activity?What are the three stages of creative activity?

These are analogous to ____?These are analogous to ____?

Brooks says that the programmer builds from Brooks says that the programmer builds from
____.____.

pure thought stuff; concepts and flexible representations. pure thought stuff; concepts and flexible representations.
However, today this is not true.However, today this is not true.

83. Questions, Cont’d

Cost varies as the number of persons and the number Cost varies as the number of persons and the number
of monthsof months
•However, progress does not.However, progress does not.

Can we use the man-month as a unit for sizing a job?Can we use the man-month as a unit for sizing a job?
•No. It is too dangerousNo. It is too dangerous

People and months are inter-changeable only when a People and months are inter-changeable only when a
task can be partitioned among many workers with task can be partitioned among many workers with
_____._____.
•No communication between themNo communication between them

The added burden of communication is made up of The added burden of communication is made up of
_____._____.
•two parts: training and intercommunication.two parts: training and intercommunication.

Long projects can expect a turnover of ___% a year.Long projects can expect a turnover of ___% a year.
•2020

84. Questions, Cont’d

How much of the total time does Brooks How much of the total time does Brooks
devote to Definition, Analysis and Design?devote to Definition, Analysis and Design?
•1/31/3

How much time to coding?How much time to coding?
•1/6 to Coding1/6 to Coding

How much time to testing?How much time to testing?
•1/4 to component test and early system test1/4 to component test and early system test
•1/4 to total system test1/4 to total system test