Software Project Management (MB341IT) Question Paper: July 2008, Exams of Software Project Management

Previously solved sample paper July 2008

Typology: Exams

2018/2019

Uploaded on 09/18/2019

anupam-dua
anupam-dua 🇮🇳

11 documents

1 / 19

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Question Paper
Software Project Management (MB341IT) : July 2008
Section A : Basic Concepts (30 Marks)
This section consists of questions with serial number 1 - 30.
Answer all questions.
Each question carries one mark.
Maximum time for answering Section A is 30 Minutes.
1. If the structural complexity S(i) is 0.61 and data complexity D(i) of module i is 0.39, then system complexity
C(i) is
(a)
1
(b)
0.22
(c)
0.2379
(d)
1.5641
(e)
1.6393.
<Answe
r>
2. Integrity is one of the measures of software quality. The integrity of the system is defined as:
(a)
Integrity =
(b)
Integrity =
(c)
Integrity =
(d)
Integrity =
(e)
Integrity =.
<Answe
r>
3. In concurrent development model, if customer indicates that changes in requirements, then the modeling activity
moves to
(a)
Awaiting changes state
(b)
Under development state
<Answe
r>
1
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13

Partial preview of the text

Download Software Project Management (MB341IT) Question Paper: July 2008 and more Exams Software Project Management in PDF only on Docsity!

Question Paper

Software Project Management (MB341IT) : July 2008

Section A : Basic Concepts (30 Marks)

This section consists of questions with serial number 1 - 30. Answer all questions. Each question carries one mark. Maximum time for answering Section A is 30 Minutes.

1. If the structural complexity S(i) is 0.61 and data complexity D(i) of module i is 0.39, then system complexity C(i) is

(a) 1

(b) 0.

(c) 0.

(d) 1.

(e) 1.6393.

2. Integrity is one of the measures of software quality. The integrity of the system is defined as:

(a) Integrity =

(b) Integrity =

(c) Integrity =

(d) Integrity =

(e) Integrity =.

3. In concurrent development model, if customer indicates that changes in requirements, then the modeling activity moves to

(a) Awaiting changes state

(b) Under development state

(c) Under revision state

(d) None state

(e) Under review state.

4. ISO 9001:2000 has adopted a “Plan-Do-Check-Act” (PDCA) cycle which is applied to the quality management elements of a software project. Within a software context, the term “Check”

(a) Establishes the process objectives, activities and tasks necessary to achieve high quality software and resultant customer satisfaction

(b) Monitors and measures the process to ensure that all requirements established for quality management have been achieved

(c) Implements the software process

(d) Initiates software process improvement activities that continually work to improve the process

(e) Eliminates the process objectives, activities and tasks which are not necessary to achieve high quality software.

5. There are many LOC-oriented estimation models proposed in the literature. According to Walston-Felix model, the Effort (E) is

(a)

(b) 5.5 + 0.

(c)

(d)

(e) 4.2.

Both (II) and (III) above

(c) Both (III) and (IV) above

(d) (I), (II) and (III) above

(e) (II), (III) and (IV) above.

9. In which of the following framework activities of Personal Software Process (PSP) model, component level design is refined and reviewed?

(a) Planning

(b) High-level design

(c) High-level design review

(d) Development

(e) Postmortem.

Which of the following is false about Personal Software Process (PSP) model?

(a) PSP emphasizes personal measurement of both the work product that is produced and the resultant quality of the work product

(b) PSP makes practitioner responsible for project planning and empowers the practitioner to control the quality of all software work products that are developed

(c) PSP needs high training costs

(d) PSP will show managers how to coach and motivate their teams and how to help them sustain peak performance

(e) Training required for using PSP is relatively lengthy.

Which of the following is not a framework activity (in terms of terminology) of Team Software Process (TSP) model?

(a) Launch

(b) High-level design

(c) High-level design review

(d) Implementation

(e) Postmortem.

Which of the following debugging strategies introduces the concept of Binary partitioning?

I. Brute force. II. Back tracking. III. Cause elimination.

(a) Only (I) above

(b) Only (II) above

(c) Only (III) above

(d) Both (II) and (III) above

(e) All (I), (II) and (III) above.

Which of the following statements is/are false about RAD model?

I. RAD model is an evolutionary model. II. In RAD model, rapid development is achieved by using a component based construction approach. III. RAD model may not be appropriate when technical risks are high.

(a) Only (I) above

(b) Only (II) above

(c) Both (I) and (III) above

(b) Controllability

(c) Stability

(d) Decomposability

(e) Observability.

