Category: Project 21

Mike Allen’s new methodology

Project 21 not dead just resting!

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!

Update to Interfaces

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 are fun!

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.

Is this an Agile methodology?

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.

Navigation Updates and Methodology Blogging

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.

Logical Design Rewrite

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.

Information Model Visualizations

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.

Conceptual data modelling

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.

Logical Design – at the workface

I’ve just put the Logical Design page up, and I seem to need more content, so it’s back to the writing desk to create this bit. This will be interesting as I try to describe what is often a very dynamic process in words that other people can understand. I’ll set myself a target of Friday and get started. This may be the start a a slightly more formal approach as it involves ‘Use Cases’.