Software Engineering Solved Paper June 2013: Fundamentals and Critical Systems, Exams of Software Engineering

Download Software Engineering Solved Paper June 2013: Fundamentals and Critical Systems and more Exams Software Engineering in PDF only on Docsity!

2) Customized Products  These are systems which are developed for a particular customer.  A software-contractor develops the software especially for that customer.  The company which is buying the software controls the software-specification.  The software-developers must work to that specification.  For example: → electronic-device control systems & → air-traffic control systems.

**1c. Explain emergent system properties with example (10 Marks) Ans: EMERGENT SYSTEM PROPERTIES

1. Functional Emergent Properties**

• These properties appear when all parts of a system work together to achieve some objective.
• For ex, After a bicycle is assembled from different components, the bicycle has the functional property of a transportation-device. 2) Non-functional Emergent
• These properties relate to the behavior of the system in its operational environment.
• For ex, → reliability → performance → safety & → security.
• Failure to achieve these properties may make the system unusable.
• Most often, a system which is unreliable or too slow is rejected by all the end-users.

**EXAMPLES OF EMERGENT PROPERTIES

1. Volume**

• The volume means the total space occupied in the system.
• The volume varies depending on how the components are arranged and connected. 2) Reliability
• System-reliability depends on component-reliability.
• Unexpected-interactions between components can cause new types of failure. Therefore, this affects the reliability of the system.
• Three types: 1) Hardware Reliability  What is the probability of a hardware-component failing?  How long does it take to repair the component? 2) Software Reliability  How likely the software-component will produce an incorrect output? 3) Operator Reliability  How likely the system-operator will make an error? 3) Security
• The security of the system cannot be easily measured.
• Attacks may be devised which are not anticipated by the system-designers.
• Attacks may defeat built-in safeguard. 4) Repairability
• How easy it is to fix a problem in the system, once it has been discovered?
• This depends on being able to i) Diagnose the problem ii) Access the faulty-components and iii) Modify or replace the components. 5) Usability
• How easy it is to use the system?
• This depends on i) Technical-components ii) Component’s operators and iii) Component’s operating environment.

2a. Explain the different types of critical systems. (06 Marks) Ans: CRITICAL SYSTEMS

• These are socio-technical systems that people or businesses depend-on.
• Failure of the systems results in i) Serious problems and ii) Significant losses.
• Three main types: 1) Safety-Critical Systems  A system whose failure may result in → injury → loss of life or → serious environmental damage.  Example: Control-system in a chemical manufacturing plant. 2) Mission-Critical Systems  A system whose failure may result in the failure of some goal-directed activity.  Example: Navigational-system in a spacecraft. 3) Business-Critical Systems  A system whose failure may result in very high costs for the business.  Example: Customer accounting-system in a bank. A SIMPLE SAFETY-CRITICAL SYSTEM
• Automated insulin delivery-systems → monitor blood sugar-levels & → deliver an appropriate dose of insulin when required (Figure 3.1).
• A software-controlled insulin- system works by using a micro-sensor embedded in the patient.
• The micro-sensor is used to measure some blood parameter that is proportional to sugar-level.
• The controller computes the sugar-level and the amount of insulin that is needed.
• Then, the controller sends signals to a miniaturised pump to deliver the insulin via a needle.
• There are 2 high-level dependability requirements:
  1. The system should be available to deliver insulin when required (Figure 3.2).
  2. The system should deliver the correct amount of insulin.

Figure 3.1 Insulin pump structure

Figure 3.2 Data-flow model of the insulin pump

• Six best practices are recommended: 1) Develop Software Iteratively  Plan increments of the system based on customer-priorities.  Develop & deliver highest priority system-features early in the development-process. 2) Manage Requirements  Explicitly document the customer’s requirements.  Keep track of changes to customer’s requirements.  Analyze the impact of changes on the system before accepting them. 3) Use Component-based Architectures  Structure the system-architecture into components. 4) Visually Model Software  Use graphical-models to present static- and dynamic-views of the software. 5) Verify Software Quality  Ensure that the software meets the organizational quality-standard. 6) Control Changes to Software  Manage changes to the software using i) change management-system & ii) configuration-management tools.

**2c. Explain security terminologies. (05 Marks) Ans: SECURITY TERMINOLOGIES