Putnam-Norden-Rayleigh curve provides an indication of the relationship between effort applied and delivery time for a software project. If time to complete the project is t, development effort is E and productivity parameter is P. Which of the following is the expression for the number of lines of code (L)?

(a)

(b)

(c)

(d)

(e) .

If the probability of occurrence for a risk is 40 percent, cost to the project if that risk occurs is $25,000, then Risk Exposure (RE) is

(a) $

(b) $10,

(c) $15,

(d) $41,

(e) $62,500.

If is the number of modules in the current release, is the number of modules in the current release that have been changed, is the number of modules in the current release that have been added, is the number of modules from the preceding release that were deleted in the current release, then Software Maturity Index (SMI) is computed as:

(a)

(b)

(c)

(d)

(e) .

In a project, if the percentage of software availability is 60, mean-time-to-failure is 40 then what is the mean- time-to-repair?

(a) 16.

(b) 60.

(c) 26.

(d) 75.

(e) 80.66.

Which of the following statements is true about Security testing?

(a) Security testing focuses verification effort on the smallest unit of software design

(b) Security testing is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing

(c) Security testing verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration

(d) Security testing executes a system in a manner that demands resources in abnormal quantity, frequency

Practitioners

(d) Customers

(e) End-users.

Using white-box testing methods, the software engineer can derive test cases that

I. Guarantee that all independent paths within a module have been exercised atleast once. II. Exercise all logical decisions on their true and false sides. III. Execute all loops at their boundaries and within their operational bounds. IV. Exercise internal data structures to ensure their validity.

(a) Both (I) and (II) above

(b) Both (III) and (IV) above

(c) (I), (II) and (IV) above

(d) (II), (III) and (IV) above

(e) All (I), (II), (III) and (IV) above.

Boehm introduced a hierarchy of software estimation models bearing the name COCOMO. COCOMO is an acronym for

(a) Comprehensive Construct Model

(b) Complex Construct Model

(c) Component Construct Model

(d) Constructive Cost Model

(e) Comprehensive Cost Model.

Which of the following software makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis?

(a)

Engineering/scientific software

(b) System software

(c) Embedded software

(d) Product-line software

(e) Artificial intelligence software.

Loop Testing comes under which testing method?

(a) White Box

(b) Black Box

(c) Green Box

(d) Yellow Box

(e) Blue Box.

Putam and Myers suggest different approaches to the software sizing problem. Which of the following is not an approach to software sizing problem?

(a) Fuzzy logic sizing

(b) Function point sizing

(c) Knock off balance sizing

(d) Standard component sizing

(e) Change sizing.

END OF SECTION B

This section consists of questions with serial number 7 - 8. Answer all questions. Marks are indicated against each question. Do not spend more than 25 - 30 minutes on Section C.

END OF SECTION C

END OF QUESTION PAPER

Suggested Answers

Software Project Management (MB341IT) : July 2008

Section A : Basic Concepts

Answe r

Reason

1. a If S(i) is the structural complexity and D(i) is the data complexity of module i, then system complexity C(i) is +. So, C(i) is 1.

< TOP >

2. c The integrity of the system is defined as:. < TOP > 3. a In concurrent development model, if customer indicates that changes in requirements then the modeling activity moves from under development state to awaiting changes state.

< TOP >

4. b ISO 9001:2000 has adopted a “Plan-Do-Check-Act” (PDCA) cycle which is applied to the quality management elements of a software project. Within a software context, the term “Check” monitors and measures the process to ensure that all requirements established for quality management have been achieved.

< TOP >

5. d According to Walston-Felix model, Effort (E) is 5.2. < TOP > 6. c Software project tracking and control allows the software team to assess progress against the project plan and take necessary action to maintain schedule.

< TOP >

7. C Tools, methods, process, quality focus are the layers of software engineering. Information, status are not layers of software engineering.

< TOP >

8. b Stage pattern define a framework activity for the process and Phase pattern define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature

< TOP >

9. d In Development activity, the component level design is refined and reviewed. < TOP > 10. D Personal Software Process (PSP) model will not show managers how to coach and motivate their teams and how to help them sustain peak performance. Team Software Process (TSP) will show managers how to coach and motivate their teams and how to help them sustain peak performance.

< TOP >

11. c High-level design review is not a collection of related tasks that produces major work product of Team Software Process (TSP) model.

< TOP >

12. c Cause elimination is the Debugging strategy that introduces the concept of Binary partitioning.

< TOP >

13. a RAD model is high-speed adaptation of the water fall model, in which rapid development is achieved by using a component based construction approach. RAD model may not be appropriate when technical risks are high. RAD model is an incremental process model.

< TOP >

