First part introduction
Steven Franklin Software Designers and Process March 2004
This series of articles consisting of multiple articles tells how to develop a software item by applying the Rational Unified Process (RUP) and the Rational Tools in a very tight time and budget. The first part of the article contains high-level planning and demand.
RAIONAL's development kits support two-way engineering (RTE), distributed, and collaborative development, highly iterative development cycles and more features. This first part of this series of many articles will show you the role of the Rational tool and show you that you can simplify distributed J2EE (Java 2 Platform, Enterprise Edition) by using Rational tools. We will look at a single fictional project and the introduction of high-level plans and demands as a development and will transition to various stages of the Rational Unified Process (RUP). This article assumes that you have a certain understanding of RUP; if you don't know RUP you can view the relevant resources listed in the article.
For the sake of simplicity, we don't want to complete all the necessary iterations in the RUP, but only the features of the tools used in each phase of the project. We will follow our small sample project, complete its first main building, as follows:
Understand the concept of RUP and the use of Rational Tools, apply them to deal with remote development, tight time planning and restricted budget challenges Using Rational technology to implement end-to-end management in J2EE project integrated Rational Tools Complete automated test, bidirectional engineering, geographical code check and quality assurance (QA) Rational technology and J2EE tool integration, for ultimate solution, especially application J2EE, relational database, like DB2 or Oracle, and Java integrated development environment
Each of this series of articles has a similar form of organizational form. Each article begins with a road sign, just like the following, each link will be part of the corresponding article.
Part 1: Project introduction; high-level plan Part 2: Risk management; demand management
Part 3: Model creation and access control; demand analysis
Part 4: Use examples to refine; production reports; tools and technologies
Part 5: Architecture and design
Part 6: Detailed design; early development; two-way engineering; early unit test
Part 7: Continue development; early construction; demo
Part 8: Unit test strategy; functional testing; GUI test script
Part 9: System construction and testing; defect tracking; product delivery
Part 10: Project completion; conclusion; future work
The first part of the tools and techniques in the first part of the snapshot:
Rational Uniform Process (RUP) - Work products for project high-level plans are generated or updated:
Danteap-is created for the purpose of project management, as a baseline executed as a time schedule and project budget is measured.
The sample project introduces the virtual assumption in this article is that we are a software company, named Lookoff Technologies Incorporated, our company's main business is in IT systems, including integration, support, and development. Our headquarters in Toronto and have some small offices throughout Canada. Because our analysis and development team is very close to our large multinational customers, this company's structure allows us to concentrate our experts (typical backend development and project management) in a very good way.
We assume another virtual company, AudioPhile Speaker Design, Inc. (ASDI), this company is located near New Brunswick. ASDI begins with a small company engaged in speaker manufacturing and design, mainly developing some custom speaker schemes for personal users. With the increase of ASDI's reputation, they have developed more mainstream speaker product lines and supplies products to users and electronic stores in Canada and North America. ASDI's technical facilities do not meet their growth needs. They have been difficult to manage orders, plan to produce materials, track part demand and management transportation. More importantly, ASDI customers complain that they lack the ability to browse the availability and delivery.
ASDI realizes that the transition from paper and spreadsheets to automated asset management systems is accompanied by risk, and ASDI decides to give all of their IT requirements to a home. They choose our main reason is that our good reputation is very close (easy to support) from their company.
Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I've acquired through excellent books such as those listed under Note: Although the sample project is fictional, but it is based on my Personal experience, observations of other projects and I have obtained knowledge through some excellent books (such as those listed in the end of the article).
Like a high-level demand like many small non-IT companies, ASDI realizes their problems, but they don't know what they look like. Their original working state only two papers, and it is a mix of contract, functional, and programming. We are sitting down to discuss each of their needs; the most interesting thing is the contract and programming issues, discussing as follows:
Contract Problem Customer (ASDI) I hope that we sign a company fixed price (FFP) contract, the contract value is $ 10 million (CDN), according to the contract, the software system should be delivered within 10 months. It is impossible to sign this contract for us without a clear demand vision. This will bring us too much risks and may be unfair to customers, and we can determine that their technical needs will be satisfied. We started the first meeting to discuss the development of the iterations and and incremental software development is superior to the order ("Waterfall").
The key features of our RUP that emphasizes customers include:
Iterative Engineering, reducing risks and polymeric programs do their best to use existing tools, technologies, and developed products to reduce cost enhancement. Management and control changes to customers to create high quality products for understanding production products.
Customers are still very concerned about the lack of software delivery. Through some discussion, we successfully showed that customers from the beginning to end of the project should have a sufficient understanding of the progress of the project. They also want the project's budget to pay in phases, and ask us to fulfill some obligations when performing projects. Therefore, the project plan is divided into two to the stage:
Stage 1 - Create a system of "Conceptual School" version. Customers will pay our fees according to the work, but within the preselection of the first phase. Stage 2 - Create a product version of the system, pay the fee according to FFP.
For the stage 1, the customer requires the upper limit of 250K CDN, we feel that this budget is very sufficient for the demo version of us to create the first prototype system. We created the Dante chart of Figure 1, which we have shown this point in four months should have a demo version and review with the customer to ensure that at least the first phase of the timetable is roughly synchronized. (Then we have checked this time schedule more closely with them) Figure 1: Stage 1 Dante
The picture in Figure 1 is created with Microsoft Visio, but you can easily use Microsoft Project or some similar software tools to plan your project. This chart is the main purpose of our work to reach the time-proof and milestone, and establish a layered map of the work decomposition structure (WBS), each of the work decomposition structure can be tracked, estimated, and executed.
Programming Problem ASDI is an ISO certified company, and they are very faithful, continuous milestones, and wide quality control. They are not a very technical company, they have their own ideas on the process. One of our challenges in cooperation with them is to find a process and a collection that is satisfied with the work product, and will not make our team feel more. They conducted several meetings and highlighted to have a lot of thorough detailed documentation. Moreover, their milestones are sequential, and their thoughts are that every task must end before the next task begins. Their understanding of the process allows us to make greater challenges in the most likely ways.
Although ASDI agreed to develop (based on RUP) methods we used iterations and increments, they don't seem to be interested in this approach. They want to get the following:
Fixed milestones:
System Requirements Check (SRR), Preliminary Design Check (PDR), and Key Design Check (CDR) Demo Release of Two Software Receive Test (FATS) and Customer Acceptance Test (CATS)
We simply insert these milestones into our process (as shown in Figure 1).
A formal demand document, a design manual and accept the test document. These are newly-oriented symbols based on RUP methods, and ASDI is not very concerned about all of them, but ASDI still agrees to maintain their high-level levels of their delivery work, so that we can make The work product of RUP meets the work products expected by ASDI. We feel that you can use the Rational tool to generate a document you need, will not cause great hindrance to our process, and you can successfully communicate the information to the customer. Specifically, Rational SODA enables us to generate a document from the model easier.
ASDI also plans to hire an IT manager to contact us and is also responsible for maintaining and managing completed projects. We need ASDI's people to join the project, this person should be a technical authority for the project. Unfortunately, this IT manager (for the company is an emerging thing) lacks knowledge of customer operation, just like our team.
Summary In a series of meetings that start with our customers, we have achieved some very good progress. ASDI's deliberation is a significant flexibility for delivering products and time, and allows us to develop based on RUP-based methods. We reached a rough time schedule for the project and established a good relationship with our customers. Through discussions with customers, we recognize some risks, followed by our priority and project management we used to divide the task.
One of the highest priorities that we should conduct in the future is to start the vision of the project from the customer's work (SOW). We have obtained a probably understanding of customer needs, but we also need to analyze the specific work that needs us.
We must also refine our time schedule and start our best in the starting stage as soon as possible. During phase 1, to ensure that a solution is cost-effective and meet customer needs, we must find out how to meet customer needs. Customers have already mentioned that the main factors that decide whether to proceed to the second phase is the maintenance of the final system and the cost of system architecture software / hardware. All in all, what we should do in the past few weeks include:
The Customer Work Status (SOW) described in detail in the project, and enters the project requirements in Rational RequisitePro. To stage 1 refine the time schedule After successful design, create a project plan to display how to transition to the second phase. Develop a detailed implementation plan to mitigate the identified risks
The main risk projects will be made a few weeks for establishing effective customer relationships and keeping projects in the right and appropriate technical direction. We don't have much time to find the needs of the technology and integrate these technologies into our team, because the customer's expectation project is very fast.
We believe that we must establish a database of databases, we can make action entries, questions, and risks in a centralized lookup database. By publishing this information to the web, you can monitor project information in either a centralized office or a remote development team. If there is a necessary, even long-distance workers can track and update the risk of the project.
Resource
Rational Unified Process: Introduction, Second Edition Author Philippe Kruchten (Addison-Wesley, 2000) This book provides a very good introduction to RUP. More detailed information can be found in the RUP product. Rapid development: Tame crazy project progress Author Steve McConnell (Microsoft Press, 1996). Moon Myth, Anniversary Edition: Software Engineering Prose Author Frederick P. Brooks, Jr. (Addison-Wesley, 1995). Death march: The Complete Software Developer's Guide To Surviving "Mission Impossible" Projects by Edward Yourdon (Prentice Hall PTR, 1999).
