Use of software tools to support business processes is both a possibility and necessity for both large and small enterprises of today. Given the variety of tools on the market, the question of how to choose the right tools for the process in question or analyze the suitability of the tools already employed arises. The paper presents an experience report of using a high-level business process model for analyzing software tools suitability at a large ICT organization that recently transitioned to scrum-based project methodology of software development. The paper gives overview of the modeling method used, describes the organizational context, presents a model built, and discusses preliminary findings based on the analysis of the model.

1. Building a High-Level Process Model for
Soliciting Requirements on Software Tools
to Support Software Development:
Experience Report
Ilia Bider - DSV SU/IbisSoft
Athanasios Karapantelakis – Ericsson Research
Nirjal Khadka – DSV SU/SE
Presentation for PoEM 2013 http://poem2013.rtu.lv/
Riga, Latvia, November, 2013
Proceedings: http://bit.ly/17n1gV5
1
PoEM 2013

2. Goals with presentation
Essentially, old models are wrong, but some of them are useful (George
P.E. Box)
• Present an example of the above and at the same time
• Present a new process modeling technique useful for understanding
what type of IT-support a particular process need
• Demonstrate how it works on particular example which was used as
the first test for the modeling techniques
• Show how modern IT development copes in the global world
2
PoEM 2013

3. Object of modeling: software
development process at a large ICT
provider
Who went from
•
a traditional phase-based development approach with local
software development teams
To
•
3
working in an iterative manner using the Scrum project
management methodology and employing geographically
distributed teams that have cultural differences and may work in
different time zones
PoEM 2013

4. Goal with the project
I. Practical goals
1.
2.
Better understanding of current practice
Find weak points in the process and/or IT-tools employed in it
II. Research golas
1.
2.
4
Test the modeling technique in practice
See whether the technique suits the task of analysis of existing
tools rather than the task of choosing the tool
PoEM 2013

5. Goal with modeling technique
• Discover essential properties of a business process
without going into too many details
• Enough to derive requirements on capabilities of IT-tools
that would provide satisfactory support for people enged
in the process.
-------------------------------------------------------------------• Original indentation – provide guidelines for choosing
tools/systems/services
• For this project – analyze already employed tools
5
PoEM 2013

6. Main notions of modeling technique
1. Step (phase, work package) a unit of work; a model
includes a small number of steps5-10
2. Relationships between the steps of different kinds
-------------------------------------------------------------------• Relationships can be presented graphically; easy to
understand
or
• In the form of octagonal matrixes; these could be
manipulated formally
6
PoEM 2013

7. Input-output relationships (graphical form)
7
PoEM 2013

8. Input-output relationships (additional details)
8
PoEM 2013

9. Input-output relationships in the graphical
form
Input
Output BR
TR
AR
FD-A
FD-B
IC
RM
Priorities
Bug reports,
Preliminary
integration.
Priorities
Bug reports,
Preliminary integration
BR
TR
AR
*Product req.
spec.
*Design
req. spec.
FD-A
*Feature A req.
spec. , Schedule
FD-B
*Feature B req.
spec., Schedule
Early versions of
code
IC
*Split schema,
Schedule
Status info
Status info
RM
*Split schema,
Schedule
*Code and
instruct.
*Code and
instruct.
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
9
Status info
Schedule
changes
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013

10. Parallel execution matrix
BR
TR
AR
FD-A
FD-B
IC
RM
BR
TR
AR
.
FD-A
x
x
FD-B
x
IC
x
x
x
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
10
x
x
RM
x
x
x
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013

11. Parallel dependencies matrix
Output BR
Input
TR
AR
FD-A
FD-B
IC
RM
BR
AR
FD-A
IC
RM
TR
*Product
req.
spec.
AR
+
AR
.
FD-A
x
*Feature A
req. spec.
, Schedule
Priorities Bug reports,
Preliminary
integration.
FD-B
*Feature B Early
req. spec., versions
Schedule
of code
*Split
schema,
Schedule
Status
info
Status
info
RM
*Split
schema,
Schedule
*Code
and
instruct.
x
RM
x
x
*Code Schedule
and
changes
instruct
.
=
FD-A
Status info
FD-B
IC
FD-A
RM
x
x
IC
x
x
x
x
x
RM
x
x
FD-B
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
x
x
Priorities Bug reports,
Preliminary
integration
IC
x
x
x
FD-B
IC
*Design
req.
spec.
FD-A
11
FD-B
BR
BR
TR
TR
x
x
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013
x
x