14. b Prototype model, Concurrent Development model and Spiral model comes under evolutionary process models. Incremental model is an incremental process model.

< TOP >

15. d Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency.

< TOP >

16. c Stability: “The fewer the changes, the fewer the disruptions to testing”. < TOP > 17. a Number of lines of code (L) :. < TOP > 18. b Risk Exposure (RE) is defined as:

RE = P C = 0.4025,000 = $10000.

< TOP >

19. b Software Maturity Index (SMI) is computed as:. < TOP > 20. c Percentage of software availability =

< TOP >

21. c Security testing verifies that protection mechanisms built into a system will, in fact, protect it from improper penetration Unit testing focuses verification effort on the smallest unit of software design. Integration testing is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency or volume Recovery testing forces the software to fail in a variety of ways and verifies that recovery is properly performed.

< TOP >

achieve a maturity level, the specific goals and practices associated with a set of process areas must be achieved. The relationship between maturity levels and process areas is shown in the Figure.

2. The main function of the SQA group is to assist the software team in achieving a high quality end product. These activities are performed (or facilitated) by an independent SQA group. 1. First of all they Prepares an SQA plan for a project: The plan is developed during project planning and is reviewed by all stakeholders. The plan identifies evaluations to be performed, audits and reviews to be performed standards that are applicable to the project, procedures for error reporting and tracking, documents to be produced by the SQA group and amount of feedback provided to the software project team. 2. After words they participate in the development of the project’s software process description. The software team selects a process for the work to be performed. The SQA group reviews the process description for compliance with organizational policy internal software standards, externally imposed standards and other parts of the software project plan. 3. They Reviews software engineering activities to verify compliance with those defined as part of the software process. This is the major step in SQA activity .In this they will check complete ness and correctness of the project. The white box testing is done by the developers. (The testing which is done at design phase is called white box testing). The people which are involve in the SQA group whether the modules involved in the project are user friendly are not .This will done by usability test. The SQA group reviews selected work product, identifies, documents, and tracks deviations; verifies that corrections have been made; and periodically reports the results of its work to the project manager. 4. After words they ensure that deviations in software work and work products are documented and handled according to a documented procedure or not (Deviations may be encountered in the project plan, process description, applicable standards, or technical work products). 5. Finally the Noncompliance items are tracked until they are resolved and reports to senior management.

< TOP >

3. If I am the software tester at Symphosis, the following are the system testing techniques that i perform in order to check the performance of the project: System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Although each test has a different pur 0 0 1 F pose, all work to verify that system elements have been properly integrated and per 0 0 1 F form allocated functions. Stress tests are designed to confront programs with abnormal situations. Stress testing executes the application in a manner that demands resources in abnormal quantity, frequency, or volume. For example, (1) special tests may be designed that generate ten interrupts per second, when one or two is the average rate, (2) input data rates may be increased by an order of magnitude to determine how input func 0 0 1 F tions will respond, (3) test cases that require maximum memory or other resources are executed, (4) test cases that may cause memory management problems are de 0 0 1 F signed, (5) test cases that may cause excessive hunting for disk-resident data are cre 0 0 1 F ated. Essentially, i attempt to overwhelm the program. A variation of stress testing is a technique called sensitivity testing. In some situa 0 0 1 F tions (the most common occur in mathematical algorithms), a very small range of data contained within the bounds of valid data for a program may cause extreme and even erroneous processing or profound performance degradation. Sensitivity testing attempts to uncover data combinations within valid input classes that may cause in 0 0 1 F stability or improper processing. I go for the Performance testing design to test the run-time performance of software within the context of an in 0 0 1 F tegrated system. Performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module may be as 0 0 1 F sessed as tests are conducted. However, it is not until all system elements are fully integrated that the true performance of a system can be ascertained. Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation. That is, it is often necessary to measure resource utilization (e.g., processor cycles) in an exacting fashion. External in 0 0 1 F strumentation can monitor execution intervals, log events (e.g., interrupts) as they occur, and sample machine states on a regular basis. By instrumenting a system, i can uncover situations that lead to degradation and possible system failure.

< TOP >

4. Depending on the use cases in SRS (Software Requirement Specification), test engineers are preparing test cases for functional, performance, security test. If I am the software tester at Symphosis, I will write the following test cases for usability testing. TestCase 1: Spelling check: Whether all menu items etc. are correctly spelled or not. TestCase 2: Graphics check: Alignment, font, style, size (width & height), color, labels start with capital letter, Gap between every two objects etc. are correctly maintained or not. Testcase 3: Whether project is showing meaningful error messages. Testcase 4: Whether the data is accurately displayed or not. Testcase 5: Accuracy of data in the database as the result of user input is maintained or not. For example, if user enters the value in the form say 10.768 but it is rounded and stored in the database as 10.77. If we want to display that value it will give 10.77 instead of 10.768.

