Lecture Software process improvement: Lesson 5 provide students with knowledge about: process models; software process; software engineering; process trade-off factors; process standardization; customization and standardization;... Please refer to the detailed content of the lecture!
Process Models Lecture # 5 Why Software Process? • Software development can be exceedingly complex and there are often many alternative ways to perform the various tasks • There is a need for a organized set of activities, which when performed accurately, will result in an orderly development effort Software Process • A defined process can help guide the software professionals through tasks, which can be performed in a number of ways, in an orderly way • This results in the establishment of a process definition they can understand Software Process • This enable software professionals to better understand – What they should do – What they expect from their coworkers, and what they are expected to provide in return • This allows them to focus on doing their jobs; contract between coworkers Software Process • Operational definitions are “something everyone can communicate about and work to” – Deming • They provides organizations with a consistent working framework while permitting individual adjustments to unique needs Software Engineering • Software engineering is not a routine activity that can be structured and regimented like repetitive manufacturing or clerical procedure • It is an intellectual process that must dynamically adjust to the creative needs of the professionals and their tasks; tradeoff is needed Process Tradeoff Factors 1 • Since software projects have differences, their software engineering processes must have differences as well • In the absence of a universal software engineering process, organizations and projects must define processes that meet their own unique needs Process Tradeoff Factors 2 • The process used for a given project must consider the experience level of the members, current product status and the available tools and facilities Process Standardization • Elaborate on the need to have standardization and the need to have individual creativity • Example: music, artistic painting, electrical circuits, etc • Let’s see what are the compelling reasons for process standardization Process Standards 1 • Process standardization helps to reduce the problems of training, review, and tool support • With standard methods, each project’s experiences can contribute to overall process improvement 10 Worldly or W Process Models • They specify who does what when • Where appropriate, they reference the A level that specifies standard task definitions or tool usage • For each task, W models define the anticipated results, the appropriate measures, and the key checkpoints 27 Atomic or A Process Models • “A” process models are enormously detailed • They are used to automate specific process activity or use a standardized method or procedure to guide execution of a task 28 Atomic or A Process Models • Precise data definitions, algorithmic specifications, information flows, and user procedures are essential at this level • The amount of details to be included in such models must be determined by their use • For example, an experienced developer who is repeating known manual tasks will not need as detailed a standard as a new trainee29 Atomic or A Process Models • When the task is to be automated, however, a great deal of detail is generally required • Atomic process definitions are often embodied in process standards and conventions, which can be treated as process abstractions in the higher level “W” or “U” process models 30 Relations of Software Process Models • U process models embody policies – What are policies? • W process models embody procedures – What are procedures? • A process models embody standards and/or tools – What are standards and/or tools? 31 Policies • Policies establish a high level framework and set of principles that guide the overall behavior of organizations • They are particularly helpful in unanticipated circumstances where no precedents have been established • Some policylevel statements might be: 32 Policylevel Statements 1 • All work will be subjected to an inspection before it is incorporated in a baseline • The quality of each product, at the time of new shipment, shall be better than its predecessor or leading competitor 33 Policylevel Statements 2 • All commitments for software cost or delivery will be supported by a documented and approved software engineering plan • Quality Assurance (QA) will review the software development process to assure senior management that the work is done according to established standards and procedures and in conformance with the intent of the stated policies 34 “W”level, Procedures • At the “W”level, procedures are established to implement the policies • This Wlevel process model refers to any available Atomiclevel standards that define precisely how tasks are to be performed 35 “W”level, Procedures • At the Wlevel, for example, a procedure might define the points at which Quality Assurance reviews are to be conducted and how resulting issues are to be handled • This might specify what percent of work is to be reviewed, how statistical samples are to be selected, and whether, when, how SQA independently tests or monitors the software engineering work as it is being done 36 Atomic level standards • Atomic level standards serve as the basis for directing the work and for the SQA review • For example, a code inspection standard would specify what code is to be reviewed, when, the methods to be used, the reports to be produced, and the acceptable performance limits 37 Atomic level standards • The developers would use this standard to guide their actions • The SQA people would review their actions and work products against this standard 38 Critical Software Process Issues • Quality • Product technology • Requirements instability – Unknown requirements – Unstable requirements – Misunderstood requirements • Complexity 39 Summary 40 References • Managing the Software Process by Watts S. Humphrey (Chapter 13.113.6) 41 ... A framework within which projectspecific software? ?processes are defined • Software? ?Process? ?Model – One specific embodiment of a? ?software? ?process? ? architecture 15 Software? ?Processes • Software? ?processes can be categorized ... Careful analysis results in … 16 Levels of? ?Software? ?Process? ? Models • Universal or U? ?Process? ?Models • Atomic or A? ?Process? ?Models • Worldly or W? ?Process? ?Models 17 Universal or U? ?Process? ?Models • U? ?process? ?models provide highlevel ... Definitions 1 • Software? ?Engineering? ?Process – The total set of? ?software? ?engineering activities needed to transform a user’s requirements into software 14 Definitions 2 • Software? ?Process? ?Architecture