Lecture 8

Process Quality: Management, Teams and QA

(Based on Stevens and Pooley, 2006, Chapter 20) David Meredith [email protected]

www.titanmusic.com/teaching/cis224-2006-7.html

CIS224 Software Projects: Software Engineering and Research Methods 1

Process quality

• Some defects in a product may be due to the development process – Need to evaluate process frequently and improve it when necessary • In this lecture, we consider

process quality

– Contribution made to quality of a system by • Organisation that builds it – Management – Leadership – Teamwork • Quality assurance processes 2

Management

• Two types of management important in software development – People management – Project management • Each type of management can be seen in two ways – Management as enabling activity – Management as (financial) control 3

Management as enabling activity

• Manager enables people working on task to get the job done • Minimises obstacles and risks, e.g., – Missing information – Inadequate training – Equipment lack – Unrealistic schedules – Mindless bureaucracy 4

Management as (financial) control

• Controls what happens with view to maximising organisation’s financial success • Primary goal is financial gain • High quality product, social contribution, ensuring satisfaction of employees and customers all only matter insofar as they indirectly promote financial success 5

Project management

• Project manager has overall responsibility for success of project • Responsibilities include – Analysing and controlling risk – Liaising with the customer and other parts of the organisation – Defining lines of communication between teams and between developers and customer – Employing and training the right people – Planning: schedule, cost estimate, quality plan – Assigning tasks – Measuring progress – Ensuring appropriate components, tools and techniques are used – Keeping project on schedule – Ensuring contractual obligations fulfilled – Ensuring that project implements lessons learned in previous projects and feeds back new experience into organisation’s other projects 6

Estimating an iterative project

• In waterfall process, clear milestones (end of analysis phase, end of design phase, etc.) • In iterative process, need to define goals for each iteration which could be particular subset of functionality • Beck’s

planning game

each use case (including design, implementation, testing and documentation) • Schedule estimation is always very difficult – Particularly with one-off custom systems that satisfy a particular customer’s needs – Schedule usually set long before developers have a good idea of what is required – Requirements change throughout a project – Customers pressure developers to promise delivery as early as possible, sometimes unrealistically quickly • Project manager must defend realistic schedule against customer’s impatience : estimate time required to realise 7

Managing component-based development

• Project manager should make sure that developers make good use of available components – Authorizing investigation and purchase of component libraries – Liaising with other departments on reuse – Ensuring effective reuse within project • If use case driven project, then must identify appropriate <> relationships between use cases to minimise duplication of effort • Development should be

architecture-centric

– Implies should be one person who is ultimately responsible for architectural decisions in project • Usually not project manager – Promotes unity of vision within project and coherence of system 8

People management

•

Matrix management

– Each person has a project manager and a personal manager – Personal manager responsible for career development, training, performance assessment, etc.

– Project manager determines work done on a particular project – Project and personal managers have different interests • Personal manager concerned with employee’s career development • Project manager concerned with success of project 9

Teams

• What makes a successful team?

– Team needs people who are good at • Seeing the customer’s point of view • Coming up with ideas • Finding flaws in ideas • Helping the team to stay focused on task • Making sure everyone’s voice is heard – Team should have good balance of skills – Team should get on with each other – Organisation should be happy and successful • Team usually has 3-8 people at lowest level – Keeps communication under control • Team should have clearly defined task • Team has team manager who manages interactions with other teams • Many software project failures arise from lack of communication – Some people think all communication should be controlled, passing through well-defined channels – Others think all communication should be open with project meetings to which everyone is invited • Individual roles within a team may or may not be well-defined 10

Leadership

• Leadership is not the same as management: – A manager is a smoother-down and a leader is a shaker-up • I prefer “A leader inspires, a manager facilitates” • Leaders – Know where they’re going – Have ideas on how to achieve their goals – Have “vision” – Stay focused on goal, sometimes to the exclusion of all other considerations • Leaders not necessarily good managers!

• Leadership important when reforming development process (e.g., changing from waterfall to iterative, functional to OO, etc.) 11

Quality assurance

• Quality assurance is – Convincing developers and customers that product will have high quality – Providing a basis for continuous improvement • Involves monitoring and improving development process to increase likelihood that high-quality software will be produced • Organisation usually has a

Quality Management System

(QMS) – Specifies structures and processes within an organisation for • Ensuring each project follows a high quality process • Ensuring process is continually improved using experience from previous projects – QMS may specify that each project should have a

quality plan

and define what should be covered in it • Quality plan prescribes aspects of overall project plan that are intended to ensure high quality – e.g., may define what design documents are to be produced and how they are reviewed – QMS also specifies how

quality audits

project adheres to quality plan are carried out to make sure

More on QA

• Organisation may acquire quality certification (e.g., ISO9001, BS5750) – Involves satisfying several external auditors – In some domains (e.g., defence, government) quality certification may be compulsory • Main point of QA is that documenting and measuring process used and how successful it is allows for process to be improved • Many quality management systems work against this by making it difficult to implement changes 13

Capability Maturity Model

• Company may classify its process as “CMM level

n

” where

n

is between 1 and 5 – CMM stands for “Capability Maturity Model”, a framework for process evaluation and improvement developed at Carnegie Mellon University’s Software Engineering Institute • Aims to improve process quality by – Documenting way work is performed – Measuring performance – Using data to control performance – Planning based on historical performance – Training people • CMM level 1 is defined as “ad hoc” where projects succeed through “individual heroism” • CMM level 5 indicates that an organisation makes quantitative evaluations of its projects and uses these to tune the process • CMM level 3 is about equivalent to ISO9001 and indicates that organisation has well-defined process but may not carry out quantitative evaluations of it 14

The case against QA

• If formalized QA is such a good thing, why aren’t all companies aiming for ISO9001 or high CMM levels etc.?

– Increasing bureaucracy and cost outweigh benefits – Documenting project makes it inflexible and less responsive • Less likely to make changes if have to be accompanied by lots of documentation – Formalized QMS discourages people from thinking independently about how to ensure high quality – Demoralizes best staff: best developers have to spend more time having meetings and writing documentation 15

• • • • • • • • • • •

Summary

To ensure high quality of product, should consider quality of process as well as that of product itself Two types of management – People management – Project management Two views of what management is – enabling activity - employees' effectiveness paramount – financial control - financial gain is paramount Role of project manager Estimating an iterative project – Beck's planning game Managing component-based development Managing people and matrix management – separating project management from personal management Teams – what makes it successful?

– Importance of communication Leadership vs. management A manager enables, a leader inspires Quality assurance – Quality management system – Quality certification – Capability maturity model – The case against QA 16