Use RUP to manage small projects and teams

David Kohrell in February 2005. The Rational Edge journal points out that the rational Unified process, or RUP, provides a flexible procedure for project advancement-the binate phase, the refinement phase, the build phase, and the product phase-to give guidance and clarification. This article pays particular attention to how RUP can also provide guidance for small projects and teams. In addition, we have observed RUP and other guidance in the capabilities of the agile development environment (e.g., project management knowledge system of the Project Management Association, or Pmbok?).

Background for small projects and teams

Usually it seems that if you are arranged to manage a small project, it means that you are new or you are outdated. It is thought that "first-class resources" should be assigned to large, enterprise-class, full-feature release projects. This understanding is wrong, let's look at the market, especially in the 2001. After COM fragmentation, the time for small projects and agile teams is ripe. The smaller the number of projects the company completes in one months, a quarter, or a year, the more opportunities there are to generate revenue, reduce costs, or expand brand and value.

After defining some of the following definitions, we continue to discuss this topic:

• Large project: The budget exceeds $500,000, the team size is 13 people or more, the project takes more than one year.
• Medium Project: Budget $100,000-$500,000, team size of six to 12 people, project time is six months to one year.
• Small project: Less than $100,000, with a team size of less than six people (including team members shared between the project and other projects, as well as the daily required staff). Project duration is less than six months.
• Change requests: All tasks that are budgeted below $50,000 are completed by a person within a few weeks.

RUP works equally well for small projects

Before Michael Jordan, Greg LeMond, and Tiger Woods, Bo Jackson ruled the world of sports. In the late the 1880s, the phrase "Bo knows basketball, football, and investment" is popular.

Over the past three months, in a seminar or class, I have cited Bo Jackson's example to refute the erroneous view of the Rup "not fit" small project. I think Rup is "fit" for all types of projects, which surprises many people. In terms of my experience with Rup over the last few years, it can be used in all large, enterprise-level projects and organizational change requests. It's not just a dispensable methodology.

Here are the two areas that people often mention to illustrate "RUP does not apply to small projects," and I will answer these questions one at a time to prove that their views are wrong:

2. The agile approach takes into account rapid and tight increases or phases, reduces overhead, and ensures a strong connection between developers and customers.
   
   My answer: Agile methods and similar methods (Scrum,paired programming) are innovative and useful in software construction. However, agile methods can also be used in RUP. Those lightweight methods can be used well in the construction phase, solution, or program of the new system, but still need to manage the upstream and downstream activities of the other three phases, such as deciding what needs to be done (requirements) and how the operating environment will be impacted (release management). The RUP does not focus on the use of all the business principles in the start-up phase, the elaboration phase, the build phase, and the product phase, in fact, it provides an optimal framework for these activities.
