Conclusion

During the elaboration phase of our sample project, we design, develop, and implement a functional architectural baseline. We run the implementation and perform initial unit tests. We also update the project planning.

What remains is to produce the documentation from the source code. To provide a user's manual in the form of HTML pages, we produce the comment Web pages by going to the Tools menu and selecting the option Build Comment Web Pages. In the displayed message box, we specify the destination where the files will be saved to (in our case, the documentation is stored in the doc folder of the project). Sample comment Web pages can be found in the doc folder in the sample solution. In addition, we produce the XML documentation, which is used for tracking (because it shows the requirement keys that have been implemented).

To produce the XML files, go to Solution Explorer, right-click on Photo Editor Application, and choose Properties. In the Configuration Properties dialog, specify the file name to be used as the XML documentation file. The XML file will be generated with every build, and the file will be saved in the build directory (bin or bind in the case of the photo editor project). The compiler will now create warnings if public members of a class do not specify an XML-style comment.

In addition to the documentation, we apply a label to the software and the documents (at least it should be done for the manually generated documents such as the project plan, the requirements document, and so on). To add a label in Visual Source Safe, open the Source Safe application and select the project. In the File menu choose Label. A window opens where you can specify the label. The label will be something like "Version 0.1.0." This complies with the Microsoft .NET standard, which uses three numbers to identify a specific version. Because the version produced is the first intermediate result, it is labeled with 0 (zero) for the main release, 1 for the intermediate release, and 0 for the minor releases. In addition, the AssemblyInfo.cs file of the Photo Editor Application should be adjusted to correspond to the version in the label before checkin.

5.8.1 Review

We must review the status of the project to decide whether the project will be continued. If the project is continued and an agreement with the customer is signed, then we check whether the project is ready to proceed to the construction phase. To decide whether the project is ready, we assess whether we have met the goals for the five core workflows:

• Requirements: Refine the requirements and system scope.
• Analysis: Analyze the requirements by describing what the system does.
• Design: Develop a stable architecture using UML.
• Implementation: Implement the architectural baseline.
• Test: Test the implemented architectural baseline.

It can be seen that the project meets all goals that were set for this phase and iteration. Therefore, the project is ready to move on to the next phase.

To get customer feedback early on, we deliver the project to the customer as intermediate V 0.1.0. It is crucial to deliver intermediate results that are functional but not yet the final product. In this way, the customer has a better understanding of the progress, and any changes that might be requested by the customer can be discussed and implemented as early as the intermediate project is delivered instead of at the end of the project. Especially with GUI development, this is very important. Another advantage of intermediate deliveries is that errors may be found by the customer and communicated to the development team while the product is still in development.