MTAT Software Engineering Management

Transcription

1 MTAT Software Engineering Management Lecture 03: Principles of Software Modeling (Part A) & Rich es Spring 2013 Dietmar Pfahl

2 Homework 1: Introduction to SPI Administrative information: This homework has to be done individually. Maximum number of marks: 3 Submission deadline is Monday, 18-Feb-2013, at 17:00 sharp. If you don t submit in time, you receive a penalty as follows: Late delivery until Tuesday, 19-Feb-2013, at 17:00 -> 1 mark penalty (-33%) Late delivery after Tuesday, 19-Feb-2013, at 17:00 -> 3 marks penalty (-100%) Submit your homework as an attachment by to: dietmar.pfahl@ut.ee Put the following information in the subject line: [SE-Man] Homework 1: <Your Name> IMPORTANT: Only files in PDF format will be accepted! I won t look at files that are not PDF.

3 Structure of Lecture 03 Introduction to Modelling Exercise 2 Prescriptive

4 What is a (Software Development)? A defines Who is doing What, When and How to reach a specific goal. In software engineering the goal is to build a software product or to enhance an existing one and by the way An effective process facilitates efficient development of software with the required quality reduces risk and increases predictability promotes common vision and culture

5 Product Quality vs. Quality When software delivers incorrect results we do not modify the results but the software that produces them. When a process delivers incorrect products then common practice is to (only) modify the products, instead of the process.

6 Software Development Challenges Product quality poor... but what should we change to fix this? e.g., when/how do we introduce defects and when/how should we find them? Deadlines missed... but where do we lose all that time? e.g., do we lose most time during requirements negotiation, or during testing? (unit testing? system testing? regression testing?) Budget overruns... but what are the most expensive activities? e.g., are we spending most effort on coding or on rework/refactoring? Overhead... do we spend much effort on non-productive activities? e.g., how much effort is spent for collecting information (manually)? New employees... how should they learn how we work?... e.g., through trial and error or by more efficient means?

7 Information Needs What information do we need to answer the questions on previous slide: Which activities are performed in which sequence? Which are the inputs and outputs of these activities? Who is involed in a specific activity? What techniques/tools should be used? How long does it (typically) take to complete an activity?... How can we gather and maintain this information? We can ask experienced professionals or we need a precise and concise descriptions of the processes holding the required information!

8 versus Description Lee Osterweil, Software are es too (ICSE 1986): While a process is a vehicle doing a job, a process description is a specification of how the job is to be done. Thus cookbook recipes are process descriptions while the carrying out of the recipes are processes. A Model is a (semi-) formal representation of a Description

9 es Types of Product-Engineering es Engineering es -Engineering es Non-Engineering es Business es Social es Modeling es Software Knowledge Development es Maintenance es Project Mgmt es Quality Mgmt es Measurement es Improvement es Product Line es Conf Mgmt es Product... Quality Taxonomy Business... Social Engineering Life Cycle Life Cycle describe (classes of) activities of development processes at a high level of abstraction Technical Managerial Engineering Proc.

10 What are the Goals of Modeling? To enable effective understanding and communication At one development site (developers, teams,...) Between development sites (distributed development, outsourcing, contractor-supplier relations,...) To support project management Transparency, tracking,... To guide the developers Incorporating new employees To improve software development activities Improving real processes requires measurement and measurement requires defined processes Evolving processes To support reuse of process knowledge Organsational learning To support automatic process enactment Workflow support

11 What is a (Software) Model? Software Model: An abstract software process description. It can be more or less formal. [Lonchamp 93] Key elements:

12 Characterization of A Model defines: an identifiable activity or a group of activities or a hierarchy of activities the sequence/order of activities (-> control flow) the input/output products (artifacts) of activities (-> product flow) the resources (roles and tools/techniques/methods) needed the relations between activities, artifacts and resources

13 Definition: Performer, Owner, Engineer Performer or Agent (PA) := Person/Agent who enacts/executes the process in order to achieve the process goal(s) Humans interpret process scripts, machines interpret process programs scripts and process programs are user-specific process descriptions Owner (PO) := Person or organizational entity that sets the goals of a process and is responsible for its achievement The PO provides resources for the enactment/execution of the process, but s/he is not responsible for providing process definitions Engineer (PE) := Person who has to fulfill one or several goals of process modeling (e.g., process definition to guide developers) To that end, the PE uses process models, which s/he defines, extends, improves, and manages The PE should pay attention to the accuracy of the model, i.e., the correspondence between real-world process enactment/execution and process model

14 Example of a Script (textual representation) Note: descriptions for humans can be enhanced by graphical representations and be made accessible in the form of: Handbooks, Electronic Guides (web-guides with hyperlinks) and Wikis. (Excerpt taken from the ISPW-6 Software Example)

15 Typical Contents of Model Representations

16 Module developer Moderator Tester Quality assurer The Role Concept Examples of Role Activity Relations RASCI Matrix R = Responsible Roles A = Approve Role A role is in charge of one or more activities defined in one or more processes A role has defined competences & responsibilities Activities Module design Module coding Module review Module testing R R S, R S R A I S = Support C = Consult I = Inform Possible relationships between agents and roles 1 : 1 1 : m n : 1 n : m

