Software Development of Large Systems F1cs.lth.se/fileadmin/cs/ETSN05/PUSS_Lecture1_2015.pdf ·...

Software Development of

Large Systems F1HENRIK COSMO

Course teachers

http://cs.lth.se/ETSN05

Henrik Cosmo

Course leader, lectures

Anders Bruce,

Project, labs, ePuss-guru,

design expert

Hussan Munir

Exercises, project, test

expert

Alma Orucevic-Alagic

Project, labs, technical

expert

Lena Ohlsson

Course secretary

About me

• Q-Labs 1989-1996 Software engineering• Lic, LTH, 1991-1994 Software engineering• ENEA 1997 Software engineering• Ericsson 1998-2001 SW manager• Sony Ericsson 2001-2012 SW management team• Asurion 2012-2014 SW responsible APAC • Mobile Heights 2012-present Internet of Things• MAPCI 2012-present Internet of Things

• Have worked in most parts of software engineering.

• Mobile: 0720 23 56 09• Email: henrik.cosmo@cs.lth.se• LinkedIn: https://se.linkedin.com/pub/henrik-cosmo/a/549/11

My research interests

• Internet of Things

• Servitization

• Software engineering

Course background

Agenda of todays lecture

Part one:

• introduction

• course/project objectives

• course program

• course/project overview

• project roles

Part two:

• the product

• the task

• development model

Question

• How many lines of “production” code does the average

software engineer write per day?

Answer

• How many lines of “production” code does the average

software engineer write per day?

• Only between 10 to 20 lines of code

What does a software engineer do every

day in office?

What does a software engineer do every

day in office?

• Code maintenance

• Testing

• Writing new code

• Fixing bugs

• Understanding

existing code

• Working with clients

• Research

• Code reviews

• Email

• Design reviews

• Deployment

• Team meetings

• Documentation

• White boarding

• Monitoring

• Thinking

• Time writing

What is this course about?

• This course will teach you about the things a software

engineer is doing when not coding

Skills needed for software engineering

• Patience

• Communication

• Curiosity

• Listening

• Self driven

• Math/logic

• Enjoys challenges

• Experimental

• Organized

Software project failures

• Swedish police system – PUST 123 million SEK

• http://computersweden.idg.se/2.2683/1.547909/polisen-lagger-ner-pust

• 10 biggest ERP software failures of 2011

• http://www.computerworld.com/article/2500604/technology-law-regulation/10-biggest-erp-

software-failures-of-2011.html

• Only 3 of 10 IT projects are successful

• http://computersweden.idg.se/2.2683/1.15441/stort-missnoje-med-it-projekt---bara-3-av-10-

anses-lyckade

• How to recognize a failing IT project

• http://chef.se/sa-kanner-du-igen-ett-misslyckat-it-projekt/

• Swedish failing IT projects

• http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-

lupp

History – Waterfall 1970

• Huge problems with software disasters led to the study of

how high-quality software could be developed on a

predictable schedule and budget

• That resulted in a the definition of the first Plan-and-

document model called Waterfall model

• W. W. Royce defined the Waterfall model in 1970

• Steps

1. Requirements

2. Architectural design

3. Implementation and integration

4. Verification

5. Operation and Maintenance

Spiral model 1986

• It is easier for customers to understand what they want

once they see a prototype

• Engineers to understand how the system works after they

have done it once

• This lead Barry Boehm 1986 to define the Spiral model

• Steps

1. Determine objectives and constraints of this

iteration

2. Evaluate alternatives and identify and resolve risks

3. Develop and verify prototype for this iteration

4. Plan the next iteration

Rational Unified Process (RUP) 2003

• Inception: makes the business case for the software and

scopes the project to set the schedule and budget.

• Elaboration: works with stakeholders to identify use

cases, designs a software architecture, sets the

development plan, and builds an initial prototype.

• Construction: codes and tests the product, resulting in the

first external release.

• Transition: moves the product from development to

production in the real environment, including customer

acceptance testing and user training.

Agile models

• Agile software development is a group of software

development methods in which solutions evolve through

collaboration between self-organizing, cross-functional

teams.

– It promotes adaptive planning, evolutionary

development, early delivery, continuous improvement,

and encourages rapid and flexible response to

change.

• The Manifesto for Agile Software Development, also

known as the Agile Manifesto, first introduced the

term agile in the context of software development in 2001.

Agile manifesto - based on 12 principles1. Customer satisfaction by rapid delivery of useful software

2. Welcome changing requirements, even late in development

3. Working software is delivered frequently (weeks rather than

months)

4. Close, daily cooperation between business people and

developers

5. Projects are built around motivated individuals, who should be

trusted

6. Face-to-face conversation is the best form of communication

(co-location)

7. Working software is the principal measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10.Simplicity—the art of maximizing the amount of work not

done—is essential

11.Self-organizing teams

12.Regular adaptation to changing circumstance

Extreme Programming (XP)• Is intended to improve software quality and responsiveness to

