J2EE Software Development Methodologies
This chapter is from the book
This chapter is from the book
This chapter is from the book
In This Chapter
(Not) Gaining a Competitive Edge in Internet Time
Why J2EE Projects Fail
The Top Ten Checklist for Initiating J2EE Projects
Organizational Frameworks for Supporting Enterprise J2EE Projects
Software Development Methodologies
J2EE Software Development Methodologies Unveiled
As stated by The Standish Group, a leader in gathering metrics on the IT industry
Approximately 40% of all IT software development projects are destined to be cancelled before their completion dates.
Approximately 30% will be heavily challenged by cost and time overruns, or changes in project scope.
Approximately $145 billion will be spent on cancelled or challenged projects.
The objective of software development projects is not to fail or become so challenged that failure is the only option. However, if they possess the "four C's" of project management, Complexity, Causes, Confusion, and Costs (James H. Johnson, chairman of The Standish Group), you can have a high confidence level that there will be problems.
At the root of all J2EE software development projects are two attributes that need to be effectively managed to promote success:
The Humanistic attribute—People, each with their own personalities and skills, play a vital role in sponsoring, managing, and conducting the activities within a project.
The Methodology attribute—A disciplined process is necessary to ensure that the J2EE software development effort is planned and executed in the most optimal manner, hence providing controlled and predictable results.
This chapter's objective is to provide you with a unique perspective on why J2EE projects either succeed or fail, through the application of software methodologies. An exhaustively detailed study of the current methodologies applied to deliver J2EE solutions is beyond the scope of this book. However, you will learn the origins and existing implementations of current methodologies, as well as a balanced view of the issues or concerns you will have to address by using them. Once you have armed yourself with this knowledge, you will be able to decide the most appropriate methodology that adapts to your J2EE project.
(Not) Gaining a Competitive Edge in Internet Time
Organizations are always striving to increase their bottom line and gain the prized competitive edge. However, due to the highly competitive pace of most industries and the subsequent ripple effects, the time available for most bottom-line–oriented decisions and solutions is decreasing exponentially. Some organizations today are trying to negate the scalability model; they want solutions with a reduced cycle-time and lower costs, while at the same time maintaining or improving quality.
Time has become a primary factor in implementing any kind of Java or J2EE solution, and for some reason six months or less has become the de facto standard to do so. Imagine you devise a J2EE solution to an persistent problem in your organization, and from your experience, you believe it may take six months to a year to implement. There is a good chance that the idea will be accepted on the premise it is implemented within six months.
At a very high level, J2EE projects typically begin with an investigation, exposing a qualified perspective of the tasks required and their respective timelines. You can be sure that these timelines will be reduced to meet either the anticipated management delivery deadlines or a budget (or both). At this point, the implementation time factor becomes a boundary within which the project must be delivered from soup-to-nuts, and its success hinges on what occurs within these bounds. Time-constrained projects have a very small margin for error because you cannot buy or extend time as you can with resources or technology. Time ticks in one direction—clockwise. Also, if a project takes too long, it increases its risk of failure due to fast-moving requirements, technology, and people.
Organizations will impose time and budgetary constraints on J2EE projects, causing them to make sacrifices wherever possible in order to achieve a competitive edge. Is this the reason why most J2EE projects
take longer, cost more, and deliver less?
linger at 90% complete?
experience productivity declines with escalated costs?
incur intense internal politics?
have their tasks and vision skewed?
deliver solutions with limited or the wrong functionality?
The answer is no, as stated earlier; IT projects do not naturally fail. The BEA WebLogic Server 7.0 and the J2EE framework are a very exciting combination for delivering unparalleled IT solutions, but their implementation alone does not guarantee a successful project. It is the complexity of the project's tasks (processes), the people within a project, and how they are managed that will inevitably prove the success or failure of a project. They all need to operate fluently together like well-oiled cogs.
NOTE
Since a process can relate to a task within the context of a project plan, the terms processes and project tasks are used synonymously in this context.
How the people and processes are selected in a J2EE project, and how they will interact, is a variable equation which needs to be formulated well before the project begins. Organizations wishing to gain a competitive edge using J2EE technology will have to develop this equation with enough foresight that it will output the correct results.
The following sections will assist you in understanding why J2EE projects fail, and what has to be in place for them to succeed. You will rapidly begin to develop a comprehension for the essentials required to derive an equation for a successful J2EE project.