Show Menu
Cheatography
  1. Home >
  2. Programming >

System Development Methodologies Cheat Sheet by

System Development Methodology Revision

Key aspects of a method­ology

Should promote activity which is:
-
Purposeful
-
Controlled
-
Rigorous
and produce results that are:
-
Meaningful
-
Reprod­ucible
-
Relevant
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?

Deadlines
Equipment
Requir­ements
Vendors

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)

Princi­ples:
-
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
-
Re-use
-
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
Steps:
1.
If there is an existing system its defici­encies are identi­fied. Iterview users, consult with support personnel
2.
New system requir­ements are defined
-
addressing any defici­encies
-
with specific proposals for improv­ement
3.
System is designed, plans created for:
-
hardware
-
operating systems
-
progra­mming
-
security issues
4.
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.
5.
System is deployed
-
might be phased in
-
shut down the old system and implement the new system all at once
6.
Monitor and maintain
-
Evaluate system post deploy
-
Mainte­nance must be kept up
-
Users should be kept up to date
Benefits
Clear project object­ives.
Stable project requir­ements
Progress of system is measurable
Strict sign-off requir­ements
Disadv­antages
Time consuming
Little room for iteration
Difficulty responding to changes

Protot­yping

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)

MOSCOW Rules

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
Benefits
-
allows for depart­men­tal­ization
-
allows for managerial control
-
Deadlines
-
In theory project will be delivered on time due to planning and process
Problems
-
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
Benefits:
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
 

Metadata

  • Languages:
  • Published: 8th November, 2016
  • Rated: 4 out of 5 stars based on 2 ratings

Favourited By

rubashov4 theLand54 brusurf sevenbates

Comments

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