Friday, March 23, 2012

What are the three controls may be put in place to enhance system security?

What are the three controls may be put in place to enhance system security?
Ans: The controls that you might put in place to enhance system security are:
1. Vulnerability avoidance: Controls that are intended to ensure that attacks are unsuccessful. The strategy here is to design the system so that security problems are avoided. For example, sensitive military systems are not connected to public networks so that external access is impossible. You should also think of encryption as a control based on avoidance. Any unauthorized access to encrypted data means that it cannot be read by the attacker. In practice, it is very expensive and time consuming to crack strong encryption.
2. Attack detection and neutralization: Controls that are intended to detect and repel attacks. These controls involve including functionality in a system that monitors its operation and checks for unusual patterns of activity. If these are detected, then action may be taken, such as shutting down parts of the system, restricting access to certain users, etc.
3. Exposure limitation and recovery: Controls that support recovery from problems. These can range from automated backup strategies and information ‘mirroring’ to insurance policies that cover the costs associated with a successful attack on the system.

What are the three principal threats to the security of a system?

What are the three principal threats to the security of a system?
Ans: In any networked system, there are three main types of security threats:
1. Threats to the confidentiality of the system and its data: These can disclose information to people or programs that are not authorized to have access to that information.
2. Threats to the integrity of the system and its data: These threats can damage or corrupt the software or its data.
3. Threats to the availability of the system and its data: These threats can restrict access to the software or its data for authorized users.

What is the distinction between a hazard and an accident?

What is the distinction between a hazard and an accident?
Ans: Accident: An unplanned event or sequence of events which results in human death or injury, damage to property, or to the environment. An overdose of insulin is an example of an accident.
Hazard: A condition with the potential for causing or contributing to an accident. A failure of the sensor that measures blood glucose is an example of a hazard.

What is the most important difference between the two classes of safety critical system?

What is the most important difference between the two classes of safety critical system?
Ans: Safety-critical software falls into two classes:
1. Primary safety-critical software: This is software that is embedded as a controller in a system. Malfunctioning of such software can cause a hardware malfunction, which results in human injury or environmental damage. The insulin pump software, introduced in Chapter 1, is an example of a primary safety-critical system. System failure may lead to user injury.
2. Secondary safety-critical software: This is software that can indirectly result in an injury. An example of such software is a computer-aided engineering design system whose malfunctioning might result in a design fault in the object being designed. This fault may cause injury to people if the designed system malfunctions. Another example of a secondary safety-critical system is the mental health care management system, MHC-PMS. Failure of this system, whereby an unstable patient may not be treated properly, could lead to that patient injuring themselves or others.

Explain the difference between a system fault and a system failure.

Explain the difference between a system fault and a system failure.
Ans: System fault: A characteristic of a software system that can lead to a system error. The fault is the inclusion of the code to add 1 hour to the time of the last transmission, without a check if the time is greater than or equal to 23.00. System faults do not always result in system errors and system errors do not necessarily result in system failures.
System failure: An event that occurs at some point in time when the system does not deliver a service as expected by its users. No weather data is transmitted because the time is invalid. System reliability and availability problems are mostly caused by system failures.

Explain how a relatively unreliable system can provide a high level of availability.

Explain how a relatively unreliable system can provide a high level of availability.
Ans: A telephone exchange switch that routes phone calls is an example of a system where availability is more important than reliability. Users expect a dial tone when they pick up a phone, so the system has high availability requirements. If a system fault occurs while a connection is being set up, this is often quickly recoverable. Exchange switches can usually reset the system and retry the connection attempt. This can be done very quickly and phone users may not even notice that a failure has occurred. Furthermore, even if a call is interrupted, the consequences are usually not serious. Therefore, availability rather than reliability is the key dependability requirement for this type of system.

Briefly define what availability means?

Briefly define what availability means?
Ans: Availability is the probability that a system, at a point in time, will be operational and able to deliver the requested services. A telephone exchange switch that routes phone calls is an example of a system where availability is more important than reliability. Users expect a dial tone when they pick up a phone, so the system has high availability requirements.

List two other system properties that are sometimes considered to be dependability properties.

