Win a copy of Transfer Learning for Natural Language Processing (MEAP) this week in the Artificial Intelligence and Machine Learning forum!

Hu Chong

+ Follow
since Jun 30, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Hu Chong

Originally posted by Stan James:
Organization by functional area might be better if each small team can drive a new feature from beginning to end with little interaction with other teams. This may be impractical if most new features require changes in common underlying modules. It is possible to design to minimize this kind of change (DIP and IOC are my favorite hammers) but it's probably not possible to completely eliminate it.

What are DIP and IOC?

In my current project, there are 2 kinds of team: common systems teams such as payment, form/letter printing, etc. and the domain teams which uses the common systems teams' components. The common systems are unaware of many new requirements because there are so many domain teams.

Is there a better organization structure to support such a large-scale project?

Originally posted by Ilja Preuss:

- dig out my copy of the book "Death March" and do the project without investing much of my soul and body into it, or
- simply refuse to do the project, possibly even quit.

You are right, most of the project members are doing either of the above.

Some have even gotten "creative" with their language. They will tell you their module can be integrated with yours. When you try using and it cannot run, they will tell you they didnt tell you it can run
[ March 28, 2005: Message edited by: Hu Chong ]

Originally posted by Stan James:

To the original question for 150 people I'd recommend The Mythical Man Month and any way you can find to turn this into 10 teams of 15 or 15 teams of 10.

Currently, the project team is divided into many teams of 6-10 members, with each working on their individual modules. However, communication is hard among teams, as each team lead is focused on their individual module. There are scenarios when a module needs to pass information to another module in order to complete a transaction.

The architect is completely overwhelmed with such a massive project.
[ March 28, 2005: Message edited by: Hu Chong ]
I know this is not a new problem and many times you will encounter this:

XXX promised the customer that the system can do YYYY and ZZZZ during requirements gathering. During implementation, XXX left and the new team lead got to deliver on the promised feature. The new team lead found that what has been promised is not feasible to implement. But he cannot tell the customer that. And the management is forcing him to deliver on the deadline. What will you have done if you were him?

Originally posted by Kishore Dandu:

4. Great communication & understanding(on technology approaches and execution) among project leaders & up in the hierarchy.

I have thought long on this issue of communication. Do you think using a team requirements gathering tool like Rational RequisitePro helps?

The way i see it, some people join in the project and got lost because the project is too large, some people left and take away their knowledge of the requirements. Although there were use case documentation and such, nothing beats attending the requirements meeting with the users.
[ March 27, 2005: Message edited by: Hu Chong ]
Use cases have been misused alot from my project experiences. In a particular project, use cases have to be accurate and document all possible screen flows (i.e. alternative flows). All error messages have to be identified too. As if that is not bad enough, the use cases have to comply to a certain glossary, and you could not use words that is not found inside.

My feel is that you should document enough for you to start some preliminary design and update them in iterations.
[ March 27, 2005: Message edited by: Hu Chong ]
I am currently working in a multi-million dollar project with the project team size of around 150+. There are many problems as with other IT projects
of a smaller size.

Care to share your experiences in projects of such size?

of executable acceptance tests instead of a 80 page use case document.

What are acceptance tests? you mean test cases?
At which stage of the project, should we come up with test cases? My experience is during development.
[ February 03, 2004: Message edited by: Hu Chong ]
From the software architect of my current project, he is saying that we should use ejb since there are clustering of the application servers. And, we only need to deploy the ejb once only.
But, I am thinking otherwise, since the ejbs are going to be accessed by only one applications and not many applications. We can just use a Front Controller servlet and struts actions. Just that anytime we have new changes, we have to deploy the war file to every application server.
How much information should a use case contain?
From my previous experience, a use case consists of many sub-flows. Each sub-flow answers the question of what the user do and what the system should do in return. Should the sub-flow also contain information on how the system is processing the information? One example is registration of new member. The sub-flow would be like.
1. User SELECTS register option.
2. System returns a registration screen with Name, Email, etc.
3. User ENTERS information and PRESS submit.
4. System processed information and return confirmation page.
For this sub-flow, there would be a data validation table for the screen elements (like what is the format and length) and a processing section containing things like how the email would be validated, etc.
Then, there are also alternative sub-flow for this sub-flow, like invalid email address, etc.
Is this too detailed? I have use case documentation of 80 over pages for just one use case.
[ January 30, 2004: Message edited by: Hu Chong ]
Thanks Michael, that was very useful.
Some more questions, what do you use to create the workflow diagrams? Do you have one big workflow diagram or a few of that? I am thinking one big one might be better for a very clear overall picture. Too many workflow diagrams might lead to an application which consists of many incoherent sub-systems.
From the workflow diagram, how do you decide to divide it up into use cases? I would think something like "Management of Membership records" as one use case, consisting of sub-flows like Create, Delete, Update and Search Member. Now, do i also include sub-flows like these in the workflow diagram?
Hi, I am new to gathering user requirements. Like to know how i go about doing this. What are the steps and questions to ask?
Hi, as i was looking at this topic on MDB, i like to know for what kind of situations can MDB be used effectively?
One example i can think is processing of book reservations in the library. The web application will send the request to the queue, which then is picked up by the MDB and processed it.
I also got the email, but might not be showing up, as the beta is running for 2 weeks only, starting from 11 Aug. Not much time to prepare if you are also working at same time.

Originally posted by Terry Wang:
got an email from omg saying i was selected for the beta exam, but i think i may not show up for it. after al, it's $80 even for the beta ones, and you have to take the steps from fundamental to advanced, which is $240 at least(could be $600). this set of certs just look too expensive for me (although i can get reimbursed from company, still, it's a lot). the only thing i like it is that it's not from vendors and may have a longer time to expire (until uml 3.0?)

Good Luck, Billy

Originally posted by Billy Tsai:
congratulations, i am taking the test tomorrow i hope i can pass