Loading
Programming
Languages
A programming language is a
language used to write a program that
the computer can execute. It is a set of written symbols that instruct the
computer system to perform specified tasks.
Use of these
symbols is governed by a set of rules called syntax.
There are at least several
hundred and possibly several thousand different programming languages. Although
each one of them has its own specifications, certain basic instructions are
performed by all languages.
Some of the
programming languages are well suited to all sorts of computing tasks, and the
current popularity of the C language attests to this; we can write anything
from a device driver to an application program to an operating system using C.
However, there are certain kinds of tasks, particularly those involving
artificial intelligence, process control, or very highly mathematical
applications, that can benefit from a more specific language. Programming
languages are also divided into low-level
language such as assembly language,
and high-level languages such as Pascal, C, and C++.
There is a general requirement for more reliable systems in all
application domains. Customers expect their software to operate without
failures and to be available when it is required. Improved programming
techniques, better programming languages and better quality management have led
to very significant improvements in reliability for most software.
Software
Reliability
Reliability is the most important dynamic characteristic of almost
all software systems. As general expectations of quality in all types of system
have increased, it is no longer acceptable to deliver software which fails on a
regular basis. Unreliable software results in high costs for end-users.
Developers of unreliable systems may acquire a bad reputation for quality and
lose future business opportunities.
Reliability in a software system can be achieved using three
complementary strategies:
(1)
Fault avoidance: This is the most
important strategy which is applicable to all types of system. The design and
implementation process should be organized with the objective of producing
fault-free systems.
(2)
Fault tolerance: This strategy assumes
that residual faults remain in the system. Facilities are provided in the
software to allow operation to continue when these faults cause failures.
(3)
Fault detection: Faults are detected
before the software is put into operation. The software validation process uses
static and dynamic methods to discover any faults which remain in a system
after implementation.
Software Reliability
Metrics: There
are several different reliability metrics. The most appropriate metric for a
specific system depends on the type of system and application domain. Different
metrics may be used for different sub-systems.
Metrics which
are used for software reliability specification are as follows:
(i)
POFOD (Probability of failure on demand): This is a measure of the
likelihood that the system will fail when a service request is made. For
example, a POFOD of 0.001 means that 1 out of 1000 service requests may result
in failure.
(ii)
ROCOF (Rate of failure occurrence): This is a measure of the frequency
of occurrence with which unexpected behaviour is likely to occur. For example,
a ROCOF of 2/100 means that 2 failures are likely two to occur in each 100
operational time units.
(iii) MTTF (Mean time to
failure): This is a measure of the time between observed system failures. For
example, an MTTF of 500 means that 1 failure can be expected every 500 time
units.
(iv)
AVAIL (Availability): This is a measure of
how likely the system is to be available for use. For example, an availability
of 0.998 means that in every 1000 time units, the system is likely to be
available for 998 of these.
Risk
Reduction
Risk: This is a measure of the probability that the system will cause an
accident. The risk is assessed by considering the hazard probability, the
hazard severity and the probability that a hazard will result in an accident.
Risk reduction is the process of
identifying, evaluating, and controlling what might go wrong in a project
before it becomes a threat to the successful completion of the project or
implementation of the information system.
Risk can be reduced by applying design strategies which eliminate
the hazard, which reduce the probability of the hazard occurring or which
prevent the hazard causing an accident.
There are several approaches for risk reduction which may be used:
(1)
Hazard avoidance: The system is designed
in such a way that the hazard cannot arise.
(2)
Hazard probability reduction: The system
is designed in such a way that the probability of a hazard arising is reduced.
This is usually achieved by ensuring that hazards cannot arise as a result of
any single failure or operating error.
(3)
Accident prevention: The system is
designed in such a way that hazards can be detected. Other systems may be
activated to remove the hazard before an accident is caused. If a hazard or the
cause of a hazard is detected, the monitoring system takes action to avoid an
accident.
Safety
Assurance
Safety
assurance is an attribute of computer programs that is defined as “conformance
to explicitly and implicitly specified requirements.”
It focuses on the identification and assessment of potential hazards
that may affect software negatively and cause an entire system to fail. If hazards
can be identified early in the software engineering process, software design
features can be specified that will either eliminate or control potential
hazards.
Safety
assurance encompasses procedures for the effective application of methods and
tools, formal technical reviews, testing strategies and techniques, procedures
for assuring compliance to standards, and measurement and reporting mechanisms.
Once hazards are identified and analyzed, safety-related
requirements can be specified for the software. That is, the specification can
contain a list of undesirable events and the desired system responses to these
events. The role of software in managing undesirable events is then indicated.
Safety assurance should be the responsibility of project safety
engineers who are external to the software development team (who should not be
involved in the system development). They ensure that appropriate safety checks
have been made and documented. They show that an identified hazardous condition
can never occur.
Safety assurance helps to improve the quality of
the product and the software process itself.
Software
Maintenance
The process of changing a
system after it has been delivered and is in use is called software maintenance. The changes may involve simple changes to
correct coding errors, more extensive changes to correct design errors or
significant enhancements to correct specification errors or accommodate new
requirements. It is the process of changing a system to maintain its ability to
survive.
The cost of software maintenance usually exceeds the cost of
software development.
There are three different types of software maintenance:
(1)
Corrective maintenance: is concerned
with fixing reported errors in the software. Coding errors are usually
relatively cheap to correct; design errors are more expensive as they may
involve the rewriting of several program components. Requirements errors are
the most expensive to repair because of the expensive system redesign which may
be necessary.
(2)
Adaptive maintenance: means changing the
software to some new environment such as a different hardware platform or for
use with a different operating system or when they need the product to be
interfaced with new hardware or software.
(3)
Perfective maintenance: involves
implementing new functional or non-functional system requirements. A software
product needs maintenance (to support the new features that users want) it to
support, to change different functionalities of the system according to
customer demands, (or to enhance the performance of the system.)These are
generated by software customers as their organization or business changes.
Hence, the three
types of software maintenance are: perfective
maintenance where new functionality is added to the system; adaptive maintenance where the system is
adapted to new environments and corrective
maintenance which is system repair.
Software
Re-Engineering
A product rebuild with added functionality, better performance and
reliability, and improved maintainability. That’s what we call re-engineering.
Software re-engineering is concerned with taking existing legacy
systems and re-implementing them to make them more maintainable. As part of
this re-engineering process, the system may be re-documented or re-constructed.
It may be translated to a more modern programming language, implemented on a
distributed platform.
The objective of system re-engineering is to improve the system
structure and make it easier to understand. The cost of future system
maintenance should therefore be reduced.
In context of software re-engineering, re-engineering examines
information systems and applications with the intent of restructuring or
reconstructing them so that they exhibit higher quality and better maintainability.
Advantages
of Re-engineering
- Reduced Risk
There is a high risk in new software
development. There may be development problems, staffing problems and
specification problems.
- Reduced Cost
The cost of re-engineering is often
significantly less than the costs of developing new software.
No comments:
Post a Comment