The Tools of the Trade

1
The Tools of the Trade

• Chapter 5

2
Software Engineering Tools

• Theoretical tools
• Also known as analytical tools
• Stepwise-refinement
• Cost-benefits analysis
• Software metrics
• Software tools
• CASE tools

3
Stepwise Refinement

• A technique whose basic principle is to postpone
  decisions on details until as late as possible to
  concentrate on important issues.
• Human beings can only concentrate on at most 7
  2 chunks of information at any one time
• Can be applied to most phases of the software
  lifecycle
• Specification Phase
• Refine from context diagram ? top level DFD ?
  detailed DFD ? pseudocode
• Design Phase
• Refinement of the Architectural design

4
Stepwise Refinement (2)

• Different than the divide-and-conquer technique
• Divide-and-conquer breaks up a problem into
  subproblems of equal importance
• Problem with stepwise refinement
• Which issue must be handled in the current
  refinement and which must be postponed until a
  later refinement

5
Cost-Benefit Analysis

• Comparison of estimated future benefit against
  projected future cost
• Tangible
• Measurable in terms of dollars spent
• Easy to quantify
• Intangible
• Measurable in terms of customer or user
  satisfaction
• Difficult to quantify
• Use assumptions

6
Software Metrics (1)

• Serves as early warning system for potential
  problems
• Types of metrics
• Product metric Measures some aspect of the
  product itself
• Size (eg. number of modules, LOC )
• Quality
• Reliability (mean time between failures)

7
Software Metrics (2)

• Types of metrics (cont.)
• Process metric Provides information about the
  software process itself
• Cost
• In hardware and manpower
• Duration
• How long it takes
• Effort
• How much manpower is required

8
Software Metrics (3)

• Size, Cost, Duration, Effort and Quality are
  fundamental metrics that must be measured at
  every phase.
• Management can use the data provided by the
  metrics to identify problems within the software
  organization
• Once a problem has been identified, strategies
  for correcting the problem may be considered

9
CASE

• Computer-assisted software engineering NOT
  computer-automated engineering
• Software development includes a lot of drudge
  work
• Documentation of plans, contracts,
  specifications, designs, source code, and
  management information. These are tasks that a
  typical software professional dislike doing.

10
Taxonomy of CASE

• Forms of CASE
• CASE Tool
• CASE workbench
• CASE environment
• Classification of CASE
• Front-end (upperCASE)
• Used in requirements, specification and design
  phases
• Back-end (lowerCASE)
• Used in implementation, integration and
  maintenance phases

11
Classification of CASE
(a) Tool
(b) Workbench
(c) Environment
12
CASE Tools

• Assist in one aspect of the software production.
  Examples are
• A tool that generates UML use cases assists in
  the requirements phase
• Data dictionary tool
• Stores information about all data items within a
  product
• Consistency checker tool
• Checks that all data item in the specification
  document is reflected in the design document and
  vice versa
• Report generator
• Used to generate code needed to produce a report
• Screen generator
• Used to assist developers in producing code for a
  user input screen.

13
CASE Workbench

• A collection of tools that together support one
  or two activities in software development
• An activity is a related collection of tasks
• Coding activity editing, compiling, linking,
  testing, debugging.
• Examples
• Project management workbench
• Used for every phase of the project to support
  one or more activities for each phase.
• Coding
• Can be used for rapid prototyping as well as
  implementation, integration and maintenance

14
CASE Environment

• Supports the complete software processes or at
  the very least, a large portion of the software
  process.

15
Why CASE is useful (1)

• Provides for accurate and up-to-date
  documentation at all times
• Only one, online current version exists
• Provides for online documentation
• Eliminates the need to search manually through
  users manuals
• Provides for communication among team members
• Email used to keep written record of decisions
  made during project development

16
Why CASE is useful (2)

• Assist programmers by
• Simplifying tasks
• Reducing frustration
• Increase productivity
• Example programming workbench
• Structure editor with interface checking,
  operating system front-end, source-level
  debugging and online documentation

17
Software Version

• Whether a product is being developed or
  maintained, there exist at least two versions of
  the product the old version and the new version
  (revision)
• Variations where different versions of the
  product must coexists, unlike revisions where a
  newer version replaces an older version
• Configuration Control Tool
• Used to manage software versions

18
Configuration Control

• During product maintenance
• Handles the situation when more than one
  programmer will make changes to the same module
• Use baselines, a configuration of all modules in
  a product
• During product development
• Once a module has been developed and tested, it
  is used by other modules in the product. Any
  changes to the module will impact other modules.

19
Build Tools

• A tool that assist in selecting the correct
  version of each object code module to be linked
  to form a specific product
• Example, the UNIX make utility
• Based on date/time stamps of source codes, .obj
  files and .exe files

20
Gains in using CASE Technology (1)

• Increase in productivity
• Faster development
• Fewer faults
• Better usability
• Easier maintenance
• Improved morale

21
Gains in using CASE Technology (2)

• Caveat gains can only be significant if the
  development team has sufficient training in
  application development in general, as well as
  tool-specific training, and the software process.
• Organizations at CMM 1 or 2 do not benefit from
  CASE technology
• a fool with a tool is still a fool