Course summary

Software engineering????

Software engineering include all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use.

kilde: Sommerville 2004

Software Engineering key elements

Engineering discipline: • Apply theories, methods and tools where these are appropriate• Use them selectively and always try to discover solutions to

problems• Look for solutions within organizational and financial constrains

All aspects of software production:• Not just technical processes • Include software project management and development of

tools, methods and theories to support software production

Course objectives

The aim of the course is to provide the students knowledge about major issues related to software developing processes, and enable the students to evaluate and compare different methods and approaches.

– After having read the course you should: – Have an overview of the basic problems software engineering

methods address (such as the development process, quality assurance and configuration management), and be able to discuss the pro and cons of different method and approaches.

– Know a range of criteria to be considered when selecting methods, processes and tools and understand how the criteria influence the selection.

– Be able to apply the criteria in order to evaluate and select methods and approaches to address problems in practice.

Course content- three mandatory topics and three electives

• Software development processes• Quality assurance• Change and configuration management • Virtual teams – addressing issues related to

software development in distributed and heterogeneous (global) teams.

• Software process improvements • Contemporary software development

methods (flexible, agile, rapid)

Guide to the Software Engineering Body of Knowledge

2004 Version

SWEBOK®Executive Editors

Alain Abran, École de technologie supérieureJames W. Moore, The MITRE Corp.

EditorsPierre Bourque, École de technologie supérieureRobert Dupuis, Université du Québec à Montréal

Project ChampionLeonard L. Tripp, Chair, Professional Practices Committee,

IEEE Computer Society (2001-2003)http://computer.org

Los Alamitos, CaliforniaWashington • Brussels • Tokyo

This guide is aimed at providing a topical access to the core subset of knowledge that characterizes the software engineering discipline

Software development processes

Different software process stereotypes

• Waterfall model• V-model• Incremental model• Partly incremental model• Component based models• Spiral model/explorative or iterative• Agile methods

Design as a mediated activitySoftware Engineering as design of a design activity

• Design of computer artifacts can be understood as an activity oriented to changing another activity through the construction and introduction of new (computer) artifacts

• The basic assumption is that design is a heteropraxial activity, i.e. involving groups of people with different backgrounds and different motivation for participating in the process – Differences in professional background, training and interest means

that the different parties never achieve full explicit understanding of each other

– Success can be attributed to successful acting together without explicit shared understanding

– Design activities are mediated by design artifacts e.g. programming languages, CASE-tools, specification standards, system development methods, prototypes

Based on Bertelsen 2000

Design artifacts do not prescribe pratice

• In most cases a specific design artifact is intended to be used in a specific way, and just as often the actual way in which the design artifact mediates design is very different form this intention.

•

Based on Bertelsen 2000

Amethodical Systems

Development

Truex, Baskerville and Travis

1999

7 Agile Approaches

There is at least seven agile software developmentEcosystems (schools of thought):

1. Scrum2. DSDM3. Crystal Methods4. FDD5. Lean Development6. XP (eXtreme Programming)7. Adaptive Software Development

Agile MethodsSpecific vs. General

• The amount of specific versus general guidance is key in categorizing light and agile methodologies:

• Scrum, DSDM, FDD, and XP give specific guidance in the areas they cover.

• Lean Development, Adaptive Software Development, and Crystal Methods present a theoretical basis for agile practices.

Theoretical Agile Methods

– Crystal concentrates on communication and varying practices based on project size and risk.

– Agile Software Development focuses on emergence– Lean Development emphasizes the traditional lean

concepts of value and flow. – All three emphasize the primary importance of the

development team. None of these three methods focus on specific practices, so they do not find themselves in conflict with the four agile methods that offer more specific practices, or with each other, for that matter.

Balancing Plan-Driven and Agile Methods

• agile methods and plan-driven (milestone) methods are part of a “how much planning is enough?” spectrum.

• both agile and plan-driven methods have home grounds of project characteristics where they clearly work best.

• hybrid approaches are feasible, and necessary for projects having a mix of agile and plan-driven home ground characteristics.

• how much planning? structure? documentation?

Boehm’s Planning Spectrum

Boehm, Barry. (2002) Get ready for agile methods, with care. IEEE Computer, pp. 64-69

