SOFTWARE ENGINEERING Overview of System Analysis & Design Zz System Design 40 Coding & Documentation 74 Software Project Management 106 NOTE: MAKAUT course Structure and syllabus of 5" semester has been changed from 2020. Previously SOFTWARE ENGINEERING was in 7” Semester. This subject has been shifted in 5" semester in present curriculum. Subject organization has been changed slightly. Taking special care of this matter we are providing chapterwise relevant MAKAUT university solutions and some model questions & answers for newy introduced topics along with the complete solutions of new university papers, so that students can get an idea about university questions patterns.POPULAR PUBLICATIONS OVERVIEW OF SYSTEM ANALYSIS & DESIGN 1, Structured systems development cycle approach includes which of the following characteristics? [WBUT 2013] a) dataflow b) top down c) data structure d) none of these Answer: (c) 2. A prototype refers to (WBUT 2013] a) a working model of a proposed system b) the Set of activities of a system ¢) both (a) and (b) d) none ofthese Answer: (c) 3. The most important feature of spiral model is [WBUT 2013) a) requirement analysis b) quality management ¢) risk management d) configuration management Answer: (c) : 4, ACOCOMO model is [WBUT 2013] a) common cost estimation mode! b) complete cost estimation model ¢) constructive cost estimation model . d) none of these Answer: (c) 5, Which model is generally used for developing GUI of asystem? — [WBUT 2014] a) spiral b) prototyping c) iterative waterfall d) evolutionary Answer: (2) 6, According to COCOMO number of cost drivers is (WBUT 2015] a) 10 b) 15 <) 20 4) 14 Answer: (b) 7. Which form of software development model is most suited to a system where all the requirements are known at the start of a project and remain stable throughout the project? (WBUT 2015] a) Waterfall model b) Incremental model c) Evolution model d) Spiral model Answer: (a) 8. Prototype is a [WBUT 2017] a) Working model of existing system _b) Mini model of existing system ¢) Mini model of processed system d) none of these Answer: (a) SWE-2SOFTWARE ENGINEERING 9, ACOCOMO model is [WBUT 2019] a) Common Cost Estimation Modol b) Constructive Cost Estimation Model c) Complete Cost Estimation Model d) Comprehensive Cost Estimation Model Answer: (b) 10. If every requirement stated in the software Requirement Specification (SRS) has only one interpretation, SRS Is said to be correct (WBUT 2019] a) Unambiguous b) Consistent ¢) Verifiable d) None of these Answer: (a) . 11. A typical Configuration Management (CM) operational scenario a 7 who is in charge of a software group. [WBUT 2022) a) Project manager b) System engineer ¢) System administrator d) All of the mentioned above Answer: (a) 12. CASE tool is [WBUT 2022) a) Computer Aided Software Engineering b) Component Aided Software Engineering c) Constructive Aided Software Engineering d) Computer Analysis Software Engineering Answer: (a) 413. The SCM repository is the set of 7 [weurT 2022} a) Project database b) Mechanisms and data structures ¢) A tracking and control 4) None of the mentioned above Answer: (b) ‘ 14, Software configuration management is a set of activities. a) Change management b) Process [WBUT 2022] c) Tracking and control d) None of the mentioned above Answer: (c) Short Answer Type Questions 4, What are the drawbacks of classical waterfall model? How are they rectified in other variants of the classical waterfall model? [WBUT 2013] . OR, What is SDLCM? What are the Disadvantages in Classical Waterfall Model? (WBUT 2017] Auswer: : 1" Part: A software development life cycle (SDLC) model is a conceptual framework describing all activities in a software development project from planning to maintenance, This Process is associated with several models, each including a variety of tasks and activities. SWE-3JPULAR PUBL! 2" Part: The classical model is the most widely used software development model. The name is suggested due to likeness of the model with the cascade of waterfalls. As each stage is signed off the next stage is proceeded with. End users are not involved in the development stage. It is the responsibility of the analysis,and the programmers to understand the end-users requirements. This is a risky process with the waterfall model. The six different phases starting from the feasibility study are known as the development phases. At the end of the development the:product will be delivered to the customer. In the iterative model, revision of work on the earlier stages of the system can be made, It improves the performance of the system by gaining exposure at later stages of the system development. There can be various defects in the development process like; wrong understanding, incorrect design, quick and fix of bugs, hard coding etc. Once a defect is detected, the designer needs to move backward to detect the problem and redo the work in all the stages in sequence in the process. 2. What is feasibility study? Explain different types of feasibility study? [WBUT 2013) Answer: 1" Part: A feasibility study looks at the viability of an idea with an emphasis on identifying potential problems and attempts to answer one main question: Will the idea work and should we proceed with it? Before we begin writing our business plan we need to identify how, where, and to whom we intend to sell a service or product. We also need to assess our competition and figure out how much money you need to start our business and keep it running until it is established. Feasibility studies address things like where and how the business will operate. They provide in-depth details about the business to determine if and how it can succeed, and serve as a valuable tool for developing a winning business plan. The information we gather and present in our feasibility study will help us: © List in detail all the things we need to make the business work; * Identify logistical and other business-related problems and solutions; * Develop marketing strategies to convince a bank or investor that our business is worth considering as an investment; and " * Serve as.a solid foundation for developing our business plan. 2" Parts Technical Feasibility : + Study of available technology to implement the system and the suggested alternatives. Economic Feasibility * It is the financial study related to the technical feasibility. The cost-effectiveness of the system — do the benefits outweigh the costs? Calculate the ROI (Retum on SWE-4BE Rn investment) on present value method and also on discounted money value method to arrive at the money value, Socia/Operational Feasibility © Legal Feasibility — Study of legal requirements related to technical feasibility, If there is any conflict about the system and legal procedures eg. Data disclosure and privacy Act. © Operational Feasibility - It is also known as the study of the social feasibility. It studies the impacts on the social factors on implementation of the system and how the work practices and procedures will be able to support thenew system. © Schedule feasibility — It is the time study about the proposed system. How long it will take to develop and monitoring of the proposed time frame, 3. Consider the size of an organic type s/w product that has beon estimated as 32,000 lines of source code. The average salary of s/w developers is 15,000 p.m. Determine the effort required to develop the siw, the nominal development time and the cost to develop the s/w, the nominal development time and the cost to develop the product. [WBUT 2013] Answer: Effort = 2.4(KLOC)' PM =2.4 x (32)! PM 4 x 38.05462 = 91.331 PM Tdev = 2.5(Effort)°** months = 2.5x (91.331) : 5X 5.559 = 13,898 months Cost required to develop the product = 13.898 x 15,000 /- = Rs. 2,08,481/- 4, a) What is phase containment of errors? [WBUT 2013] b) Describe structured analysis and structured design. Answer: a) Detection and correction the error within the segment or phase where it actually lies. E.g, the design error should be spotted’ and rectified within the design phase rather than fixing it in the coding phase, This is the objective behind development of the iterative waterfall model and which saves time and money during the system development. A periodic review is necessary for detecting phase containment of errors, b) Structured Analysis and Design Technique (SADT) is a diagrammatic notation designed specifically to help people describe and understand systems. It offers building blocks to represent entities and activities, and a variety of arrows to relate boxes. These boxes and arrows have an associated informal semantics. SADT can be used as a functional analysis tool of a given process, using successive levels of details. The SADT method not only allows one to. define user needs for IT developments, which is often used in the industrial Information Systems, but also to explain and present an activity’s manufacturing processes and procedures. . ai The SADT supplies a specific functional view of any enterprise by describing the functions and their relationships in a company. ‘These functions fulfill the objectives of a SWE-SPOPULAR PUBLICATIONS company, such as sales, order planning, product design, part manufacturing, and human resource management. The SADT can depict simple functional relationships here and can reflect data and control flow relationships between different functions. 5. a) What are ‘baselines’ with respect to software configuration management? b) What is the necessity of software configuration management in developing a software? (WBUT 2014) Answer: a) Base line is a one or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development. Whereas configuration is a collection of all the clements of a baseline and a deseription of how they fit together. The basic purpose of Baseline provides, 1) Measurable progress points within the SDLC 2) A basis for change control in subsequent project phasés 3) Aconstant reference for future work 4) Intermediate and final points for assessing the health for purpose of project work products. b) According to Barry Bochm “Producing software from a specification is like walking ‘on water - it's easier if it's frozen. Baseline is a reference point in the SDLC marked by the completion and formal approval of a set of predefined work products, The goal. of a baseline is to decrease a project's weakness towards wild changes by fixing and formally change controlling various key deliverables (configuration items) at critical points in the SDLC. Baselines are also used to identify the aggregate of software and hardware components that make up a specific release of a system. 6. A project was estimated to be 200 KLOC. Calculate the effort development time, average staff size and productivity level for i) Organic ii) Semi-detached modes, [WBUT 2014] Answer: i) Effort= 2.4(KLOC)'*= 2.4(200)'* =625,5942 Tdev=2.5(Effort)?** = 2.5(625.5942)"*=28,88 months Average Staff Size = Effort/Time Schedule= 21.66 Productivity level = [K LOC/EFFORT] DSI/MM=200/625,5942 = 0.3197 DSI/MM ii) Effort = 3,0(KLOC)""? = 3.0(200)""? =1133,1172 .5(Effort)’** =2.5(1133.1172)°=29.30 months Average Staff Size = Effor/TimeSchedule= 38.67 Productivity level = [KLOC/EFFORT] DSI/MM=200/1133,1172 - = 0.1765 DSVMM SWE-6SOFTWARE ENGINEERING 7. The lines of source cod Ize of an organic type software product has been estimated to be 1,00,000 hi lary of eoftware developers is Re. 10,000/- per month. Determi I lop software product, the nominal development time and the cost to develop the product. [WBUT 2015) Answer: Using the cost drivers for organic model of the Cocomo. Effort (E) = 2.4(100)'® = 2.4 x (125.8925) PM = 302.1420 PM Tdev (D) = 2.5(302.1420)* = 2.5(8,7595)M = 21.8927 = 22 months (Approx.) Cost of developer is= 22x (10000) =Rs. 2,20,000/- . 8. a) Explain the phases of Spiral Model with advantages and disadvantages. [WBUT 2015] OR, Explain Spiral Model for software development with a diagram, [WBUT 2017] Explain the software life-cycle model that incorporates risk factor. [WBUT 2022]. b) Explain the advantages and disadvantages of prototype model. [WUT 2015] OR, Explain the disadvantages of prototype model. IWBUT 2019) Answer: ‘ a) There are several advantages and disadvantages of spiral model, which should be considered before finalizing on spiral model implementation. The overview of steps in developing a spiral life cycle model can be given as below. ¢ Step 1: The requisites of the new system are described in depth, by cohsuliing all the users of the existing model and an introductory system design is prepared for new model or system. © Step 2: First archetype is built up with features close to the final system, followed by creating second type. * “Step 3: Creating second prototype involves evaluating the performance of the _ first and describing the requisites of the second prototype, followed by building and testing the second architecture. * Step 4: The discrepancies in the estimated running cost are evaluated and the efficiency of the new prototype is tested to find out if the new model meets the expectations of the customer. * Step 5: The steps in creating new prototype are repeated till the new prototype fulfills all the demands or requisites desired by the customer. ©. Step 6: Maintenance of the new model is done to avoid break down, till it is assured that the new system is working smoothly. Just like any other system or model, a client should evaluate spiral model advantages and disadvantages. Let's go through these quickly. SWE-7PO PUB! Spiral Model Advantages Repeated or continuous development helps in risk management. The developers or programmers describe the characteristics with high priority first and then develop a prototype based on these. This prototype is tested and desired changes are made in the new system. This continual and steady approach minimizes the risks or failure associated with the change in the system. Adaptability in the design of spiral model in software engineering accommodates any number of changes, that may happen, during any phase of the project. Since the prototype building is done in small fragments or bits, cost estimation becomes easy and the customer can gain control on administration of the new system. 7 As the model continues towards final phase, the customer's expertise on new system grows, enabling smooth development of the product meeting client's needs. Spiral Model Disadvantages ~ The following can be summarized as the disadvantages of the spiral model. Spiral models work best for large projects only, where the costs involved are much higher and system pre requisites involves higher level of complexity. Spiral model needs extensive skill in evaluating uncertainties or risks associated with the project and their abatement. Spiral models work on a protocol, which needs to be followed strictly for its smooth operation. Sometimes it becomes difficult to follow this protocol. . Evaluating the risks involved in the project can shoot up the cost and it may be higher than the cost for building the system. There is a requirement for further explanation of the steps involved in the project such as breakthrough, blueprint, checkpoints and standard procedure. Spiral model serves as the best option for businesses with volatile business goals but where there is a need for a prototype to handle the complexities in the business procedures. This was about spiral model advantages and disadvantages and spiral model development steps. I hope this article has helped you with spiral model pros and cons. b) Advantages of Prototype model: The system prototypes have the following benefits: Misunderstandings are detected at early stages User will notice incomplete or inconsistent requirements, . Toy model can be built quickly to demonstrate systems Fits top-down building and testing strategies It can be used for training before the system is finished The Prototype may be used as a basis for writing the specification for a production-quality system. Seen The benefits of using prototyping in the software Process are: 1. Improved system usability; ; 2. Improved design quality 3. Improved maintainability SWE-84, Reduced development effort Disadvantages of Prototype model: Some of the disadvantages of the prototyping model are: 1, User may get bored and frustrated due to repetition of the process 2. Sometimes system becomes quite unreliable, if not throwaway type. 3. The size of the prototype is limited 4, Alayered style of waterfall model is viewed as weaknesses in one direction only 5. It is expensive and repetition of work is involved. 9. Discuss the characteristics of a good SRS document. [WBUT 2016] Describe the various steps of requirements engineering. Is it essential to follow these steps? [WBUT 2016] Answer: A good SRS should contain: i) Interfaces ii) Functional Capabilities iii) Performance Levels ‘ Data Structures/Elements Safety Reliability Security/Privacy Quality Constraints and Limitations 10, List three common types of risks that a typical software project might suffer from. [WBUT 2016] Answer: Refer to Question No. 3(b),of Long Answer Type Questions. 411, Explain Empirical Cost Estimation Techniques. [WBUT 2017] Answer: 7 Empirical estimation technique is based on the data taken from the previous project and some based on guesses and assumptions. There are many empirical estimation techniques but most popular are a) Expert Judgement Techaique b) Delphi Cost Technique Expert judgement technique: “ An expert makes an educated guess of the problem size after analyzing the problem thoroughly. Expert estimate the cost of different components that is modules and sub modules of the system. SWE-9POPULAR PUBLICATIONS. Disadvantages: Human error, considering not all factors and aspects of the project, individual bias, more chances of failure. Estimation by group of experts minimizes factors such as individual oversight, lack. of familiarity with a particular aspect of a project, personal bias and desired to win a contract through overly optimistic estimates. Delphi cost estimation: Experts Group Estimation + Coordinators Role of Members: Coordinator provide a copy of Software Requirement Specification (SRS) document and a form of recording it cost estimate to each estimator. Estimator: It completes their individual estimate anomalously and submit to the coordinator with mentioning, if any, unusual characteristics of product which has influenced his estimation. The coordinator and distribute the summary of the response to all estimator and they re- estimate them. SRS, Estimator | Estimate a — i Coordinator Oma>ama- Estimatorn |——— Estimate ‘This process is ITERATED for several rounds This process is iterated for several rounds. No discussion is allowed among the estimator during the entire estimation process because there may be many estimators get easily influenced by rationale of an estimator who may be more experienced or senior. After the completion of several iterations of estimation, the coordinator takes the responsibility of compiling the result and preparing the final estimates. 12. Develop @ work breakdown structure specification for showing the process of admission to an engineering college. Assume major phase as exam preparation, entrance exam, admission criterion and counseling and fees payment. Also write the output of each major task performed. [WBUT 2018] Answer: The efficiency of a work breakdown structure can determine the success of a project. The WBS provides the foundation for all project management work, including, planning, cost and effort estimation, resource allocation, and scheduling. Therefore, one should take creating WBS as acritical step in the process of project management. SWE-10Outputs: Admission criterion Counseling, | Fees payment Work Breakdown Structure of Admission to an Engineering College ‘Admission Process 10 43. ‘A good software should have high cohesion but low coupling’ = Explain. [WBUT.2018] OR, Discuss why “low coupling.and high cohesion” are features of good design. [WBUT 2022] Answer: One of the most important goals of object. oriented design is to have high cohesion classes and loose coupling between these classes. Coupling refers to links between separate units of a program. In object oriented programming, if two classes depend closely on many details of each other, we say they are tightly coupled, Coupling is a measure of the interdependence between classes. If every object has a reference to every other objgct, then there is tight coupling, and this is undesirable. Because there's potentially too much information flow between objects. Loose coupling is desirable. It means that objects work more independently of each other. Loose coupling minimizes the "ripple effect" where changes in one class cause necessity for changes in other classes. Cohesion, on the other hand, refers to the number and diversity of tasks that a class is designed for. If a class is responsible for a few related logical tasks, we say it has high cohesion, = Cohesion is a measure of strength of the association of variables and methods within a class, High cohesion is desirable because it means the class does one job well. Low cohesion is bad because it indicates that there are elements in the class which have little to-do with each other, Modules. whose elements are strongly and genuinely related to SWE-11. 2. Resour ULAR, each other are desired. Each method should also be highly cohesive, Most methods have only one function to perform. Don't add extra instructions into methods that cause it to perform more than one function. Low coupling makes it possible to: * Understand one class without reading others + Change one class without affécting others © Thus: improves maintainability High cohesion makes it easier to: © Understand what a class or method does © Use descriptive names * Reuse classes or methods 44, What are the major components of SRS? [WBUT 2012] Answer: The basic issues an SRS must address are: + Functionality. * Performance. + Design constraints imposed on-an implementation. + External interfaces. Design Control Process 1. Which outputs should be produced from the given inputs? 2. Relationship between the input and output. 3. A detailed description of all the data inputs and their source, the units of measure. 4. The range of valid inputs. Design Constraints 1. Standards that must be followed. limits & operating environment. 3. Reliability 4, Security requirement 5. Policies that may have an impact on the design of the system. Standards Compliance: This specifies the requirements for the standards that the system must follow. Hardware Limitations: The software may have to operate on some existing or predetermined hardware thus imposing restrictions on the design, SWE-12SOFTWARE ENGINEERING Reliability and Fault Tolerance: Fault tolerance requirements can place a major constraint on how the system is to be designed. Fault tolerance requirements often make the system more complex and ‘expensive. Security: Security requirements are particularly significant in defense systems and many database systems. Security requirements place restrictions on the use of certain commands, control access to data, provide different kinds of access requirements for different people require the use of passwords and cryptography techniques and maintain a log of activities in the system. External Interface Requirements: * All the possible interactions of the software with people, hardware and other software should be clearly specified. For the user interface, the characteristics of each user interface of the software product should be specified. User interface is becoming increasingly important and must be given proper attention. A preliminary user manual should be created with all use commands, screen formats and explanation of how the ‘system will appear to the user, and feedback and error message, « Like other specifications these requirements should be precise and verifiable. So a statement likes “the system should be no longer than six characters” or command names should reflect the function they perform used. If the software is to execute on ig hardware or on predetermined hardware, all the characte hardware, including memory resirictions, should be specified. In addition, the current use and load characteristics of the hardware should be given. 15. Draw a diagram for spiral life cycle. [WBUT 2019] Answer: 1. Objectives determinatio, 4, Review and plan for the next Phase SWE-13POPULAR PUBLICATIONS Spiral model is one of the most important Software Development Life Cycle models, which provides support for Risk Handling. In its diagrammatic representation, it looks like a spiral with many loops. The exact number of loops of the spiral is unknown and can vary from project to project. Each loop of the spiral is called a Phase of the software development process. The exact number of phases needed to develop the product can be varied by the project manager-depending upon the project risks, As the project manager dynamically determines the number of phases, so the project manager has an important role to develop a product using spiral model. The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the angular dimension represents the progress made so far in the current phase. Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions of these four quadrants are discussed below- 1. Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant. 2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution is identified and the risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is built for the best possible solution. 3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software.is available. 4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started. 16. Discuss the basic COCOMO model for software cost estimation. [WBUT 2022] Answer: Refer to Question No, 2(a) of Long Answer Type Questions. 47. Write short note of Software Project plan. [WBUT 2022] Answer: Refer to Question No. 11(a) of Long Answer Type Questions. 48. Write the short note Re-engineering legacy systems. [WBUT 2022} Answer: A legacy is something valuable that you have inherited. Similarly, legacy software is valuable software that you have inherited. The fact you have inherited it may mean that it is somewhat old-fashioned. It may have been developed using an outdated programming language, or an obsolete development method. Most likely it has changed hands several times, and shows signs of many modifications and adaptations, SWE-14‘SOFTWARE ENGINEERING Perhaps your legacy software is not even that old. With rapid development tools and rapid turnover. in personnel, software systems can tum into legacies more quickly than you might imagine, The fact that the software is valuable, however, means that you do not just want to throw it away. A piece of legacy software is critical to your business, and that is precisely the source of all the problems: in order for you to be successful at your business, you must constantly be prepared to adapt to a changing business environment. The software that you use to keep your business running must therefore also be adaptable. Fortunately a lot of software can be upgraded, or simply thrown away and replaced when it no longer serves its purpose. But a legacy system can neither be replaced nor up- graded-except at a high cost. The goal of reengineering is to reduce the complexity of a legacy system sufficiently that it can continue to be used and adapted at an acceptable cost. The specific reasons that you might want to reengineer a software system can vary significantly. For example: + You might want to unbundie a monolithic system so that the individual parts can be more easily marketed separately or combined in different ways. + You might want to improve performance. (Experience shows that the right sequence is “first do it, then do it right, then do it fast”, so you might want to reengineer to clean up the code before thinking about performance.) * You might want to port the’system to a new platform. Before you do that, you may need to rework the architecture to clearly separate the platform-dependent code. * You might want to extract the design as a first step to a new implementation. * You might want to exploit new technology, such as emerging standards or libraries, as a step towards cutting maintenance costs. * You might want toreduwce human dependencies by documenting knowledge about the system and making it easier to maintain. Though there may be many different reasons for reengineering a system, as we shall see, however, the actual technical problems with legacy software are often very similar. It is this fact that allows us to use some very general techniques to do at least part of the job of reengineering, - Long Answer juestions 1. a) Give the guideline formulated in IEEE 830 for writing SRS document. b) Assuming standard activities in a Library, write SRS according to IEEE 830. [WBUT 2013] Answer: a) How to write the SRS documentation, following IEEE Std. 830 1. General 1.1 All documents should have a title page (to include information such as: title of the Project, course name and number, team members, place, date, and other relevant information). 1.2 Table of Contents normally makes a lot of sense, so should be included as well SWE-15POPULAR PUBLICATIONS 1,3 Number all sections in the document. 1.4 Any reference correctly included in Section 1.4 should be written as follows: For books, reports, theses, standards, manuals, etc.: [number] NameOfAuthor(s), TtitleOfWork, Publisher, Place, Date (if authors’ or editors’ names are not available, it can start with a title of the name of the Publisher) For papers/articles: [number] NameOfAuthor(s), TtitleOfWork, JournalName, VolumeNumber, IssueNumber, PageNumbers (pp. first-last), Year (or Month and Year) For papers in Conference Proceedings: [number] NameOfAuthor(s), TtitleOfWork, Phrase “Proceedings of the” Conference Name, Place, Date(, Publisher, Place Date] For websites: . [number] AuthorNames(s), TitleOfWork, Company’s Name, Place, Date, URL Note. For names of authors never use full first names, only initials! 1.5 All references: from Section 1,4 have to be referred to in the text (using [number] notation) ' 1.6 Do not-end section titles with colons. 1.7 Every figure/diagram should have a caption (number and titile). Place it underneath the figure/diagram. 1.8 Every table should have a number and title, placed above the table. 1.9 “Shall/Must” phraseology should not be used in unless it is requirement. This means that normally it is not used in sections 1 or 2. 2. Writing “Introduction” - In Section 1.1 “Purpose”, describe the purpose of this doctiment, not the purpose of the software being developed. z - In Section 1.2 “Scope”, describe the scope of this document, not the scope of the software being developed. - In Section 1.5 “Overview”, provide an overview of this document, not the overview of the software being developed. . - Definitions, in Section 1.4, should be write using the following template: word_defined. Followed by a definition. For example: user, The person, or persons, who operate or interact directly with the product. 3. Writing “Overall Description” - _aContext Diagram is mandatory. - other important characteristics are: Product Perspective, product Functions, User . Characteristics, Constraints, Assumptions and Dependencies. 4, Writing “Specific Requirements” - Never specify the Operating System or Language in the SRS, unless the customer demands deing so. These are strictly implementation issues, and well designed SWE-16SOFTWARE ENGINEERING software can be implemented in any specific programming language to run under any specific operating system on any specific hardware platform. ific Requirements Section should be split into: * “External Interfaces” derived from the Context Diagram * “Functional Requirements” that should be further split into “Input Requirements” (related to user inputs, commands, etc.), “Output Requirements” (mostly related to the GUD, “Input/Output Requirements” (if they cannot be separated), and “Processing Requirements” * “Non-Functional Requirements”, such as performance, reliability, safety, security, etc. * “Design Constraints”, normally related to software and hardware limitations (OS, platform, stand-alone or networked, network protocols, standards, etc.); * “Database Requirements” — can be combined with “Design Constraints”. - Use Case Diagrams have to be included. in most seétions, specifically in the “Functional Requirements” section. Several Use Case Diagrams have to be presented, including specific scenarios, how the system will respond to certain user/operator requests or commands, or network behaviour. 5. Other ‘ - End your SRS document by the following line (centered across the page): b) SRS of LIBRARY MANAGEMENT SYSTEM TABLE OF CONTENTS . 1. Introduction (1.1 Purpose, 1.2 Scope, 1.3 Projected Audience, acronyms and abbreviations) 2. Overall Description (2.1 Product Perspective, 2.2 Product Functions, 2.3 Operating adh od al Environment, 2.4 User Characteristics, 2.5 Design and Implementation Constraints, 2.6 Assumptions and Dependencies) Extemal Interfaces Requirements (3.1 User Interfaces, 3.2 Hardware Interfaces, 3.3 Software Interfaces) Functional Requirements Behavioural Requirements Non-Functional Requirements Library Management System 1. Introduction . 1.1 Purpose: The purpose of this document is to describe the LMS System. It consists of L, the functional, behavioural and non-functional requirements of the project with system engineers and designers guidelines. .2 Scope LMS is principally transforming the manual system into a web enabled application so that the users know the details about availability books, time for borrowing, and account details. It will work as a complete user interface for library management process and library usage SWE-17POPULAR PUBLICATIONS 1.3 Projected Audience, acronyms and abbreviations: . The intended users of this document are the developers, testers, library owners, managers, and coordinators. 1.3.1 Acronyms and Abbreviations | Meaning Acronym MS SQL. Microsoft Structured Query Language __| ASE. Active Server Pages _ ISBN International Standard Book Number TEEE ~ LInstitute of Electrical and Electronics Engineers 2. Overall Description 21 Product Perspective: LMS is a replacement for the ordinary LMS based on paper work for recording books. 2.2 Product Functions Neecesee .2.1 Normal Users (Library Members) Admin should be able to insert, modify and delete books. Can accept or reject a new user according to the library policy or payment methods. Increase the period for borrowing a book for specific type or group of users. Can get the information (status report) of any member who has borrowed a book. Add and edit book categories and arrange books by categories. Add and edit authors and publishers information. Can send lateness warnings to people who have exceeded deadline date. Can record books returned by users. * The member should be provided with the updated information about the books catalog. © Members are given an access to check their account’s information and change it. * Members haye the ability to search through books by subject, title, authors or any information related to the book. * Canextend the period of borrowing books according to the library policy. + The customer may suggest a book to be brought to the library book collection. 2.3 Operating Environment The LMS will operate on web site over browsers like Microsoft Internet Explorer, Google Chrome, Mozilla Firefox with Flash Player and JavaScript. 2.4 User Characteristics Users of this LMS are members, librarians and the administrators who maintain the ‘website. Members and librarians are assumed to have basic knowledge of computers and Intemet browsing. Administrators of the system should have more knowledge of internal,modules of the system and are able to rectify small problems that may arise due to disk crashes, power failures and other catastrophes, 2.5 Design and Implementation Constraints SWE-18‘SOFTWARE ENGINEERING ‘The information of all users, books and libraries must be stored in a database that is accessible by the website. « MSSQL Server will be used as SQL engine and database. «The Online Library System is running 24 hours a day. «Users may access from any computer that has Internet browsing capabilities and an Internet connection. «Users must have their correct usernames and passwords to enter into their online accounts and do actions. é 2.6 Assumptions and Dependencies - «The product needs the following third party products. « Microsoft SQL server to store the database. + ASP.net develops the Product. 3, External Interfaces Requirements 3.1 User Interfaces and Login Interface In case the user is not registered yet, he can enter the details and register. Which asks the user to type his username and password .If the user entered cither his username or password incorrectly then an error message occurs, Search: The member or librarian can enter the type of book he is looking for and the title he is interested in them, and then can be searched for the required book by entering the book name. Categories view: Categories view shows the books categories view with ability to Liberian to add/edit or delete category from the list. Librarian’s Control Panel This control panel will allow librarians to add, confirm, or remove users; add, edit, or remove a medium. And manage lending options. 3.2 Hardware Interfaces . Only the recommended configuration (basic requirements of a computer system) no other specific hardware is required to run the software. 3.3 Software Interfaces ¥ Browser to load. and view the web pages ¥ Operating System 4. Functional Requirements 4.1.1 Librarian Insert book: This action is done to add new book to library book collection Delete / modify book: This event is to delete an existing book or modify its information. Delete member: Admin can delete a member due to some specific rules. Return book: Admin should confirm the return of books borrowed by users 4.1.2 Normal User Register: SWE-19POPULAR PUBLICATIONS When new user enters for the first time then he has to register Extending borrowing deadline: Member can extend the borrowing time to some limit decided by Admin 4.1.3 Common Functions Login: Both Admin and members must be logged in before they modify any information Search for book: When user or admin wants to search on some book by name, author or subject etc. 5. Behavioural Requirements USE CASE Diagram . R Search took ‘Student —— zg ‘Database Lend book Librarian Orders if not modifies details of, Update data base 6. Non-functional Requirements Error handling * Library Management System shall handle expected and non-expected errors in ways that prevent loss in information and long downtime period. Performance Requirements + The system shall accommodate high number of books and users: without any fault. Safety Requirements * System use shall not cause any harm to human users Security Requirements * System will use secured database SWE-20SOFTWARE ENGINEERING + Normal users can just read information but they cannot edit or modify anything except their personal and some other information. « System will have different types of users and every user has access constraints 2.Do “ comparative study among the following CoCoMo models: [WBUT 2013] a) Basic a Intermediate ¢) Complete d) COCOMO2. Answer: a) Constructive Cost Model (COCOMO) use cost drivers for estimation proposed by Barry Bohem, which is categorized as algorithmic methods. There are three forms of the constructive cost model: 1, Basic COCOMO which gives an initial rough estimate of man months and development time. 2. Intermediate COCOMO which gives a more detailed estimate for small to medium size projects. 3. Complete COCOMO which gives a more detailed estimate for large projects. * BASIC COCOMO Y Itisused for relatively small project. Y Only a few cost drivers are associated. Y Cost drivers depend upon project size mainly. Y Useful when the team size is small, ie. small staff. The effort (E) and schedule (S) of the project are calculated as follows > Effort E=a *(KDSI) b * EAF Where KDSI is number of thousands of delivered source instructions a and b are constants, may vary depending on size of the project. > Schedule $= * (E)d where E is the Effort and , d are constants. % EAF is called Effort Adjustment Factor which is 1 for basic cocomo, this value may vary from I to 15: The basic cocomo gives the magnitude of cost of the project. It varies depending upon size of the project. The various classes of software projects are . Onganie mode projects : Y Used for relatively smaller teams, ¥ Project is developed in familiar environment. ~ There is a proper interaction among the team members and they coordinate their work. ¥ ~Bohem observed E=2.4(KDSI)1,05 E in person-months. ~ And S=2.5(E)0.38. * Semi-detached mode projects : ‘ Y It lies between organic mode and embedded mode in terms of team size. Y It consists of experienced and inexperienced staff. SWE-21POPULAR PUBLICATIONS ¥ Team members are unfamiliar with the system under development. % Bohemi observed E=3(KDSI)1.12 E in person-months. Y And S=2.5(E)0.35. . renga mode projects: The project environment is complex. Team members are highly skilled. Team members are familiar with the system under development. Bohem observed E=3.6(KDSI) 1.20 E in person-months, And S=2.5(E)0.32. QA b) INTERMEDIATE COCOMO It is used for medium sized projects. The cost drivers are intermediate to basic and advanced cocomo. Cost drivers depend upon product ieliability, database size, execution and storage. v Team size is medium. . SAN ¢) COMPLETE COCOMO Y Itis used for large sized projects v The cost drivers depend upon anquiements, analysis, design, -testing and maintenance. ¥ Team size is large. @d cocomo Ul COCOMOII was developed in 1995 * It could overcome the limitations of calculating the costs for non-sequential, rapid development, reengineering and reuse models of software. + It has 3 modules Y Application composition: good for projects with GUI interface for rapid development of project. v Early design: Prepare a rough picture of what is to be designed. Done before | the architecture is designed. Y Post architecture: Prepared after the architecture has been designed. COCOMO II calculation ¥ InCOCOMO II the constant value b is replaced by 5 scale factors. ¥ Effort (E) is calculated as follows: ’ E=a*(KDSI) sf* x(EM) Y Where a is constant, sfis scaling factor, EM is Effort Multiplier (7 for Early design, 17 for Post architecture), 3. a) What is SRS? Write the features of SRS. [WBUT 2014] OR, What do you mean by the term ‘requirement’? Explain the process of determining the requirements for a software based system. {WBUT 2016] SWE-22SOFTWARE ENGINEERING b) What is Risk? Why Risk Analysis is done? (weur 2014) Answer: a) Software Requirement Specification (SRS) document usually contains a software yendor’s understanding of a customer’s software requirements. This document ensures that the software vendor and the customer are in agreement as to the features required in the software system being built. SRS is created after the initial requirement elicitation phase in which Software vendor interacts with the customer to understand the software needs. Usually SRS documentation is prepared by a business analyst who has some technical background, Software SRS establishes the basic for agreement between the client.and the supplier on what the software product will do. 1. ASRS provides a reference for validation of the final product. 2. Ahigh-quality SRS is a prerequisite to high-quality software. 3, Ahigh-quality SRS reduces the development cost, Characteristics of an SRS 1, Correct Complete Unambiguous Verifiable Consistent Ranked for importance and/or stability Modifiable Traceable Ssayvrayy b) High degree of precession and cost is involved in a software project so as the risk. Thus risk dictates assessment and analysis. Two activities are involved in the risk analysis. 1. Uncertainty 2. Loss However, small and medium size software projects are being managed informally and on an Ad hoe basis. The time spent in identifying, analyzing, and managing risk pays itself back in many ways. Diagrammatically:the risk management process may be presented as follows: ke identification Risk avoidance and contingency plans Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. SWE-23 a #POPULAR PUBLICATIONS ¢ Arisk is a probability that some adverse circumstance will occur; © Project risks affect schedule or resources; © Product risks affect the quality or performance of the software being developed; © Business risks affect the organisation developing or procuring the software. The risk management process includes: Risk identification Identify project, product and business risks: Risk analysis Assess the likelihood and consequences of these risks : Risk planning Draw up plans to avoid or minimise the effects of the risk: Risk monitoring Monitor the risks throughout the project. 4. a) What is software engineering? b) Discuss the software engineering process. c) Explain waterfall model in detail with the help of diagram. State its advantage and also its limitations. [WBUT 2016] Answer: a) Software engineering is a field of engineering, for designing and writing programs for computers. or other electronic devices. A software engineer, or programmer, writes sofiware (or changes existing software) and compiles software using methods that improve it. Better quality software is easier to use: According to IEEE's definition it is an application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. b) A software engineering process is the model chosen for managing the creation of sofiware from initial customer inception to the release of the finished product. The chosen process usually involyes techniques such as Analysis, Design, Coding, Testing and Maintenance yaeNe SWE-24SOFTWARE ENGINEERING Several different process models exist and vary mainly in the frequency, application’ and implementation of the above techniques, for example, different process models use different analysis techniques, other models attempt to implement the solution to a problem in one big-bang approach, while others adopt an iterative approach whereby successively larger and more complete versions of the software are built with each iteration of the process model. E.g. the various phases of what is probably the oldest software development process in existence, namely the classic life-cycle. paradigm, sometimes called the "waterfall model". This paradigm implies a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing and maintenance. Modeled after the conventional engineering cycle, the life-cycle paradigm encompasses the above activities. ©) 1" Part: The Waterfall Model The waterfall model is believed to have been the first process model which was introduced and widely followed in software engineering The phases of "The Waterfall Model" are: Requirement Analysis & Definition: All requirements of the system which has to be developed are collected in this step. Like in other process models requirements are split up in functional requirements and constraints which the system has to fulfill. Requirements have to be collected by analyzing the needs of the end user(s) and checking them for validity and the possibility to implement them. The aim is to generate a Requirements Specification Document which is used-as an input for the next phase of the model. System Design: The system has to be properly designed before any implementation is started. This involves an architectural design which defines and describes the main blocks and components of the system, their interfaces and interactions. By this the needed hardware is defined and the software is split up in its components. E.g. this involves the definition or selection of a computer platform, an operating system, other peripheral hardware, etc. The. software components have to be defined to meet the end user requirements and to. meet the need of possible scalability of the system. The aim of this phase is to generate a System Architecture Document this serves as an input for the software design phase of the development, but also as an input for hardware design or selection activities, Usually in this phase various documents are generated, one for each discipline, so that the software usually will receive a software architecture document. Software Design: Based on the system architecture which defines the main software blocks the software design will break them further down into code modules. The interfaces and interactions of the modules are described, as well as their functional contents, All necessary system states like startup, shutdown, error conditions and diagnostic modes have to be considered and the activity and behaviour of the software has to be defined. The output of this phase is a Software Design Document which is the base of the following implementation work. SWE-25POPULAR PUBLICATIONS Coding: Based on the software design document the work is aiming to set up the defined modules or units and actual coding is started. The system is first developed in smaller portions called units. They are able to stand alone from an functional aspect and are integrated later on to form the complete software package. _ Software Integration & Verification: Each unit is developed independently and can be tested for. its functionality. This is the so called Unit Testing. It simply verifies if the modules or units to check if they meet their specifications. This involves functional tests at the interfaces of the modules, but also more detailed tests which consider the inner structure of the software modules. During integration the units which are developed and tested for their functionalities are brought together. The modules-are integrated into a complete system and tested to check if all modules cooperate as expected. System Verification: After successfully integration including the related tests the complete system has to be tested against its initial requirements. This will include the original hardware and environment, whereas the previous integration and testing phase may still be performed in a different environment or ona test bench. Operation & Maintenance: The system is handed over to the customer and will be used the first time by him, Naturally the customer will check if his requirements were implemented as expected but he will also validate if the correct requirements have been set up in the beginning. In case there are changes necessary it has to be fixed to make the system usable or to make it comply to the customer wishes. In most of the "Waterfall Model" descriptions this phase is extended to a never ending phase of "Operations & Maintenance", All the problems which did not arise during the previous phases will be solved in this last phase, Requirements Engineering SWE:26a™ Part: Advantages. « Simple and easy to use. « Easy to manage due to the rigidity of the model - each phase has specific deliverables and a review process, « Phases are processed and completed one at a time. «Works well for smaller projects where requirements are very well understood, Disadvantages Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle; High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high risk of changing. 5. a) What is the Heuristic Project Estimation technique? [WBUT 2017] Answer: Refer to Question No. 9(a) [Heuristic Techniques] of Long Answer Type Questions. . b) A Project size of 200 LOC is to be developed. Software development team has average experience on similar type of project: The project schedule is not very tight. Calculate Effort, Time of Development, Average Staff size and Productivity of the Project. [WBUT 2017] Answer: i) Effort= 2.4(KLOC)'® = 2.4(200)' =625.5942 Tdev=2. 5(Effort)”* =2.5(625.5942)°*=28.88 months Average Staff Size=Effort/TimeSchedule= 21.66 Productivity level=[KLOC/EFFORT] DSI/MM=200/625,5942 =0.3197 DSI/MM . ii) Effort= 3.0(KLOC)""? = 3,0(200)'"? =1133.1172 Tdev=2,5(Effort)*”* =2.5(1133.1172)°**=29.30 months Average Staff Size=Effor/TimeSchedule= 38.67 Productivity level= [KLOC/EFFORT] DSI/MM=200/1 133.1172 = 0.1765 DSI/MM 6. a) Draw a DFD that depicts and ATM system (only withdrawal) mentioning Suitable Assumptions. Now build a structure chart. b) An-embedded system of size 400 KLOC has to develop, Project manager has a choice of hiring from two pools of developers: very highly capable with very little experience (AEXP very high) or developers of low quality (LEXP very low) but a lot of Experience, Find the values of EAF, Effort & Development Time. [WBUT 2017] SWE-27POPULAR PUBLICATIONS Answer: a) i Invalid ——— Card Card details ——— Invalid —— PIN 4 PIN Overdraw details yy Transaction Amount peceipt eget Context Diagram - ATM (Cash Withdrawal) System - Data Flow Diagram Template Values of EAF, Effort & Development Fig: Structure Chart - ATM b) This is the case of embedded mode and model is intermediate COCOMO. Hence, : E=a,(KLOC)" *EAF D=0(E)* = 2.8(400)!2°= 3712. PM. Case I: Developers are very highly capable with very little experience in the programming being used. EAF = 0.82 x 1.14 = 0.9348 E=3712x 934! D=2,5 (3470)** Case I: Developers are of low quality but lot of experi i i ipsa hg used. ty ‘perience with the programming BAF = 1.29 x 0.95 = 1.22 E=3712x 1.22=4528 PM 5 (4528)? = 36.9 M SWE-28SOFTWARE ENGINEERING 7. What is cost benefit analysis? What are the common techniquos for cost benefit analysis? Develop a set of functional and non-functional requirements for a new software project. [WBUT 2018] Answer: 1" Part: A benefit-cost ratio analysis (BCR) is an indicator used in cost-benefit analysis to show the relationship between the relative costs and benefits of a proposed project. Benefit- cost ratios (BCRs) are most often used in capital budgeting to analyze the overall value for money of undertaking a new project. However, the cost-benefit analyses for large projects can be hard to get right, because there are so many assumptions and uncertainties that are hard to quantify. : 2™ Part: The common techniques for cost benefit analysis are- cost-utility analysis, risk-benefit analysis, economic impact analysis, social return on investment (SRO!) analysis. © Cost-utility analysis: Cost-utility analysis (CUA) is a form of financial analysis used to guide procurement decisions. The mostcommon and well-known application of this analysis is in pharmacoeconomics, especially health technology assessment (ATA). Cost-utility analysis allows comparison across different health programs and policies by using a common unit of measure (money/QALYs gained). Cost-utility analysis provides a more complete analysis of total benefits than simple cost-benefit analysis does. This ig because Cost-utility analysis takes into account the quality of life that an individual has, while Cost-benefit analysis does not. « Risk-benefit ratio: A risk-benefit ratio is the ratio of the risk of an action to its potential benefits. Risk-benefit analysis is analysis that seeks to quantify the risk and benefits and hence their ratio. Analyzing a risk can be heavily dependent on the human factor. A certain level of risk in our lives is accepted as necessary to achieve certain benefits. « Economical impact analysis: An economic impact analysis (EIA) examines the effect of an event on the economy in a specified area, ranging from a single neighbourhodd.to the entire globe. It usually measures changes in business revenue, business profits, personal wages, and/or jobs. The economic event’ analyzed can include implementation of a new policy or project, or may simply be the presence of a business or organization. An economic impact analysis is commonly conducted when there is public concern about the potential impacts of a proposed project or policy. An economic impact analysis typically measures or estimates the change in. economic activity between two scenarios, one assuming the economic event occurs, and one assuming it does not occur (which is referred to as the counterfactual case). This can be accomplished either before or after the event. > Social return on investment: Social return on investment (SRO!) is a principles- based method for measuring extra-financial value (such as environmental or social value not currently reflected or involved in conventional financial accounts). It can be used by any entity to evaluate impact on stakeholders, identify ways to improve performance, and enhance the performance of investments. The SROI method as it SWE-29POPULAR PUBLICATIONS . has been standardized by the Social Value UK provides a consistent quantitative approach to understanding atid managing the impacts of a project, business, organisation, fund or policy. It accounts for stakeholders’ views of impact, and puts financial ‘proxy’ values on all those impacts identified by stakeholders which do not typically have market values. The aim is to include the values of people that are often excluded from markets in the same terms as used in markets, that is money, in order to give people a voice in resource allocation decisions. 3" Part: : Functional Requirements define what the system needs to do, Functional requirements are what the business users expect the software to ‘do’; what tasks they wish it to perform. (e.g. write paychecks, calculate launch date for lunar orbit, do hours to gross calculation for movie studios, etc.) . Whereas non Functional Requirements describe how the system will do it. The functional requirement is to produce a pay slip for an employee, the non-functional requirement is to print a pay slip per employee (up to, say, 10,000) in, say, 48 hours elapsed. The non functional requirement may be one of the Ci Success Factors, it may even be the prime driver for the development, but it is still non-functional. Non functional Tequirements have also been called the ‘ilities' because they are most simply expressed like this: 1. usability 2. reliability 3. interoperability 4. scalability 5. security Functional Requirements are either met or not met. Non-functional requirements tend to be things that you can measure. Example: The Functional requirements for the Librarian are: Insert book: This action is done to add new book to library book collection Delete / modify book: This event is to delete an existing book or modify its information. Delete member: Admin can delete a member due to some specific rules. Return book: Admin should confirm the return of books borrowed by users. Non-functional Requirements for the Librarian are: Error handling: Library Management System shall handle expected and non-expected errors in ways that prevent loss in information and long downtime period. Performance Requirements: The system shall accommodate high number of books and users without any fault. Safety Requirements: System use shall not cause any harm to human users Security Requirements: System will use secured database. SWE-30SOFTWARE ENGINEERING 8. a) Consider a project with 950 lines of code which has the following distribution in terms of days for each effort: . Phase Programmer Days Requirements 20 Design 10 Implementation 10 Testing 15 Documentation 40 Calculate the productivity given the line of code and number of programmer days. b) Calculate COCOMO effort, development time and productivity for an organic project that is estimated to have 39,800 lines of code. Assume values of constant a =2.4 and b= 1.05, [WBUT 2018] Answer: a) Total Efforts = (20+10+10+15+10) = 65 Productivity = LOC/ Total Efforts = 950/65 = 14.6 LOC/programmer’s day b) For Organic model, 39800 Lines of codes = 39800 = —— =39.8KLOC ines of codes am a=2.4, b= 1.05 ‘The COCOMO effect (E) = 2.4(39.8)'* PM = 10.235 PM Taa= 2.5(10.235)"* = 6.050 = 6Months( Approx) 39.8 ——— DSI | MM =3.888 Therefore, Productivity = <= = 7 - 9. a) Why is intermediate COCOMO expected to give more accurate estimates than the basic COCOMO? [WBUT 2019] Answer: The basic COCOMO adopt effort and development time as functions of the product size. But, a host of other parameters besides the product size affect the effort required to develop the product along with the development time. Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant (15 different) parameters must be taken into account and which is done in the intermediate COCOMO model. That's why intermediate COCOMO is projected to give more accurate estimates compared to the basic COCOMO model of cost estimation. ) Use a schematic diagram to show the order in COCOMO estimation technique jor i) cost Ui) effort iti) durati iv) eas [WBUT 2019] SWE-31POPULAR PUBLICATIONS Answer: Requiremens Effort of Size Cont and Type Software cost drivers estimation process Omration Other cost drivers Loading In. a classical view of the estimation process, it will generate three outputs - efforts, duration and loading. The following is a brief description of the outputs: « * Manpower loading - number of personnel (which also includes management personnel) that are allocated to the project as a function of time. © Project duration - time that is needed to complete the project. « Effort - amount of effort required to complete the project and is usually measured in units as man-months (MM) or person-months (PM). ‘The outputs (loading, duration and effort) are usually computed as fixed number with or without tolerance in the classical view. But in reality, the cost estimation process is more complex than what is shown in figure 1. Many of the data that are inputs to the process are modified or refined during the software cost estimation process. ‘Theré are two main equations that are used to calculated effort and schedule time (measured in months). They are: Equation 1 PM = a(KDSI)b * EAF Equation 2 TDEV = o(PM)4 Where: * PM is effort in person-months. ¢ EAF is the effort adjustment factor * TDEYV is the schedule time + KDSI is the number of lines of code (in thousands) * a,b,c, and d areall constants based on the mode you are using (refer to Table 1) Table 1 — List of Constants Based on Mode Model a b © d Or ic 24 1.05 25 0.38 Semi-detached 3.0 1.12 25 0.35 [Embedded 3.6 | 120 [25 [032 40. a) ‘Sofiware doesn’t wear out’ justify. b) Write the IEEE definition of software engineering. c) Mention the characteristics of software contrasting it with characteristics of hardware. [WBUT 2022] Answer: a) Software docs not wear out. There is a well-known “bath tub curve” in reliability studies for hardware products. The curve is given in Fig. 1. The shape of the curve like “bath tub”; and is known as bath tub curve. SWE-32= Failure intensity > Time ————> Fig. 1 Bath tub curve There are three phases for the life of a hardware product. Initial phase is burn-in phase,.where failure intensity is high. It is expected to test the product in the industry before delivery. Due to testing and fixing faults, failure intensity will come down initially and may stabilise after certain time. The second phase is the useful life phase where failure intensity is approximately constant and is called useful life of a product. After.few years, again failure intensity will increase due to wearing out of components. This phase is called wear out phase. We do not have this o rallbeighaiy => — Time ——> Fig. 2 Software curve phase for the software as it does not wear out, The curve for software is given in Fig. 2. Important point is software becomes réliable overtime instead of wearing out. It becomes obsolete, if the environment for which it was developed, changes. Hence, software may be retired due to environmental changes, new requirements, new expectations, etc. b) IEEE defines software engineering as: (1) The application of a” systematic, disciplined, quantifiable. approach to the development, operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in the above statement. ©) Difference between Hardware and Software Parameters Hardware Software ‘ Basic. | Hardware is a physical part of the | Software is a set of instructions that Definition ‘computer that causes the processing | tells a computer exactly what to do. of data. Development | It is manufactured. It is developed and engineered. Dependency — | Hardware cannot perform any task _ | The software can not be executed without software. without hardware. Process of Electronic and other materials are Created by utilizing a computer creating used to create hardware. language to write instructions. SWE-33POPULAR PUBLICATIONS Parameters Hardware Software Tangible Hardware is tangible as hardware is | Software is intangible as we can see a physical electronic device, that can | and also use the software but can’t be touched. : touch them. Durability Hardware typically wears out over _ | The software does not wear out with time. time. However, it may contain flaws and glitches. Types thas four main categories: It is mainly divided into 1, Input Devices 1. System software 2. Output Devices 2. Application software. 3, Storage Devices 4, Internal Components. Virus effect Hardware is not affected by Software is affected by computer computer viruses. viruses, Transfer It cannot be transferred from one It can be trarisferred via a network place to another electrically through _| means. L the network. Machine- ‘Only machine-level language is The program accepts human- Level known to be understood by readable input, interprets it in language hardware. machine-level language, and sends it to hardware for additional processing. Replacement | Ifthe hardware is damaged, it is If the software is damaged, its replaced with a new one. backup copy can be reinstalled. Failures Dust, overheating, humidity, and ‘Overloading, systematic error, other factors are commonly major-minor version error, and other responsible for hardware failures, | factors are commonly responsible for software failures. Examples Ex: Keyboard, Mouse, Monitor, Ex: MS Printer, CPU, Hard Word, Excel, PowerPoint, Photosho _| disk, RAM, ROM, etc. |p, MySQL, etc, 11. Write short notes on the following: a) Software Project Plan (WBUT 2013, 2022] b) Software Configuration Management [WBUT 2014, 2015, 2018] c) Risk management (WBUT 2015] d) CASE tools [WBUT 2015, 2017, 2018] e) Waterfall Model [WBUT 2016, 2018] f) COCOMO Model [WBUT 2016] g) Team Structure of an Organization . [WBUT 2017) h) Risk Identification & Assessment [WBUT 2017] i) Spiral model [WBUT 2019] j) RAD model [MODEL QUESTION] Answer: a) Software Project Plan: Estimation of various project parameters is a basic project planning activity, The important project parameters that are estimated include: Project size, effort required to SWE-34SOFTWARE ENGINEERING develop the software, project duration, and cost. These estimates not only help in quoting the project cost to the customer, but are also useful in resource planning and scheduling. There are three Utoad categories of estitnation techniques: 1. Empirical Estimation Techniques: * Empirical estimation techniques are based on making an educated guess of the project . parameter: While using this technique, prior experience with development of similar products is helpful. Although empirical estimation techniques are based on common sense, different activities involved in estimation have been formalized over the years. 2. Heuristic Techniques: Heuristic techniques assume that the relationships among the different project parameters can be modeled using suitable mathematical expressions. Once the basic (independent) parameters are known, the other (dependent) parameters can be easily determined by substituting the value of the basic parameters in the mathematical expression. 3. Analytical Estimation Techniques: . Analytical estimation techniques derive the required results starting with basic assumption regarding the project: Thus, unlike empirical and heuristic techniques, analytical techniques do have scientific basis. Halstead’s software science is an example of an analytical technique. Halstead’s software sciencé can be used to derive some interesting results starting with a few simple assumptions. b) Software Configuration Management: The output of the software process is information that may be divided into three broad categories: 1. Computer programs (both source level and executable forms). 2. Documents that describe the computer programs (targeted at both technical papers and users). 3. Data (contained within the program or external to it). The items that comprise all information produced as part of the software process are collectively called a software configuration. As the software process progresses, the, number of software configuration (SCls) grows rapidly. A System Specification spawns a Software Project Plan and Software Requirements Specification (as well as hardware related documents). These in turn spawn other documents to create a hierarchy of information. There are four fundamental sources of change: 1, New business or market conditions dictate changes in product requirements or business rules, 2. New customer needs demand modification of data produced by systems, functionality delivered by products, or services deliver computer-based system. 3. Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure. 4. Budgetary or scheduling constraints cause a redefinition of the system or product. Software configuration management is a set of activities that have been developed to manage change throughout the life-cycle of computer software. Customers want to modify requirements. Developers want to modify the technical approach. Managers want to modify the project strategy. Why all this modification? The SWE-35POPULAR PUBLICATIONS answer is really quite simple. As time passes, all constituencies know more (about what they need, which approach would be best, how to get it done and still make money). This additional knowledge is the driving force behind most changes. c) Risk management: Refer to Question No. 3(b) of Long Answer Type Questions. Risk control: It is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, It is useful to record decisions in the plan, so that both customer and developer can review how problems are to be avoided, as well as how they are to be handled when they arise. We should also monitor the project as development progresses, periodically reevaluating the risks, their probability, and likely impact. Risk resolution is the execution of the plans for dealing with each risk. The risk management practice is to identify the nature and status of the risk, write them down, communicate them to concerned people and authority including insurance consultants over the duration of the project, d) CASE tools: CASE (Computer Aided Software Engineering) tools capture the data items appearing in a DFD automatically to generate the data dictionary. CASE tools support queries about definition and usage of data items. For example, queries may be made to find which data item affects which processes a process affects which data items the definition and usage of specific data items, etc. Query handling is facilitated if data dictionary is stored in a relational database management system (RDBMS). Several CASE tools are available: © To support structured analysis and design © To maintain the data dictionary * Tocheck whether DFDs are balanced or not Use of CASE Change tools and 4GL. ‘control Timeliness Documentation Customer Cost Partnership ‘control Fig: CASE Tools The tasks like Systems Analysis and drawings of Data Flow Diagrams are falling under the category of Lower Case. However, Upper Case focuses on tools found in different CASE produets to help in the analysis and design process, Some of the Upper Case tools are screen generators, report generators ete. ¢) Waterfall Model: Refer to Question No. 4(c) of Long Answer Type Questions. SWE-36SOFTWARE ENGINEERING £) COCOMO Model: Refer to Question No. 2 of Long Answer Type Questions. g) Team Structure of an Organization: Personnel required for a program or a project is a practice of finding, evaluating, and establishing a working environment and fires them when they are no longer needed. Staffing involves finding people, who.may be hired or already working for the company (organization) or may be working for competing companies. Staffing management plan is a part of software development. «It may not be possible to appoint the ideal people to work ona project Project budget may not allow for the use of highly-paid staff © Staff with the appropriate experience may not be available An organisation may wish to develop employee skills on a software project. Managers have to work within these constraints especially when there are shortages of trained staff. There is a risk if right kinds of people are not available in a project, it makes a big difference whether a project is staffed with capable engineers. If key positions are filled- up with inappropriate people, the project runs the risk of delaying deliveries or producing poor-quality products, or both. Project Team Staffing management plan is a part of software development. It may not be possible to appoint the ideal people to work on a project * Project budget may not allow for the use of highly-paid staff; “e Staff with the appropriate experience may not be available; ‘An organisation may wish to develop employee skills on a software project. Managers have to work within these constraints especially when there are shortages of trained staff. There is a risk if right kind of people is not available in a project; it makes a big difference whether a project is staffed with capable engineers. If key positions are filled- up with inappropriate people, the project runs the risk of delaying deliveries or producing poor-quality products, or both, Number of staff.required ina project depends on an ideal logical view of a software engineering environment, which covers: © The infrastructure is the heart of the environment: all connections among different components take place through it. © Individual tools constitute a layer that uses the services ‘provided by the infrastructure. * Methods and methodologies—the external layers of the structure—provide guidance on the use of tools. They enforce a predefined strategy of using the tools according to the principles that underlie the method or the methodology. Finally, the environment must support group work: designers do not work in isolation, norcan they interact only through the database. Much critical activity in the software production process is of a “social type” (brainstorming sessions, walk-through, code inspections, etc.) not presently supported by the available commercial technology. SWE-37 oePOPULAR PUBLICATIONS Some of the software organizations are: «© Centralized-Control Team Organization Chief programmer Librarian Programmers Specialists © Decentralized-Control Team Organization OP oO) © (a) Management structure (b) Patterns of communication. ¢ Mixed-Control Team Organization Project manager Senior engineers Junior engineers @ ) Mixed-control organizations. (a) Management structure. (b) Patterns of communication. An Assessment of Team Organizations h) Risk Identification & Assessment: Refer to Question No. 3(b) of Long Answer Type Questions. i) Spiral model; Refer.to Question No. 8(a) of Short Answer Type Questions, j) RAD model: The Rapid Application Development Model is a property of IBM. User involvement is essential at every stage of the model. At the first step of the model building a prototype is built. RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users. Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the SWE-38SOFTWAREENGINEERING analysis, design, and implementation phases, such as CASE (computer-aided sofware engineering) tools. One possible subtle problem with RAD-based methodologies is managing user expectations, According to the functional requirements the model is separated into four stages; © Requirement Planning © User Description * Construction Phase © Cut over Phase SWE-39POPULAR PUBLICATIONS SYSTEM DESIGN 4. Which is NOT a non-functional requirement? (WBUT 2014] a) efficiency b) reliability ¢) productfeatures di) stability Answer: (c) 2. To allocate resource to activities we use [WBUT 2014] a) PERT chart b) Gnatt chart c) Network Diagram d) all of these Answer: (d) 3. To achieve a good design, modules should have — [WBUT 2014] a) weak cohesion low coupling b) weak cohesion high coupling c) strong cohesion low coupling d) strong cohesion high coupling Answer: (c) 4. If data from one module is used to direct the order of execution in another, then the coupling is known as - [WBUT 2014] a) Stamp Coupling b) Data Coupling c) Control Coupling d) Content Coupling Answer: (c) §. Cardinality in an ER Diagram refers to [WBUT 2014] a) number of attributes in an entity b) the order of co-related entities c) the number of sub-entities d) degree of a relationship Answer: (b) 6. The bet type of cohesion is [WBUT 2015] a) coincidental —_b) logical ¢) informational d) functional Answer: (d) . 7. A physical DFD specifies . (WBUT 2015] a) what processes will be used b) who generates data and who processes it c) what each person in an organization does d) none of these Answer: (d) 8. The most creative and challenging phase of system life cycle is [WBUT-2017] a) Design b) Feasibility study c) Maintenance d) none of these Answer: (a) ¥ SWE-40SOFTWARE ENGINEERING 9, The database design activity deals with the design of [WBUT 2017] a) Logical database b) Physical database ¢) both (a) and (b) d) none of these Answer: (c) 10. Coupling is a measure of [WBUT 2017] a) Relative functional strength b) Interdependence among module ¢) both (a) and (b) d) none of these Answer: (c) 41. DFD shows [WBUT 2017] a) the flow of data b) the processes c) the areas where they are stored d) all of these Answer: (d) 42. DFD balancing means [WBUT 2018] a) balancing of weight of processes b) must match the total number of bubbles ¢) must match the data flow at the next level of DFD d) None of the above Answer: (c) 13. When the two bubbles are interconnected directly, it is referred as (WBUT 2018] a) serial DFD b) direct DFD ¢) synchronous —_—d) balanced DFD Answer: (c) 14, Which is not true in context of Decision Tree? [WBUT 2019] a) Used in white box model b) Perform well with large data c) Handles both categorical and numerical data d) Random forest tree is used for regression type problem Answer: (d) 15. Which depicts flow of control in program modules? [WBUT 2019] a) Flowchart b) DFD c) Both (a) and (b) d) None of these Answer: (a) 16. The CMMI was developed ‘o combine multiple into one framework. [WBUT 2022} a) Meta model b) Business maturity models ¢) Bootstrap d) All of the mentioned above Answer: (b) 17. What is the use of CMMI? [WBUT 2022] a) Decreases tisks in software b) Encouraging a productive ¢) Streamlines process improvement d) All of the mentioned above Answer: (d) SWE-41POPULAR PUBLICATIONS 18. Which of the following is a building block of UML? [WBUT 2022) a) Things b) Relationships c) Diagrams d) All of the mentioned Answer: (d) Short Answer Type Questio: 4. What is “Top-Down and Bottom-Up Design” approach? [WBUT 2014] OR, Explain top-down and bottom-up design. [WBUT 2015) Answer: Top-Down Design is a process, where refine the design at each step and then decompose, divide and conquer. In a bottom-up design approach it is just opposite. It starts with parts and then composed. In case of simple programs, a simple waterfall likes process, * But to use this process, one needs to be sure that the requirements are fixed and well understood! — Many software problems are not like that — Often customer refines the requirements when try to deliver the initial solution * With Top-Down. approach it is harder to test early because parts needed may not have been designed yet * With Bottom-Up, you may end up needing things different from how you built : them. 2. Draw an ER diagram for Hospital Management System showing cardinalities, strong and weak entities, derived attributes, primary key etc. [WBUT 2014] OR, Draw the E-R diagram fora hospital management. [WBUT 2016] SWE-42Answer: DOCTOR{Doctor-id, name, specialization, sex, age, contactno) PATIENT(Patient-ID, name, diesis, doctor-id(FK), Nurse-ID(FK)} NURSE(Nurse-ID, name, department, specialization,contactno) DEPARTMENT(Department-ID,_name, Doctor-id,_Nurse-ID, Type} Note: There is no weak entity. A 3. What are Cohesion and Coupling? Mention different kinds of cohesion. [WBUT 2015] Answer: Refer 0 Question No. 13(b) of Long Answer Type Questions. 4. What is Use’Case diagram? Draw the Use Case diagram of Hospital Management System. [WBUT 2015] Answer? 1 Part: Use Case Diagram displays the relationship among actors and use cases. SWE-43POPULAR PUBLICATIONS 2" Part: Out-Patient Dispensary Patient Recording Hospital Management System USE CASE Diagram i . tient after Patient Frreatniihs ‘Actor Actor 5. It is estimated that there will be 70 errors in a software. During testing 25 errors have been experienced. Calculate the failure intensity with a given value of ¢=0.03 using Jelenski Moranda model. What will be the failure intensity after experiencing 50 errors? [WBUT 2015] Answer: The Jelinski_Moranda model is one of the most primitive reliability model. The functional representation of the failure intensity can be expressed in the form Rate of failure(t) = O(N-i+1), where time interval of failure is-assumed to be same N= Total number of errors present . i= Number of errors found at time intervals ‘The set of observations for our case is: N=70 errors 1=20 failure ©=0.03 (given) Rate of failure(t)}=0.03(70-25+1 }=0.03x46 =1.38 failure/epu Hr. After 50 failures Rate of failure(t)=0.03(70-50+1 )=0.03x19 = .57 failure/cpu Hr Hence the rate of failures is decreasing with number of failures 6. Draw the use case diagram of a library management system. _ [WBUT 2016] Answer: Refer 10 Question No. 3(a) (2" Part) of Long Answer Type Questions. 7. What is meant by cohesion? How should software be designed considering cohesion? What is the difference between cohesion and coupling? [WBUT 2017] SWE-44SOFTWARE ENGINEERING Answer: Refer to Question No, 13(b) of Long Answer Type Questions. 8, Specify the general principles of user interface design. [WBUT 2018] Answel The principles of user interface design are’ intended to improve. the quality of user interface design. These principles are: (i) The structure principle: Design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concemed with overall user interface architecture. (i) The simplicity principle: The design should make simple, common tasks easy, communicating clearly and simply in the user's own language, and providing good shortcuts that are meaningfully related to longer procedures. (ii) The visibility principle: The design should make all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don't overwhelm users with alternatives or confuse with unneeded information. Z (iv) The feedback principle: The design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users. (v). The tolerance principle: The design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonable, : (vi) The reuse principle: The design should reuse internal and external components and behaviours, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember. 9. Write the short note on Rayleigh curve. [WBUT 2022] Answer: Putnam estimates project effort, schedule, and defect rate by using a tool known as The Norden / Rayleigh Curve. SWE-45———— Orerall Curve Design and Coding ——> Time +— The Rayleigh manpower loading Curve The software equation was derived by Putnam after he observed that the productivity levels of software staffing profiles followed the Rayleigh distribution, L=CKrP abel Putnam model involves the following terms: K, which represents the total effort expended (in PM) in product development e —L, the product estimate in KLOC. «. td; which correlates to the time of system and integration testing and can be relatively considered as the time required for developing the product. * Ck, the state of technology constant that reflects requirements that impede the development of the program, * Ckhas typical values of 2 for a poor development environment * 8 fora good software development environment * 11 for an excellent environment where software engineering principles, automated tools, and techniques are used. The exact value of Ck for a specific task can be calculated from the historical data of the organization developing it. Putnam’s model proposes that an ideal number of staff required to develop a project should follow the Rayleigh distribution. Initially, only a few engineers are needed to perform planning and specification tasks. As the project progresses and more detailed work is required, the number of engineers needed reaches a peak. After implementation and unit testing, the number of project staff reduces. Long Answer Type Questions 4, a) Briefly describe different user interface elements. [WBUT 2013] b) What are the methodology for dialog design? Answer: a) When designing your interface, try to be consistent and predictable in your choice of interface elements. Whether they are aware of it or not, users have become familiar with SWE-46SOFTWARE ENGINEERING elements acting in a certain way, 80 choosing to adopt those elements when appropriate will help with task completion, efficiency, and satisfaction. 2 Interface elements include but are not limited to: Input Controls: checkboxes, radio:buttons, dropdown lists, list boxes, buttons. toggles. text flelds, date field Navigational Components: breadcrumb, slider, search field, pagination. slider, tags. icons . Informational Components: tooltips, icons, progress bar, notifications, message + ~es, modal windows . Containers: accordion . b) Dialogue is a literary and theatrical form consisting of -a written or spoken conversational exchange between two or more people. Dialogue is used in classrooms, community gatherings, federal agencies, and other public addressing places to enable people, usually in small groups to share their perspectives and experiences about difficult issues. It is used to help people resolve long-standing conflicts and to build deeper understanding of contentious issues. Dialogue is about understanding and learning. Dialogue dispels steteotypes, builds trust, and enables people to be open to perspectives that are very different from their own. Dialogic relations have a specific nature: they can be reduced neither to the purely logical (even if dialectical) nor to the purely linguistic (compositional-syntactic). They are possible only between complete utterances of various speaking subjects... Where there is ‘no word and no language, there can be no dialogic relations; they cannot exist among objects or logical quantities (concepts, judgments, and ‘so forth). Dialogic relations presuppose a language, but they do not reside within the system of language. They are impossible among elements of a language. Today, dialogue is used in classrooms, community centers, corporations, federal agencies, and other settings to enable people, usually in small groups, to share their perspectives and experiences about difficult issues. It is used to help people resolve long- standing conflicts and to build deeper understanding of contentious issuies. Dialogue is not about judging, weighing, or making decisions, but about understanding and learning. Dialogue dispels stereotypes, builds trust, and enables people to be open to perspectives that are very different from their own. Structured dialogue: Structured dialogue represents a class of dialogue practices developed as a means of orienting the dialogic discourse toward problem understanding and consensual action, Whereas’ most traditional dialogue practices are unstructured or semi-structured, such conversational modes have been observed as insufficient for the coordination of multiple perspectives in a problem area. A disciplined form of dialogue, where participants agree to follow a framework or facilitation, enables groups to address complex problems shared in common. SWE-47