Use Rational Tools to simplify J2EE-based projects (2) Start projects

Part 2: start the project

Steven Franklin
Software designers and Process experts
March 2004

There are manyArticleThe series describes how to gradually apply the Rational Unified Process (RUP) and other rational tools. The detailed plan of the sample project in this article is discussed around management requirements and risks.

Part 2 snapshots

Part 1 shows the tools and technologies: Rational Unified Process (RUP)-Support the formulation of project plans RUP Microsoft Word template-Draft the project vision document Rational requisitepro v2001a-Required database Rational ClearQuest v2001a-Used for Risk Management Products to be created or updated: Requisitepro Database-It is created to store the requirements from the customer's work description (SOW), and then the requirements will be converted into a more detailed system requirement specification that is directly oriented to the analysis work. ClearQuest risk database-(By modifying the ClearQuest plan) is created to track project risks.

Failed to plan from the beginning
In a software project, it is critical to get a good start. Not only do you want your early work to determine the tone of the entire project, but you also want to quickly identify the high risks and challenges in the system. The fate of more than half of projects is doomed in the first month of the project. The factors that determine the fate include:

• Insufficient Customer Relationship
• Insufficient budget
• Poor management (including poor management capabilities, risk priority, and poor project scope management)
• Too dependent on silver bullet
• Lack of engineering skills and experience
• Unrealistic time progress

By improving the efficiency and guidance of the team, the Rational Unified Process (RUP) can minimize the cause of project failure. Good data can affect project management by project managers, better tools can support engineering teams, and better processes can help software products develop in a foreseeable way. Part 1 of this series will focus on some of the early strategies we can apply to get something out of the box in our sample project.

Note that project management involves some activities that aren't currently addressed in the RUP. I highly recommend the book. Please note that project management includes activities not currently included in the RUP. I strongly recommend this bookRapid development: tame crazy software progressIt can be used as a further reference to reduce risk factors in development projects.

Refine the progress of Stage 1
We want to start software engineering as soon as possible, but first we must get the customer's consent on a series of schedule issues. We brought it.The time progress of stage 1st that we have created(End with a demo at a four-month time point) and more closely reviews the progress with the customer. The customer raised the following questions, all of which were justified and discussed:

• "With iterative development, how will the engineering team know how many iterations are required to achieve our goal ?"
• It is uncomfortable for us to design the architecture and design before the necessary conditions for analysis and architecture are met. "
• "What functions will we get in four months ?"
• "What tools will you use to create a system? We hope to start the procurement and training process ."

This is the main concern of the customers we see, and we have answered each question:

• Worried about the continuous development of the project spiral, but there is no clear delivery productBecause ASDI is a company that follows the sort-by-order ISO standards, they tend to develop a time baseline in an early stage in a specific sequence from one to another. We point out that iteration can reduce risks and avoid the inherent problems of all products at a time. Although the number of iterations may change in the project process, the customer can better observe the progress of the project than a single iteration. Although a single iteration seems simpler, we need multiple iterations to create a system more cost-effectively. ASDI participation in early iterations will give them more benefits, which gives customers the opportunity to provide their own views on the input of the development system.
• Worry about missing demands and inadequate analysis.Once again, the asdi iso background makes them more willing to believe that analysis should be executed and documented before any design begins. We have emphasized to them the benefit of using RUP to allow overlapping tasks, that is, tasks in different stages can be executed in parallel. For example, the detailed design can include the creation of the prototype and otherCodeDevelop to verify design assumptions and reduce performance risks. Waterfall development is very flexible and does not provide you with many early warnings of high risks.
• Worried about project progress tracking.ASDI has begun to worry about the use of iterative development methods, and they need to see the assurance of the specific progress that can be demonstrated in the project. At this point, we cannot tell them what the demo looks like. This will take one or two months before we can be identified when we understand more about the critical and high-risk areas of the system. We explained to them that at least the system demonstration should show some deep-seated aspects of the architecture that have reduced the major risks we have identified. We also expect that the system demo will display the entire system workflow, availability issues, and interoperability issues between components.
• We are worried that the tools we selected will not be available or supported in the future.This is very important for ASDI because they plan to take responsibility for system maintenance after the project ends. They don't want to see the use of exciting but risky technologies too early. In terms of tool selection, we need to make some early exploration work for customers' technical needs, maintenance plans and other needs. The OTs evaluation (including what we recommend) will give ASDI the opportunity to review our standards and rationale for the selection of tools and technologies. At this point, ASDI still has no confidence in its own execution conditions. At present, there is very little IT infrastructure that drives us to make quick decisions.

To sum up, we do not feel that our time schedule is overly confident, and we are confident to complete the task within the customer's cost expectations. Our ability to meet the time schedule comes from our team structure where we review the project with ASDI in the project team. As shown in table 1, we plan to include some part-time roles. For example, we have a separate QA personnel in our project, who also plays a role in her project; in our project, she is shown as a 20% role, this means that in our project, she worked for one day a week:

