More UML

When I blogged the other day about the reason for confusion the two students had with UML was because of not having followed a formal process of collecting and analysing requirements. I was right.

It was on Friday evening when I met them at my office. They showed me their use cases, sequence diagrams drawn using MS Word! and a lot of other documents. The use cases were lengthy and often didn't make sense and included system design and ran into several pages. Some of the actors in the document had a limb missing (handicapped!) . Growing tired of it I finally gave these two a crasch course in OOAD and UML in 60 minutes and asked them to come back with the use cases.

Its a pity why people have a notion that UML is complex. Infact its probably one notation that provides syntax to capture most modelling decisions. Its also a wrong notion to expect UML or any of the tools that support UML like IBM Rational Rose or Together J to solve your modelling problems. Just like brush and paint do not create a picture; Rose and UML can't create a model. The artist or modeller should supply the thought. Hope you get the picture! Maybe someday I'll post a few steps on how to model software systems.

Unified Modelling Language

Yesterday I was surprised to receive a mail from a student of engineering asking if I could help clarify some doubts, that she had, about the UML. Well Yes I obliged. She had about 6 questions of which two of them caught my attention.

* From the sequence diagram(drawn to a underlying software but not the GUI) how to synthesis .h &.c files for a frame work?

* Can i have a sequence diagram without a actor?if i can how to represent a external event generating the request?

I couldnt understand the 1st question, but was pretty sure that this dame was using OOAD and UML to design something that was to be implemented in the "C" language. The mention of .h and .c files indicated this. She also went on to explain that she had trouble in maintaing state chart diagrams. What else can you expect when you use OOAD for a non object oriented language like "C"?

Now on to the second question. Well its not possible to have a sequence diagram without an actor but by asking this question she just showed that the procedure of gathering requirements, analysing and decomposing was not followed. Pity that this project is part of her curriculum.

Best wishes for a memorable 2005 and beyond

Oracle Partner Network

Was at the OPN ISV forum at the ballroom of Taj Coromandel, yesterday. The forum was hosted by Oracle, Sun and AMD. Lot of presentations on why one should partner with Oracle and the benefits of OPN. For one, I finally got a clear picture of "GRID COMPUTING" that Oracle talks about when it markets 10g. Looking forward to the 10g workshop and 3 day ISV tech forum scheduled for mid Jan and March next year.

Minimum "New Work" ... SurvivalSkills2005

Tom Peters author of "Liberation Management", "In Pusuit of WOW" etc offers his Survival Kit for 2005.

Currently Reading




Currently Listening




 

Amazed Tux! 

Business Proposals

Every time I read a business proposal to a potential client I am amazed by the amount of overhead (bullshit) we add in the document - A lot of stuff about your company's history (Nobody cares), the clients history etc. I am a little taken aback by the client's history part, I wonder which joker would want to tell a client about themselves. I dont know who started this practice but its definitely funny. Some really very cautious sales execs put in a lot of riders to cover their backsides. So essentially you'll end up with a proposal that will tell you a lot about what you will not do for your client rather than what you will do.

Now that brings us to what should be contained in a proposal. For one I believe that you should assess what the client wants to accomplish. It may be business targets like - increase customer base, improve turn around time of tele callers, increase the number of credit worthy customers etc etc.

You should highlight in your proposal that you have understood this busiess need; The solution you propose to achieve this; The mechanism you'll implement to facilitate achieving this business objective and the infrastructure you have to support this implementation. PERIOD. Nothing more nothing less. All this in about 10 - 12 pages including all title, revision history and everything else that your quality procedures require. Every other legal clause can be saved for the contract.

My recommendation would be to have the following contents in your proposal.
1. Situation Summary
2. Objectives
3. Value provided by you
4. Measure of Success - How will you measure that the objectives have been met
5. Methodology
6. Scope and Timelines
7. Critical Success Factors - A disguised way of highlighting accountabilities of the client
8. Compensation

Never title your proposal "Proposal"! Write a title that states the benefit to the client. E.g. "Increasing number of positive prospects", Highlight the key points using bullets or by emphasing text, eliminate jargon and quantify your benefits. You are sure to strike GOLD.

Getting Things Done

Been practising the art of "Getting things done" (David Allen). See my earlier post on the book. Over the last two weeks I've found that I am able to do a lot more, close the open loops and never visit them again. Did the weekly review second week in a row. Decisions are quicker and made with greater confidence. Projects move forward. Head is clear. No lapses in my Yoga routine.... All this without implementing the "Tickler File" system, not having an industrial strength stapler and an electronic labler. Looking forward to acquiring this GTD accoutrements! Wonder what else is in store for me.

My Yahoo!

If you havent seen the latest My Yahoo then I suggest that you rush to the portal and have a dekko. Those of you who already use the service you'll be in for some pleasant surprise. There are some really cool features.

For one My Yahoo now allows you to add content syndicated from other sources on the web. It allows you to create multiple pages instead of one so that you can add content based on the context - Professional, Personal etc. You can change the background theme if you wish. You can add all of Yahoo's services - mail, briefcase etc as content. Combine this with Yahoo Geocities for your personal home page. Now this is what I call great personalisation.

Currently Reading

The Great Arc

1600 miles, 50 years started circa 1800, no fewer than 700 men, few tons of equipment, Lethal Climate - Insects, Dense jungles, Malaria, Typhus fever, Tigers, Snakes etc.

