Using IBM Rational Unified Process in small projects: Extreme Programming profiling

Summary

IBM Rational Unified Process (or RUP) is a complete software development process framework with several out-of-the-box instances. The process originating from the RUP is extensive, from lightweight RUP that meets the needs of small projects in a short cycle to a more complete process that can meet the needs of large, distributed project teams. Various Types and projects of scale have successfully used the RUP. This whitepaper explains how to use RUP in a lightweight manner in small projects. We will explain how to apply extreme programming (XP) technology within the context of a complete project.

Introduction

A little story

One morning, a manager asked me if I could spend a few weeks creating a simple information system for a company's newly launched investment. I'm tired of the projects at hand and eager for the excitement of starting a new project, so I'm excited for this opportunity-I'm quick start to develop new great solutions, and get rid of the bureaucracy and procedures of the large organizations I work.

Things are going smoothly at the beginning. I have been working for a long time and have fun in the first six months. My work efficiency is incredible, and some work is a masterpiece of my career. The development cycle is fast, and I can complete some major new parts of the system every few weeks. The interaction process with users is simple and direct. we all belong to a closely linked team, and some procedures and documents can be skipped. There is no formal design;CodeDesign is the code. Everything is perfect!

This kind of perfection only lasted for a while. With the development of the system, we need to do more. The existing code must be improved as the problem changes, and the concept of work is refined accordingly. I hired some developers to help with development. We work like a unit and often discuss some issues with each other. This enhances communication and eliminates the need for forms.

A year has passed.

We are also adding developers. The entire team includes 3 to 5 people, and then 7 people. It takes a long time to learn each time you add people. If you have no experience, it is difficult to understand and explain the entire system, even an overview. We started to use a whiteboard to display the overall structure, main concepts, and interfaces of the system more formally.

We are still using tests as the primary means to verify whether the system meets the needs. Many new developers stand on the user's standpoint and we find that informal requirements and personal contacts in the early stages of the project cannot meet their needs. It takes us a longer time to plan the target content we want to establish. As a result, we keep the text record of the discussion, instead of frequently recalling the previous decisions. We also found that the description of requirements and use cases can help to introduce the situation to new users of the system.

The scale and complexity of the system are constantly increasing, and unexpected situations occur-the system architecture needs to be clearly described. At the early stage of the project, most of the architecture was stored in my mind, and later it was written down in notes or activity diagrams. However, as the number of project personnel increases, the architecture is somewhat out of control. Since not everyone is as experienced as me, they cannot discover the impact of some changes on the entire architecture. We have to use more accurate terms to define constraints on the system architecture. Any changes that may affect the architecture must be discussed by the Team and approved by me. We found this problem only after a circle. After accepting some important lessons, we realized the importance of architecture.

This is a real experience. It only describes some of the difficult experiences of this project. These experiences are only unusual in one aspect: some of us have been together since the very beginning for more than a year. Developers often come halfway through a project and leave without waiting for the end, without any further impact on what they do.

This project should have been managed using some processes. Too many processes may lead to mistakes, but not using them will bring new risks. Just as people who invest in high-risk stocks only see high returns, the project team that barely uses the process ignores the key risks in the project environment. In fact, they expect the best results, but no plans for the worst case ".

Overview

This article discusses how to apply the process to the project described above. Our goal is to get the "proper level" of the use process ". Understand the challenges faced by the development team and the environment in which the development team is located, and determine the appropriate level of use of the process. If we understand these challenges, we can use just enough processes to reduce risks. The "one-size-fits-all" process does not exist, whether it is lightweight or other. In the following content, we will study this idea, that is, the proper level of the process can be used as a function of risk.

We focus on how to get the appropriate level of the process by using two popular methods: Rational Unified Process or RUP and extreme programming (XP ). We show you how to use RUP in small projects and how to deal with areas not involved in XP. The integration of the two provides the required guidelines for the project team-to reduce risks while achieving the goal of delivering software products.

