I’ve been reviewing Project 21 and how it fits in relationship to Agile and other methodologies. The theme of Project 21 can be broken up into three segments Analyse, Design and Construct. Repeat until the project is complete. These segments are not mutually exclusive, but in a self-assembling team they would have different, but overlapping primary participants.
I didn’t originally set out to structure the methodology this way, but then I realised that all my analysis was conceptul, which made that one simple. Design started as Logical and Physical Design, which are always next to each other, so that’s the design segment. Often the same team members are involved with logical and physical design, and it can be regarded as a continuum joining analysis to construction. Contruction is the goal, and testing has to be part of that.
For the one-man team this is simple. Think about what you are about to do, then how you are going to do it and then do it. Repeat until complete.
The mechanism for joining all of this together is the model, the conceptual model is the home of the end users vision of what the system will achive, curated by team members, so that it is realistic.
The design model is the common model against which the project is constructed, it should be minimalistic and descibe sufficient features to tie conceptual thinking and construction together.
I’m tempted to use the term Domain Model as a unifying model that rules everything.
I’ve decided it’s time to spend a little more time on Project 21. I’ve recently been involved in a development project and I feel better qualified to write on this subject from a contemporary viewpoint, so I will. I’m also reading Scott Ambler’s fine book ‘Disciplined Agile Delivery’. I thought that as I went through the book that I would see how Project 21 handles the various aspect of Agile.
Project 21 in principally designed as a lightweight methodology for small multi-disciplinary teams, so by its nature it should be Agile.
I’ve been a bit too busy to get around to Project 21 lately, but I will get around to it. I’ve been working on my own web site at http://www.mikeallen.com.au and other projects. I intend to get back to methodology as soon as I can. My next update will begin to integrate the Business Motivation Model(BMM) into my ideas. I’ve had a bit of an epiphany about functional and non-functional requirements and I need to work it through in the BMM context. I think the functional/non-functional divide, while useful, can be considerably improved on by using the BMM. The BMM has enormous potential to change the way we think about business and technology and can enable us to fully integrate technology into the business plan. This can create a real Win-Win scenario where business can clearly associate technology with business needs and technologists can link their solutions directly to the business plan.
Watch this space for more updates real soon!
I’ve completed an update of the Logical Design of Interfaces, human interfaces that is, and I’ve found a fertile area for more visualizations of the way that people can interact with the system. This connect very well with Use Cases, which looks like it will be the next area for an upgrade. The division of the development phases of the methodology into the User Interface, Process and Data streams is not meant to define separation but more aspects of development that complement each other in the completed solution. I say this because I don’t see the methodology as rubber stamping three-tier development, which was a good approach for traditional client server, but was never meant to be the ideology that some people make it into.
If there is any ideology in this methodology it is the ideology of ‘connectedness’, that no aspect of a system can be viewed in isolation and out of context. The useful synthesis of ideas and visulizations with business process and data should be apparent in the user interface and how people interact with that interface.
Non-functional requirements seem to be a really hot topic, I suspect that my blog is getting a lot of hits because there’s not a lot out there on the subject. I may be going against what I’ve already put on the Project 21 page but I think I have a growing feeling that non-functional requirements should be related to the ‘Ends’ and that Functional requirements are related to the ‘Means’. Looking at the OMG Business Motivation Model (BMM) tends to confirm this and gives a much firmer logical basis for non-functional requirements. It probably also indicates that we should be calling them something else like ‘Business Requirements’, which kind of fits in with having ‘Business Use Cases’ with ‘Functional Requirements’, that make those Business requirements happen. I kind of like having BMM compliant requirements, because that just says what they are and how they relate, not how you express them. So if you wanted to express requirements in RDF or some ontological form that would fit in quite well. It has some implications for traceability as well, if a function cannot be traced back to a non-functional requirement why would it be needed? I’m going to back track and redo requirements in the next few weeks, this should be fun.
Working on the design process makes me think that Project 21 sometimes looks like Agile and sometimes not, depending on which stage it is at. Considering the Agile and the Business Analyst are often at odds, this seems to be perfectly normal. Just by trying to separate the analysis of the problem from the design of the solution exposes the Agile dichotomy; is it possible to design a solution without analyzing the problem? The answer must be a definite maybe, but for any non-trivial problem analysis and design are needed to ensure that the solution solves the problem. Project management methodologies tend to go around this issue by being prescriptive about eliciting requirements and signing off, yet Agile addresses the issue of the requirement developing with the solution.
To a degree both approaches have their merits, if the user can state business requirements at a high level these can be quantified in the development cycle. The design phase can say ‘we address these broad requirements’, and development can refine the detailed requirement. I’m not going to brand Project 21 as purely an Agile methodology, it is an adaptable methodology.
I’ve noticed that I’m not getting a lot of navigation between pages so I’ve started puting some navigation links in the appropriate places, so that people aren’t relying on ‘Contents’ for navigation but can go straight to Project 21 pages via hyperlinks where the page is referenced. I’m still mulling whether I need page navigation with a ‘next’ and ‘previous’ and ‘up’ context. I’m back on content this week and working on the heartland of logical design, hope to publish and blog a bit more by next week. Teasing apart Analysis and Design is quite interesting, I think the pressures of teaching mean that most I.T. people see it as a single process. Business people on the other hand want to skip analysis and design completely and go stright to the solution! Maybe I’m generalizing too much, but ther’s no doubt of the popularity of single stage development, where the user dictates requirements and the programmer creates the solution. Single stage development can work in some instances but falls over in the face of complexity, which is why I’m pitching my methodology in that nice sunny spot between the rapids of Agile and the mythical Waterfall.
It looks like I need to put a little more work into Logical Design, I’ve realised now that defining scope can occur several times, as the analysis and design refine the problem and the solution. After analysis the decision needs to be made of ‘how much’ of the problem needs to be solved, which comes down to the process model and detemining the Use Cases. I’m trying out some new blogging software BlogDesk, which seems to be doing the job, so far, soo good.
I’ve added some visulizations to the Information Model. I’ve come to think that a blog without visualizations is like a book without pictures, and visualization is a very important part of the modeling of a software solution. This marks another milestone for me as the online document is now in advance of the offline document; but I will pull the offline version into line today.
I’ve been reviewing the conceptual data area, what I have called the ‘Information Model’ and I’ve come to the conclusion that the Data Structure Diagram is what I’m after, albeit with arrows, not crows feet. One of the advantages of the DSD is that you can describe an interface fairly readily with it and put objects inside each other. I think the crow’s feet belong at the Logical E-R diagram level. Thinking about these areas does make you realise how limiting the conventional UML class diagram can be in conceptual and design thinking.