Software Engineering

(THEORY) DIGITAL ASSIGNMENT

SLOT-B2

Name – Rajvansh Singh Chhabra

Registration number – 20BCE2689
Q1) In February 2003 the U.S. Treasury Department mailed 50,000 Social Security checks
without a beneficiary name.

A) Reasons for the mistakes:

 According to the research, the US treasury Department mailed over 50000

Social security checks without a beneficiary name, SOFTWARE ERROR being
the reason.
 Another crucial reason being Lack of monitoring, maintenance, upgrades,
continuous testing and debugging, and too much focus on quickly getting o/p’s
at the cost of maintenance were the main culprits in this regard.
 Rigidity and lack of flexibility of the system causing compatibility issues with
the changing atmosphere and i/p’s on which the operation was being
performed. The software was unable to keep itself up to data with the rapidly
evolving and diverse scenarios.
 Unorganized distribution of functions among the modules, including excess
dependency on each other for the data, system, input, output and services,
without proper coordination and planning.
 Complexity in the implementation of applications. This complexity was due to
a large amount of web servers and services, database storage on the cloud and
overly distributed and segmented datastores, overwhelming size, spatial
complexity and compilation time of the applications, lack of organization in
the multi layered architecture and cumbersome and unnecessary programs.
 There were some errors in the code due to rigid time constraints, unorganized
working protocols, lack of planning, less focus on proper software development
phases, improper debugging and test cases, arbitrary test cases not pertaining
to real scenarios, poor management, design, and faulty libraries, applications,
services, compilers, software development platforms etc.

B) Avoidance of this mistake:

 Proper risk identification, analysis, planning, monitoring and management

plays an important role in the smooth functioning of a country’s treasury
department, especially the US treasury.
 Continuous testing.
 Improvement of the code.
 Adequate upper management.
 Clear policies and proper funding.
 Proper estimation of size of software, rate of defect repair, time required,
database requirements and development time.

PAGE 1
  Proper investment in infrastructure, compilers, assemblers and development
Soft-wares.
 Proper investment of time and resources in identifying the adequate software
models, user and system requirements, functional and non -functional
requirements, change management, system model, architectural design,
implementation and testing, reuse, scalability, adaptability, compatibility and
security for such organizations.
 Dedicated team is required.

The Testing procedures the US Treasury should have

focused on:

 INTEGRATION TESTING - All the modules of a system should be tested as a

whole to ensure the integrity of the system as well as compatibility with client
and server applications on a network etc.
 SRESS TESTING => It is mandatory that the treasury department of a country
be able to handle unforeseen circumstances and influx of data, making testing
with enormous amount of data, abstract data, as well as illogical data crucial.
 MUTATION TESTING => This kind of testing involves deliberately
introducing bugs and contradictory input and programs to test the system
under adverse circumstances.

Q2) In July 2001 a “serious flaw” was found in off-the-shelf software that had long been
used in systems for tracking U.S. nuclear materials. The software had recently been
donated to another country and scientists in that country discovered the problem and told
U.S. officials about it.

A) Umbrella activity off the shelf components used for developing

the product.
Description of the activity:

 The umbrella activity that is used for developing the product is Software
Configuration Management. Since, the used product used has some flaw, it
was given to some other country, to discover the problem and rectify it. A
detailed explanation is given below.

PAGE 2
  Configuration management determines clearly about the items that make up
the software or system. These items include source code, test scripts, third-
party software, hardware, data and both development and test documentation.
 It is also about making sure that these items are managed carefully,
thoroughly and attentively during the entire project and product life cycle.
 Configuration management has a number of important implications for
testing. Like configuration management allows the testers to manage their test
ware and test results using the same configuration management mechanisms.

It also allows us to keep the record of what is being tested to the underlying
files and components that make it up. This is very important. Let us take an
example, when there was report defect about the off the shelf component, we
need to report them against something, something which is version controlled.
If it is not clear what we found the defect in, the programmers will have a very
tough time of finding the defect in order to fix it. For the kind of test reports
discussed earlier to have any meaning, we must be able to trace the test results
back to what exactly we tested.

Q3) In October 1999 the $125 million NASA Mars Climate Orbiter an inter-planetary
weather satellite was lost in space due to a data conversion error.

A) Reasons for the loss:

 A unit error in the software was used to help predict the velocity of the Mars