RUP is a process framework developed by IBM rational. It is an iterative development method based on six industry-proven best practices (see the RUP appendix ). As time advances, a RUP-based project will go through four phases: Inception, elaboration, construction, and transition ). Each stage includes one or more iterations. In each iteration, You need to invest different workload based on different requirements or workflows (such as requirements, analysis, and design. The key driving factor of RUP is to reduce risks. Using thousands of IBM rational customers and partners in thousands of projects. The workflow of a typical iteration process is displayed:

Typical iterative stream

As an example of how risks affect the process, we should consider whether to model the business. If some major risks are not taken into account in our understanding of the business and the system we build is wrong, we should perform some business modeling work. Do we need to formally perform modeling? This depends on our stakeholders-if a small team will use the results in an informal manner, we may only make informal records. If other people in the Organization will also use the results or view the results, we may have to make more efforts and ensure that the results are correct and understandable.

You can customize the RUP to meet the needs of almost any project. If you do not have an out-of-the-box process or roadmap that meets your specific needs, you can easily create your own roadmap. The roadmap describes how the project plans the use process, and thus represents a specific process instance of the project. This means that the RUP can become simple or complex as needed, and we will explain it in detail in this article.

XP is a code-centric Lightweight Process for small projects (see the XP appendix ). It came from Kent Beck's idea and attracted the attention of the software community in the C 3 payroll project of Chrysler in around 1997. Like in RUP, XP is based on iterations and embodies several practices such as small-scale release, simple design, testing, and continuous iteration ,. XP has introduced some effective technologies for appropriate projects and environments; however, there are also hidden assumptions, activities, and roles.

The basic principles of RUP and XP are different. RUP is a framework of process components, methods, and technologies. You can apply it to any specific software project. We want users to limit the scope of use of RUP. XP, on the other hand, is a process with more restrictions and requires additional content to make it suitable for a complete development project. These differences explain a point of view in the software development field: the developers who develop large systems use RUP to solve problems, while those who develop small systems use XP as a solution. Our experience shows that most software projects are between the two-try to find the appropriate level of process that fits your needs. It is inadequate to simply use either of the two.

When you integrate the XP Technology in the RUP, you get the correct amount of process, which not only satisfies the needs of all project members, but also solves all major project risk problems. XP is fully qualified for a small project team working in a highly trusted environment where users are part of the team. You need to do some other work for scenarios where the team is becoming increasingly dispersed, the Code volume is getting bigger, or the architecture is not well defined. In projects with contract style in user interaction, XP alone is not enough. RUP is a framework that allows you to expand xp with a more robust set of technologies, as necessary, starting from the RUP.

The following section describes a small project based on the four phases of RUP. In each phase, we determine the activities and artifacts generated. Although RUP and XP have different roles and responsibilities, we will not handle these differences here. For any organization or project, the actual project member must be associated with the correct role during the process.

Project start-start stage

For a new development project, the initial stage is very important. Before the project continues, you must handle important business and demand risks. For projects that enhance the existing system, the initial phase is relatively short, but its purpose is to determine the implementation value and feasibility of the project.

In the initial phase, you can create business cases to build software. A view is a key component in the initial process. It is an advanced description of the system. It explains to everyone what the system is, users who may use the system, reasons for using the system, required features, and constraints. The view may be very short, and there may be only one or two segments. A view usually includes key features that software must provide to customers.

The following example shows the short view of a project, which transformed the external website of rational.

To make rational a world leader in electronic development (including tools, services, and best practices), we can enhance customer relationships through dynamic and personalized websites, provides self-service, support, and target content for visitors. New processes and technologies enable content providers to accelerate release and improve content quality through a simplified and automatic solution.

Four important activities in the beginning of the RUP phase are:

Define the scope of the project. If we plan to build a system, we need to know its content and how it meets the needs of the stakeholders. In this activity, we capture sufficient detailed information about the content and the most important requirements to produce acceptable standards for the product.

Plan and prepare business cases. We use views as guidance to define risk mitigation strategies, develop initial project plans, and determine known costs, schedules, and profit margin balances.

The alternative architecture is obtained. If there is no novelty in the system being planned and the framework is widely used, you can skip this step. Once we know the customer's needs, we need to allocate time to study feasible alternative architectures. New technologies can bring about new and improved solutions to solve software problems. In the early stages of the process, you can spend some time evaluating whether to purchase or create a system, select technology, and develop a starting prototype, which can reduce some major risks of the project.

Prepare the project environment. Any project requires a project environment. Whether you use XP technology (such as Pair Programming) or a more traditional technology, you need to determine the physical resources, software tools, and steps that the team will use.

During small project development, there is no need for too much "process time" to start the process. You can usually do this in a few days or less. The following content describes the expected artifacts in addition to views in this phase.

One approved business case

Stakeholders have the opportunity to determine from the business perspective that the project is worthwhile. Both RUP and XP acknowledge that it is best to come to an early conclusion about whether the project is worthwhile, so as not to spend valuable resources on a project destined to fail. As described in "Planning eXtreme Programming, XP's answers to questions about how a project is formed and the roles involved are vague (it seems that it is the clearest in an existing project or system environment ), however, in the research phase, the artifacts processed by XP are the same as those in the initial process of RUP.

Whether you consider business issues in XP in an informal way, or make business cases a top-notch project artifacts in RUP, you need to consider these issues. Risk list you should keep a risk list record throughout the project development process ). Using a risk list can be a simple list with a planned risk mitigation strategy. Set a priority for each risk. Any project-related personnel can view the content of the risk and how to handle the risk at any time, but there is no general way to solve the risk.

