U08784 Software Project Management

1. U08784 Software Project Management lecturer: Timothy Au email: timothykfau@yahoo.com url: www.geocities.com/timothykfau/2007/u08784

2. What have we learnt last week • In the last week lecture, we have learnt: • Risk Analysis Report • Risk Management (the lecture presentation slides) • The RMMM Plan

3. Lecture 6 • In this lecture, you will learn: • Software Quality Assurance 7 • Software Quality Concepts • The SQA Plan • ISO 9126 • Technical Review • Quality Requirements • Quality Plan (QP) • Quality Assurance Review (QAR)

4. Lecture Outcomes • You should be able to understand the following upon this lecture: • Quality requirement • Quality Plan • Quality Control • Quality Review • Project Milestones • Refine your project schedule according to your progress • Performing your project risk analysis and assessment • Preparing Quality Plan

5. Software Quality and Project Planning • Quality software • Quality will be of concerns at all stages of project planning and execution [Hughes Sec.12.2 p.258]

6. The Importance of Software Quality • The importance of software quality [Hughes Sec.12.3 p.260] • Criticality of software – especially reliability – organizations become more dependent on their computer systems and hence software reliability becomes critical. • Intangibility of software – how “good” it is when developers produce the “deliverables” to be examined for quality. • Accumulating errors (amplification effect) – during development, the later in the project that an error is found, the more expensive to recover from the error.

7. Software Quality • In the context of software engineering, software quality measures • how well software is designed (quality of design), • quality of design measures how valid the design and requirements are in creating a worthwhile product; • how well the software conforms to that design (quality of conformance) • quality of conformance is concerned with implementation (Software Quality Assurance),

8. Software Quality • Definitions • Tom DeMarco, "a product's quality is a function of how much it changes the world for the better". • This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality[1] • Steve McConnell's Code Complete • divides software into two pieces: internal and external quality characteristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are those that do not

9. What is Software Quality • What is software quality? [Hughes Sec.12.4 p.261] • Quality is a rather vague term, we need to define it (or quantify) more precisely in terms of software project. • There should be THREE specifications: • functional specification – describes what the system is to do. • quality specification – concerns how well the system is to perform. • resource specification – how much we can afford to spend on the system.

10. Software Quality Measures • Reliability • Mean-time-between-failure (MTBF) = Σ(down time – up time)/ number of failures= mean-time-to-repair (MTTR) + mean-time-to-fail (MTTF) • Availability– the percentage of time intervals that a system is usable = MTTF / (MTTF + MTTR) * 100% • Failure on demand – the probability that a system • Support – the number of fault report • Maintainability • Extendibility • …

11. Software Reliability • Software reliability is an important facet of software quality. • It is defined as "the probability of failure-free operation of a computer program in a specified environment for a specified time“. • One of reliability's distinguishing characteristics is that it is objective, measurable, and can be estimated, whereas much of software quality is subjective criteria. This distinction is especially important in the discipline of Software Quality Assurance. These measured criteria are typically called software metrics. • Software reliability in software development: • requirement • analysis • design • programming • testing

12. Software Testing • Software testing, should increase overall software quality of conformance by testing (if it is handled appropriately) that the product conforms to its requirements. • Testing includes the followings (but is not limited to): • Unit Testing • Functional Testing • Performance Testing • Failover Testing • Usability Testing • Agile methodologies is being used as early testing in the development cycle to ensure quality in their products • To ensure quality (development), test-driven development practice, tests are written before the code they will test, c.f. Extreme Programming.

13. Quality Plan • A quality plan can be used as a kind of checklist that all quality issues have been addressed. • A quality plan is prepared to ensure the quality management system is understandable and to be observed by all project team members. • Quality activities are implemented as described in the quality plan for each development project phase according to the quality management system.

14. Quality Plan • A quality may have the following contents: • Purpose, Scope of Plan • List of Reference • Management arrangement, organization, tasks and responsibilities • Documentation to be produced • Standards and Practice, Conventions • Reviews and audits • Testing • Problem Reporting and Corrective action • Tools, Techniques and Methodologies • Code, Media and Supplier Control • Record Collection, Maintenance and Retention • Training • Risk Management

15. Quality Requirements • Project teams are required to consider the following quality requirements: • Project Planning, • Quality Planning, • Requirement Review, • Development Planning, • Design and Implementation, • Testing and Validation, • Acceptance, • Delivery and Installation, • Maintenance, • Configuration Management, • Document and Data Control, • Training

