Using Tytan Workflow in Software Engineering

Tytan Workflow application was used in ComArch S.A. to automate processes related directly with software development and maintenance. Examples of processes which was modeled and implemented are:

 software service

 change request management  project management  reports generation 3.1. Service Processes

It is set of few processes that are used in realization of notifications and problems handling (e.g. software bugs, suggestion, questions) that are reported by clients and

workers. Process maintain whole life cycle of notification called ticket – from its submitting through realization and finally until verification of solution or answer and closing ticket. There are for user groups that participate in this process and therefore there are four for each one (and also four group types):

x Clients – persons that create ticket and verify whether the solution is satisfying

x First line – it mediates between clients and rest of company workers, gathers

information to describe problem more precisely, and if it can realize ticket

x Second line – occupy technical analysis, patches and corrections

x Production – if project is still in development changes that solves notified

problem are attached into product or in its newest version

Each group has dedicated its own process – their instances are connected into hierarchy of subordinate and precedent processes, it means that e.g. first line process is started as subprocess of client process, and from the other hand process of second line is started as subprocess of first line process. Synchronization of data between processes is achieved with using mechanism of copying parameters values and also with help of global parameters which values are common for all processes in one hierarchy tree. Process participators from different groups may communicate between each other thanks to consultation mechanism, that provide possibility of sending text messages.

Most important steps of service processes are: x Client Process

 Registration – submitting person provide description of problem

 Starting of first line subprocess

 Waiting for ticket solution

 Solution Verification – in case of rejecting the solution, process backs to

first line x First line process

 Registration - accepting ticket parameters provided in client process

 Problem solving

 Starting of second line subprocess – it is not mandatory, takes place

when solving the problem can not be achieved here

 Solution verification – if negative process may back to second line or

again to first line problem solving steps

 Waiting for solution acceptance from client – if solution is rejected

process backs to problem solving x Second line process

 Registration

 Problem solving

 Starting production process – not mandatory

 Verification of solution

x Production process

 Registration

 Problem solving

 Starting other production process instance – if somebody want to divide

problem realization between wider group of people

 Verification of solution

As you can see all process except of client’s one are quite similar. But their strict separation is necessary – it provides possibility of division of work between specialized departments, gives also better control of whole process, makes easier creating statistics. Introducing such set of processes is step into paperless company. All data related to given ticket are provided through web browser as texts or attachments, and afterwards stored in database in records related to process instance, therefore improved management of data is possible. All advantages allows in some degree to reduce costs of whole process of software maintenance.

3.2. Change Request Management

This process is example of introducing ISO quality standards into company daily work. Process model was created basing on ISO procedure that concerns change request management. Change request is client’s wish to change functionality of product which already has been implemented and works for some time. Changing functionality may be easy or very hard (that means expensive), has to be consulted with product road map to anticipate possible conflicts and many other factors influence whole process. It is necessary to provide proper handling of this kind of requests from client. There is several groups of workers that participate in this process:

x Attendance – people that contact with client, preparing and presenting offers

an gathering opinions and answers

x Change manager – manage all change request from given product, allocates

people resources which have to occupy given request

x Change request manager – is pilot of this project, inspects process of its

realization

x Product manager – person which controls development of given product,

circumscribe its future paths

x Analysts – prepare analysis of selected problems

x Workers – usually they got precise tasks what should be done

Main steps of change request management process are:

x Registration

x Initial analysis

x Consultation with client about costs

x Offer for client

x Realization

x Verification of changes

3.3. Project Management Process

This process model was implemented to provide better control of whole process of creating the project. Groups that participate in realization are:

x Registerer – person that enters informations about project and selects resource

x Resource manager – person that allocate people resources for project and selects project manager

x Project manager – controls whole procedure of project realization

x Worker – they execute tasks pointed by project manager

Project management consists of three processes:

x Contract Order Process – main process that serves as monitor during project

realization

x Internal Project Order – this is subprocess started when realization of project

requires ordering another project

x Task Order Process – this process is used by project manager to order

particular tasks for workers 3.4. Report Process

This process is example of integrating Tytan Workflow with external systems – in this case with Ocean module for report generating. Process definition contains various activities that correspond with particular reports definition (which are stored in separate repository). User who opens such process instance can select one of defined reports type and in next task fill required parameters. Entered data are used as arguments in invoking procedures from Ocean to generate chosen report which is returned to user.

4. Summary

Using Tytan Workflow allows to increase in work efficiency through strict definition, organization and automation of company activities. Allows to speedup execution, centralize information storage, divide responsibility between company departments. It simplifies control of such aspects like work flow, times spent on particular stages of processes (thus could be helpful in its improvement) and efficiency of particular workers. It is also promising tool for integration various systems into common platform. Within one process definition many products may be used for particular actions. This all could be achieved under one very important condition – process model and its definition has to be simply good – fulfill goals for which it was projected. It is not simple matter – process definition is long and laborious operation – it require many consultation with workers to recognize and understand their work. But without good process model advantages from using Workflow software could easy turn into financial loses.

Bibliography

[1] G. Alonso, D. Agrawal, A. E1Abbadi and C. Mohan. Functionality and Limitations of Current Workflow Management Systems. IEEE Expert 1997. Available on the Web at http://www.almaden.ibm.com/cs/exotica/wfmsys.ps

[2] The Workflow Reference Model. Workflow Management Coalition, December 1994. Available on the web: http://www.aiai.ed.ac.uk/WfMC/

[3] IEEE: IEEE Standard Glossary of Software Engineering Terminology, IEEE, Standard IEEE Std 610.12-1990, 1990

[4] Solecki, A.: Workflow narzĊdziem z przyszáoĞcią. Strategie informatyzacji – Integracja systemów, InfoVide, 5 April 2000

[5] Bennett, K.: Software Maintenance – Cut the biggest IT costs. Computer Bulletin, BCS, January 2005 [6] Somerville, I.: InĪynieria oprogramowania (Software Engineering), Wydawnictwo Naukowo Techniczne,

2003

Architecture of Parallel Spatial Data