Preliminary Project Plan

This plan includes resource estimation, scale, and phase plan. For any project, these estimates are constantly changing and you must monitor them.

Project Acceptance plan

Whether your plan is formal depends on the project type. You must determine how the customer sees your project as successful. For an XP project, the customer will take the form of acceptance test. In a more general process, the customer may not actually perform tests, but the acceptance criteria must be made directly by the customer or by another role, such as a system analyst who is in direct contact with the customer. Other acceptance criteria may also exist, such as creating end user documents and help, but XP does not.

Initial refined iteration plan

In a RUP-based project, you plan the next iteration at the end of the previous iteration in detail. At the end of the iteration, you can evaluate the criteria set at the beginning of the iteration. XP provides some excellent techniques for monitoring and measuring iteration success. The measurement criteria are simple and you can easily merge them into iteration plans and evaluation criteria.

Start case model

Although it sounds formal and frustrating, it is quite simple. The use case corresponds to the "story" written by the customer in XP. The difference is that a use case is a complete set of actions initiated by participants or people or things outside the system. This is the value of the use case. Use Cases may include several XP "Stories ". To define the boundaries of a project, we recommend that you determine the user and role in the initial process. Focusing on the entire set of operations from the user's point of view helps to divide the system into valuable parts. This helps to determine the appropriate implementation features, so we can deliver some results to the customer at the end of each iteration (unless early in the initial iteration and refined iteration ).

Both RUP and XP can help us avoid a situation where the entire project has completed 80%, but it is not deliverable. We have always hoped that the released system will be of value to users.

At this point, the use case model has little or only little detail to support in identifying use cases and participants. It can be a simple text or UML (Unified Modeling Language) diagram drawn manually or using tools. This model helps us ensure that we have included the correct functions that the stakeholders are interested in, and do not forget any functions, and allows us to easily view the entire system. Use Cases are prioritized based on several factors, including risks, importance to customers, and technical difficulties. There is no need for too formal or too large artifacts in the initial stage. Keep them simple or formal as needed. XP includes guidelines for planning and system acceptance, but RUP needs to add more content early in the project. These few additions may provide great value for the project by dealing with a more complete set of risks.

Refinement stage

The goal of the Refinement phase is to set up a baseline for the system architecture and lay a solid foundation for a large number of design and implementation work in the construction phase. Architecture evolved by considering the most important requirements (those that have the greatest impact on the system architecture) and evaluating risks. The architecture stability is evaluated through one or more architecture prototypes.

