Recent studies are advocating that Software Process Development (SPD) can be viewed as a Knowledge Intensive Process (INCLUIR REFERENCIAS). In fact the development of a software involves several processes that are less predictable, COLOCAR CARACTERISTICAS BASICAS (VER CICCIO) and depends intensively on participants' knowledge. Some authors introduced the expression Artfull Process to describe processes with this characteristics.
There are plenty of challenges in working in a KIP. One of these issues is knowing the context of a task. Considering SPD for example, the context of a coding task includes the artifacts that are consumed and produced during that task (source-code, documentation, manual, etc.). A senior developer, for example, knows the documentation (business requirements, rules, constraints, manuals, etc) that is consumed and the source-code that is created or updated during a coding task. A junior developer (or a new member in a development team) may have more difficulty to reach these artifacts.
In this text, the context of a task will be referred as Task Context Information (TCI).
We are presenting a solution to assist the participants in a SDP to know the TCI. A model to represent SDP and TCI is proposed based on an existent notation (BPMN). This notation allows the software process engineering to define at design-time the process and the TCIs of some activities. It is also possible to learn by mining process log.
The solution builds knowledge from previous instances of a process and uses this knowledge to predict a candidate TCI. The solution involves a model to represent a TCI and a heuristic to learn and predict a Task Contextal Information.
Knowledge Intensive Processes (KiPs) are those whose execution is highly influenced by the participants' knowledge. They are genuinely knowledge, information and data centric and require flexibility at design- and run-time . DiCicio characterizes KIP with eight main characteristics: Knowledge-driven, Collaboration-oriented, Unpredictable, Emergent, Goal-oriented, Event-driven, Constraint- and rule-driven and Non-repeatable. The author also proposed a framework to evaluate the support to KIP was devised and used it to check the efficiency of some existing process-oriented solutions. This framework includes 25 requirements divided in 7 areas: Data, KNOWLEDGE ACTIONS, RULES AND CONSTRAINTS, GOALS, PROCESSES, KNOWLEDGE WORKERS and ENVIRONMENT. The study concludes that none of the approaches evaluated fulfills all the requirements. Actually, there are plenty of requirements that is not covered by almost all approaches. Therefore, there are plenty of open questions in this subject.
DiCicio presents a study that discusses the characteristics, requirements and analysis of contemporary approaches related to KIP. A framework to evaluate the support to KIP was devised and used to check the efficiency of some existing process-oriented solutions. The study concludes that none of the approaches fulfills all the requirements. Actually, there are plenty of open questions related to KIP.
There are several studies that claim that Software Development Development (SDP) is a Knowledge Intensite Process (REFERENCIAS).
bla bla bla
We define a model named TCI Model to represent the Task Context Information and its relation with others concepts.
This model partly address some of the requirements proposed in DiCicio: The requirement named R1 Data modeling defines that a model to represent all relevant data manipulated by the process and their interrelationships is required. The requirement R3 Access to appropriate data states that all the relevant data should be available to the proper participants. The requirements R16 Learning from event logs and R17 Learning from data sources define that a KIP must help an organization to learn from previous executed instances.
We are aware that this model is covering a small part of the knowledge in a KIP. The TCI Model represents one perspective of a KIP.
Software Process Development can be classified as a KIP since it has some bla bla bla.
The Task Context Information is an embracing concept. There are a wide range of items that can compose the context of a task. Some of these items are obvious like documentation, source-code, tutorials, constraints and rules, etc. Others can be less obvious, like weather, participant's humor, participant's clothes, etc.
In the scope of this text, Task Contextual Information (TCI) is the set of identifiable software artifacts that a participant uses, creates or updates during the execution of a task. As examples of a TCI considered in this proposal we can mention: source-code, documentation, software, forum question, etc.
On the other hand, items that could not be identified are not part of a TIC. In this category we can mention: weather, participant's humor, participant's clothes, etc.
A Context Item (CI) represents an individual artifact that can be identifiable during the process. The TCI is the set of all CI related to a task.
In the model, there are two CI types: user defined and discovered. As the name suggest, the first reference CI that are defined by the user and the second CI discovered during a process instance execution.