Part 4: Progress in analysis and tools
Steven Franklin Software Designers and Process experts in April 2004
In this next phase of the sample items used by RUP and other Rational tools, the use of examples are refined by adding documents and traceability to demand, and tools and technologies used are evaluated and selected.
The focus of this section 4 is in the refinement phase of the ASDI project, especially in use case analysis (refining our use cases to add trackerability, and standardize and generate example documents) and select appropriate Tools and technology.
Part 4 Snapshots in Part 4 Demo Tools and Techniques:
Rational Rose Enterprise Edition - Tools Rational RequisitePro for the Customer Checking Rational Soda - Tools for Managing Customer Rational RequisitePro - Managed Trackability between SOW Demand and Use Examples Or being updated:
Rational Rose Model - Changed and add more detailed content use case reports in all aspects of the use case - Generate the REQUSITEPRO database from ROSE using the ROSE-Updated to include SOW requirements and use cases
Adding and Documentation Approach Figure 1 shows the evolution of the use case in the first phase of the ASDI item (initial and refinement phase) of the ASDI item. As we discussed in Part 3, we created business use cases in the initial phase, and then transition business use cases into an example of the "current" system in the initial stage of the refinement phase. Now we are the most intense moment in the refinement phase, we are preparing to refine our use case, and complete the conversion of the system to detailed needs. This evolution is naturally formed, because until it is determined whether the use case we start defined is correct, we can add more detailed information for the use case. Once the detailed system demand is completed, we will be reviewed as a formal delivession by ASDI.
Figure 1: Evolution of the first stage
The standardized use case document we annotated in the conference we were informal with ASDI's informal inspections. The examples and packages are also regularly checked by our senior team members, a "sound" check will bring the following results:
Feedback unstable or omission feedback to the group leader useful analytical recommendations, mode and functional decomposition considerations Considering system view engineering team on detailed requirements
Our current focus is to record things we have learned. We agree with ASDI in the form of use case documents, and we are very happy that they are willing to accept ways to add documents directly in the ROSE model. This is a simpler for us, because this means lowering the beautiful expectations of documents.
In the case of multiple team members working together, we found that we need to standardize documents associated with each use case. Therefore, we drafted a document template for a use case and applied to each use case of the ROSE model. The content shown in FIG. 2 is a document window that is pasted into each use as a template. Note We use the term "variation" as a speed notger mark for RUP optional flow concepts in this template.
Figure 2: Used Document Template
Later in the project, we realized that there is a large number of ASCII forms in the model (* .mdl and * .cat) file, so that the load is slow down. Thanks to our fast computer, this side effect can also be tolerated, but in later projects we use more formal ways to maintain the content of the usage, through a custom interface (just like in article Fine Tuning Rose to Complement Your Process discussed there). Another optional method is to use ROSE with a separate Microsoft Word document to the characteristics of the use case (select the use case by right-click and select NEW> file from the context menu).
The traceability of use cases ASDI original expectations are SOW will eventually become a document in a large text. Through the continuous discussion with them, we finally realized the shortcomings of this method and made a concessional posture. They now understand the benefits of using the use case and soon understand the relevant concepts, and understand the use case will give them a very powerful and appropriate feedback of the model. In any case, a good time and energy distribution have entered SOW, you can understand that ASDI wants us to ensure that it will not miss anything captured in SOW.
In order to provide this guarantee, we use the Rational's tool to create trackability between SOW requirements and our fairly stable use case. First we associate the Rose model with the managed demand document through RequisitePro, and select SOW by selecting Tools> Rational RequisitePro> Associate Model to Project. Then we map each use case to the main SOW requirements, select Requirement Properties> New by right-clicking the case and select Requirement Properties> New in the context menu. As shown in Figure 3, we show a list of SOW requirements and select the appropriate needs.
Figure 3: Relevance requirements and use cases
We have established these associations in the model, we can track the needs of the needs, and the opposite is possible. Bidirectional trackability is important, so we can find out the need for omissions or find new needs. I miss a need for unacceptable, tracking needs to use cases can make us discover any of our missions. Adding requirements without clear adjustments will result in the spread of the project and have a negative impact on the time planning and budget of the project. In order to prevent all this, we should track all the SOW requirements or change requests that exist to each.
Unlike the tracking needs, the tracking of the opposite direction is often ignored, but we can easily complete this in Rose. To browse the SOW demand associated with an example, we are simple to right click on the Rose model and select Select View RequisitePro Association from the context menu. This will pop up a window indicating which SOW requirement is the selected case tracking, as shown in Figure 4. If the use case is not mapped to a SOW requirement, the two domains at the bottom will display "NONE". We can also produce more complex tracking reports through Rational SODA.
Figure 4: Sow requirements for a use case reported by Rose
Note It is important to use a shortcut in this method. Through the way we use, we can only associate a use case to a requirement, and vice versa; however, a use case is actually tracking back to several needs, the same requirement may be distributed into multiple usage. We don't have to distress multi-to-many relationships. We directly associate with the needs of the SOW, but a better way is to introduce a use case specification document managed by the RequisitePro, which contains many text descriptions of many use case requirements and multi-to-many mappings. (Detailed description You can find in Rational White Paper USE Case Management With Rational Rose and Rational RequisitePro.) We now think that the use case specification document is an important step we should not skip.
The inspection cycle of using an example document We understand that the frequent check cycle of documents will lead to endless cycles. End any document is difficult, because every time you read documents, check people often produce some new ideas. In an iterative method, the same "When the end" challenge will also appear in the software documentation and other tasks. In order to meet the concern about the end, we describe what we will do with the inspection cycle of the use case document, we work hard to borrow the concepts described in RUP (see Figure 5). Figure 5: Document check cycle map
Just as you can see, each of our documents has passed a series of iterations. For us to find a tool to support it, we find such a tool in Rational Soda, which allows us to generate documents other than ROSE models. Although it is tempting for direct modifications to documents, this will bring the risk of documentation and model. If you will put energy in one or more documents, a better way is to put energy in the model. In addition to the software user manual you develop, the model is almost the product that can continue to be referenced and maintained after the software is delivered.
By using SODA, it is simple to generate a report. For the customer's check generation case document, we select Soda Report from ROSE's report menu, which will have a list of report templates, as shown in Figure 6. From our choice of a Rup Use-Case Model Survey Template.
Figure 6: SODA report selection
Each template provides a default report (as a Microsoft Word document) accompanied by an empty part and the corresponding content form (TOC). Figure 7 shows the TOC we choose to report. We started with ASDI checking TOC and we viewed our use case to decide whether it would require appropriate cropping according to our needs in the report.
Figure 7: SODA USE-CASE SURVEY Report (TOC)
You may want to know why we worry about check TOC with ASDI before writing any actual content. We found this is an important step. Sometimes ASDI gives us a DID (data item description), which provides a TOC on formal delivery, but we find that it is useful to get information from ASDI (or internal team checkpoint) before starting enrichment. Sometimes we fill in every part to display the title we will refine, but there is almost no paragraph content in the first TOC check.
Subsequent article section discusses more detailed information about Rational SODA and template customization.
Refinement: Not just use cases in order to make life more difficult, ASDI expects us to create an example document before continuing subsequent tasks. We must remind them that the document will be "completed" by the software to be delivered, unless they do not want us to update when demand changes or new demands. We persuaded them, they would not be interested in the completed milestones or even confident milestones. However, they want to put a check mark to the next "detailed use case document" item, because it is very mature, we agree with this point.
The real challenge is to persuad all the activities of ASDI should be parallel, not all milestones are delivered in order. We use it as a routine focus in the early project, it is still not completely resolved. In order to let him meet some activities of the use case analysis, we have proposed these two views:
The simulation of the screen will simplify the needs of the demand and can be described in a wide range of times. There are no forward-looking prototypes, tools, installation, and training should not happen.
We are very happy ASDI agreed to simulate and prototype as a useful part of the analysis phase. This allows us to enter the architecture and tool selection problem before useful analysis is completed.
Choosing tools and technology tools and technologies have never been tight tasks, although it is often ignored. The team often selection according to the start of the cost, "small tool factors", curiosity or loyalty to tools and technology. Instead, they should consider production cost, reliability, training, team skills, and characteristic standards. Add some formal procedures during the evaluation process to ensure that the choice of tools makes the project-based rather than personal subjective comments. The official tool assesss a rare place in RUP is a team to pick off-the-shelf - also known as the Commercial Spot Supply (COTS) - Tools. It can be understood that one place in this process area is Carnegie-Mello Software Engineering (SEI), where cots-based systems initiative focuses on the choice of COTS products and adoption strategies. It is particularly interesting for SEI's Product Feature Checklist; although it is more concerned about the component and framework of the software system, many of them can also be used to select software development tools, web services, databases, and more.
Tool Selection Standard ASDI shows us that they feel that they will affect our tools:
They finally undertake the core development and maintenance team of the system contains 3 to 5 people. The system can be accessed by 4 to 7 internal users and 1 to 5 from 20 to 30 companies (although the future versions of the system will support thousands of people online users). Cross-platform technology is important because ASDI expects that this system is still available in a few years. Training for all technologies must be easily obtained. They strongly prefer Java-based solutions. They prefer OODB (object-oriented database) as data storage. The early versions of the system will run on the Linux system, although they will run on the Solaris system. Developers need to be able to use software on Windows 2000 machines. Performance is not an important challenge, as only a few users are interacting with the system at the same time.
Application Server Selection We have experience in the J2EE application server, so we are very lucky ASDI selection based on Java solutions. However, in our rapid assessment of computing techniques (mainly Microsoft .NET / DNA) after entry-level Web schemes such as Perl / CGI and PHP.
We unanimously discovered that Orion Application Server is a friendly and a cost effective development environment. There is a low-level aspect of Orion is the stability and support of the supplier. Companies that provide Orion products are very small and have the ability and reputation of WebSphere, a WebLogic or IBM. However, after discussion with ASDI's inspector, we agreed with the benefits of Orion's J2EE standard compliance to offset these risks. If the second phase is developed, careful development will ensure that we have a lightweight to port to other application server solutions. So we chose Orion - this means that this start-up cost is zero because ORION is free.
The web server selects Orion with a high-speed built-in web server, so the selection process of the Web server is also conclusively when ORION is selected. Its main competitor is apache. However, it is displayed on the Orion website to reach and exceed the Apache in some tests.
The selection of which database selection is not obvious. Databases usually do not perform high loads, but it needs rich feature support. For example, a complex data relationship requires a complete reference integrity limit. At the same time, the system must be running uninterrupted 24 hours, so we hope it has hot standby functions, replicates, other usability and fault tolerance features. Whether we will use all features will be decided later.
We think that PostgreSQL is just a candidate with a qualified open source. It has good ANSI SQL support and reference integrity, and as long as it is not too big to grow, it can maintain good performance. However, data storage requires more CommTed support from one vendor. In addition, we feel that PostgreSQL online support (such as user community discussions) is not enough. MySQL is actually a more popular open source database, but it lacks too many features (such as foreign key support). Then we go to the mainstream database: DB2, Oracle, and Microsoft SQL. We have a wealth of experience in Oracle, but the new processor unit price model is too expensive for our application. Oracle's basic load per MHz per CPU means that ASDI will endure high production environment costs unless they are willing to mount Oracle on a P-133 machine. Microsoft SQL is eliminated because it is based on a private platform. If you create a DNA-based solution, Microsoft SQL is naturally preferred, but is rarely selected for J2EE.
Finally, we chose DB2, our survey indicated that DB2 has very good support, powerful fault-tolerant features, failed price modes, and a collection of online users that are growing and trained. IBM's JDBC driver is high performance, and their personal version can be used for development teams. Unfortunately, we lack DB2 skills, which means that some training is needed during prototyping activities.
You may just want to know what happens about the choice of ASDI's preferred OODB. After passing the prototype and exploring the product, we quickly reached the conclusion, the benefits of using OODB are not enough to offset the risk it brings. About this more ideas, look at the following article references and other resources.
Integrated Development Environment (IDE) Select at this point, we don't want to use any high-end IDE products, there are several reasons:
We don't clearly clarify the prove to use Enterprise JavaBeans. The investment of IDE is expensive. Team members have already had their own choices. Because the time of the first stage is very tight, the learning curve brought by VisuaLage, such as IBM is unbearable.
Instead, we have mixed the following tools:
JCREATOR - Free Java-based IDE CodeGuide - Low Cost Ide Log4J - Simplified Server Debug Log Tool Jikes - Quick Strigual Java Compiler
Naturally, these tools can make up for the lack of testing, tuning, and code coverage by using Rational tools.
Summary At this stage we have seen the evolution of the use case (via trackability and documentation) and the use of the use case participating in ASDI, we quickly discovery that we are experts in the world. This is usually one of the biggest challenges in the software development project, so early and effectively establishing this relationship is true victory. Our concern is usually very good to ASDI. They quickly understand and agree to the RUP-based development process without spending too much energy. This is surprising that the development of the preferred waterfall type to finally achieve this sum. Many methods of iterative and incremental development encouraged by RUP are well adjusted, and ASDI also sees good.
We are fortunately the choice of tools is quite simple and is completed early in the project. Some of Rational's tools are used to save our time. In the previous project, we used Excel to manage requirements, but we found Rational RequisitePro to be a first-class and complete solution. In addition, Rational Soda reports can greatly reduce the cost of our documentation. Because this project is our first use SODA, we are very happy with ASDI to expressed satisfaction with standard SODA templates. Planning the future, we put the focus on the product related to the needs, and spend relatively spendless time to assess the technology and create prototypes to support tools. It is now important to disclose the system more complex fields by creating more challenging prototypes, and began to use tools in actual development. Will we use XML? If we use, what kind of interpreter should we use? What kind of safety mechanism do we need? Should we use Enterprise JavaBeans? I will have an answer like these issues.
In other words, it is time to transfer from the analysis to the architecture and design - as fast as possible, because most technical risks will appear in the next few weeks. We have a good function baseline containing a series of well-defined cases. It is important to avoid analyzing the driving force of paralysis and maintenance.
Main risks have no new risks to be identified; in fact, our risk list is shorter than before. Because ASDI agrees that this project OODB is not suitable, we will no longer have technical risk to be managed. They also relaxed our formal forms of our delivery and their expected structure, and they have not retained our RUP framework-based documentation.
On the issue of the remaining time and workload of our concern, when we increase the understanding of the required understanding and familiarity, we feel that the budget is more in line with the project. Further technology explores that do not doubt new challenges.
Quote and other resources
FINE TUNING ROSE to Complement Your Process Steve Franklin (Rose Architect, Winter 2000) Use Case Management With Rational Rose and Rational RequisitePro Rational Software (Rational White Paper)
