程序代写代做代考 flex 17spm_L17

17spm_L17

Dynamic System Development Method

SPM 2017 © Ron Poet Lecture 17 1

Dynamic System Development Method

� Launched in 1995.
� A framework designed for software systems but also applied to other

business change methods.
� Typically used for projects with a time frame of 3 to 6 months.
� Principles

SPM 2017 © Ron Poet Lecture 17 2

� Principles
o The main cause of failure is people issues.
o 80% of the solution can be produced in 20% of the time.
o Things can always be completed later.
o Meet the current needs of the business.
o Choose simple solutions that are fit for purpose.

The Eight Principles (1, 2)

� Focus on the business needs.

o Understand the true business priorities.

o Establish a sound business case.

o Seek continuous business sponsorship and commitment.o

o Guarantee to produce the top priority deliverables.

� Deliver on time

o Timebox the work.

o Focus on the priorities of the business.

o Always hit deadlines.

3SPM 2017 © Ron Poet Lecture 17

Principles (3, 4)

� Collaborate

o Involve the right stakeholders at the right time throughout the
project.

o Empower the members of the team to take necessary decisions.

o Actively involve the business representative.

o Build a team culture.

� Never Compromise on quality

o Determine the required level of quality at the start.

o Don’t drop quality for any reasons.

o Design, document and test continually.

o Ensure quality by constant review.

4SPM 2017 © Ron Poet Lecture 17

Principles (5, 6)

� Build incrementally.

o Deliver business benefit early whenever possible.

o Continually confirm that the right system is being built.

o Formally reassess the project at the end of each iteration.o

� Develop iteratively.

o Do enough design up front to create a strong foundation.

o Build everything iteratively.

o Customer feedback after each iteration.

o Most details emerge later rather than sooner.

o Experiment, learn and evolve.

5SPM 2017 © Ron Poet Lecture 17

Principles (7)

� Communicate Continuously

o Daily team standup sessions.

o Facilitated workshops.

o Modelling and prototyping.o

o Present the current full solution early and often.

o Keep documentation lean and timely.

o Manage stakeholder expectations.

o Encourage informal face-to-face communications.

6SPM 2017 © Ron Poet Lecture 17

Principles (8)

� Demonstrate control.

o Formal approach to track and report progress.

o Plans and progress visible to everyone.

o Measure progress by delivery of products rather than completed o
activities.

o Manage proactively.

o Continually evaluate the project viability.

7SPM 2017 © Ron Poet Lecture 17

Lifecycle

� There is more initial planning than in other agile methods and it is an
agile approach to iterative development.

� Initial work

o Pre-project.

o Feasibility

o Foundations

� Main cycle, usually repeated.

o Exploration

o Engineering

o Deployment

� Post-project

8SPM 2017 © Ron Poet Lecture 17

Three Iterations

� Investigation

o The first iteration produces a rough working system.

o The team learns what needs to be done for the proper version.

o Takes 10 – 20% of the total time.o

� Refinement

o Build as much of the system as possible based on knowledge
gained in the investigation.

o 60 – 80% of the total time.

� Consolidation

o Finish up.

o 10 – 20% of the total time.

9SPM 2017 © Ron Poet Lecture 17

Initial Work

� Pre-project

o Outlines the business case for the project and the project sponsor.

o Resources for a feasibility study are obtained.

� Feasibility study

o Outlines possible approaches to the problem and estimates the cost
and timescale.

o Outlines business benefits and risks.

o If favourable, resources for the project are obtained.

� Foundation.

o High-level requirements, business case and schedule.

o Outline management and team structure and development plan

10SPM 2017 © Ron Poet Lecture 17

Vertical or Horizontal

� Requirements can be developed in two ways.

� Vertical

o Requirements are developed in full but sequentially.

o A basic system is available early on, with more functionality added o
later.

� Horizontal

o Simplistic versions of all requirements are developed together at
the start.

o Each requirement evolves as the system is developed.

11SPM 2017 © Ron Poet Lecture 17

Main Cycle

� Exploration

o Produce models and prototypes to learn more about possible
solutions.

o The code will not be used.

� Engineering

o Builds the actual code.

� Deployment

o The solution is used by the business.

o Training and support for users is provided.

o The product is reviewed.

o A decision is made about further iterations.

12SPM 2017 © Ron Poet Lecture 17

Post-Project

� 6 months after the deployment phase of the final iteration.

� A review on how well the project met the business objectives.

13SPM 2017 © Ron Poet Lecture 17

Roles

� There are a large number of different roles that people occupy.

� Of course, one person can occupy several roles.

� There are 3 families of roles:

o Businesso

o Technical

o Management

14SPM 2017 © Ron Poet Lecture 17

Business Roles

� Business Sponsor

o Make the business case and obtain the resources needed to keep
the project going.

