This preview shows page 1. Sign up to view the full content.
Unformatted text preview: CHAPTER-2 A GENERIC VIEW OF PROCESS Chapter Overview What? A software process a series of predictable steps that leads to a timely, high-quality product. Who? Managers, software engineers, and customers. Why? Provides stability, control, and organization to an otherwise chaotic activity. Steps? A handful of activities are common to all software processes, details vary. Work product? Programs, documents, and data. Correct process? Assessment, quality deliverable. 2.1 Software Engineering-A Layered Technology tools methods process model a "quality" focus QUALITY:Any engineering approach must rest on an Organizational commitment to quality. The bedrock that supports software engineering is a quality focus. PROCESS:Process defines a frame work that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products( documents, models, data, reports, forms, etc.) are produced, milestones are established, quality is ensured and change is properly managed. METHODS:S/W engineering methods provide the technical "how to' s" for building s/w. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing and support. Tools:Software technology tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the software development, called Computer-Aided Software engineering is established. 2.2 A Process Frame Work
A Process framework establishes the foundation for a complete software process identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. A Common Process Framework
process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities The process framework encompasses a set of Umbrella activities that are applicable across the entire software process. The following generic (common) process framework is applicable to the vast majority of software projects: Communication (customer collaboration and requirement gathering) Planning (establishes engineering work plan, describes technical risks, lists resource requirements, work products produced, and defines work schedule) Modeling (creation of models to help developers and customers understand the requires and software design) Construction (code generation and testing) Deployment (software delivered for customer evaluation and feedback) Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management Attributes for Comparing Process Models Overall flow and level of interdependencies among tasks Degree to which work tasks are defined within each framework activity Degree to which work products are identified and required Manner in which quality assurance activities are applied Manner in which project tracking and control activities are applied Overall degree of detail and rigor of process description Degree to which stakeholders are involved in the project Level of autonomy given to project team Degree to which team organization and roles are prescribed 2.3 Capability Maturity Model Integration (CMMI) The CMMI defines each process area in terms of "specific goals" and the "specific practices" required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of process-related activities. 1. 2. The CMMI represents a process meta-model in two different ways: Continuous model Staged model. Capability levels:Level 0: Incomplete. The Process area is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability. Level 1: Performed. All of the specific goals of the process area have been satisfied. Work tasks required to produce defined work production are being conducted. Level 2: Managed. All work associated with the process area conforms to an organizationally defined policy; All people doing the work have access to adequate resources to get the job done; Stakeholders are actively involved in the process area as required; All work tasks and work products are "monitored, controlled, and reviewed; Level 3: Defined. The process is "tailored from the organization's set of standard processes according to the organization's tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets" . Level 4: Quantitatively managed. "Quantitative objectives for quality and process performance are established and used as criteria in managing the process". Level 5: Optimized. The process area is adapted and optimized using quantitative means to meet changing customer needs and to continually improve the efficacy of the process area under consideration. The specific goals (SG) and specific practices (SP) defined for project planning are:SG 1: Establish estimates SP: 1. Estimate the scope of the project 2.Establish estimates of work product and task attributes. 3. Define project life cycle. 4. Determine estimates of effort and cost. SG 2: Develop a project plan SP: 1. Establish the budget and schedule 2. Identify project risks 3. Plan for data management. 4. Plan for project resources. 5. Plan for needed knowledge and skills. 6. Plane stakeholder involvement. 7. Establish the project plan. SG 3: Obtain commitment to the plan SP: 1. Review plans that affect the project. 2. Reconcile work and resource levels. 3. Obtain plan commitment. The Generic goals (GG) and practices (GP) for the project planning process area are: GG 1: Achieve specific goals GP: 1. Perform base practices. GG 2: Institutionalize a managed process GP: 1. Establish an organizational policy 2. Plan the process. 3. Provide resources. 4. Assign responsibility. 5. Train people. 6. Manage configurations. 7. Identify and involve relevant stakeholders. 8. Monitor and control the process. 9. Objectively evaluate adherence. 10. Review status with higher level management. GG 3: Institutionalize a defined process GP: 1. Establish a defined process. 2. Collect improvement information. GG 4: Institutionalize a quantitatively managed process. GP: 1. Establish quantitative objectives for the project. 2. Stabilize subprocess performance. GG 5: Institutionalize a Optimizing process. GP: 1. Ensure continuous process improvement. 2. Correct root cause of problems. 2.4 Process Patterns Process Patterns define a set of activities, actions, work task , work products and /or related behaviours. Templates or methods for describing important characteristics of software processes . Examples:- Customer Communication( Process activity ) Analysis( An action ) Requirement gathering( Process task ) Design model ( Work Product ) Software teams can combine software patterns to construct processes that best meet the needs of specific projects Generic software pattern elements : Pattern Name Intent (objective of pattern) Type Task pattern (defines engineering action or work task) Stage pattern (defines framework activity for the process) Phase pattern (defines sequence or flow of framework activities that occur within process Initial context (describes conditions that must be present prior to using pattern) Problem (The Problem to be solved by the pattern is described). Solution (describes how to implement pattern correctly) Resulting context (describes conditions that result when pattern has been implemented successfully) Related patterns (links to patterns directly related) Known uses/examples (instances in which pattern is applicable) 2.5 Process Assessment
The Process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment option are available. -SCAMPI -CBA IPI -SPICE -ISO 9001:2000 Standard CMMI Assessment Method for Process Improvement (SCAMPI):It provides a five-step process assessment model that incorporates initiating, diagnosing, acting, establishing learning. CMM-Based Appraisal for Internal Process Improvement (CBA IPI):Provides a diagnostic technique for assessing the relative maturity of a software organization. SPICE (ISO/IE15504): SPICE (ISO/IE15504) standard defines a set of requirements for process assessment ISO 9001:2000: ISO 9001:2000 for Software defines requirements for a quality management system that will produce higher quality products and improve customer satisfaction Assessment and Improvement
Identifies Modifications to Is examined by Software Process Assessment Leads to Leads to Identifies capabilities and risk of Software Process Improvement
Motivates Capability Determination 2.6 Personal and Team Process Models
1. Personal Software Process (PSP):- The Personal Software Process (PSP) emphasizes personal measurement of both the work product that is produced and the resultant Quality of the work product . What is PSP?
The Personal Software Process shows engineers how to 1. Manage the quality of their projects. 2. Make commitments they can meet. 3. Improve Estimating and Planning. 4. Reduce defects in their products. The PSP can be used by engineers as a guide to a disciplined and structured approach to developing software. The PSP can be applied to many parts of the software development process, including small-program development requirement definition document writing systems tests systems maintenance enhancement of large software systems The PSP process model defines the five framework activities:
1. 2. 3. 4. 5. Planning:- This activity isolates requirements. High-Level Design:-External Specifications. High-Level Design Review:-Formal verification. Development:- The component level design. Postmortem:- The effectiveness of the process is determined. 2. Team Software Process (TSP):The goal of TSP is to build a "Self-Directed" Project team that organizes itself to produce highquality software. What is TSP?
The Team Software Process (TSP), along with the Personal Software Process (PSP), helps the high-performance engineer to 1. Ensure quality software products 2. Create secure software products 3. Improve process management in an organization Objectives of TSP: Build self-directed teams that plan and track their work, establish goals, and own their processes and plans Show managers how to coach and motivate their teams and maintain peak performance Accelerate software process improvement by making Level 5 behavior normal and expected Provide improvement guidance to high-maturity organizations Facilitate university teaching of industrial team skills TSP defines the following framework activities: 1. Launch 2. High-Level Design 3. Implementation 4. Integration and test 5. Postmortem. Each project is "launched" using a sequence of tasks To establish a solid basis for starting the project. Review project objectives with management and agree on and document team goals. Establish team roles. Define the team's development process. Make a quality plan and set quality targets. Plan for the needed support facilities. Make a development plan for the entire project. Make detailed plans for each engineer for the next phase. Merge the individual plans into a team plan. Rebalance team workload to achieve a minimum overall schedule. Assess project risks and assign tracking responsibility for each key risk. 2.7 Process Technology Tools Used to adapt process models to be used by software project team Allow organizations to build automated models of common process framework, task sets, and umbrella activities These automated models can be used to determine workflow and examine alternative process structures Tools can be used to allocate, monitor, and even control all software engineering tasks defined as part of the process model 2.8 Process and Product. ...
View Full Document
- Spring '10