Show Menu

System Development Methodologies Cheat Sheet by

System Development Methodology Revision

Key aspects of a method­ology

Should promote activity which is:
and produce results that are:
Remember that a method­ology is only a means to an end and not an end in itself

Dynamic Systems Develo­pment Method Image

Extreme Progra­mming (XP) Method­ology

For creating software within a very unstable enviro­nment
Allows flexib­ility within the modelling process
Main goal to lower the cost of change in software requir­ements
XP Core Practices
Fine scale feedback
Test driven develo­pment
Planning game
Whole team
Pair progra­mming
Continuous process rather than batch
Continuous Integr­ation
Design Improv­ement
Small Releases
Shared unders­tanding
Simple design
System metaphor
Collective code ownership
Coding standards or coding conven­tions
Programmer welfare
Sustai­nable pace (i.e. forty hour week)
Corollary practices
Intera­ction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and priori­tizes work for the team, and who can answer questions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
If learning is good, take it to extremes: Reduce the length of develo­pment and feedback cycles. Test early.
Simple code is more likely to work. Therefore, extreme progra­mmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplic­ation in their code.
If simple code is good, re-write code when it becomes complex.
Code reviews are good. Therefore XP progra­mmers work in pairs, sharing one screen and keyboard (which also improves commun­ica­tion) so that all code is reviewed as it is written.
Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refact­oring to remove comple­xity). The system is period­ically, or immedi­ately tested using all pre-ex­isting automated tests to assure that it works. See test-d­riven develo­pment.

What can go wrong?


Re-use - Search for ‘Short­-Cuts’

Re-use, clone, develop
Packages (modif­y/t­ailor)
Share code/l­ibr­ari­es/­buy-in
Build new interfaces
Umbrella systems
Leverage existing system­s/e­xpe­rience

Top tips

Avoid Poor Estimating and/or Scheduling
Avoid Ineffe­ctive Stakeh­older Management
Avoid Insuff­icient Risk Management
Avoid Insuff­icient Planning
Avoid Shortc­hanging Quality Assurance
Avoid Weak Personnel and/or Team Issues
Avoid Insuff­icient Project Sponso­rship

Why do we have different types?

Degrees of the problem domain, hard and soft
Peoples particular mind sets
Easier to use hard approaches
Soft provide greater insight

Dynamic Systems Develo­pment Method (DSDM)

Active user involv­ement is imperative
Focus is on frequent delivery of products
DSDM teams must be empowered to make decisions
Fitness for business purpose is the essential criterion for acceptance of delive­rables
Develo­pment is iterative and increm­ental
All changes during develo­pment are reversible
Requir­ements are baselined at a high level
Testing is integrated throughout lifecycle
Collab­orative and co-ope­rative approach between stakeh­olders is essential
Key Features
Deliver quickly and often (timeb­oxing)
Critical functi­onality delivered (MoSCoW)
Joint Applic­ation Develo­pment workshops (JAD)
Protot­ypi­ng/­tools used to validate user requir­ements
Extreme Progra­mming (user stories, paired progra­ming, focus on commun­ication and teamwork)
Requir­ements not fully defined before develo­pment
Culture change
Benefits - overcomes:
Long iteration of refine­men­t/a­gre­ement
Contacting key partie­s/a­rra­nging meetings
Cycle of meetings
Resolving different views/­per­spe­ctives
Changing requir­ements during process
Loss of moment­um/­com­mitment
Deliver on time to budget
Does not cut important corners
Results from practical experience

Systems Develo­pment Life Cycle (SDLC) Method­ology

Conceptual model used in project management
Water fall was original
Describes the stages involved in systems dev project
Docume­ntation is crucial
Docume­ntation is done in parallel with the develo­pment process
Most important factor project success may be how closely the plan was followed
If there is an existing system its defici­encies are identi­fied. Iterview users, consult with support personnel
New system requir­ements are defined
addressing any defici­encies
with specific proposals for improv­ement
System is designed, plans created for:
operating systems
security issues
System is developed
Components and programs must be obtained and installed.
Users must be trained
Perfor­mance must be tested. Adjust­ments must be made at this stage.
System is deployed
might be phased in
shut down the old system and implement the new system all at once
Monitor and maintain
Evaluate system post deploy
Mainte­nance must be kept up
Users should be kept up to date
Clear project object­ives.
Stable project requir­ements
Progress of system is measurable
Strict sign-off requir­ements
Time consuming
Little room for iteration
Difficulty responding to changes


Protot­ypi­ng/CASE tools
Ability to deliver quickly
Experi­men­t/try out ideas
Project management
Encourages re-use
Version control
Automates testin­g/s­ystem cut-over
Prototype is the technical specif­ica­tion, a repository provides self docume­ntation

Rapid Applic­ation Develo­pment (RAD)

Different versions exist
DSDM (Dynamic Systems Develo­pment Method)


Must have – without these features the project is not viable (min. CSFs)
Should have – to gain maximum benefit, these features will be delivered
Could have – if time and resources allow these features will be delivered
Won’t have – these features will not be delivered

Waterfall (a.k.a. Tradit­ional) Method­ology

Version of the systems develo­pment life cycle model
Classic approach
Rigid and linear
Distinct goals for each phase of develo­pment
Each phase is completed before the next one is started
There is no turning back
allows for depart­men­tal­ization
allows for managerial control
In theory project will be delivered on time due to planning and process
often falls short of expect­ations
does not embrace the inevitable changes and revisions that become necessary with most projects
Once an applic­ation is in the testing stage, it is very difficult to go back and change something that was not thought of in the concept stage

Scrum Method­ology

Agile method
Goal is to dramat­ically improve produc­tivity in teams previously paralyzed by heavier, proces­s-laden method­ologies
Charac­terized by
A living backlog of priori­tized work to be done
Completion of a largely fixed set of backlog items in a series of short iterations or sprints
A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and obstacles are raised
A brief planning session in which the backlog items for the sprint will be defined
A brief heartbeat retros­pec­tive, at which all team members reflect about the past sprint
Facili­tated by a scrum master
Scrum master role
Primary job is to remove impedi­ments of team to deliver sprint goal
Not leader of team (team is self-o­rga­nizing)
Acts as produc­tivity buffer between team and destab­ilizing influences
Enables creation of self-o­rga­nizing teams
Encourages verbal commun­ication across team members and across discip­lines
Adopts an empirical approach - accepting the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to respond in an agile manner to emerging challe­nges.

Practi­tioner Advice

Senior management should support the project whole heartedly
Detailed planning should be undertaken
Project management principles should be applied
The key business objectives should be identified and kept in focus
Requir­ements should be evolved over time by the use of protot­ypes.
Organi­sat­ional politics must be considered and navigated
Ensure adequate investment is made
Develop realistic implem­ent­ation timescales
Use an approp­riate develo­pment approa­ch/­method for the context
Identify users and stakeh­olders and involve them
Ensure you have skilled, proactive IT/IS people
Changing requir­ements should be recognised as a normal occurrence and systems need to be put in place to facilitate this
The technology itself should be proven
Any contra­ctors should be managed as if they were an internal team
Problems should be evaluated and where relevant resolved as they are encoun­tered and not ignored
As a last resort, if serious problems are encoun­tered, project timescale should be delayed, rather than risk a disaster


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Regular Expressions Cheat Sheet
          Python Cheat Sheet
          Master Measures & Weights with this Cheat Sheet Cheat Sheet

          More Cheat Sheets by NatalieMoore