Continuing on Unity project description from Chapter1, more detailed overview of the used and recommended tools follows.
The ASDP Tools Suite is a set of third party software tools recommended by SoftCo to individual ACS teams. These tools cover most parts of software development process and it is SoftCo’s task to make them as compliant to and compatible with ASDP as possible. Note that usage of any of these tools is not mandatory to ACS teams, as long as they follow ASDP rules and produce all required work products.
These tools are configured and supported by SoftCo. The ones which are web- or server-based are also hosted and maintained by SoftCo.
However, because the tools are meant for different tasks, their field of responsibility is naturally connected and also overlaps. SoftCo is therefore continuously working on their mutual integration. Thanks to that, data would not need to be duplicated in mul-tiple tools, which would reduce the amount of work and also decrease chance of errors when data are changed.
Parts of the integration are already fully operational, while other are still being de-veloped.
Overview of the disciplines and provided tools is depicted in Figure 1.1 in Chap-ter1.
Regarding to requirements management, testing and defect tracking, and thus scope of this thesis, two of these tools are at utmost importance: Contour for requirements and test management and Jira for issue tracking. They are described in more details in this section.
3.6.1 Contour
Contour by JAMA Software is a recommended tool by SoftCo to be used by ACS teams for
38
3. ACS SOFTWAREDEVELOPMENTPROCESS
• requirements management,
• test management and test execution.
It was chosen by SoftCo after evaluating several requirement management tools.
One of the reasons for choosing Contour was also its simplicity when compared to other professional tools. Such a tool must be as simple as possible, so that users understand it properly. Otherwise, they would not be able to use it properly which would reduce both efficiency and effectiveness of testing.
Contour is a web based application. Data are organized into projects. It provides possibility to specify a template when a new project is about to be created.
Customization functionality is used by SoftCo team by means of ASDP Contour De-fault Configuration4, which provides several item types, like ASDP Product Feature, ASDP Declarative Requirement or ASDP Test Case. These items are designed to follow ASDP documentation as closely as possible, though it is not always possible to be followed completely. Default configuration also provides a folder structure which provides a de-fault way how to organize items. It unifies structure among projects and thus makes it easier and quicker for the user to get understanding of a new project. It also makes possible for definition of several metrics and reports.
Folder structure of ASDP Contour Default Configuration is presented in Figure3.11.
Figure 3.11: Folder layout of Contour Default Configuration
4. can be downloaded from Contour’s internal Wiki
39
3. ACS SOFTWAREDEVELOPMENTPROCESS
Requirements management in Contour
Requirements management in Contour is very similar as described in ASDP. For the scope of this thesis, it does not need to be discussed any further.
Test management in Contour
Test management in Contour follows ASDP very closely, mainly because of the cus-tomization and default configuration prepared and maintained by SoftCo. Although, there are slight differences.
According to ASDP, testing shall start with planning and creation of ASDP Test Plan, which is however not possible in Contour. Therefore, this artifact is usually created in MS Word. Prior to the actual execution of the test cases, a ASDP Test Execution Plan is created5. It specifies which test cases shall be executed and assigns them to testers, and also defines a time schedule.
In the complementary thesis [17], Schimmel focuses on this planning and accuracy of its estimates.
3.6.2 Jira
Jira by Atlassian is an issue tracker recommended by SoftCo, which is used by most teams in ACS and Aerospace as well. Jira is used to record any type of issues, which can be general tasks, logs or most importantly for this thesis, defects.
Jira has several item types, each of which is defined by a set of fields and its behavior.
For example defects pass through several states: reported, open, resolved, closed, . . . . Like in Contour’s case, also Jira has been customized by SoftCo by means of ACS Jira Default Configuration6. It defines best practices for Jira usage, as well as custom workflows which closely follow ASDP.
Jira itself provides several metrics and indicators, like number of defects in each state.
3.6.3 Tools Integration
Jira is greatly extensible and customizable. Widgets can be simply added into it which makes it the ideal base for any integration with other tools. This extensibility has been recognized by SoftCo and provided start for ACS Jira Extensions project.
The integration is important because it reduced the amount of information user need to enter into the tools. It also speeds up navigation, because it is now possible to navigate directly to an item in another tool, just by following a hyperlink.
Thanks to all of these features, quality of the product specification becomes more clear, resulting in fewer problems and thus higher quality of the final product.
5. Note, that the naming is inconsistent and it is called Test Plan in Contour 6. It can be downloaded from internal Wiki
40
3. ACS SOFTWAREDEVELOPMENTPROCESS
At this time, it is possible to create inter-tool links between Contour and Jira. Most obvious are links between a failed test case (in Contour) and a recorded defect (in Jira).
This first integration plugin was deployed full ACS in August 2012.
SoftCo is working on further integration plugins, which will bridge the gaps be-tween other tools. Thanks to them, more tools will get connected, resulting in higher amounts of traceability information available. In the future, it may add possibilities for several other metrics and indicators.
41
Chapter 4
Data evaluation
Chapter 2reviewed best practices of test management found in literature. Chapter 3 reviewed Honeywell’s point of view, namely description of requirements and test man-agement as specified in ASDP. This chapter continues by looking at the quality of real data, recorded in real projects in ACS. First, it describes how data can be gathered and where from. Then it evaluates to what extent the data fit practices from Chapter2and documentation in ASDP, what problems it may cause and the ways to prevent them.
Finally, it identifies stakeholders, who may get most benefit by improving the qual-ity of data by means of metrics.