4. Rup and similar guidance, such as PMBOK, the Integrated Competency Maturity Model (CMMI) of the Software Engineering Association (SEI), or the UK's IT Infrastructure Library (ITIL) standard imposes unnecessary processes on small projects. They are in fact only applicable to large projects over 10 million.
   
   My Answer: A method, a knowledge system, or a mature model does not impose a process. They provide some basis for estimating what needs to be done and how to do it better. The "How To Do" section is determined by the implementing organization.
   
   Pmbok does not specify that the 39 procedures in version 2000 or the 44 procedures in version 2004 must be used in a project. It is a knowledge system that provides a starting point for the various situations that a project manager may encounter. For example, it helps define what the change control process for your organization should include. Now, project management Professionals (PMP), under the supervision of the Project Management Association (PMI), must, of course, follow Pmbok. PMI is qualified for PMP, so that organizations that hire professionals can be assured that the professional understands pmbok. However, this does not mean that professionals must use every item of knowledge in each project to Pmbok. The Capacity Maturity Model (CMM) and CMMI of the
   
   Sei assess and validate the maturity of an organization from five levels. According to Sei's rules, it is very clear to evaluate and verify what an organization does, and in a way, how they are done. However, this does not stipulate that a "repeatable process" (level two) must be done using processes, tools, and organizational roles.
   
   Similarly, the "Essence of Rup"--and many of the tools that have been developed to implement RUP--fosters the gradual refinement of the concept, the nature of incremental development. The RUP view is that organizations should design and build some rather than all of the solutions, and the requirements are known. In reality, one of the most effective ways to verify that a feature or system is a "popular application" (such as an idea) or a "failure" (for example, Coca-Cola's New Coke, since 1984) is to deliver the product to the user.
   
   Applying RUP to explore the SEI cmm/cmmi evaluation, or using PMI Pmbok, best practice is to use these wizards in a systematic manner. For example, you should first understand the business needs (a.k.a requirements), start with the essential use cases, and model them based on the powerful features of use cases and UML. In 2004 the Rational Unified Process made Easy , Per Kroll and Philippe Krutchen described this method nicely:

... Perhaps the most common mistake people adopt when using RUP is to use too many artifacts or do too much activity. Excessive use of RUP will reduce your development efficiency; The RUP process framework is similar to a buffet, and if you want to stay healthy and happy, you can't eat all the food. 1

RUP is used in small project environments

Now, let's take two examples to verify the use of RUP in a small project environment. The first is the public sector project – updating a printing process that has been in use for 15 years. The second project involves the use of RUP to create a learning management system portal called "tap University". Two project budgets are lower than $100,000 and are completed within 90-120 days by a small team.

Print Service Update Project

Bill Wonch, one of the authors of the paper, is a part-time lecturer and software architect for the Nebraska State Department of Labor. He has recently been responsible for updating a set of 20-year-old programs, totaling and printing thousands of statements and bills, and the following is his story.

It's just a small project. However, it is the core of the system, called Mix, and must support updates to other systems within the department. This large framework illustrates the Deliverable Software architecture documentation in RUP-understanding each project, changing commands, or tasks affecting the progress of the work, as each line of golf is associated with others.

The "Mix update Project" started when a system needed to be updated to work with the company's modern unemployment insurance benefit payment system. The original system mix was built with COBOL and runs on a host system. "Mix" is not a short name; 1987 was named "Mix" because it mixes the main frame data and forms for a lot of printing work.

The new system will be built in Java using mature commercialization (commercial-off-the-shelf,cots) applications and components to generate the necessary XML files.

In the first phase of the project, we define three participants for the system:

• An abstract application class that represents all systems that use the mix application.
• An action class that represents an employee's actions to manage printing.
• The business consumer, the person who uses the document repository.

As shown in 1, each participant is associated with the appropriate use case. Remembering these participants and use cases, we can choose the best commercial application for the update system. With this information, we can accurately calculate the cost of the update. Those are limited content in project contracts and plans. Based on this, we can estimate the funding of the project.

Figure 1: Three participants defined for the system at the project start-up phase

Based on the planned and captured use cases identified in the inception phase, RUP directs the project. Part of the essence of RUP is the ability to divide requirements into groups, and to classify groups into the first, refinement, build, and product phases as needed. The mix system consists of 106 print programs, binate stages to the production phase, dividing these programs into several groups, and then processing them separately, each of the four stages is a low-risk (verification method), and then integrates the large and small print programs. The above approach is meaningful.

TAP University

TAP (technology as promised) university is an online learning Management system project. Tap University's goal is to extend this in-person training provided by TAP partners to corporate clients and to provide online services to companies, public users and students. 2

This is a small project. Improve an open-source learning management system. The draft visual documentation for the project was presented on February 22, 2005 and the project plan was completed on May 3, 2005, including the resources, costs and scope required. Table 1 describes each iteration and use case.

Table 1:tap Iterations and use cases for university projects

From conception to implementation, the project was less than six months old, and it took only 90 days from the start of the formal project to the completion of the function, from the project plan to the support of the product.

There are 8 resources involved, and the estimated number of hours required to complete the project is 652. The cost is mainly "human capital"--less than $15,000.

The RUP application in this project mainly includes the following two aspects:

1. RUP has provided a framework for the organization of iterations and use cases. The use case shown in table 1 together with the two-page project plan that contains the MS Project schedule output forms a document file. CVS 1.12 and LMS act as shared libraries.
2. RUP Guides how we build and produce, even in cases where only 80% of the requirements are known. For example, there are three optional e-commerce solutions that need to be evaluated. Deciding which ecommerce tool to use does not rule out the output of the iteration 1. This means that the company's customers are able to use iteration 1 immediately.

Conclusion: RUP is indeed suitable for small projects

The two small projects mentioned in the article present the needs of different types of organizations: large public sector offices and newly developed small companies. The focus of the project is also different: The update uses the 15-year-old print collection tool and the online learning management system. Two projects in common, they are small in size and RUP provides a rigorous and flexible approach.

Several authors, such as Gary Pollice, have made valuable suggestions for small-project managers in the software development of small teams:

In

the face of constant change, how can the project team master how to cope with change to achieve maximum productivity? We believe that the key is to learn as many different technologies as possible, to learn how to use the tools effectively to support different technologies, and to decide what and when to work together. 3

Rup and a variety of tools that support Rup are indeed "suitable for small projects", and project managers should know how best to leverage the strengths of RUP.

Comments

1 Per Kroll and Philippe Kruchten, the Rational Unified Process made easy:a practitioner ' sGuide to the RUP, ADD ison-wesley:2004, pp. 244-245.

2http://www.tapuniversity.com/

3 Pollice, Augustine, Lowe, and Madhu, software development for Small teams:a rup-centric approach, ADDISON-WESL EY, 2004. P. xix.

Resources

• You can refer to the original English text on the DeveloperWorks global site in this article.

Use RUP to manage small projects and teams