1. Exposure**  Possible loss or harm in a computing-system.  This may be loss or damage to data.  This may be a loss of time & effort if recovery is necessary after a security breach. 2) Vulnerability  A weakness in a computer-system that may be exploited to cause loss or harm. 3) Attack  An exploitation of a system’s vulnerability.  Often, attack is from outside the system.  Often, attack is a deliberate attempt to cause some damage. 4) Threats  Circumstances that have potential to cause loss or harm.  Threats are a system-vulnerability that is subjected to an attack. 5) Control  A protective measure that reduces a system’s vulnerability.  For ex: Encryption can be used to reduce a vulnerability of a weak access control system.

3a. Explain the metrics for specifying non-functional requirements. (06 Marks) Ans:

3b. Explain requirement engineering process. (06 Marks) Ans: Requirement Engineering Process

• The goal is to create and maintain a system requirement document.
• The overall process includes 4 sub-processes: 1) Feasibility Study: Concern with accessing whether system is useful to the business. 2) Elicitation & Analysis: Discovering requirement and analyzing them. 3) Specialization: Converting this requirement into some standard form. 4) Validation: Checking that the requirement actually defines the system that the customer wants.
• These activities are concerned with → discovery documentation & → checking of requirements.
• The people involved in development gain better understanding of → what they want to do the software → modification made to the software and organizational environment.
• The process of managing these changing requirements is called requirement management.

Figure 7.1 The requirements engineering process

4a. List and explain different types of system models. (10 Marks) Ans: CONTEXT MODEL

• This shows how the system is positioned in an environment with other systems and processes.
• They also define the boundaries of the system (Figure 8.1).
• However, they do not show the relationships between → specified system and → other systems in the environment.

Figure 8.1 The context of an ATM system

BEHAVIORAL MODEL

• This is used to describe the overall behavior of the system.
• Two types of model: 1) Data-flow models and 2) State machine models. Data Flow Models  This shows how data is processed at different stages in the system.  This also shows how data flows through a sequence of processing stages.  Notations used to represent the model (Figure 8.4): 1) Oval represents functional processing. 2) Rectangle represents data stores. 3) Labeled arrow represents data movements between functions.

Figure 8.4 Data-flow diagram of library loans system

State Machine Model  This shows how the system reacts to internal & external events.  This does not show the flow of data within the system.  Assumption: At any time, the system is in one of the possible states.  When a stimulus is received, the system changes from one state to another state.  An event is something that affects the system.  Application: Used for modeling real-time systems.

Figure 8.5: State machine model of ON/OFF button

DATA MODEL

• This is used to describe the logical structure of data processed by the system (Figure 8.7).
• Most commonly used technique is ERA model (Entity Relation Attribute).
• ERA model shows
  1. Data entities
  2. Associated attributes and
  3. Relations b/w the entities.
• ER models are commonly used in database design.
• This can be implemented using relational databases.

Figure 8.8 Semantic data model for the library system

OBJECT MODEL

• This describes the system in terms of object-classes and their associations.
• They may be used to represent both system-data and its processing.
• An object is executable entity with the attributes and services of the class.
• A class is a set of objects with common attributes and the operations provided by each object.
• A class is represented as a rectangle.
• The rectangle contains 3 sections (Figure 8.10):
  1. Name of the class is in the top section.
  2. Attributes are in the middle section.
  3. Operations associated with the class are in the bottom section.

Figure 8.10: Object Model of contact management system

5) Personnel Selection & Evaluation

• Project-managers must select people to work on their project.
• Project-managers have to settle for a less-than-ideal project-team. The reasons for this are: i) The project-budget may not cover the use of highly paid staff. ii) Staff with the appropriate experience may not be available. iii) The organisation may wish to develop the skills of its employees. 6) Report Writing & Presentations
• Project managers are usually responsible for reporting on the project to both i) Client and ii) Contractor organisations.
• They have to write brief documents that abstract critical information from detailed project reports.

5a. With an example describe the repository-model and give its advantages and disadvantages. (10 Marks) Ans: REPOSITORY-MODEL

