PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of MCA

Size: px

Start display at page:

Download "PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of MCA"

Merry Lawson
5 years ago
Views:

USN 1 P E PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of CA INTERNAL ASSESSENT TEST II Date : 20/09/2016 ax.

1 USN 1 P E PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of CA INTERNAL ASSESSENT TEST II Date : 20/09/2016 ax.arks: 50 Subject & Code: Software Engineering (13CA33) Time: 08:30A 10:00A Faculty Name : s. anjula.c..prasad SOLUTION SET NOTE: Answer any five Questions: 1 a Explain requirement elicitation and analysis process with a neat diagram. 06 In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints, and so on. Requirements elicitation and analysis may involve a variety of people in an organisation. The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include endusers who interact with the system and everyone else in an organisation that may be affected by its installation.

2 Other system stakeholders may be engineers who are developing or maintaining related systems, business managers, domain experts and trade union representatives. Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system s operational constraints. ay involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts. Requirements documentation Requirements are documented and input into the next round of the spiral. Requirements discovery The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems. Viewpoints Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements. Interactor viewpoints People or other systems that interact directly with the system. In an AT, the customer s and the account database are interactor VPs. Indirect viewpoints Stakeholders who do not use the system themselves but who influence the requirements. In an AT, management and security staff are indirect viewpoints. Domain viewpoints Domain characteristics and constraints that influence the requirements. In an AT, an example would be standards for inter-bank communications. Interview In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of

3 issues are explored with stakeholders. Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn t worth articulating. Scenarios Scenarios are real-life examples of how a system can be used. They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes. Use-cases Use-cases are a scenario based technique in the UL which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system b What is requirement validation and what are the different checks to be carried out during requirement validation? Requirement validation is Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Validity. Does the system provide the functions which best support the customer s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? 04

2 a What is System odelling? Explain Use case odelling with example. System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

4 2 a What is System odelling? Explain Use case odelling with example. System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. 06 odeling user interaction is important as it helps to identify user requirements. odeling system-to-system interaction highlights the communication problems that may arise. odeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. Use case diagrams and sequence diagrams may be used for interaction modeling. Use cases were developed originally to support requirements elicitation and now incorporated into the UL. Each use case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or other systems. Represented diagrammatically to provide an overview of the use case and in a more detailed textual form. b Explain Sequence modelling with HC-PS example. Sequence diagrams Sequence diagrams are part of the UL and are used to model the interactions between the actors and the objects within a system. Sequence diagram has two dimensions are, Vertical Dimension Horizontal Dimension Horizontal dimension represent different objects- objects in real world. Ex: card reader, AT screen Vertical dimension represent the time. Vertical line is called the object s lifeline Object s lifeline represents the object s existence during the interaction. A sequence diagram shows the sequence of interactions that take place during 04

a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these.

5 a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows. 3 a Explain Data driven/activity modelling with example. System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. 05 Behavioural models are used to describe the overall behaviour of a system. Two types of behavioural model are: Data processing models that show how data is processed as it moves through the system; State machine models that show the systems response to events. l These models show different perspectives so both of them are required to describe the system s behaviour. l l Data flow diagrams (DFDs) may be used to model the system s data processing. l These show the processing steps as data flows through a system. l DFDs are an intrinsic part of many analysis methods. l Simple and intuitive notation that customers can understand. Show end-to-end processing of data l l DFDs model the system from a functional perspective. Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system. Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment

They show the system s responses to stimuli so are often used for modelling real-time systems.

6 b Explain Event driven/ State machine modelling with icrowave open example. These model the behaviour of the system in response to external and internal events. They show the system s responses to stimuli so are often used for modelling real-time systems. State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. Statecharts are an integral part of the UL and are used to represent state machine models. 05

7 4 a What are the advantages of software architecture? Explain Layered pattern with example. Architectural design is an early stage of the system design process. Represents the link between specification and design processes. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis eans that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems Product-line architectures may be developed. 06 Layered pattern is Used to model the interfacing of sub-systems. Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. However, often artificial to structure systems in this way. Name Description Example Layered architecture Organizes the system into layers with related functionality assoc provides services to the layer above it so the lowest-level layers likely to be used throughout the system. A layered model of a system for sharing copyright documents he When used Used when building new facilities on top of existing systems; wh across several teams with each team responsibility for a layer of requirement for multi-level security. Advantages Allows replacement of entire layers so long as the interface is ma (e.g., authentication) can be provided in each layer to increase th Disadvantages In practice, providing a clean separation between layers is often d may have to interact directly with lower-level layers rather than t below it. Performance can be a problem because of multiple leve request as it is processed at each layer.

8 b Explain Repository pattern with example. Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; Each sub-system maintains its own database and passes data explicitly to other sub-systems. When large amounts of data are to be shared, the repository model of sharing is most commonly used as this is an efficient data sharing mechanism. Ex: University which consists of approvals, administrator, registration, approvals and reports. Library book store, pesse info from all depts... Advantages Efficient way to share large amounts of data Sub-systems need not be concerned with how data is produced. Centralised management e.g. backup, security, etc. Sharing model is published as the repository schema Disadvantages Sub-systems must agree on a repository data model. Inevitably a compromise Data evolution is difficult and expensive in case of large data No scope for specific management policies on subsystems 04

9 Difficult to distribute efficiently Design editor Code generator Design translator Project repository Program editor Design analyser Report generator 5 a Discuss about 4+1Architectural view. A logical view, which shows the key abstractions in the system as objects or object classes. A process view, which shows how, at run-time, the system is composed of interacting processes. A development view, which shows how the software is decomposed for development. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. Related using use cases or scenarios (+1) 02 b Explain Client-server architecture with example. Name Client-server 04 Description In a client server architecture, the functionality of the system is o service delivered from a separate server. Clients are users of thes make use of them.

