cis224 software projects software engineering and research methods n.
Skip this Video
Loading SlideShow in 5 Seconds..
CIS224 Software Projects: Software Engineering and Research Methods PowerPoint Presentation
Download Presentation
CIS224 Software Projects: Software Engineering and Research Methods

Loading in 2 Seconds...

play fullscreen
1 / 16

CIS224 Software Projects: Software Engineering and Research Methods - PowerPoint PPT Presentation

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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CIS224Software Projects: Software Engineering and Research Methods David Meredith 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