Part II: Starting the project
Steven Franklin Software Designers and Process March 2004
This series of many articles 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 needs and risks.
The second part snapshot Part 2 show the tools and techniques of the display:
Rational Unified Process (RUP) - Support Project Program RUP Microsoft Word Template - Draft Project Vision Document Rational RequisitePro V2001A - Database Rational ClearQuest V2001A - Products for risk management will be created or updated:
RequisitePro Database - is created to store requirements from the customer's work description (SOW); then demand converts to a more detailed system requirements specifications for direct analysis work. ClearQuest Risk Database - (by modifying the ClearQuest plan) is created to track project risk
From the beginning of the plan or plan failure in a software project, it is very critical to get a good start. You will not only want your early labor to determine the tone of the entire project, but you also want to quickly identify the high-risk and challenges in the system. About more than half of the project's destiny has been destined in the first month of the project, and the factors determined include:
Not good enough customer relationships, bad management (including non-good management capabilities, risk priority division and bad project management) too dependent on silver project skills and experience lack unrealistic time progress
Rational Unified Process (RUP) can reduce the failure of the project failure by improving the efficiency and guidance of the team's efficiency and guidance team's maturity. Good data can affect the administrator of the project to the project management, better tools can support engineering teams, better processes to help software products develop in a foreseeable way. Part 2 of this series will focus on some of the early strategies we can apply to get some things that are swaying in our sample projects.
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 some activities currently not included in the RUP. I strongly recommend this book to quickly develop: tame crazy software progress It can serve as a further reference for reducing risk factors in the development project.
Refining the first phase time Progress We hope to start the software engineering as soon as possible, but we must first get the consent from our customers on a range of schedule issues. We brought the time schedule we have created (at the end of the 4 months) and ended more closely with our customers more closely. Customers have proposed the following questions, all issues are justified and some discussion:
"Use iterative development, how will the engineering team know how many iterations do you need to achieve our goals?" "" The necessary conditions in the analysis and architecture are reached before the design architecture and design are uncomfortable to us. "" At 4 months, we will get what functional system demonstration? "" What tools do you use to create a system? We want to start the purchase and training process. "
This is the main concern of our customers, and we answer each item:
Worried that the project spiral continuous progress has not been clearly delivered. Because ASDI is a company that follows a sequential ISO standard, they tend to develop specific time bottom lines in the order from one to another. We point out that iterations can reduce risks and avoid elaborate issues with all products. Although the number of iterations may vary during the project, customers can progress than only a single iterative better observations. Although a single iteration looks more simple, we need multiple iterations to create a system with more cost effective. ASDI's participation in early iterations will give them more benefits, which makes customers have the opportunity to provide their own views on the development system. Worried about the needs and insufficient analysis of omissions. It will be mentioned here that the ASDI ISO background makes them prefer to believe that the analysis should be performed and documentated before any design begins. We emphasize that RUP has the benefits of allowing tasks to overlap execution; that is, tasks in different phases can be performed in parallel. For example, the detailed design can include the creation of prototypes and some other code development to verify design assumptions, reduce performance risks, and more. The waterfall development process has little flexibility and will not provide you with a lot of early warnings for high-risk. Worried about tracking of project progress. ASDI has begun to have a concern of an iterative development method, and they need to see a guarantee that can be made in the project into system demonstration. At this point we can't tell them what is defined. This requires one or two months when we can be determined when we understand the key and high-risk areas of the system. We explain to them that at least system demonstrations should show a deep part of the architecture of the main risks we have identified. We also expect the system demonstration to display the workflow, availability issues, and interactivity between components throughout the system. Worried that we choose tools that they cannot provide or support in the future. This is important for ASDI because they plan to bear the responsibility of the maintenance system after the end of the project. They don't want to see premature use of exciting but risky technologies. In terms of tool selection, we need to make some early exploration work for customers' technical needs, maintenance programs and other needs. The OTS assessment (including what we recommend) will give ASDI to review our standards and reasons for tools and technologies. At this point, ASDI still has no confidence in its own implementation conditions. They currently have few IT infrastructure to promote us quickly decisions. In summary, we don't think we have a time schedule is too confident, and we have confidence to complete the task within the customer's cost. About us to meet the progress of time comics comes from our team structure, in the project team we review the projects with ASDI. As shown in Table 1, we planned to include some part-time character. For example, we have a separate QA personnel in our project, and this person also plays a role in her project; showing her as a 20% role in our project, this thinks in our project She works a week:
Character
Time promise
Project Management Project Manager 50% financial support 15% quality assurance 10% project engineer 50% project support (including configuration management, system management, etc.) part-time support and review team (regular review and consultation) part-time job (from project and project Excerptists) Group leader / senior analyst full-time senior developer full-time general developer full-time database architect 25% Table 1: Team structure
In general, we plan to need 450 people's workload to create system demonstrations for these four months. During the progress of the project, we will know if we need to add time or completed in advance, and we will also notify the ASDI project. When presenting the system demonstration, we also have to prepare in-depth design reviews, and can show the estimates of the second phase of the project. If ASDI is satisfied with the work of our conceptual inspection (POC) in the first stage, they will develop product-based systems with the 2nd phase of our launch project.
Although we are still creating a demonstration of ASDI, ASDI is very happy to see the work we work will be a good input to further develop product system. At least they have been close to the demand for review, screen mode, OTS evaluation, architectural review, two actual version and a system presentation. Managing risks are extremely important from the beginning. In the previous project, 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 cost effective tool for risk management. However, it can also centralize our integration and testing issues. In addition, we plan to take this cost in other projects in Lookoff.
Using ClearQuest Designer can be very convenient to design new data structures and forms. For example, creating a risk entry form is similar to the defect form that has been displayed in ClearQuest Designer, we can delete some unnecessary entries and renamed others according to the Defect Tracking Schema. Entries, similar updates, corresponding forms, delete, or rename the necessary prompts and domains.
Here is how you can test themselves: Suppose you have installed ClearQuest and have administrator, you should be able to find the ClearQuest Designer application. From the File menu, select Create Plan (New Schema) and select an existing plan you want to modify (Schema). We choose to modify the defect tracking plan (DefectTracking Schema). Once you give you a new program (Schema), you will be prompted to create a database associated with this plan (Schema). Unless you make a special method, you will create this database in the form of a Microsoft Access database. When you are asked to associate this new database with a plan (Schema), select the plan you just created and named. (SCHEMA). Then you can check the edit and modified forms and data types to meet your requirements. For example, you can expand the record type and a list of table nodes of the directory tree to see the existing defect_base_submit form. These forms can be renamed, some domains can be deleted, added, and more. For more information on ClearQuest forms, create and modify the ClearQuest documentation.
I can quickly enter the risk of our project to ClearQuest in our desktop. All members of the entire team can access risk databases and enter the risk they observed. Although only project managers (PM) and project engineers (PE) should have permission to close risks, it is nothing wrong with the permissions of each member of the team. The project manager first wants to view the risk visible for the customer, because some of the risks may not be associated or can be solved quickly. For example, Figure 1 shows a form that is used to enter the risk of the project we have discussed.
Figure 1: ClearQuest Risk Enter Form
I found and entered and a total of 17 risks for the beginning of the project. This is not a very large number, some of which (such as challenging time schedules) will exist until the final period of the project.
Figure 2 shows the ClearQuest interface of a list of a part of the project risk we query. The risk is listed above and is strictly arranged in order. More detailed single risk information can be obtained by clicking the risk item in the list.
Figure 2: ClearQuest Risk Report
Tracking progress management requires tools to track projects. In the early stage of the project, we cannot rely on any icon defect, change request, and test results to measure the success of the project. Instead, we must estimate the proportion of actual completion based on the work decomposition structure (WBS) item and our progress. Good working decomposition structure (WBS) is very important for tracking project progress. The Dantecha in Part 1 describes the work task package in our first stage. In order to enable us to refine the useful matrix, these task packs must be clearly defined and appropriately planned for the size of each work task package. We typically allocate 10 to 40 days of working workload for these tasks.
In addition, ClearQuest can also help us track the variable parts in the system - in these variable parts, the change request is extremely high. In some previous items, we found too much change request in the refinement phase is usually one or more of the following aspects: not enough analysis, difficult to get along with customers, fragile engineering teams, poor Process execution or complex project. If these symptoms have occurred in certain aspects of the system, managers and group leadiers need to have additional attention to these parts.
Managing Customers expects to be easier to reduce customers' meeting and contact; however, it is actually one of the most important members of your project team members, and customers should be included in the entire project from the beginning. This can not only produce better analysis and improve the results obtained by each iteration, but can better manage customers's expectations by letting customers see the product and understanding of the product and understanding of understanding. Especially when customers are not very proficient in technology, their expectations of the final product will be greatly exceeded by real cost, time progress and feasibility.
We suspect that real project priority and motivation do not reflect the current situation of customers, we also need to understand the main priority and expectations of customers. In order to achieve anything, we drafted a profile of vision documents to help understand more customers expect. (Due to time limitations, we combine business vision and project vision into a document.) Whether it is a work status (SOW) or the vision documentation is required to make multiple revisions with customers.
The vision document is based on one of the Microsoft Word templates provided by several RUP installation packages. We installed these templates in Word specified (through tool> option> file location). As shown in Figure 3, we generate a preview for each template (by opening each .dot template file, select File> Properties> Summary, check "Save Preview Screen", save the file) and rename the title of the template *. DOT files make them easier to browse.
Figure 3: Browse RUP Microsoft Word Templates
Management demand demand is not insignificant for the system. Similarly, because ASDI has few IT infrastructure, the system requirements are required to be fully costly software requirements to the detailed software requirements. Rational RequisitePro can help us to complete this task, which allows us to manage our needs and tracking projects throughout the project.
The current situation of the customer has begun (SOW) can be used as a baseline of our system. In many cases, we start with business modeling and demand analysis as described in RUP. This should include a collection of business use, supplementary system specifications and business object models. But it is very important to meet their expectations from our customers and build it in their work. We will generate a RUP product called Software Demand Manual (SRS) in accordance with the current situation, and put it as a base collection of demand, according to it we can track our later analysis and modeling products.
RequisitePro's ability is very easy to help us insert demand from our client's operating status (SOW). The rules we create should match our "bullets" style, or match any or all keywords "Must", "Will", and "Should" match. Others can help us establish a demand level to obtain a demand block at the same level, and set the default value for the appropriate parent requirements under the demand block creation label, and then let the creation tool complete the next job. (First we use the demand block to create no parent demand, so we must return to every requirement and set the parent demand for each requirement - this is a tedious work.) Figure 4 shows A page from the customer service subsystem (about 40 pages). Just like you see, RequisitePro's interface is closely integrated into the Word application, so you can use Microsoft Word and RequisitePro at the same time.
Figure 4: Rational RequisitePro interface
What kind of information we closely communicate with customers is needed, but we let them work a lot of work on demand documents. This proves to be a very effective way; we can teach their team skills, and they can give our team their discipline. We tend to invest in some fields in some areas, while in other fields are just at very high levels. In some cases it is very reasonable, but in other cases they excessively fanatically excessively. By reviewing the document, we can guide the ASDI to write appropriate and detailed demand collection. Because we are processing the Word document, interoperability on the specification is easy. When we are satisfied with this document, we can run RequisitePro on the document.
At this time, we pay attention to the non-functional needs of the system, which means that these needs will not be described by the system's functional specification. These non-functional requirements include the availability requirements of the factors (such as comfortableness of learning and use) and reliability requirements.
Summarizing this point in the project, we operate a small team. Develop plans and obtain resources is our primary task. Until we know what direction we should work and know how to achieve goals, our team will become more and more fighting. It is first most important for us to complete our client's working condition (SRS), which specifies the basic system and software requirements of the project.
Planning the future we hope to make an engineering team as soon as possible, but our next task requires a senior analyst to make RUP's initial phase more progress. First, the demand displayed in our working status (SOW) is essentially a series of decomposed specifications that cannot be guided by clear work decomposition, or even clues that can not produce many architectures. We have always believed that the demand expressed by the white text will not bring the same benefits to the needs of the unified modeling language (UML), so we plan to convert our needs into use case (use UML in Rational ROSE).
Similarly, we need a formal way to manage customer change requests, customers concerned from places and customers. Although we didn't use the ClearQuest's web interface, it looks like a perfect tool to keep the development team and customers synchronize. Establishing ClearQuest Web is the highest priority of us or the second week.
Main risks Our risk has no significant change: we must continue to put energy in establishing effective customer relationships and fast moving projects along the correct direction. I now have a problem database, so we can close this risk; however, until we have established a ClearQuest's web interface, customers can see the risks of the project and they can support our fields more clearly. (Later, when we shut this risk, we can't provide time or infrastructure to establish ClearQuest, but a large project will be clearly benefited from ClearQuest.) Customer is very happy that our progress is completed as scheduled, part of our Work products do not feel unrelated to them. When we continue to move to RUP products, we must maintain our comfort and gentle access to new concepts through a large number of guidance: use cases, business objects, and more.
We feel that our time schedule is the actual and design is good in addition to very small accidents. This means that resources must be in place as soon as possible, and the review must be timely. We must also pay attention to high-level risks from the beginning, because we can't let them go in the first stage of the project later.
Resource
Rapid development: Tame crazy software time progress author Steve McConnell (Microsoft Publishing, 1996)