o A largely political role.

� Business Visionary

o Looks after the detailed business needs.

� Business Analyst

o Makes sure requirements are correct and communicated to
developers.

� Business Advisor: Subject matter specialist.

� Business Ambassador: Represents users.

15SPM 2017 © Ron Poet Lecture 17

Technical Roles

� Technical coordinator

o Chief designer and technical expert.

� Team leader

o Leads the development team.o

� Solution developer

o Programmer

� Solutions tester

o Tests the code.

16SPM 2017 © Ron Poet Lecture 17

Management Roles

� Project manager.

o Looks after the big picture

� Workshop facilitator

o Plans the workshops, which are a main way of keeping o
communications open.

o An independent chair.

� DSDM Coach

o An expert on the DSDM framework.

17SPM 2017 © Ron Poet Lecture 17

Workshops

� Much of the requirement for good communication between people is
achieved with workshops.

� The facilitator does not contribute to the technical content of the
workshop.

o They plan the format: brain-storming, story boards, mind maps, o They plan the format: brain-storming, story boards, mind maps,
SWOT charts etc with flip charts, white boards and sticky notes.

� Strength, Weaknesses, Opportunities, Threats.

o They make sure everyone contributes and no one dominates.

o Make sure the goals are achieved.

18SPM 2017 © Ron Poet Lecture 17

Workshops (2)

� The workshop owner will benefit from the information the workshop
delivers.

o They define the objectives and provide the funding.

� The participants.

o Provide the solutions.

� The scribe records the outcomes and follow up actions.

19SPM 2017 © Ron Poet Lecture 17

Workshop Facilitator Tasks

� Define the objectives and plans with the workshop owner.

� Prepare by distributing the agenda and objectives to the participants.

� Run the workshop.

� Review the workshop at the end.

� Distribute the scribes report. These are not minutes but summaries of
decisions.

� Follow up the workshop with the workshop owner.

20SPM 2017 © Ron Poet Lecture 17

Assigning Priorities

� Use MoSCoW system.

� Start with everything as “Would Like To Have”.

o The business must argue to increase the level.

� Challenge all “Must Haves” to make sure they really are vital.

� Regularly re-evaluate priorities.

� Can’t make everything a Must Have!

21SPM 2017 © Ron Poet Lecture 17

Timeboxing

� A timebox is an iteration!

� It starts with a Kick Off meeting in the usual way.

� It ends with a Close Out meeting.

o This often runs back to back with the next Kick Off meeting.o

� Each day starts with a 15 minute standup meeting in the usual way.

� Keeping to the timeboxes means that everything will always be
delivered on time!

o In practice this means that all the Must Haves will be delivered.

o If the project goes well then some of the other requirements will
also be delivered.

22SPM 2017 © Ron Poet Lecture 17

Estimating

� The schedule is produced first.

� The effort required for all the requirements is estimated.

� The overall effort that can be spent on the project is then calculated.

� The scope (which requirements will be done) is then decided.

� Some contigency time must be allocated to cope with unexpected
difficulties.

o Should Have and Could Have requirements provide the flexibility
to cope with problems and still deliver the contracted system (the
must haves).

o Therefore, Must Haves should not account for more than 50% of
the initial requirements.

23SPM 2017 © Ron Poet Lecture 17

Estimating (2)

� People doing the work should make the estimates.

� An estimating workshop is the ideal place.

� Estimates of the effort required for the whole project should be made.

� They should be low precision, with typically 3 values.

o Low: just do the Must Haves.

o Medium: add Should and Could items.

o High: add the difference between medium and low on to the
medium estimate.

� Once into timeboxing (iterations), the time and effort is fixed.

� The only thing that can be changed is how many features are delivered.

24SPM 2017 © Ron Poet Lecture 17

Quality

� Quality is defined as:

o A minimum set of useable functions (the Must Haves)

o Usability and performance metrics.

o Maintainability.o

� There are three levels of maintainability, the customer decides which
one he wants.

o Maintainability is essential.

o A working solution is delivered as soon as possible. A
maintainable version will then be delivered later.

o All that is wanted is a workable solution that will not be
maintained.

25SPM 2017 © Ron Poet Lecture 17

Measuring Quality

� Don’t let quality management interfere with the process.

� Have periodic quality reviews.

� Show that correct processes are being used.

26SPM 2017 © Ron Poet Lecture 17

Risk Management

� Identify risks in a risk workshop.

o Impact: how much damage it could cause.

o Probability: how likely.

� Produce a risk log

o The risk and who owns it.

� Work out countermeasures for each risk.

o Prevention: may be quite costly

o Reduction: reduce the probability

o Acceptance: nothing can be done.

o Transfer: insurance or to a supplier

� Contingency plan: in case it happens.

27SPM 2017 © Ron Poet Lecture 17