293088155 Software Engineering 2015 Solved Question Papers for VTU Information Science Semester 5 PDF

Preview

Summary

computer software subject...

Description

SoftwareEngineering 

10IS51

Question Papers Solutions UNIT - 1 1. What is softwa re engineering? What are the attributes of good software? Key challenges facing Softwa re Engineering.] [July 2013, Dec 2013, June 20 15] [5 to 10M] Ans : Com puter programs and associated documentat ion. Software products may b e developed for a particular customer or may be developed for a general market. Software products may be • Generic - dev eloped to be sold to a range of different customers • Bespoke (custom) - developed for a single customer according to their specification  Soft ware engineer ing is an engineering discip line which is co ncerned with a ll aspects of soft ware production.  Soft ware engineers should adopt a s ystematic and organized appro ach to their work and use appropriate tools and techniques depending on the problem to be solved, the develop ment constraints and the resources a va ilab le.

Attributes of a good software : Software is engineered and not manufactured. Software does not ware out Most softwares are custom built rather than being assembled from components

DeptofISE,SJBIT

Page1

SoftwareEngineering 

10IS51

                 2. Describe four Ethics & Professional responsibilities of a software engineer.[ Dec 2014] [5M]

DeptofISE,SJBIT

Page2

SoftwareEngineering 

10IS51

3. Define Socio technical systems and explain Emergent system p roperties with example. [June 2013] [5M]

The entire prop erties of a system are cal led Emergent properties.

DeptofISE,SJBIT

Page3

SoftwareEngineering 

10IS51

                   4. Describe briefly the phases of System engineering p rocess with neat dia gram. [June 2013, Dec 2014, June 2015] [10M] [ 5M]

DeptofISE,SJBIT

Page4

SoftwareEngineering 

10IS51

System require ments definition: This requirements definition phase usu all y concentrates on deriving three t ypes of requirement: 1. Abstract functional requirements: Th e basic fu nctions that the sys tem must provide are defined at an abstr act level. More detailed functional requirements specific ation t akes place at the sub-sys tem level. For example, in an air traffic control sys tem, an abstract functional requirement would specify that a flight-plan database sho uld be used to store the flight plans of al l aircraft entering the control led airsp ace. However, you would not normally specify the d etails of the database unless they affe cted the requirements of o ther sub-systems. 2. System pro per ties : These are non-functional emergent system properties such as availability, performance and safet y, as I have discussed above. Th ese nonfunct ional system properties affect the requirements for all sub -systems. 3. Characteristics that the system must not exhibit It is sometimes as important to sp ecif y what the system must not do as it is to specify what the system should do. For example, if you are specif ying a n air traffic control system, you might specify th at the system should not present the controller with too much information. System Design: The activities in volved in this process are:

I. Part ition requirements You analyse the requirements and organise them into related groups. There are usual ly several possible partitioning optio ns, and you may su gg est a number of alternatives at this stage of the process. 2. Identif y sub-systems You sho ul d ident ify sub-systems that can individually o r col lectively meet the requirements. Groups o f requirements are usually related to sub-systems, so this activity and requirements partitioning m ay b e amalgamated. However, sub -system identification may also be influenced by other organi zational or environmental factors. 3. Assign requirements to sub-sys tems You ass ign the requirements to subsystems. In principle, this should be straightforward if the requirements partitioning is used to drive the sub-system identification. In practi ce, there is never a clean match between requirements partitions a nd identified sub-systems. Limitat ions of extern ally purchased sub-systems may mean that you have to change the requirements to accommodate these constraints. 4. Specify sub -system functionality You should specify th e specific fun ctio ns provided by each sub-system. This may b e seen as part of the system design phase. 5. Define sub-system interfaces You define the interfaces that are provided and required by ea ch sub- sys tem. Once these interfaces h ave b een agreed upon, it beco mes possible to develop these sub -sys tems in parallel. System modeling: DeptofISE,SJBIT

Page5

SoftwareEngineering 

10IS51

