INF5181: Process Improvement and Agile Methods in Systems Development

INF5181: Process Improvement and Agile Methods in Systems Development Lecture 12 September 2017: Standard software process models. Understanding processes and their contexts E-mail: dagsj@ifi.uio.no INF5181 / 2017.09.12 / Slide 1 Structure The concept of software process model Standard process models Choosing, adapting and improving software process models Understanding processes and their contexts Describing context Describing processes Describing outcome Exercise for group lecture INF5181 / 2017.09.12 / Slide 2 1

Process taxonomy What are typical processes in a software project? Product-Engineering Processes Engineering Processes Processes Process-Engineering Processes Non-Engineering Processes Business Processes Social Processes Process Modeling Processes Development Processes Project Mgmt Processes Measurement Processes Maintenance Processes Product Line Processes Quality Mgmt Processes Conf Mgmt Processes Improvement Processes INF5181 / 2017.09.12 / Slide 3 What is a model? Why do we create models? INF5181 / 2017.09.12 / Slide 4 2

12/09/17 Real process vs. model of a process System development process (=actual, real process) Those activities that are carried out in a development project Process model (= formal process) An abstract representation of a process. The model describes the process from a certain perspective A process model may be Descriptive: describes an actual process the way it is (model of) Prescriptive (normative): describes a process the way it should be* (model for) *The terms Process model are mostly used in the prescriptive meaning, also in this course INF5181 / 2017.09.12 / Slide 5 Formal Process model: What we say we do or what we should do INF5181 / 2017.09.12 / Slide 6 versus Real process Process execution: What we actually do 3

12/09/17 Descriptive vs. Prescriptive Process Models How it should be done? How it is done? INF5181 / 2017.09.12 / Slide 7 Process versus Process Model Lee Osterweil, Software are Processes 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. * = Prescriptive process model INF5181 / 2017.09.12 / Slide 8 4

Abstraction levels of process models Pre-defined standard process models like Scrum, Kanban, XP, Cleanroom... Inspire Organizational Process model Process models exist at 3 levels: standard level, organizational level, and project level (type and instance) Your INF5181 project Project (type) 1 process model Project (type) 2 process model Project (type) n process model INF5181 / 2017.09.12 / Slide 9 Abstraction levels of software process models Standard process models (Waterfall, V-model, Scrum, etc.) Process models Company/group process models Project process models Process conformance Real process Software (development) process INF5181 / 2017.09.12 / Slide 10 5

Why is process conformance important? (Process conformance = how well the actual process follows the formal process) How could that be relevant to your project in INF5181? INF5181 / 2017.09.12 / Slide 11 Structure The concept of software process model Standard process models Choosing, adapting and improving software process models Understanding processes and their contexts Describing context Describing processes Describing outcome Exercise for group lecture INF5181 / 2017.09.12 / Slide 12 6

Generality of process models Standard process models (waterfall, V-model, Scrum, etc.) General for all software development Company/group process models Project process models Tailored to a company/department/ group Tailored to a given project/situation (for example, using BPMN) INF5181 / 2017.09.12 / Slide 13 Project process model: INF5181 / 2017.09.12 / Slide 14 7

Well-known standard software process models Waterfall V-Model Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Agile / SCRUM Spiral The Waterfall model Idea: Sequential creation of products on different levels of abstraction (e.g., precede design by requirements, precede code by design) Controlled iterations are still acceptable Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance 8

Prerequisites for the Waterfall model The requirements are knowable in advance of implementation. The requirements have no unresolved, 1 high-risk implications, such as risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, and organizational impacts. The nature of the requirements will not change very much either during development or evolution. The requirements are compatible with all the key system stakeholders expectations, including users, customer, developers, maintainers, investors. The right architecture for implementing the requirements is well understood. There is enough calendar time to proceed sequentially (Barry Boehm 2000) INF5181 / 2017.09.12 / Slide 17 Evaluation of the waterfall model Advantages Easy to understand Well-defined stages make it clear who are responsible at each time and facilitates management Disadvantages Requirements and design risks are not discovered until late in the life cycle Inflexible with respect to, for example, changes in requirements Written definitions of requirements often lead to misinterpretations Working software is produced late INF5181 / 2017.09.12 / Slide 18 9

