Quality Management Principles - Assignment Example

Quality Management Principles Assignment Task I Professional and legal standards required of a computer professional The role of a computer professional is not limited to writing program code; as in any industry, certain professional and legal standards are in place for computer professionals (Sommerville 2008). Sommerville (2008) mentions some professional responsibilities of a computer professional: To respect employer and client confidentiality irrespective of the presence of a confidentiality agreement. To refuse work that is beyond ones level of competence. To constantly work towards protecting clients and employers intellectual property. To avoid computer misuse. The Association for Computed Machinery (ACM) and Institute of Electrical and Electronic Engineers (IEEE) have jointly developed "Software Engineering Code of Ethics and Professional Practice". Figure 1 is the shorter version of the code while the longer version can be found at the ACM Web site. Figure 1 ACM/IEEE code of ethics. Copyright (c) 1999 by ACM and IEEE. The British Computer Society has also published a "Code of Good Practice" and a "Code of Conduct" for its members. Apart from a common ethics, the code also has detailed description of designation-based ethics (BCS, n.d.). II Problems caused by the lack of compliance with standards Software developed without compliance with professional ethics could lead to failures. Some such systems include: London Ambulance Service Computer Aided Despatch System. The system was reported as a failure in October 1992. On enquiry several factors emerged - incomplete software, lack of adequate testing, high risk implementation approach, improper assumptions made during specification, no communication with users and clients during development, to name a few (Finkelstein & Dowell 1996). London Stock Exchanges TAURUS project. The International Stock Exchanges TAURUS project, which was planned as a database of investors and their holdings, was abandoned in the early 1990s. Research shows several factors are responsible for this failure: improper cost-benefit analysis, no defined template, too many stakeholders with rival interests. The project was awarded to a US company which attempted to customize the software for UK requirements, and a package that would have cost £1 million amounted to £14 million (International Stock Exchange: TAURUS Project n.d.). III Internationally Recognized Standard Certification for increased growth Internationally recognized standard certifications such as ISO 9000 seek to eliminate differences in quality standards between nations. An international standard certification implies adoption and usage of highly sophisticated quality management system in the organization. New technologies are promoted and both process and product development is improved. Regular quality audits ensure that all the processes are well defined, the right methods are adopted, and all the deliverables in product development are supplied. All these factors contribute to increased organizational efficiency, giving a competitive edge in the global market. Task 2 I Information System Development Methodology Since 1990s, Object Oriented Software engineering has become the method of choice for information systems development (Pressman 2001). In this approach, the developers characterize the problem domain as a set of objects with specific attributes and behaviours. Operations manipulate these objects while messaging protocols allow interaction between the objects (Pressman 2001). How does the method benefit Software Solutions R Us? As objects encapsulate both data and the applied processing, classes of objects can be built and libraries of classes and objects can be reused. Also, information is hidden and any side effects associated with changes, especially in the software maintenance stage, are minimized. Moreover, interfacing among encapsulated objects is simplified and system coupling is reduced (Pressman, 2001). Method Object oriented process is not limited to object oriented programming. All stages of software engineering are covered: analysis, design, development, database management systems, testing, and end user documentation. As object oriented systems evolve over time, an evolutionary process model works best for the system, especially along with component reuse (Pressman, 2001). Figure 2 demonstrates such a model. Figure 2 Object oriented process model (Copyright © Grady Booch, 1994) Systems documentation maintenance in analysis, specification, and design stages: As in any software engineering process, the software development life cycle of an object oriented process also has similar stages - conceptualization, requirements analysis, design, development and testing, and release. a. Capturing System Requirements Similar to traditional analysis, requirements are gathered and defined in the customer requirements document. Unlike traditional requirements analysis that focuses on the flow of data within a system, object oriented analysis captures system requirements on the basis of classes and objects found in the vocabulary of the concept. Documents: A data dictionary has a list of all required objects and classes with meaningful names. This dictionary contains all abstractions relevant to the system (Booch 1994). Class diagrams and object diagrams become part of the formal requirements analysis document that describes functioning of the system. b. Modelling of Static and Dynamic Behaviour of the system Booch (1994) defines object oriented design as a design method that covers the process of object-oriented decomposition and a notion for depicting both logical and physical as well as static and dynamic models of the system. In this stage, decisions are made about the representation of each abstraction and mapping these abstractions to a physical model. Documents: Class diagrams depict static behaviour and interaction diagrams depict dynamic behaviour. Use cases are developed to model system behaviour. Software requirements specification document contains descriptions of the new modules as well as the use cases. II Version Control, Indexing, Cross-referencing Version Control. All products of object-oriented process, including code and documents are placed in a configuration management tool. Groups of classes form the unit of version control. At any point, an individual works on a group of classes that map to a subsystem. When a set of subsystems become stable, they are frozen, baselined, and released internally. The individuals may work on a newer version of the subsystem while other teams use the stabilized version (Booch 1994). Indexing. The data dictionary, which lists all classes and objects, allows team members to browse through all the elements of a project. Newer team members use it as an index tool to learn about a project. Cross-referencing. Objects associate among themselves through links called messages. These links permit cross-referencing among objects. III Project plan Computer System Project Computer System Organization Software Solutions R Us Objective The objective of this project is to develop a computer system for Software Solutions R Us Description A computer system development project Team members Name Default role Mail Thomas Black project manager t.black@ssrus.com Helen Brown analysis h.brown@ssrus.com Mary White developer m.white@ssrus.com Jenny Gray developer j.gray@ssrus.com Abdul Kareem Tester a.kareem@ssrus.com Leena Matthews doc writer l.matthews@ssrus.com Sonia Paul packager (.rpm, .tgz, ...) s.paul@ssrus.com Timelines Figure 3 Timelines (Using Ganttproject) Deliverables Kick off Customer requirements document Analysis Data dictionary FRD Risk analysis report Design Use cases SRS Test plan Development Code Installers Release document Testing & Documentation Test cases Bug reports QA report End user documentation Implementation Installer Completion certificate Task 3 I Quality Assurance Procedure for Software Solutions R Us Quality Assurance Procedure would focus on two aspects: product quality and process quality. Process Quality: Process quality document specifies standards for a process in the system. All stages of the Software Development Life Cycle are covered. Product Quality: Product quality document focuses on all aspects of product quality - deliverables, document quality, code quality, test tools and standards. As the implementation of quality assurance procedures for the entire organization is beyond the scope of this assignment, I have focused on one process - document review. Three different people conduct reviews of documents in the organization. Effective implementation of the procedure has lead to: Catching of incorrect assumptions and project errors at the earliest stage. Improvement in all software engineering processes. Better quality documents. Quality Assurance Procedure Document Review Process 1. Purpose The purpose of this quality assurance procedure is to provide review guidelines for software documents. 2. Scope This process applies to all documents at Software Solutions R Us. 3. Responsibilities Responsibilities for the Document Quality Assurance group are as defined in the table below: No. Designation Responsibilities 1 Quality Analyst Technical Review 2 Project Manager Managerial Review 3 Documentation Expert Editorial Review 4. Reviewing documents A document that is ready goes through three stages of review: technical review to check the correctness of procedures, managerial review to check for professional standards, and editorial review for language and style. An approval is required at each stage, before proceeding to the next. After editorial review, no changes can be made to the document. 5. Approving documents On completion of review, the reviewer fills in the review checklist whose template is located in the configuration management software. The document is approved only if the reviewer is satisfied with the document quality. Corrections and recommendations are added in the respective text boxes located in the system. 6. Corrections The document owner should make the corrections and submit the document for review within 24 hours of receiving correction request. If the corrections take longer, the entire group should be informed of the reason for delay. 7. Templates Review Checklist: DRC.doc Review Approval: DRA.doc II Software Solutions R Us conforms to quality control tools The information system developed for Software Solutions R Us was built using object-oriented process and an evolution process model. Many quantifiable quality parameters exist, but we shall consider the defect-discovery rate. The defect-discovery rate for this system is that of a healthy project (Booch 1994). Defects are tracked during the life cycle according to severity and location. Frequency of errors is plotted against time and slope is measured. The system gives a graph with highest defect-discovery rate in the middle of software testing process. As the testing process allows early and continuous collection of possible defects, the graph obtained is bell shaped (Booch 1994). Bibliography ACM/IEEE. Software Engineering Code of Ethics and Professional Practice. Retrieved March 30, 2009 from http://www.acm.org/about/se-code. BCS. Code of Good Practice. Retrieved March 30, 2009 from http://www.bcs.org. Booch, G. (1994). Object-Oriented Analysis And Design, 2nd ed. CA: Addison-Wesley. Finkelstein, A. & Dowell, J. "A Comedy of Errors: the London Ambulance Service case study" in Proc. 8th International Workshop on Software Specification & Design IWSSD-8, (IEEE CS Press), 1996, 2-4. Retrieved March 30, 2009 from http://www.cs.ucl.ac.uk/staff/a.finkelstein/papers/lascase.pdf International Stock Exchange: TAURUS Project Case Facts. Retrieved March 30, 2009 from http://www.scit.wlv.ac.uk/~cm1984/qmp/failures/NINE.HTM Pressman, R.S. (2001). Software Engineering: A Practitioners Approach, 5th ed. New York: McGraw-Hill. Sommerville, I. (2007). Software Engineering, 8th ed. China: China Machine Press. Read More