< TOP >

Testcase 6: Whether the project is displaying meaningful help messages or not. Testcase 1 to testcase 5 are used for user interface testing and testcase 6 is used for manual support testing.

5. The prototyping paradigm assists the software engineer and the customer to better understand what is to be built when requirements are fuzzy. The prototyping paradigm begins with communication. The software engineer and customer meet and define the overall objectives for the software, iden 0 0 1 F tify whatever requirements are known, and outline areas where further definition is mandatory. A Prototyping iteration is planned quickly and modeling (in the form of a "quick design") occurs. The quick design focuses on a representation of those as 0 0 1 F pects of the software that will be visible to the customer/end-user (e.g., human in 0 0 1 F terface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and then evaluated by the customer/user. Feedback is used to refine requirements for the software. Iteration occurs as the pro 0 0 1 F totype is tuned to satisfy the needs of the customer, while at the same time en 0 0 1 F abling the developer to better understand what needs to be done. Ideally, the prototype serves as a mechanism for identifying software require 0 0 1 F ments. If a working prototype is built, the developer attempts to make use of exist 0 0 1 F ing program fragments or applies tools (e.g., report generators, window managers. etc.) that enable working programs to be generated quickly. It is true that both customers and developers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. Yet, prototyping can be problematic for the following reasons: 1. The customer sees what appears to be a working version of the software, un0 0 1 F aware that the prototype is held together "with chewing gum and baling wire," unaware that in the rush to get it working we haven't considered overall soft 0 0 1 F ware quality or long-term maintainability. When informed that the product must be rebuilt so that high-levels of quality can be maintained, the customer cries foul and demands that "a few fixes" be applied to make the prototype a working product. Too often, software development management relents. 2. The developer often makes implementation compromises in order to get a prototype working quickly. An inappropriate operating system or program 0 0 1 F ming language may be used simply because it is available and known; an in 0 0 1 F efficient algorithm may be implemented simply to demonstrate capability. After a time, the developer may become comfortable with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system. Although problems can occur, prototyping can be an effective paradigm for soft 0 0 1 F ware engineering. The key is to define the rules of the game at the beginning; that is, the customer and developer must both agree that the prototype is built to serve as a mechanism for defining requirements.

< TOP >

6. The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Cost of quality studies are conducted to provide a base line for the current cost of quality, identify opportunities for reducing the cost of quality, and provide a normalized basis of comparisons. Quality costs may be divided into costs associated with prevention, appraisal, and failure. If I am the project manager in ShinTech, I consider the above mentioned costs for getting a cost effective solution. Prevention costs which include quality planning, formal technical interviews, test equipment, and training. Appraisal costs include activities to gain insight into product condition the “first time through” each process. Examples of appraisal costs include in-process and interprocess inspection, equipment calibration and maintenance, and testing. Failure costs are those that would disappear if no defects appeared before shipping the product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include rework, repair, and failure mode analysis .External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are complaint resolution, product return and replacement, help line support, and warranty work.

< TOP >

Section C: Applied Theory

7. A typical CM operational scenario involves a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the software engineers who are responsible for developing and maintain 0 0 1 F ing the software product, and the customer who uses the product. In the scenario, assume that the product is a small one involving about 15,000 lines of code being de 0 0 1 F veloped by a team of six people. At the operational level, the scenario involves various roles and tasks. For the project manager, the goal is to ensure that the product is developed within a certain time frame. Hence, the manager monitors the progress of development and recog 0 0 1 F nizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system. The goals of the configuration manager are to ensure that procedures and poli 0 0 1 F cies for creating, changing, and testing of code are followed, as well as to make in 0 0 1 F formation about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating them (via a Change Control Board that is re 0 0 1 F sponsible for approving

< TOP >

order prioritization. Risk impact and probability have a distinct influence on management concern. A risk factor that has a high impact but a very low probability of occurrence should not absorb a significant amount of management time. However, high-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow. All risks that lie above the cutoff line must be managed.

Assessing Risk Impact

Returning once more to the risk analysis approach proposed by the U.S Air Force, the following steps are recommended to determine the overall consequences of a risk:

  1. Determine the average probability of occurrence value for each risk component.
  2. Using impact assessment table determine the impact for each component based on the criteria shown.
  3. Complete the risk table and analyze the results as described in the preceding sections.

The overall risk exposure, RE, is determined using the following relationship:

RE = P x C

Where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.

< TOP OF THE DOCUMENT >