During the system requirements and des ign activit y, systems may be model led as a set of components and relationships between these components. These are normally illustrated graphicall y in a sys tem architecture model that gives the reader an overview of the system organisation. The system architecture may be presented as a block diagram showing the major subsystems and the intercon nections between these sub-systems. When drawing a block diagram, you should represent each sub- sys tem using a rectangle, and you should show relationships between the sub-systems using arrows that link these rectangles. The relat io nships indicated may include data flow, a uses'/' use d by' relationship or some other type of dependency relatio nship. Sub-system development : During sub-system development, Ihe sub- sys tem s identified dur ing system design are implemented. This may involve starting another sys te m engineering process for individual sub-systems or, if the sub- sys tem is software, a software process involving requirements, design, implementation and testing. Systems integration: During the systems integration pr ocess, yo u take the independently developed subsystems and put them t ogether to make up a complet e sys tem. Integration can b e done using a 'big bang' approach, where all the sub- sys tems are integrated at the same t ime. However, for technical and managerial purposes, an incremental integration process where sub-systems are integrated one at a time is the best appro ach, for two reasons: 1. It is usually impossible to schedule the develo pment of all the sub-systems so that they are all finished at the same time. 2. Incremental integration reduces the cost of error location. If many sub-systems are simultaneousl y integrate d, an error that arises during t esting may be in any of these subsystems. When a single sub-system is integrated with an already working system, errors that occur are pr obabl y in the newly integrated sub-sys tem or in the interactions b etween the exist ing subsystems and the new sub-system. System evolution: La rge, complex systems have a very long lifetime. During their life, they are changed to correct errors in the original system requirements and t o implement new requirements that have emerged. The system's co mputers are likely to be repl aced with new, faster machines. System evolution is inherently costly for several reasons: 1. Proposed changes have t o be anal yzed very carefully from a business and a technical perspective. Changes have t o contribute to the goals of the sys tem and should not simply be techni cally motivated. 2. Because sub-systems are n ever completel y i ndependent, changes to one subsys tem may adversel y affect the performance or behavior of other subsystems. Consequent changes to these sub-systems may t herefore be needed. 3. The reasons for or iginal design decisio ns are often unrecorded. Those responsible for the system evolution have to work out why particular design d ecisions were made. 4. As systems a ge, their structure typicall y becomes corrupted b y change so the costs of making further changes increases.

DeptofISE,SJBIT

Page6

SoftwareEngineering 

10IS51 UNIT -2

1. Explain the different dimensions of dependability with a neat diag ram [ Dec 2013, June 2015] [5M].

There are four principal dimensio ns to dependability:

1. Avai lability Informally, the availability of a s ystem is the probability th at it will be up and runni ng and able to del iver useful services at any given time. 2. Reliability Informally, the reliability of a system is the probabil it y, over a given period of t ime, that the system will correctly deliver services as expected by the user. 3. Safety Informall y, the safety of a system is a judgment of how likely it is that the system will cause dama ge to people or its environment. 4. Security Informally, the security of a system is a judgment of how likely it is that the system can resist accidental or deliberate intrusio ns. 2. What is process iteration? Explain Boehm’s spiral model. [July 2013, Jan 2014] [ 1 0 M]

Iterat ion approach interleaves the activities of specification, development a nd validation. An initial system is rapidly devel ope d from very abstract specifications. This is then refined with customer input to produ ce a system that satisfies the customer s needs. The system may then be delivered. Alternatively, it may b e re-implemented using a more structured appro ach to produce a more robust and maintainable system. In a spiral model, process is represented as a spiral rather than as a seque nce of act ivities with backtracking Each loop in th e spiral represents a ph ase in the process.No fixed phases such as specification or design -loops in the spiral are ch osendepending on what is required. Risks are expl icitly assessed and resolved throughout the process.This model is developed by Barry Bohem. It is an evolutionary software process model.

DeptofISE,SJBIT

P age7

SoftwareEngineering 

10IS51

The goal of this m odel is to provide a framework for designing such process, guided b y the risk levelsin the project at h and. The spiral model may be viewed as a meta-model. This model focuses on identifying and el iminating high risk problems by careful process design.

3. What are th e four basic process activities? Explain the general model of design process with a neat diagram. . [June 2 0 14] [10M] Process activities: 1. Software specificatio n The functionality of the software and constraints on its operation must be defined. 2. Software design and implementation The software to m eet the specification must be produced. 3. Softw are validation The software must be validated to ensure that it does what the customer wants. 4. Software evolution The software must evolve to m eet changing customer needs. The specific design process activities are: 1. Archi tectural design The sub-systems making u p the sys tem and their relationships are identified and documente d. 2. Abstract specification For e ach su b- sys tem, an abstr act specification of its services and the constraints under which it must operate is produced.

DeptofISE,SJBIT

Page8

SoftwareEngineering 

10IS51

3. Interface design For each su b-system, its interface with other sub-sys tems is d esigned and documented. This interface specification must be unambiguous as it allows the subsystem to be used without knowledge of the sub-system operation . 4. Component design Services are allocated to components and the interfaces of these components are design ed. 5. Data structure design The data stru ctures used in the system implementation are designed in detail and speci l1ed. 6. Algori thm design The algorithms used to provide servi ces are designed in detail and specified.

4. With a figure, explain phases in RUP. [June 2013, June2015] [5M] The Rational Unified Pr ocess (RUP) is an example of a modern process model that has been derived from work on the UML and the associated Unified Software Development Process. RUP is normally descri bed from three perspe ctives: I. A dynamic perspective that shows the phases of the mod el over t ime. 2. A static perspective that shows the process activities that are enacted. 3. A practice perspe ctive that suggests good practices to be used during the pro cess. Figure shows the phases in the RUP.

These are: 1. In ception The goal of t he inception phase is to establ ish a business case for the system.

DeptofISE,SJBIT

Page9

SoftwareEngineering 

10IS51