• In a system, the subsystems exchange information so that they can work together effectively.
• Information can be exchanged in 2 ways. 1) Centralized  All shared data is held in a central-database (Figure 11.2).  These data can be accessed by all subsystems. 2) Distributed  Each subsystem maintains its own database.  Data is interchanged with other subsystems by passing messages to them.
• The systems that use large amounts of data are organized around a shared-database (or repository).
• This model is suitable to applications where → data is generated by one sub-system and → data is used by another sub-system.
• Examples include → control/CAD systems → management information system (MIS) and → CASE toolsets.

Figure 11.2 The architecture of an integrated CASE toolset

ADVANTAGES OF REPOSITORY-MODEL

1) Efficient Data Sharing  Large amount of data can be shared efficiently.  There is no need to transmit data explicitly from one sub-system to another. 2) Data Independence  Subsystems need not be concerned with how data is produced. 3) Centralized Management  Following activities are centralized: i) Backup ii) Security and iii) Access control  These activities are the responsibility of the repository-manager.  Tools can focus on their principal function rather than be concerned with these issues. 4) Easy Integration  It is easy to integrate new tools if they are compatible with the agreed data model. **DISADVANTAGES OF REPOSITORY-MODEL

1. Subsystems must agree on a repository data-model**  Obviously, this is a compromise between the specific needs of each tool.  Performance may be badly affected by this compromise.  It may be difficult to integrate new sub-systems if they are not compatible with the agreed data model. 2) Data-Evolution is difficult & expensive  A large amount of information is generated.  Translating agreed data model to a new model is expensive. 3) No scope for specific management policies  Different subsystems may have different requirements for security/backup policies.  The repository-model forces the same policy on all sub-systems. 4) Difficult to distribute efficiently  In distribute repository, there may be problems with data redundancy & inconsistency.

**6a. Explain the principles of agile methods. (06 Marks) Ans: PRINCIPLES OF AGILE METHODS

1. Customer Involvement**

• Customers should be closely involved throughout the development process.
• Customer’s role: → provide and priorities new system requirements. → evaluate the iterations of the system. 2) Incremental Delivery
• The software is developed in increments.
• The customer specifies the requirements to be included in each increment. 3) People not Process
• The skills of the development-team should be recognized and exploited.
• Team members should be left to develop their own ways of working w/o prescriptive processes. 4) Embrace Change
• Expect the system-requirements to change, so design system to accommodate these changes. 5) Maintain Simplicity
• Focus on simplicity in both → developed software and → development process.
• Wherever possible, actively work to eliminate complexity from the system.

6b. What is pair programming? Explain its advantages. (06 Marks) Ans:

• The programmers work in pairs to develop the software.
• They actually sit together at the same workstation to develop the software.
• Development does not always involve the same pair of people working together.
• Basic idea: Pairs are created dynamically so that all group-members may work with other members in a pair.
• Advantages: 1 ) Supports the idea of common ownership & responsibility for the system.  The software is owned by the team as a whole.  The individuals are not held responsible for problems with the code.  The team has collective responsibility for resolving the problems. 2 ) Acts as an informal review process.  Each line of code is looked at by at least 2 people.  Code inspections/reviews are very successful in discovering a high percentage of errors.  Drawbacks of code inspections/reviews: i) They are time consuming to organize. ii) They introduce delays into the development-process.  Advantage: Pair programming is a much cheaper inspection process than formal program inspections. 3 ) Helps to support refactoring.  Refactoring is a process of software-improvement.  Principle of extreme programming: The software should be constantly re-factored i.e. the code should be rewritten to improve their clarity or structure.  Drawbacks of refactoring: i) This is effort that is used for long-term benefit. ii) Individual who practices refactoring is judged less efficient than s/w developer.  If pair programming and collective ownership are used, then others benefit immediately from the refactoring so they are likely to support the process.

**6c. Explain Lehman’s laws of program evolution dynamics. (08 Marks) Ans: LEHMAN’S LAWS

1. Continuing Change**