17 Descriptive vs. Prescriptive How is it done? How should it be done?

18 Prescriptive vs. Descriptive Prescriptive (theoretical) Ideal (Assumed) best practice Often requires instantiation and detailing Deviations from real processes are likely Examples: waterfall, V- model, spiral model, incremental, iterative, evolutionary, agile process models Descriptive (empirical) Accurate elicitation of actual, real processes Basis for the revision of existing (prescriptive) process models based on observation and experience

19 Relationship between Descriptive and Prescriptive Modeling

20 The Four Domains Principle [Source: Heidrich, Münch, Verlage: Modeling, Lecture at Uni KL, Summer 2012, Chapter 1] (Model)

21 Structure of Lecture 03 Introduction to Modelling Exercise 2 Prescriptive

22 Exercise 2 Handout Task: Read the textual description of the process of surveying Customer Satisfaction using the Kano-Model Form a pair with a student sitting next to you and create a process model of the process of surveying Customer Satisfaction using the Kano-Model, i.e. Identify activities, artifacts, roles, tools/techniques/methods, and the relations between these entities Use either the graphical or the table notation shown on the next slide Give the resulting model to the course instructor

23 Exercise 2 (cont d) Model representations: Using product-flow notation Programm er uses consumes Design Implement Java Development Environment uses Activity Artifact Role produces Using table notation Method / Tool Code

24 Structure of Lecture 03 Introduction to Modelling Exercise 2 Prescriptive

25 Prescriptive How is it done? How should it be done?

26 Abstraction Levels of Prescriptive Pre-defined process models like Scrum, EVO, RUP, XP, Cleanroom... Inspires Organizational model models exist on 3 levels: family/standard level, organizational level, and project level Project (type) 1 process model Project (type) 2 process model Project (type) n process model

27 Families, Standards and De-facto Standards Maturity CMMI SPICE Engineering Life Cycle Waterfall Prototyping Spiral ISO Technical RUP XP V-Model XT Managerial Scrum Kanban Lean Engineering Proc. IEEE 1074 Incremental Life Cycle describe (classes of) activities of development processes at a high level of abstraction

28 Families Maturity CMMI SPICE Engineering Life Cycle Waterfall Prototyping Spiral ISO Technical RUP XP V-Model XT Managerial Scrum Kanban Lean Engineering Proc. IEEE 1074 Incremental Life Cycle describe (classes of) activities of development processes at a high level of abstraction

29 Waterfall: Royce Model (1970) Idea: Sequential creation of products on different levels of abstraction (e.g., precede code by design, precede design by requirements) and integration in reverse direction Strictly sequential control flow can be weakened by controlled iterations SYSTEM REQUIREMENTS PRELIMINARY DESIGN ANALYSIS PROGRAM DESIGN SOFTWARE REQUIREMENTS CODING PRELIMINARY PROGRAM DESIGN ANALYSIS PROGRAM DESIGN Prerequisites: Familiarity with application domains, methods, techniques, tools, engineering processes Good understanding of the requirements Stable requirements High capabilities for effort estimation CODING TESTING TESTING OPERATIONS USAGE

30 Prototyping An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions (Sprague and McNurlin) Main types: throw away prototypes evolutionary prototypes What is being prototyped? human-computer interface functionality Prerequisites: - Experience with development technology - Availability of technical infrastructure (e.g., HW) for evaluation Challenges: - Risk that non-functional requirements are not sufficiently well explored

31 Project Start Boehm s Spiral Model The spiral model proposed by Boehm (1988) is an iterative model with focus on risk resolution: Determine objectives and constraints Evaluate alternatives Identify risks Resolve risks after assigning priorities to risks Develop a series of prototypes for the identified risks starting with the highest risk Use a waterfall model for each prototype development ( cycle ) If a risk has successfully been resolved, evaluate the results of the cycle and plan the next round If a certain risk cannot be resolved, terminate the project immediately

32 Iterative Enhancement (Incremental Delivery) Origin: Basili und Turner, 1975 Idea: Split functionality into several increments Develop each increment (i.e., a product part that fulfills a subset of requirements) in a Waterfall style; integrate increment by increment into the product until delivery (release) The focus of the development of an increment might be completion of functionality or structure, but it can also be refinement and improvement Strictly sequential control flow can be weakened by controlled iterations Prerequisites: Structure of the problem permits incremental development

33 Incremental delivery delivered system design build install evaluate first incremental delivery design build install evaluate second incremental delivery design build install evaluate increment 1 increment 2 increment 3 Requirements third incremental delivery

34 Iterative Enhancement (Incremental Delivery) Advantages: Efficient learning during the project; thus, experience level can be low Early availability of a product, with the essential properties of the final product. Allows for early customer involvement and feedback Applicable when parts of requirements are (still) unclear or unstable Supports integration testing Good applicability in case of fixed delivery dates (-> prioritize requirements with the customer) Disadvantages: Risk that, by ignoring specific requirements, the product will be designed in such a way that fulfilling future requirements becomes difficult/expensive particularly problematic are non-functional requirements Comprehensive version and configuration management is necessary

