Keynote at CBSOFT2014

1. Climbing the tree of unreachable
fruits reusing processes
P R O F . D R . I T A N A G I M E N E S
UNIVERSIDADE ESTADUAL DE MARINGÁ
CBSOF T , 2 0 1 4

2. Summary
— An overview of the software process research
¡ From well-defined process to software quality
¡ From fully-automated processes to toolkits
¡ Is software process really different from workflow
management?
¡ The Agile breakthrough
¡ Current Challenges
— Reflections on our community
¡ JSERD

3. Our first belief, 27 years ago
— “Software processes are software too” (Osteweil, ICSE 1987)
¡ Well-defined processes might lead to reductions in software
production costs and improvements in software quality.
¡ Software Process is the total set of software engineering activities
employed in the production, assessment and certification of an
operational system (Gimenes, 1992; Liu & Conradi, 1991).
Software Process
Model is a formal
representation
(abstraction)

4. From well-defined process to software quality
— Process Modelling
Languages (PML)
¡ DesignNet (Petri Net –
based)
¡ Formal models
(considering activity as
mathematical functions)
ex. HFSP
¡ Rule-based models –
activities are defined as
rules ex. Marvel
¡ Plan-based – emphasis on
goals, ex. GRAPPLE.
EPOS PML

5. PML went too far and
basically missed the point
(Fuggeta, 2000)

6. From well-defined process to software quality
— Process Improvement and Assessment (from mid
80s)
¡ Software process is dynamic
¡ ISO9000s
¡ ISO/IEC 12207, 15504
¡ IEEE
¡ CMM (1987), CMMI (2001)
¡ SPICE
¡ SPEM
¡ MPS-BR (Estudo de Caso: 10 Anos de MPS.BR’, Softex, 2014)
÷ 2004 – 2007 MPS-BR Implementation
÷ 2008 - 2011 MPS-BR Consolidation

7. • A strong community
was formed supported
by: Academy,
Government and
Industry.
• Evaluation and
measurement prevails
over prescription and
fully automation.

8. From fully-automated processes to toolkits
— Software Engineering Environment (SEE), 1990s
¡ A set of integrated tools acting over domain-specific database
which can support software engineers throughout the software
development process.
— PSEEs – Process-centered SEEs
¡ A SEE with a top level layer that controls the software process.
— PCTE
¡ a framework for tool integration

9. The PCTE Framework
Process Integration
Process Step
How well do relevant tools combine to support
the performance of a process step?
Event
How well do relevant tools agree on the events
required to support a process?
Constraint
How well do relevant tools cooperate
to enforce a constraint?
Tool
Provision
To what extent are a tool’s services used by
other tools in the environment?
Use
To what extent does a tool use the services
provided by other tools in the environment?
Control Integration
Figure 4-1 Properties of Integration1
Presentation
Integration
Appearance and
Behavior
To what extent do tools
use similar screen
appearance and
interactive behavior?
Interactive Paradigm
To what extent do two
tools use similar
metaphors and mental
models?
4.1 Platform Integration
Data Integration
Interoperability
How much work must be done
to manipulate data produced by
another?
Nonredundancy
How much data managed by a
tool is duplicated in or can be
derived from the data managed
by the other?
Data Consistency
How well do tools cooperate to
maintain the semantic constraints
of the data they manipulate?
Data Exchange
How much work must be done to
make the nonpersistent data
generated by one tool usable by
the other?
Synchronization
How well does a tool
communicate changes it makes
to the values of nonpersistent,
common data?
CMU/SEI-93-TR-1
The intent of platform integration is to provide network and operating system transparency to

10. From fully-automated processes to toolkits
— PSEEs didn’t survived.
— However, many good ideas survived into tool kits
¡ Configuration management, ex. SCCS, Git
¡ Software building, ex. Maven, Jenkins
¡ Programing environments, ex. Netbeans
¡ Source code analysis, ex. SonarQube
¡ Testing, ex. XUnity family
¡ Project management, ex. Jira
— Integration is still a burden.