In RUP, design activities mainly focus on the concept of system architecture. For software-intensive systems, it is the concept of software architecture. Using the component architecture is one of the six best practices for software development embodied in the RUP. It is recommended that you invest some time in the Development and behavior architecture. The time spent in this work can mitigate the risks associated with the fragile and rigid daily system.

XP uses "metaphor" to replace the concept of architecture. Metaphor only captures part of the architecture, while the rest of the Architecture evolves with the natural results of code development. XP assumes that the architecture starts from generating simple code and then performing continuous code refactoring.

In RUP, the architecture is not just a "metaphor ". In the Refinement phase, you build an executable architecture that may reduce many risks related to whether or not to meet non-functional requirements, such as performance, reliability, and robustness. By reading the XP literature, it is very likely that it is futile to deduce some content described by the RUP for the Refinement phase, especially the excessive attention paid by the infrastructure that is called too XP. XP considers that creating infrastructure without any need leads to overly complicated solutions and the results created are of no value to customers. In RUP, the architecture is not equivalent to the infrastructure.

The methods used to create a framework in RUP and XP are completely different. It is recommended that you focus on the architecture to avoid the spread of time-based scope, increase the project scale, and the risks brought about by the adoption of new technologies. XP uses an existing architecture that is simple enough or easy to understand and can evolve with the code. XP recommends that you do not design for tomorrow, but for today. XP believes that if you try to keep the design as simple as possible, it will be easy to manage in the future. RUP wants you to consider the risks brought about by this claim. If the system or part of the system has to be rewritten in the future, XP believes that this initiative is more wise and less costly than planning it now. This is true for some systems, and the same conclusion will be drawn when you consider risks in the Refinement phase when using RUP. RUP does not consider this to be true for all systems, and experience suggests that it may be disastrous for systems that are larger, more complex, and have no precedent.

Although spending too much energy on the possibility of the future (which may never happen) may be a waste, it is a smart move to focus on the future. How many companies can afford to constantly rewrite or even refactor code?

For any project, you should complete at least these three activities in the Refinement phase:

Define, verify, and set the baseline of the architecture.Use the risk list to develop an alternative architecture from the initial stage. We are concerned about ensuring that the software in concept is feasible. If the selected technology has no novelty or complexity for the system, this task will not take too long. If you are adding content to the existing system, this task is not necessary if the existing architecture does not need to be changed. However, when architecture risks occur, you do not want your architecture to "take chances ".

As part of this activity, You may select components and make a decision to buy, create, and reuse components. If this requires a lot of work, you can divide it into separate activities.

Refined view.In the initial stage, you developed a view. Because you need to determine the feasibility of the project and the stakeholders have time to check and evaluate the system, you may need to make some changes to the view documents and requirements. Modifications to views and requirements are generally made in the Refinement phase. At the end of the Refinement phase, you have a deep understanding of the most critical use cases for building and planning. Stakeholder needs to be recognized. In the current architecture environment, the current idea can be realized as long as the entire system is developed according to the current plan. In subsequent iterations, the number of changes should be reduced, but you may spend some time managing requirements in each iteration.

Create an iteration plan for the build phase and set a baseline. Now you can fill in details for your plan. At the end of each build iteration, you can reconsider the plan and make adjustments as needed. The adjustment process is often necessary, because the work to be done is often misestimated, the business environment will change frequently, and sometimes the demand will change. Set priorities for use cases, scenarios, and technical work, and assign them to the iteration process. At the end of each iteration, you plan to generate a work product that provides value to the stakeholders.

You can perform other activities in the Refinement phase. We recommend that you establish a test environment and start development and testing. Although the detailed code is not complete yet, you can still design the test and maybe you can implement the integration test.ProgramPersonnel should be ready to perform unit tests at any time and learn how to use the test tools selected by the project. XP recommends that you design the test content before writing the code. This is a unique insight, especially when you add content to an existing code body. However, no matter how you choose to perform the test, you should establish a regular test system in the Refinement phase.

The detailed phases described in the RUP include the research and investment phases in XP. XP handles technical risks (such as novelty and complexity) by using a "spike" solution, such as spending some time experimenting to estimate the workload. This technology is effective in many cases. When a large risk is not reflected in a single use case or "story, you need to spend some time ensuring system success and accurate workload estimation.