The V-model Prerequisites: As for the waterfall model Time *Figure from: Donald G. Common system and software testing pitfalls: how to prevent and mitigate them: descriptions, symptoms, consequences, causes, and recommendations. Addison-Wesley Professional, 2014 Evaluation of the V-model Advantages Easy to understand. Demonstrates the relationships between each phase of the development life cycle and its associated phase of testing Strong emphasis on testing, emphasizes early test planning Disadvantages Basically the same as for the waterfall model INF5181 / 2017.09.12 / Slide 20 10

The Spiral Model a meta model Idea: Early in the project, identify risks: what may prevent the project from reaching its goals and how likely is it that the event will occur Depending on the result of the risk analysis, choose process model (waterfall, V-model, Agile (Scrum, Kanban), etc. For example, if the assumptions of the waterfall model are present, use it. Often this is not the case, use Project Start Prerequisites: Ability to identify and categorize risks *One may go backward in the spiral Risk analysis Risks are situations or possible events that can cause a project to fail to meet its goals. They range in impact from trivial to fatal and in likelihood from certain to improbable. A risk management plan enumerates the risks and prioritizes them in degree of importance, as measured by a combination of the impact and likelihood of each. For each risk the plan also states a mitigation strategy to deal with the risk. For instance, the risk that technology is unready may be mitigated by an appropriate prototype implementation in an early spiral cycle. (Barry Boehm, 2000) 11

Evaluation of the Spiral model Advantages High amount of risk analysis. Hence, risk reduction Good for large and mission-critical projects Strong approval and documentation control Disadvantages Risk analysis requires highly specific expertise Project s success is highly dependent on the risk analysis phase INF5181 / 2017.09.12 / Slide 23 Incremental and iterative systems development (agile) An increment is a part that fulfills a subset of the requirements an aspect of the system An iteration is a cycle in the development an aspect of the process The purpose of an iteration may be to develop an increment but may also be to refine or improve an increment or the structure of the system INF5181 / 2017.09.12 / Slide 24 12

Incremental delivery delivered system design build install evaluate first incremental delivery design build install evaluate second incremental delivery increment 1 increment 2 design build install evaluate increment 3 Requirements third incremental delivery INF5181 / 2017.09.12 / Slide 25 Agile development with Scrum Incremental and iterative An iteration is called Sprint in Scrum More about this approach in later lectures 13

Choice, adaptation and improvement of software process models Standard process models (waterfall, V-model, spiral, Scrum, etc.) Choose and adapt Company/group process models Adapt Improve Project process models Improve INF5181 / 2017.09.12 / Slide 29 How to choose a standard process model? Most software organizations already have an existing standard process model as basis for their development If not: Consult developers, leaders, users, customers and possibly other stakeholders for their opinions Consult relevant literature that may indicate what may fit your organization INF5181 / 2017.09.12 / Slide 30 15

Example: Company Software Innovation Waterfall Scrum Kanban 2007 2010 More about their experiences with Scrum and Kanban later INF5181 / 2017.09.12 / Slide 31 Problem/Challenge/Opportunity identified in business Change initiated in business Change in business Change in organization, system and project Change of software process Change initiated in software process Change of software process Change in organization, system and project Change in business INF5181 / 2017.09.12 / Slide 32 16

Process and Project (Task) Outcome Software process Moderates Affects Project (Task) outcome System quality Time Cost Context (setting) INF5181 / 2017.09.12 / Slide 33 Processes must be adapted and improved No projects are equal No software teams are equal All aspects of a process/process model may be adapted and improved to fit the needs of your project or operational tasks INF5181 / 2017.09.12 / Slide 34 17

How to adapt and improve processes? Describe and understand: business organization project processes outcome (results) Elicit opinions of developers, leaders, users, customers and possibly other stakeholders Collect measurements and perform studies (later lectures) Update process models Document the adaptations and their justifications Software process adaptive capability may be an important organisational strength when deriving competitive advantage [Clarke et al. 2015] INF5181 / 2017.09.12 / Slide 35 Structure The concept of software process model Standard process models Choosing, adapting and improving software process models Understanding processes and their contexts Describing context Describing processes Describing outcome Exercise for group lecture INF5181 / 2017.09.12 / Slide 36 18

Suitability of processes (and methods and practices) depends on context (for example): Organizational setting: Size, competence, motivation, nationality, ownership, social and technological environment of development organization development team customer organization Project setting time (to market) resources/cost requirements, stability of requirements System setting quality criteria, size, complexity, application domain, criticality, etc. INF5181 / 2017.09.12 / Slide 37 Example of context factors, processes and outcome where four companies developed the same system independently B.C.D. Anda, D.I.K. Sjøberg and A. Mockus. Variability and Reproducibility in Software Engineering: A Study of four Companies that Developed the same System, IEEE Transactions on Software Engineering 35(3):407-429, 2009 INF5181 / 2017.09.12 / Slide 38 19

Organizational setting Aspect Variable Company A Company B Company C Company D Development org. Size (# employees) Appr. 8 Appr. 100 Appr. 25 Appr. 13,000 worldwide Nationality Domestic Domestic Domestic International Ownership By employees Private By employees Listed exchanges Location Bergen Oslo Oslo Oslo, 20 countries Formality of Light Intermediate Intermediate Heavy processes Development Size (# persons) 2 developers, 1 proj. 1 developer, 1 int. designer, 1 2 developers, 1 proj. manager 2 developers, 1 proj. manager team. manager proj. manager Allocation Part-time Part-time Part-time Full-time Co-location No No No Yes Turn-over No Change of No No Customer org. Skills Skills developer Moderate Moderate Moderate intended* intended * intended* Highly skilled, good understanding of requirements Moderate intended* INF5181 / 2017.09.12 / Slide 39 Skills of the development team Java developers selected by customer (us) based on CVs At least three years formal education in programming Three years of industrial experience with the technology used INF5181 / 2017.09.12 / Slide 40 20

Skills tested after projects Poor Good Poor A D C B B A Java Time UML Time A A2 C D2 B B2, A1, D1 D C2 C1 B1 Java Quality UML Quality Good Poor Good C D D C A B Good Poor Process matters Company C had the best Java programmers and next best UML developers. Company D had the best UML developers, but the poorest Java developers. Companies A and B had the poorest UML developers, B slightly worse than A. B had the next best Java developers Other factors of processes and their context explain more of the outcome than the skills of the developers INF5181 / 2017.09.12 / Slide 42 21

System setting Aspect Requirements spec. Application domain Functional size Complexity Description Fixed (information about empirical studies), 11 pages well-specified spec. Web-based information system Small (57 unadjusted use case points) Simple INF5181 / 2017.09.12 / Slide 43 Project setting Variable Company A Company B Company C Company D Firm price 8,750 20,000 45,380 56,000 Agreed time schedule 41 days 55 days 73 days 62 days Estimated effort 100 hours 220 hours 341 hours 650 hours Progr. language Tools Mainly Java, some Javascript, SQL, HTML, etc. IDE: Netbeans or Eclipse, Build & Deploy: Ant, CM: CVS INF5181 / 2017.09.12 / Slide 44 22

Structure The concept of software process model Standard process models Choosing, adapting and improving software process models Understanding processes and their contexts Describing context Describing processes Describing outcome Exercise for group lecture INF5181 / 2017.09.12 / Slide 45 Examples of process variables Aspect Variable A B C D Work hours Regular hours No Yes No Yes Language JSP usage High Low Low Low Issues with Project management Low High Medium Low customer Functional clarifications Low Medium High Medium before Graphical design Low Medium Low High acceptance Technical issues Medium Medium Medium Medium test Overall Low High High High Rework Deleted/Added Low High High Medium Emphasis on Activity and Phase Bugs in acceptance test Many Medium Medium Few Analysis & Design Low High High High Error correction Medium High Medium Medium Test Low Medium Medium High Tail heavy No No Yes No INF5181 / 2017.09.12 / Slide 46 23

Activity Sub-activity Hours Activity Sub-activity Hours Project(Management( Unspecified( 163( Project(Management( Project(Management( 59( Project(Management( Communication/Internal( Management( 48( Project(Management( Project(initiation(and(planning( 21( Project(Management( Communication/External( Management( 14( Project(Management( Project(meetings( 9( Project(Management( Initial(meeting( 6( Project(Management( Preparations( 4( Requirements( Unspecified( 16( Requirements( Use(case(diagrams( 4( Research(Contribution( Unspecified( 111( Research(Contribution( Logging(of(activities( 31( Research(Contribution( Interviews( 14( Research(Contribution( Copy(documents(and(code( 10( Research(Contribution( Wrap(up(activities( 1( Technical( Documentation( Unspecified( 73( Technical(Environment(Unspecified( 74( Establish(development( Technical(Environment( environment( 41( Technical(Environment(Establish(web(environment( 17( Technical(Environment(Establishment( 9( Technical(Environment(Establish(test(environment( 3( Technical(Environment(Establish(database( 2( Test( Unspecified( 47( Test( Accomplishment(of(test( 19( Test( Functional(test( 17( Test( Documentation( 6( Test( Planning(test( 4( Test( Testdata( 1( Training( Unspecified( 6( User(Documentation( Unspecified( 19( ( Hours 500 Hours spent of various activities 450 400 350 300 250 200 150 100 A B C D 50 0 INF5181 / 2017.09.12 / Slide 48 24

Relative emphasis of the activities Percent time 50 45 40 35 30 25 20 15 10 A B C D 5 0 INF5181 / 2017.09.12 / Slide 49 Emphasis along the way A B C D 25

Poor Good 900 880 860 840 820 800 780 760 740 720 700 680 660 640 620 600 580 560 540 520 500 480 460 440 420 400 380 360 340 320 300 280 260 240 220 200 180 160 140 120 100 80 60 40 20 0 Effort company (hours) Project quality (effort/cost & time) Effort customer (hours) Lead time (days) Overrun (%) Company INF5181 / 2017.09.12 / Slide 53 Communication with customer Customer effort (hours) Issues from companies Bugs in Acceptance Test Comp. A Comp. B Comp. C Comp. D Project manager 73 42 61 41 User representative 68 37 26 30 Technical support 13,5 10,5 21 13,5 Total 154,5 89,5 108 84,5 Project management 0 15 8 3 Functional clarifications 2 9 16 12 Graphical design 0 4 1 15 Technical issues 5 7 6 5 Total 7 35 31 35 85 68 71 37 INF5181 / 2017.09.12 / Slide 54 27

Choice of process INF5181 cannot teach which process (model) to choose in all cases, but we can to teach you how to evaluate suitability of processes INF5181 / 2017.09.12 / Slide 55 Exercise for group lecture 1. Characterize the processes that the companies used and indicate possible consequences. Did they work waterfall-like or agile-like? What seemed smart? What seemed not so smart? 2. Which company would you have chosen if you were the customer (justify your answer) INF5181 / 2017.09.12 / Slide 56 28

Topics next lecture Frameworks for process improvement Process evaluation and measurement INF5181 / 2017.09.12 / Slide 57 29