• A program that is used in a real-world environment necessarily must change.
• The program necessarily becomes progressively less useful in that environment. 2) Increasing Complexity
• As an evolving program changes, its structure tends to become more complex.
• Extra resources must be dedicated to preserving and simplifying the structure. 3) Large Program Evolution
• Program evolution is a self-regulating process.
• System attributes such as size & time is approximately invariant for each system release. 4) Organisational Stability Approximately
• Over a program’s lifetime, → Program’s rate of development is constant. → Program’s rate of development is independent of resources used for system development 5) Conservation of Familiarity
• Over the lifetime of a system, the incremental change in each release is approximately constant. 6) Continuing Growth Increase
• The functionality offered by systems has to continually to maintain user satisfaction. 7) Declining Quality
• The quality of systems will decrease if they are not adapted to changes in their operational environment. 8) Feedback System
• Evolution processes incorporate multi-agent, multi-loop feedback systems.
• You have to treat them as feedback systems to achieve significant product improvement.

**7a. Briefly explain the roles in inspection process. (06 Marks) Ans: INSPECTION ROLES

1. Author or Owner**  He is responsible for → producing the program → fixing defects. 2) Inspector  He is responsible for → finding errors/inconsistencies in programs → identifying broader issues that are outside the scope of the inspection-team. 3) Reader  He is responsible for presenting the code at an inspection-meeting. 4) Scribe  He is responsible for recording the results of the inspection-meeting. 5) Chairman or Moderator  He is responsible for → managing the process → facilitating the inspection and → reporting process-results to the chief-moderator. 6) Chief Moderator  He is responsible for → inspection process improvements → checklist updating and → standards development.

7c. Explain general model of testing with the help of block diagram (08 Marks) Ans: GENERAL MODEL OF TESTING

• Test-cases are specifications of → inputs to the system → expected-output from the system → statement of what is being tested (Figure 23.2).
• Test-data are the inputs devised to test the system.
• Test-data can sometimes be generated automatically. But automatic test case generation is impossible.
• The output of the tests can only be predicted by people who understand the system.
• Testing has to be based on a subset of possible test cases.
• Ideally, software companies should have policies for choosing the subset of possible test cases.
• The policies might be based on → general testing-policies. → experience of system-usage.
• For example:
  1. All program statements should be executed at least once.
  2. All system functions that are accessed through menus should be tested.
  3. Combinations of functions that are accessed through the same menu must be tested.
  4. Where user-input is provided, all functions must be tested with both correct & incorrect input.

Figure 23.1 Testing phases

Figure 23.2 A model of the software testing process

• The managers have to make decisions on who should be responsible for the different stages of testing.
• Different types of testing: 1) Component Testing  This is the process of testing individual components in the system (Figure 23.1).  Main goal: → To expose faults in the components.  The developers of components are responsible for component-testing. 2) Integration Testing  The integration team → integrates the modules from different developers → builds the software and → tests the system as a whole. 3) System Testing  System Testing has to be based on a written system specification.  This can be → detailed system-requirements specification or → higher-level user-oriented specification.  A separate team is normally responsible for system testing.  The testing-team works from the user/system-requirements documents to develop testing-plans.

**8a. Explain any five factors governing staff selection. (05 Marks) Ans: FACTORS GOVERNING STAFF SELECTION

1. Application-domain Experience**

• Main requirements of developer are: i) The developers must understand the application-domain. ii) The developers must have some domain experience. 2) Platform Experience
• If low-level programming is involved; Then platform experience may be important attribute; Otherwise, platform experience is not a critical attribute. 3) Programming Language Experience
• This is an important attribute for → short-duration projects or → where there is not enough time to learn a new language.
• Learning a language itself is easy task.
• But, it takes several months to become expert in using the associated libraries/components. 4) Problem Solving Ability
• This is important for software engineers who constantly have to solve technical problems.
• However, it is not possible to judge without knowing the work of the group-member. 5) Educational Background
• This provides an indication of → what the candidate knows and → what is his ability to learn new concepts.
• This factor becomes irrelevant as engineers gain experience across a range of projects. 6) Communication Ability
• There must be proper oral/writing communication among i) Project-staff ii) Other engineers iii) Project-managers and iv) Customers. 7) Adaptability
• Adaptability may be judged by looking at the experience that candidates have had.
• This is an important attribute, as it indicates an ability to learn. 8) Attitude
• Project-staff should have a positive attitude toward their work.
• Project-staff should be willing to learn new skills. 9) Personality
• Candidates must be reasonably compatible with other group-members.
• No particular type of personality is more or less suited to software engineering