In the Refinement phase, you will often update the artifacts, such as the requirement and risk list for the initial phase. Possible artifacts in the Refinement phase include:

Software Architecture Document (SAD ).Sad is a composite component that provides a single source of technical information for the entire project. At the end of the Refinement phase, this document may contain a detailed introduction, describe important use cases in the structure, and determine the key mechanisms and design elements. For projects that enhance the existing system, you can use the previous sad, or decide not to use this document if you do not think it brings any risks. In all cases, you should think carefully and record it in the document.

Build an iteration plan for the process.You can plan the number of iterations during the Refinement phase. Each iteration has specific use cases, scenarios, and other assigned work items. This information is reflected in the iteration plan and baseline is set. The review and approval plan can be part of the exit criteria for the Refinement phase. For very small short-term projects, you can merge iterations in the refined phase with the initial and build processes. Key activities can still be carried out, but the resources required for Iteration Planning and Review are reduced.

Build phase

The goal is to complete system development. In a sense, the construction phase is a manufacturing process. The key task is to manage resources and control operations to optimize costs, schedules, and quality. In this sense, the management philosophy should be transformed from the development of intellectual property rights in the initial and refined stages to the Development of deployment products in the construction and delivery stages.

XP focuses on the build phase. The Build stage is the stage of writing product code. All stages of XP are designed for planning, but XP focuses on building code.

Each iteration In the build phase has three key activities:

Manage resources and control processes.Everyone needs to know their work content and time. You must ensure that the workload does not exceed your capacity and the work can be carried out as planned.

Development and testing components.You can build components to meet the needs of use cases, scenarios, and other functions in iteration. Unit Test and integration test.

Evaluate the iteration.When the iteration is complete, you need to determine whether the iteration target has been reached. If not, you must reprioritize and manage the scope to ensure that the system is delivered on time.

Different types of systems require different technologies. RUP provides different guidance for software engineers to help them create appropriate components. The requirements presented in the form of use cases and supplementary (non-functional) requirements are sufficiently detailed to allow engineers to carry out their work. Several activities in RUP provide guidance for designing, implementing, and testing different types of components. An experienced software engineer does not need to view these activities in detail. Engineers with less experience can get a lot of help through best practices. Each team member can study the process as needed or just take a look. However, they all refer to a separate process knowledge base.

In XP, "story" drives the implementation process. In the book eXtreme Programming installed, Jeffries and others think that "story" is a programmer's "promises for conversation ). Continuous and effective communication is of great benefit. Although it is always necessary to clarify some details, if the "story" is not detailed enough so that programmers cannot complete most of their work, it can be said that the "story" is not ready yet. Use cases must be detailed enough to facilitate implementation by programmers. In many cases, programmers can help write the technical details of use cases. Jeffries and others believe that sessions should be recorded in the document and appended to the "story. RUP also agrees that, in addition to case specification descriptions, informal forms can be used as needed. The result of capturing and managing sessions is a task that you must manage.

XP's strength lies in the construction phase. For most teams, there is a "crystallization of wisdom and guidance" that applies to them ". The most notable practices in XP include:

Test-programmers constantly write and test the code. The test reflects the "story ". XP advocates writing tests first, which is a good practice because it forces you to deeply understand the story and ask more questions where necessary. You must write a test before or after writing the code. Add them to your test package and ensure that the test is run every time the Code is changed.

Restructuring-constantly restructuring the structure of the system without changing its behavior can make it simpler or more flexible. You need to determine whether there is a good practice for your team. The difference between simple and complex judgments varies from person to person. In this example, two very intelligent engineers in a project rewrite each other's code every night because they think the other party's code is too complicated. This produces a side effect, that is, they always interfere with the work of other Members the next day. Testing is helpful, but if they do not fall into code contention, the team will be better off.

