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 U N I V E R S I D A D E E S T A D U A L D E M A R I N G Á

C B S O F T , 2 0 1 4

Climbing the tree of unreachable fruits reusing processes

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

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)

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

PML went too far and basically missed the point

(Fuggeta, 2000)

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

•  A strong community was formed supported by: Academy, Government and Industry.

•  Evaluation and measurement prevails over prescription and fully automation.

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

24 CMU/SEI-93-TR-1

Figure 4-1 Properties of Integration1

4.1 Platform IntegrationThe intent of platform integration is to provide network and operating system transparency tosoftware tools. A framework with a high degree of support for platform integration would allowtools to operate in a distributed environment without knowing the details of the environment.In addition, the porting of tools from platform to platform would be simplified. This frameworkcould also support SEEs residing on heterogeneous networks, with platform differenceshidden from the SEE and the tool by the framework. Such support was an original design goalof PCTE, and distribution is part of the both the PCTE 1.5 and ECMA PCTE specifications.

Limited experience suggests that PCTE 1.5 implementations can serve as effective substratesfor tools, offering a significant degree of support for platform integration. Hewlett Packard hasconstructed a prototype implementation of BMS using PCTE 1.5 services [Oliver 91]. Oliver

1. From Thomas and Nejmeh’s “Definitions of Tool Integration for Environments” [Thomas 92].

Tool

Process IntegrationProcess Step

How well do relevant tools combine to supportthe performance of a process step?

EventHow well do relevant tools agree on the eventsrequired to support a process?

ConstraintHow well do relevant tools cooperateto enforce a constraint?

Data IntegrationInteroperability

How much work must be doneto manipulate data produced byanother?

NonredundancyHow much data managed by atool is duplicated in or can bederived from the data managedby the other?

Data ConsistencyHow well do tools cooperate tomaintain the semantic constraintsof the data they manipulate?

Data ExchangeHow much work must be done tomake the nonpersistent datagenerated by one tool usable bythe other?

SynchronizationHow well does a toolcommunicate changes it makesto the values of nonpersistent,common data?

Control Integration

ProvisionTo what extent are a tool’s services used byother tools in the environment?

To what extent does a tool use the servicesprovided by other tools in the environment?

Use

PresentationIntegrationAppearance and

Behavior

Interactive Paradigm

To what extent do toolsuse similar screenappearance andinteractive behavior?

To what extent do twotools use similarmetaphors and mentalmodels?

The PCTE Framework

CMU/SEI-93-TR-1

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.

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

The Impact of the Workflow Movement

� Questions: ¡  Is software process really different from workflow? ¡  Is the support environment different? ¡  and business process?


� 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, 1999) defined a reference model for WfMS (Components and Interfaces).

Similar ideas and different

communities


�  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

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.

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

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.

The Agile Breakthrough,2001

�  XP ¡  Code ¡  Test-driven development ¡  Pair programming

�  Project Management ¡  SCRUM ¡  Lean ¡  KanBan

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

The impact of the Open Source Movement

�  The Mozilla Foundation (Mitchell Baker)

�  Brought challenges in ¡  Distribution ¡  Flexibility ¡  Ability to deal with change

requirements

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

Reflection ….

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.


�  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.


�  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.


�  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)

•  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.