11. We have learned a lot
about how to integrate
tools, but the straight
jacket failed again!

12. The Impact of the Workflow Movement
— Questions:
¡ Is software process really different from workflow?
¡ Is the support environment different?
¡ and business process?

13. The Impact of the Workflow Movement
— Workflow Handbook, 1995
¡ Workflow – collection of activities organized to realize a
business process.
¡ Workflow (automation) x Process (Definition).
¡ Workflow Management Systems (WfMS) – systems that
support the definition, creation, management and
execution of workflows.
¡ Workflow Management Coalition (WfMC, Similar 1999) ideas and
defined a
reference model for WfMS (Components and Interfaces).
different
communities

14. The Impact of the Workflow Movement
— Workflow community created a prosperous research
field which led to the Business Process Management
community.
— The Workflow Reference Model 10 years on (WfMC,
2005):
“It has been a subject of some debate whether there is any
practical difference between workflow management and business
process management. Certainly many of the concepts are the
same and, where there are differences, these tend to be in points
of detail, or through different emphasis”
¡ BPM evolves from Workflow + EAI + Web

15. When Business = Software,
software process is equal to
Business Process.
High level languages and tools,
such as BPMN can be applied to
specify and simulate software
processes.

16. The Agile Breakthrough, 2001
— Questions:
¡ Is the process an end in itself?
¡ It is too rigorous, is it effective?
¡ Does it deal with human behavior?
— Values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

17. The Agile Breakthrough, 2001
Principles
— the software product is the essential focus of the
development process;
— human behavior and quality of interactions
are essential enablers and success factors;
— incremental and spiral approaches, based on
frequent releases and strict collaboration with
the costumer are quintessential traits of modern
software development initiatives;
— in general, it is vital to promptly and quickly react to
requirement changes, at any stage of the
development process.

18. The Agile Breakthrough,2001
— XP
¡ Code
¡ Test-driven development
¡ Pair programming
— Project Management
¡ SCRUM
¡ Lean
¡ KanBan

19. “Nobody can tell you the state
of agile; Everything we know is
subjective and based on
circumstantial evidence” (Ken
Schwabe, 2014)

20. The impact of the Open Source Movement
— The Mozilla Foundation
(Mitchell Baker)
— Brought challenges in
¡ Distribution
¡ Flexibility
¡ Ability to deal with change
requirements

21. We have expanded software
development a lot, but this
does not apply for all types of
software.

22. Reflection ….

23. Current Challenges - not only research
— Coping with the technology push: Internet, services,
mobile, …
¡ We had a belief that we should elicit requirements and then
make design decisions but the available technology is driving
the process.
— Coping with the increasing speed push
¡ There seems not to be enough time for careful planning and
thinking;
¡ Time-to-market has been more important than reliability/
quality.

24. Current Challenges - not only research
— Turn ideas into tools, frameworks, components …
¡ Our research ideas only get to practice when there is proof that
to be feasible, operational.
¡ software engineering has to complete its cycle of ideas, develop
tools, develop experiments.
¡ research evaluation mechanisms impair this cycle, they give
too much value to novel ideas.
¡ Model-driven engineering can help.

25. Current Challenges - not only research
— Educate software engineers with both technical and
soft skill
¡ Technical background: computer science, mathematics,
software methods;
¡ Deal with the market distance;
¡ Stimulate software skills: creativity, work in group, problem
solving, leadership.

26. Current Challenges - not only research
— Bring technology and social aspects in context
— Team distribution (Global Software Development)
— Empirical studies are not an end in itself
¡ Limitations: participants, scenarios, data volume.
— Flexible control
¡ Application Lifecycle Management (ALM) (Fuggeta 2014), ex.
MyLin, Tasktop
¡ Smart convergence (Fuggeta, 2014)

27. • Research on software process
and support environment have
produced many fruits; not all of
them worked.
• There are many challenges to
face, the main message
• Evaluate your research, try
to be proud of what you do,
not only of producing
another paper.