0% found this document useful (0 votes)
45 views27 pages

Sen W23

Uploaded by

tanupandav333
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)
45 views27 pages

Sen W23

Uploaded by

tanupandav333
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/ 27
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autanoenots USOAEC- 27001 - 2013 Certified) WINTER ~ 2023 EXAMINATION Model Answer — Only for the Use of RAC Assessors Subject Name: Software Engineering ‘Subject code: important Instructions to examiners: 2) The answers should be examined by key words and not as word-to-word as given in the madel answer scheme. 2) The model answer and the answer written by candidate may vary but the examiner may try to assess the understanding level of the candidate 3) The language errors such as grammatical, spelling errors should not be given mare importance (Not applicable for subject Enalish and Communication Skills, 4) While assessing figures, examiner may give credit for principal components indicated in the figure. The figures drawn by candidate and model answer may vary. The exarniner may give credit for any equivalent figure drawn. 5) Credits may be given step wise for numerical problems. In some cases, the assumed constant values may vary and there may be some difference in the candidate's answers and model answer. 6) In case of some questions credit may be given by judgement on part of examiner of relevant answer based on candidate's understanding, 7) For programming language papers, credit may be given to any other program based on equivalent concept 8) As per the policy decision of Maharashtra State Government, teaching in English/Marathi and Bilingual (English + Marathi) medium is introduced at first year of AICTE diploma Programme from acaclemnic year 202-2022. Hence if the students in first year (first and second semesters) write answers in Marathi or bilingual language (Enalish +Marathi, the Examiner shall consider the same and assess the answer based on matching of concepts with model Q. | Sub- Answer Marking No. | QN Scheme T ‘Attempt any FIDVE of the following: 10M a) _ | Define software. Draw the failure curve for software. 2M Ans | Software is: |. Instructions (computer programs) that when executed provide desired Correct features, function, and performance: 2. Data structures that enable the programs to| definition- | M adequately manipulate information, and 3. Descriptive information (documents) in both| and diagram- hard copy and virtual forms that describes the operation and use of the programs. IM MAH AMASHTRA STATE BOARD OP TECHNICAL EDUCATION (Autonomous) ISO/IEC - 27001 - 2013 Certified) Treveased failure ware due bo side, etfects NN curve Td alized 7 —> The gs Failuve curves fir sofhaare 1b) _| State two characteristics of software. 2M “Ans | Characteristics of software: Any two 1) Software is developed or engineered; it is not manufactured in the classical sense. correct 2) Software doesn't “wear out.” But it does deteriorate! eee 3) Although the industry is moving toward component-based construction, most} | Meeae software continues to be custom built. ©) __| State need of Software Requirement Specification (SRS). 2M “Ans | The need of SRS document is to provides “Any two points 1) A detailed overview of software product, its parameters, and goals, sunting ed oF 2) The description regarding the project's target audience and its user interface hardware and software requirements 3) How clients, team and audience see the product and its functionality. @)__ | Define risk and list any two type of risk. 2M ‘Ans | Risk is uncertain evens associted with future evenis which have a probabiliy of occurrence but it may or may not occur and if occurs it brings loss to the project. Following are the types of risk: 1) Generic risk 2) Product specific risk oR Page No: 2 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘Aatonaaous (ISOMEC - 27001 - 2013 Certified) 1) __ Schedale/Time -related Delivery Related Planning asks 2) Budget/Financial risks 3) Operational/Procedural Risks 4) Technical/Functional Performance Risks 3) ‘Other Unavoidable Risks ©) _ | Namie two cost estimation approaches. zM ‘Ans | 1) Heuristic Estimation Approach ‘Any two techniques-1 M 2) Analytical Estimation Approach each 3) Empirical Estimation Approach 1) | Define soffware quality control and qualily assurance, M Ans [Software quality control: I is @ procedure that focuses on fulfilling the quality| 1 MTore requested, QC aims to identify and fix defects, It is a method to verify the quality-| defi Validation. It always involves executing a program and hence it's a Corrective technique. Software quality assurance: Quality assurance consists of the auditing and reporting functions of management, The goal of quality assurance is to provide management with the data necessary to be informed about prodtict quality, thereby gaining insight and confidence that product quality is meeting its goals. It’s a Preventive technique. 2) | List the phases of sofiware qualily assurance, 2M ‘Ans | Following are the phases of Software Quality Assurance: ‘Any 2 phases- each | M i, Prepares an SQA plan for a project. ii. Participates in the development of the project's software process description. iii, Reviews software engineering activities to verify compliance with the defined software process. iv, Audits designated software work products to verify compliance with those defined as part of the software process. vy, Ensures that deviations in software work and work products are documented and handled according to a documented procedure, vi, Records any noncompliance and| reports to senior management. 2 ‘Attempt any THREE of the following: TM Page No: 3 | 27 AL EDUCATION i ~ [ISOMEC - 27001 - 3013 Cerliied) Explain sofware engineering as layered technology approach. 4M Sofware engineering is a layered technology. The layers of software engineering as shown in the above diagram are; ~ | a 1, A Quality Focus: Any cnginecring approach (including software engineering) must rest on an organizational commitment to quality. Total quality management, six sigma and similar philosophies foster a continuous process improvement culture, and it is this culture that ultimately leads to the development of increasingly more effective approaches to software engineering, The bedrock that supports software engineering is a quality focus. 2. Process Layer: The foundation for software engincering is the process layer. Sofiware Engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software, Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, works products (models, documents, data, reports, forms etc.) are produced, mi established, quantity is ensured, and change is properly managed, 3. Methods: Sofiware Engineering methods provide the technical —how to build software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing and support. 4. Tools: Sofiware Engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by ne tool can be used by another, a system for the support of software development, called computer-aided software engineering is established. Correct ‘Diagram -! M, explanation - 3M ts Explain the notations used for preparing a data flow diagram. 4M MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION, ‘ Attanaenousy (ISOMEC - 2700 - 2018 Certified) Ans Correct ‘Symbol Notation Use symbols with explanation - External entity External entitles are IM cach objects outside the system Process ‘A process receives Input data and process output data with different form. Data Flow Dataflow is path for data —— to move from one end to another, Data store —_— Data stores are repositories for data. Circle: A circle (bubble) shows a process that transforms data inputs into data outputs. Data Flow: A curved line shows the flow of data into or out of a process or data store, Data Store: A set of parallel lines shows a place for the collection of data items, A data store indicates that the data is stored which can be used at a later stage or by the other processes in a different order, The data store can have an clement or group of elements, Souree or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of system outputs. ©) _ | Explain following elements of management spectrum : aM i) People ii) Process iii) Product iv) Project “Ans | The management Spectrum: 4p's Effective software project management focuses on the] — Explanation four P's: people, product, process, and project. cach clement of i) The People: ‘management 1, The “people fietor” is so important that the Software Engineering Institute has developed a People Capability Maturity Mode! (People CMM) to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to| accomplish its strategic business objectives 2. The people capability maturity model defines the following key practice ireas far software people: a Staffing b. communication and coordination ©. work environment d._ performance management spectrum — 1M Page No: 5 | 27 MAILARASHTRA STATE ARD OF TECHNICAL EDUCATION 7 ‘otanom (ISOMEC - 27001 = 2013 Certified) ¢. Training, compensation, competency analysis and development, career development, workgroup development, tcam/culture development and others. 3. Organizations that achieve high levels of People-CMM maturity have higher likelihood of implementing eflective software project management practices. ii) The Product: 1, Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints’ should be identified. 2. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress, 3, Objectives identify the overall goals for the product (from the stakeholders” points of view) without considering how these goals will be achieved. 4. Scope identifies the primary dat, functions, and behaviors that characterize the product 5. The alternatives cnable managers and practitioners to select a “best” approach, given| the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and other factors. iti) The Process: 1. A software process provides the framework from which a comprehensive plan for software development can be established. 2A small number of framework activities are applicable to all software projects, regardless of their size or complexity. 3. A number of different task sets—tasks, milestones, work products, and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team, 4. Finally, umbrella activities—such as software quality assurance, software configuration management, and measurement occur throughout the process. iv) The Project: 1. To manage complexity, we conduct planned and controlled software projects. 2. The success rate for present-day software projects may have improved but our project failure rate remains much higher than it should be. 3. To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common waming signs, understand the critical success factors that lead to good project management, and develop a common-sense approach for planning, monitoring, and controlling the project. Page No: 6 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION r 1 (ISO/IEC - 27001 ~ 2013 Certined) d) Explain four basic principles of software project scheduling. Ans Basie principles soft ware projeet scheduling: 1)\Compartmentalization; The project must be comparmentalized into a number of] manageable activities and tasks. To accomplish compartmentalization, both the product and the process are Decomposed. 2MInterdepenciency: The interdependency of each compartmentalized activity or task must be determined. Some tasks must occur in sequence while others can occur in parallel. Some activities cannot commence until the work product produced by another| is available, Other activities can occur independently. 3¥Time allocation: Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort), In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis. 4)Effort validation; Every project has a defined number of staff members, As time allocation occurs, the project manager must ensure that no more than the allocated number of people has been scheduled at any given time. 5) Defined responsibilities; Every task that is scheduled should be assigned to a specific team member. 6\Defined outcomes; Every task that is scheduled should havea defined outcome. ‘7\Defined milestones: Every task or group of tasks should be associated with a project milestone. Program evaluation and review technique (PERT) and critical path method (CPM) are two project scheduling Methods that can be applicd to software development. 8\Defined outcomes; Every task that is scheduled should have a defined outcome for| sofware projects such as a work product ar part of a work product — Work products are often combined in deliverables. Attempt any THREE of the following: 2M Distinguish between perspective process model and agile process modal. 4M Page No: 7 | 27 MAHARASHTRA STATE ROARD OF TECHNICAL EDUCATION (Astonemous} ASOMEC - 27001 - 2013 Certified) Sr | Parameter Perspective Process Model | Agile Process No Model T | Quality Techanges from Trfocuses onall analysis>Design>Code>Test | aspects of SDLC at any given time ‘Quality control Detection & fixing during | Early detection and system and regression testing | fixing in each atthe last phase of project | sprint fallowed by stabilization 3 | Continual improvement | Lesson Teamed from previous | Lesson Teamed release implemented in next | from Previous release. sprint will be implemented d in the next sprint. ‘Any four poinis each point | M 4 | Risk ‘No risk identification. Early identification firefighting during testing and mitigation in phase every sprint 3 | Postmortern/retrospection | After Every place ‘After Every sprint in Retrospection meeting 6 | Customer Feedback At the end of project At the end of every sprint b) _| Describe any four principles of communication for software engineering. aM Ans | Principle 1 Listen: 1M for one - principle, Any © Try 10 focus on the speaker's words, rather than formulating your response 10} four principles those words. with description © Ask for clarification if something is unclear but avoid constant interruptions. # Never become contentious in your words or actions (e.g., rolling your eyes or shaking your head) as a person is talking. Principle 2 Prepare before you communicate: * Spend the time to understand the problem before you meet with others. If necessary. perform some research to understand business domain. + Ifyou have responsibility for conducting a mecting, prepare an agenda in advance of the meeting. Principle 3 someone should facilitate the activit Page No: 8 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘\utomermonst (SOME - 7001-2013 Certified * Every communication meeting should have a leader (a facilitator) * Tokeep the conversation moving in a productive direction, © To mediate any conflict that docs occur, and © To ensure that other principles are followed. Principle 4 Face-to-face communication is best: * Kt usually works better when some other representation of the relevant information is present. + For example, a participant may create a drawing /document that serves as a focus for discussion. Principle 5 Take notes and document decisions: Someone participating in the communication should serve as a recorder and write down all important points and decisions. Principle 6 Strive for collaboration: © Collaboration occurs when the collective knowledge of members of the team is used to describe product or system functions or features * Each small collaboration builds trust among team members and creates a ‘common goal for the team. Principle 7 Stay focused; modularize your discussion: + The more people involved in any communication, the more likely that discussion will bounce from one topic to the next. + The facilitator should keep the conversation modular; leaving one topic only after it has been resolved. Principle 8 If something is unclear, draw a picture: *© Verbal communication goes only so far. A sketch or drawing can often provide clarity when words fail to do the job. Principle 9 (a) Once you agree to something. move on. (b) Ifyou can't agree to something, move on. (c) If a feature or function is unclear and cannot be clarified at the moment, move on, © The people who participate in communication should recognize that many topics require discussion and that moving on is sometimes the Page No: 9 | 27 MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION ‘Nutonomnoas) [ISOMEC - 27001 - 2013 Certified) best way to achieve communication agility, Principle 10 Negotiation is not a contest or a game: It works best when both parties win, * There are many instances in which you and other stakeholders must negotiate functions and features, priorities, and delivery dates, If the team has collaborated well, all parties have a common goal. Still, negotiation will demand compromise from all parties. Draw DFDO and DFDI diagram for library management system. 4M Ans a5 ee Sead et wee sien + t seahregeniinire DED Level 0 for Library Management System Level 02M Level 12M MATARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘Aono (ISOMEE - 27001 - 2013 Certified DFD Level | for Library Management System d) | Explain line of code metrics for size estimation. 4M Ans | Line of code metrics for size estimation: Correct LOC counts the total numberof lines of source code in a project. — The units of LOC are: KLOC- Thousand lines of code NLOC- non-comment lines of code KDSI- Thousands of delivered source instruction. The size is estimated by comparing it with the existing systems of the same kind. The experts use it to predict the required size of various components of software and then add them to get the total size, Parameters to count LOC: 1, count only executable lines. 2. count executable lines plus data definitions. 3. count executable lines, data definitions and comments, Page No: 11 | 27 ro MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION ‘Autonomous = 27MM ~ 2013 Certified) some count physical lines on input screen, Consider the following example for counting LOC; KCSI: thousands of changed source instructions. KSSL: thousands shipped source instructions First Release of Product Y KCSI = KSSI = 50 KLOC Defects/KCSI = 2.0 Total number of defects = 2.0 * 50 = 100 Second Release, KCSI = 20 KSSI = S0+ 20 (new and changed lines of code) -4 (assuming 20% are changed lines of code) = 66 Deteet/KCSI = 1.8 (assuming 10° additional defects = 1.8 x 20= 36, improvement over the first release). Total number of Third Release, KCSI-30, KSSI 66+30 (new and changed lines of code) -6 (assuming 20% of changed lines of code) = 90. Targeted number of additional defects (no more than previous release) ~ Defect rate target for the new and changed lines of code: 10/30= 1.2 defects/KCSI or lower. Attempt any THREE of the followit 2M aw) _| Deseribe extreme programming with proper diagram. aM ‘Ans | Extreme programming is a lightweight, efficient, Tow-risk, Mexible, predictable,| 0M for scientific, and fun way to develop software. eXtreme Programming (XP) was conceived | Diagram and 3 and developed to address the specific needs of sofiware development by small teams in] ——-M for the face of vague and changing requirements. Extreme Programming is one of the Agile| explanation software development methodolo, values and principles to guide the team’s behavior, The team is exp xtreme Programming provides Page No: 12 | 27 MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION tnenous (ISOMIEC - 27001-2013 Certiied) Specific core practices. Where + Each practice is simple and self-complete * Combination of practices produces more complex and emergent behavior gery {decaeing | ROBE ib isatn cards SS Detign. a 4 Ts oN Pair Ry Pragromm io) Coding st continver-s Toteaqration hg ma G Toe rem: 7 Fig: Extreme Programming Extreme Programming is based onthe following values- *® Communication © ‘Shmplicity + Feedback * Courage © Respect Extreme Programming involves- © Writing unit tests before programming and keeping all of the tests running at all times, The tnt tests are automated and eliminate defects early, thus reducing the costs. * Starting with a simple design just enough to code the features at hand and redesigning when required. Page No: 13 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION q (Autonoma) (ISOMEE - 27001 + 2013 Certified) © Programming in pairs (called pair progiamming), with Iwo programmers al one screen, taking tums to use the keyboard, While one of them is at the keyboard, the other constantly reviews and provides inputs + Integrating and testing the whole system several times a day * Putting a minimal working system into production quickly and upgrading it whenever required © Keeping the customer involved all the time and obtaining constant feedback. Iterating facilitates the accommodating changes as the software evolves with the changing requirements, Extreme Programming solves the following problems often faced in the software development projects- © Slipped schedules: Short and achievable development cycles ensure timely deliveries. * Cancelled projects: Focus on continuous customer involvement. ensures transparency with the customer and immediate resolution of any issues. © Costs incurred in changes: Extensive and ongoing testing makes sure the changes do not break the existing functionality. A running working system always ensures sufficient time for accommodating changes such that the current operations are not affected. + Production and post-delivery defects; Emphasis is on the unit tests to detect and fix the detects early. ® Misunderstanding the business and/or domain: Making the customer 4 part of the team ensures constant communication and clarifications * Business changes: Changes are inevitable and are accommodated at any point of time, © Staff turnover: Intensive team collaboration ensures enthusiasm and goodwill, Cohesion of multi-disciplines fosters the team spirit, ‘Extreme Programming takes the effective principles and practices to extreme levels. Extreme Programming Page No: 14 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Aatanemoe) (SOAEC- 27001 - 2018 Certified) © Code reviews are effective as the code is reviewed all the time. © Testing is effective as there is continuous regression and testing. Design is effective as everybody needs to do refactoring daily. © Integration testing is important as integrate and test several times a day. © Short iterations are effective as the planning game for release planning and iteration planning b) Enlist core principles of software engineering practice. 4M “Ans T Core Principles off software engineering practice arez 1 The Reason It All Exists A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. 2.Keep it simple stupid. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. 3. Maintain the vision A clear vision is essential to the success of a software project. 4. What You Produce, Others Will Consume. Always specify, design, and implement by keeping in mind that someone else will have to understand what you are doing. §.Be open to the future. Assystem with a long lifetime has more value. Systems must be ready to adapt changes. 6. Plan ahead for reuse The reuse of code and designs has a major benefit of using object-oriented technologies. 7. Think! Placing clear, complete thought before action almost always produces better results. List ofall core principles- 4 M ©) | Describe RNIMM strategy with example. aM Ans |) RMMM Plan 1M for : introduction to > tis part of the software development plan or a separate document risk and 3 M > ‘The RMMM plan documents all work executed as a part of risk analysis and used] ff MMM phon example by the project manager as a part of the overall project plan. Page No: 15 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (SOME - 27001 - 2013 Certified) © The sk mitigation and monitoring start aller the project is Started and (he documentation of RMMM is completed Risk: Computer Crash Mitigation: The cost associated with a computer crash resulting in the loss of data is crucial, A computer crash itself is not crucial, but rather the loss of data. A loss of data will result in not being able to deliver the product to the customer. This will result in not receiving a letter of acceptance from the customer. Without the letter of acceptance, the group will receive a failing grade for the course. As a result, the organization is taking steps to make multiple backup copies of the software in development and all documentation associnted with it, in multiple locations. « Monitoring: When working on the product or documentation, the staff members should always be aware of the stability of the computing environment they're working in. Any changes in the stability of the environment should be recognized and taken seriously. - Management: The lack of a stable-computing environment is extremely hazardous to a software development team. In the event that the computing environment is found unstable, the development team should cease work on that system until the environment is made stable again or should move to a system that is stable and continue working there Page No: 16 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘ Autonomous) UISOMEC 2700 « 2013 Certified) Si Ss ohare csarprorents scheebitec! fat roam wil fot, be ‘appheance the mmaining Rchcnality sal herve te ba custom Schteadition |: Certain reusable semponente were devalaped by thinl party with no knowleclge of internal design standards Subcondition 2: Yhe design standard lor component interfaces haw not bese cliched ond may not conkerm to-certein exieing resnanhle components 2 Pe sh oe ‘comider comsporteetsruchire when deciding on interlace protocol 2° Chath 0 chtermine mamber of components in aubsconeliion 3 cotmpory, check eects tha ara won, ore a Disalon veroo sheer Jeadiparal seeoarene st Shaan wit edgy ithe 5/12/02: Minigition steps iniietad ee Soe ete @)_ | Describe following project cost estimation approaches IM i) Heuristic ii) Empirical ‘Ans | Project cost estimation approaches TM for Heuristic and i) Heuristic 2M for Empirical 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 determined by substituting the value of the basic parameters in the mathematical expression, Different heuristic estimation models « ided into the following two classes: single variable model and the multi variable model Single variable estimation models provide a means to estimate the desired characteristics of a problem, using some previously estimated basic (independent) characteristic of the software product such as its size, A single variable estimation mode! takes the following form: Estimated Parameter = ¢) * 14) In the above expression, ¢ is the characteristic of the software which has already been estimated (independent variable), Estimated Parameter is the dependent parameter to be estimated. The dependent parameters to be estimated could be effort, project duration, staff size. ete. cl and dl are constants. The values of the constants ¢l and Page No: 17 | 27 az MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION ‘Autanomou) = USOMEC + 27001 2018 Certiied) di are usually determined using data collected from past projects (historical data), The basic COCOMO model is an example of single variable cost estimation model. A multivariable cost estimation model takes the following form; Estimated Resource = 61" ey") #e2 "eH. Where e1, ¢2, .., are the basic (independent) characteristics of the software already estimated, and c1,€2. dl, d2, ... are constants. ii) Empirical Empirical estimation is a technique or model in which empirically derived formulae are used for predicting the data that are a required and essential part of the software project planning step These techniques are usually based on the data that is collected previously from a project and based on some guesses, prior experience with the development of similar types of| projects, and assumptions. Tt uses the size of the software to estimate the effort, In this technique, an educated guess of project parameters is made, Hence, these models are based on common sense. However, as there are many activities involved in empirical estimation techniques, this technique is formalized. ©) | Explain GANTT chart and i’s application for project tracking with an aM example. ‘Ans | GANTT Charts Description and When creating software project schedule, we begin with a set of tasks. [automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration and start date are then input for cach task. in addition, tasks may be assigned to specific individuals. Because of this input, a time-line chart, also called a Gantt chart is generated. A timeline chart can be developed for the entire project. The figure below depicts a part of a software project schedule that emphasizes scoping task for a word-processing (WP) software product All project tasks are listed in the lefl-hand column, The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamond indicates milestones. Once the information necessary for the generation of a time-line chart has been input, many software project scheduling tools produce project tables — a tabular listing of all project tasks, their planned and actual start and end dates, and a variety of related information. Used in conjunction with the time-line chart, project tables enable to track Example- 3 M Application- IM Page No: 18 | 27 MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION nena) 0 USOMEC - 27001 = 2013 Certiied) Application of Gantt Chant > The sheer simplicity and ease-of-access of all relevant information make Gantt charts an ideal choice for teams to tse for organizing their schedules. Due to this, Gantt charts are widely used in project management, IT, and development teams. Apart from them, marketing, engineering, product launch, manufacturing teams can also uuse Gantt charts to get an overview of how things are rolling on the wark front. Attempt any TWO of the following: 2M ‘Sketch use-case diagram for library management with minimum four use- ‘cases and two actors, 6M Page No: 19 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘Atmos (ISOMEC - 27001 - 2013 Certified) ‘Ans’ Use case diagram: 4 Valid Use Cases— 4M, 2 valid actors : 2M=0M b) | Differentiate between white box and black box testing. (Any six point) 6M ‘Ans Differences between white Sr. | Black Box Testing White Box Testing box and black No, box testing any T | iis a way of software testing in Tris a way of testing the software in we — which the internal structure orthe —_| which the tester has knowledge about each program or the code is hidden and the internal structure or the code or the nothing is known about it, program of the software. 2 | Implementation of code is not Code implementation is necessary for needed for black box testing. white box testing, 3 | tis mostly done by software testers, | 1 mostly done by software developers. 4 | Noknowledge of implementation is_ | Knowledge of implementation is needed, required, Page No: 20 | 27 MAHLARASHTEEA STATE BOARD OF TECHNICAL EDUCATION ‘Autonernous) (ISOMEC- 27001 - 3013 Certified) It can be referred to as outer or Itis the inner or the internal software external software testing. testing. It is a functional test of the software. | It is a structural test of the software, This also called as closed box Trisalso called as transparent box / ‘opaque box testing clear box testing, ©) | Describe a cocomo and cocomo-II models. 6M ‘Ans | COCOMO: ‘COCACO del COCOMO is a hierarchy of cost estimation models it includes basic, intermediate and description 74 detailed sub model. M,COCOMO I model 1. Basic Model The basic model aims at estimating, in a quick and rough fashion, most of the small to medium sized software projects. Three modes of software development are considered in this model: Organic: A small team of experienced developers develops software in a very familiar environment Embedded: The project has tight constraints, which might be related to the target processor, Semidetached: It is an intermediate mode between the organic mode and embedded m Depending on the problem at hand, the team might include a mixture of experienced and less experienced people with only a recent history of working together The Basic COCOMO equations take the form: *(KLOC)* OEY D = Deployment time SS = staff size P productivity ab .bb ,cb db = Coefficients 2. Intermediate Model In the Intermediate model Bochm introduced an additional set of 15 predictors called cost drivers in the intermediate model to take account of the software development environment, Cost drivers are used to adjust the nominal cost of’ a project to the actual project environment, hence increasing the accuracy of the estimate. The cost drivers are grouped into 4 categories:~ 1. Product attributes a. Required software reliability (RELY) b. Database size (DATA) c. Product complexity (CPLX) 2. Computer attributes a. Execution time constraint (TIME) description : 3 M, Total - 6M. Page No: 21 | 27 MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION exams usomec TUN ~ 2913 Certified) b. Main store constraint (STOR) ¢. Virtual machine volatility (VIRT) d. Computer turnaround time (TURN) 3. Personne! attributes a. Analyst capability (ACAP) b. Application experience (AEXP) ¢. Programmer capability (PCAP) i Virtual machine experience (VEXP) e. Programming Language experience (LEXP) 4. Project attributes a. Morden programming practices (MODP) b. Use of software tool (TOOL) ¢, Required development schedule (SCED) 3. Detailed COCOMO A large amount of work is done by Bochm to capture all significant aspects of a software development. It offers a means for processing all the project characteristics to construct a software estimate. A software development is carried out in four successive phases:- 1, Plan! requirements: This is the first phase of the development cycle. The requirement is analyzed, the product plan is set up and a full product specification is generated. This phase consumes from 6% to 8% of the effort and 10% to 40% of the development time. 2. Product Design: The second phase of the COCOMO development cycle is concerned with the determination of the product architecture and the specification of the subsystem. This phase requires from 16% to 18% of the nominal effort and can last from 19% to 38% of the development time, 3. Programming: The third phase of the COCOMO development cycle is divided into two sub phases: detailed design and code/unit test. This phase requires from 48% to 68% of the effort and lasts from 24% to 64% of the development time. 4. Integrationtest: This phase of the COCOMO development cy delivery. This mainly consist of putting the tested parts together and then testing the final product this phase requires from 16% to 34% of the nominal effort and can last from 18% to 34% of the development time. occurs before COCOMO II: COCOMO-I is the revised version of the original Cocomo (Constructive Cost Model) and is developed at University of Southern California. It is the model that allows one to estimate the cost, effort and schedule when planning a new software development activity, COCOMO II provides the following three-stage series of models for estimation of Application Generator, System Integration, and Infrastructure software projects: COCOMO II has three different models: 1. The Application Composition Model : : + Supports prototyping projects and projects where there is extensive reuse. Page No: 22 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘Nttonomens} MISOAEC - 27001 - 2013 Cernitiedy + Based on standard estimates of developer productivity in Application (object) points ‘month. * Takes CASE tool use into account Formula is —PM =( NAP * (1 - “oreuse/100) )/ PROD. ~ PM is the effort in person-months, NAP is the number of application points and PROD is the productivity 2. Early design model + Estimates can be made after the requirements have been agreed. + Based on a standard formula for algorithmic models -PM=A * SizeB xM where ~ M = PERS * RCPX * RUSE * PDIF * PREX * FCIL = SCED; ~ A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity. 3._ The reuse model * Takes into account account black-box code that is reused without change and code that has to be adapted to integrate it with new code. * There are two versions: ~Black-box reuse where code is not modified. An effort estimate (PM) is computed. — White-box reuse where code is modified, A size estimate equivalent to the number of lines of new source code is computed. This then adjusts the size estimate for new code. Reuse model estimates + For generated code PM =(ASLOC * AT/100)/ATPROD ~ ASLOC is the number of lines of generated code ~AT is the percentage of code automuativally generated. — ATPROD is the productivity of engineers in integrating this code. Reuse model also estimates When code has to be understood and integrated: ESLOC = ASLOC * (1-AT/100) AT/L00) * AAM. ~ASLOC and AT as before. ~— AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of | reuse decision making. Altempt any TWO of the following: 2M Draw neat labelled diagram of translation of requirement model into design mode! and explain it with details. 6M Ans Diagram of translation of requirement model into design model Tabeled diagram of translation of Page No; 23 | 27 MAILARASHTRA STATE BOARD OF TECHNICAL EDUCATION wtamomoas (ISOMEC - 27001 - 2013 Certined) Each of the clements of the requirements model provides information that is necessary to create the four design models required for a complete specification of design. The flow of information during software design is illustrated in Figure above The requirements model, manifested by scenario-based, class-based, low-priented, and behavioral elements, feed the design task, Using design notation and design methods, design produces a data/class design, an architectural design, an interface design. and a component design. The datwelass design requirement model into design model : 3 Mand shall be given marks ): 3M, total 6M Page No: 24 | 27 a) -MAIARASIITIA STATE HOARD OF TECHNICAL EDUCATION (ISOAEC - 27001 - 2013 Certified) Transforms class models into design class realizations and the requisite dala structures required to implement the software. The objects and relationships defined in the CRC diagram and the detailed data content depicted by class attributes and other notation provide the basis for the data design action. Part of class design may occur in conjunction with the design of software architecture More detailed class design occurs as each software component is designed. ‘The architectural design defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented. The architectural design representation—the framework of a computer-based system—is derived from the requirements model. The interface design describes how the software communicates with systems that interoperate with it, and with humans who use it. An interface implics a flow of information (c.2., data and/or control) and a specific type of behavior. Therefore, usage scenarios and behavioral models provide much of the information required for interface design. The component-level design transforms structural elements of the software architecture into a procedural description of software components. Information obiained from the class- based models, flow models, and behavioral models serve as the basis for component design, During design you make decisions that will ultimately affect the success of software construction and, as important, the ease with which software can be maintained. b) | Deseribe CMMI. Give significance of each level. 6M ‘Ans | SEI CMMI is a process improvement approach that provides organizations with the] Description of essential elements of effective processes, CMMI: | M: + CMMI can help you make decisions about your process improvement plans. CMM stands for Capability Maturity Model. + Focuses on elements of essential practices and processes from various bodies of knowledge. * Describes common sense, efficient, proven ways of doing business (which you should already be doing) - not a radical new approach. + CMM is a method to evaluate and measure the maturity of the software development process of an organization. * CMM measures the maturity of the software development process om a scale of | to 5. Capability Level 0; Incomplete An “incomplete process” is a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process ‘This is tantamount to Maturity Level | in the staged representation. Capability Level 1: Performed A Capability Level 1 process is a process that is expected to perform all of the Capability Level 1 specific and generic practices. Performance may not be stable and may not meet specific objectives such as quality, cost, and schedule, but useful work can be done. This is only a start, or baby-step, in process improvement. It means that you are doing something but you cannot prove that it is really working for you. significance of all levels :5 M. total 6 M Page No: 25 | 27 ‘itis MAHARASHTRA STATE HOARD OF TECHNICAL EDUCATION, ‘Auton uso = 27001 = 2013 Certitied) Capability Level 2: Managed A managed process is planned, performed, monitored, and controlled for individual projects, groups, or stand-alone processes to achieve a given purpose, Managing the process achieves both the model abjectives for the process as well as other objectives, such as cost, schedule, and quality. ‘As the title of this level indicates, you are actively managing the way things are done in your organization. ‘You have some metrics that are consistently collected and applied to your management approach. Capability Level 3: Defined A capability level 3 process is characterized as a "defined process." ‘A defined process is a managed (capability level 2) process that is tailored from the organization's set of standard processes according to the organization's tailoring guidelines, and contributes work products. measures. and other process-improvement information to the organizational process assets. Capability Level 4: Quantitatively Managed ‘A capability level 4 process is characterized as a "quantitatively managed process.” A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques, Quantitative objectives for quality and process performance are established and used as criteria in managing the process. Quality and process performance is understood in statistical terms and is managed throughout the life of the process. Capability Level 5: Optimizing ‘An optimizing process is a quanti understanding of the common causes of proce: It focuses on continually improving proce: innovative improvements, Both the defined processes and the organization's set of standard processes are the targets of improvement activities. ly managed process that is improved, based on an variation inherent to the process, performance through both incremental and ©) _| Identify and enlist requirement for given modules of employee management 6M software ; i) Employee detail ii) Employee salary iii) Employee performance. ‘Ans | |. Employee detail Tdentification and enlisting ii, Employee salary requirements: " for 3 modules iii, Employee performance Piet 6M This is with perspective of employee management software Requirements for following modules will be as Page No: 26 | 27 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION ‘.utoouoast Aasoaee : 27001 2013 Certied) T. Employee details a. Getting information about the customer b, Updation of employee details (department, change of address, emp_code ete.) ¢. Assignment of tasks, duties and responsibilities. d. Recording of employee attendance. i, Employee salary a. Salary calculation b, Allowances, special bonus calculation and approval c, Tax statement/certificate 4, Apply loanapprovals ili, Performance a. Recording annual performance b. Details about parameters for performance appraisal ¢. Analysis performance and determining hike in payment. Page No: 27 | 27

You might also like