List two other system properties that are sometimes considered to be dependability properties.
Ans: 1. Maintainability: As systems are used, new requirements emerge and it is important to maintain the usefulness of a system by changing it to accommodate these new requirements. Maintainable software is software that can be adapted economically to cope with new requirements, and where there is a low probability that making changes will introduce new errors into the system.
2. Survivability: A very important attribute for Internet-based systems is survivability. Survivability is the ability of a system to continue to deliver service whilst under attack and, potentially, whilst part of the system is disabled. Work on survivability focuses on identifying key system components and ensuring that they can deliver a minimal service. Three strategies are used to enhance survivability—resistance to attack, attack recognition, and recovery from the damage caused by an attack.

What are the four principal dependability properties?

What are the four principal dependability properties?
Ans: There are four principal dependability properties:
1. Availability: Informally, the availability of a system is the probability that it will be up and running and able to deliver useful services to users at any given time.
2. Reliability: Informally, the reliability of a system is the probability, over a given period of time, that the system will correctly deliver services as expected by the user.
3. Safety: Informally, the safety of a system is a judgment of how likely it is that the system will cause damage to people or its environment.
4. Security: Informally, the security of a system is a judgment

Give three reasons why a system’s dependability is more important than its detailed functionality.

Give three reasons why a system’s dependability is more important than its detailed functionality.
Ans: The dependability of systems is now usually more important than their detailed functionality for the following reasons:
1. System failures affect a large number of people. Many systems include functionality that is rarely used. If this functionality were left out of the system, only a small number of users would be affected. System failures, which affect the availability of a system, potentially affect all users of the system. Failure may mean that normal business is impossible.
2. Users often reject systems that are unreliable, unsafe, or insecure. If users find that a system is unreliable or insecure, they will refuse to use it. Furthermore, they may also refuse to buy or use other products from the same company that produced the unreliable system, because they believe that these products are also likely to be unreliable or insecure.
3. System failure costs may be enormous. For some applications, such as a reactor control system or an aircraft navigation system, the cost of system failure is orders of magnitude greater than the cost of the control system.
4. Undependable systems may cause information loss. Data is very expensive to collect and maintain; it is usually worth much more than the computer system on which it is processed. The cost of recovering lost or corrupt data is usually very high.

What are latent conditions and active failures?

What are latent conditions and active failures?
Ans: Inevitably, all barriers have weaknesses of some kind. Reason calls these ‘latent conditions’ as they usually only contribute to system failure when some other problem occurs. For example, a weakness of a conflict alert system is that it may lead to many false alarms. Latent conditions lead to system failure when the defenses built into the system do not trap an active failure by a system operator. The human error is a trigger for the failure but should not be considered to be the sole cause of the failure. Reason explains this using his well-known ‘Swiss cheese’ model of system failure.
In this model, the defenses built into a system are compared to slices of Swiss cheese. Some types of Swiss cheese, such as Emmental, have holes and so the analogy is that the latent conditions are comparable to the holes in cheese slices. The position of these holes is not static but changes depending on the state of the overall socio-technical system. If each slice represents a barrier, failures can occur when the holes line up at the same time as a human operational error. An active failure of system operation gets through the holes and leads to an overall system failure.

Why are plan-driven (rather than agile) processes used in systems engineering?

Why are plan-driven (rather than agile) processes used in systems engineering?
Ans: Plan-driven processes are used in systems engineering because different parts of the system are being developed at the same time. For systems that include hardware and other equipment, changes during development can be very expensive or, sometimes, practically impossible. It is essential therefore, that the system requirements are fully understood before hardware development or building work begins.
Reworking the system design to solve hardware problems is rarely possible. For this reason, more and more system functionality is being assigned to the system software. This allows some changes to be made during system development, in response to new system requirements that inevitably arise.

What are the main drivers for system procurement decisions?

