Browse Prior Art Database

A System and Method of Retrospective Knowledge Driven Project Testing

IP.com Disclosure Number: IPCOM000246519D
Publication Date: 2016-Jun-15
Document File: 7 page(s) / 295K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper is mainly focus on to build out a standard retrospective 3D ( 3- Dimensional) knowledge-driven model. In current project lifecycle, there will be many different kinds of problems occur in each phase and client oriented becomes more and more popular. So problem management will play a significant role to project succeed. This objective of this model is developing a standard knowledge-driven framework, which makes problem analysis make sense. Every problems involved in project can be caught exactly and tracked easily - based on its properties like where it was found, who found it, what is the appearance, what is the root cause, environment, assumption, etc, it will be addressed on the model with different dimensions. This model makes every change on product could retrospect to knowledge we get or problem we analysis. Here knowledge will cover from problem analysis to data mining. Problem recorded and captured is its raw data, after cycle as preconditioning, transforming, modeling, processing, feedback from clients, team get first- hand knowledge, which could direct product development trend.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 01 of 7

A System and Method of Retrospective Knowledge Driven Project Testing

Challenges we met,

1. Problems and issues are separated from software cycle. In current software lifecycle, problems and issues are multifarious and redundantly recorded in DB (database) or defect management system separately, its usage is only to export to a defect list for test execution report, which is a huge waste to project team. With team members' change, no one could trace new problem's root cause, and long-term client will also easily lose faith on product.

2. Developers are always blindly led by clients. As typical requirement theory, client don't know what they want actually, and developers always develop the way that they thought what client need. But the usual result is, the client reject the version that developers hard working on it. Through the model in this paper, product team could provide model and knowledge to client, guide and provide them the best way of implementation, and ensure the greatest ROI (Return On Investment) to both sides.


3. Product team is always puzzled by endless problems and issues, and cannot find their internal relations.

4. Due to knowledge limitation of current product. It is hard for client to make a correct decision on future version of product.

From this model, we can get:

1. Analysis Report: 360 degree perspective to show the project to our client.

2. Statistical Analysis Report: extract key points/issues/problems/milestones etc. in project and build knowledge base, provide foresight.

3. Decision maker: provide more evidence to strategy users, and provide the product development direction based on data mining on knowledge driven project.


4. Retrospect and Traceability: any feedback from client after product launch, could trace and position on one or more cells in 3D architecture model,

which make root cause finding authentic. We could update knowledge repository, for next problem determine, resolve, optimize, and better user experience.

Experience

1



Page 02 of 7

Figure 1 3D architecture model - level 1

In this paper, we make3D architecture cubic square as its model, with timeline/organization/system as its x/y/z axis. Timeline corresponding with each phase in project, organization corresponding with each role in project, and system corresponding with each component in project.

The source data can be collected automatically from current used problems DB or systems like defect management tool. They comes from input of everyone in project team, take an example, test lead could input defects and issues encounter in test environment, developer lead could input task assignment, block issues, skill resolution in each build, project manager could input project progress, staff allotment, risk control, dependencies, etc.

Once an environment issue logged to database of this model with specified format table as Table 1, which ensure data integrity and consistency in data

warehouse. Then this table was imported to 3D architectu...