16. Quality Requirements • Project Planning • Plan, monitor and control project in accordance with "Projects IN Controlled Environments" (PRINCE) Methodology • Estimate resources using Function Point Analysis (FPA) and other appropriate methods • Quality Planning • Follow the Quality Planning (QP) Procedures and Quality Assurance Review (QAR) Procedures in ensuring that all products and/or services produced satisfy user requirements • Maintain accurate and legible quality records • Requirement Review • Clearly define user requirements and produce user requirement specifications • Conduct review of requirements • Development Planning • Plan with considerations on development methodologies to be applied such as Structured Systems Analysis and Design Methodology (SSADM), Rapid Application Development (RAD) and Object Oriented Methodology (OOM) • Design and Implementation • Use methodologies such as SSADM, RAD, OOM and its related tools in transforming user requirements into an application system product

17. Quality Requirements • Design with consideration on Interoperability Framework • Apply and follow work steps, verification processes, standards and procedures; and produce required inputs and outputs according to SSADM, RAD, OOM and PRINCE • Produce implementation documents according to the Documentation Standards • Testing and Validation • Follow the Guidelines on Application Software Testing • Perform test planning and control, produce test documentation, apply test tools and techniques and follow checklists for different levels of testing • Acceptance • Organize acceptance test to determine whether the finished system meets the user requirements and is acceptable to the user • Assist user to prepare acceptance test plan and specification • Delivery and Installation • Oversee site preparation, hardware and software installation, and operating environment set-up; produce documentation; arrange training and hand over of system to operation • Maintenance • Follow the standard procedures as stated in the Guidelines on System Maintenance Cycle • Configuration Management • Follow the standard procedures as specified in Software Configuration Management Process Guide • Document and Data Control • Produce master lists to properly control all documents and data related to the project and the system • Produce documents and data as required under PRINCE, FPA, SSADM, RAD, OOM and QM • Produce documents according to Document Style Manual if applicable • Training • Train staff and users adequately to perform their task.

18. Quality Management • The Quality Manual • It defines the organization, policies and principles of the Quality Management System (QMS) that is applied to the software development. • It also defines the responsibilities and authorities for those manage, perform and verify the quality work and the effective implementation of such quality system.

19. Quality Management • The Quality Management System (QMS) applies to activities in all software development project, including the following SDLC phases: • Project Initiation Phase • Feasibility Phase • Systems Analysis & Design Phase • Implementation • Post-implementation Phase

20. Quality Management • The Quality Management System (QMS) Documentation includes: • Project Initiation Phase • Feasibility Phase • Systems Analysis & Design Phase • Implementation • Post-implementation Phase

21. Quality Planning • Quality Planning Procedure • Project manager defines the quality related requirements including the tasks, standards, responsibilities and resource requirements at project planning throughout the system development life cycle. • A standard Quality Plan which makes reference to various procedures, standards and practices defined as the Quality System in the Quality Manual for the software project is used as a framework for project quality planning. • Project manager tailors the procedure and standard framework the plan to fit the project purpose. • Using the assistance of this tailor-made standards and procedure, the project manager will define the Project Quality Plan specific to his/her project and ensure compliance to the Quality System. • This procedure is also used as a supplement to the quality planning activities of PRINCE.

22. Quality Assurance • Software quality include the following factors: • Safety • Security • Reliability • Resilience • Robustness • Understandability • testability • Adaptability • Modularity • portability • usability • Reusability • Efficiency • Learnability • completeness • conciseness • consistency • maintainability • Structuredness

23. Quality Assurance Review • The Quality Assurance Review Procedure establishes the minimum requirements and procedure of formal quality assurance processes for projects • The objectives of this document are to establish standards for : • the quality assurance requirements (and the resources required for the quality assurance activities) in the project quality plan; • Identify the quality assurance Checkpoints and the responsibilities of personnel and parties performing the verification; • procedure to verify quality controls of products against requirements and standards; • document the review results; • monitor the processes and products during system development; • provide evidence that the completed product conforms to the requirements.

24. Quality Assurance Review • Quality Assurance Review (QAR) contains the following checkpoint reviews: • Project Initiation • Feasibility Phase End of Phase Review • Systems Analysis & Design Phase End of Phase Review • Implementation End of Phase Review • Post-implementation Pre-production Review • The objective is to ensure that the requirements are met and handled; appropriate standards and methodologies are employed effectively throughout the design and implementation.

25. Quality Control • Quality Control involves • Inspection • Review • Testing • Throughout the software development process to ensure the work meets or exceeds the customer requirement.

26. Quality Control and Quality Assurance • Definitions • Quality Control is the process by which product and/or service is compared with applicable standards according to the quality management system. • Actions will be taken when non-conformances are detected. It is the responsibility of the workers. • Quality Assurance is a planned and systematic set of activities necessary to produce sufficient confidence that the requirements are met and that the products and/or services conform the specific quality requirements. • It may be called quality control over quality control because it evaluates whether quality control is working. It is the management responsibility