What are the main drivers for system procurement decisions?
Ans: The drivers for system procurement decisions are:
1. The state of other organizational systems: If the organization has a mixture of systems that cannot easily communicate or that are expensive to maintain, then procuring a replacement system may lead to significant business benefits.
2. The need to comply with external regulations: Increasingly, businesses are regulated
and have to demonstrate compliance with externally defined regulations (e.g., Sarbanes-Oxley accounting regulations in the United States). This may require the replacement of noncompliant systems or the provision of new systems specifically to monitor compliance.
3. External competition: If a business needs to compete more effectively or maintain a competitive position, investment in new systems that improve the efficiency of business processes may be advisable. For military systems, the need to improve capability in the face of new threats is an important reason for procuring new systems.
4. Business reorganization: Businesses and other organizations frequently restructure\ with the intention of improving efficiency and/or customer service. Reorganizations lead to changes in business processes that require new systems support.
5. Available budget: The budget available is an obvious factor in determining the scope of new systems that can be procured.

What are the three principal stages of systems engineering?

What are the three principal stages of systems engineering?
Ans: 1. Procurement or acquisition: During this stage, the purpose of a system is decided; high-level system requirements are established; decisions are made on how functionality will be distributed across hardware, software, and people; and the components that will make up the system are purchased.
2. Development: During this stage, the system is developed. Development processes include all of the activities involved in system development such as requirements definition, system design, hardware and software engineering, system integration, and testing. Operational processes are defined and the training courses for system users are designed.
3. Operation: At this stage, the system is deployed, users are trained, and the system is brought into use. The planned operational processes usually then have to change to reflect the real working environment where the system is used. Over time, the system evolves as new requirements are identified. Eventually, the system declines in value and it is decommissioned and replaced.

What is a wicked problem?

What is a wicked problem?
Ans: Generally, complex socio-technical systems are developed to tackle what are sometimes called ‘wicked problems’. A wicked problem is a problem that is so complex and which involves so many related entities that there is no definitive problem specification. Different stakeholders see the problem in different ways and no one has a full understanding of the problem as a whole. The true nature of the problem may only emerge as a solution is developed. An extreme example of a wicked problem is earthquake planning. No one can accurately predict where the epicenter of an earthquake will be, what time it will occur, or what effect it will have on the local environment. It is impossible to specify in detail how to deal with a major earthquake.

Why are socio-technical systems non-deterministic?

Why are socio-technical systems non-deterministic?
Ans: Socio-technical systems are non-deterministic partly because they include people and partly because changes to the hardware, software, and data in these systems are so frequent. The interactions between these changes are complex and so the behavior of the system is unpredictable. This is not a problem in itself but, from a dependability perspective, it can make it difficult to decide whether or not a system failure has occurred, and to estimate the frequency of system failures. For example, say a system is presented with a set of 20 test inputs. It processes these inputs and the results are recorded. At some later time, the same 20 test inputs are processed and the results compared to the previous stored results. Five of them are different. Does this mean that there have been five failures? Or are the differences simply reasonable variations in the system’s behavior? You can only find this out by looking at the results in more depth and making judgments about the way the system has handled each input.

What are three influences on the reliability of a system?

What are three influences on the reliability of a system?
Ans: In a socio-technical system, you need to consider reliability from three perspectives:
1. Hardware reliability: What is the probability of hardware components failing and how long does it take to repair a failed component?
2. Software reliability: How likely is it that a software component will produce an incorrect output? Software failure is distinct from hardware failure in that software does not wear out. Failures are often transient. The system carries on working after an incorrect result has been produced.
3. Operator reliability: How likely is it that the operator of a system will make an error and provide an incorrect input? How likely is it that the software will fail to detect this error and propagate the mistake?

What are emergent properties?

What are emergent properties?
Ans: The complex relationships between the components in a system mean that a system is more than simply the sum of its parts. It has properties that are properties of the system as a whole and cannot be attributed to any specific part of the system, known as ‘emergent properties’.
There are two types of emergent properties:
1. Functional emergent properties when the purpose of a system only emerges after its components are integrated. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.

2. Non-functional emergent properties, which relate to the behavior of the system in its operational environment. Reliability, performance, safety, and security are examples of emergent properties.

What is the difference between a technical and a socio-technical system?