35 Standards Maturity CMMI SPICE Engineering Life Cycle Waterfall Prototyping Spiral ISO Technical RUP XP V-Model XT Managerial Scrum Kanban Lean Engineering Proc. IEEE 1074 Incremental Life Cycle describe (classes of) activities of development processes at a high level of abstraction

36 ISO 12207: Standard for Information Technology-Software Life Cycle es This standard officially replaced MIL-STD-498 for the development of DoD software systems in August 1998 This standard defines a comprehensive set of processes that cover the entire life-cycle of a software system from the time a concept is made to the retirement of the software The standard defines a set of processes, which are in turn defined in terms of activities. The activities are broken down into a set of tasks. The processes are defined in three broad categories: Primary Life Cycle es Supporting Life Cycle es Organisational Life Cycle es

37 ISO es Primary life cycle processes: Acquisition process Supply process Development process Operation process Maintenance process Supporting life cycle processes: Audit process Configuration Management Joint review process Documentation process Quality assurance process Problem solving process Verification process Validation process Organisational processes: Management process Infrastructure process Improvement process Training process

38 ISO 12207: Development es

39 IEEE Std 1074 Standard for developing software life cycle processes (first published in 1997) Directed primarily at the process engineer (called architect in the standard) Defines a process for creating a software life cycle process (SLCP) in three steps: Select a (generic) software life cycle model (SLCM) to be used in projects Define details based on selected SLCM and associated reference activities Augment SLCM with Organizational Assets (OPAs) to create the desired SLCP

40 IEEE Std 1074: Generic Software Lifecycle

41 De-facto Standards Maturity CMMI SPICE Engineering Life Cycle Waterfall Prototyping Spiral ISO Technical RUP XP V-Model XT Managerial Scrum Kanban Lean Engineering Proc. IEEE 1074 Incremental Life Cycle describe (classes of) activities of development processes at a high level of abstraction

42 Rational Unified (RUP) Published by Jacobson, Booch, and Rumbaugh in 1998 (UP) Refined by Kruchten (UP > RUP) A generic process framework for software development Consists of generic description of phases and activities that must be adapted for different types of organisations, application domains, competence levels and project sizes Component-based: system is constructed from components interconnected via interfaces Use-case-driven: focuses on the end user during design, implementation, test Architecture-centric: embodying the most significant static and dynamic aspects of the system (4+1) Iterative and incremental: divides project into iterations, each iteration resulting in an increment that is added to the system

43 Rational Unified (RUP) Inception: creates a vision and business case for the final system Elaboration: specifies system s use cases and defines architecture Construction: builds the system, evolves the architecture Transition: system testing and debugging

44 RUP Static Static Structure of the A process defines who is doing what, how, and when. The RUP is represented using four primary modeling elements: Workers (Roles), the "who" Activities, the "how" Artifacts, the "what" Workflows, the "when" Activities, Artifacts, and Workers

45 RUP Resources and Workers (Roles) A worker defines the behavior and responsibilities of an individual, or a group of individuals working together as a team. You could regard a worker as a "hat" an individual can wear in the project. One individual may wear many different hats. The responsibilities we assign to a worker include both to perform a certain set of activities as well as being owner of a set of artifacts.

46 RUP Workflow Example: Analysis & Design Workflows A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram.

47 V-Modell XT (XT = Extreme Tailoring) Somewhat comparable to the role of PS 2000 in Norway Published in January 2005 Predecessor: V-Model (1997) for military authorities in Germany Structured in a modular way Mandatory for IT projects in public and military domains in Germany Goals: Enhance support for adaptability, scaleability, changeability, and expandability of V-Model 97 Consider state of the art and adapt to current regulations and standards Expand application range considering the complete system lifecycle of development projects Introduce a process of organizational process improvement

48 V-Modell XT: Model Elements

49 V-Modell XT: The Big Picture The German V-Model comprises four sub-models: System Development (SD) Quality Assurance (QA) Configuration Management (CM) Project Management (PM)

50 V-Modell XT System Development (SD) Sub-Model SD 2

51 V-Modell XT: System Development (SD) Sub-Model SD2: System Design Handling (Refinement)

52 V-Modell XT: System Development (SD) Sub-Model SD2: System Design

53 V-Modell XT: The Big Picture The German V-Model comprises four sub-models: System Development (SD) Quality Assurance (QA) Configuration Management (CM) Project Management (PM)

54 V-Modell XT: Project Management (PM) Sub-Model Activity Types: Management-related Initialization/Finalization Periodically Required Placement/Procurementrelated Planning-related Resource-related

55 Next Lecture Topic: Principles of Modeling (Part B) & Tools For you to do: Finish Homework 1 (if not yet done): deadline is today at 17:00 (sharp!) Send me the result of Exercise 2 (if not yet done) as soon as possible