how would you prepare or start your project ?
hello
I would like to ask about the typical way you start a project ?
Im not asking about your personal way ?Im asking about a method .
here is what I have done ,could you pls correct me if I was wrong !!
*conference with the client to know his problem and demands
*drow on papers the graphical interface that he would like to have
*create the class diagram
I believe that I have a problem here
*I transfered the class diagram to ERD
*I generated the sql script to creat my database
*I converted the ERD diagram to java classes
I believe that this is the class diagram that had to be converted to java classes
*divide the program into 3 packages graphics , programme and database
classes in programme packege contains all the getters and setters of the objects
classes in the database packages contains the mehods that allow the objects to deal with the database
classe in graphics package contains all the panel and frame ..etc
any advice is welcome ,or if you dont have time just write down good link about managing project
thank you in advance
> *drow on papers the graphical interface that he would like to have
This is a pet peeve of mine. The longer you can avoid talking GUI, the better.
Clients, of course, think program == GUI. That's all they see so they think that's
all there is. This gets in the way of having them think about the real functionality
of the application.
Early on, I would stress writing down the use-cases (or "stories") and building a glossary or data dictionary, so that you can be clear about the domain's terminology. I've been on several projects where they didn't do enough work
on use-cases, like what happens when step X fails? "I don't know, we assumed no action would ever fail or need to be canceled". Sigh.
> > *drow on papers the graphical interface that he
> would like to have
>
> This is a pet peeve of mine. The longer you can avoid
> talking GUI, the better.
> Clients, of course, think program == GUI. That's all
> they see so they think that's
> all there is. This gets in the way of having them
> think about the real functionality
> of the application.
>
> Early on, I would stress writing down the use-cases
> (or "stories") and building a glossary or data
> dictionary, so that you can be clear about the
> domain's terminology. I've been on several projects
> where they didn't do enough work
> on use-cases, like what happens when step X fails? "I
> don't know, we assumed no action would ever fail or
> need to be canceled". Sigh.
My personal favorite was working on a project where we had a demo but the formulas giving calculations were wrong and the big concern was if we could change the color of the buttons and the background - it was a scary day indeed. All I can say is I'm happy it wasn't a financial institution.
*conference with the client to know his problem and demands
Repeat this step often. Customers will change their minds about requirements, it's a fact of life. When they do, you either have to a) change the project, or b) explain to them why they're wrong. Either way, the sooner you do it, the better off you are. There's nothing like waiting until you're a month away from launch to find out you have to completely redo large parts of the code.
I'm sure everyone has horror stories. I joined a project half-way through
when all the use cases were thought to be clear, so my job was implementing
them. At some point the client said "we are often interrupted in the middle of
a use case and asked to do a second case at the same time, and this
can occur more than once and a third, fourth, ... interruption may occur while
doing the second, third, ... interruption's use case. Oh, thanks for telling me now...
> *conference with the client to know his problem
> and demands
>
> Repeat this step often. Customers will change
> their minds about requirements, it's a fact of life.
I not even sure if it's change their mind, more like making them realize they have to think about all the possibilities, not just what would happen in the ideal world best case scenario.
> When they do, you either have to a) change the
> project, or b) explain to them why they're wrong.
> Either way, the sooner you do it, the better off you
> are. There's nothing like waiting until you're a
> month away from launch to find out you have to
> completely redo large parts of the code.
> not just what would happen in the ideal world best case scenario.
Exactly! Clients often think in terms of the ideal world. For example,
they say "at this point I enter this piece of information"... So I'd ask,
"what if you don't know it at that moment?" Can you omit it? Does that
change your operation procedure? Does this need to be flagged in
some way? Etc... And their reply more or less "we muddle though
somehow, as it is". I'm thinking of a project where working with the IT
people on the project effected how the client side reworked their
SOPs, and not just because of interaction with the app we were
developing, but because the analysis pointed out how pathetic their
day to day procedures were.
I do a little stretching before I go on the ice and try to get my muscles warmed up and then go to the crease for some serious stretching and try to get in front of a few pucks before the game starts.Oh wait that's a different topic alltogether.PS.
I would like to say "AMEN!" to all that was said so far.
I also just to get myself on track ask the most knowlegable user, or users on large projects, represented in the group to go over the process as they know it, then have an administrator most knowlegable go over the same thing.
Then I sit down and get resolution on the 2 wildly different stories. Don't be in a great hurry to get thinks carved in stone right off: the stories will change--THEY ALWAYS DO!
Once I have a handle on what is going on, and in some cases the user may have gotten an education at the same time, then I ask what they would like to change "give a perfect world".
Then give weights to tasks (feaures of their process), review the next meeting what I and my team understood from their comments in the previous. Negotiate and accept change request.
Do all of the previous steps unti we get a consitant story, then start on deliverables, such as; proposed GUI sketches, rough time lines, and etc.
When all is said and done--The user may not always be right, but they are the user. You may have given them the most magnificent work the world has ever known, but f they aren't happy, then what was the point?
> > *conference with the client to know his problem
> > and demands
> >
> > Repeat this step often. Customers will
> change
> > their minds about requirements, it's a fact of
> life.
>
> I not even sure if it's change their mind, more like
> making them realize they have to think about all the
> possibilities, not just what would happen in the
> ideal world best case scenario.
Right! I used "change their minds" because they're always convinced that they understand the problem completely and know exactly what they need, when they usually don't. Later they realize they were wrong (or just come up with extra things it should do) and then act like it's no big deal to ask for the changes. My point is that requirements gathering isn't something you just do at the start, but that you should do continually, hopefully to keep on top of the changes.
Here is a little tidbit from my very first consulting job:
I met with everyone got the stories resolved everything according to their process stories. I then looked a their processing forms and saw there wasn't any field for a unique identifier, such as ssn. Now this was a federally funded agency and I knew you cold not breath according to the feds unless you had an ssn, but everyone insisted that ssn wasn't used. I talked with the fiscal department and they just shook their head and said: "Give them what they ask for, they run their own program."
I ended up making a interface for their gui i developed and the ability to easily chain more pages of data into the project and showed thier programmmer how to do it when the "not used" ssn showed up and they wanted to enter it.
It wasn't a full week later and their programmer called me and told me: "The missing page of the data forms showed up today and they want to know how to enter the SSN."
I took him about an hour to do the recomended mod, I had shown him previously to get the new page in.
The user is the user, you try to not let them shoot themselves in the foot, but some just insist on doing it any way.
I worked somewhere where I was asked to implement a very unintuitive portion of the UI, whereby a series of obscure keystrokes and button-pushes would select all the documents in-view (it was a content management system). I instantly queried this, and asked "wouldn't it be simpler if there was just a check box at the top of that list of check boxes?". The reply was that that's what the customer had asked for, and it wasn't our place to question their decision. Nobody had even bothered talking to the customer about this. I left within a few weeks, partly because of this, and partly because of other horror stories I've used before. The moral is, though, it's your job to ensure the customer has made an informed decision about these things
ok thank you all , this give me alot pf help ,and infact ,I feel as all of you are working with me "in the same office " .you are just tell my story about the clients and how do they change their mind ,infact every time I meet the client ,he tell me new things about his needs
but may I go more in technical details ,would you transfer your class diagram to java classes or this is the erd diagram that has to be transform to the java classes ?
A piece of advice that may be obvious, but I think is extremely helpful anyway: Link your classes/methods to specific requirements. In your javadoc, document which requirement the method fulfills, along with all the other details. That way you can reference requirement 13.5 to make sure that it does it's job, and when 13.5 changes, you know where to go to make the change. It's also a good way to make sure you're only writing code that fulfills requirements. If you can't link it to at least one req, it probably shouldn't exist. You do have a formal reqs doc, right? ;)
> A piece of advice that may be obvious, but I think is
> extremely helpful anyway: Link your classes/methods
> to specific requirements. In your javadoc, document
> which requirement the method fulfills, along with all
> the other details. That way you can reference
> requirement 13.5 to make sure that it does it's job,
> and when 13.5 changes, you know where to go to make
> the change. It's also a good way to make sure you're
> only writing code that fulfills requirements. If you
> can't link it to at least one req, it probably
> shouldn't exist. You do have a formal reqs doc,
> right? ;)
Ok I see what you mean
thanks
Lord almighty haven't any of you had the luxury of a business analyst?!
If you are lucky enough to have one, then let the BA gather information from the clients and write up specification documents.
When you recieve the spec's then draw your class diagrams and write technical specifications with pseudo-code and models. Go back and revise your class diagrams as you see fit.
After this you can begin coding, and the BA will constantly keep in touch with the client for the life of the project and handle situations where the customer changes his mind.
In other words, Let the customer be the BA's client, and the BA be the developers client.
> Lord almighty haven't any of you had the luxury of a business analyst?!
The time I landed on a project where a business analyst was contracted
to do that was a nightmare. I wouldn't name the company the BA was
from, but it rhymes with Foo-shitz-uu. He produced reams of high-level
documents (with templates and a document generator). They were
all useless or out-of-date by the time I saw them, and being a contractor,
he was long gone. The management also refused to pay to get more work
done on the documents. They might as well have been filed in the circular
filing system.
Unless you are in my situation. In which case, the BA is a former client who does not take others needs into account, thinks others can not do the job as well as he, and sometimes has unrealistic expectations.
What is XP's view of BAs?
[url= http://news.bbc.co.uk/2/hi/technology/3682803.stm]BA does not like XP.[/url]
Why did they feel the need to show us this key?[url #" style="display: block; background-image: url(' http://newsimg.bbc.co.uk/media/images/40112000/jpg/_40112079_sasser-bbc203.jpg'); width: 203px; height: 152px] [/url]
Because it is the same color as Jos' tutus.
I'd never get away with that colour. Makes my skin look blotchy.
Most Canadians have splotchy skin. Look...[url #" style="display: block; background-image: url( ' http://www.cfpc.ca/cfp/2006/Sep/_images/vol52-sep-clinical-dermacase-gra1.png'); width: 433px; height: 303px] [/url]
Ugh. You made me look. I'd say that's a sensitivity to poutine.
psoriasis. Although the patient in question is from PQ.
Bloc Quebecois. Parce que on est differents
Plus a change, plus cest la mme chose.The leader of the Bloc is thinking of trying to be the leader of the PQ:[url #" style="display: block; background-image: url(' http://www.bowjamesbow.ca/images/duceppe.jpg'); width: 155px; height: 175px] [/url]
I woulda thunk you would have made some comment about the psoriasis lady being truly different.
Also, I think all good projects involving Business Analysts should start with the hiring of a hit man ;-)
> The leader of the Bloc is thinking of trying to be> the leader of the PQ:Two buttocks of the same bum.
