McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 1
Configurat...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 2
About this...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 3
What is co...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 4
Developmen...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 5
Challenges...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 6
Configurat...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 7
Configurat...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 8
Typical CM...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 9
Typical CM...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 10
Retrievin...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 11
How confi...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 12
Labeling ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 13
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 14
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 15
Storage o...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 16
Storage o...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 17
Item life...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 18
Item life...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 19
Life cycl...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 20
Directori...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 21
Item data...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 22
Document ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 23
Dynamic r...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 24
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 25
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 26
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 27
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 28
Automatic...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 29
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 30
Makefile ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 31
Makefile ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 32
Makefile ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 33
Concurren...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 34
Concurren...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 35
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 36
Change pr...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 37
Change pr...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 38
The CM pl...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 39
CM item s...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 40
Example: ...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 41
Responsib...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 42
Configura...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 43
Change co...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 44
CASE exam...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 45
Developme...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 46
CASE exam...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 47
CASE exam...
McGill University ECSE 428 © 2003 Radu Negulescu
Software Engineering Practice Configuration management—Slide 48
Discussio...
Upcoming SlideShare
Loading in …5
×

Software Engineering Practice - Configuration management

483
-1

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
483
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Engineering Practice - Configuration management

  1. 1. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 1 Configuration management McGill ECSE 428 Software Engineering Practice Radu Negulescu Winter 2003
  2. 2. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 2 About this course module A typical software project may generate thousands of source files and pieces of documentation, and there are many opportunities for introducing inconsistencies between these artifacts: • Teamwork, parallel development and QA • Change requests • Bug fixes • Schedule pressures Here we discuss how to effectively organize the artifacts of a software project. Recommended reading: • Jalote ch. 10 • Bruegge & Dutoit 10.2,10.3,10.4.1,10.4.3,10.4.4 • McConnell Rapid Dev. pp. 338-341, 403-414
  3. 3. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 3 What is configuration management B&D: The disciplines and techniques of initiating, evaluating and controlling change to software products during and after development. • In other words, staying on top of change Known by many names: • CM • SCM - sometimes pronounced “scum” • Version control • Source control (especially in relation to code) • Document control
  4. 4. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 4 Development problems addressed Typical problems of software projects due to lack of tracking: • Communication blocks • Inconsistencies Accidental deletes Wrong releases Overlapping updates • Lost issues (and rework) Lost bug reports Lost reasons for change • Poor predictability Absence of baseline data • Awkward integration • High cost of human error Difficult “undo”
  5. 5. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 5 Challenges of configuration management Challenges: • Number of change requests (100s, 1000s, ...) • Rapid growth of configurations: builds components variants • Superlinear growth of team coordination overhead Number of communication paths required • Dangers of bureaucracy • ...
  6. 6. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 6 Configurations Item: artifact under configuration management • Possibly nested aggregate • Possibly overlapping with other aggregates Configuration: state of an item Variants: configurations of the same item that are intended to coexist Beware: • Terminology varies, although needs and solutions are similar • Focus on the concepts
  7. 7. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 7 Configurations Version: augmented specification • Additional features • Major or minor, depending on the amount of features Release: same spec, enhanced implementation • Bug fixes • Refactored architecture Build: instance of a system, integrated • For testing • Release candidates Shown to customer for evaluation Become a release once accepted
  8. 8. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 8 Typical CM functions Retrieve a configuration / undo a change • E.g. what was our best build? • … before we messed up the event model? Life cycle control • Static access restrictions E.g. a code module can only be signed out by the “owner” (Dev.) E.g. a bug report can only be put in “closed” state by QA E.g. each new feature must be impact analyzed before it is scheduled for development E.g. only PL and CC create releases • Dynamic access restrictions E.g. no simultaneous updates
  9. 9. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 9 Typical CM functions Automatic builds • Invoke the compiler tools on the updated files only Concurrent updates • Branching then merging • Reconciliation of changes Tracing rationale • E.g. why did we need a new event model anyway? • Who issued a request for change? Propagating change • E.g. bug fix for deployed version then new version • E.g. multiple platforms, languages, user privileges Statistics • E.g. determine percentage of testing vs. development delays
  10. 10. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 10 Retrieving a configuration What we want from a mechanism for retrieving configurations: • Label configurations in a way that orients the users • Store configurations efficiently There can be many of them... • Be tailored to the actual flow of configurations
  11. 11. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 11 How configurations are generated Three main sources of change • Shifting requirements Rework previous code • Bug fixes Batches from QA sessions Continuous flow from debugging • Internal issues, such as: New vendor/new technology Performance tuning Refactoring Not synchronized to the main development process • Need for change may occur at any time • Thus, you need some buffering Req flow Issue flow Bug flow Develop. process Customer QA
  12. 12. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 12 Labeling of configurations File names are vital • Orient the developers and customers • Gets interesting when dealing with 100s of files … or even 10s of files Releases • 2.5: version 2, release 5 • 2.3.5: version 2.3, release 5 Builds • RN-2002-03-08-16:01:53 • Internal use only Not in the release file name CC keeps record of release number
  13. 13. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 13 Example: JAR files Distinguish release candidates sent to customer • E.g.: do not send multiple System.jar files to customer Better: FlatCart-Release4.3-… Include the purpose of the file in an envelope name E.g.: FlatCart-Release4.3-ForAcceptanceCandidate2.zip Can use normal release names in the contained files E.g.: FlatCart4.3.jar (JAR file) E.g.: FlatCart4.3.exe (self-extracting archive) In Java 2, JAR files can be annotated with version info • Version (“specification-version” attribute) • Release or build (“package-version” attribute) What if the system includes multiple components with different version & release numbers? • The system can have yet another version scheme
  14. 14. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 14 Example: branch labeling [After Bruegge & Dutoit] revised revised Main revised Branch derived merged released MUE.1.1:Releas MUE.1.2:Releas MUE.1.3:Releas MUE.1.2.1.1:Releas MUE.1.2.1.2:Releas MUE.2.0:Releas
  15. 15. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 15 Storage of configurations Basic operations supported • Get latest configuration: most frequent • Insert a new configuration: frequent • Get previous configurations: on a need-to basis Rollback (undo changes) Locate insertion of a defect
  16. 16. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 16 Storage of configurations Reverse delta • Complete “baseline” version: latest • Deltas See diff tool • Retrieval: compute previous versions from deltas • E.g. VSS Storing branches and variants • A new base can be created for each branch on splitting from trunk Not many branches sharing won’t save much space Storing aggregates • Store cross-references only consistency, space (preferred) • Store copies of all included components ready access
  17. 17. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 17 Item life cycles Enforcing item life cycles • Proper state transitions • E.g. program modules The system is ready for acceptance testing when all modules are OK (Next page) • E.g. triage of new feature requests Impact analysis: which modules will be affected? Prioritization, cost estimation Development, testing Acceptance
  18. 18. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 18 Item life cycles Passed Module 1 Private Ready for unit test Baselined / released Done Failed Passed Module 2 Private Ready for unit test Done Failed ... System/accepta nce testing Passed Failed
  19. 19. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 19 Life cycle control Objectives • Facilitate access by developers • Permit collection of management stats • Allow easy traceability Main mechanisms • Directories • Item database • Document logs
  20. 20. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 20 Directories Storage • One directory for each module state • State transitions: move among directories • May use read/write permissions for directories • Use CM tools for access restrictions in common areas • Example: Infosys’ WAR project Enforcement • Directory read/write privileges
  21. 21. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 21 Item database Storage • State attributes for each item • Some tools restrict which users may set which attributes Enforcement • Attribute settings
  22. 22. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 22 Document logs Storage • Use module headers • Insert date of change, author • Specify distribution list Enforcement • Self-discipline • Configuration audits A reason to maintain redundant info...
  23. 23. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 23 Dynamic rights Mutual exclusion of updates • Check-in/check-out • Except for deliberate branching/merging
  24. 24. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 24 Example: WinCVS www.wincvs.org Work areas • Repository • Working directory Check out • CVS admin → Checkout module • Specify module and working directory Check in • Update the working directory • Commit to the repository Related tools • On-line CVS: www.freepository.org • CVS Workspace 1 Workspace 2 Master directory Software repository Check-in Check-out Baseline
  25. 25. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 25 Example: WinCVS
  26. 26. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 26 Example: document control [After Jalote] States = directories • Under development ← Initial state Author: Done → Under review • Under review Reviewer: Defects found → Under development Reviewer: No defects → Baselined • Baselined CCB: CR authorized → Under development Under dev Under review Baselined [author] [reviewer] [reviewer]
  27. 27. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 27 Example: document control Distribution list Controlled Proprietary Limited Unlimited Uncontrolled To be destroyed
  28. 28. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 28 Automatic builds Builds are frequent • Some processes support daily builds E.g. McConnell ch. 18 Highly effective schedule reduction • Other processes support continuous refactoring XP compensates de-emphasis of global design Compilation can take a lot of time • Idea: recompile only the updates • Careful not to compile the wrong ones Redundancy is hard to maintain • Executables are easily created ⇒ executables are not normally controlled • Hence the term “source control”
  29. 29. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 29 Example: the make utility Make • A tool that controls generation of executables • Handles multiple source files • Recompiles if executable is older than a source • Looks up change dates • Not tied to a particular language • Can even be used to format documents Makefile • Tells make how to recompile • A text file • Two sections: variables and rules • Variables come first, but are optional More info (GNU make) http://www.gnu.org/software/make/make.html http://www.gnu.org/manual/make/html_mono/make.html
  30. 30. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 30 Makefile rules E.g. [from GNU] edith : main.o kbd.o command.o display.o insert.o search.o files.o utils.o cc -o edith main.o kbd.o command.o display.o insert.o search.o files.o utils.o main.o : main.c defs.h cc -c main.c kbd.o : kbd.c defs.h command.h cc -c kbd.c command.o : command.c defs.h command.h cc -c command.c display.o : display.c defs.h buffer.h cc -c display.c insert.o : insert.c defs.h buffer.h cc -c insert.c search.o : search.c defs.h buffer.h cc -c search.c files.o : files.c defs.h buffer.h command.h cc -c files.c utils.o : utils.c defs.h cc -c utils.c clean : rm edith main.o kbd.o command.o display.o insert.o search.o files.o utils.o
  31. 31. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 31 Makefile rules Call make Program make make clean General format target: prerequisite1 prerequisite2 ... <tab> command1 <tab> command2 ... And here's a very useful one: clean: rm *.o core ./tmp/* Deletes all object files in the current directory any core dump all files in ./tmp // Looks up a file named “makefile”
  32. 32. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 32 Makefile variables Example objects = main.o kbd.o command.o display.o insert.o search.o files.o utils.o edith : $(objects) cc -o edith $(objects) main.o : main.c defs.h cc -c main.c kbd.o : kbd.c defs.h command.h cc -c kbd.c command.o : command.c defs.h command.h cc -c command.c display.o : display.c defs.h buffer.h cc -c display.c insert.o : insert.c defs.h buffer.h cc -c insert.c search.o : search.c defs.h buffer.h cc -c search.c files.o : files.c defs.h buffer.h command.h cc -c files.c utils.o : utils.c defs.h cc -c utils.c clean : rm edith $(objects)
  33. 33. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 33 Concurrent updates Branch: concurrent development path requiring independent configuration management. Merge: reconcile different branches. merging point UI branch main trunk comms branch
  34. 34. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 34 Concurrent updates Support for change reconciliation • View changes side-by-side Decide which changes to adopt Might be tedious for divergent versions Supported for text files, not binary (e.g. VSS) • Merge the most recent changes Example: Word for windows “Merge Documents” Tools → Merge Documents → open document Accept or reject changes (Tools→Track changes→ ...)
  35. 35. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 35 Example: feature interaction Functionality partitioning • First release: F1, F2 • Second release: F3, F4 F3 is easy • M4, M5 can be a separate increment • Versioning of M4, M5 independent of M1, M2, M3 F4 needs a separate CM branch • Create branch: copy M2, M4, M5; create M6 Do not check out M2, M4, M5 at this time Other developers keep working on M2, M4, M5 • Implement F4 • Reintegrate branch to main build (trunk) Check out M2, M4, M5 Use delegated permission Merge changes Regression tests of F4 Check in M2, M4, M5 Regression tests of F1, F2, F3 (and F4 to be sure) • If reintegration fails, one version is dumped… M1 M2 M3 M4 M5 M6 F1 X X X F2 X X F3 X X F4 X X X X
  36. 36. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 36 Change propagation & traceability Forward change requests to all related modules Retrieve reason for each modification • So the modification can be undone! Traceability databases • Propagate changes along dependency relations E.g. among variants E.g. from SRS to DD to code to TP • Dependency matrix • Dependency tree
  37. 37. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 37 Change propagation & traceability Example: derived modules • After the current version is deployed The current version is in a maintenance phase. Work may begin on a new version. • If multiple versions are supported Bug fixes may occur for any supported version Bug reports, changes, etc. must propagate to the other versions Keep module derivation relationships across multiple supported system versions.
  38. 38. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 38 The CM plan CM item structure • Naming scheme • Versioning scheme Release Baseline Physical setting Configuration control process • Staff responsibilities Configuration audits
  39. 39. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 39 CM item structure Can be more or less elaborate • Depends on size of project, usage of artifacts, and change flow Same idea as in modular design • Things that are likely to change together should be kept together • Things that are unlikely to change together should be separate • The hierarchy of storage should reflect the likelihood of change Modularity • Subsystems Nesting • E.g. per increment Overlapping • E.g. per increment & per artifact type
  40. 40. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 40 Example: client-server system [From B&D]
  41. 41. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 41 Responsibilities Example: • Configuration controller Create executables Baseline code and docs ... • Developers Check out, check in at specific times
  42. 42. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 42 Configuration auditing Danger: state related mistakes • E.g. move a non-tested module into the release directory Use several mechanism for life-cycle support • E.g.: directory structure + “master table” • E.g.: directory structure + revision lists in module headers Status monitoring • Consistency of the redundant state mechanisms E.g. directory placement same as master table entry • Consistency of the revision list with the artifact life cycle Audits • Check whether proper process is being followed • Check the baseline and release states
  43. 43. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 43 Change control board The change control board (CCB) • Analyze changes • “Triage” changes • Bundle changes Representatives from each party • Development, QA, user documentation Artifacts owners • Customer support, marketing, mgmt Danger: go overboard...
  44. 44. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 44 CASE example: the Rational Suite The full Rational Enterprise Suite is installed in our lab. Team integration tools • RequisitePro: organize, prioritize, track, control requirements • ClearQuest: manage every type of change Implements artifact lifecycle Talks to a database • SoDA: automated documentation Extracts info and puts it in a Word template
  45. 45. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 45 Development • Rose: draw UML diagrams Checks consistency Implements code frameworks from the diagram: it writes class and method declarations and some docs, and you fill in the body of the methods • Purify: run-time errors and memory leaks Needed big time in C/C++ Theoretically, not needed in Java (JVM-managed garbage collection) Practically, Java programs can exhibit object pool overflows, JVM malfunctions, heap reallocations, etc. -> need memory leak tools • Visual PureCoverage: expose testing gaps It instruments the code to register execution • Visual Quantify: Profiles the application to check performance bottlenecks
  46. 46. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 46 CASE example: the Rational Suite Quality assurance • Robot: record and playback test scripts Point-and-click operations are saved into a script Graphical object capture Verification points: test only certain properties of certain objects. This allows changes in the UI design without changing all the test cases The scripting language is called SQA-Basic, and it is very similar to VB except for a couple of statements. See if you can run SQA-Basic scripts in VB • TestFactory Automatic test generation: “Best test”: a random run through the code that works out as much of it as possible Source code coverage analysis: what code was exercised by the test cases
  47. 47. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 47 CASE example: the Rational Suite Integration among these tools • Rational Administrator Integration with other tools • MS Project: activities can be linked to requirements in the RequisitePro database • MS Office: many of the Rational tools use Access for a RDBMS, and Word for their documentation interface • MS VisualStudio: VB, VC++, ... • Java
  48. 48. McGill University ECSE 428 © 2003 Radu Negulescu Software Engineering Practice Configuration management—Slide 48 Discussion Thank you! Any questions?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×