10 Example example of a film and video/dvd library organized as a client server system. When used Used when data in a shared database has to be accessed from a range of locations. B can be replicated, may also be used when the load on a system is variable. Advantages The principal advantage of this model is that servers can be distributed across a netw functionality (e.g., a printing service) can be available to all clients and does not nee implemented by all services. Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or Performance may be unpredictable because it depends on the network as well as the be management problems if servers are owned by different organizations. c. Explain Pipes and Filter architecture with example. Name Pipe and filter 04 Description Example When used Advantages The processing of the data in a system is organized so that each p discrete and carries out one type of data transformation. The data component to another for processing. example of a pipe and filter system used for processing invoices Commonly used in data processing applications (both batch- and are processed in separate stages to generate related outputs. Easy to understand and supports transformation reuse. Workflow many business processes. Evolution by adding transformations is implemented as either a sequential or concurrent system.

11 Disadvantages The format for data transfer has to be agreed upon between communicating transfor transformation must parse its input and unparse its output to the agreed form. This in system overhead and may mean that it is impossible to reuse functional transformati incompatible data structures. 6 By considering any project scenario draw all the diagrams /system models. (Class, Use case, Sequence, Activity and State models) 10 Borrower ake Reservation Remove or Update Title Add Title <<uses>> Remove Reservation <<uses>> libraria <<uses>> Add Item <<uses>> <<uses>> aintenance Librarian Lend Item Remove Item <<uses>> <<uses>> Return of Item Add Borrower Remove or Update borrower

12 : Librarian :Lending window :Title : Borrower information :Loan :Item 1:find title 2 :find string 3:find item 4 : find on title 5:identify borrower 6:find string 7: create ( borrower information, Item)

13 Not reserved entry: Number of reservations = 0 Title reservation/ Number of reservations ++ Reservation removed [ Numbe of reservations = 1] / Number Reserved Title reservation / Number of reservations ++ Reservation removed Number of reservation 1 ] / Number of reservations --

14 User logs in to the system Specify details of book being returned return book Registered User Unregistered User borrow book Update Book Catalog view catalog Ask for registeration no reservation for book reservation exists for book Select the book yes no Notify ember who reserved the book Register user Get book issued 7 a Explain Coupling and Cohesion in detail Cohesion the degree to which the internals of a module are related Coupling the degree to which the modules of a design are related The ideal system has highly cohesive modules that are loosely coupled high cohesion -> well-designed reusable module low coupling -> coherent design, resistant to change Types of Cohesion coincidental multiple, completely unrelated actions logical series of related actions, often selected by parameters temporal 06

15 series of actions related in time procedural series of actions sharing sequence of steps communicational procedural cohesion but on the same data informational series of independent actions on the same data functional: exactly one action Types of Coupling content one module directly references content of another common both modules have access to same global data control one module passes an element of control to another stamp one module passes a data structure to another; which only uses part of the passed information data one module passes only homogeneous data items Examples of Cohesion Logical cohesion Input/Output libraries ath libraries Temporal cohesion Program initialization Communicational cohesion calculate data and write it to disk Closely related: sequential cohesion the output of one element is the input to another Examples of Coupling Control coupling One module passes control flags (parameters or global variables)

16 that control the sequence of processing steps in another module Stamp coupling (alternative definition) Similar to common coupling (modules that share global data) except that globals are shared selectively among routines that require the data Ada packages support stamp coupling since variables defined in a package specification are shared between all modules which use the package. b Write short notes on etrics. etrics are A quantitative measure of the degree to which a system, component, or process possesses a given attribute. [IEE93] Software measures are Processes are collection of software related activities Products are any artifacts, deliverables or documents that result from a process activity. Types of metrics etrics for Analysis System Size Functionality Delivered Specification Quality etrics for the Design Architectural etrics Component Level Interface Design etrics for the Code Halstead etrics Complexity etrics Length etrics etrics for Testing Defect metrics 04 8 a Explain Function oriented design with Data flow diagram of AT. 05

17 Function - oriented : consists of module definitions, with each module supporting a functional abstraction Function-oriented design views a system as a set of modules with clearly defined behavior that interact with each other in a clearly defined manner to meet the system's requirements A system is considered modular if it consists of discreet components so that each component can be implemented separately, and a change to one component has minimal impact on other components Helps in system repair and in system building Each component needs to support a well-defined abstraction and have a specific interface that other modules use to interact with it As Jalote says odularity is where abstraction and partitioning come together. A bottom-up approach starts with primitive components that provide foundational services and using layers of abstraction builds the functionality the system needs until the entire system has been realized A top-down approach is typically more useful in situations only if the specifications of the system are clearly known and application is being built from scratch (water fall model) odule It is a logically separable part of a program It is a program unit that is discreet and identifiable with respect to compiling and loading Can be a function, a procedure, a process or a package odule level concepts are Coupling and Cohesion.

18 b Discuss about Design documentation. Detailed design Interface design module interfaces are negotiated, designed and documented Example: 05

19 Example: Login 1. Get Username and Password Data structure and algorithm design module details (data structures and algorithms) to provide system services are specified 2. If user name is equal to the entered Username & the password is equal to the entered Password 3. Then login successful 4. Else login failed 5. End If.

Lesson 06. Requirement Engineering Processes

Lesson 06. Requirement Engineering Processes Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To