Plans process plans (tasks, milestones, org charts) product plans (architectures, designs)

Agile methods involve planning, but results largely become tacit interpersonal knowledge–

rather than explicit documented knowledge and are valued less than responding to change

It works both ways….Plans can be used to scale up agile methodsAgile methods can be used to streamline plan-driven methods

Agile methods are “fresh air” for many plan-driven people attracting cowboy hackers valuable as pace of change accelerates

Plan-driven methods are valuable, especially with large, critical systems with foreseeable change.

Agile or Plan-Driven? Agile Methods• rely on tacit knowledge

embodied on team• premium developers• dedicated customers w/

knowledge of full span of application

• turbulent environment, constant change

• requirements are emergent• tightly coordinated teamwork

needed to succeed becomes increasingly difficult beyond 15 or 20 (Constantine 2001)

Plan-driven Methods• Invest in process & product plans;

major milestones• compensate for customer

shortfalls via use of architecture review boards and independent expert project reviews

• requirements can be determined in advance, or via prototyping; requirements remain relatively stable

• vital for stable, safety critical embedded software

How different? At the management level, the biggest distinction is the attitude toplans and planning. • traditional methodologies focus on producing detailed plans--often

laid out far into the future--and treat deviations from the plan as errors that need to be corrected.

• agile methodologies also produce plans, but treat them only as approximations for what will actually happen. When there is a deviation from the plan this is treated as feedback, and future plans are adjusted accordingly.

While traditional methodologies resist change, agile methodologiesembrace change and view it as a vital part of a vibrant project.

Quality

Quality: What is that?

• Quality is the totality of characteristics of an entity that bear on the ability to satisfy stated and implied needs (Cited from ISO 8402 Quality vocabulary)

Four Kinds of Quality

$Process

Product

Need

Price

What Quality work in a project constitutes?

What Quality work in a project constitutes?

• Using defined methods and tools (process quality)• Carrying out reviews (process and product quality)• Quality requirements (non-behavioral part of requirements

specification)• Management of changes in (quality) requirements• Metrics and measurements; during (process) and after

(process and product)• Systematic reporting of quality data (based on

measurements)

Walkthroughs

Minimal overhead

Developer training

Quick turnaround

Requirements elicitation

Ambiguity resolution

Training

Method Family Typical Goals Typical Attributes

Little/no preparation

Informal process

No measurement

Technical

Reviews

Formal process

Author presentation

Wide range of discussion

InspectionsDetect and remove all defects efficiently and effectively.

Formal process

Checklists

Measurements

Formal verification

Types of Reviews and Inspections

Process improvement• Process oriented improvement can be made using a

normative process model as for example CMM, BOOTSTRAP or SPICE.

• Product oriented improvement can be made using a normative product model such as ISO 9126.

• But if you don’t believe that there is one good way (Best Practice) to devlop software you can instead gather information in your own organization using GQM

GQM• Find characteristics for Organisation and Project• Define “Goals” using Business Plan, Business Goals

and Strategy• Break down into “Questions” og “Metrics” • Collect the Measurements• Arrange Feedback sessions where Measurement

Data are analysed and interpreted• Presenting and distributing the Measurement Data

Steps

CMM: The most commonly used framework for

Software Process Improvement

Immature software development

• Schedule and budget overruns, low quality and functionality never delivered are said to be signs of an immature discipline

• Best practices reported for a number of years • 15 years ago the Capability Maturity Model

(CMM) was invented

Introduction to CMM framework

• A learning process in connection with Best Software Practice

• Assessment is NOT comparable with an ISO 9000 Certification

• Your maturity picture for your development process• A sound basis for improvement

CMM – Capability Maturity Model

1 Initial

2 Repeatable

3 Defined

4 Managed

5 Optimizing

CMM Maturity levels

Initial

Repeatable

Defined

Ma-naged

OptimizingFeedback, Continuousimprovements

Quantitavely understood,and stabilized

Quality,Process is documentedand standardized

Repeating possible,Success depends on individuals

Ad hoc,Chaotic at times,Fire fighting

-Maintaining and fur- ther developing the high org. standard

-Technology and process change management-Defect prevention

-Process monitoring-Procesa analysis-Quality mgmt.

-Training-Peer reviews-Org. process focus-Standard processes