Role Time Commitment Project Management Project Manager 50% Financial support 15% Quality assurance 10% Project Project Engineer 50% Engineering support (including configuration management and system management) Part-time job Support and Review Team (regular review and consultation) Part-time employment (from within and outside the project) Team Lead/Senior Analyst Full-time employment Senior developers Full-time employment Common developers Full-time employment Database architect 25%

Table 1:Team Structure

In general, we plan to require 450 person-days of work to create a system demonstration over the past four months. During the project progress, we will know whether we need to add time or finish it in advance, and we will also notify the ASDI project. When presenting the system demonstration, we should also fully prepare for the in-depth design review, and show the customer the estimated project stage 2nd. If ASDI is satisfied with our work on the proof of concept (POC) in phase 1, they will work with Phase 2 of our startup project to develop a productized system.

Although we are still creating the ASDI stage 1st demo, ASDI is very pleased to see that our work will be a good input for further developing the productization system. At least they are close to on-demand review, on-screen mode, OTs assessment, architecture review, two actual versions, and one system demo.

Manage Risks
It is extremely important to track risks from the very beginning. In previous projects, we used Microsoft Excel to manage risks. This time we decided to use Rational ClearQuest to simplify risk input, management, and reporting. ClearQuest is not a cheap tool, and it is not a unique and cost-effective tool for risk management. However, it can also centrally manage our integration and testing problems. In addition, we plan to share this cost with other lookoff projects.

ClearQuest designer allows you to easily design new data structures and forms. For example, creating a risk input form is similar to a defect form that is already displayed in ClearQuest designer. We can create a new Schema Based on the defecttracking schema ), you can also delete unnecessary entries and rename other entries, such as updating the corresponding form, deleting or renaming the necessary prompts and fields.

Here is how you can experiment on your own: If you have installed ClearQuest and have administrator permissions, you can easily find the ClearQuest designer application.Program. From the File menu, select new schema and select an existing schema you want to modify ). We chose to modify the defect tracking Plan (defecttracking schema ). Once you name your new schema, you will be prompted to create a database associated with the schema. Unless you develop a special method, you will create the database in the form of a Microsoft Access database. When you are asked to associate the new database with a schema, select the schema you just created and named ). Then you can check the edited form and data type to meet your requirements. For example, you can expand the record type and the form node of the directory tree to view the existing defect_base_submit form. These forms can be renamed, and some fields can be deleted or added. For more information about creating and modifying ClearQuest forms, see the ClearQuest document.

I can quickly input the risks of our project into ClearQuest on our desktop. All members of the entire team can access the risk database and enter the risks they observe. Although only the project manager (PM) and project engineer (PE) should have permissionsCloseRisk, but to every member of the teamProposalThere is nothing wrong with the risky permissions. The Project Manager first wants to view the risks visible to the customer, because some of these risks may not be associated or can be quickly solved. For example, figure 1 shows a form used to input early risks of the project we discussed.

Figure 1:ClearQuest risk input form

At the beginning of the project, I found and entered a total of 17 risks. This is not a very big number, and some of the risks (such as challenging time schedules) will exist until the end of the project.

Figure 2 shows the ClearQuest interface for the list of a part of the project risk we are querying. Risks are listed at the top and strictly arranged in order. Click the risk item in the list to obtain more detailed information about a single risk.

Figure 2:ClearQuest risk report

Tracking progress
Management requires tools to track project progress. In the early stages of a project, we cannot rely on any image defect, change request, or test results to measure the project's success. On the contrary, we must estimate the actual proportion of completion based on the work breakdown structure (WBS) and our progress.

A good working Breakdown Structure (WBS) is very important for tracking project progress.Features in section 1stDescribes our 1st stage work task package. In order for us to work out useful matrices, these job packages must be clearly defined and the size of each job package should be properly planned. We typically allocate 10 to 40 days of work to these job packages.

In addition, ClearQuest can also help us track variable parts in those systems-in these variable parts, the change request is extremely high. In some previous projects, we found that too many change requests in the Refinement phase are usually one or more of the following signs: inadequate analysis, difficult customers, fragile engineering teams, poor process execution or complex re-engineering. If some of these symptoms occur in some aspects of the system, additional attention should be paid to them by the management staff and the team lead.

Manage customer expectations
It is easy to reduce the number of meetings and contacts with customers. However, it is actually one of the most important members of your project team, and the customer should be included in the entire project from the perspective. This not only produces better analysis and improvement of the results of each iteration, but also allows customers to better manage their expectations by allowing them to see evolving products and understand the challenges they face. Especially when the customer is not very proficient in technology, their expectations for the final product will greatly exceed the actual cost, time schedule and feasibility.

We suspect that the real project priority and motivation do not reflect the current situation of the customer. We also need to understand the main priorities and expectations of the customer. To achieve this, we have drafted an outline of the Vision document to help understand more customer expectations. (Due to time constraints, we have merged the business vision and project vision into a document .) Both the current situation (SOW) and Vision documents should be revised with the customer several times.