What is the difference between a technical and a socio-technical system?
Ans: Technical computer-based systems are systems that include hardware and software components but not procedures and processes. Examples of technical systems include televisions, mobile phones, and other equipment with embedded software. Most software for PCs, computer games, etc., also falls into this category. Individuals and organizations use technical systems for a particular purpose but knowledge of this purpose is not part of the system. For example, the word processor I am using is not aware that is it being used to write a book.
Socio-technical systems include one or more technical systems but, crucially, also include people who understand the purpose of the system within the system itself. Socio-technical systems have defined operational processes and people are inherent parts of the system. They are governed by organizational policies and rules and may be affected by external constraints such as national laws and regulatory policies. For example, this book was created through a socio-technical publishing system that includes various processes and technical systems.

What is the difference between the business process layer and the organizational layer in the socio--technical systems stack?

What is the difference between the business process layer and the organizational layer in the socio--technical systems stack?
Ans: At business process layer level, the organizational business processes, which make use of the software system, are defined and enacted. The organizational layer includes higher-level strategic processes as well as business rules, policies, and norms that should be followed when using the system.

Binary Search Integer Array C Code Algorithm (Simplified code to learn)

What are search algorithms?
Given a database, the first thing you would want to do is probably search through its entries to see if a particular entry exists. This is why search algorithms are one of the most basic and widely used algorithms, and one of the first algorithms taught in any class.

Binary Search drastically reduces the worst-case time required to search through a database. However, it can be used only when the database is sorted i.e. when the entries are arranged either in ascending or descending order.

Following binary search algorithm(in C language) takes user inputs to load the specified data structure array in this case and then sorts it using insertion sort approach, you could also use other sorting methods. Then it print the sorted array of integers. It asks for user to input what entry you want to search, it then prints if particular entry if found or not.
Yes, we can add even more functionality to this code, but I made it simple enough so that other people can understand it and go further to add more towards it.
(Please leave your feedback) Code is:

#include<stdio.h>
//this function sorts the array using insertion sort
int sort(int array[],int n)
{
   int i,j,temp;
   for(i=1;i<n;i++)
   {
          temp=array[i];
          j=i-1;
          while(temp<array[j] && j>=0)
          {
                  array[j+1]=array[j];
                  j=j-1;
          }
          array[j+1]=temp;
   }
}

//this function gets data from user to load into data array
int get_data(int array[],int n)
{
   int i;
   printf("Enter data for array :\n");
   for(i=0;i<n;i++)
   {
          scanf("%d",&array[i]);
   }
}

//this function prints the sorted array
int out_data(int array[],int n)
{
   int i;
   printf("Array after sorting......\n\n");
   for(i=0;i<n;i++)
   {
          printf("%d ",array[i]);
   }
}

//this function searches for particular number entry in the data array
int binary_search(int a[], int low, int high, int target)
{
    if (high < low)
        return -1;
    int middle = (low + high)/2;
    if (target < a[middle])
        return bi_search(a, low, middle-1, target);
    else if (target > a[middle])
        return bi_search(a, middle+1, high, target);
    else if (target == a[middle])
        return middle;
}

//its main code which loads user inputs to functions and perform binary search after sorting the data array
main()
{
//make sure array size is hard coded in this program (30) therefore enter number of array elements less than 30
   int n,array[30],k,b;
   printf("\n\nEnter number of elements you want to enter to data(less than 30 since array size is 30):");
   scanf("%d",&n);
   get_data(array,n);
   sort(array,n);
   out_data(array,n);
   printf("\n\nEnter value to search :");
   scanf("%d",&b);
   k=binary_search(array,0,n-1,b);
   if(k==-1)
   printf("-->%d is not found......!\n",b);
   else
   printf("-->%d is found......!\n\n",b);
}
}




Monday, March 19, 2012

Changing login shell on a Linux machine

How can you change your default login shell on a Linux machine?

Whenever you get your first account on a Linux machine, your account will use Bourne Again Shell as its default login shell. But using bash is not a requirement, you can choose any shell to be your login shell. The chsh utility is used to change your default login shell.

'chsh' allows you to change your default login shell. It prompts you for the full pathname of the new shell, which is then used as your shell for subsequent logins.

For example, I changed my default login shell from Bash to a C shell:

$ chsh ...change the login shell.

Changing shell for smith

