Course summary

1
Course summary
2
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
3
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

4
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.

5
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)

6

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

Guide to the Software Engineering Body of
Knowledge 2004 Version SWEBOK Executive
Editors Alain Abran, École de technologie
supérieure James W. Moore, The MITRE
Corp. Editors Pierre Bourque, École de
technologie supérieure Robert Dupuis, Université
du Québec à Montréal Project Champion Leonard L.
Tripp, Chair, Professional Practices
Committee, IEEE Computer Society
(2001-2003) http//computer.org Los Alamitos,
California Washington Brussels Tokyo
7
(No Transcript)
8
(No Transcript)
9
Software development processes
10
Different software process stereotypes

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

11
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
12
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
13

• Amethodical Systems Development
• Truex,
• Baskerville
• and Travis
• 1999

14
7 Agile Approaches

• There is at least seven agile software
  development
• Ecosystems (schools of thought)
• 1. Scrum
• 2. DSDM
• 3. Crystal Methods
• 4. FDD
• 5. Lean Development
• 6. XP (eXtreme Programming)
• 7. Adaptive Software Development

15
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.

16
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.

17
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?

18
Boehms Planning Spectrum
Boehm, Barry. (2002) Get ready for agile methods,
with care. IEEE Computer, pp. 64-69
19
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

20
It works both ways.

• Plans can be used to scale up agile methods
• Agile 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.

21
Agile or Plan-Driven?

• 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

• 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)

22
How different?

• At the management level, the biggest distinction
  is the attitude to
• plans 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 methodologies
• embrace change and view it as a vital part of a
  vibrant project.

23
Quality
24
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)

25
Four Kinds of Quality
Product
Price

Process
Need
26
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)

27
Types of Reviews and Inspections
Method Family
Typical Goals
Typical Attributes
Minimal overhead Developer training Quick
turnaround
Little/no preparation Informal process No
measurement

• Walkthroughs

Formal process Author presentation Wide range of
discussion
Requirements elicitation Ambiguity
resolution Training
Technical Reviews
Formal process Checklists Measurements Formal
verification
Detect and remove all defects efficiently and
effectively.
Inspections
28
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 dont believe that there is one good
  way (Best Practice) to devlop software you can
  instead gather information in your own
  organization using GQM

29
GQM
Steps

• 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

30
CMM The most commonly used framework
forSoftware Process Improvement

31
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

32
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

33
CMM Capability Maturity Model
5 Optimizing
4 Managed
3 Defined
2 Repeatable
1 Initial
34
CMM Maturity levels
35
Requirements management
36
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

37
The requirements engineering process
The goal is to create and maintain a system
requirements document
Feasibility study
Requirements elicitation and analysis
Requirements specification
Feasibility report
Requiements validation
System models
User and system requirements
Requirements document
Sommerville 2004
38
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

39
Configuration management
40
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.

41
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

42
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

43
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

44
Virtual teams addressing issues related to
software development in distributed and
heterogeneous (global) teams
45
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)

46
Tactic 1 Reduce intensive collaboration
47
Tactic 2Reduce cultural distance (I)
48
Tactic 3Reducing temporal distance
49
Collaboration practiceMulti case study
(Passivaara and Lassenius 2003)
50
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.

51
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