12. Weak dependencies matrix
FD-A
FD-A
FD-B
IC
Explanations of
code behavior
FD-B
Details on the
status
Explanations of
test results/bug
reports
IC
Details on the
status
Details on the
status
RM
Explanations of
code behavior
Explanation of
test results/bug
reports
Explanations of
code behavior
Explanations of
test results/bug
reports
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
12
RM
Details on the
status
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013

13. Team relationships
Output BR
Input
TR
AR
FD-A
FD-B
IC
RM
BR
TR
AR
.
FD-A
1 person.
FD-B
1 person.
IC
1 person
1 person
RM
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
13
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013

14. Teams + weak dependencies matrix
FD-A
FD-B
FD-A
FD-B
IC
RM
Explanations of
code behavior
Output FD-A
Input
Explanation of
test results/bug
reports
Details on the
status
Explanations of
test results/bug
reports
Explanations of
test results/bug
reports
FD-B
IC
FD-A
+
1 person.
FD-B
1 person.
IC
1 person
1 person
RM
IC
Details on the
status
Details on the
status
RM
Explanations of
code behavior
Explanations of
code behavior
FD-A
FD-B Details on the status
Explanations of test
results/bug reports
RM
Explanation of test
results/bug reports
Explanations of test
results/bug reports
IC
Details on the status Details on the status
RM
14
IC
Explanations of
code behavior
FD-A
=
FD-B
Details on the
status
Explanations of
code behavior
Details on the status
Explanations of
code behavior
BR: Business (product) requirements
TR: Technical (design) requirements
AR: Assigning requirements
FD-A: Feature A development
FD-B: Feature B development
IC: Implementation Coordination
RM: Release management (integration)
PoEM 2013
RM

15. Capabilities of IT-tools/systems/services
Information
logistic
support
15
Intra-step
collaboration
support
Inter-step
collaboration
support
Process flow
restriction
enforcement
Process
flow
support
PoEM 2013
Participation
restriction
enforcement

16. Matching capabilities and process
properties
16
PoEM 2013

17. Process for choosing BPS
tools/systems/services
Identify
steps in
business
process
17
Fill in
basic
matrices
Build
derived
matrices
Identify
capabilities
using
matrices
Chose BPS
that provides
identified
capabilities
PoEM 2013

18. Tool usage in the process
BR
TR
BR
TR
AR
FD-A
FD-B
IC
RM
GPT
BR,FS
BR,FS
PPM
PPM,GP RC,PPM
T
AR
RC
RC,PPM
FD-A
DE,FT,FS, GPT
RP,ST,TM
FD-B
RC
FS,BR,GP
T
DE,FT,FS, GPT
RP,ST,TM
IC
RC
GPT
GPT
RC,PPM BR,GPT
RM
18
RC
RC
FS, GPT
FS,GPT
GPT
Specialized tools
AB - Automated Build, continuous integration
tool for building snapshots of code
BR – Bug Tracker, an in-house developed bug
reporting tool
DE - Development Environment for authoring
code.
FT – Tool for function and unit test automated test framework (in-house
developed).
FS – Secure file server, for feature teams to
deliver code to RM for integration or to other
feature teams in case of inter-dependencies.
AB,BR,ST,TM
General Purpose Tools (GPT)
CT - Communication Tool for email,
instant messaging, and meetings.
DS – Document Store, a database for
storing documents or links to
documents.
ICMS - Internal Content Management
System for broadcasting information of
general interest, e.g. project milestone
results, info from other process cases,
etc.
Office - Spreadsheet and Word
Processing.
SN – An internal social network with
technical forums for idea exchange
PPM - Product and Portfolio Management tool
for project management.
RC - Requirements Composer for defining and
following up the requirements.
ST - automated System Testing tool for
regression testing (part of acceptance testing)
TM - Test Management Tool for documenting
test cases
ST - Scrum Tool for backlog management.
RP - Version control system, for collaborative
code development in feature teams
PoEM 2013

19. Problem identified
FD-A
FD-B
IC
Explanations of
code behavior
FD-A
FD-B Details on the status
Explanations of test
results/bug reports
Explanation of test
results/bug reports
Explanations of test
results/bug reports
IC
Details on the status Details on the status
RM
19
RM
Explanations of
code behavior
Explanations of
code behavior
PoEM 2013
Details on the status

20. Thank you for your attention!
Main Contact
Ilia Bider, SU/IbisSoft
Email: ilia@{ibissoft|dsv.su}.se
20
PoEM 2013