2. Elab orat ion The goals of the elaboration phase are to develop an understanding of the problem domain, establ ish an architectural framework for the system, develop the project plan and identify key project risks . 3. Construct ion The co nstruction phase is essentially concerned with system design, programming and testing. Parts of the system are developed in parallel and integrated during this phase. 4. Transit ion The final phase of the RUP is concerned with moving the system from the development community to the user community and m aking it work in a re al environment. 5 . W h a t i s C r i t i c a l s y s t e m s ? E x p l a i n D i m e n s i o n s o f d e pe n d a b i l i t y ? [June 2013,June 2015][6M] For critical systems, it is usually the case that the most important system p roperty is t he dependability of the system. The dependability of a system reflects the user’ s degree of trust in that system. It reflects the exte nt of the u ser’s confiden ce that it will operate as users expect and that it will not ‘fail’ in normal u se. Usefu lness and tru stworthine ss are not the sa me thing. A system does not have to be trusted to be useful Dimensio ns of depen dability

DeptofISE,SJBIT

Page10

Soft wareEngineering 

10IS51 UNIT-3

1.

Describe functional and non -functiona l requirements with examples. [ Dec 2 013, Ju ne 2015][10M]

Software system requirements are often classified as functional requirements, nonfunctional requirements or domain requirements: 1. Functional requirements These are statements of servi ces the system should provide, how the system should react to particular inputs and how the sys tem should behave in particular situations. In some cases, the fun ctional requirements may also explicitly state what the system should not do. 2. Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards. Non-functional requirements often apply to the system as a whole. They do not usuall y just appl y to individual system features or services. Functional requirements: Example, here are examples of functional requirements for a university library system called LIBSYS, used by students and faculty to order boo ks and documents from other libraries. 1. The user shall be able to search either all of the initial set of databases or select a subset from it. 2. The system shall provide appropriate viewers for the user to read docum ents in the document store. 2. Every order shall be allocated a unique identifier (ORDER_ID), which the user shall be able to copy to the a ccount's permanent stora ge area.

DeptofISE,SJBIT

Page11

Softwar eEngineering 

10IS51

Non-functional requirements: Types of Non-funct ional requirements:

              Non-functional requirements are not just concerned with the software system to be developed. Some non-funct ional requirements m ay constrain th e pr ocess that should be used to develop the system. Examples of proc ess requirements include a specification of the quality standards that sho uld be used in the process, a specification that the design must be produced with a particular CASE toolset and a description o f the process that should be followed. 2. What are th e metrics used to specify non -functional system properties? [ July 2013] [5 M]

Sl No Property 1

Speed

Measure Processed transaction/second User/Event response time Screen refresh time

DeptofISE,SJBIT

2

Size

kilo bytes Number of Ram chips

3

Ease of Use

Training time Number of help frames

4

Reliability

M ean time to failure

Page12

SoftwareEngineering  

10IS51 Probability of unavailability Rate of failure occurance Availability

5

Robustness

6

Portability

Time to restart after failure Percentage of events causing failure Probability of data corruption Percenta ge of target dependent statements Number of target systems

3. Explain the IEEE standard format for requirement document in detail. [Dec 2013 ] [6M]

IEEE standard suggests the following structure for requirements documents: 1. Introduction 1.1 Purpose of the requiremt:nts document 1.2 Scope of the produ ct 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 2. Gen er al description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific requirements cover functional, non-functional and interface requirements. This is obviously the most subs tantial part of the document but b ecause of the wide variabil ity in organi zational practice, it is not appropriate to defin e a sta ndard structure for this section. 4. Appendices 5. Index The structure of a requirements document:

DeptofISE,SJBIT

Page13

SoftwareEngineering 

10IS51

                                 4. Explain requirements elicitation and analysis process and its activities. [ Jan 2014 ] [10M]

DeptofISE,SJBIT

Page14

SoftwareEngineering 

10IS51

The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the system and ev eryone else in an organisation that may be affected by its installation. Other sys tem stakeholders may be engineers who are developing or maintaining related systems, business managers, domain ex perts and trade union representatives. Eliciting and understanding stakeholder requirements is difficul t for several reasons: 1. Stakeholders often don't know what they want from the co mputer sys tem exce pt in the most general terms. They may find it difficult to articulate what they want the system to do or make unrealistic demands beca use they are unaware of the cost of their requests. 2. Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work. Requirements engineers, without ex perience in the customer's domain, must understand these requirements. 3. Different stakeholders have different requirements, which they m ay express in different ways. Requirements engineers have to consider all potential sources o f requirem ents and discover commonalities and conflict. 4. Political factors may influence the requirements of the sys tem. For example, managers may demand specific sys tem requirements that will increase their influenc e in the organisation. 5. The econom ic and business environment in which the anal ys is takes place is d ynamic. It inevitabl y changes during the anal ys is process. Hence the importance of particular requirements may chan ge. New requirements may emerge from new stakeho lders who were not origin all y consulted. A ver y general process model of the elicitation and anal ysis process is shown in figure:

DeptofISE,SJBIT

Page15

SoftwareEngineering ...