This article is a series of articles (as listed below) in a distributed, J2EE-based project (as listed below).
Part 1: Project introduction; high-level plans Part 2: Risk management; requirements management Part 3: Model creation and access control; demand analysis Part 4: Use example refine; production report; tools and technology Section 5 : System architecture and design Part 6: Detailed design; early development; two-way engineering; early unit testing Part 7: Continue development; early construction; demo Part 8: unit test strategy; function test; GUI test script Part 9 : System construction and testing; defect tracking; product delivery Part 10: Project is completed; conclusion; future work
In this article, we are a software company Lookoff Technologies Incorporated, our customers AudioPhile Speaker Design, Inc. (ASDI), which hires us to achieve their initial IT needs. For more detailed information, see Part 1.
The last part of this series of arts discusses some remaining little things that end the ASDI project needed. We have passed the acceptance test, and the system is now ready to hand over to ASDI (delivery and maintenance). At the end of this article, we come to discuss our discussions in the project, and hope to learn from our work in this project's work to learn some experiences and lessons.
Part 10 Snapshots in Part 10 Demo Tools and Techniques:
Rational ClearQuest - Problem for tracking and managing issues in the initial real world use and maintenance:
ClearQuest Defect Database - Updated to track any new ideas or inappropriate requirements identified at this stage
Project delivery is now the time to deliver the first phase of the project to the customer (and decide if there will be a second phase). We deliver the system to ASDi and help them install the system on their site. They immediately start testing system through real-world use, starting input management and configuration data and transplanting their expected "partial" section list to the system. They also do their best to enter orders and generate some reports. The system is running normally, and the customer is very happy, and all of our remaining work is to maintain the system.
Maintenance Because our sum is the work that includes all parts of the system, there is no formal guarantee period. ASDI only proposes some new ideas or uncomfortable demands, and we submit these questions into the Rational ClearQuest Defect Database. Because we don't have a web interface for the Rational ClearQuest, the customer's input is communicated with us through a hard copy. Although this process is working very well for system changes made throughout the development analysis phase, it is proven to be heavy in maintenance phases; our first choice is to let customers access our database. Second problems are discussed and confirmed by a conference call, while other issues have been postponed until we agree with the scope, impact and implementation plan of project maintenance.
ASDI has no infrastructure or resources to maintain the software system itself, so we have retained development and testing environments in our company. This is also meaningful, because if ASDI decides to continue the second phase of the project for this project, the decomposition of our environment will be a waste of time and resources.
We modify the software on our site and will build a good system to give the customer. This is a little awkward arrangement, because we still have allocated resources into the project in full-time, but in this project maintenance, there is not enough job to ensure full-time work in engineering and integration and test teams. . However, because ASDI does not have suitable personnel, software or hardware to perform their own maintenance, this arrangement must last for a while. There is a rough assignment during the first phase of the maintenance period of the first phase:
50% of new features request 40% availability issues, 6% of BUG 3% requirement for new or changed tips, messages, menu, etc.
Most of the questions are in the "Good View" category, such as changes that make it easier to use, but they are not critical. For example, there is a region on the user interface of the system, where the term in the ASDI service domain is incorrect or the letter spelling error. The ideal situation is that these issues are picked out in early reviews, but there is always difficult to pick out all errors in the first review.
A large number of requests for new features reflect this is an unfinished product - a natural result of the user displaying the system from one start to the project. Because the first phase of the project is just a conceptual verification system, our purpose is to verify the functionality of the system, and our large number of work is done around this purpose.
Unimportant bugs remaining in the system are not a big contradiction with demand, they are in comparative underlying incorrect implementation. These issues include some rounding of the incomplete values generated by the system in the financial data report.
We don't have to worry too much about the mistakes on demand. Our analysis is very thorough, but remembering two things is important:
The actual situation of ASDI is to evaluate this conceptual verification system as a real-world system, and we only discover a small number of questions on us, and we are a huge victory for us. Most demand errors are small and easy to fix. In many cases, update use cases and related documents take more time than modifying the code itself.
second stage? There are some discussions about whether or not, and how asdi continues the second phase of this project. There are some views in discussion:
Some operators using the system will not use the computer, and they can use the old way to do things. Some operators who like new systems want to use it. The external B2B interface is not very mature, completely automated or bundled a diversified platform. In the current situation, ASDI does not distribute these libraries and APIs to them. The first phase is good to control within the budget, so we have the second phase of the project in the time and budget. ASDI's technical leaders think they should do their own work, although they don't have enough people who can support this work. ASDI has transplanted all of their data to the first phase of the system, and worrying that this work will be repeated in the second phase of the project. ASDI believes that although some things can prove that the second phase of the project can be more efficient than the first phase, the effectiveness of exceeding the old system obtained from the first phase system may be sufficient.
When we initially plan the first phase and the second phase, we know that we will eventually face this intersection. Some of the above problems have become a result of a refined prototype created at the end of the first phase, and when you expect in a conceptual verification system, there are some parts that do not have product quality. As mentioned above, the B2B interface provided to the enterprise batch operation provided to ASDI has not been fully implemented. Many requirements for new features are recorded in the ClearQuest database and is set to a wait state. The user document is not sufficient, there are some task operations instructions for the operator.
We pointed out some qualitative evidence prove that if we continue the second phase of the project, the output system will be more efficient than the system produced in the first phase. Many features will be added to the second phase - such as the ability to support data entries by integrated with the database, not through the command line interface - this will undoubtedly mean higher efficiency. At the same time, ASDI's project manager feels that the current system has great improvements. When we show it to the company, we can rename it from a "beta" version "full version 1". Finally, ASDI agreed to continue playing the role of system maintenance, although ASDI guarantees at least from us to employ two full-time personnel (a developer, a tester), while other support can be by phone Implementation. After ASDI has more data on their own financial situation and clearer understanding, they decided to postpone the second phase of work until a relatively rely.
Observing that we have learned a lot of things from this project because this project is our first exploration in several new technologies. As our first extensive practice RUP, it provides us with a series of project observations and ideas for the process.
During this project, our relationship has a very good relationship with ASDI. After so many years, we found that it is good communication with a good relationship with our customers, and the visibility of the project progresses and has practical proposals. The only tricky problem with ASDI is that they initially expected the project to be strictly carried out in accordance with the development method of the waterfall type. This is very different from our operational projects, and there is a huge difference with the RUP method. Finally, we can perform we feel that it is necessary, and try to show the ASDI to the Structure of the waterfall type method to meet their needs.
Customers have changed approximately one-third of the route throughout the project. Although the change is not strong (see Figure 1), it also caused some transformation from the initial SOW. We can use Rational RequisitePro to track the needs, but they have the impact on the entire system.
Figure 1: Changes on the project range
The change above the range adds some features of the function, but it also deletes the area of other features. When the importance of the B2B interface is lowered, the importance of the operator screen is increased, and we think this is a safe and wise decision for ASDI. Although we have already given a command (and budget) to implement and test a secure B2B interface, ASDI realizes that the maximum value they spend money is in data integration, web-based data entrance, report, and order management. . This is not only to help Asdi sell our potential users to use the system's idea, but also provide immediate results (do not require them to wait for business partners using B2B interface).
In our team, the confidence of ASDI is constantly changing in the cycle of the project. This very subjective estimate of this is shown in FIG. 2, the primary point in the confidence curve is corresponding to the label of the label listed in the drawings below.
Figure 2: Customer confidence
Confidence is quite high; ASDI is based on our name and proposal to grant us and about. In the early stage of the project, with the proposed schedule, we are concerned about the process of unfamiliar symbols and the process of analyzing and designed heavy work, and some fear. We conducted a lot of explanations and statements to convince their approach to our way. When prototypes and detailed analysis meetings, ASDI has become more satisfying with our progress. They also became the main contributors of review and analysis process, and they were undoubtedly a very valuable member of the team. This leads to more visibility to buy and increase project progress, and also add confidence to ASDI. When we still do not enter the implementation phase, and spend a lot of time in class diagrams, prototypes, scenes, etc. Sell. Take a look at the time schedule, ASDI is very worried that we have used half of the time, but still in detail. The team began to enter an efficient product phase, and ASDI saw fast results. We quickly build software, our demo is an impressive, and how we perform the logic and value of our initial and refinement phases look more obvious. When the frequency and maturity of the demo increase, ASDI continues to be satisfied with the work we did. Although there have been some technical problems during the process, it is clear that we have enough time to solve the defects and the remaining tasks. When ASDI starts using system versions generated in their site, they continue to be satisfied with the product. We can easily solve the new problems they put forward in our own maintenance and test environments. Process Our previous project draws on some of the incremental and iterative contents of some RUP, but this project is our first truly large-scale implementation RUP. We don't have completely moving RUP content, because we want to avoid the risk of the project team through the "process work" brought about too many new steps.
Rational's tools can help us understand RUP and online RUP documents is also very valuable. RUP's documentation provides us with excellent policy suggestions in every step of implementing RUP's road, and RUP's tool guidance also helps us understand how each tool in Rational is applied.
One of RUP is that it is concerned that it is reduced. Iterative methods, early prototypes, demos, and large number of customers involved, all of which can help reduce the risk of the project. We feel that the risk of our project is compared to the path comparison in Figure 3 (the corresponding label entry is below). Note that this picture is not a graphic, just a label that is identified. Obviously, a project is the biggest risk at the beginning, because the unknown is always in front; at the beginning of the project, you almost rarely know what is all the risks of the project.
Figure 3: Project risk
Project risks are the largest at the beginning of the project. Until we form good work relationship with our customers, our core technologies can verify our estimate, we still expose a lot of risks that can cause damage to our projects. Through this, we work closely with ASDI, and their concerns have been relieved to the process, and we have created many early prototypes, which guides our technical selection of system architecture. When the technical leadership of ASDI began to push an object-oriented database scheme, we are worried about the introduction of this new technology. Further prototype helps us persuad ASDI and our confident relational database is the safest route. Additional design and architecture, as well as early development can help us reduce risks. We have a clear technical solution that is more reliable and we feel that the time plan they can do. After the midway of the construction phase, some new technical issues have hindered our progress. These issues are some low levels; they only affect estimates at class and module levels and will not endanger any overall clues or subsystems. For the remainder of the construction phase, there is a relatively clear route because the technical solution is obviously reasonable, and the progress is also accelerated. At this time we have implemented the customer's acceptance test, there are very few questions in the acceptance test, and ASDI is also satisfied with the product. Technical and Tools All the techniques selected for the architecture are executed in accordance with expected. Early prototypes in the initial and refined phases help us confirm the choice of these technologies and give us a good start in training, API familiarity and development.
Recalling, we are very happy that we have adopted the route using the IBM DB2 database. When we face the pressure from the object-oriented database into the architecture, we conduct a careful evaluation and comparison of an option, and can demonstrate the object-oriented database actually not safe enough, or There is also a better choice on the product.
Ratioanl's tools provide a series of benefits on our old way. We may be able to deliver products that meet the needs under the same budget. We have a new way to compare new methods from three aspects: availability, quality and performance.
The system is more available because ASDI has been closely involved in many iterations and systems build. Frequent demonstrations, extensive analysis stages, and intervention of usability experts contribute to the ease of use of the final system. In fact, the operator can use the system without an online document or user manual. The system has higher quality than the system we deliver. Not only our defect rate is lower, but the architecture and design are also outstanding. By carefully assessing the assessment of architecture and design, we have discovered a series of problems in the early stage of the project, and usually these problems will be discovered during the implementation phase. We now think that the design phase is a valuable prototype and risk reduction form, and we don't have a quick jump to the implementation phase. Use two-way engineering to ensure that synchronization between design and code is very useful. The system is more consistent and reliable than previous products. More than just high-efficiency initial and refinement phases, it is more successful in building a robust system, but our design is more successful. Because our data modeling in Rose has been strictly reviewed, even our model is very efficient and accurate. We properly lay out of data access, simplifying the optimization of queries (data access in previous projects sometimes mix in business logic). In the end, we gain huge benefits from the Rational test tool. Rational Quantify enables us to identify bottlenecks, Robot and Siteload to test software under extremely high load to ensure that the system can respond to worst conditions.
Team Productivity Team has been working together, so there is a good morale, communication and collaboration between team members. This allows them to put more energy on projects and learn new tools.
We have found that tracking team productivity is interesting in the process of project. Although we are not a metrical fan, such as the code line statement (Slocs), but in this example, it is indeed interesting. In our previous project, under the same amount of money, we can write more code; however, in those projects, we have never provide so many features in those projects. Therefore, even if we do a better job, our SLOC metrics seem to be lower. We will attribute this to have a more clear design, better use and very small rework. The engineering team also felt the pressure of time, so they can spend some time to reconstruct the code before the code review. Figure 4: Team productivity
There is no activity in the early stage of the project. We just start building our basic hardware and even don't know what kind of tool we will use. We start to create prototypes in the early stages of the project to help us identify some technical and software development tools used. When we will focus on detailed analysis and early architecture, this will have few coding work, any written code will be discarded after you want. Once we entered the refinement phase, we start refining and aim at the original shape, which will help us reduce technical risks and help us do design decisions. There are some code here that can be reused in the implementation; however, the early most code in the refinement phase is abandoned after the purpose of the risk reduction. During the construction phase, the engineering team focuses on building a system and is the most efficient implementation. The entire construction phase engineering team left a large number of extreme performance tests. The integration and test team perform some non-coding work, which allows the engineering team to concentrate on the construction system until the end of the construction phase. At the end of the construction phase, the engineering team must only modify the defects displayed in the test and update residual build and test documents. Finally, the output of engineering team coding has declined significantly.
Ending This section summarizes this small J2EE-based fictional project with RUP and other Ratinoal. This series shows a project that can adopt a multi-possible path of Rational tools and procedures. This special path includes the simplicity of maintaining things and trying to have every technique and tool before deciding. The team did not try to master RUP and all Rational tools in a separate project, but a stable, disciplined approach to Rational processes and tools.
Project technology, team structure and time plan is very beneficial to merge RUP and other tools without hindering progress. The situation in your project may be different, because the combination of the technology you use may be more efficient or inefficient than this article. For budgets that can give them, some training opportunities can help introduce Ratioanl tools into the project. You shouldn't have this feeling - these tools are the "silver bomb" that can save your project, they just enable the team to work more.
Remember this article is not an explanation of any actual project we have worked before, although it is based on my experience in actual projects. The new technologies described and some Rational Tools still cannot be obtained for many of the projects I do. Also note that I don't agree with many decisions made in the ASDI project, but I wrote them to the article to demonstrate and develop different ideas.
I agree with this article: formal, modern software engineering tools and processes can bring excellent productivity and quality for a software project. Although I have to be vigilant about "silver bomb syndrome", I still have been looking for a way to simplify work. A series of tools for Rational can do this, and these tools are well integrated and even available.