changing customer requirements.

• It advocates frequent "releases" in short development cycles.

• Other elements of extreme programming include: – programming in pairs or doing extensive code review,

– unit testing of all code,

– avoiding programming of features until they are actually needed,

– a flat management structure,

– simplicity and clarity in code,

– expecting changes in the customer's requirements as time

passes and the problem is better understood,

– and frequent communication with the customer and among

programmers.

Scrum

• Is an iterative and incremental agile software

development methodology for managing product development.

• A development team works as a unit to reach a common goal",

encouraging physical co-location, as well as daily face-to-face

communication among all team members and disciplines in

the team.

Kanban

• Is a method for managing knowledge work with an

emphasis on just-in-time delivery while not overloading

the team members.

• In this approach, the process, from definition of a task to

its delivery to the customer, is displayed for participants to

see.

• Team members pull work from a queue.

Waterfall vs. Agile

• Pure waterfall models have gotten a lot of criticism due to

lack of customer communication through out development

• Agile methods are one answer to this criticism, but they

have other problems.

• Most projects in industry are still waterfall based

development. Very often a mix of the two is used.

• You have to choose the model that fits your needs.

– Start ups - Agile

– Large military projects – Waterfall with agile

influences

This course teaches Waterfall

• This course teach a waterfall model that can be tailored to

become more agile

• Due to

– That it is a good basis to understand all development

methods.

– Is the most used in industry.

– The trend is to move towards a mix of the two main

methods.

What is this course about?

Course and project objectives

Prepare you for large-scale, industrial software

development in teams.

Knowledge of:

• development processes

• project management

• central concepts from large-scale development

Experience with:

• problems in large projects

• possible solutions to problems

