AB HELSINKI UNIVERSITY OF TECHNOLOGY
T–76.3601 — Introduction to Software Engineering
http://www.soberit.hut.fi/T-76.3601/
Casper [email protected]
Software Engineering PracticeSoftware Configuration Management
AB HELSINKI UNIVERSITY OF TECHNOLOGY
Software Engineering Practice
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
What is “Practice”?
• Practice is a broad array of concepts, principles, methods and tools that you must consider as software is planned and developed
• It represents the details—the technical considerations and how to’s—that are below the surface of the software process—the things that you’ll need to actually build high-quality computer software.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
WARNING!
• Most things said during this lecture will sound extremely simple and self-evident
• This is because they basically are
• However, most of the good practices are not practiced in many software development projects!
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The Essence• George Polya, in a book written in 1945(!) describes the
essence of software engineering practice...
• Understand the problem (communication and analysis)
• Plan a solution (modeling and software design)
• Carry out the plan (code generation)
• Examine the result for accuracy (testing and quality assurance)
• At its core, good practice is common-sense problem solving
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Core Software Engineering Principles
• Provide value to the customer and the user
• KIS—keep it simple!
• Maintain the product and project vision
• What you produce, others will consume
• Be open to the future
• Plan ahead for reuse
• Think!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
General Practices for the Basic Software Engineering Activities
• Planning
• Modeling
• Construction
• Deployment
• Communication
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Planning Practices• Principles
• Understand the project scope
• Involve the customer and other stakeholders
• Recognize that planning is iterative
• Estimate based upon what you know
• Consider risk
• Be realistic
• Adjust granularity as you plan
• Define how to achieve quality
• Define how to accomodate changes
• Track your plan
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Planning Practices• Ask Boehm’s questions:
• Why is the system developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they located? (organizationally)
• How will the job be done (technically and managerially)
• How much of each resource is needed?These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Modeling Practices• We create models to gain a better understanding of
the actual entity to be built
• Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain
• Design models represent characteristics of the software that help practitioners construct it effectively: the architecture, the user interface, and component-level detail
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Analysis Modeling Practices
• Principles
• Represent the information domain
• Represent the software functions
• Represent software behavior
• Partition the representations
• Move from essence towards implementation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Design Modeling Practices• Principles
• Design must be traceable to the analysis model
• Always consider architecture
• Focus on the design of data
• Interfaces (user, internal) must be designed
• Components should exhibit functional independence
• Components should be loosely coupled
• Design representations should be easily understood
• The design model should be developed interativelyThese courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Construction Practices• Preparation principles (before you start coding!)
• Understand the problem
• Understand basic design principles and concepts
• Pick a programming language that meets the needs of the software and environment
• Select a programming environment that provides tools that make your work easier
• Create a set of unit tests that will be applied once the component you code is completed (if you use the test-first approach)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Construction Practices• Coding principles
• Select data structures that meet the needs of your design
• Understand the architecture and create compliant interfaces
• Keep conditional logic as simple as possible
• Create nested loops in a way that makes them easily testable
• Select meaningful variable names and follow local coding conventions
• Write self-documenting code
• Create a visual layout (indentation, blank lines etc.) that aids understanding
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Construction Practices• Validation principles
• Use code walkthroughs
• Perform unit tests and correct errors
• Refactor the code
• Testing principles
• All test should be traceable to requirements
• Tests should be planned (!?)
• The pareto principle applies to testing
• Testing begins “in the small” and moves toward “in the large”
• Exhaustive testing is not possible
• Testing can only show the presence of bugs—not their absence!These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Deployment Practices
• Principles
• Manage customer expectations for each increment
• A complete delivery package should be assembled and tested
• A support regime should be established
• Instructional materials must be provided to end-users
• Buggy software should be fixed first, delivered later
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Communication Practices• Principles
• Listen
• Prepare
• Facilitate
• Face-to-face is best
• Take notes and document decisions
• Collaborate with the customer
• Stay focused
• Draw pictures when things are unclear
• Move on...
• Negotiation works best when both parties win!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY
Software Configuration Management
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The “First Law”
• No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.
Bersoff, et el. 1980
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
What are these Changes?
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
data
otherdocuments
codeTest
Project
Plan
changes in
technical requirements
changes in business requirements
changes in
user requirements
software models
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Three Basic Problems• Double maintenance problem
• Multiple copies of a file on different computers. All must be updated.
• Shared data problem
• Single copy of file on server. Only one person can work on it at a time.
• Simultaneous update problem
• Master copy of file on server, developers have work copies. Changes might get overwritten.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Software Configuration Management• Version management
• files and documentsn (not only source files!)
• Build management
• building the executable from the right sources
• “manufacturing process”
• Change management
• what changes are implemented, and how
• Status accounting
• recording and reporting
• visibility
• Release management
• what is delivered to the customer
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Why Version Management?
• During the lifetime of a system, files change
• Old versions of files can be needed
• troubleshooting
• reverting to a tested and working version
• Different versions might be incompatible
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Configuration Item
• Something that is versioned
• An atomic unit from the SCM point of view
• Examples
• files
• documents
• components
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Version
• An instance of a configuration item that differs from other instances of the same configuration item
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Versions: Revisions and Variants
• Variant
• an alternative to another version of the same CI
• typically used, e.g. for customization
• Revision
• replaces another (previous) version of the same CI
1
2
M1
M2 D2
D1
D3M3
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Merging Variants
• Textual
• Syntactic
• Semantic
• Version management systems or IDEs typically contain tools helping with merging (e.g. diff)
1
2
M1
M2 D2
D1
D3M3
D4
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Configurations• Configuration
• a set of logically connected configuration items
• a collection of CI versions (max 1 version/CI)
• Work set
• current configuration
• Baseline
• a permanent configuration created for a purpose (testing, release)
• possible to return to later
• implemented, e.g. by tagging CIs
• Release
• permanent configuration that is delivered to the customer
• subset of deliverable structure baseline
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Baseline• The IEEE Std 610.12–1990 defines a baseline as:
• A specification or product that has been forma&y reviewed and agreed upon, that therea'er serves as the basis for further development, and that can be changed only through formal change control procedures.
• a baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration items and the approval of these SCIs that is obtained through a formal technical review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The SCM Process
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
13
identification
change control
version control
configuration auditing
reporting
SCIs
Software
Vm.n
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Change Management• Changes to approved items must be controlled
• Change management is a procedure by which a change to an item is requested, evaluated, approved or rejected, scheduled and tracked
• The purpose is to avoid uncontrolled changes to software in order to
• minimize quality problems
• control schedule and effort
• avoid gold plating and feature creep
• Uses a well-defined configuration as a starting point
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
CM Process I/III
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
change request from user
developer evaluates
change report is generated
change control authority decides
need for change is recognized
change request is denied
user is informed
request is queued for action
change control process—II
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
CM Process II/III
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
16
assign people to SCIs
check-out SCIs
make the change
review/audit the change
change control process—III
establish a “baseline” for testing
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
CM Process III/III
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release
check-in the changed SCIs
perform SQA and testing activities
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Change Request (CR) Content• Submitter (customer, tester)
• description of problem
• who found
• version
• error messages/symptoms
• Analyst
• cause
• affected components/subsystems
• effort estimation
• Manager
• decision fix/postpone/drop
• target release
• responsible developer
• Developer
• actions taken
• affected files
• release notes
• actual effort
• Tester
• retesting
• regression testing
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Correct Level of CM• Depends on many factors, e.g.
• size of team
• criticality of software
• risk
• scope of change
• criticality of change
• release process
• ...
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Build Management
• The manufacturing process for software
• Selecting the right sources for a build
• Performing the right steps
• Compiling only the necessary parts of the system depending on what has been changed
• Typically automated
• make, ant, ...
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Build Cycle• Heartbeat of a project
• build and smoke-test e.g. daily
• show concrete progress
• Frequent builds and automated tests
• minimize integration risk
• reduce quality risk
• easier debugging
• improve morale
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Status Accounting
• Making status of the development visible
• Is the developer finished with a file?
• Is a file reviewed?
• Is a CR rejected?
• Status reflects the lifecycle of a CR or bug report
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Release Management
• About managing what gets released, under what conditions, and to whom
• In product environments, release cycles are common
• E.g. major release every 1-3 years, yearly minor updates, unscheduled (on a need basis) patch releases (service packs)
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Release Classifications
• Alpha release
• Beta release
• Final release
• Update and upgrade release
• Patches and emergency fixes
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Distribution of Releases• Physical media
• CD ROM, DVD, tapes, chips
• Networked media
• Internet
• NFS
• Software as a service
• Not installed on client computers, but site upgraded
AB HELSINKI UNIVERSITY OF TECHNOLOGY
Questions?