In This Chapter
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.
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.
You always pass failure on your way to success.—Mickey Rooney, 1920
There are too many people involved in projects today who are decision makers, and have absolutely no clue about the consequences of their decisions. They will continue to make the same decisions until they begin to learn from their mistakes. In order to truly have an aptitude for developing successful J2EE projects, it is important to, at a minimum, recognize and learn from the characteristic traits of failing software development projects.
BEA WebLogic Server and J2EE projects are by their very nature not low-priced at all. Most of these projects, including the purchase of the technology tools, application server licenses, training, and the allocation of sufficient skilled resources, can cost a quarter of a million dollars just to get started.
With so much money at stake in a project, there are two options: Either deliver the J2EE solution in a usable fashion that will have a positive impact on the bottom line of the business, or terminate it as soon as the light at the end of the tunnel becomes fuzzy. The early detection of a failing project and its subsequent termination is a success of its own. Most money holders within the business community are aligning themselves to take the same perspective, since the implementation of a technical business solution with very poor foundations will typically cost the same as if it was done right from day one. However, at that time the definition of “right” is not known, only just that it does not exist.
The root causes for failed J2EE projects share the same symptoms as most failures in the general IT industry. The following is a comprehensive list and description of the most prominent reasons why J2EE projects fail, in no particular order of severity.
The executive sponsor, who could be one person or several senior-level people, is responsible for supporting the value and return on investment (ROI) the J2EE solution brings to the organization; half-baked ideas are easily recognized and sieved out by executive sponsors. Without human intervention from an executive sponsor, there is a guarantee that if problems arise with your project that warrant senior-level management involvement, it may face the guillotine block. Too many projects face this dilemma and hence can see their end prematurely.
The executive sponsor may also carry budgetary and funding responsibility; therefore, it is important for them not to lose sight of any growing costs—the costs should never exceed the business benefits or ROI.
A lack of involvement from users can affect a J2EE project in the following four ways:
Business needs may be met, but the user’s needs may not be met.
Users may be resistant to providing any feedback on developing the J2EE solution.
Users will not appreciate any change in their normal working practices.
Any usability concerns for the J2EE solution will not be properly addressed, causing the solution to behave and appear in a very unnatural way to the end users.
The ramifications for not including the end users to the degree that they feel they are a valuable part of the project can be huge, both technically and operationally for the J2EE solution.
If there is one way you do not want to start a J2EE project, this is it. Understanding what the project is going to deliver in complete clarity is essential. You do not want the project objectives to lend themselves to misinterpretation, as this will cause confusion among the project members as to what they should align their decisions and efforts toward accomplishing.
Not knowing exactly what the project is going to deliver will cause political problems in the project camp, since no one will really know whether what they are delivering is right or wrong. Frustration and low morale are the typical end results if this is not caught early, ideally before the project actually begins. After a project begins, completely re-vamping or skewing its initial mission can be a very expensive or even a vain effort.
If your J2EE project does not have a clearly defined, flexible, formal process for managing any form of change to its underlying requirements, changes will wreak havoc on the deadline and the overall budget of the project. Unless you set the expectation for each change request, you can be sure that both the project delivery date and costs will be exceeded.
Typically, sponsors, managers, and marketing groups involved in championing a J2EE project will want to please as many end users as possible. They will immediately say “yes” to end users, without considering whether their decision can have an adverse effect on the successful delivery of the J2EE solution.
Tip
When technology or business needs evolve beyond your project’s scope, you should seriously re-think the objective of the project.
For example, the U.S. Air Force has a rule that by the time 15 percent of the project time and/or budget is consumed, success or failure of the project can be predicted. If the project has maintained scope, is on time, and is within budget, there is a high confidence level the project will be a success. Otherwise, the project will be marked as not successful and immediately cancelled for re-evaluation. Only once the kinks have been worked out, will the project be reconsidered for a fresh restart.
When project managers are assigned to a project where they are not familiar with the technical terrain or complexity of the solution, they may try to apply a cookie-cutter approach to manage the project without requesting advice.
The project may then swing into a mode where there is not enough project planning and articulated decisions, causing
Poorly managed project changes
Unrealistic deadlines
One monolithic project effort, as opposed to smaller, more manageable work streams
Best practices and technical standards to be potentially ignored
It can also swing into the mode where every aspect of the project is micro-managed, causing progress to become very staggered and frustrating. Since the project manager may not be qualified to manage the project, the project manager will possibly make an effort to learn on the job.
Technical accountability has become a major concern in most organizations. Recently there have been signs that IT management will get involved in J2EE projects, but if they do not understand the technology, they will not be able to support the project. Instead, they will opt to step aside and watch.
It is the responsibility of IT management to institute standards and best practices throughout the organization. However, none will be created or sponsored if the IT management adopts a “watch and see” attitude. Hence, large organizations will not learn from their J2EE project failures or successes; no guidance will be provided to J2EE projects. The technical decisions and success of a J2EE project in this scenario depends heavily on the skills of the technical regiment in the project.
Too many J2EE projects are initiated without a skills analysis of the technical team. All J2EE projects require people who are at least well versed with the Object Modeling and Object-Oriented programming techniques, but sometimes that requirement is not met. This can lead to severe impacts at each level of the project team; for example
Project leaders may have no experience with developing object-oriented solutions, and therefore have no comprehension of the processes that need to occur to even deliver a J2EE solution. They typically learn on the job after struggling in a round-robin style. In the meantime, their project schedules will be skewed to reflect a traditional approach to delivering a software project—the Waterfall Method.
Business analysts capture the project requirements using the traditional methods of data and process modeling, hoping that everything will come together to form an object at some point in the project.
Technical architects try to develop high-level views of the desired J2EE solution, leaving many technical voids to be filled in later as they learn the technology.
Development programmers try to program in Java, working 24/7 to learn the language, and even after the training, they still might deliver a procedural system.
Ideally, it is important to have people who are Java and J2EE literate on the project. However, if the project members do not have the direct skill, they can gain it very easily through training if they possess a firm understanding of object-oriented concepts. You can also augment your project team with experienced consultants to gain a kick-start to the technical efforts.
As projects become more complex and warrant quick time-to-market solutions, a new breed of developer will need to emerge who will posses the following skills:
While you are immersed in a project, it can be sometimes quite difficult to see or feel that your project is headed for failure. You will probably know the reason for your project’s failure or termination when it is too late, at which time it will seem obvious.
However, there are some signs you can look for that will provide a gauge as to how well the project is performing. If you do notice them, you can quickly address them and prevent any potential problems from settling in too long to make themselves at home.
Regardless of the duration of a J2EE project, there has to be a metric to measure the progress of the project. This comes in the form of a set of agreed-upon milestones. If the milestones are not met in a consistent manner, this does not build a high confidence level that the project delivery date or budget will be met.
Communication builds synergy and aligns the team members to converse on the same frequency. In addition, it synchronizes everyone’s knowledge on the state and flow of the project.
However, there may be times when a team member, for whatever reason, becomes discordant with the project. This is the true test of how well the communication mechanism has been implemented within a project. If the project member cannot find a natural or straightforward way to realign the project, a gap is created between the project team’s forward momentum and the static state of that team member. Such a gap can be easily detected when
Multiple team members are conversing about the same thing and not recognizing they are.
A common objective is perceived differently among the team members.
A team member does not understand what the state of the project is.
A team member does not understand the reasons for certain decisions.
A team member loses focus on the actual needs of the customer.
If a decision must be made which requires a meeting and a consensus among several people, you have a bottleneck in the decision-making process within your project. This approach is typically taken when people want to feel involved or in control within a project. They may not necessarily have the skills to articulate an educated decision, but just being part of the decision process is a comfortable feeling and provides recognition of their involvement.
Problems like this exist in projects where
There is a lack of team spirit, and one or more people want to ensure they are individually credited for their efforts.
There is a lack of trust within the actual decision makers.
With Java becoming a de facto language for implementing scalable and interoperable solutions, the J2EE framework is becoming the backbone for most mission-critical systems that possess a Web-based user interface, such as corporate portals, knowledge management, e-commerce, and supply chain management systems. Since more than half of all mission-critical projects fail to deliver their expected benefits, and the J2EE framework is beginning its journey to a more customer-oriented focus, the stakes to ensure success are high. In general, even though most IT projects fail due to management-related issues as opposed to technical problems, every aspect of a failed project, including the employed technology, somehow becomes tainted with a negative shroud.
In spite of this, the employment of a simple project assessment checklist will ensure that most J2EE projects that have the potential to fail are either saved or terminated before they begin. The following list is a well-observed and industry-accepted IT project checklist, which you can use to check the health of your J2EE project before it actually begins. Every J2EE project must have
Executive Sponsorship
Every J2EE project of mission-critical nature must have a nominated executive sponsor or project champion, who is aligned with the mission of the project and has a significant stake in the success of the business. The sponsor should be immediately responsible for executive decisions that directly affect the delivery of the project; for example, maintaining focus on why the project is being done in the first place. The sponsor must also be able to cultivate adequate funding and dedicated resources from the organization.
A Business Case
In essence, all J2EE projects are business projects; they all need a business motivation to exist. J2EE projects must be conceived and implemented with a constant eye towards how they will affect the organization’s bottom line. Most business cases must include
A Steering Committee
The steering committee is typically a group of people who are the stakeholders of the project. They are the ones that actually release funds and make decisions to either continue or pull the plug on the project.
A Core Project Team
A core project team needs to be created, representing both the business and IT worlds. The members, including a qualified project manager, should be identified with an estimate of the time and duration of their involvement.
Before the project manager is assigned, he must be able to demonstrate a successful record of accomplishment on comparable projects, as the project manager is the lead resource on the core project team.
Tip
If you have a $10 million project, don’t put it in the hands of someone who has never managed a $50,000 project.
Many enterprises have no formal processes for evaluating the skills of their project managers and the respective training they have or need to receive. Also, mechanisms are lacking to enable project managers to share their success or failure attributes with other project managers. Some people are gifted with project management skills. However, when these skills are lacking, training or pursuing a project management certification from the Project Management Institute is the best place to start. For more information on the Project Management Institute, please visit www.pmi.org.
An Industry-Proven Software Development Methodology
There has to be a proven systematic and holistic approach to the overall process of analyzing, designing, and constructing high-quality J2EE components for maximum reuse potential. Such an approach must include processes throughout the project to ensure that components meet their business requirements and are quality-assured.
An Effective Project Plan
It is the responsibility of the project manager to develop a project plan that details the first phase of the project, with possible outlines to subsequent phases. This initial plan must adhere to the methodology selected to develop the J2EE solution.
Project management activities should include the following:
Define the requirements for the project
Plan, measure, and assess the project lifecycle
Budget and manage costs
Estimate and allocate project staff appropriately
Ensure a mechanism for fluent inter-project communication
Negotiate and manage external resource contracts
Assess and manage risks weekly, with an emphasis on project size, business requirements, skills, and technologies
Manage scope through change management
Motivate team members
Project reports that focus on what milestones have been achieved and which still remain
Requirements Definitions
There needs to be a defined approach to collecting and specifying requirements that embraces the selected software development methodology. The requirements must be clear and focused on meeting the business objective of the project, and not render themselves to misinterpretation.
The processes will need to be formally established to manage changes to the project team personnel, any additional features that may be required, and functionality requests. Properly established processes will prevent any risks to the delivery date or the budget.
Phased Delivery
In order to illustrate measurable benefits within a short time frame, the project must be broken down into manageable value-driven milestones. The duration between each milestone will be driven by how quickly the target business objective is prone to change.
Skills Assessment
The role of the project manager is to develop a skills gap analysis based upon the skills required for the success of the project, as compared to the project resources available.
This exercise will clearly indicate how qualified the project resources are, how much training is required, and how many experienced consultants will be needed to augment the project.
Project Motivation and Incentives
It is extremely important to ensure that everyone involved in a J2EE project is equally motivated toward delivering a successful solution. Hence, it is essential to ensure there is an appropriate reward mechanism in place that will inspire and provide continuous motivation to the project team members.
Note
It is becoming very noticeable in most organizations that technical people of similar skills, and who work at a similar pace, are being grouped together to form task teams. This approach allows people who are properly motivated to either work together on critical aspects of the project to ensure delivery, or to augment groups where motivation, inspiration, or just a helping hand is required to ensure delivery of a specific milestone.
Within organizations, there will always be elements related to software development that will remain constant, regardless of the technology and programming languages employed to construct the information systems. Being able to recognize and fine-tune these elements, so they can be applied toward software development efforts, can provide the following long-term benefits:
Projects can leverage proven best practices.
Projects can be delivered with a greater degree of confidence, reducing risk and costs.
Risks involved in a project can be mitigated by employing accepted shared practices.
Technical competencies and skills can be developed through practicing consistent approaches.
However, most organizations fail to recognize these benefits. It is essential for organizations to possess internal communication mechanisms that can easily cross-fertilize information and promote best and worst practices across the spectrum of active IT projects. Two organizational frameworks that have proved invaluable in the support for enterprise J2EE software development efforts are Communities of Practices and Technical Centers of Excellence for J2EE Architecture.
Communities of Practice is a term used to define a forum of people, who can be extended across an organization, who share a common interest. Communities can exist for multiple topic areas, just like public user groups; the only difference being that their existence must contribute in some manner to the success of the organization.
In most organizations, J2EE solutions need to swiftly proceed from concept to prototype to production, and continue to evolve even after they are deployed. As a result, Communities of Practice need to be involved in developing the most practical, flexible, and efficient approaches for the J2EE software development efforts, especially in the areas that require business analysis, such as project inception and requirements gathering. Communities of Practice will derive best practices and techniques for assisting J2EE software development projects in a manner that will be supported and governed by the culture of an organization.
Communities can be technical and non-technical in nature. What is important is that they understand how they can contribute to the success of J2EE software solutions.
This community represents the advocates for the end users within an organization, and primarily supports the Requirements and Analysis phases of a J2EE software development methodology. End users, just by the nature of their roles in an organization, do not typically have insight to how information systems are developed. Hence, they will not understand the activities or processes they will be involved in, or the implications of documenting or changing business processes.
This aspect of their interactions with IT projects always consumes their concentration over providing valuable information and knowledge to the business analysts. However, they are the primary information resources for nearly all IT projects.
Business analysts need to apply an investment in educating end-user communities on the Requirements and Analysis phases to ensure they understand the informational value they posses and how they can effectively articulate that information.
Such communities require sponsorship and need to be championed by a well-recognized and respected member of the end-user community. A strong marketing effort is also required to promote its existence, since there is no point in building a Community of Practice if no one knows it exists. It is extremely important for them to gain exposure and be utilized by the organization.
Technical communities are more prevalent than the non-technical end-user communities within an organization, and are usually composed of representatives from an organization’s technical workforce—technical architects, software developers, and testers.
These communities generally exist for technology platforms, development languages, and their respective integrated development environments. Hence, technical communities have established themselves as developing the suite of technology criteria for the deployment of successful information management systems within an organization.
Examples of the concentration of such communities include
Programming languages (Java, C++, and Visual Basic)
Databases (Oracle, Sybase, DB2, and SQL Server)
Technical vendors (Oracle, BEA, Microsoft, and IBM)
There should always be an entity that sets the technical directions and standards within the organization, but the technical community should not be that entity. The mission of technical communities is to develop how those technologies can best be applied or practiced, not by theory, white papers, or technical paraphernalia, but through actual hands-on experience.
By creating and sponsoring technical communities, organizations will over time develop consistent approaches to software development that will possess a high degree of quality and success.
A Center of Excellence is a formalized group of people who are focused on a specific technology or software platform which their organization utilizes in its software development efforts. Their roles are to be experts, practitioners, and mentors on the technology domains they represent. This group must also wear the business hat to continually monitor business drivers that affect them, as well as the areas within an organization that could potentially be affected by the technology they represent.
If your organization is going to transition its software development platform to one that employs the J2EE architecture, there will be an expectation, after the completion of the first few J2EE projects, that subsequent J2EE project efforts become more efficient through the reduction of time, cost, and risk. With major updates occurring to the J2EE architecture almost every six months, a Center of Excellence is the means to realize those goals.
The J2EE Architecture team must collectively define how they are going to publish their information and knowledge to the organization, to ensure that the J2EE value proposition is comprehendible. Hence, they will need to represent technical ideas and the business implications of J2EE solutions, without needing to explain the intricate underlying technology. Business leaders view technical architecture as a winning gamble—an investment today with the optimism it will reap huge benefits in the future.
Note
The J2EE Architecture team must learn to talk in relation to user implications, as all technical choices should ultimately be linked back to business strategies and drivers.
The work that the J2EE Architecture team conducts should be in a level of detail that can be achieved within a set timeframe, typically no longer than the duration of the next release of the J2EE specifications. The longer they take to establish compliance on how J2EE solutions should be implemented, the less productive their mission and existence becomes. The litmus test for how successful an organization is with a J2EE Architecture team can easily be measured by the number of projects that adopt J2EE as the platform for the solution and have a successful deployment.
The biggest payoff of having a J2EE Center of Excellence within your organization is the ability for their members to get involved with J2EE projects right from the beginning, and ensure that a J2EE solution is valid and best suited for the solution domain. At a minimum, it should provide the appropriate technology guidance.
However, the biggest mistake that IT projects make in selecting a platform for their solution architecture is they see both the Requirements and Analysis phases of a software development lifecycle as the building blocks for producing the overall design of the system.
In reality, the role of the Requirements phase is to identify the functionality of the system, not how the functionality will be implemented. The Analysis phase, on the other hand, provides essential information contributing toward an understanding of the solution domain, and not what the solution system will look like—that is the role of the Design phase.
It is also important to note that an IT solution’s architecture should not be confused with its design. The focus of the architecture is on how the system will be deployed, and not its granular implementation details. The architecture of a system should capture the elements of design, which provide a clear vision and guidance for the overall design of the system.
The J2EE Architecture Center of Excellence should ensure that when they get involved in projects, the due diligence for the technology solution does not take a J2EE bias. If J2EE is selected as the appropriate platform, they should provide an architectural blueprint for the following:
How the J2EE services can be implemented
How existing organizational J2EE business components, such as EJBs, JavaServer Pages, and Servlets, can be reused
How the system can evolve and scale over time, resisting any stress placed upon it by the business
How and who to hire for project augmentation
How newly created J2EE business components can be harvested into a central component library
Another area where the J2EE Center of Excellence will be very valuable is in systems integration. J2EE is a relatively new technology platform for most organizations. Although much of an organization’s data will have been collected by existing applications, the value will not be in the replacement of these existing systems, but in how they can be interfaced into new J2EE solutions, hence commoditizing their value.
The term methodology is one of those terms that can mean different things to many people. In the context of developing software, however, there should be one simple interpretation—“A Methodology provides a methodical roadmap, framework, or guidance for developing software solutions derived from business needs.”
The term Software Development Lifecycle (SDLC) sometimes gets confused with a methodology. The two terms are interrelated, but have different implications. A Software Development Lifecycle describes a defined set of phases or events that occur in the development of software solutions, as illustrated in Figure 2.1.
A methodology, as illustrated in Figure 2.2, encapsulates an SDLC, and describes a general philosophy for developing the software solution, as well as what is expected from each of its phases in terms of inputs, outputs, and the respective coordination of any activities.
Figure 2.2. The methodology with respect to a SDLC describes a general philosophy for developing a software solution.
Methodologies are not technology-bound, and in essence, they cannot afford to be. Methodologies are engineered to be open frameworks that can apply to a variety of business and technical challenges. However, with the explosion of Web-based n-tiered applications, as represented by the BEA WebLogic Server 7.0 united with the J2EE platform, methodologies have become driven by the following three factors:
Features or functionality of your system solution
Web-based interface
Architecture that will be used in the construction of your system solution
These methodology drivers will be discussed in more detail in the “Selecting a Software Development Methodology” section of this chapter. In the meantime, it is important for you to begin to relate to these factors, as this chapter systematically describes the development process of J2EE solutions.
The methodology spectrum can range from pure philosophies, or best practices on what is needed in each phase of the SDLC, to a fully specified roadmap, providing complete guidance on the whys, whats, and hows of developing software solutions.
There is no rule or guiding authority that specifies you have to use a particular methodology. However, working without rules or guidance can be a costly exercise. The merits of using existing methodologies generally include the following:
Proven and successful methodologies are available to be used, and thus you do not need to reinvent the wheel
Optimism that the requirements of the solutions have been captured correctly
Reduced risk and errors in the development and deployment of the software solution
Improved documentation and communication during the SDLC
Easier project management
Straightforward maintenance and upgrade of the deployed (production) software
However, the true realization of benefits depends on the methodology you have selected, and how it is implemented and executed within your organization.
There is no doubt that J2EE solutions are being developed through a catalog of methodologies, each providing a unique approach. However, if you take a closer look at the methodologies at a very high level, there are certain core activities or phases that span them all; the only disparity is that they are fine-tuned or enhanced in their exact implementation and how they are practiced.
Methodology types have evolved from the early Structured Systems and Analysis type methodologies to Object-Oriented type methodologies, which are more gauged to develop object- and component-based software. Structured methodologies do not support the concept of looking at the real world in terms of objects. Object-Oriented type methodologies are more appropriate for developing J2EE solutions.
An Object-Oriented (OO) methodology is in essence a strategy for observing the business world as a suite of objects (for example: people, desks, pens, computers), and deriving an object-oriented software system from it. This is accomplished by mapping real-world objects to software business objects, which are written in an object-oriented programming language such as Java, C++, and now C#.
The primary difference between Structured and OO methodologies is in their underlying concepts. Instead of defining systems as two disparate parts—data and functionality—OO methodologies require systems to be defined as a collection of interacting objects. These objects possess characteristics (data) and behavior (functionality), which are mapped from the real world to Java classes or J2EE objects, such as EJBs and Beans.
The methodology you use to construct your J2EE system needs to be addressed very early on, before the project begins, as it affects every aspect of your system development effort. Depending on the culture and skill sets of your project staff, either you can embrace a complete OO approach, including the tools you use, or you can embrace a mixed-bag approach using structured approaches for certain phases of the SDLC; for example, for the Requirements phase. Even though a complete OO approach is favored and more conducive toward J2EE systems development, a decision will need to be made on which approach will yield a more successful return for your project, and not what the industry beckons.
Caution
Best practices are not always the most practical practices if they do not provide any benefits to your organization or are too challenging to implement, thus causing resistance to their use.
The following sections illustrate a few influential points you should consider if you are in the position to decide whether you should use the OO or mixed bag approach.
One of the axioms of systems development is that a solution should closely resemble the original problem. The only way to do this is if you observe your problem domain in its natural state, which is in terms of objects interacting with each other.
If you take this natural perspective, you will better understand your requirements, and more importantly be able to easily refer back to your problem domain to validate the Analysis and Design phases of the SDLC.
There is no better way to understand the object-oriented paradigm than to be involved in a project that encourages and practices it. Software developers and architects who are already familiar with one of the OO programming languages will be familiar with the concepts. If you are a project manager or business analyst, there are plenty of books that discuss OO concepts and even provide case studies, but the true test is if you live the experience, because things are never what they seem.
For those who are new to OO, the following are key OO areas that will assist you to further understand the OO paradigm.
The “black box” concept means that implementation details of objects and components are hidden from their consumers. This concept is formally known as information hiding and is a key element in OO thinking.
You should not worry if you do not understand how an object or component is implemented in your J2EE solution. The main emphasis should be that you understand its purpose: What functionally does it provide and what data does it possess?
Objects and components are seen as black boxes because they are designed with the concepts of abstraction, encapsulation, and concurrency.
Abstraction is the process of suppressing or ignoring inessential details, while at the same time putting focus on the more important or essential details.
Abstraction is typically spoken of in terms of levels, the higher levels addressing why the object exists, and the lower levels leaning more to how it is implemented. There are many types of abstraction, but in terms of objects, the following are important:
Functional abstraction, which deals with hiding the functionality within an object, while only exposing the interfaces on how you can interact with it.
Data abstraction, which hides the details on how an object’s functions and data are implemented.
Process abstraction, which manages internal processing of operations.
Encapsulation is the process of logically or physically wrapping together functionality and data that pertains to a unit, business need, or concept into a class or component; that is, information hiding.
This concept acts as a software wall or protector, allowing interaction only via specified interfaces; the internals being hidden. Hence, if a change needs to be made to the data or functionality within a class or component, it can take place without cascading changes to the other parts of the system that interact with it.
The biggest difference between OO and procedural systems is how they manage concurrency—the capability to process an operation.
Non-OO systems will tend to create a broker object or central routine that will take the responsibility of managing how other aspects of the system receive processing requests. OO systems, on the other hand, will tend to leave this process management to the object itself or the environment that object exists within. For example, in the case of EJBs, concurrency is managed by the EJB container.
Reusability does not only apply to the concepts of class inheritance or component reuse, which without a doubt are the primary beneficiaries in an OO software development effort. Since OO approaches focus on delivering OO systems without a bias on the implementation language, the whole software development lifecycle and the artifacts can be reused on other projects.
OO systems, such as in the case of J2EE, are not designed to be monolithic self-satisfying systems. OO methodologies promote systems to be loosely coupled, but very cohesively designed. Even though J2EE systems can be dispersed throughout an organization regardless of the location (for example, hosted on WebLogic Servers), as interoperability increases, the concept of a network and any system interconnections slowly begin to disappear.
When you are developing a system, requirements play a key role in every aspect, from the development through to deployment efforts. By reviewing the deployed system, it can become be very difficult to reverse-engineer a production feature to its root source.
The term traceability defines the degree of ease with which a concept, idea, or feature item may be traced from one point in a SDLC to either a succeeding or a preceding point in the same SDLC. For example, you may want to verify how a specific requirement actually becomes implemented, or trace how a feature actually was implemented in the production release of your software.
OO software development is a very illustrative process, as opposed being textual. Depending on the OO methodology you select, you will need to develop models to illustrate the real world as it exists, how you want the real world to behave in the software solution, and lastly, how the solution will translate to object-oriented source code in Java using the J2EE architecture.
Object blindness is a technical term for those involved in OO software projects who fail to recognize the concept of an object, and thus are not able to think in the OO paradigm. The failure again arises from lack of either exposure to OO-type projects or technical education.
In the past, universities and other educational institutes had been slow to introduce OO into their curriculum. Also, OO software projects were less frequently initiated by organizations. For these reasons, there are many people in the computing industry with object blindness. This is slowly changing with better educational curriculums and the speed at which Java and Web-based applications are being developed with Java and J2EE architectures.
Object blindness has contributed toward the poor adoption of OO methodologies in the past. However, today object blindness is one of the many reasons that explain the challenges that OO methodologies must overcome, which are discussed in the following touchpoints:
The software development tools used within OO projects are still centered on structured methodologies—data and functionality (process). The solution is simple: If you are going to develop objects, use tools that are object-oriented. The benefit is huge.
Mixed methodologies do not provide a consistent OO perspective to the J2EE software development effort. For example, if you execute the Analysis and Design phases in a structured manner, your software developers will use the Java language and the J2EE architectures poorly. Thus, they will render a system that is not scalable, suffers from performance bottlenecks, and which may not even behave in an OO manner.
There is a stigma that OO methodologies will add complexities to an already challenging project. Such perception typically originates from a lack of understanding of OO techniques, and can hence close any opportunities for using OO methodologies.
With J2EE projects typically having a fast time-to-market stigma around them, not enough investment is being made to prepare for J2EE projects. With lack of training and know-how, J2EE projects will take considerably longer than originally anticipated.
Most J2EE projects are composed of a small number of developers who prefer informal development approaches that they have been exposed to in their past experiences. Hence, any formal methodology that requires documentation is considered overhead.
Project staff who are in the process of developing J2EE systems for the first time tend to apply methodologies composed of unrelated technologies that have worked for them in previous projects. As a result, the only way for them to realize that an OO methodology is required is by experiencing failure and learning from it.
Many Java developers do not understand the J2EE architecture, and thus it is inappropriately used and implemented.
Business analysts do not understand the OO modeling technique using the Unified Modeling Language (UML), which does have a learning curve. Consequently, the design of the system may be good, but it will fit a poorly analyzed system.
Note
▸ UML will be discussed in detail in Chapter 3, “A Developer’s Guide to the Unified Modeling Language (UML).”
The benefits or Return of Investment (ROI) from using an OO methodology is not apparent immediately, as expected by most organizations. Object reuse typically becomes an attractive proposition after a few J2EE projects have been implemented.
It is true that Waterfall and Object-Oriented type methodologies are being used to develop J2EE solutions in organizations today. Some organizations may even place a wrapper around the waterfall methodology, by renaming it or adding some overlap in some of the phases. However, in essence, it remains a waterfall methodology and it is still prone to the failures associated with it when developing J2EE solutions.
In order to understand object-oriented methodologies, this section will also discuss the Waterfall Methodology and the associated reasons as to why you should not use it to develop J2EE solutions.
The traditional Waterfall Methodology is an early software development methodology created by Dr. Winston Royce, who described the methodical and sequential phases for developing software solutions. As you can see in Figure 2.3, this methodology resembles a waterfall for one main reason—each phase must be complete by a specified date before entering into the next. With the forces of gravity acting on each of the phases, the Waterfall methodology in practice does not encourage revisiting any previous phase once it is deemed complete.
Figure 2.3. The traditional Waterfall Methodology does not encourage the revisiting of any phase once it has been passed through.
The Waterfall Methodology suffers from two major problems that can cause the quality and schedules related to software development to be adversely affected:
There are no feedback mechanisms between each phase.
There are completion dates imposed on each phase of the software development lifecycle.
Each of these failures will be discussed in the following sections.
The most important phases of a software development lifecycle, where you develop the building blocks of your system, are the Requirements, Analysis, and Design phases. Since there are no feedback mechanisms between the phases, Requirements must be complete before Analysis can begin, which will need to be completed before Design can begin, which will need to be completed before Development can begin, and so on.
So why does this methodology fail? It is because these activities cannot be measured complete purely by a scheduled end date; an organization itself, as well as its needs, change over time. Since this type of methodology was not engineered to have a short lifecycle, there is no way to feed in any changes to the software development effort that will be needed to deliver a successful information system.
Even though the software is delivered, the duration it takes from inception to final delivery is huge. Typically, by the time a system is deployed it will not fully meet the needs of its initial customers, since
The customer needs may have changed over time, which is known as requirements drift.
The system does not function in a manner that truly represents the real-world flow of business operations.
The system is not intuitive to use, thus facing resistance to its adoption.
When following the Waterfall methodology, project managers tend to impose end dates to the Requirements, Analysis, Design, and Development phases. This is an unfavorable situation because the phases are tightly coupled processes during the development of object- and component-based systems.
Practicing a linear model does not encourage creativity or flair to add value to the underlying system being built among the project staff. Business analysts, architects, and developers need the freedom to discover and rediscover what they are building through continuously revisiting their dependent phases. Establishing sequential end dates will cause these phases to be executed independently of each other. Such projects, also known as stove-piped projects, have one common failure within them: They always deliver a dysfunctional or out-of-date system from the perspective of the customer.
It has been stated many times that developing software is an art, and in some ways it is—you can look at it from varying angles and perspectives, and you will see a hologram of methodologies that can be used to implement a solution. However, if you sift through the complexities presented by the hologram, you will see that there is a core suite of activities or phases that are common to many of the methodologies, which can be applied toward developing J2EE solutions. These core phases are illustrated in Figure 2.4.
Figure 2.4. The core phases of a J2EE software development effort are common to most of the methodologies that can be applied toward J2EE development.
They are
The Project Initiation or Feasibility Phase
Is a pre-project, due diligence exercise to verify the validity of a J2EE software development effort. This is accomplished through the discovery of high level requirements, technical and operational complexities, risks, costs, and lastly a proposed project plan. The Project Initiation phase defines the value proposition for the J2EE solution.
The Requirements Phase
Is an iterative exercise that captures the needs of the stakeholders and end users, as well as capturing a clear definition of the problem domain and scope.
Tip
The requirements must be captured in a format that the stakeholders and end users can relate to. The format will dictate the business vocabulary and the depth of the presented information. Hence multiple formats will be needed to address the varied audiences required to be involved in the gathering of requirements.
The Analysis Phase
Is an iterative exercise with the Requirements phase, where business analysts develop an understanding of the problem domain and scope, and then begin to conceptually develop a solution.
The Design Phase
Is an interactive exercise with the Analysis phase, where architects and developers begin to develop a technical and conceptual solution based on the results of the Analysis phase.
The Development or Construction Phase
Is an iterative exercise with the Design phase, where developers begin to program and develop J2EE objects and services, using the software design proposed in the Design phase.
The Testing Phase
Is an iterative exercise with the Development phase, where each logical unit of code (EJB, Servlet, JSP, or Bean) is tested. Upon successful testing, it is deployed for integration testing with other aspects of the system, which have also completed unit testing.
The Implementation or Production Phase
The final phase of the software development effort is to deploy the J2EE solution into a production-ready BEA WebLogic Server. A final production test is required to ensure that all J2EE objects and services are working as expected and interactions with any external (legacy) systems and databases are operational.
The whole purpose of following a software development methodology is so you have a methodical set of process or tasks that, if followed correctly, will deliver the system solution you and your end users coherently envisioned. By understanding these phases in the context of a methodology, and the activities they entail, you will be well informed to validate whether your organization can successfully embrace it to develop your J2EE solutions.
There are plenty of software development methodologies available; each one being unique in the way it performs the core phases of a SDLC. The methodology that you decide to adopt should be well-documented and supported in order to act as a guide when in you are in doubt. It is important to review the origin of the methodology, since it can be developed in-house by large consulting companies, fostered by consultants/authors, or crafted by software product companies. Based on the origin, you will quickly understand all the support infrastructures available for that methodology. You will also be able to evaluate whether there is a cost factor involved for using a specific methodology or obtaining any support.
Another important factor for selecting a methodology is whether it supports the type of system you intend to build. Since this book is focused on the BEA WebLogic Server, there is a high probability that you will be developing a Web-centric system. As a result, not only will you be dealing with a project staff quite different from the kind of project staff involved in most software engineering endeavors (graphic designers and HTML developers, and so on), you will also need to include a usability study throughout the SDLC.
At a high level there are two types of methodologies—Predictive (Heavyweight) and Agile (Lightweight).
Predictive methodologies, also known as heavyweights due to the sheer overhead that comes with using them, such as the Rational Unified Process (RUP), are full lifecycle methodologies which posses the following attributes:
They are tools-based, which means that a modeling tool is required to support the adoption of the methodology. As in the case of RUP, you can use either TogetherSoft’s Control Center 5.5 product or Rational Rose 2001.
The methodologies are extremely well documented for the phases of a software development lifecycle.
They are either process- or architecture-driven.
The methodologies are template-driven, which means that document templates guide the use of the methodology. All you have to do is execute according to the guidelines, and fill in the blanks of the template. Hence, the project will produce a large set of documentation, all of which will need to be read, signed off, and managed.
Tip
Rational Rose 2001 has a plug-in template for developing BEA WebLogic applications. You can download it from Rational’s Web site—www.rational.com. However, since it is a Rational product, it ultimately implies that you will use the Rational Unified Process.
They encourage knowledge collaboration within the project team, using a common vocabulary.
They are flexible and modular in nature, suiting small- to large-scale projects.
They are developed and supported by software houses.
The software development methodology will need to be purchased at a cost.
Agile methodologies, such as BEA Systems Accelerated Process and SteelThread, eXtreme Programming, SCRUM, Feature Driven Development (FDD), and Dynamic System Development Method (DSDM), possess the following attributes:
They are not bound to one specific modeling tool.
The project staff is not required to fill out specific templates.
Depending on the methodology, the software development guidelines can be documented anywhere from a very general to a detailed manner.
The methodologies promote Rapid Application Development (RAD) philosophies, focusing on a quick time-to-market approach for the solution.
They are supported by formal consortiums or public communities of practice, which provide revisions to the methodology for public appraisal.
The Agile software development methodologies are either typically free to use, or the supporting documentation may be purchased for a small nominal fee, as in the case of DSDM.
The following sections will outline the more popular methodologies that you may want to initially consider in your selection process. Since a detailed analysis of each methodology would be beyond the scope of this book, it is recommended that you first develop an overview of the methodologies discussed and if need be, investigate them further through the resource links provided at the end of each methodology section.
Since this book is focused on BEA Technologies, the BEA Systems methodologies will be discussed in some detail.
The Project Initiation or Feasibility phase of a project validates the value proposition of developing a technical solution for a problem domain, and creates the environment for the project to be successful. The bottom line for this phase is to decide on whether the project is a “Go” or “No Go.” If it is a Go, then you must consider what are the initial project plan, resource requirements, software development methodology, and the technology that will be applied toward the solution.
Caution
It is important to have an open mind when trying to derive a solution to a business domain. Not all problem domains require technical solutions. Forcing technology upon a solution as the answer may not only be costly proposition, it may be one that does not get accepted organizationally by its end-users.
There are two main problems in developing software today. First, sometimes this phase is completely omitted, causing the software development lifecycle to begin with the Requirements phase. The problem with this situation is that there is no substantial due diligence that the project delivers value or will be successful. Second, this phase often takes too long and the project goes over budget, suffers from poor morale, and then dies a slow death.
In order to validate the viability of a project and arrive at a point that decisions can be made, there will be some questions that need to be answered. Obviously, each organization will have their own set of questions before a project is initiated, but here is a sample of questions that should be answered:
What is the problem domain, in a clear uninterruptible format—for example, does it hold a value proposition for a solution?
What are the needs from the business or problem domain—for example, a vision or mission statement?
What are the constraints the project will have to operate within—for example the political, technical, and cultural environment?
What are the corporate or organizational rules that will apply to the project—for example policies on spending and technology?
What is the longevity of the solution, and what solution (operational or technical) will scale to the end?
At a high level, what are the technical and operational requirements for the project—for example scalability, availability, and scheduled usage time (24*7)?
In order to move forward with a stable footing on a project, it is extremely important how you execute this phase. Remember, you and your organization must enter a project with a high confidence level that it will be delivered successfully with a minimum number of surprises.
Most OO methodologies will concur that this phase is required; however they fail to explain how it should be conducted, and hence how the deliverables can be achieved. BEA Systems, cognizant of this void in systems development efforts, and in an effort to ensure projects utilize J2EE and their WebLogic application servers, have developed an approach called the “Accelerated Process” (AP), which is provided through their Professional Services Group.
The objective of the Accelerated Process is to execute the project initiation phase in the shortest and most feasible time frame possible, without sacrificing the quality of any of the following deliverables:
A Feature Set Document (FSD), where system requirements are defined into categories in terms of their respective release schedules.
A Project Strategy, which describes how the project should be conducted and what software development methodology best suits the project.
A Project Plan to develop the solution, which includes the project phases, schedules, resources requirements, and other associated costs.
Note
Even though this section briefly describes the Accelerated Process, it is advisable to contact BEA Systems Professional Services Group to get guidance on its full usage and practice.
The Accelerated Process is principally comprised of the following activities:
The sessions are highly structured and participatory activities. The events are informal meetings, all of which are conducted by an experienced facilitator, whose responsibility is to guide the sessions and events to ensure the outcome is delivered successfully (see Figure 2.5).
Figure 2.5. The BEA Systems Accelerated Process is composed of highly structured and participatory events.
The participators of this process fall into two categories—Customers and Suppliers. Customers should be empowered people or Subject Matter Experts (SMEs) from cross-sections of your organization that will derive a direct benefit from the J2EE and BEA WebLogic solution.
Caution
Customers of the potential system should not include self-appointed proxies, as this can cause skewed or biased views that are not true to the real business domain under examination.
Alternatively, Suppliers are technical personnel or experts whose responsibility is to provide input into the technical decisions that need to be made during this phase, and potentially for all subsequent phases of the SDLC (analysis, design, development, test, documentation, and training). Examples of Suppliers include architects, lead developers, database architects, the project manager, and any external personnel representing the technical vendors for the project, for example BEA Systems, as in the case for BEA WebLogic Server.
The API is the first phase of the Accelerated Process. This is a very short event; typically in the context of a meeting, the executive sponsors, stakeholders, and project managers define the project in terms of its scope and vision. The result of this meeting leads to the development of the framework and a decision where emphasis will be placed in the subsequent sessions and events that comprise the Accelerated Process.
The outputs of the API event include
An identification of the project sponsors and other authoritative decision makers.
Establishing a vision, the objectives, and scope of the project.
Establishing the business and functional success metrics for the project.
An initial schedule of the required Accelerated Process events and sessions.
A preliminary list of project Customers and Suppliers with names and defined roles.
Identification of any related Customer documentation pertinent to the project.
As in all the events and sessions in the Accelerated Process, the outputs lead into the next phase.
The ARM is a very formal facilitator-based and documented session with the Customers of the project. It typically lasts anywhere from a few hours to a maximum of a few days, depending on the complexity of the project. The objective is to gain consensus and alignment at a high level on the business requirements for the project, without any emphasis on the technological feasibility of the solution. The goal here is to concisely, but accurately, state the problem that needs to be solved—the what is and the whys, not the how is. Even though requirements for the system are gathered at a high level from the Customers, this exercise is not a replacement for the Requirements phase. In this phase, the requirements will be gathered in a more formal and due diligent manner across the spectrum of the project’s scope.
Tip
Suppliers are encouraged to observe, listen, and learn more about their Customers and their respective needs.
The output of this session is a real-time list of functional requirements, as proposed by the customers, with the following value-added descriptors:
Categorization—. Categories are developed by grouping requirements according to their likeness.
Benefit Points—. Define how a functional requirement will profit the target business or problem domain.
Proof Points—. Represent one or more positive statements that prove a functional requirement has been met.
Annotated Commentary—. Is a set of assumptions, issues, action items, and comments made about each functional requirement.
Prioritization—. Prioritization artifacts identify the precedence or importance of each functional requirement defined in conjunction with the other functional requirements.
The outputs of the ARM session become the inputs to the next AP event, the ATFA.
The ATFA is very similar to the ARM, except in ATFA the Suppliers are in the spotlight. Again, this is a very formal facilitator-based session with inputs directly from the ARM session. Ideally, the Accelerated Process facilitator will coordinate this session with a technology expert/architect or evangelist from BEA Systems or the J2EE technology world.
The objectives of this session are to solidify the scope of the project through discussing the technical feasibility concerns, technical requirements, overall project approaches, and key technical assumptions which stem from the business requirements that were proposed by Customers in the ARM session. Depending on the complexity of the project, the duration of this session could be anywhere from a couple hours to a few days.
The delivered outputs of the ATFA are consolidated with the API and ARM outputs to form a document formally known as the Combined Findings Document (CFD).
The outputs of the ATFA include the following:
An early high-level technical architecture diagram, providing the Suppliers with an initial vision of how the solution will be designed.
A list of assumptions made by the Supplier team regarding the project.
A list of issues or concerns identified by the Supplier team which could potentially impact the project.
A list of potential functional requirements made by the Supplier team that were not collected during the ARM session.
A list of non-functional requirements the Supplier team requires in order to begin to develop the potential solution.
A technical assessment for each of the functional requirements identified in the ARM session, which ensures synchronicity between the two groups, the Customers and Suppliers.
Note
BEA Systems have an AP Tool that is specifically designed to capture and evolve the Combined Findings Documents throughout the various phases of the Accelerated Process.
The output of this session provides input into the next AP event, the Customer Validation Meeting (CVM).
During this meeting, the facilitator of Accelerated Process and the advocates from the Customer team review the Combined Findings Document. The output from the ATFA is included in the Combined Findings Document.
The objective of the CVM is to identify any technicalities from the ATFA session that may affect the scope or complexity of the project. Since the Accelerated Process is really gauged to be customer-driven, it is the Customers who decide whether to accept or refute the conditions and requests made by the Suppliers in the ATFA.
The ARRP is a highly formal session with the Supplier team to identify, assess, and document the risks of the project in the Combined Findings Document. The starting point for this session is a review of the Combined Findings Document and the results of the Customer Validation Meeting. By focusing on risks involved prior to any planning exercises, the risks can either be mitigated or contained through inclusion strategies, ensuring the initial project plan has a safe start. The outputs of the ARRP session directly affect the Project Plan.
Note
Depending on the complexities of the project, the duration of the ARRP can be anywhere from a few hours to a few days.
The output from this session is a documented list of risks in the Combined Findings Document, their associated consequences if not managed, any plans of mitigation, and any proposed containment strategies. These outputs then feed directly into the next AP event, the Risk Validation Meeting (RVM).
In this event, the advocates from the Customer team review and assess the key risks in the Combined Findings Document, as proposed in the ARRP session. The advocates from the Customer team can accept the risks or request further clarification from the Supplier team, but they cannot refute any risks.
The output of this meeting, which typically lasts a day, is documented in the Combined Findings Document. It is used as a basis to develop the initial project plan.
In this event, the Accelerated Process facilitator in conjunction with the project manager begin to review the Combined Findings Document, which includes output from all previous AP sessions.
Their objective is to identify the project requirements with their associated technical metrics for realization, and begin to formularize the following:
Project Structure—. Project tasks and their estimated start and end dates, and any milestones.
The Software Development Process—. A methodology, which should embrace the following activities:
Implementation of best practices or standards for consistent development
Architecture modeling
Object and code reuse
Code inspections
Software change management
Production support
The project management approach.
Augmentation to the project using consultants.
Any training that will need to be conducted to educate the project staff.
By determining the estimated project tasks, and associated start and end dates, an overall project duration can be developed.
The outputs from this event are as follows:
A Feature Set Document (FSD), where system requirements are defined into categories in terms of their respective release schedules.
A Project Strategy, which describes how the project should be conducted and what software development methodology would be best suited to deliver a rapid time-to-market solution.
A Project Plan to develop the solution, which includes the project phases, schedules, resource requirements, and other associated costs.
The two factors that will greatly influence the success of the APP event fall on how well the project plans and strategies have adapted themselves for component-based development. It is imperative that the touchpoints described in the following sections exist quite prominently in the project plan and strategy.
The project plan should be refactored into smaller incremental and iterative phases with milestones or binary deliverables.
Tip
Since it can be quite difficult to measure the progress of a project continuously, you must measure it using the concept of milestones.
A binary deliverable is an executable deliverable that has one of two states—done or not done. Since Analysis and Design can never be shown to be complete, they should not be considered binary deliverables. Ideally, a binary deliverable should be some software code which demonstrates a requirement the end-user (Customer) can relate to. For a J2EE system, this will include the presentation, server-side, and even data tiers of the system.
Every organization is different, so it is up to the project manager to define the duration between milestones that is acceptable to the end-users, without giving the impression too much time has passed without anything to show for it.
These two philosophies will stand the test of time in the development of component-based systems. First, you must acknowledge that you will not always get things right the first time around in developing software. Therefore, you will have to return to certain activities, but knowing more than you did initially enables you to be closer to getting it right. This is the concept of iterative development, which recognizes a single return to an activity is unlikely to result in complete success. As a result, each activity is repeated many times to refine the deliverables.
Note
Iterative development will span across the Requirements, Analysis, Design, Development, and Testing phases of the SDLC.
A software development process should never attempt to build an entire system in one monolithic effort. It should be partitioned into binary deliverables, each with its own independent, parallel streamlined effort—individual sub-project plan. The process involves each binary deliverable being developed, unit tested independently, and then integrated into the full system. This concept is known as incremental development.
Iterative and incremental software development practices should not blind the project members to the overall software development objective. This is quite common, as people are so consumed in what they need to deliver that they forget about the rest of the world. Hence, it is important to keep people connected in how the project is progressing as a group, not only so they understand there are other aspects of the project, but also to promote knowledge transfer from anything learned, positive or negative.
In order to control a software development effort, you need a natural feedback communication mechanism. The term natural is used because if it is not natural, there will be resistance in providing feedback over time.
The project manager is the person solely responsible for managing the project, and will consistently need to measure its progress; identify new risks and provide counter measures; compare that progress against the plan; and then fine-tune the development parameters to correct any deviations from the plan.
There is no given rule to what the feedback communication must be; for example, meetings, presentations, or artifacts such as status reports are normal means to provide feedback. The bottom line is that it must be acceptable to the people that will provide it; otherwise it will not work.
Unrealistic deadlines can cause unnecessary stress to everyone involved in the project, especially the development staff that has to produce a tangible product to show the user at the end of each milestone. This inevitably renders poor quality in the work and morale of the software development effort.
To prevent such environments, it is important to assess the iterative cycles of development, and reflect the true measures of effort for the delivery of each milestone into the project plan. In addition, during times of stress, it is important to keep people focused and involved in their domains of expertise, thus gaining the maximum return on their time. For example, developers should not be gathering requirements in times of stress; that should be the role of the business analysts.
Tip
In order to foster a good working environment for the people involved in a project, deadlines and milestones must be realistic and achievable, and not strain the cultural bounds that people are prepared to sacrifice toward a project. When milestones are aggressive, clear communication surrounding the justification for the schedule and some form of reward system on meeting the milestone work well. In an increasingly health conscious work environment, serving food, such as donuts and pizza, is losing its appeal!
The outputs of the APP become the inputs to the next AP event, the Project Commitment Meeting (PCM).
In this final meeting in the Accelerated Process, the Supplier team, including the project manager, formally presents their plans of executing the project and developing the technical solution to the Customer team, using the output from the APP.
Caution
This meeting has to be couched entirely in the vocabulary of the business. Even though a decision to move forward with a project may be implied, the plan has to be clear and concise, and address a balanced perspective of the value proposition as well as the risks to ensure acceptance.
During this meeting, the Customers will provide challenges by asking qualifying questions of the Supplier team, in order to make a decision on whether the project will be given the “Green Light” to proceed. Once agreed, the Project Plan, Feature Set Document, and the Project Strategy are all leveraged into the actual software development effort, thus providing a high confidence level for success to the overall project.
Note
For more specific details of the Accelerated Process, please contact BEA Systems or visit their Web site (www.bea.com).
One of the key architectural risks you will encounter in today’s J2EE system development efforts is the question of integration with other systems.
If your integration is going to occur inside WebLogic Server, it is going to be Java-based, and more than likely it will be successful, given that it is on the same platform and all you will need to do is tap into the appropriate interface with the right information and do some through testing. Tuning BEA WebLogic Server will take care of the performance and scalability issues.
However, if you are developing a distributed architecture which will include legacy, database, and vendor-based solutions outside the realm of WebLogic Server, the immediate question is the feasibility, scalability, and performance of the distributed architecture. It is imperative you validate all distributed architectures up front before any concentrated development efforts occur.
A BEA Systems SteelThread, rendered as a service through their Professional Services Group, is a prototyping methodology that embraces the concept of quickly developing an end-to-end “thread” of technical and procedural functionality the distributed architecture will need to support, as illustrated in Figure 2.6.
Figure 2.6. SteelThread promotes the idea of developing a single end-to-end “thread” or functionality the distributed architecture will need to support.
Ideally a SteelThread should be a single requirement that spans the complexities of your distributed architecture. Metaphorically, a requirement should be an inch wide and be proofed a mile deep, as illustrated in Figure 2.7.
Figure 2.7. In the SteelThread prototyping approach the thread should be a single requirement that spans your entire distributed architecture.
For example, a thread may include the presentation layer (JSP, HTML), server-side Java (Servlets, Beans, EJBs), and span all the way to the legacy and data layers.
An important aspect of the SteelThread prototype is that it is built with a mindset that it will serve first as a system design framework, and second as a foundation for future development. A SteelThread is not a throw-away, as the prototype term can sometimes imply. If the SteelThread is not successful in its objectives, it will at least serve as an excellent early proofing method for the design of a system. At the same time, another approach for the distributed architecture will need to be devised and executed using the SteelThread method.
The benefits of using a SteelThread are
You are able to realize early the capabilities, risks, and constraints of the distributed architecture. This will in turn enhance your understanding of the total system as you move closer to the actual development phases.
There is an extensive amount of knowledge transfer from BEA Professional Services to your development staff around the BEA WebLogic Server 7.0 capabilities and its facilitation of J2EE distributed architectures.
After participating in a SteelThread effort, your development staff will have experienced an end-to-end solution of a requirement. Hence, they will be better poised to develop the J2EE solution in parallel efforts.
Tip
For complex distributed architectures, multiple SteelThreads can be developed and executed in parallel.
Surprisingly, the Analysis and Design phases do not need to be completed for any SteelThread activity to begin. However, since the objective is to derive an end-to-end solution for a specific requirement, the duration a SteelThread will depend on the quality of the following factors, as illustrated in Figure 2.8.
Defined technical requirements.
An understanding of the business requirements by the development staff.
Project knowledge of the interfacing systems (Integration).
Availability of vendors and personnel from the interfacing systems (Integration).
The availability of any environment to design, develop, and test the SteelThread.
The better the information that feeds into a SteelThread, the quicker the pace for its execution. However, the less input you provide into a SteelThread, the more work the SteelThread will incur to gather the base inputs.
eXtreme Programming or “XP” is a lightweight software methodology that was developed by Kent Beck. Since its inception approximately five years ago, XP has evolved and inspired a developer-centric revolution. The XP methodology has its roots in projects where requirements are prone to change; development risks need to be mitigated to ensure success; and there are a small number of developers within an extended development team.
Everyone who participates in XP is considered an integral part of the team, including the advocates from the business. The “Whole Team” concept includes the following roles:
Tracker—. Is in contact with the XP developers regularly, and provides a roadmap action for any concerns or problems.
Customer—. Plays the role of the subject matter expert, and has the responsibility and authority to explain the requirements and set priorities as to which requirements are designed and developed.
Programmer—. Estimates the length of the development and testing cycle, and implements one or more requirements into a functional piece of software.
Tester—. Implements and runs the functional and acceptance test of the software code.
Coach—. Ensures the project remains focused and does not deviate from being “eXtreme.”
Manager—. Is the administrative arm of the group, who for example arranges meetings and ensures they are conducted to meet their objectives.
Doom Sayer—Shouts out when there are severe problems with the project.
The success of XP in today’s methodology wars has been how it has evolved using the following core principles:
Simplicity—. The design of the system is kept deliberately simple and clean, thereby delivering the software your customer needs, when it is needed.
Communication—. XP emphasizes teamwork between project managers, customers, and software developers, all being part of the XP team.
Feedback—. XP developers communicate regularly with their customers and fellow programmers. Through testing their software early with continuous feedback, XP developers can deliver the system to the customers as early as possible, and implement changes as suggested.
XP stresses complete customer satisfaction.
Courage—. XP empowers developers to confidently respond to rapidly changing customer requirements and technology, even late in the life cycle.
Using these principles, XP itself is conducted through a few rules and a large number of software development practices, thus establishing a methodology that is quite streamlined toward developing software. It embraces the rules and practices that promote the development of creativity, speed, and quality, and overlooks anything that can seem too complex to practice or an overhead for the development effort; hence the reason why this approach was coined the name “eXtreme Programming” and is considered extreme by most software development traditionalists. For example, XP eliminates the unnecessary artifacts of most heavyweight processes (formal status report, large volumes of requirements and analysis documents, and even UML diagrams), which can slow down and drain the development staff.
XP, as you will discover in the following sections, is very development- and test-centric. Through developing test scenarios and associated prototypes, the software solution is evolved from concept to actual code to refined design. It is this test-first-and-design-later approach that makes XP so efficient, as illustrated in Figure 2.9.
Note
Even though refactoring and testing code is the most important emphasis of XP, as opposed to requirements gathering, analysis, and design as in most traditional methodologies, industry surveys have identified XP as the one methodology which stimulates the most productivity from the people involved—hence proving the validity of XP as a methodology for software development projects.
In order to gain an introduction to XP, you will need to understand the 12 core practices of eXtreme Programming, which can be broadly described through the following:
The Planning Game Practices, Small Releases Practices, and Customer Test Practices
The XP team embraces a simple form of planning and tracking that allows the development of a solution in a series of small, fully integrated releases, in close consensus with the customer.
The Simple Design Practices, Pair Programming Practices, Test-First Development Practices, and Design Improvement Practices
XP developers work together in pairs, continuously improving the design of the solution through a repetitive testing ritual.
Continuous Integration Practices, Collective Code Ownership Practices, and Coding Style Practices
Once the initial skeleton system can be deployed, the XP developers will continuously work as a group to keep it operational and maintained through incremental code integration and a consistent coding style.
Metaphor Practices and Sustained Pace Practices
The XP team shares the same perspective of the requirements and solution, developing it at a sustained pace.
The main idea behind this practice is to make a rough plan quickly, and refine it as things become more clear, since both the customers and the developers will evolve their understanding of the requirements and desired solutions as the project progresses. The planning game also emphasizes visibility of the progress through some tangible releases as soon as possible, not only to show progress, but also to validate the projects existence.
This practice focuses on steering the project toward predicting the answers to two key questions:
What to initially release, and by what due date?
What to do next?
These are addressed through two exercises—Initial Release Planning and Iteration Planning.
During this exercise, the customer presents the desired requirements of the system to the XP programmers through user stories, which are small descriptions of the features and functionality of the system written on index cards. After the initial user stories have been collected, the customer sorts the stories by prioritizing them into the following three piles:
Critical for system to meet its business goals.
Will have a measurable impact on the system’s business goals.
Will make the user happy, but without explicit justification.
The programmers then sort user stories by risk into the following three piles:
By now, each card will carry a priority and risk factors, allowing the whole team to pinpoint the business requirements that require further clarification. The ones that carry a high priority and risk can then be refined through improved requirements or a prototyping exercise. Features with low priority and high risk are suspended until the whole solution has taken shape, thereby allowing the requirement to be better understood.
Once the requirements have been identified, the programmers estimate the level of difficulty and associated costs involved, and then lay out a plan to prototype the requirements into a tangible initial release that the customer can relate to. Initial release plans are imprecise, since the priorities and their estimates are not truly solid, and until the first prototype is built, the release schedules will not be accurately predicted.
After the initial release of a requirement, the knowledge of the amount of effort required is very visible, hence cultivating more predictable release schedules as the project progresses through subsequent prototyping efforts.
Within the Iteration planning exercise, the customer provides the programmers with features that will need to be delivered into the software system within a two-week window frame. Using the knowledge from preceding prototyping efforts, the programmers decompose the requirements into a granular roadmap consisting of tasks, time, and costs. The amount of progress made every two weeks is binary—a user story may or may not be implemented as a software component.
A golden practice in XP is to get something in front of the customers as soon as possible. The only technique to enable you to facilitate this is iteratively developing small releases of the system, each one having a bearing on a user story that the customer has provided. Some XP Web projects release to their customers as often as daily.
Not only can the customer reap the business value, but also this provides a mechanism for early positive and negative feedback to the whole XP process.
As part of providing user stories to the programmers, customers must also provide a means to test whether the desired features are functional in a specific manner. This acceptance testing criteria is embossed into a programmer’s efforts, causing all releases to be validated prior to customer viewing. This not only saves the customers time, but also illustrates that progress is positive. The customer is encouraged to be available as much as possible to the XP programmers.
In an incremental, iterative process like XP, a simple consistent design philosophy is critical to the formula for success. As each project will be different, the definition of a simple design can be quite nebulous. Probably the best definition can be derived from the touchpoints provided by Kent Beck, where a simple design
Runs all the programmer’s tests
Contains no duplicate code
Clearly states the intent of the programmer within the source code
Contains the fewest possible classes and methods
The idea of a simple design is to provide exactly what the customer has requested—no more, no less. Deviations from simplicity can cause extended release schedules and undue complexities in the actual deployed solutions.
Of all the aspects of XP, pair programming is probably the most questioned and argued for its productivity. Through the Pair Programming Practice, a user story is designed, developed, tested, and deployed by two programmers sitting side by side, at the same machine. Pair programming involves writing all production code in pairs, sharing a single machine. The notion is that two heads think better than one, while at the same time functioning as a single entity. This ensures that every aspect of an XP release is a collaborative effort between two XP programmers.
One XP programmer typically sits in the driver’s seat, designing and coding, while the other (co-driver) sits and watches, questioning any decisions and providing helpful resources as needed. After a release is deployed, the two XP programmers will move either together or separately to assume similar or opposite roles in other XP release efforts.
This arrangement can be quite difficult to fathom, but there are advantages to pair programming:
Business and technical knowledge transfer is osmotic when two people sit side-by-side.
An experienced XP programmer functioning as the driver can easily teach the co-driver at the same time as delivering a release.
Changing paired XP programmers will increase the comprehension of the total system solution.
The design and source code must be consistently reviewed by one person.
The budgetary personnel in a project who are used to heavyweight methodologies may faint when they learn that two resources are required to sit side-by-side, which can be perceived to be an expensive endeavor. However, industry evaluations have proved that two programmers working together can do a better job than one. An excellent resource to further investigate pair programming can be found at www.pairprogramming.com.
XP programmers use the concept of unit testing as a means to design and develop their specific software releases. Unit testing has programmers first write tests, and then create software to fulfill test requirements. Unit testing is a means for testing a thread of a system at any point in time. Even before a line of Java code is written, comprehensive unit test cases are envisioned for each method that will be developed.
Once the unit test cases are specified, development can begin. Source code is written in a test-centric manner, writing enough source code to execute and pass the associated unit test. As a result, software development evolves, preserving the simple design philosophy and providing 100% test coverage on the source code.
Only software that has undergone successful unit testing is checked into a software change management system. The test cases are then automated and collected to a large test set. As software releases are integrated into the larger solution, the test cases are run in an automated manner to ensure nothing is broken.
Continuous design improvement, or refactoring as it is termed, is a technique of improving the source code of a unit of software without modifying any of its functionality.
Throughout the XP programming efforts, programmers (the drivers and co-drivers) will be continuously predicting whether there is a better way to implement their software development effort. Programmers will be looking toward providing high cohesion and low coupling in their software, which is typically the trademark of a well-thought-out software solution. Hence, all duplication of any kind (objects, methods, and services) is removed.
There is a technical phrase back east, “A software system does not break; it is delivered broken.” In the west, this is known as integration hell, where the entire software system is broken and no one knows why.
XP aims to mitigate this horror of a situation by imposing that as soon as the developed system is mature enough to be integrated, it stays integrated, with rebuilds on every new introduction of code and multiple scheduled rebuilds on a daily basis.
There are three primary reasons why XP puts a lot of emphasis on this practice:
The XP team collectively becomes knowledgeable on the building process, not relying on inexperience at any time.
Problems with newly integrated code can be addressed immediately by the associated developers at hand; the cause of failure for any particular integration effort is obvious.
The only code that is frozen is off a working system, which can be rebuilt to provide a stable platform for future integration efforts.
With XP providing a continuous feedback loop to the success of a developed piece of code, it should not end when it is integrated into the large system set.
There are software development projects today where programming code becomes an emotional asset owned by its author, with all subsequent changes having to go through some approval and coordination process directly with the author of the code. This is such a lengthy and unnecessary process and can cause inter-team conflicts.
XP does not believe in any of this possessive nonsense. Within an XP project, every programmer owns and is responsible for all the code. Therefore, any pair of programmers can improve or modify any line of code at any time, practicing Unit Testing of course. This provides more eyes and minds to review the software as it is developed.
In order to practice Collective Code Ownership and Design Improvement consistently though an XP project, a coding standard and style need to be in place that all programmers follow religiously. The objective is for all the code in the system to appear as if it were written by one person on the XP project.
Without having any coding standard, it will be extremely difficult to refactor code, switch pairs of programmers to manage other software development efforts, and practice collective code ownership.
The coding standard and style should be discussed and implemented as much as possible before coding begins, to avoid any retrofitting further into the development effort.
Metaphors within the context of an XP project are a glossary of terms that becomes a fundamental part of an XP vocabulary within a project, making it easier for people to converse about how the solution system will work, where to look for functionality, and where to place functionality in the context of the overall system. Metaphors are defined at project launch and prevent ad-hoc names from being created to define aspects of the technical system, such as Java classes, methods and variables.
The XP methodology is a very team-oriented methodology, which implies that the pace of the project is governed by the people who will collectively execute it. There is no point having 70-hour work weeks if only one third of your project team can live up to those terms. It is unreasonable to impose unnecessary hours of work when the work will not be productive or conducive to the success of the project. There have been many studies on the harmful effects of working long hours: stress, poor productivity, coding mistakes, hair-loss, weight-gain and loss, poor vision, metabolic fatigue, and mental burn out are just a few of the possible harmful effects.
XP has a philosophy that the project will be a success if the selected pace of the project can be sustained by everyone throughout the SDLC. If people are having fun on a project, they will naturally work the hours necessary to make it successful. The “whatever it takes” attitude should come from the team, and not be imposed on it.
To get a better and detailed perspective of XP, you should review the following books:
Extreme Programming Explained: Embrace Change, by Kent Beck
Extreme Programming Applied: Playing to Win, by Ken Auer and Roy Miller
Extreme Programming Installed, by Ron E. Jeffries, Chet Hendrickson and Ann Anderson
Planning Extreme Programming, by Kent Beck and Martin Fowler
Extreme Programming Examined, by Giancarlo Succi and Michele Marchesi
Extreme Programming in Practice, by James W. Newkirk and Robert C. Martin
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, by Scott W. Ambler
The Rational Unified Process, or RUP as it is known in the development community, is an excellent example of a predictable or heavyweight software development methodology.
The Rational Unified Process has its roots in the Objectory Process developed by Ivar Jacobson, which was an object-oriented design methodology that focused on development through the use of case modeling. With the efforts of Ivar Jacobson, Grady Booch, Jim Rumbaugh, Philippe Kruchten, Walker Royce, and other people from Rational Software, the Objectory Process began to evolve. The realization of the effort being the Rational Unified Process, which
Unified the crème de la crème of proven software development practices.
Embraced UML as the de facto notation for all of its modeling artifacts.
Addressed the full software development lifecycle from project inception to post-production phases.
The Rational Unified Process is in essence a very comprehensive software engineering process that needs to be followed meticulously, since it asks the following:
In order to effectively utilize the Rational Unified Process, you not only need to purchase the product from Rational Software, but you also have to purchase a modeling tool that supports the current implementation of UML and the Rational Unified Process. Unfortunately, there is only one to choose from—Rational Software’s Rational Rose 2001.
The product itself, as illustrated in Figure 2.10, is Web-enabled, and needs to reside on every project member’s desktop while the process is underway. This allows all of the team members to share one knowledge base, one view of the process, and one modeling language reference (UML).
Figure 2.10. The Web-enabled Rational Unified Process interface needs to reside on every project member’s desktop.
In conjunction with Rational Rose, you have access to a wide range of features and support resources, for example
A powerful graphical navigation system and search engine.
An interactive knowledge base.
Guidelines, templates, and tool mentors.
Examples and templates for how to construct UML models in Rational Rose 2001.
Access to Rational’s Resource Center, where you can review white papers, updates, hints, and add-on products, such as the BEA WebLogic Plug-in.
Both the Rational Unified Process and Rational Rose 2001 are available for download for a fifteen-day trial at the Rational Software Web site (www.rational.com).
The principles of the Rational Unified Process are all based on the following software development practices:
Interactive Development: Through the feedback achieved in every design and development cycle, an evolving understanding of the problem is refined, illuminating potential risks before they can arise.
Use Case Driven: Use cases provide the primary requirements of the problem domain, which are then further refined to detailed use cases. They provide a visual perspective of the system by answering who its users are and how they interact with it.
Architecture-Centric design: An architectural blueprint of the desired system is built early, and is central to the future development of the solution system. Having a stable upfront architecture paves the road for parallel development efforts, and clearly identifies where and how the software design will be implemented.
Risk Management: Encourages the high priority risks to be mitigated sooner rather than later.
Software Quality Control: Using appropriate metrics, quality control is built into every aspect of the Rational Unified Process.
Software Change Management: The Rational Unified Process is a collaborative effort from a mid-to-large number of people within a team. A high frequency of documents, artifacts, and source code are generated, all of which need to be stored centrally and managed to control any changes.
The Rational Unified Process has two dimensions—Phases and Process Workflows, as illustrated in Figure 2.11.
There are four distinct phases in a Rational Unified Process SDLC—Inception, Elaboration, Construction, and Transition.
Each phase is composed of a number of iterations. Each iteration constitutes a complete development lifecycle, from requirements to deployment of an executable piece of code, as illustrated in Figure 2.12.
The first pass through the four phases is called the Initial Development Cycle. Unless the life of the product stops, an existing product will evolve into its next generation by repeating the same sequence of inception, elaboration, construction, and transition phases, which is known as the Evolution Cycles.
A phase is analogous to a milestone, with instructions on how to achieve a given set of objectives, what artifacts to produce, and how to evaluate the quality of the deliverables. Based on this information, a management decision can be made on whether to proceed to the next phase.
The objective of this phase is to specify a business case and project scope, including initial requirements, costs, and risks for the desired system. If the project is feasible, a plan is developed for the next phase of the RUP, the Elaboration Phase.
To gain an understating of the problem domain and scope, multiple high-level use cases are developed. A use case defines and describes a way an end user (actor) performs a series of steps to obtain a result. Use case diagrams model all interactions between an actor and a system in a single high-level diagram. This allows everyone to be in sync with the intent and scope of domain.
The documents and models that are produced from this phase contribute toward the Requirement Set artifacts, and can include
A vision of the desired system.
Use case models of the primary functionality of the system.
A tentative architecture.
A project plan for the Elaboration Phase.
The primary objective of this phase is to analyze and stabilize all the requirements (technical and non-technical), and mitigate any potential high risks in order to derive an architectural foundation that will be sustained until the end of the project.
All architectural decisions are made based on the requirements illustrated through detailed use case models, and only those architecturally significant use cases are used to design the architecture.
The documents and models that are produced from this phase contribute toward the Design Set artifacts, and can include
The objective of this phase is to complete any outstanding analysis work and most of the design and implementation. The software is iteratively and incrementally developed toward a point when the first or beta release of the product can be transitioned into the user community.
The documents and models that are produced from this phase contribute toward the Implementation Set artifacts, and can include
A Deployment model
An Implementation model
During this phase, depending on the development cycle, a beta or final release of the software product is transitioned into the user community. With initial deployments to the user community, bug fixes, addition feature requests, and feature-based training will need to occur.
At the end of this phase, the objectives are measured against the associated requirements, and a decision is made whether to iterate through another development lifecycle.
The Process Workflows outline the steps you actually follow to develop your system through each development cycle of a phase. As illustrated in Figure 2.13, the Process Workflows are
Business Modeling: Develops an understanding of the problem domain through visual modeling techniques such as use cases.
Requirements: Use cases are used to functionally specify the system and its boundaries.
Analysis and Design: A detailed design of how the system will be implemented.
Implementation: Code development, compilation, and unit testing followed by software deployment.
Test: Testing the software to ensure it meets the needs of the end users.
Deployment: Deployment of the software to the actual end user community, and providing any supporting documentation and training.
The supporting workflow processes include Configuration and Change Management, Project Management, and environment.
Even though the activities associated with a specific workflow process can overlap into multiple phases, as illustrated in Figure 2.10, the objectives of the activities will be governed by the phase they are executed within.
To get a better and detailed perspective of RUP, you should visit the Rational Software Web site (www.rational.com) or review the following books:
The Rational Unified Process, An Introduction (The Addison-Wesley Object Technology Series), by Philippe Kruchten
The Unified Process Explained, by Kendall Scott (Paperback)
The Road to the Unified Software Development Process (Sigs Reference Library), by Ivar Jacobson and Stefan Bylund
A Practical Guide to Unified Process, by Donald Kranz and Ronald J. Norman