• experience one particular project role (hands-o

Important areas that you should know

about after the course

• Development models

• Requirements engineering

• Configuration management

• Test and quality management

• Project management

– Planning and follow-up

• Some basic software engineering terminology

Pedagogical approach

• Learning by doing: Case-based learning

• Simulate a real project in a typical large software

organization.

• Having issues is good for learning. Some issues may only

appear in some teams.

• Apply approaches used in current software engineering

practice, such as project management, process model,

milestones, reviews, etc.

Support

Compendia:

• project guide (PH)

• base system see course website

Lectures (4+1)

Exercises (3), Tool labs (2)

Experts (3+1): requirements, design, test

Section manager

Reviews (2+1)

Course compendium

Lectures, exercises, labs and reviews

Week 1 2 3 4 5 6 7

Lecture FÖ1 FÖ3 FÖ6

FÖ2 FÖ4

Exercise Ö1 Ö3

Ö2 Ö4

Labs TÖ1 TÖ2

Reviews Gr1 Gr2 Acc-test

Other deadlines and meetingsWeek 1 2 3 4 5 6 7

PG PSU,ESU LSU

PrM PrM PrM PrM PrM PrM PrM

KOM SMM SMM SMM SMM SMM

SG PSU,ESU LSU

PrM PrM PrM PrM PrM PrM PrM

KOM EM EM EM EM EM

UG PSU,ESU LSU

PrM PrM PrM PrM PrM PrM PrM

EM EM EM EM EM

TG PSU,ESU LSU

PrM PrM PrM PrM PrM PrM PrM

KOM EM EM EM EM EM

Project meetings = PrM PM, All

Section manager meeting = SMM PM

Expert meeting = EM PM, SG, UG, TG

Kick-off möten = KOM PG, SG, TG

Exercise sign-up = ESU All

Lab sign-up = LSU All

Project sign-up = PSU All

Document Timeline

Week 1 2 3 4 5 6 7

PG

SG

UG

TG

SDDD

SSD

PFR

PFR

PFR

PFR

SVVI

SDP

SRS

SRS

SVVS

STLDD

STLDD

SDDD

SVVR

Review: SSR

Baseline: SpecificationReview: PDR

Baseline: Design&Test

Review: PR

Baseline: Product

Reports

Week 1 2 3 4 5 6 7

PG TiR,WR,IA TiR,WR,IA TiR,WR,IA TiR,WR,IA TiR,WR,IA TiR,WR,IA TiR,WR,IA

RR RR RR

SG TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA

PR PR PR PR PR PR

UG TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA

TG TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA TiR, IA

TeR TeR TeR

Time report = TiR All

Status report = SR SG

Weekly report = WR PG

Review report = RR PG

Test report = TeR TG

Problem report = PR SG

Indivudual assignment = IA All

Lecture 5 in week 6

• Seminar on problems in large projects

• Discussions based on your input

• You can submit your discussions-points (will be kept

anonymous if preferred) as input to the lecture during

week 6 to

henrik.cosmo@cs.lth.se

• More information later

Assessment model

Project

What are we going to do on the course?

Development project

Development project

• Project managers

• Software architects

• Software developers

• Software testers

80 students have registered for the course

80/4 = 20 students per project

Build new software system

from a legacy system

Fundamental software engineering principlesDefining requirements, CCB, configuration management,

quality assurance, project planning, project follow up,

defining processes, roles and responsibilities, …

Development modelsPlan-and-document

Agile

The project task

• The course will be split into 4 teams to solve an Internet

of Things project task together

• Development of Android apps

The product

Some basic Use cases to be

implemented

• Turn on/off the lamp

• Change color of the lamp

• Activate/deactivate that the sensor sends data.

• Get sensor data for different sensor types (humidity,

temperature…) within chosen time intervals.

Project organization

• Project managers (PG)

• System Architects (SG)

• Developers (UG)

• Test Groups (TG)

”External” roles

Project management group (2 persons)

• Responsible for the group producing a result

• Plan, put together group, assign (and re-assign) tasks

• Identify configuration items

• Collect and report metrics data

• Report to the Section manager

• Put together the Software Development Plan (SDP),

• The System Specification Document (SSD) and the

Project Final Report (PFR)

Kick-off project managers:

Wednesday 02/09 17:00 (after the lecture) with Henrik Cosmo in

E:2405

System group (3 persons)

• Responsible for coordinating the technical work

• Handle the base system and interfaces

• Responsible for program library and error- and change reports

• Put together the

Software Requirements Specification (SRS),

Software Top Level Design Document (STLDD)

Software Detailed Design Document (SDDD)

• Do time reporting

Kick-off architects:

Thursday 03/09 12:15 with Anders Bruce and Alma Orucevic-Alagic in

E:2405

Developers (2 persons/team)

• Develop the requested new functionality

• Produce parts of the

Software Requirements Specification (SRS),

Software Top Level Design Document (STLDD)

Software Detailed Design Document (SDDD)

• Do time reporting

NO kick-off for your Group

Test group (2 persons/team)

• Responsible for testing

• Build new versions of the system before testing

• Create test files and carry out testing

• Produce the

Software Verification and Validation Specification (SVVS),

Software Verification and Validation Instruction (SVVI)

Software Verification and Validation Report (SVVR)

• Responsible for coordinating appendices

• Time reporting and error reporting

• A test manager must be appointed

Kich off with Hussan Munir on Wednesday 02.09 at 12:15 in E:2405

Experts and Section Manager

• Section manager -- SDP and PFR

• Requirements expert -- SRS

• Design expert -- STLDD and SDDD

• Test expert -- SVVS, SVVI and SVVR

• ePUSS-guru – Internet of Things system

People from Computer Science are experts and the Section

manager, customer (via the Section manager) and quality

evaluators (through reviews)

From requirements to code

Development model

Some software engineering concepts

(PH:1.2)

• Process, development model

• Configuration management, change management

• Requirements engineering

• Specification, analysis, design, implementation

• Review/inspection, validation ("Are you building the right

thing?"), verification ("Are you building it right?") and test

• Product documentation

• Project management, time planning, costs, resources

• Quality assurance

• Metrics (Metrics planning, -collection and -analysis)

• Characteristics, e.g. reliability

• Support system, CASE-tool

Administration

Signing up for the project

If you have doubts about taking the course – make up your

mind NOW!

Choose group via the homepage until Tuesday at 23.59

https://sam.cs.lth.se/LabsSelectSession?occasionId=3

84

Check your email often Tuesday/Wednesday, as your

project managers will call for the first group meeting

Sign up for exercises

• Exercises: no later than today at 18:00

• Labs: next week – check the course website for news

Lectures, exercises, labs and reviews

Week 1 2 3 4 5 6 7

Lecture FÖ1 FÖ3 FÖ6

FÖ2 FÖ4

Exercise Ö1 Ö3

Ö2 Ö4

Labs TÖ1 TÖ2

Reviews Gr1 Gr2 Acc-test

Sign up system

https://sam.cs.lth.se/LabsSelectSession?occasionId=384

To do before exercise session 1

• Mandatory preparation and participation on

exercises!

• Bring your computers if you have. This will help you

a lot during the exercise. If you do not have computer

with internet connection, please a print out of the

exercise!

• Prepare according to exercise preparation instructions.

Tentative project plan week1 (PH:C)

We are looking for project managers

We are looking for project managers!

The job requires: persistence, will to carry through,

discipline

The jobs gives:

• experience, overview, satisfaction

Previous experience not required, but merits are

appreciated. Talk to the Section manager during the break.

Email application to: Henrik.Cosmo@cs.lth.se

• No later than this afternoon at 18:00 !!!

Good to do this today!

• Read PH chap. 1 through 4.4 (before exercise 1)

– study carefully the tasks of all roles (PH:3)

• Get an overview of the development model (PH:A)

• Check out the course home page:

http://cs.lth.se/ETSN05

• Before your first project meeting

– check email often (project managers may call for

meetings)

• Give comments on what you would like to discuss on

lecture 5

Thank You

Questions?

Email Henrik.Cosmo@cs.lth.se