Not Signed-In
Which clippings match 'Project Management Method' keyword pg.1 of 1
18 JUNE 2014

Scrum: iterative and incremental agile software development

"Scrum is a management framework for incremental product development using one or more cross–functional, self–organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed–length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration."

(Michael James)

1

2

3

TAGS

agile developmentagile modellingapplication development • close online collaboration • cross-functional teams • development life cycleface-to-face communicationfacing unpredicted challengesflexible management methodology • holistic process • incremental development • incremental product development • iterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)management methodology • Michael James • physical co-location • product development methodology • product development strategy • project managementproject management method • requirements churn • return on investment (ROI)scrum software development processself-organising teamssoftware development method • sprints • whirlpool model

CONTRIBUTOR

Liam Birtles
26 JANUARY 2014

MoSCoW Analysis: a project requirements prioritisation technique

"MoSCoW analysis divides requirements into four categories: Must, Should, Could, and Won't. It is most applicable for software development or timeboxed delivery efforts, as it focuses on determining which requirements can be implemented given specified time or resource constraints. Category descriptions are as follows:

Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Should: Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

Could: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

Won't: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future."

(Kevin Brennan, 2009, p.165)

Kevin Brennan (2009). "A Guide to the Business Analysis Body of Knowledge". International Institute of Business Analysis. ISBN 978–0–9811292–1–1.

TAGS

building in measuresbusiness analysis • business requirements • clear project objectives • could • design requirements • importance • International Institute of Business Analysis • management methodmanagement methodologymanagement technique • MoSCoW analysis • MoSCoW method • MoSCoW prioritisation • must • organisational process • organisational technique • prioritisationprioritisation analysisprioritisation techniqueproject definitionproject deliverables • project delivery • project goalsproject managementproject management methodproject objectivesproject requirementsquantifiable definitionsrequirements gatheringrequirements prioritisation • should • software development methodtime management • wont

CONTRIBUTOR

Simon Perkins
19 JANUARY 2011

Single-pass sequential 'waterfall' approach to software development

"I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post–flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on–time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation. ...

A more grandiose approach to software development is illustrated in Figure 2. The analysis and coding steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a program design step, and followed by a testing step. These additions are treated separately from analysis and coding because they are distinctly different in the way they are executed. They must be planned and staffed differently for best utilization of program resources."

(Winston Royce, 1970)

Figure 2 The "waterfall method" (one of numerous development models discussed by Royce in his seminal paper).

Winston Royce (1970). "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

1

CONTRIBUTOR

Simon Perkins
06 NOVEMBER 2009

Rolling Wave Project Planning

"Rolling Wave Project Planning (RWPP) is a phased iterative approach to project development, applicable to new product development, information systems and other technical development environments. It is an excellent formal project development approach for inventive work. When done well, it balances structured process with flexibility. It is appropriate for project life cycle models/methods that allow incremental development (spiral, evolutionary prototyping, etc.)."

(Gregory D. Githens, Catalyst Management Consulting)

Rolling Wave Project Planning" (PMI Symposia Proceedings '98NPD Track)

1

TAGS

Catalyst Management Consulting • development life cycle • evolutionary prototyping • flexibilityincremental developmentinventioninventive workiterative designiterative design processlifecycle model • Process Model • project development • project life cycle • project managementproject management method • Rolling Wave Project Planning • RWPP • spiral mode

CONTRIBUTOR

Simon Perkins
06 NOVEMBER 2008

The Waterfall Versus Whirlpool Project Management Methods

"'Whirlpool' projects embrace the fact that requirements are volatile. Instead of trying to deliver a system that satisfies 100% of the requirements in one go, the focus is on delivering an agreed subset of the requirements at intervals. Use cases are the building blocks of requirements and provide a convenient basis for risk assessment and prioritising. The riskiest and most significant use cases are tackled first, within the context of a clearly understood architectural vision. Tackling risk early identifies problems before they become too expensive or threatening, and helps lead to more stable architectures. The system evolves as a sequence of increments, each one an enhancement to the already–delivered functionality.

The development process for each increment is founded on the idea of a workflow, consisting of activities. For example. instead of having an analysis stage followed by a design stage, a worker might be engaged in analysis activities and design activities, depending on the job in hand. It is important to recognise that analysis activities focus on the problem space, while design activities focus on the solution space. A good understanding of one part of the problem may well lead to faster progress to design in that area. It is also possible that design activities highlight shortcoming in the analysis or even the requirements, in which case these are amended to reflect the newer (and hopefully better) understanding.

Successive iterations converge on a more complete, correct and consistent model, leading ultimately to implementation and delivery."
(Tecademy)

1

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.