Pair Programming-XP believes that Pair programming can create better code in a shorter time. There is evidence that this is correct. If you follow this practice, you need to consider many cultural and environmental factors. Are programmers willing to try this? Can your physical environment meet this situation? Is there enough space for two programmers to work effectively in a separate workstation? How do you deal with programmers working remotely or elsewhere?

Continuous integration-the integration and construction work must be carried out continuously, and may be performed more than once a day. This is a good way to ensure the code structure is complete, it also allows continuous quality monitoring during the integration test process.

Collective code ownership-Anyone can modify any code at any time. XP relies on the fact that a good set of unit tests reduces the risk of this practice. Let everyone figure out the benefits of everything. Isn't it limited to a certain scale-is it 10 thousand lines of code, 20 thousand lines of code, or must it be less than 50 thousand lines?

Simple Design-with the reconstruction process, you need to constantly modify the system design to make it easy to change. Again, you need to determine the extent to which the work is appropriate. If you spend the necessary time designing the architecture during the Refinement phase, we believe that a simple design will be completed quickly and become stable.

Code standards-this has always been a good practice. Standards do not matter, as long as you use them and everyone recognizes them.

Both RUP and XP think that you must manage (and Control) iteration processes. Metrics provide better plan information because they help you select what is best for your team. Three things need to be measured: time, size, and defects. In this way, you can obtain all types of statistics you are interested in. XP provides you with simple metrics to determine progress and predict results. These measurements are centered on the number of completed "Stories", the number of tests passed, and the statistical trend. XP provides a good table rate for the use of the smallest number of metrics, because too much viewing does not necessarily increase the chance of project success. RUP provides you with guidance on what you can measure and how to measure, and provides examples of measurement standards. In all cases, the measurement criteria must be simple, objective, easy to collect, easy to express, and easy to misunderstand.

What artifacts will be generated during the iteration of the build phase? Depending on whether the iteration is in the early or later stages of the build phase, you can create the following artifacts:

Component-the component represents a part of the software code (Source code, Binary code or executable programs), or files containing information, such as a STARTUP file or a ReadMe file. Components can also be aggregated by other components, such as applications composed of several executable programs.

Training materials-if the user interface of the system is complex, compile the first draft of the user manual and other training materials as soon as possible based on the case.

Deployment Plan-the customer needs a system. The deployment plan describes a set of tasks required to install, test, and effectively deliver products to users. For a web-centered system, we have found that the importance of the deployment plan has increased.

Delivery phase iteration plan-you need to complete and review the delivery phase iteration plan near delivery.

Is the code complete?

Code is designed and designed, that is, code. The code is always consistent with itself, which is absolutely true. We think that it is worthwhile to design and communicate with each other, not just to create code. The following small story will illustrate this point.

The differences between RUP and XP include different aspects in addition to building the architecture. One of them is the communication mode about design concepts. XP

An engineer has had two such software project experiences. The design is embodied in the Code and the design information can only be found in the Code. Both projects are about compilers: one is to improve and maintain the optimization program for the ADA compiler, and the other is to port the front-end of a compiler to a new platform, connect to a third-party code generator.