-Project management-Project planning-Configuration mgmt.-Quality assurance

1

2

3

4

5

Level Characteristics Challenges

Enhancedquality andproductivity

Reduced risk

Requirements management

Requirements management• Requirements management is the process

of understanding and controlling changes to system requirements; keeping track of individual requirements and maintaining links between dependent requirements so that you can asses the impact of requirements changes

• A formal process for making change proposals and linking these to system requirements is necessary

The requirements engineering process

Feasibility study

Requirements elicitation and

analysisRequirements specification

Requiements validation

Feasibility report

System models

User and system

requirementsRequirements

document

Sommerville 2004

The goal is to create and maintain a system requirements document

Different types of traceability

• Requirements E.g. links the dependent requirement with the requirements document

• Dependences E.g. this requirement (1.2.3) regarding the user interface depend on the hardware platform

• Design E.g. this requirement (2.2.2) is fulfilled by design (F.2) – links the requirements to the design module where the requirements are implemented

• Changes E.g. this requirement (7.8.9) was changed 3 SEP as a add-on to the prior requirement (7.8.9) from 4 JAN

• Rational E.g. why did we decide that requirement (4.5.6) should be added.

• Source E.g. Information linking the requirement to a stakeholder

Configuration management

Configuration Management in Practice

The point is to tailor the configuration management activities to support each phase, function, special condition, product, and business.

The need is typically driven by:– External requirements ( from standards, for certification,

from customers)– Own strategy and wish for imporvement (quality

problems, shorter time-to-market through reuse, requirements from maturity models)

Configuration Management includes an element of insurance.

SCM systems may provide services in the following areas:

Managing a repository of components• Different components of the software and their versions

(version management, product modeling and complex object management)

Help engineers in their usual activities• SCM products try to provide engineers the right objects,

in the right location - workspace control (compilation and derived object control)

Process control and support• The formal definition of what is to be performed on what

(a process model) and the mechanisms to help/force reality to conform to this model

Different software development approaches different CM

• Most CM standards assumes a waterfall model is used for system development

• Incremental development requires a different approach supporting frequent builds – agile and rapid development approaches cannot be based around rigid procedures and paperwork

What may be placed under configuration management

• Administrative documents– Letters, contracts, process description, sales material, templates, standards ect.

• Code– Header files, include files, source code, system libraries, object files etc.

• Environments– Compilers, linkers, operating systms, tools, word processors etc.

• Product documentation– User manuals, build scripts, data, events registrations, installation procedures,

plans ect.

• Technical documentation– Requirements (all levels), design (all levels), technical nots

• Test material– Drivers, stubs, test data(base), test reprots, test specifications and test

procedures

Virtual teams – addressing issues related to software development in

distributed and heterogeneous (global) teams

Issues related to global SE(Herbsleb and Moitra 2001)

• Strategic issues - (division of work, job security, loss of control, relocation, extensive travel)

• Cultural issues• Inadequate communication - (limited face-to-face

communication, time zone differences, language, culture)

• Project and process management issues -(coordination/synchronization)

• Technical issues - (data formats, tools, configuration management)

Tactic 1: Reduce intensive collaboration

Tactic 2:Reduce cultural distance (I)

Tactic 3:Reducing temporal distance

Collaboration practiceMulti case study (Passivaara and Lassenius 2003)

Synchronization of main milestones Linked to the software development process used in the collaborating companiesFrequent deliveries

Establishment of peer-to-peer links Effect the organizational structure and the roles in the collaborating companies

Problem-solving practices Support communication and collaboration within and between collaborating companies

(collections of several practices that are closely related and have similar goals)

Informing and monitoring practices

Relationship building practices

Examination project• The students can chose between two forms:

– A theoretical project on a course relevant topic– A case study

• The project should use relevant course literature and

additional research literature selected by the students.– 10 relevant research papers chosen by the project group need

to be referenced– 3 key papers should be included as appendix to the project

report.

• Groups with 2-3 students are expected to produce a project report about 20-25 pages, groups of 4-5 students 25-35 pages.

What does it mean that the course is advanced?

• Basic knowledge about systems development is a prerequisite

• Research based literature• You are expected to develop skills to find and

evaluate research literature • Practice and research should be used to reflect on

each other• Individual (group vise) chose of literature for

examination