1 / 16

CIS224 Software Projects: Software Engineering and Research Methods

CIS224 Software Projects: Software Engineering and Research Methods. David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2006-7.html. Lecture 8 Process Quality: Management, Teams and QA (Based on Stevens and Pooley, 2006, Chapter 20). Process quality.

donnan
Download Presentation

CIS224 Software Projects: Software Engineering and Research Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2006-7.html Lecture 8 Process Quality: Management, Teams and QA (Based on Stevens and Pooley, 2006, Chapter 20)

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

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

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

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

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

  7. 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: estimate time required to realise 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

  8. 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 <<include>> 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

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

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

  11. 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.)

  12. 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 are carried out to make sure project adheres to quality plan • QMS specifies how improvements are proposed, validated and rolled out

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

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

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

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

More Related