View
215
Download
0
Tags:
Embed Size (px)
Citation preview
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
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
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: 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)
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
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 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 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 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)
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