Swicetrip: A Collaborative Travel Site Designed with ISO/IEC 29110

SwiceTrip Project

The proposed project to start a social networking website for travelers called SwiceTrip was done by a team of two part-time partners (co-authors of this article), over a period of one year requesting nearly 1,000 hours. The new ISO/CEI 29110 standard developed specifically for very small entities and startups was used to develop the software.

This site aims to help a traveler throughout the life cycle of a trip: The initial planning, the monitoring, and the  during the trip and to sharing his experience. The site offers an attractive and easy to use interface to allow users to create travel itineraries and share useful information with fellow travelers (Figure 1).

Figure 1. Two main interfaces of the SwiceTrip site

The objective of the website is to help a traveler throughout the life cycle of a trip, from the initial planning stage to the ongoing monitoring and sharing of the travel experience. The site offers an attractive and easy-to-use interface to allow users to create travel itineraries and share useful information with fellow travelers, as well as keep track of the details of the trip, such as dates, names, hotels, and so on (figure 2). The description of a trip can include cities, activities, accommodations, and photos, all of which can be accessed by the traveler’s friends, who can also view its history. This small startup organization offers their travel services free of charge. The revenues will come from the advertising displayed on the site.

Figure 2. users interface to create travel itineraries and share useful information with fellow travelers

This is the first time that the new ISO / IEC 29110 standard was used to start a business of two people. This standard helps very small entities (VSMs) of 25 people or less to develop software.

Project management

The basic profile of the ISO / IEC 29110 standard is divided as shown in Figure 3, into two processes: the process of project management and process implementation [1]. A project begins upon receipt of a statement of work and ends with the delivery of documents and software to the customer.

Figure 3. Basic profile of ISO/CEI 29110

Figure 4 on the next page shows the flow of information among the four activities in the PM process of the ISO/IEC 29110 standard, including the most relevant work products and the relationship between them.

Figure 4. Flow of information from the four activities in the PM process of the ISO/IEC 29110 standard

Since SwiceTrip.com is a new product from a start-up, we played the role of a client to write a statement of work with the high-level specifications. The main requirements of the project were extracted from the features defined in the Statement of Work (SoW) document to establish the scope of the project and the overall product description. The assignment of different roles, as described in ISO 29110, for each member of the team has been documented in the form of a table of the project plan (Table 1).

Table 1. Assignment of roles

To make the estimate of the time required for each activity, we determined the time we could spend on this project. It was not possible to devote more than 10 hours per week for each teammate because they were already employed full-time. To help with project planning, the team used an open-source GanttProject software tool.

Quality assurance

A template to record anomalies detected during reviews, which would apply to documents required by ISO/IEC 29110, was developed early in the project (figure 5).

Figure 5. Anomalies detected during reviews, which would apply to documents required by ISO/IEC 29110

Implementation process

Figure 6 shows the flow of information between the six activities associated with this process, including the most relevant work products and their relationships.

Figure 6. Flow of information between the six activities associated with this process

Software Requirements Analysis

This activity analyzes the requirements agreed to by the customer and establishes the validated project requirements [1]. At the time of writing requirements specification, many questions were raised about how to meet the initial requirements. This analysis was very helpful when monitoring monthly project activities since some features have been removed from the project because of their complexity and others were added. Verification and validation of requirements specification were performed several times to verify the accuracy and testability of specification requirements and its compatibility with the product description. These audits have found major abnormalities and reduce recovery efforts downstream.

Software Architecture and Detailed Design

This activity transforms the software requirements into the software system architecture and detailed software design [1]. It began following correction of the anomalies detected during the verification and validation of the requirement specification document

Software Construction

This activity develops the software code and data from the software design [1]. It began following verification and validation of the architecture and design documents. Components to develop (i.e., code), were assigned to the two-person team in accordance with the project plan. Since both the requirements and the architecture had been submitted for review, the construction phase went very smoothly.

Software Integration and Testing

This activity ensures that the integrated software components [1] satisfy the software requirements (table 2). For each test case, the authors defined its relationship with the use case, a test description, the steps involved, and the expected results.

Table 2. Software requirements

Results

Table 3 presents the efforts of the team recorded on the timesheets as the number of hours expended for each task. The total effort devoted to this project was 990.5 hours. The effort devoted to prevention, such as the installation of the environment (e.g., server, tools), was 89 hours, and the execution of the tasks took 716 hours. These figures do not include the effort required to review artifacts (60.5 hours) and to correct defects (i.e., rework) (125 hours). One can see that the remediation effort (rework), which was greater, was mainly related to the definition of customer requirements (SoW) and the detailed specifications. In fact, a great deal of time was spent on reviewing and correcting specifications before embarking on the other phases, knowing that when more defects are found early in the development cycle, the effort to correct them will be less than if they are detected during testing.

Table 3. Efforts of the team recorded on the timesheets as the number of hours

The percentage of prevention task effort was 8.9 percent (i.e., 89 hours/990.5 hours) and the percentage of rework effort was 12.6 percent (i.e., 125 hours/990.5 hours) for this project, which is close to the performance of a Capability Maturity Model (CMM)® maturity level of 3 (Paulk et al. 1993), in a comparison of the authors’ results with those attained in a study on the impact of CMM on quality, as illustrated in Table 4.

Table 4. Maturity level

Additional Information

For more information on this project, please see the following article:

Claude Y. Laporte, Charles Hébert, and Christian Mineau (2014). Development of a Social Network Website Using the New ISO/IEC 29110 Standard Developed Specifically for Very Small Entities. Software Quality Professional (SQP), Volume 16, issue 4, pp. 4-25 (PDF).