Password: ...must verify you are who you say.

New shell [/bin/bash]: /bin/tcsh ...enter full pathname.

$ ^D ...terminate login shell.

login: glass ...log back in again.

Password: ...its private

% _ ...this time I'm in a C shell.


List of full pathnames of the shells as needed for chsh linux utility.

Shell
Full pathname
Bash /bin/bash (or /bin/sh)
Korn /bin/ksh
C /bin/tcsh (or /bin/csh)

There is also another way to find out the full pathname of your login shell, which is to type the following:

$ echo $SHELL ...display the name of my login shell.

/bin/tcsh ...full pathname of the C shell.

$ _

Thursday, March 8, 2012

BCD Incrementor Lab VHDL Code (binary-coded-decimal and show digits on 7-segment LED's)

Project specification:
The binary-coded-decimal (BCD) format uses 4 bits to represent 10 decimal digits. For example, 259 is represented as "0010 0101 1001" in BCD format. A BCD incrementor adds 1 to a number in BCD format. For example, after incrementing, "0010 0101 1001" (i.e., 259) becomes "0010 0110 0000" (i.e., 260). We want to design the circuit and display the results on three 7- segment LED displays.

The input and output of the incrementor are
input:
b2, b1, b0: three 4-bit inputs representing 3 BCD digits and b2 is the most
significant digit.
output:
y2, y1, y0: three 4-bit outputs representing 3 incremented BCD digits and y2 is
the most significant digit.

BASIC INCREMENTOR VHDL CODE:
library ieee;
use ieee.std_logic_1164.all;
entity incrementor is
port
(
x: in std_logic_vector(3 downto 0);
y: out std_logic_vector(3 downto 0);
E: out std_logic
);
end incrementor;
architecture inc_arch of incrementor is
signal p: std_logic_vector(11 downto 0);
begin
--evaluate intermediate signals
p(11) <= (not x(3)) and x(2) and x(1) and x(0);
p(10) <= x(3) and (not x(2)) and (not x(1)) and (not x(0));
p(9) <= (not x(3)) and x(2) and (not x(0));
p(8) <= (not x(3)) and x(2) and (not x(1));
p(7) <= (not x(3)) and (not x(2)) and x(1) and x(0);
p(6) <= (not x(3)) and (not x(1)) and x(0);
p(5) <= (not x(3)) and (not x(0)) and x(1);
p(4) <= (not x(2)) and (not x(1)) and (not x(0));
p(3) <= (not x(3)) and (not x(0));
p(2) <= x(3) and x(2);
p(1) <= x(3) and x(0);
p(0) <= x(3) and x(1);
--get the final outputs using intermediate signal values
y(3) <= p(11) or p(10);
y(2) <= p(9) or p(8) or p(7);
y(1) <= p(6) or p(5);
y(0) <= p(4) or p(3);
E <= p(2) or p(1) or p(0);
end inc_arch;
 

MUX VHDL CODE USED TO SELECT OUTPUT FROM INCREMENTOR:
--***************************************************************
--
-- Author: Sikander
--
-- File: mux_for_invertion.vhd
-- Design units:
-- ENTITY mux_for_invertion
-- ARCHITECTURE invertion
-- Purpose: to select particular input
-- Inputs: 2 4-bit inputs and ctl
-- Outputs: 1 4-bit output
--
-- Library/Package:
-- ieee.std_logic_1164: to use std_logic
--
-- Software/Version:
-- Simulated by: Altera Quartus v11.0
-- Synthesized by: Altera Quartus v11.0
--
-- Revision History
-- Version 1.0:
-- Date: 9/29/2006
-- Comments: Original
--
--***************************************************************
library ieee;
use ieee.std_logic_1164.all;
entity mux is
port(
a,b: in std_logic_vector(3 downto 0);
ctl: in std_logic;
output: out std_logic_vector(3 downto 0)
);
end mux;
architecture selection of mux is
signal p,q: std_logic_vector(3 downto 0);
begin
p <= (not ctl) & (not ctl) & (not ctl) & (not ctl);
q <= ctl & ctl & ctl & ctl;
output <= (a and p) or (b and q);
end selection;

DISPLAY DIGITS ON 7-SEGMENT LED OF FPGA DEVICE VHDL CODE:
--***************************************************************
--
-- Author: Sikander
--
-- File: hex_toshow_LES.vhd
-- Design units:
-- ENTITY hex_toshow_LES
-- ARCHITECTURE arch
-- Purpose: to use LED
-- Inputs: 4-bit input
-- Outputs: 7-bit output
--
-- Library/Package:
-- ieee.std_logic_1164: to use std_logic
--
-- Software/Version:
-- Simulated by: Altera Quartus v11.0
-- Synthesized by: Altera Quartus v11.0
--
-- Revision History
-- Version 1.0:
-- Date: 9/29/2006
-- Comments: Original
--
--***************************************************************
library ieee;
use ieee.std_logic_1164.all;
entity hex_toshow_LES is
port(
bin: in std_logic_vector(3 downto 0);
sseg: out std_logic_vector(6 downto 0)
);
end hex_toshow_LES;
architecture arch of hex_toshow_LES is
begin
with bin select
sseg <=
"1000000" when "0000",
"1111001" when "0001",
"0100100" when "0010",
"0110000" when "0011",
"0011001" when "0100",
"0010010" when "0101",
"0000010" when "0110",
"1111000" when "0111",
"0000000" when "1000",
"0010000" when "1001",
"0001000" when "1010",
"0000011" when "1011",
"1000110" when "1100",
"0100001" when "1101",
"0000110" when "1110",
"0001110" when others;

end arch;

FINAL BCD INCREMENTOR VHDL CODE:
--***************************************************************
--
-- Author: Sikander
--
-- File: bcd_inc.vhd
-- Design units:
-- ENTITY bcd_inc
-- ARCHITECTURE bcd_arch
-- Purpose: to function as 3 digit BCD incrementor
-- Inputs: 3 4-bit input
-- Outputs: 3 4-bit output
--
-- Library/Package:
-- ieee.std_logic_1164: to use std_logic
--
-- Software/Version:
-- Simulated by: Altera Quartus v11.0
-- Synthesized by: Altera Quartus v11.0
--
-- Revision History
-- Version 1.0:
-- Date: 9/29/2006
-- Comments: Original
--
--***************************************************************
library ieee;
use ieee.std_logic_1164.all;
entity bcd_inc is
port
(
b2, b1, b0: in std_logic_vector(3 downto 0);
y2, y1, y0: out std_logic_vector(3 downto 0)
);
end bcd_inc;
architecture bcd_arch of bcd_inc is
signal p,q,r,s: std_logic_vector(3 downto 0);
signal F,G: std_logic;
begin
b0_unit: entity work.incrementor(inc_arch)
port map(x=>b0, y=>y0, E=>F);
b1_unit: entity work.incrementor(inc_arch)
port map(x=>b1, y=>p, E=>G);
b2_unit: entity work.incrementor(inc_arch)
port map(x=>b2, y=>q);
mux1_unit: entity work.mux(selection)
port map(a=>b1, b=>p, ctl=>F, output=>y1);
mux2_unit: entity work.mux(selection)
port map(a=>b2, b=>q, ctl=>G, output=>y2);
end bcd_arch;
 

Thursday, March 1, 2012

List four important factors used to assess applications for evolution.

List four important factors used to assess applications for evolution.
Answer: Understandability How difficult is it to understand the source code of the current system? How complex are the control structures that are used? Do variables have meaningful names that reflect their function?
Documentation What system documentation is available? Is the documentation complete, consistent, and current?
Data Is there an explicit data model for the system? To what extent is data duplicated across files? Is the data used by the system up-to-date and consistent?
Performance Is the performance of the application adequate? Do performance problems have a significant effect on system users?
Programming language Are modern compilers available for the programming language used to develop the system? Is the programming language still used for new system development?
Configuration management Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system?
Test data Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system?
Personnel skills Are there people available who have the skills to maintain the application? Are there people available who have experience with the system?
(pick your choice of 4)

What are the strategic options for legacy system evolution?

What are the strategic options for legacy system evolution?
Answer: There are four strategic options:
1. Scrap the system completely: This option should be chosen when the system is not making an effective contribution to business processes. This commonly occurs when business processes have changed since the system was installed and are no longer reliant on the legacy system.
2. Leave the system unchanged and continue with regular maintenance: This option should be chosen when the system is still required but is fairly stable and the system users make relatively few change requests.
3. Reengineer the system to improve its maintainability: This option should be chosen when the system quality has been degraded by change and where a new change to the system is still being proposed. This process may include developing new interface components so that the original system can work with other, newer systems.
4. Replace all or part of the system with a new system: This option should be chosen when factors, such as new hardware, mean that the old system cannot continue in operation or where off-the-shelf systems would allow the new system to be developed at a reasonable cost. In many cases, an evolutionary replacement strategy can be adopted in which major system components are replaced by off-the- shelf systems with other components reused wherever possible.

What are the principal systems re-engineering activities?

What are the principal systems re-engineering activities?
Answer: The activities in this reengineering process are as follows:
1. Source code translation: Using a translation tool, the program is converted from an old programming language to a more modern version of the same language or to a different language.
2. Reverse engineering: The program is analyzed and information extracted from it. This helps to document its organization and functionality. Again, this process is usually completely automated.
3. Program structure improvement: The control structure of the program is analyzed and modified to make it easier to read and understand. This can be partially automated but some manual intervention is usually required.
4. Program modularization: Related parts of the program are grouped together and, where appropriate, redundancy is removed. In some cases, this stage may involve architectural refactoring (e.g., a system that uses several different data stores may be refactored to use a single repository). This is a manual process.
5. Data reengineering: The data processed by the program is changed to reflect program changes. This may mean redefining database schemas and converting existing databases to the new structure. You should usually also clean up the data. This involves finding and correcting mistakes, removing duplicate records, etc. Tools are available to support data reengineering.

What process metrics might be used to assess maintainability?

What process metrics might be used to assess maintainability?
Answer: Examples of process metrics that can be used for assessing maintainability are as follows:
1. Number of requests for corrective maintenance: An increase in the number of bug and failure reports may indicate that more errors are being introduced into the program than are being repaired during the maintenance process. This may indicate a decline in maintainability.
2. Average time required for impact analysis: This reflects the number of program components that are affected by the change request. If this time increases, it implies more and more components are affected and maintainability is decreasing.
3. Average time taken to implement a change request: This is not the same as the time for impact analysis although it may correlate with it. This is the amount of time that you need to modify the system and its documentation, after you have assessed which components are affected. An increase in the time needed to implement a change may indicate a decline in maintainability.
4. Number of outstanding change requests: An increase in this number over time may imply a decline in maintainability.

What factors should be assessed to understand the relationship between a system and its environment?

What factors should be assessed to understand the relationship between a system and its environment?
Answer: The following factors should be assessed to evaluate the relationships between a system and its environment:
1. The number and complexity of system interfaces: The larger the number of interfaces and the more complex these interfaces, the more likely it is that interface changes will be required as new requirements are proposed.
2. The number of inherently volatile system requirements: Requirements that reflect organizational policies and procedures are likely to be more volatile than requirements that are based on stable domain characteristics.
3. The business processes in which the system is used: As business processes evolve, they generate system change requests. The more business processes that use a system, the more the demands for system change.

What are the three different types of software maintenance and how is effort distributed across these maintenance types?

What are the three different types of software maintenance and how is effort distributed across these maintenance types?
Answer: There are three different types of software maintenance:
1. Fault repairs: Coding errors are usually relatively cheap to correct; design errors are more expensive as they may involve rewriting several program components. Requirements errors are the most expensive to repair because of the extensive system redesign which may be necessary.
2. Environmental adaptation: This type of maintenance is required when some aspect of the system’s environment such as the hardware, the platform operating system, or other support software changes. The application system must be modified to adapt it to cope with these environmental changes.
3. Functionality addition: This type of maintenance is necessary when the system requirements change in response to organizational or business change. The scale of the changes required to the software is often much greater than for the other types of maintenance.

Effort distribution:
Fault Repair (17%), Environmental Adaptation (18%), Functionality Addition (65%)