INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 1 IN5140 – Smart processes and agile methods in software engineering Lecture 19 August 2020: Course overview, Challenges in system development, System development processes Yngve Lindsjørn E-mail: ynglin @ifi.uio.no Antonio Martini E-mail : [email protected]
39
Embed
IN5140 –Smart processes and agile methods in software ...€¦ · agile methods in software engineering Lecture 19 August 2020: Course overview, Challenges in system development,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 1
IN5140 – Smart processes and agile methods in software engineeringLecture 19 August 2020: Course overview, Challenges in system development, System development processes Yngve Lindsjørn
About Me• Current position: Associate Professor at University of Oslo
– Agile and Lean Methods, – Teamwork in agile teams
• Education: – MSc, University of Oslo, 1987
• Work experience– University of Oslo (IFI) since 2010– OsloMet since 2012– Comptel (now Nokia), 2008-2010– Own company, Kompetanseweb, 2000–2008– Tieto Enator, 1997-2000– Norsk regnesentral 1987–1997
• Leading a large research project (TeamIT) from 2009 to 2014
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 3
Structure
• Part 1: Course information
• Part 2: Software development and challenges
• Part 3: Software processes
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 4
Topic: Agile, Lean and Process Improvement
Whole organization:
System development:
Lean processes
Agile/lean processes, methods and techniques
Process improvement
Scrum … Kanban
Software Process Improvement
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 5
Learning Outcomes
At the end of the course you will ...
• have gained a good understanding of modern software development processes, including Lean and Agile methods
• know characteristics and effects of different development processes (process models)
• be able to contribute to efficient organization, conduct and improvement of software development processes
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 6
Student Project
• Prepare a (realistic) software process improvement(SPI) plan for a software development organization
• What could be improved?– a process, – an activity of a process or – a method/technique used in an activity or a process– …
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 7
Project – Topic IdeasExamples of problems and related improvement goals:• Customers find too many defects – Improve software reliability • Inaccurate planning / estimates – Improve planning methods/models• New technologies or standards make their way into the market (e.g., TDD, MDD,
test automation, cloud computing, green computing) – Adapt existing processes to the new technologies and standards.
• Software is hard to maintain / difficult to evolve – Improve software architecture and associated processes
• Increasing competition – Speed-up development, issue releases more frequently• Customer are dissatisfied with deliveries – More customer participation and more
flexible process• “Old-fashioned", heavy development process – Modernize development
processes, methods, and tools• Little diffusion of competence, low motivation – Improve training & enhance
involvement of people
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 8
Project Case –System/Development Organization
• System/software development organization: real or fictional
• Suggested improvement actions must be clearly related to identified problems and defined goals
• Find a realistic approach to solving a realistic problem, challenge or issue. Use your imagination
INF5140 -> Lecture 2020.08.19 -> Intro -> Slide 9
Project Case
– Contact a software development organization– Not necessary to mention the organization’s name– If you find (or is involved in) a real-world improvement
project, don’t make yourself completely dependent on the reality, because a real-world project might have a longer time-frame than IN5140
– Alternatively, select one of the cases at the subsequent slides:
Case 1: Improving estimation practices to support portfolio managementProblem:An organization runs a number of software development projects in parallel. Every four months there is a review process in which it is decided which new projects that will be started and possibly which of the ongoing projects that will be stopped. Project estimates are important input to this review, together with a cost-benefits analysis, risk assessment and a project plan with the required resources. The organization has gradually come to feel that the review process of the portfolio managers is not good enough and that this is partly due to the projects estimates. Description of organizationApproximately 100 people are involved in software development. Portfolio management is performed by a special team that (among other tasks) meets and reviews project plans every 4 months.How the problem was identifiedManagement realized that there was a large delay between the identified need for new systems, or changes to existing systems, and the start-up of projects. Apparently because of a lack of resources. Few projects were stopped, and employees complained that they were actually idle much of the time. The portfolio management team realized that actual use of resources in the project had little resemblance to the initial estimates, and that the project managers documented their estimates differently, especially with respect to the uncertainty of the estimates.Goal:An estimation process should be implemented in the company to ensure that estimates are documented equally, that uncertainty is handled in a uniform way across projects and estimates that become more realistic, that is, the gap between estimates and actual effort is reduced.Current processThe projects follows a RUP-like process, but with the use of scrum within each iteration.There is no formal estimation process, but bottom-up estimation and planning poker is used. Estimates are seldom compared to actual effort used. Each time management attempts to do that, the projects managers get upset and claim that they cannot compare estimates and actual effort because there has been so many changes in requirements, plans and availability of resources.Current roles, activities, artifacts and toolsThe company typically has 5 to 10 ongoing projects staffed with business analysts, architects, developers, user interaction specialists, testers and project managers. Excel is the main tool for project planning.
Case 2: Improving the efficiency of software maintenance Problem:An organization has a large number of systems that are continuously maintained. Maintenance is defined as the work involved in user support, handling change requests, error correction and small functional enhancements and the deployment of new versionsof the systems to its users. The organization experiences that there is a growing back log of change requests from the users andfeels that the current maintenance process is too time consuming.Description of organizationApproximately 50 people work on maintaining 6 different systems. They are organized in 2 groups, each with of 3 teams. One group handles 3 systems, and the other group handles the other 3 systems. Each group has a manager and each team has a team lead. The teams are 1. User support who handles questions and requests from the users of the systems, 2. Requirements and test with functional specialists who specify new requirements for the system and subsequently test that these are fulfilled,and 3. Development with developers who correct errors and implement the required changes.How problem was identifiedThe organization was compared to other similar organizations in a benchmarking, and a result of the benchmarking was that it became clear that this organization spends a lot more effort than other similar organizations on software maintenance. In particular, much effort is spent on communication between the teams about the change requests and on sending these back an forth between the teams. Furthermore many defects slip through testing.Goal:The goal is a more efficient maintenance process where less time is spent on communication and defects are detected earlier.Current processThe current process is very similar to the V-model.Current roles, activities, artifacts and toolsThe change requests, called CRQs, are registered by User support in a system called Repair. Each CRQ contains a description of the problem and a suggested solution in the form of new requirements. When Development has implemented the requirements they tick off a box for development completed. Correspondingly a box for test completed is ticked off by Requirements and test when they have completed testing.
Case 3: Improving requirements handling for a software product lineProblem:A company maintains software for a product line of access control systems. When software is to be developed for a new kind of lock, a new project is set up. The company has no formalized process for requirements handling, so each new project tends to define their own way of documenting and handling requirements. This also means that requirements are not transferred in a systematic way when the system is set in production and the software is transferred to maintenance. Many requirements are similar across projects, but due to the lack of a formalized process for handling requirements the reuse of requirements from one project to another depends on the people who are involved. The company has recently experienced tougher competition and is looking at ways to become more competitive.Description of organizationThe company primarily consists of project managers, developers and product specialists, organized in projects. In addition some people are employed in administrative functions. How problem was identifiedThe company recently hired a new employee who told the management that in his former company requirements management was done in a more formalized way and that that increased their competitiveness.Goal:A formalized process for requirements handling that reduces time-to-market for new software products, and in particular reduces the necessary effort to start a projects.Current processScrum is used in development, but scrum relies on a back-log of requirements, for example in the form of user stories, and does not incorporate requirements handling.Current roles, activities, artifacts and toolsEach project has a project back-log in the tool Jira with user stories and tasks to be performed in the project.
– Improvement context (type of company, product, process) and improvement goal(s) (what? how much? when?)
– BPMN model of the existing process that you will improve (Deliverable 1)– Suggested changes of SW development process (What? / Old process vs. New process)– Implementation of process changes (When? Who is responsible?)– Monitoring/Control (Identify and describe measures to be used to assess effects of process
changes. Based on the improvement goal(s) in your project, use for example GQM to define a minimum of 3 measures, for each describe: Who will collect/report data? When (how often) will data be corrected? How is data collected, for example using which tools? How is data quality and validity ensured, who is for example responsible? Also discuss possible challenges related to data collection and data validity. Note that you do not have to actually collect all data for all the measures if practically difficult.)
Project: Groups• Group submissions, groups of two to four students
– You are allowed to form groups yourself. But we will also form groups if needed. Forming groups will start in the seminar group, Tuesday 12.15-14 (group teachers Steffen Almaas and Erlend Stenlund),
• Expectations– Same quality expected from individuals or groups– Length: 15-20 pages from 1 person, 18-23 pages from 2 persons,
20-25 pages from 3 persons, and 22-27 pages from 4 persons
What’s Special about Software?• Software is developed, not produced – every software
product is unique• Software development
– is a design process, – is often experimental, and– requires knowledge, skills and creativity
• Software is not tangible (not “physical”)– Natural laws irrelevant (only relevant for HW)– Often large design teams– High degree of flexibility/changeability of artefacts– Measurements of size, complexity and quality is not (yet?)
• One defect may be fatal!– Denver International Airport – baggage
handling system disaster: $ 560 Mio extra (1993)
– Ariane missile: € 0.5 Billion loss (1996)– The Y2K problem (2000)– Shutdown of LAX air-traffic controls (2004)– Lockheed’s F-22 Raptor stealth fighter jet:
systems switched off when crossing the date line (2007)
– UK air traffic centre: 6 years delay due to bugs– German Telecom: € 50 million in wrong bills– Postbank (NL): 55 000 double withdrawals– ... many other examples
K. El-Emam and A.G. Kouru. A Replicated Survey of IT Software Project Failures, IEEE Software, 25(5):84-90, 2008. (Available on theIN5140 lectures web page)
Source: Top Ten Lists of Software Project Risks: Evidencefrom the Literature Survey by TharwonArnuphaptrairong, Proceedings of IMEC 2011, March16-18, 2011, Hong Kong
Process Affects Properties of both Project and System being Developed
• The development process and the context in which it is performed affect the quality of project properties and the resulting system or product being developed
• The process also affects the work environment (work satisfaction, motivation, competence development, etc.), which in turn affects project and product quality