INF5180: Software Product- and Process Improvement in Systems Development

INF5180: Software Product- and Process Improvement in Systems Development

INF5180: Software Product- and Process Improvement in Systems Development Part 07: Processes and Process Modeling Dr. Dietmar Pfahl email: [email protected] Spring 2008 INF5180 – Spring 2008 Part 07: Processes and Process Modeling What is a (Software Development) Process? A Process … • defines Who is doing What, When and How to reach a certain goal. – In software engineering the goal is to build a software product or to enhance an existing one An Effective Process … • provides guidelines for efficient development of quality software • reduces risk and increases predictability • promotes common vision and culture Page 2 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Process Impact (source: Rombach) Process Performance ≈ f (Process, Goals, Context) can be determined by Product Availability and -empirical study (measurement) and Quality of Resources Project can be estimated by related Familiarity with - simulation Process and Application Domain Page 3 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling A Process Taxonomy Software Processes [Rombach & Verlage, 1995] Engineering Processes Non-Engineering Processes Product-Engineering Process-Engineering Business Social Processes Processes Processes Processes Technical Managerial Improvement Processes Processes Processes Development Development Modeling and Processes Processes (Re-)Planning Processes Life-Cycles Measurement Processes Reuse Processes Page 4 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling What is a (Software) Process Model? • “Software Process Model: An abstract software process description. It can be more or less formal.” [Lonchamp 93] • Key elements: Page 5 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling The Role Concept • Role – A role is in charge of one or more activities defined in one or more processes – A role has defined responsibilities – Possible relationships between agents and roles 1 : 1 1 : m n : 1 n : m Page 6 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Role Responsibilities RASCI Matrix R = Responsible Roles A = Approve S = Support Tester Quality assurer Moderator Activities Module developer Tester Quality assurer Moderator Module developer Module R C = Consult development I = Inform Module R coding Module S A review S, R Module Module R testing I Page 7 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Characterization of Process Models A Process Model defines: 27.Integration Test (Host) • an identifiable activity or a group of Customer Data Tools activities APS TSPA (from P3) 30.Customer Data Upgrade Test Protocol / Tool-Upgrade • a hierarchy of activities Specification • the control flow between activities Customer Data 28.Integration Test (Target) Data Delta • the input/output products of activities Conformance Test Cases Regression Test Cases • the product flow • the relations between activities and techniques, methods, tools, and roles Page 8 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling What are the Goals of Process Modeling? • To enable effective understanding and • To support project management communication – Transparency, tracking, ... – At one development site (developers, teams, • To guide the developers ...) – Incorporating new employees – Between development sites (distributed development, outsourcing, contractor-supplier • To support reuse of process relations, ...) knowledge • To improve software development activities • To support automatic process – Improving real processes requires enactment measurement and measurement requires – Workflow support defined processes – CASE tools – Evolving processes Page 9 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Descriptive vs. Prescriptive Process Models 27.Integration Test (Host) How is it done? Customer Data Tools APS TSPA (from P3) 30.Customer Data Upgrade Test Protocol / Tool-Upgrade Specification Customer Data 28.Integration Test (Target) Data Delta How should it be done? Conformance Test Cases Regression Test Cases Page 10 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Prescriptive vs. Descriptive Process Models • Prescriptive Models (theoretical) • Descriptive Models (empirical) – “Ideal” Process – Accurate elicitation of actual, – (Assumed) best practice real processes – Often requires instantiation and – Basis for the revision of existing detailing (prescriptive) process models – Deviations from real processes based on observation and are likely experience – Examples: waterfall, V-model, spiral model, incremental, iterative, evolutionary, agile process models Page 11 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Relationship between Descriptive & Prescriptive Process Modeling Process enactment Real world Model world Descriptive Prescriptive process modeling process modeling Description of the Process Description of observed process analysis constraints and guidelines for the process enactment Page 12 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Descriptive Process Modeling Page 13 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Goals of Descriptive Process Modeling • Understand the process • Support measurement – Explicit documentation – Describe, who can measure – Analyses (consistency, what and when completeness, complexity) – Collect quantitative information about processes, products and • Communicate (about) the resources process • Manage the process (and – Find agreement in case of conflicting opinions products) – Propagation of ‘Best Practices’ – Define goals (target values) and control the adherence to these goals. Page 14 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Steps of Descriptive Process Modeling 1. Formulate goals and scope of the task 2. Choose a conceptual schema (meta-model) 3. Choose a process modeling language / notation 4. Select or adapt tools 5. “Elicitation” 6. Create process model 7. Analyze process model 8. Analyze process Page 15 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Process Elicitation • Structured interview, 1-2 Hours Role 1 Role n • 2 interviewers • Separated by roles – no large groups – clear focus – manageable process models – no mutual interaction (horizontal and vertical hierarchic relations) Information Information • Perform interviews one after another, however not more than 3 interviews per day Process Page 16 Copyright 2008 © Dietmar Pfahl model INF5180 – Spring 2008 Part 07: Processes and Process Modeling Example Form for Structured Interview Scope Project, process name, role Project Activity Name Integration-Test (Target) Responsibility PL Input Products Entry Criteria -TSPA - Possibly Integration Test (Host) Input products and - Customer Data (by Customer Data Delta) -Input complete -APS - Hardware available - Conformance Test Cases - APS and Customer Data loaded - Regression Test Cases - Test time available entry conditions Activity Description - Conduct Integration Test on target according to TSPA Case A: Old Features (upgrade): - Regression Test (Tool: A8619 (PORIS) for SSW / USR for ASW) - Possibly, update of TSPA Test Cases Case B: New Features: - Manually conducted TSPA Test Cases Description of the process/activity - Recorded with A8619 (Poris) for SSW / USR for ASW - Conduct Conformance Test according to Standards with test tool K1197 - Defect correction Output Products Exit Criteria - Test Protocol (Part of TSPA) - Feature runs correctly on host - Regression Test Cases (updated) - No more test time available (Rem. by QM: this criterium is not permitted!!) Output products and exit conditions Copyright 2008 © Dietmar Pfahl Resources Page 17 - Developers - Support team of TK Systems etc. - A8619 (PORIS) -USR fürASW - K1197 -TK Systems -CSTA Test tool -CSTA-Spy Resources INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (1/3) • Obtain information about – the organization – the software domain • Analyze existing documents and products • Observe the relation between developers and quality assurance • Ask whether an ongoing or upcoming organizational restructuring impacts the process • Make sure that the interview partner is selected according to your instructions / guidelines • Begin the interviews with a quality manager or project manager Page 18 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (2/3) • Opening of Interview • Main part of Interview – Summary – Behave neutral – Explain goal and purpose – At first ask about the products – Stress confidentiality – Then ask about processes – General questions about the – What are typical (known) process, and existence of deviations from the prescribed variants processes? – Which other roles participate in the processes? (Cross-Check) – Always be precise – Try to identify process variants Page 19 Copyright 2008 © Dietmar Pfahl INF5180 – Spring 2008 Part 07: Processes and Process Modeling Rules for Process Elicitation (3/3) • Closing of Interview • Ask questions even when a noticed ambiguity seems to be small, often – Explain future

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    51 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us