A Classification of CASE Technology

1
A Classification of CASE Technology

• Alfonso Fuggetta, Politencnico di Milano and
  CEFRIL
• Sanaa kamari

2
Why CASE?

• The design, implementation, delivery, and
  maintenance of software are complex and expensive
  that need improvement and better control.
• Need technology to achieve this goal.
• CASE( computer-aided software engineering)
  computerized applications supporting and
  partially automating software- production
  activities.

3
CASE research areas

• How can they develop more integrated and easier
  to use CASE tools?
• To develop technologies to support formal
  definitions and automation of the software
  product.
• To overcome the misleading terminologies used.
• Such as tool, workbench, toolset, and environment
  are given different meaning and interpretations.

4
Critical issues in classification schemes

• The acronym CASE is associated with many
  definitions
• The functionalities of CASE products are not
  standardized.
• The goal of this type of classification is
  shallow.
• it is not easy to agree on the levels of
  abstraction of the reference framework used to
  classify CASE products.
• Confusion can be created by placing a specific
  tool within one category when others might
  believe it belongs to another category.

5
Author classification
Software process

• Based on a general framework derived from the
  work of Conradi and al.

Is supported by
Software-process support
Is implemented by
CASE technology
6
Refining the reference framework

• CASE products are further classified according to
  the breath support they offer.
• Three categories of CASE products
• Tools support only specific tasks in the software
  process.
• Workbenches support only one or few activities.
• Environments support (a large part of) the
  software process.

7
Tools

• A CASE tool is a software component supporting a
  specific task in the software-production process.
• Editing tools editors.
• Textual editors and graphical editors.
• Programming tools used to support coding.
• assemblers, compilers, debuggers, code
  generatorsetc
• Verification and validation tools tools that
  support program validation and verification.
• Test-case generator, emulator/simulator, static
  and dynamic analyzersetc.

8
Tools

• Configuration management tools coordinate and
  control the construction of a system composed of
  many parts
• Version management, item identification, library
  managementetc.
• Metrics and measurement tools
• Tools to analyze the source-code metrics.
• Tools to monitor the execution of programs and
  collect run time statistics.

9
Tools

• Project management tools
• Cost-estimation tools, project planning tools,
  bulletin boards.
• Miscellaneous tools products difficult to
  classify.
• spreadsheets and hypertext systems.

10
workbenches

• Integrate in a single application many tools
  supporting specific sw process activities to
  achieve
• A homogeneous and consistent interface
• Easy invocation of tools and tool chains
• Access to a common data set, managed in a
  centralized way.

11
Classes of CASE workbenches

• Business planning and modeling products to
  support the identification and description of a
  complex business.
• Ex PC Prism
• Analysis and design three categories
• For data-intensive applications Excelerator
• For control-intensive app Statemaate
• General purpose for both type app Teamwork
• User interface development helps with user
  interface design
• Ex HP interface.

12
Classes of CASE workbenches

• Programming wb
• Text editor, compiler, linker and debugger.
• VV wb products that help with module and system
  testing.
• Test-case generator.

13
Classes of CASE workbenches

• Maintenance and reverse engineering wb
• Exrecoder.
• Configuration management wb support version
  control, configuration building, and change
  control
• ExPCMS.
• Project management wb
• Ex coordinator

14
Environments

• A collection of tools and workbenches that
  support the software process.
• Toolkits limited to programming, configuration,
  and project management, Unix programmer's wb
• Language centered env centered around a specific
  language, Smalltalk

15
Environments

• Integrated env with some limitations they
  operate using standards mechanisms so users can
  integrate tools and wb, ex DEC Cohesion
• 4th generation env set of tools and wb
  supporting the development of a specific class
  of program.
• Process centered env operates by interpreting a
  process model created by specialized tools.

16
IEEE Standard for Developing Software Life Cycle
Processes

• Sanaa kamari

17
Scope and purpose

• Scope the standard provides a process for
  creating a software life cycle process (SLCP).
• It is the function of the process architect to
  create the SLCP.
• Purpose defines the process by which an SLCP is
  created.

18
Product of standard

• SLCP is the product of this standard, it is based
  on
• A Software Life Cycle Model (SLCM) that is
  selected for the project.
• The activities a defined body of work to be
  performed including its required I/O information.
• The Organizational Process Assets (OPAs) that
  are selected for the project.

19
Intended audiences

• Provides guidance to those responsible for
  determining the implementation of this standards
  activities.
• Process architect, is expected to have
• The authority to develop SLCP.
• A knowledge of the OAPs
• A knowledge of the SLCMs
• An understanding of the activities that are
  presented in this standard.
• Also of use to the performers of the activities.

20
Relationship to other key standards

• The standard is associated with the following
  standards
• ISO 90019004 and ISO 9000-31994
• Recommends organizing a software development
  project in accordance with a selected life cycle
  model.

21
Relationship to other key standards

• IEEE/EIA 12207.0-1996
• Require an acquirer to
• Determine which processes, activities and tasks
  of IEEE/EIA are appropriate for the project and
  tailor them accordingly.
• Require a supplier to
• Define or select a life cycle model and map the
  processes, activities and tasks to IEEE/EIA
  12207.0-1996.

22
Relationship to process improvement

• This standard can be integrated into an
  Organizations Process Improvement program to
• Minimize the effort needed to create an SLCP.
• Facilitate the reuse of existing OPAs.
• Lead to the improvement of the OPAs by
  incorporating lessons that were learned from the
  use of the OPAs in projects.

23
Organization of the standard
24
Overview, references, definitions

• Contains required, introductory information
• Supporting references and citations to the
  standard.
• Contextual definitions and acronyms.

25
Key concepts

• Activities a description of the required
  transformation input information into Output
  information.
• Elements of the SLCP
• SLCM is the framework on which the activities of
  this standard will be mapped.
• SLC is the executable sequence of activities that
  are to be performed during a project.
• OPAs are the artifacts that define the
  environment of an organization for software
  projects.

26
Key concepts

• Mapping establishes the sequence of activities
  in this standard onto a selected SLCM.
• Input information and output information where
  information flows among activities, it can be
  traced from its original activity to the
  receiving activity.

27
Implementation of the standard

• Select an SLCM To which the activities will be
  mapped
• Create an SLC the activities are mapped onto the
  SLCM, the components of the mapping are
• Place the activities in executable sequence.
• Develop and justify a list of activities not
  used.
• Verify the map
• Establish an SLCP.