Colonel William Lambton, Superintendent of the great Trignometrical Survey of India and later his successor Lieutenant George Eve-rest, inspite of the casualities (entire teams of about 150 were wiped out at times), mapped India.

Model of accuracy and the maps which it yielded faithfully....indicating 'the position of every town, fort, village.. all rivers and their courses, the roads, the lakes, tanks [reservoirs], defiles, mountains, and every remarkable object, feature, and propert of the country'

Inspite of the combined assault of climate and local prejudice which contributed to wiping out survey parties in single season, they carried on relentlessly sometimes taking long sabbaticals to recuperate from exhaustion and sickness.

Nothing gives a better idea of his passion for shaving tolerances to an infinitesimal minimum than this pursuit of a variable amounting to just seven thousandths of an inch.

But at times the measurements made by zenith observations could not be reconciled by triangulation.

It was said that if experienced observers, taking all possible precautions, found rhemselves confronting an anomoly for which they could not account, they were probably 'on the vergeof some important discovery'' - The fact that mountain masses exercise an attraction over the plumbline

Finally in 1857 the "Great Meridional Arc of India" was completed, The heights of the major himalayan peaks (Nanda Devi, K2, Kanchenajunga) were ascertained and Mount Everest was named (obvously in honour of Lieutenant George Eve-rest) . During this period Surgeon Ronald Ross discovered the source of Malaria at Begumpet (Hyderabad)

In the land of rope tricks, snake charners, superstions, spirituality and sadhus; This sweat soaked odyssey was the largest scientific endaevour known to man. It was one of the most stupendous works in the whole history of science.

An Awesome Project.

My laws on Software Project Management!

Here is a look at the lighter side of software project management. ENJOY!!!

1. The silliest bug will find your best customer.
2. If a software code has been found defective, its author has just embarked on a plane to the US.
3. After improving quality from 95% to 99%, the remaining 1% defects will find its way to your regular paying customer.
4. The moment you disciver that additional testing is required, the software code has lareday been FTP'd to your customer.
5. The number of Quality Control Procedures followed is inversely propotional to the number of programmers who folow them and the number of project managers who understand them.
6. The number of testing cycles that an application undergoes is directly proportional to the number of defects it is shipped with.
7. The best product that marketing wants to sell is the one which 'Product Delivery' is least interested.
8. The product in which both marketing and 'Product Delivery' agree upon is th eone in which the customer is least interested.
9. A mission critical application is likely to break down because of the smallest unit of code.
10. The probability of an application failing increases rapidly as the warranty period is about to expire.
11. A random sample in a Customer survey will not include a disgruntled customer.
12. The project manager who complains about quality the most is the one who understands quality the least.
13. If a company has just obtained its quality certification (ISO/CMM), customers have recently complained about the numerous bugs in the application.
14. When your client asks about a missing business requirement in the specifications, its probably the first time you ask the same question yourself.
15. When you conduct a training program, the person who needs it most will be firefighting to attend it.
16. During the arer times a manager enquires about a certain project, the projectmanager is on leave.
17. 90% of the software defects are discovered by your client, the rest by your testing team
18. The client who demands the most prompt delivery is the least prompt in payment.
19. The intensity or length of a company's celebration in launching a product or obtainig a project is inversely proportional to the life of it.
20. The more eloquent or impressive a presentation to a prospective cleint is, the more bleak is the chances of them buying the idea.

Cathedral and the Bazaar

A couple of days back I had blogged with comments on the book by Eric Raymond. This is what he has to say.

1. Every good work of software starts by scratching a developer's personal itch
2. Good programmers know what to write. Great ones know what to rewrite (and reuse)
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor
6. Treating your users as co-developers is your lest-hassle route to rapid code improvement and effective debugging
   
7. Release early. release often. And listen to your customers
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone
9. Smart data structures and dumb code works a lot better than the other way around
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong
13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to yo
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

If this makes sense then read the full book. If this doesnt make sense then you must read the book, Better still get some formal education in software engineering.

Resource Marshalling

20 People in 5 days. Thats the number of prospective new hires I spoke to this week - in person, telephonic.... Guess I was down on luck got to shortlist just a few of them. Found one thing common amongst all of them - lack of passion, They are here just to land their next job. There were Project Managers who were not aware of (and hence obviously did not practice) Requirements management, traceability; Design was limited to drawing a few rectangles and arrows in MS Word or Visio; Estimations and scheduling were based on prior experience (mystical I guess!) and not on Function Points; No reports to management, no phase ends, no schedule monitoring, no quality plans, no risk identification and hence no mitigation; no histograms, no pareto analysis, no formal defect prevention mechanisms other than probably yelling at the team!; and so NO LEARNINGS. Yet all of them draw fat salaries that would be the envy of neighbours and friends. WHY?

Now Reading

Its been a good week. Completed reading "Cathedral and the Bazaar" an essay by Eric Rayomond on software development more specifically on the methods. The "Cathedral" style followed by most software development organisations and the "Bazaar" style followed by a cohesive set of volunteers like the Linux Kernel Project, Mozilla, GNU Cash etc. He goes on to disprove a lot of conventions that we have as project managers on motivation, resource marshalling, schedule, budget and time, and proves very convincingly the superiority of "Bazaar" style development. Which in hindsight is true considering that most of us have a contempt for documentation and quality processes. But we still believe that the "Cathedral" style will provide that magic cure to all our software development ills. Such Shortsightedness. Well now on to another masterpiece