System Analysis 101

My Presentation at Ain Shams career conference.

System Analysis 101

View more presentations from Muhammed Nabil.

Accelerate your requirements

Its not secret that time is villain in the IT industry. Project managers fear it, Clients waste it, and resources are suffering with it.

Sure you know that Time = Money, and in order to save your money and come up with a successful project you need to save your time.

Now how time is being affected??

• Its affected by uncontrolled scope.
• Its affected by ambiguous needs.
• and of course the number one time waster of all time - REWORK

In this post I'll introduce an old art, that was reborn again with the new dawn of agile.. its the "Model up front"

We sure know that an image wroth more than thousand word, but only if its a descriptive image. So when people agree on using model up front, sometime they get messy and start building Screens and hunt the low level of details ... so please HALT

And think what do we need -

• We need to finalize the scope with your customer
• We need to test our theories and assumptions
• We need to have a blueprint for the project
• We need to document the requirements for sign-off and contracting purpose.

How ..

Its the ultimate, don't leave home without, the guider of all .... "THE DOMAIN MODEL" a.k.a High level class digram.

http//en.wikipedia.org/wiki/Domain_model

The DM-Domain model is very handy to define the following:

• Identify business entities.
• Identify relation, and structure.
• Act as a road map for detailing the requirements later.
• A common language between Analyst and designers.
• Allow you to test your theories and identify if there is a missing entity some where.

Interested?? .. stay tuned for the next post about using 20% of the UML to do all the modeling

How i'll run my IT company !!

Okay. some one asked me in an interview, he was the GM of an IT company "if you are in my place what would you do", I told him " I'll lose some weight " :)


But after the interview kept thinking if were in his place what shall I do??


So here it is to everyone who will start an IT company or have an IT department this is my 10 commands of how to have the best IT company

1. You precious resource is the people invest in them , and they will invest in you
The time is people precious resource help them save it, they will save you

2. Under Estimation is Bad
Over Estimation is Good
Accurate estimation is Better


3. Personality & management :
A clever person solves a problem.A wise person avoids it.
-- Einstein

4. Problem solving:
The significant problems we face cannot be solved by the same level of thinking that created them.
-- Albert Einstein

5. Everybody Knows:
If you don't understand it, you can't program it.
If you didn't measure it, you didn't do it.

6. Scheduling:
Wexelblat's Scheduling Algorithm:
Choose two:
A. Good
B. Fast
C. Cheap

7.Deming's 14 points ;)

1.Create constancy of purpose.
2.Adopt the new philosophy.
3.Cease dependence on mass inspection to achieve quality.
4.Minimize total cost, not initial price of supplies.
5.Improve constantly the system of production and service.
6.Institute training on the job.
7.Institute leadership.
8.Drive out fear.
9.Break down barriers between departments.
10.Eliminate slogans, exhortations, and numerical targets.
11.Eliminate work standards (quotas) and management by objective.
12.Remove barriers that rob workers, engineers, and managers of their right to pride of 13.workmanship.
14.Institute a vigorous program of education and self-improvement.
15.Put everyone in the company to work to accomplish the transformation.


8. Acting technique:
On the radio the other night, Jimmy Connors said the best advice he ever got was from Bobby Riggs:
do it
do it right
do it right now

9. Acting technique 2:
It is not enough to do your best: you must know what to do, and THEN do your best.
-- W. Edwards Deming

10. If its to be its up to Me
--Mohamed Nabil

Why Analyst ?

This is an article wrote by me and published in our company magazine the graphics where created by Mostafa Murad .. the article is targeted to those who question the role of the analyst ..

Click to enlarge

UML the right tool .... Really !!

So i was talking to one of my friends and we were talking about BP "Business Process", and how does the analysis for a BP differ from other type of project. and he shocked me with his response that he model Business Processes with UML!!!

I: let me ask you one question, would you use a jackhammer to open a canned tuna? Him: No sure not.

I: Probably you are using a CASE tool right?
Him: Yes

I: What sort of diagram you gonna use?
Him: Activity Diagram for sure.

I: I guessed so, okay tell me Is UML a methodology ?
Him: I guess not.

I: Does Activity Diagram have a notation for processes fault handling and compensation, and data storage?
Him: hmmm i guess not.

I: Does Activity Diagram allow you to add sub-processes and define micro transactions?
Him: haaaa !!! No i Guess.

I: one last thing, does it allow you to express the 2 commit protocol of the transaction state?
Him: Okay it doesn't, what do you suggest?

I: first as an analyst you need to think out of the box, UML is not the only modeling notation in the world, plus its just a notation it doesn't tell you how to build you diagram, it just what is this diagram.

So whenever facing a situation when you need to model, think how I'm going to benefit from my model, or its just a one time thing, and will be thrown away after finished. i learned this after long hours of modeling and not using what i did.

And for the BPM, you need to learn BMP notation and BP analysis, as Business Process is a methodology more than just a notation you will need to learn when to commit and when to add handeler and how to calculate FLOW TIME, Throughput Rate.

By this we ended our conversation , in my next article i would talk aout UML and Scott Ambler ideas of its insufficiency

I'm an Analyst .... i use a Template

After seeing so many templates in different software houses all over the middle east, I though to share some realistic facts from my reading so analysts should wake up.. and lose the template

therefore I'm sharing the following quotes for Scott Ambler , Alistair Cockburn and Martin Fowler regarding what is exactly useful in documents and templates.

I summarized it for you in three separate points:

First , Adrenaline Junkies: He Talks about the book “adrenaline junkies and template zombies “ the junkies are the agilists and the zombies … you know :)

“ModernAnalyst.com: So, you’re saying if I just use a template, it’s not necessarily disciplined, right?

Scott Ambler: Yeah, exactly. There’s actually a really great book out right now, that I do want to suggest to your readers… The book is called “Adrenaline Junkies and Template Zombies.” It’s a collection of patterns and anti-patterns for IT. So, one of the anti-patterns is template zombies; those are people who just fill in templates and making sure it’s filled out. “does this sounds familiar” Whether or not it makes sense, just fill it out. Whether or not it’s even the right template, but I have a template, I’m going to fill it out. It’s just a novel waste of time. A lot of wastage in general…. It’s a really interesting book and one of the really neat things about it … they present these patterns and anti-patterns just as a collection of one or two pages in length. … I suspect it will end up being one of those instant classics that we’ll be referring to 20 years from now.”

Second: In another interview on itc.conversationsnetwork.com

“Based on his recent review of Alistair Cockburn's new book, "Agile Software Development", Ambler said (interestingly): "in this book Alistair tackle about 28 ways of communicating between software project members, and paper/documentation is considered the worst one among them!”

Third: In one of Scott Ambler Book's "Agile modeling:effective practice for eXtreme programming and Unified process " he mentions and i totally agree:

“A common refrain within the object community is that 80% of your object modeling needs can be satisfied with 20% of the notation”

Finally , I want you to check this article if you have time : Varying SDLC methodologies among development teams it will give you an idea why things go bad by using the same process all over again in every project

And my favorite proverb "If you not gonna use it, LOSE IT"

I would like to thanks Essam Badawi from Raya Corp for his support and contribution