Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
61 views15 pages

SE Question Paper

Software engineer questions paper
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
61 views15 pages

SE Question Paper

Software engineer questions paper
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 15
N~N Nov-2022 PG Examinations : USN 20MCA21 RV COLLEGE OF ENGINEERING® (An Autonomous Institution affiliated to VTU, Belagavi) II Semester Master of Computer Applications SOFTWARE ENGINEERING Time: 03 Hours Maximum Marks: 100 Instructions to candidates: 1. Each unit consists of two questions of 20 marks each. 2. Answer FIVE full questions selecting one from each unit. UNIT-1 1a What is software? Discuss the essential attributes of good software? | 06 b Explain professional responsibilities of the software engineers. 04 c Identify the major activities involved in the software specification process with neat diagram. 10 8 OR 2a Explain the key challenges of software engineering faced by software . y Bs ‘, engineering in present scenario. 06 b Describe various notations used for writing system requirement. 04 c Identify the characteristics of software requirement specification (SRS) document. 10 UNIT-2 3 a Identify the various components of waterfall software process model and where it is applicable? 10 b Differentiate between plan driven and agile process models with neat diagram. 10 - OR 4 a Discuss scrum life cycle with neat diagram. 10 b Identify different components of pair programming. 10 UNIT-3 5 a ‘Analyze which architectural design best suits to film library. Justify your answer. 10 b Explain MVC pattern. List advantages and disadvantages of the MVC. architecture. 10 OR a | Analyze various architectural views available for software design with 6 ly e neat diagram. 10 b___| Describe use case model with suitable example. 10 x S s | z S| ° z * ols UNIT-4 7 Explain general guidelines for interface testing. 10 | Explain development test cases and derive the same for the weather station object interface. 10 OR 8 What is Test Driven Development (TDD? Analyze the benefits of the TDD. 10 Discuss in detail about performance-based testing. 10 UNIT-5 9 Tdentify the role of ISO 20001 core process to develop for product delivery process. 1@ Compare and contrast software product standards and process standards in terms of quality. 10 OR 10 Identify the quality plan structure for providing software quality assurance for any Banking System. 10 Compare and contrast Review and Inspection process in terms of quality. 10} Woah. ramee ao ED Powe Gee A roqramme MCA Covssctade votth tite 2 frolng, 2 ~ & Ne. lay SCHEME AND SOLUTLON Nov-20 9, oMon Marks. ‘What is Software? Discuss the essen solution attributes of good software? 1586 Computer programs and associated documentation, Software products may be developed for a particular customer or may be developed for a general market, Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable iTb) ‘Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable, and compatible with other systems that they use. Dependability and security Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Software has to be secure so that malicious users cannot access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, resource utilization, etc. Maintainability Software should be written in such a ‘way that it can evolve to meet the changing needs of customers, This is a critical attribute because software change is an inevitable requirement of a changing business environment, Explain professional responsibilities of the software engineers, 4 AKI etorks V.Confidentiality You should normally respect the confidentiality of your employers or clients regardless of whether or not a formal confidentiality agreement has been signed. 2. Competence You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence. 3. Intellectual property rights You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected. 4,Computer misuse You should not use your technical skills to misuse other people's computers. Computer misuse ranges from relatively trivial (game playing on an employer's machine) to extremely serious (dissemination of viruses or other malware). ) Solution Idetify the major activities involved in the software specification process neat diagram GTO There are three main activities in the requirements engineering process: 1. 1 Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. 2. Requirements specification Requirements specification is the activity of translating the information gathered during requirements analysis into_a Poy 2 Tocument that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. 3. Requirements validation This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems. Requirements elicitation and ‘analysis Requirements validation sytem descriptions |, t User and system fequirerents Requirements document Bachviker XQ moe each = 6 asks — daagren 4 rent OR Pa) Tdentify and explain the Key challenges of Software Engineering faced by Software Engineering present scenario. ‘lution Key challenges + Explanation each: 2+4*1 Marks Key challenges : Heterogeneity ,Business and social change Security and trust, Scale pb) Deseribe various notation used for writing system requirement Explanation with simple example — Trek X 4 > 4 moaks- Natural language sentences The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural language The requirements are written in natural Janguage on a standard form or template, Each field provides information about an aspect ofthe requirement, Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system. UML (unified ‘modeling language) use case and sequence diagrams are commonly used, Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sels. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don't understand a formal specification. They cannot check that it of i3 5) Tepresents what they want, and they are reluctant to accept it as @ stem contract. Identify the characteristics of Software Requirement Specification Document 10 Preface This defines the expected readership of the document and describe is version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This describes the need for the system. It should briefly describe the system’s functions and explain how i will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This defines the technical terms used in the document. There should not make assumptions about the experience or expertise of the reader. User requirements definition Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section, This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. ‘System architecture presents a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted. System requirements specification This describes the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System models includes graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This describes the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. ‘Appendices These provide detailed, specific information that is related to the application being developed—for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included, As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. ies) Unit it a) Tienify the various components of Waterfall sofiware process model and where it is applicable? Solution b) 5 servi ts, and sments analysis and definition The system’s services, constraints, i il anc ve as a system specification. 7 ee ee devi pos alos he requirements to either hardware or software systems. It establishes a) a system architecture, Software design involves identifying and describing the fundamental software system abstractions and their relationships. | 3. Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying, that each unit meets its specification. 4, Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. 5. Operation and maintenance Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that were not discovered in earlier stages of the life cycle, improving the implementation of system units, and enhancing the system's services as new requirements are discovered, cay onunlt with Aaplanchon — 7 Parke Applicable at development of — 3 mars. 1. Embedded systems where the software has to interface with hard systems. Because of the inflexibility of hard se to Iware, it is not usually possible to delay decisions on the software's functionality until itis being i 2. Critical systems where there is a need 3. Large software systems that are part of by developed by several partner companies Ti i developed using a similar model, and comperien, Td ca ode aot hardware and software. Furthermore, where severe: oo coTO involved, complete specifications may be needed to allovw fae eames ate development of different subsystems, ow forthe independent ifferentiate between roader engineering systems plan drive ile pre i it n and aaile process models with neat diagram: Miogram 4 x Plan: S45=10 ter for plan clvi ive9 tee ~ F monty | Plan-driven software development processes that completely specify the requirements and then design, build, and test a system are not geared to rapid software development. As the requirements change or as requirements problems are discovered, the system design or implementation has to be reworked and retested. As a consequence, a conventional waterfall or specification-based process is usually a lengthy one, and the final software is delivered to the customer long after it was originally specified. Bingen + Gp leven Apt — 5 mace Agile methods are inctemental developmen methods in which the increments are small, and, typically, new releases of the system are created and made available to customers every two or three weeks. They involve customers in the development process to get rapid feedback on changing requirements. They minimize documentation by using informal communications rather than formal meetings with written documents. Hay 345510 Hib) ‘The starting point for the Scrum sprint cycle is the product backlog—the list of items such as product features, requirements, and engineering improvement that have to be worked on by the Scrum team. The initial version of the product backlog may be derived from a requirements document, a list of user Stories, or other description of the software to be developed. ‘Serum, as originally designed, was intended for use with co-located teams where all team members could get together every day in stand-up meetings. However, much software development now involves distributed teams, with team members located in different places around the world . Tdentify different components of pair programming 32-10 Haves, the sane pi do oot avs progam together. Rate, pi ae crated danish al eam members rk with each oer ing the development process. Pir programming as a number of advantages. 1 It supports the idea of collective ownership and responsibility for the system. This reflects Weinbere's idea of egoless programming where the software is coned by the team as a whole and individuals are not held responsible for problems with the code. Instead, the team has collective responsiblity for resalving these problems. 2 t acts as an informal review process because each line of code is locked at by at least two people, Code inspections and reviews are effective in discovering a high percentage of software errors. However, they are time consuming to organize and, typically, introduce delays into the development process. Pair programming i a less formal process that probably doesn’t find as many errors as code inspections. However, it is cheaper and easier to organize than formal program inspection. 3. It encourages refactoring to improve the software structure. The problem with asking programmers to rfactor in a normal development environment is that effort. 4. An developer who spends time refactoring may be judged tobe less efficient than one who simply caries on developing code. Wher collective ownership are used, others benefit immed so they are likely to support the process, pair programming and iately from the refactoring ve] The programming pair sits at the same computer to develop the software, a) UNITAIL olution Tdentify architectural design for film library Justify your answer Client server architecture is used for film li 73-10 rary. Clients may have to know the zames of the available servers and the services they provide. However, servers do not need to know the identity of clients or how many clients are accessing their services. Clients acess the services provided by a server through remote Procedure calls using a request-reply protocol (such as http), where a elient makes a request toa server and waits until itreceivesa reply from that server, ear a a ait, Web-based system for providing a flm and photograph Uibrary. In this system, several servers manage and display the differen types of m transmitted quickly and in synchrony but at nay be compressed in a store, so the video on and decompression in different formats maintained at a high resolution, separate server. The appropriate to maintain them on a deal with a variety of queries and provide links system that include data about the film and video to the web information 8, and at system that supports the sale of photographs, film, ips. The cet at suy and video clips. The client Program is simply an integrated user interface, constructed using a web browser, to access these services hy Tubificaken af enclitechasl Lavin = Ute expierahin — G marke Juskifresbien ~ 3 mang dmnocks fi2 b) Explain MVC pattem List its advantages and disadvantages of the MVC architecture, 7H3=10 ‘olution fay Explanation of MVC architecture Description Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other, ‘The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (eg, key Presses, mouse clicks, etc.) and passes these interactions to the View and the Model. The architecture of a web-based application system organized using the MVC pattem, When used Used when there are multiple ways to view and interact with data, “Also used when the future requirements for interaction and presentation of data are unknown. Advantages Allows the data to chan vice versa. Supports changes mad ge independently of its representation and Presentation of the same data in different ways, with ‘one representation shown in all of them, Disadvantages May involve additional code and code complexity when the data model and interactions are simple Discuss various architectural views with neat diagram C@> Logical wen Development ical view, which shows the Key abstractions inthe system as objecs op tijet sesut sould be paste to rete the system requrereny to ities inthis logical view, : interacting processes. Ths view is useful for making judgments about non- functional system characteristics such a performance and availabilty. 3. A development view, which shows how the software is decomposed for development; that is, it shows the breakdown of the software into components that are implemented by a single developer or development team. This view is Useful for software managers and programmers. 4. A physical view, which shows the system hardware and how software ‘Components are distributed across the processors in the system. This view is useful for systems engineers planning a system deployment, pb) Describe use case model with suitable example 7+3=10 ‘olution | Explanation ™ Use cases are a way of describing interactions between users and a system Sage S eePhical model and stuctured text. They were first introduced ye ake Objectory method (Jacobsen et al, 1993) and have now become a fundamental é) feature ofthe Unified Modeling Language (UML). Use cases are documented using a ‘cases represents all of the po system requirements. Actors in the process, Pstems, are represented as stick figures. Each close of interaction. is Tepresented as a named ellipse, Lines k the actors with the interaction, Oj ‘rally, arrowheads may be added to lines 10 show how the interaction is, ated. ill be described in the who may be human or other 3M Suitable Example UNITIV (7a) Explain general guidelines for interface texting So10 somlamine the code to be tested and identi eaah-~ ; : q F all to a extemal components are atthe extreme ends of the anges. These ext Yalues are most likely to reveal interface inconsistencies, eal U 2. Where pointers are passed across an interface null pointer parameters, deaiae SESS testing in message passing systems. This me: ans th design tests that generate many more messages thas Tkely scot Practice. This is an effective way of revealing timing problem *>” (© O°eUr in 5. Where several components interact though shared me i compor mor that vary the order in which these components ae asivense Thee ne sevea implicit assumptions made by the programmer bored ef May the shared data is produced and consumed, der in which fz Explain development test cases and Derive the same for weather station object interface “There are three stages of development testing: 1. Unit testing, where individual program units or object classes are tested, Unit testing should focus on testing the functionality of objects or methods. 2. Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing the component interfaces that provide access to the component functions. 3, System testing, where some or all of the components in a system are integrated and the system is tested as a whole, System testing should focus on testing component interactions. Development testing is primarily a defect testing process, where the aim of testing is to discover bugs in the software. It is therefore usually interleaved with debugging—the process of locating problems with the code and changing the program to fix these problems. ia) ‘What Test Driven Development (TDD) and analyze the benefits of the TDD. Test-driven development (TDD) is an approach to program development in which you interleave testing and code development Develop the code incrementally, along with a set of tests for that increment. Don’t start working ‘on the next increment until the code that developed passes all of its tests. Test- driven development was introduced as part of the XP aj method. = 3b Mews development implement functionality and relacot Benefits 1. Code coverage In principle, every code segment that you write should have at least one associated test. Therefore, you can be confident that all of the code Identify new functionality Write test Run test Implement functionality and refactor fail pass. Software testing the system has actually been executed. Code is tested as it is written, so defects are discovered early in the development process. 2. Regression testing A test suite is developed incrementally as a program is developed. You can always run regression tests to check that changes to the program have not introduced new bugs. 3, Simplified debugging When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified. You donot need to use debugging tools to Tosa the problem. Repors of the use of ‘TDD suggest that it is hardly ever necessary to use an automated debugger in test-driven development : 4, System documentation The tests themselves act as a form of documentation that describe what the code should be doing, Reading the tests can make it easier to understand the code. 3b) Discuss in detail about performance based testing 10 Explanation and its uses in stress testing SHS=10 Performance tests have to be designed to ensure that the system can process its intended load. This usually in wolves running a series of tests where you increase the load until the system performance becomes unacceptable. AAs with other types of testi demonstrating that the In performance testing, this means stressin that are outside the design limits of the testing. Say you are testing a transaction Process up to 300 transactions per second. fewer than 300 transactions per second. You then gradually increase the load on the system beyond 300 transactions per second until it is well beyond the ‘maximum design load of the system and the system fails, ig the system by making demands ® software. This is known as stress Processing system that is designed to |. You start by testing this system with Stress testing helps you do two things: 1. Test the failure behavior of the Unexpected combination of events where the load placed on the system ‘exceeds the maximum anticipated load. In these circumstances, system failure should not cause data corruption or unexpected loss of user services, Strees {esting checks that overloading the system causes it to “fail-sof” rather than collapse under its load. system. Circumstances may arise through an 2. Reveal defects that onl ly show up when the system is full it can be argued that th ly loaded. Although ) ese defects are unlikely to cause system failures in normal use, there may be unusual combinations of circumstances thatthe sexe testing replicates. Stes testing is particularly relevant to distributed syclone based on a network of processors. ‘These systems often exhibit severe degradation when they are heavily loaded, ‘The network becomes swamped with coordination data that the different Prosesses must exchange The processes become slower and slower as they wait for the required data from other proce: ses, Stress testing helps you discover when the degradation begins so that you can add ‘checks tothe system to reject transactions beyond this point. Loftz Wn Identify the role of ISO 20001 core process to Develop for product delivery | 10 — process. Explanations of the 9 core process: 6 marks Role of ench core process to] develop Health Care Systme:4 marks mB) Compare and Contrast Software terms of quality, Comparison Product standards and process standards in} 10 marks Contrast ( differences): Smarks Product standards These apply to the software product being developed. They include document standards, such as the structure of requirements documents, documentation standards, such as a standard comment header for an object class definition, and coding standards, which define how a programming language should be used, Process standards These define the processes that should be followed during software development, They should encapsulate good development practice, Process standards may include definitions of specification, design, and validation processes, process support tools, and a description of the documents “ that should be written during these processes ul Product standards Process standards Design review form Design review conduct Requirements document | Submission of new code for structure system building Method header format Version release process Java programming siyle Project plan approval process Project plan approval process | Change control process Project plan format Change request form Test recording process OR 0a) | Wéentify the quality plan sructare Tor roviding Softwar e for any Banking System a | Tdentification “of quality plan struclarer for Bank i 7 ki a janking transactions Relating quality plan structure the context of System and explanations : 5 marks 0b) _[ Compare and contrast Review and Inspection process in terms of quality hto-——_] Comparison + 5 marks Contrast( po as + Inspections for defect removal (product); * Reviews for progress assessment (product and Process); La RD \ Inspections A group of people carefully examine part or all of a software system and its associated documentation. + Code, designs, specifications, test plans, standards, etc, can all be reviewed. Software or documents may be ‘signed off at a review which signifies that Progress to the next development stage has been approved by management, These are peer reviews where engineers examine the source of a system with the aim of covering anomalies and defects, Inspections do not require execution of a system so may be used before implementation, ‘They may be applied to any representation of the system (requirements, design,configuration data, test data, etc,), They have been shown to be an effective technique for discovering program errors.

You might also like