The vision document is created based on one of several Microsoft Word templates provided by the RUP installation package. We will install these templates in a place specified by word (via tools> Options> file location ). As shown in 3, we generate a preview for each template (by opening each. DotTemplate File, select File> Properties> summary, check "Save preview screen", save the file) and rename the template title*. DotFiles to make them easier to browse.

Figure 3:Browse the RUP Microsoft Word template

Management requirements
Requirements are not trivial for the system. Similarly, because ASDI has very few IT infrastructure, the transition of system requirements to detailed software needs requires sufficient time and effort. Rational requisitepro can help us with this task, which allows us to manage our needs throughout the project and track changes in the scope of the project.

The customer's initial work status (SOW) can serve as a baseline for our system requirements. In many cases, we start with business modeling and Requirement Analysis as described in the RUP. This should include a set of business use cases, supplemented system specifications, and business object models. However, it is very important for us to meet the expectations of our customers and build on their work. We will generateSoftware Requirement Specification(SRS) is a product of the RUP and serves as a basic set of requirements. Based on this, we can track our subsequent analysis and modeling products.

The capabilities of requisitepro can easily help us insert requirements from the customer's working status (SOW. Rules for creating requirements must match the style of our "Bullet", or match any or all of the keywords "must", "will", and "shoshould. Other tricks that can help us establish a requirement level include obtaining the requirement block at the same level, and setting the default value for the appropriate parent requirement under the requirement block creation tag, then let the creation tool complete the subsequent work. (At first we didn't set the parent requirement when creating the requirement block, so we had to return to each requirement and set the parent requirement for each requirement-this is a tedious task for hundreds of requirements .)

Figure 4 shows a page from the customer service subsystem requirement (about 40 pages in total ). As you can see, the requisitepro interface is tightly integrated into the word application, so you can use Microsoft Word and requisitepro features at the same time.

Figure 4:Rational requisitepro Interface

We closely communicate with our customers about what information is needed, but we have asked them to do a lot of work in the requirement documents. This proved to be a very effective way; we were able to teach their teams the process skills, and they were able to give our team expert advice on their disciplines. We tend to invest a lot of detail in some fields, while others are only at a very high level. In some cases, this is reasonable, but in other cases, they are overly enthusiastic about a specific field of the system. Through a document review, we can instruct ASDI To Write appropriate and sufficiently detailed sets of requirements. Because we are processing Word documents, it is easy to interoperate on specifications. When we are satisfied with this document, we can run requisitepro on the document.

At this time, we also pay attention to the system'sNon-functionalRequirement, which means that these requirements will not be described by the system's functional specifications. These non-functional requirements include availability requirements that focus on people's factors (such as learning and use comfort) and reliability requirements.

Summary
At this point in the project, we operate a very small team. Planning and Resource Acquisition are our top priorities. Our team will become more and more motivated until we know where we should work and how we can achieve our goals. First of all, the most important thing for us is that we must complete the customer's working status (SRS), which specifies the basic system and software requirements of the project.

Plan the future
We hope to form an engineering team as soon as possible, but our next task requires a senior analyst to make the initial stages of the RUP more progressive. First, the requirements displayed in our working state (SOW) are essentially a series of decomposed specifications, which cannot lead to clear work breakdown, or it cannot even generate many architectural clues. We always believe that the demand for plain text representation will not bring the same benefits as the demand for Unified Modeling Language (UML) expression, therefore, we plan to convert our requirements into use cases (using UML in Rational Rose ).

Similarly, we need a formal approach to manage customer change requests, customer concerns, and customer feedback. Although we didn't use the ClearQuest web interface before, it looks like a perfect tool to keep the development team and the customer in sync. Setting up ClearQuest web is the highest priority for the next week or the next week.

Major Risks
There is no significant change in our risk: we must continue to focus on establishing effective customer relationships and quickly moving the project forward in the right direction. We now have a problem database, so we can close this risk. However, until we establish the ClearQuest web interface, customers can have a clearer view of project risks and their support for our fields. (When we close this risk, we cannot provide time or infrastructure to build ClearQuest, but a large project will definitely benefit from ClearQuest .)

Customers are happy that our progress has been completed on schedule, partly because our work products are not unrelated to them. As we continue to move to the product of RUP, we must provide a lot of guidance to maintain the customer's comfort and gently move into the new concept: Use Cases, Business Objects, and so on.

We feel that our time schedule is practical and well designed except for small accidents. This means that resources must be put in place as soon as possible, and the review responses must be timely. We must also focus on high-level risks from the very beginning, because we cannot let them step into Project 1st later.

Resources

• Rapid development: tame crazy software time progressBy Steve McConnell (Microsoft, 1996)

Author's blog:Http://blog.csdn.net/legendinfo/