Compiler Technology is complex, but it is also widely known. In both projects, the engineer wants to have an overview of the design and implementation of the compiler (or optimization program. In each case, he received a bunch of source code lists about several feet thick and was told to "view this information ". He should have been provided with some support text to build a good graph. The optimization program project is not completed. However, the compiler project is indeed successful, and the code quality is very high due to extensive tests in the code development process. The engineer spent several days studying the code in the debugger to understand its role. Personal losses are still the second, and the cost of team losses is even less worthwhile. We did not complete the development in 40 hours as shown in xp. Instead, we spent a lot of personal efforts to complete the work.

The main problem only caused by code development is that no matter how well the code documentation is written, it does not tell you the problem to be solved. It only provides a solution to the problem. Some Requirement documents can still explain the original project objectives well after the initial users and developers continue to work for a long time. To maintain the system, you often need to understand the design objectives of the initial project team. Some advanced design documents are similar-the code is often not highly abstract, so no information can be provided to indicate what functions the overall system can implement. This is especially true in an object-oriented system, because it is difficult or even impossible to obtain the execution thread simply by viewing the class files in it. The design document guides you to view the content when a problem occurs later-problems often occur later.

This story shows that it takes time to create and maintain design documents. This reduces the risk of misunderstanding and accelerates the development process. The XP method is to spend several minutes to outline the design content or use CRC cards. However, the Team does not advocate this, but only code development. They have an implicit assumption that the task is simple and we already know how to proceed. Even if we successfully complete the task, the next new employee may not be so lucky. It is recommended that you spend more time creating and maintaining these design artifacts.

Delivery phase

The focus of the delivery phase is to ensure that the software is available to end users. The delivery phase includes product testing for release and minor adjustments based on user feedback. At this point in the life cycle, user feedback focuses on precise product adjustment, configuration, installation, and availability.

Early release and regular release are good methods. But what is the purpose of publishing? XP does not clearly explain this problem, nor does it handle the issues that must be created to release commercial software. In internal projects, you can find shortcuts to solve these problems, but even so, you still need to edit documents, staff training, and other work. What about technical support and change management? Is it feasible for on-site customers to control such content? Bruce Conrad pointed out in his XP InfoWorld comment that software that users do not want to get is constantly changing. You must weigh the benefits, disadvantages, and possible instability of the quick change software.

When you decide to publish, you must provide end users with more things than the code. Activities and artifacts in the delivery phase will guide you through this part of the software development process. These activities mainly aim to provide available products to your customers. Key activities in the delivery phase are as follows:

Determine end user support information. This activity is simple. You only need to provide a list. However, make sure that your organization is ready to provide technical support to customers.

Test deliverables in your environment. If you can simulate the user environment within the company, it is best. Otherwise, go to the customer's company to install the software and ensure it can run. You certainly don't want to awkwardly answer the customer: "But it works very well on our system. "

Precisely adjust the product based on user feedback. If possible, plan one or more beta testing cycles when you deliver software to a limited number of customers. If you perform this test, you need to manage the beta test cycle and consider the customer feedback in your "closing work.

Deliver the final product to the end user. For different types of software products and release versions, many problems related to packaging, manufacturing, and other products need to be addressed. You certainly won't just copy the software to a folder, and then send an email to the customer telling them that the software is in place.

Like other stages, the process format and complexity are different. However, if you do not pay attention to the deployment details, it may result in weeks or months of good development work to be abandoned, and thus the failure to enter the target market.

You can generate several artifacts during the delivery phase. If your project involves future release (How many projects are not involved ?), Then you should begin to determine the features and defects for the next release. The following artifacts are critical to any project:

Deployment Plan-completes the deployment plan that begins with the build phase and uses it as the delivery roadmap.

Version note-it is a rare software product that does not contain commands that are critical to end users. You can make plans for the annotations in an available and consistent format.

Delivery Phase Information and Documentation-this type of information can take many forms. Can you provide all the content online? Will you provide guidance? Is your product help complete and available? Do not consider what you know, as do customers. Your success lies in helping your customers succeed.

Conclusion

Building software is far more than writing code. A software development process must focus on all the necessary activities to publish high-quality software to users. A complete process does not have to be huge. By focusing on the main activities and artifacts of the project, we have shown you how to perform a small but complete process. If it is helpful to execute an activity or create an artifacts to mitigate risks in the project, proceed. You can use more or less processes and formats for your project team and organization as needed.

RUP and XP do not have to be mutually exclusive. By combining these two methods, you can get a process that helps you deliver higher quality software faster than you do now. Robert Martin describes a process called dx, which serves as an accessory to the RUP. It is an example of a process built from the RUP framework.

Industry-proven best practices can be used for an excellent software process. Best practices have been used in real software development organizations and have been tested by time. XP is a widely used method. It is code-centric and provides a commitment that maximizes productivity with minimal process overhead. Many of XP's technologies are worth considering and adopting when appropriate.

XP focuses on "Stories", tests, and code-It discusses the plan in depth, but does not elaborate on how to get the plan. XP means you can do other work, such as "using some cards for CRC design or drafting a UML ...... "Or" Please do not generate documents or other artifacts that are not used ", but it is just a hyphen. RUP wants you to create useful and necessary things and point out what these things are when creating and updating development plans.

RUP is a process that can process the entire software development cycle. It focuses on best practices and has been baptized by thousands of projects. We encourage research and development of new technologies to produce best practices. As new Best Practices emerge, we want to incorporate them into the RUP.

Appendix: Rational uniied Process

Rational Unified Process, or RUP for short, provides a regular method for software development. It is a process product developed and maintained by IBM rational. It provides several plug-and-play roadmaps for projects of the same type. RUP also provides some information to help you use other rational tools during software development, but it does not require that rational tools be effectively applied to the entire organization, you can also integrate Rational Tools with products from other vendors.

RUP provides guidance for all aspects of the software project. You do not need to perform any specific activities or create any specific artifacts. It only provides you with information and guidance, and you can decide what to apply to your organization. If no specific roadmap is available for your project or organization, RUP also provides guidance to help you customize your process.

RUP emphasizes the adoption of some best practices for modern software development as a way to reduce the inherent risks arising from the development of new software. These best practices include:

1. iterative development

2. management requirements

3. Use a component-based architecture

4. Visual Modeling

5. Continuous Quality verification

6. Control Changes

These best practices are integrated into the following definition of Rational Unified Process:

Role-the series of activities executed and the artifacts owned.

Discipline-key fields in software engineering, such as requirements, analysis and design, implementation and testing.

Activity-define the way the artifacts are generated and evaluated.

Artifacts-work products used, generated, or modified during execution activities.

RUP is an iterative process that determines the four phases of any software development project. As time advances, each project must go through the initial, refinement, construction, and delivery phases. Each stage includes one or more iterations, where you can generate executable files, but the system may be incomplete (except for the initial stage ). During each iteration, you perform activities in several disciplines at different levels of detail. The following is an overview of the RUP.

RUP Overview

The book the rational uniied process, an introduction, and second edition is a good overview of RUP. You can find further information on the rational web site www.rational.com and evaluate the RUP.

Appendix: Extreme Programming

Extreme Programming (XP) is a software development discipline developed by Kent Beck in 1996. It is based on four values: communication, simplicity, feedback, and courage. It emphasizes continuous communication between customers and development team members and sets up an on-site customer in the development process. The on-site customer decides the creation content and sequence. By constantly refactoring the code and creating the smallest set of non-code artifacts, this is simple. Many short-term releases and continuous unit tests have established feedback mechanisms. Courage means doing the right thing, even if it is not the most popular thing. It also means to be honest with what you can and cannot do.

12 XP practices support these four values. They are:

Planned Development: determine the functions of the next version by combining the priority "story" and technical estimation.

Minor version: software is often released to customers in small incremental versions.

Metaphor: A metaphor is a simple, shared "story" or description that describes how the system works.

Simple Design: The design is simple by keeping the code simple. Constantly search for complex points in the Code and immediately remove them.

Test: You can write test content to test the story. Programmers write test content to discover any problems in the code. Write the test content before writing the code.

Refactoring: This is a simplified technique that removes repetitive content and complexities from code.

Pair Programming: two members of the team use the same computer to develop all the code. One person writes code or drives, and the other person reviews the correctness and comprehensibility of the code at the same time.

Collective code ownership: Anyone owns all the code. This means that everyone can change any code at any time.

Continuous integration: You can create and integrate the system multiple times a day, as long as any implementation task is completed.

40 hours per week: programmers cannot guarantee the maximum efficiency during fatigue. It is absolutely not allowed to work overtime for two consecutive weeks.

On-site customer: a real customer works in the development environment full-time to help define the system, write test content, and answer questions.

Encoding standards: programmers adopt consistent encoding standards.

There are currently three books describing XP:

1. Extreme Programming (explained)

2. Extreme Programming implementation (eXtreme Programming installed)

3. Planning eXtreme Programming)

Some web sites also have further information about XP.

References

• For more information, see the original article on the developerworks global site.
  
  

About the author Gary pollice