Thursday 10 May 2007
Wednesday 25 April 2007
I can see it is going to take some time to get into this. Having watched the mighty Saints fall to Leeds at the weekend and Chelsea fail to capitalise on Man U slipping up my weekend of sport was ruined. Lets hope the blues can get the better of the reds tonight.
Well I have my most recent set of requirements for my up coming project and am re-writing them as use cases. I can see everyone jumping up, but the requirements read like minutes from a meeting, only slightly ordered. There has been no effort to attempt to quantify what the vision is and then wrap the requirements around the vision, and there is far too much specification of the solution.
Having just spent a week at the behest of my boss formalising what we call a HLD, High level design, I am now giving the results their first try out. Some background. Our HLD has always been one document with no real formalised structure, we have always started with a set of UML use cases and UML activity diagrams, then defined a deploment diagram (non uml) and from there component diagram (logical architecture) then maybe throw in some sequence diagrams and screen flows for good measure, all coupled together with text. Further problems are that no one developer uses the same diagrams or follows the same pattern. How do the business cope with technical documentation that continuously changes from team to team? You may ask!!
Firstly, remember all documentation must have some value, most books and sources describe this value in the sense of does it give the business value for money, however I also think that as developers we all have our strengths and weaknesses, so if you think your coding/end product will benefit from you doing something that potentially would not otherwise give the project benefit directly, then think of it giving the project benefit indirectly, not all documentation ahs to be for the directors. Remember it is essentially the end product that matters, and if you can deliver that to the customer without documentation, then you are either short sighted and lucky or just damn good? Take a long hard look at yourself before you pick one of those to describe yourself. Remember we all have weaknesses, the best thing is to recognise them and try to mitigate them by formalising a structure around them.
Having spent time reading a number of resources on Agile Development processes, I am currently proposing to silently ditch the HLD for a Design Pack (still called a HLD, shock and awe does not generally work in the business environment). Now logically this pack is split into two parts 'Requirements' and 'Design'.
In the Requirements pack we will include the BA's Requirements Document, a new 'Use Case' and a new 'Supplementary Specification' document.
The 'Requirements Document' is what the analysts present us with when we are allowed access to the project. Yes unfortunately I am drowning in niagra falls, however I intend to try to steer part of the process to a Agile method but we can only go very slowly. The documents have been written so that they can flex towards Agile Methodologies but if you were being strict they would need some tweeking.
In the design pack we have a document that is split into 8 parts. Not all parts warrant completion every time just what is needed. I have steered away from 8 individual documents because not all of these parts can really stand on their own and having too many documents can become complicated to manage.
Requirements Documentation
1. Use Case Document
Part I : This describes the Use Cases in Brief which takes a casual format with or without alternate scenarios and identifies the Primary, Supporting and offstage actors. It is this element you would look to complete 80% of during Inception to gain you an overview of the main requirements.
Part II : This describes the use cases in full or 'Fully Dressed'. This element would be completed in inception during a waterfall process but in Agile it is completed iteration by iteration, choosing the cases/part of cases to work on iteration by iteration, until complete. So in an iteration of 3 weeks you may spend 2 days at the start expanding use cases and design.
Part III : UML Use Case Diagrams for supporting the use case text.
2. Supplementary Specification
A document whos purpose is to capture 'URPS' (usability, reliability, performance, supportability) attributes or requirements that do not sit as use cases (features).
Design Documentation
1. Design Document
Part I : Domain Model
Part II : Deployment Architecture
Part III : Logical Architecture
Part IV : Operational Contracts
Part V : Activity Diagrams
Part VI : Sequence Diagrams
Part VII : Class Diagrams
More on these later
reference : 'Applying UML and Patterns' - Craig Larman
Well I have my most recent set of requirements for my up coming project and am re-writing them as use cases. I can see everyone jumping up, but the requirements read like minutes from a meeting, only slightly ordered. There has been no effort to attempt to quantify what the vision is and then wrap the requirements around the vision, and there is far too much specification of the solution.
Having just spent a week at the behest of my boss formalising what we call a HLD, High level design, I am now giving the results their first try out. Some background. Our HLD has always been one document with no real formalised structure, we have always started with a set of UML use cases and UML activity diagrams, then defined a deploment diagram (non uml) and from there component diagram (logical architecture) then maybe throw in some sequence diagrams and screen flows for good measure, all coupled together with text. Further problems are that no one developer uses the same diagrams or follows the same pattern. How do the business cope with technical documentation that continuously changes from team to team? You may ask!!
Firstly, remember all documentation must have some value, most books and sources describe this value in the sense of does it give the business value for money, however I also think that as developers we all have our strengths and weaknesses, so if you think your coding/end product will benefit from you doing something that potentially would not otherwise give the project benefit directly, then think of it giving the project benefit indirectly, not all documentation ahs to be for the directors. Remember it is essentially the end product that matters, and if you can deliver that to the customer without documentation, then you are either short sighted and lucky or just damn good? Take a long hard look at yourself before you pick one of those to describe yourself. Remember we all have weaknesses, the best thing is to recognise them and try to mitigate them by formalising a structure around them.
Having spent time reading a number of resources on Agile Development processes, I am currently proposing to silently ditch the HLD for a Design Pack (still called a HLD, shock and awe does not generally work in the business environment). Now logically this pack is split into two parts 'Requirements' and 'Design'.
In the Requirements pack we will include the BA's Requirements Document, a new 'Use Case' and a new 'Supplementary Specification' document.
The 'Requirements Document' is what the analysts present us with when we are allowed access to the project. Yes unfortunately I am drowning in niagra falls, however I intend to try to steer part of the process to a Agile method but we can only go very slowly. The documents have been written so that they can flex towards Agile Methodologies but if you were being strict they would need some tweeking.
In the design pack we have a document that is split into 8 parts. Not all parts warrant completion every time just what is needed. I have steered away from 8 individual documents because not all of these parts can really stand on their own and having too many documents can become complicated to manage.
Requirements Documentation
1. Use Case Document
Part I : This describes the Use Cases in Brief which takes a casual format with or without alternate scenarios and identifies the Primary, Supporting and offstage actors. It is this element you would look to complete 80% of during Inception to gain you an overview of the main requirements.
Part II : This describes the use cases in full or 'Fully Dressed'. This element would be completed in inception during a waterfall process but in Agile it is completed iteration by iteration, choosing the cases/part of cases to work on iteration by iteration, until complete. So in an iteration of 3 weeks you may spend 2 days at the start expanding use cases and design.
Part III : UML Use Case Diagrams for supporting the use case text.
2. Supplementary Specification
A document whos purpose is to capture 'URPS' (usability, reliability, performance, supportability) attributes or requirements that do not sit as use cases (features).
Design Documentation
1. Design Document
Part I : Domain Model
Part II : Deployment Architecture
Part III : Logical Architecture
Part IV : Operational Contracts
Part V : Activity Diagrams
Part VI : Sequence Diagrams
Part VII : Class Diagrams
More on these later
reference : 'Applying UML and Patterns' - Craig Larman
Thursday 19 April 2007
What is this blog?
This is just another blog about my everyday battle to keep up to date with development languages, patterns and practices, oo design while at the same time keeping the wife happy. ;-) I may even throw in the odd thing about Rugby League and the best Rugby League team in the world 'The Saints'.
http://www.saintsrlfc.com/
In all seriousness, It seems that we learn new concepts on a daily basis, however when we do not use them we soon forget them and start applying them incorrectly. This is hopefully a way for me to write down my thoughts on these subjects and enable me to look back when I am banging my head against a wall to give me inspiration. Well thats the idea anyway, whether it works, well who knows, maybe it will even inspire some of you!!! I Doubt it tho.
Appologies for my english, not my best subject at school, although what was. ;-).
Anyway, I am currently some way through reading the book;
I would recommend this book to any developer at any level, and wish I had read it before now. If you have not bought it or read it, buy it NOW and read it tommorrow, do not wait.
I will start talking about modeling rather than what Larman starts with which is in a nutshell Unified Process and Agile Development, thats because thats the bit i'm wading through now while lighting bolts flash over my head and big Ahhhaaaa escapes from my mouth, as I start to understand stuff I have known for years but never formalised.
For an overview on Agile Methodologies goto :
http://en.wikipedia.org/wiki/Agile_software_development
Anyway ive started now so hopefully I can keep this up, but as developers we all know it never finishes. We must be MAD!!!
Catcha later.
Paul
http://www.saintsrlfc.com/
In all seriousness, It seems that we learn new concepts on a daily basis, however when we do not use them we soon forget them and start applying them incorrectly. This is hopefully a way for me to write down my thoughts on these subjects and enable me to look back when I am banging my head against a wall to give me inspiration. Well thats the idea anyway, whether it works, well who knows, maybe it will even inspire some of you!!! I Doubt it tho.
Appologies for my english, not my best subject at school, although what was. ;-).
Anyway, I am currently some way through reading the book;
'APPLYING UML AND PATTERNS An Introduction to Object-Oriented Analysis and Design and Iterative Development 3rd Edition'
by Craig Larman.
I would recommend this book to any developer at any level, and wish I had read it before now. If you have not bought it or read it, buy it NOW and read it tommorrow, do not wait.
I will start talking about modeling rather than what Larman starts with which is in a nutshell Unified Process and Agile Development, thats because thats the bit i'm wading through now while lighting bolts flash over my head and big Ahhhaaaa escapes from my mouth, as I start to understand stuff I have known for years but never formalised.
For an overview on Agile Methodologies goto :
http://en.wikipedia.org/wiki/Agile_software_development
Anyway ive started now so hopefully I can keep this up, but as developers we all know it never finishes. We must be MAD!!!
Catcha later.
Paul
Subscribe to:
Posts (Atom)