• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

artifacts for design

 
Ranch Hand
Posts: 3851
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What artifacts you design for a project? And what name do you give to them? For example Functional Specification, Technical Specification or Low Level Design Document etc.

Thanks.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It would be nice to have a cookbook for all this, and some folks think methods like RUP or books are just that. But you have to customize what you make to meet the needs of your own team. I pull this out about once a week:

______ reads ______ to learn _______ so they can ______

"Developers read the design to learn class hierarchies so they can code them"

"Enterprise architects read the architecture document to learn what protocols the system uses so they can approve them or recommend changes"

Statements like this might tell you that you need a document. Or you might quickly spot better ways to communicate - presentation, code reviews, face to face meeting, etc.

See Scott Ambler's web sites - AgileModeling.com comes to mind - for some down to earth advice on when to make documents and models and when something else might be better.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or main artifacts are a release plan (a simple spreadsheet), user stories (on index cards) and the code with unit tests. We also *should* have acceptance tests (working on it). Everyting else is very much dependent on the situation - recently we are doing more and more quick design sessions on the white board, often some UML mixed with freeform elements as needed.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic