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 plan Part 2: Risk management; demand management
Part 3: Model Creating and Access Control; Demand Analysis Section 4: Use Case Refining; Equipment Report; Tools and Techniques Part 5: System Architecture and Design Part 6: Detailed Design; Early Development; Early Engineering; Unit testing Part 7: Continue development; early construction; demo
Part 8: Unit test strategy; functional testing; GUI test script
Part 9: System construction and testing; defect tracking; product delivery
Part 10: Project completion; conclusion; future work
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 seventh part of this series of arts is mainly concerned about the construction and demonstration of our continued development. These topics are only very simple in the Rational Uniform Process (RUP), because this topic has very much dependence on the essence of a particular project. How will you integrate and demonstrate your system on your client, project size and project risk.
Part 7 Snapshots in Section 7 Tools and Techniques:
Rational Unified Process (RUP) - Guidelines for Build and Presentation Plan are created or updated product:
Build and demo schedules for updates to code and design models during continuing development
Demonstration in the refinement and construction phase demonstrates in several points of the ASDI project, especially in the refinement and construction phase of RUP. However, constructing is an iterative process, integrating components that are developed, and as a small milestone for the regular part of tracking development process services, demonstrating more towards special goals. In our project, these goals depends on where the project progresses, and these goals determine the accuracy of the demo and his viewers. The demonstration may be based on the construction, or may not be (for example, they can be analog user interface), and the presentation may be inside the company, or for external users.
The target of the demonstration is in the refinement phase, and the presentation has the following goals:
Show the assessment results of Spot Supply (OTS) software products. Display the simulation of the user interface, show the sketch of the main screen, and sometimes display the workflow of the system. Manage customers' expectations by evolving very early demonstrations. Reduce the risk of architecture. Get the feedback from the analysis.
In the construction phase, the demonstration has some objectives:
Provide customers with progress information. The problem is recognized by using an interface at the early stage to reduce the integration of the subsystem. Avoid the integration of "huge system" and get the delivery system at the end of the project. The project staff's morale is encouraged by changing the team in a meeting in one or more subsystems.
In addition, early presentations provide practical guidance for the formal construction of the integrated and testers, formally constructing all demand and complete build documents, and more.
Internal Demo VS. External Demonstration The internal team is naturally less than the number of external demonstrations and costs. Whenever we show the software to the customer, we all want to avoid any faults when presenting to the customer, but this is not very important in internal demo checks.
The internal demo is usually performed in a week in the week, perhaps the time to take a moment on Friday afternoon. One or more developers working in a particular subsystem or thread during the demonstration can discuss their progress, showing their work schedule and discuss any problems they encounter, we can collect this information in the demo. Discussions inevitably accompanied by relevant programs, good ideas and consistency issues found by other team members. These demo requires little preparation - perhaps just non-modified buildings and quickly performs the built-in process to determine that the system can be accepted. Demonstrations will be very smooth, but we don't think of this phenomenon as a problem, because we know that it will refine them will mean the work of additional preparation and testing. External demonstrations have an increased formal standard. Because we want to maintain our customers' confidence, we don't waste their time, we follow such guidelines:
Use the agenda and other guidelines to communicate the demonstration goals. Ready to clear, clear test data collection. It is best to rebuild the plan (Schema) and code foundation from the version of the version of the resource repository. Generate scripts for demos. Execute an actual demo process with the team leader. Make sure that all engineering team members stop using any shared resources during the demo (especially those stored in the DB2 database). Demonstrates with an hour of time, which takes more than two hours of time for feedback and discussion.
These prevention measures seem to have some excessive, but we have found a customer presentation that will have little value and is a waste of time and project budget.
Build and Demonstration Table 1 lists the approval and demographic stages of the refinement and construction phase of the ASDI project:
Many of our demonstrations can be merged or can be in parallel with other meetings. For preparation demonstration, some build is necessary. The construction of our subsystems and the construction of local systems is "small build version", which is not very formal, and spend us very little time.
Type frequency Time Selection of RUP Stage or Demonstration Select Refining Phase Tool Evaluation Prototype A OTS Product Evaluation Delivery User Interface Simulation Each GUI Take Each GUI has an early and refined stage of the use case analysis Activity. The prototype is once, and the performance requirements are met. Software Architecture Document (SAD) Delivered before the construction phase user interface appearance twice, respectively design the original SAD delivery in the two weeks of implementing the primary SAD delivery, the component demo begins in the construction phase early subsystem to build a weekly entered construction The first to 2 weeks of subsystem demonstrations and the construction of local systems have entered the construction phase of 3 to 4 weeks of complete system build and system demo every month to enter the construction phase 4 to 6 weeks.
Table 1: Build and demo plan
There are many ways to perform demo. These methods seem to be quite obvious activities, but there are some novel ways to increase demo value.
Joint Application Development (JAD) Joint Application Development (JAD) basically includes intended to focus on all items in a demo place for a very concentrated and intense free discussion activity, typically include some demonstrations. We tried several JAD methods in our project, but we found that this method is difficult and produces some mixed results. The various references we have checked (there are two references "related resources" in the end of the article) have emphasized the importance of JAD arbiters. JAD arbiters should have high skills and vision, we think we have It can do better in this area.
In our project, Jad means collecting ASDI's problem, ASDI IT leadership, our senior engineers and project managers from both parties. We pay attention to the discussion of our design and user interface design (although not at the same time). Before the JAD meeting, we have provided a agenda arrangement that arbitrates arbitrators will conduct a guiding meeting from agenda. A lot of discussions were conducted in the conference, and a senior picture was drawn on a whiteboard. (We used a digital whiteboard, we can save and print the draws on this digital whiteboard, which is very time.) We also make a project team spend some time to record any support. Comment. We attempt to use the JAD method in two phases of the project: in the early refinement phase, for the role (Actor) and the use case requirements; and in the later refinement phase for the user application workflow and design (main Is a user interface design). Here we will turn to the latter of our example.
At this second JAD meeting, developers who made good at JSP and HTML in our project showed an early user interface simulation based on use case analysis and annotation. We spend 15 minutes in each screen interface, and those who participate in meetings in the event of a particular user interface and the overall interface, the displayed function and the navigation of the system are collectively discussed. When there is any suggestion, we discussed these recommendations on the spot. We will combine the results of the discussion together and learn these lessons in the process:
For developers, it is difficult to keep up with the recommended significant changes on your computer. We need to use a special quick build prototype tool, limit the scope of the proposal, or change from multiple developers in parallel. Arbitrators must be very late in the guidance of the conference process: having a sufficient technical background to follow discussion, but must also be outwarded to enable each person involved in a relaxed and natural atmosphere, and from a neutral angle Guide discussion. Arbitrators should not be responsible for tracking time. Instead, it should be paid by another person to pay attention to the tasks in the meeting and the control of the assigned time. If a topic exceeds the prescribed time, then this topic should be delayed to other times and discuss it. JAD meetings require a subtle balance in the scope of protection and time plan and encourage feedback and improvement.
Showing and explanation, we find that simple display and demographic methods are the most effective and easier management methods. Unlike the problem in a real-world JAD meeting, a small demo separate from about one week can give us time to consider the impact of the request, and we can propose solutions to the identified problems. If we have been approved to have additional JAD training, we may be able to compress a few display and unspecific demonstrations into one or two Jad meetings; maintaining effective collaboration in the same place to save our plan A lot of time.
The opportunity of customers actually operates With the progress of the construction phase, our system arrives at the customer to begin to operate it. As shown in Table 1, when the system presentation starts four to six weeks, we have entered the construction phase. During these presentations, we allow the ASDI to use the system. This not only gave them more participation in the project, but we also got the feedback from them, if they do not allow them to use the system, we will not be able to get these feedback. When the system is gradually maturing, ASDI spends more time on the system, and they provide us with free testing work and modify some problems in the early stage of product development. However, there will be certain risks accompanying access to an immature system that allows customers to freely access:
If the system looks quite elegant from the appearance (that is, on its user interface), the customer may assume that all work has been almost completed. If the system looks very rough from the appearance (for example, the lack of error handling and stability), the customer may be uneasy to the progress of the team. When an earlier version of the ASDI operating system, we must constantly remind them that we are just in the first phase of the concept verification, and those "appearances beautiful" non-key features will be delayed in subsequent project work. However, we ensure that all their suggestions are recorded, because many of their ideas are very good, and we deserve our consideration in the next work. Typically, ASDI understands the intentions and restrictions of providing them with the opportunity to operate the actual operating system, so the risks mentioned above are not a problem for us.
The front VS. System of the system has spent some time to debate the advantages of the early demo creation system compared to the advantage of using an evolved product. Typically, the front is a product that hides the scene behind the system, which is implemented as quickly and low-cost implementation. On the other hand, the use of evolved products requires more design and implementation of work to early versions.
In fact, in the first phase of the ASDI project, in order to demonstrate the graphical user interface, we have tried to use these two methods during the analysis of the user workflow. Table 2 compares the results of two methods.
Demonstration of the development tools used in front of the outside system Microsoft FrontPage JSP / Text Editor Prepared 3 days before the first demonstration 3 days 1.5 weeks to the customer convey workflow / GUI's ability to transfer similar appearance to the final product Good response to requests and suggestions to change the demo speed is very slow to moderate training. The short-term training of the short training (because the team trained in JSP) and the backend servlet and database Easy degree is not good
Table 2: Using a front demo UI vs. Using the Early Code Version UI
We used positive for the early days of the initial phase and refinement phase of the project. Although there will often be some scattered demonstrations, but we feel that investment is worth it. We used FrontPage because we didn't have difficulties integrate with Java Servlet and database, because we have no database plan or component that needs to be connected. Because we used FrontPage in the project, the FRONTPAGE 2002 database integration capabilities have been improved. If we need it in future projects, we can even use it to display test data from the database plan.
Once the design begins to stabilize, we entered an iterative encoding cycle using JSP and Servlet. In the early part of the project (during the initial and refined period), scattered Java code is very small, because at that time, in addition to java we can't even determine that we will use JSP and servlet. Using FrontPage is more easier, and we don't have to worry about any implicit technique option.
Early and frequently constructing the early beginning of the project's construction phase The build version can be more quickly eliminated, and frequently generate the build version can help keep the synchronization of each member in the project. It is important to find a balance between excessive and too little build versions in the ASDI project. Select frequent builds must take into account the problem of project complexity, vacation programs, team skills, customer usability (for external demonstration) and component and subsystems.
The construction of subsystems Our subsystem integrates components that are developed, and sometimes results in the generation of systems. We don't insist on requesting all subsystems to build a demo; but team leaders will implement an internal build version - usually every build version of the planning time is once a week - just ensures that part of the code can be collected together. This synchronizes everyone working in the subsystem, because, for example, all of them must use the same database plan for the build version. When the team leader chooses to demonstrate the integrated subsystem, this demonstration is displayed at the weekend team meeting, how is it improved by watching the system part of their responsible, giving a team a achievement. Team leaders are efficient in establishing these demonstrations. The entire team knows that the code starts to modify their code on Friday morning to prepare for integration. Typically, the build version is at noon, if any problems have occurred during the integration process, allowing for two or two hours of time to modify and discuss. After ensuring that all recently updated code has been checked (Check IN), team leaders will propose all code from the source repository library.
Our configuration management tool is a stumbling block for our project. We did not choose Rational ClearCase as our configuration management method, but used the ability to provide the ability to provide the free CVS (Concurrent Versioning System) tool. Configuration Management is an important part of software management, and after the project, we hope that we can invest more times on the guidance of our configuration management tools. We don't use an integrated solution that mean:
The team is almost impossible to check (Check Out) files with a regular basis. Data is lost in poor configuration management. Changes cannot be easily associated with a problem or software change request for integration and test (I & T). The use of bad CVS tools will make the team's work efficiency decrease.
We decided that if we have won the second phase of the project, we will evaluate the tools of ClearCase as another Rational Tools we use.
The construction of the system may be integrated into a system build version, just like subsystem builds, the system has the same benefits and target, except:
System construction will cost more preparation, which has a greater impact on the team and is why we are more decentralized for us. They usually reveal a large number of problems, even more serious problems that threaten the success of the project. They start in the late stage of the construction phase, because we need enough subsystem to adjust integrated work. Complete system construction is ultimately intervened by the integration and test (I & T) team.
The engineering team completed the first test version of the two complete systems with the help of integrating and testing teams. These initial buildings are painful: we have many problems in configuration management; some sub-system interface levels have been lost; and some subsystems are slightly behind the plan. In the second test version, the integration and test team joined in as an observer and started the integration of the next system. This facilitates the transfer of duties and knowledge to integration and testing team, and will not be wasted in two buildings.
For engineering teams and later integration and test teams, it is very important to include any clear concepts in every build version; otherwise, build work will be slow, and will waste teams time's up. In fact, we understand the process of iteration and each integrated work, and we can cost the build work.
Summary Our construction and internal demonstrations are usually very smooth; however, remote builds require additional attention from project engineers. Schemes for remote development of subsystems often do not complete on time, because the remote development team cannot access the same resources as the core engineering team. Our customer demonstration is very successful. We are very confident that we have a clear customer demand early in the construction phase, and customers also have a clear concept of products. There is a small misprising expectation and surprise during the final product delivery.
Planning the future system builds now, we will quickly enter the test work. We plan to use Rational Test Tools to help us complete the test work. We need to make sure that all ASDI projects have been implemented, and test the performance of our web application under certain loads. These activities have also increased the familiar integration and test team to systematically, and start learning to use test tools.
Main risks Our buildings and demonstrations have no new risks; in fact, find and modify early issues help reduce risk. We continue to feel the pressure on time schedule, however, we know that the construction must be carried out in a fast pace. In the drafting of our function test, we have been behind planned. RUP recommends that these work earlier in the earlier project, we now have a huge pressure because we have delayed a activity.
Resource
"Joint Application Development (JAD) for Requirements Collection and Management" by Alan Cline (Carolla Development, Inc. whitepaper) "Joint Application Development (JAD) -? What do you really want" by the University of Texas at Austin
About the author Steven Franklin has a very broad background in software design, architecture, and engineering process, which is often used in large, distributed information management and control systems. He started using Rational tools in 1997, his main interest in XML, J2EE, wireless and software engineering technology. You can contact Steven via Steve@sfranklin.net.