Climate Orbiter, which in turn is used to predict the trajectory the Mars
Climate Orbiter would take to enter the Martian atmosphere. This was a
simple conversion mistake: the results were in pound force and the program
that predicted velocity assumed Newton’s, a factor of 4.45 difference. The error
in the software resulted in the calculated trajectory being higher than the
actual trajectory.
 The Jet Propulsion Laboratory was not fully involved in the development of the
space craft, hence many issues related to propulsion, altitude, control,
navigation and software systems remained unresolved. Consequently, safety
protocols were not followed nor were the proper phases of testing.
 Lack of coordination between the various departments and teams.
 Conflicting roles of the senior management, hence there were issues related to
accountability and responsibility.

PAGE 3
  Also, the development team could not involve the experts at JPL to suggest
better solutions and designs, hence a crucial resource of extremely valuable
knowledge and experience was completely neglected.

B) Testing to avoid the error:

 Conversion Testing should have helped the scientists to avoid such data
conversion error.
 The main reasons behind the lack of coordination, improper management, and
limited involvement of the experts at JPL were the establishment of an
unrealistic schedule with unrealistic deadlines, budget constraints, and
unavailability of the required resources on time. Hence proper establishment
of a realistic schedule, early estimation of the budget and policy constrains, as
well as identifying the crucial resources (like JPL in this case) as quickly as
possible is very important.
 Conversion testing is to verify that one data format can be converted into
another data format so that the converted data format can be used seamlessly
by the application under test appropriately.
 Database file conversion.
 Programming language conversion.
 Media conversion (audio, video, image, documents).
 It is good practice to identify the software process model, process activities,
requirements (user, system, technical and mission requirements), system
models and architecture, design, development, testing and designing phases,
proper risk and change management strategies.
 The roles and responsibilities of the teams and the departments as well as the
management should be decided in the early stages of development.
 Proper communication, timely sharing of resources, data, plans and
presentation of the technical and management issues is a must.
 The departments should be well aware of the roles and the responsibilities of
the other departments to avoid any miscommunication.

Q4) In June 1996 the first flight of the European Space Agency's Ariane 5 rocket failed
shortly after launching, resulting in an uninsured loss of $500,000,000.

PAGE 4
A) Reasons for the Failure:

 During the launch preparation campaign and the count-down no events

occurred which were related to the failure.
 At 36.7 seconds, approximately 30 seconds after lift-off, the computer within
the back-up inertial reference system, which was working on stand-by for
guidance and attitude control, became inoperative. This was caused by an
internal variable related to the horizontal velocity of the launcher exceeding a
limit which existed in the software of this computer.
 Approx. 0.05 seconds later the active inertial reference system, identical to the
back-up system in hardware and software, failed for the same reason. Since the
back-up inertial system was already inoperative, correct guidance and attitude
information could no longer be obtained and loss of the mission was
inevitable.
 As a result of its failure, the active inertial reference system transmitted
essentially diagnostic information to the launcher's main computer, where it
was interpreted as flight data and used for flight control calculations.
 On the basis of those calculations the main computer commanded the booster
nozzles, and somewhat later the main engine nozzle also, to make a large
correction for an attitude deviation that had not occurred.
 The limitations of the alignment software were not fully analyzed and the
possible implications of allowing it to continue to function during flight were
not realized.
 The specification of the inertial reference system and the tests performed at
equipment level did not specifically include the Ariane 5 trajectory data.
Consequently, the realignment function was not tested under simulated
Ariane 5 flight conditions, and the design error was not discovered.

B) Guidelines when developing Critical system:

It would have been technically feasible to include almost the entire inertial
reference system in the overall system simulations which were performed. For
a number of reasons, it was decided to use the simulated output of the inertial
reference system, not the system itself or its detailed simulation. Had the
system been included, the failure could have been detected.

Overall, this loss of information was due to specification and design errors in
the software of the inertial reference system. The extensive reviews and tests
carried out during the Ariane 5 Development Program did not include
adequate analysis and testing of the inertial reference system or of the

PAGE 5
 complete flight control system, which could have detected the potential
failure.

There are three types of critical system:

 Safety-critical systems: A system whose failure may result in injury, loss of life
or serious environmental damage. An example of a safety-critical system is a
control system for a chemical manufacturing plant.
 Mission-critical systems: A system whose failure may result in the failure of
some goal- directed activity. An example of a mission-critical system is a
navigational system for a spacecraft.
 Business-critical systems: A system whose failure may result in very high costs
for the business using that system. An example of a business-critical system is
the customer accounting system in a bank. Business-critical systems may be
affected by security-related failures.

Thanking You,
With
Regards,
Rajvansh.

PAGE 6