instead of giving you some topics imp points to save your project from some dangers they r as follows
Some of these dangers simply slow down the project, some are false trails, and still others can outright ruin any chance of success. However, all are avoidable with good preparation, knowledge about the journey ahead, and local guides who know the terrain.
This article is simple in structure; I will cover each hazard as follows:
Danger name: One-liner outlining the hazard
Project phase: The project phase where the hazard occurs
Project phase(s) affected: In a lot of cases, hazards can have a knock-on effect on later project phases
Symptoms: Symptoms associated with this hazard
Solution: Ways to avoid the hazard altogether and how to minimize its effects on your project
Notes: Points I wish to impart that relate to the hazard, but don't fit into the previous categories
As noted above, we'll examine each danger in the context of an enterprise Java project, along with its important phases. The project phases cover:
Vendor Selection: The process of picking the best possible mix of tools before you start your J2EE project -- from the application server right down to your brand of coffee.
Design: In between a rigorous waterfall methodology and an approach of "code it and see," lies my take on design: I do enough design so that I can move comfortably into development. I consider my design phase complete when I know exactly what I am building and how I will build it. Moreover, I use design templates to make sure I have asked all the right questions of myself and my proposed solution before moving into development. However, I'm not afraid to code in this phase; sometimes it's the only way to answer a question on say, performance or modularity.
Development: The project phase where the amount of work done in earlier phases will show. A good choice of tools coupled with a good design doesn't always mean a super-smooth development, but it sure helps!
Stabilization/Load Testing: In this phase, the system architect and project manager will impose a feature freeze and focus on build quality, as well as ensure that the system's vital statistics -- number of concurrent users, failover scenarios, and so on -- can be met. However, quality and performance should not be ignored until this phase. Indeed, you can't write poor-quality or slow code and leave it until stabilization to fix.
Live: This is not really a project phase, it's a date set in stone. This phase is all about preparation. It's where the ghosts of past mistakes will come back to haunt your project, from bad design and development to a poor choice of vendors.
visit this site for further guidance
goodluck
2006-09-21 00:59:15
·
answer #1
·
answered by Anonymous
·
0⤊
0⤋
Do something that uses web serives / soap .. as this is the hottest in industry now and it gives weightage in ur resume.
2006-09-21 10:20:46
·
answer #2
·
answered by AaRoN 2
·
0⤊
0⤋