Characteristics of Computer Aided Software Engineering Tools
Characteristics of Computer Aided Software Engineering Tools
Characteristics of Computer Aided Software Engineering Tools
(CASE) Tools:
Computer Aided Software Engineering (CASE) tool refer to
automated tools that are used for software development activities. CASE
helps in development, verification, maintenance and generation of
processes and artifacts.
2) Flexibility :
A CASE tool must provide flexibility and options to the user for editors
and other tools.
3) Strong Integration :
CASE tools must be integrated with all stages of software development.
This means that if a change is made in a model, it must reflect in the code
documentation and all related design. Hence, this offers an organised
environment for software generation.
6) Online Help :
CASE tools offer online tutorials.
2) Tools Layer :
Along with the CASE tools a set of services to manage the tools are also
included The behavior of the tools within the environment is controlled by
the Tools Management Services (TMS). TMS carries out multitask
communication and synchronization in case multitasking is performed by
executing multiple tools at a time. This is done by gathering metrics on the
usage of the tools, coordinating the information flow between the
repository and management system to the tools. The auditing and security
functions are also completed by it.
When some defect has been identified in the software and the code is
debugged to fix it.
Firstly, whenever we make some changes to the source code for any
reasons like adding new functionality, optimization, etc. then our program
when executed fails in the previously designed test suite for obvious
reasons. After the failure, the source code is debugged in order to identify
the bugs in the program. After identification of the bugs in the source code,
appropriate modifications are made. Then appropriate test cases are
selected from the already existing test suite which covers all the modified
and affected parts of the source code. We can add new test cases if
required. In the end regression testing is performed using the selected test
cases.
Risk Management
A software project can be concerned with a large variety of risks. In order to be adept
to systematically identify the significant risks which might affect a software project, it
is essential to classify risks into different classes. The project manager can then check
which risks from each class are relevant to the project.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
3. Business risks: This type of risks contain risks of building an excellent product that
no one need, losing budgetary or personnel commitments, etc.
Software Metrics
A software metric is a measure of software characteristics which are measurable or
countable.
Software metrics are valuable for many reasons, including measuring software performance,
planning work items, measuring productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software
metrics are similar to the four functions of management: Planning, Organization, Control, or
Improvement.
External metrics: External metrics are the metrics used for measuring properties that
are viewed to be of greater importance to the user, e.g., portability, reliability,
functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and
resource metrics. For example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to
check the project's progress. Data from the past projects are used to collect various
metrics, like time and cost; these estimates are used as a base of new software. Note
that as the project proceeds, the project manager will check its progress from time-
to-time and will compare the effort, cost, and time with the original effort, cost and
time. Also understand that these metrics are used to decrease the development
costs, time efforts and risks. The project quality can also be improved. As quality
improves, the number of errors and time, as well as cost required, is also reduced.
In making inference about the effort to be put in the design and development of the
software systems.
In providing feedback to software managers about the progress and quality during
various phases of the software development life cycle.
The definition and derivation of Software metrics are usually based on assuming
which are not standardized and may depend upon tools available and working
environment.
Modularization
Advantage of modularization:
Smaller components are easier to maintain
Program can be divided based on functional aspects
Desired level of abstraction can be brought in the program
Components with high cohesion can be re-used again
Concurrent execution can be made possible
Desired from security aspect
Cohesion
Cohesion is a measure of the degree to which the elements of the module are functionally
related. It is the degree to which all elements directed towards performing a single task are
contained in the component. Basically, cohesion is the internal glue that keeps the module
together. A good software design will have high cohesion.
The degree in which elements of a module are functionally related to each other.
Cohesion is a glue that holds a module together.
In the module High cohesion is desired.
Higher cohesion => lower Coupling
There are seven types of cohesion
1. Functional cohesion
If two operations present within a module perform the same functionality task or
they are part of the same purpose.
2.Sequential cohesion
An element outputs some data that becomes the input for other element, i.e.,
data flow between the parts.
3.Communicational cohesion
Two elements operate on the same input data or contribute towards the same
output data.
Each element effect each other.
4.Procedural cohesion
When elements of module are grouped together, which are executed
sequentially in order to perform a task,
5.Temporal Cohesion
The elements are related by their timing involved.
6.Logical cohesion
The elements are logically related and not functionally. Ex- A component reads
inputs from tape, disk, and network.
7.Co-incidental cohesion
The elements are not related(unrelated). The elements have no conceptual
relationship other than location in source code.
Coupling
Coupling is the measure of the degree of interdependence between the modules. A good
software will have low coupling.
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
1. Interviews:
Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:
It is a group technique
It is intended to generate lots of new ideas hence providing a platform to
share views
A highly trained facilitator is required to handle group bias and group
conflicts.
Every idea is documented so that everyone can see it.
Finally, a document is prepared which consists of the list of requirements
and their priority if possible.
ADVANTAGES OR DISADVANTAGES: