Human factors in Software Process Automation

1
Human factors in Software Process Automation

• Attitudes to change
• Specific human oriented issues
• General non-technical and technical issues
• The Personal Software Process - a Self-Help
  programme for individuals

2
Phases of technology adoption

institutionalization
adaptation
Commitment Phase
installation
Acceptance Phase
understanding
Preparation Phase
awareness
Initial contact
time
3
People need time to adjust
Przybylinski (cited by Christie)
productivity

time
unfreezing ice breaking
Refreezing new practices become standard
When new practices are introduced, productivity
may actually fall initially
4
Human reactions to change
Reactions to Change
satisfaction
Emotional State

optimism
hope
time
pessimism
Important not to abandon new technology too
soon! Good gauge is to suggest replacing
automated system with old manual system and see
reaction.
5
Human Oriented Issues

• Success of Automating Processes depends on
• Personnel
• Organisational element
• Cultural elements
• There is a high initial cost to Process Centred
  Environment development and so if it does not
  meet developers requirements, it is likely to
  become shelf-ware.
• Some developers resent the controlling nature of
  Process Automation technology.
• Management must create an environment of trust
  and closely involve developers in the development
  and transition to the Process Centred Environment

6
Process issues for managers and developers

• Management need information and may view Process
  Automation in terms of better control of
  software process
• Developers use Process Automation for guidance
  and relief from menial chores so see it in a
  supporting role
• Process Automation can also assist developers in
  cooperative product development providing both
  support for and control of products e.g.
  automated Configuration Management, concurrent
  debugging

7
Fear of Process Automation

• Why developers fear Process Automation
• reduction of privacy
• loss of control over how one performs work
• de-skilling
• fear of redundancy

• Why managers fear Process Automation
• loss of control due to automated decision making
• loss of control due to introduction of
  self-directed work groups
• loss of control over information
• ignorance (fear) of new technology
• loss of status

8
Guidelines from Computer-supported Cooperative
Work

• Do not try to get too elaborate with
  sophisticated functionality
• aim for basic functions
• ease of access
• performance from the end user view point
• Use suitable analogies and metaphors
• If possible try to achieve seamless data and
  control integration between applications in
  Process Centred Environment
• Ensure system does not favour one group over
  others
• Design for adaptability as system must be
  adaptable to account for user experience

9
Selecting tasks for automation

• tasks that are well understood and stable
• tasks that have clear interfaces to and from
  other tasks
• tedious tasks
• tasks where manual involvement is error prone
• tasks with high amounts of routine communications
  
• high integrity tasks where conformance to process
  must be assured
• If individual in charge of process is hostile to
  PA then better to chose an alternative process.
  Once islands of PA have been built up, these can
  be bridged.

10
Other Issues

• Resistance to chance - Issues such as fear of job
  loss, being controlled by a machine, concerns
  over intrusive metrics should be discussed and
  everyone should buy in to an agreed solution
  e.g. metrics data should be used for process
  improvement and not for performance evaluations
• Process Ownership and Involvement - Philosophy
  should be to push responsibility down in the
  organisation - enpowerment

• Training - Both technical and non-technical
  issues must be addressed by training
• Organisational Context- Start at project level
  then standardise through out organisation
• Broad higher-level process models may be used to
  guide the organisation of lower-level processes
  and information flows but detailed low level
  process automation should be bottom up

11
The Personal Software Process (PSP)

• A self-improvement process designed to help you
• to control,
• to manage and
• to improve
• the way you work as a software engineer
• The PSP is a structural framework of forms,
  guidelines and procedures for developing
  software.
• Properly used, it provides historical data needed
  to make and meet development commitments and it
  makes routine elements of your work more
  predictable and more efficient.

12
Key points

• The Personal Software Process can be adapted to
  individual circumstances.
• Through Personal Software Process principles, it
  is possibleto define, measure and analyse your
  own process.
• With experience it is possible to improve (i.e.
  enhance) your processes to take advantage of new
  technology, tools and methods.
• Overall goal of Personal Software Process
  Understanding your own performance as a software
  engineer and determining how to improve your
  performance

13
Do-It-Yourself Professional Development Plan

• It relates problems to industrial software
  development to issues of professional discipline
  and describes how an individual can use
  disciplined methods to improve their performance
  as a software engineer.
• Basically the Personal Software Process is a
  self-improvement programme

14
The Rationale behind Personal Software Process
Improvement

• Software professionals will better understand
  what they do if they define, measure and track
  their work
• They will then have a defined process structure
  and measurable criteria for evaluating and
  learning from their own and others experiences

• Based on this knowledge and experience, they can
  select those methods and practices that best suit
  their particular tasks and abilities
• By using a customised set of orderly,
  consistently practical and high quality personal
  practices they will be more effective members of
  development teams and projects

15
4 Main Steps lead to the personal software process

• Identify those large-scale s/w methods and
  practices that can be used by individuals
• Define the subset of these that can be applied
  while working on small projects ie developing
  small programs
• Structure the methods and practices so they can
  be gradually introduced
• Provide exercise suitable for practicing these
  methods in an educational/professional
  development setting

16

Evolution of Personal Software Process Improvement
PSP 0 Current Process - Basic record keeping
Baseline
PSP 0.1 Coding standard, process improvement
proposal, basic measures
PSP 1 estimating, test report
Planning
PSP 1.0 task and schedule planning
Quality management
PSP 2 code design reviews
PSP 2.1 design templates
Repeat
PSP 3 Cyclic development iterative incremental
development
Anyone who is well versed in the Personal
Software Process has the basis for carrying out
Process Improvement in a software development
team and in an organisational context.
17
5 Principles behind the Personal Software Process

• A defined and structure process can improve
  working efficiency
• Defined personal process should fit the
  individuals skills and preferences
• For professionals to be comfortable with a
  defined process, they should be involved in its
  definitions
• As professionals skills and abilities evolve, so
  should their processes
• Continuous process improvement is enhanced by
  rapid and explicit feedback