52530-20225-0901 ITS-SPM (MB3G2IT)

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

1/18

Page 1 of18

Question Paper

Software Project Management (MB3G2IT): January 2009

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. The prototyping model of software development is

(a) A reasonable approach when requirements are well defined(b) A useful approach when a customer cannot define requirements clearly(c) The best approach to use for projects with large development teams(d) A risky approach that rarely produces a meaningful product(e) Another name for component-based development approach.

2. Which of the following statements is/are false about the component-based development model?I. The component-based development model incorporates many of the characteristics of the spiral model.II. The component-based development model does not compose applications from prepackaged software

components.III. The component-based development model leads to software reuse and reusability provides software

engineers with a number of measurable benefits.

(a) Only (II) above(b) Only (III) above(c) Both (I) and (II) above(d) Both (I) and (III) above(e) Both (II) and (III) above.

3. Which of the following statements is/are true about the formal methods model?

I. The formal methods model encompasses a set of activities that leads to formal mathematical specificationof computer software.

II. Formal methods model enable a software engineer to specify, develop and verify computer-based systemby applying a rigorous, mathematical notation.

III. The development of formal methods model is currently quite-time consuming and expensive.

(a) Only (I) above(b) Only (II) above(c) Only (III) above(d) Both (I) and (II) above(e) All (I), (II) and (III) above.

4. Constantine suggests four organizational paradigms for software engineering teams. Which of the following

statements is/are false about open paradigm?

I. Heavy communication and consensus-based decision making are the trade marks of open paradigm teams.II. Open paradigm team structures are well suited to the solution of complex problems but may not perform as

efficiently as other teams.III. Open paradigm relies on the natural compartmentalization of a problem and organizes team members to

work on pieces of the problem with little active communication among themselves.

(a) Only (I) above(b) Only (II) above(c) Only (III) above(d) Both (I) and (II) above(e) Both (II) and (III) above.

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

2/18

Page 2 of18

5. Project management activity encompasses

I. Measurement and metrics.II. Estimation and scheduling.III. Risk analysis.IV. Tracking and control.

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

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

6. FP-based estimation techniques require problem decomposition based on

(a) Information domain values(b) Project schedule(c) Software functions(d) Process activities

(e) Hardware functions.

7. Which of the following statements is/are false about the Software Project Metrics?

I. Software project metrics are used for strategic purposes.II. Software project metrics are used to assess product quality on an ongoing basis and, when necessary,

modify the technical approach to improve quality.III. Software project metrics are used to minimize the development schedule by making the adjustments

necessary to avoid delays and mitigate potential problems and risks.

(a) Only (I) above(b) Only (II) above(c) Only (III) above(d) Both (I) and (II) above(e) Both (II) and (III) above.

8. The formula for Defect Removal Efficiency (DRE) is

(a) E/(E-D)(b) (E * D)/(E+D)(c) (E+D)/E(d) E/(E+D)(e) 2E/ (E+D).

9. In the basis path testing, if the flow graph contains 4 regions and 2 nodes, then the number of edges are

(a) 2(b) 3(c) 4(d) 5(e) 1.

10.Which of the following statements is/are true about Outsourcing?

I. The decision to outsource can be either strategic or tactical.II. Outsourcing improves business performance and profitability.III. Outsourcing can be viewed more generally as any activity that leads to the acquisition of software or

software components from a source outside the software engineering organization.

(a) Only (I) above(b) Only (II) above(c) Only (III) above(d) Both (I) and (II) above(e) All (I), (II) and (III) above.

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

3/18

Page 3 of18

11.Which of the following risks identify the potential design, implementation, interface and verification andmaintenance problems?

(a) Project risk(b) Technical risk(c) Strategic risk(d) Market risk

(e) Budget risk.

12.Risk projection is also called as

(a) Risk identification(b) Risk mitigation(c) Risk refinement(d) Risk estimation(e) Risk management.

13.Which of the following is/are the primary objectives of Risk Monitoring?

I. To assess whether predicted risks do, infact, occur.II. To ensure that risk aversion steps defined for the risk are being properly applied.III. To collect information that can be used for future risk analysis.

(a) Only (I) above(b) Both (I) and (II) above(c) Both (I) and (III) above(d) Both (II) and (III) above(e) All (I), (II) and (III) above.

14.Which of the following is not a guiding principle of software project scheduling?

(a) Compartmentalization(b) Market assessment(c) Interdependency(d) Time allocation(e) Effort validation.

15.A web application and its support environment has not been fully fortified against attack. Web engineersestimate that the likelihood of repelling an attack is only 30 percent. The system does not contain sensitive orcontroversial information, so the threat probability is 25 percent. What is the integrity of the web application?

(a) 0.625(b) 0.725(c) 0.825(d) 0.775(e) 0.875.

16.A web engineering team has built an e-commerce web application that contains 145 individual pages. Of thesepages, 65 are dynamic i.e., they are internally generated based on end-user input. What is the customizationindex for this application?

(a) 0.34(b) 0.23(c) 0.52(d) 0.44(e) 0.68.

17.A legacy system has 940 modules. The latest release required that 90 of these modules be changed. In addition,40 new modules were added and 12 old modules were removed. Compute the software maturity index for thesystem.

(a) 0.524(b) 0.628(c) 0.725(d) 0.848

(e) 0.923.

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

4/18

Page 4 of18

18.Quality costs may be divided into costs associated with prevention, appraisal and failure. Failure costs may besubdivided into internal failure costs and external failure costs. Which of the following is included in internalfailure cost?

(a) Complaint resolution(b) Product return and replacement(c) Helpline support

(d) Warranty work(e) Failure mode analysis.

19.Which of the following statements is/are false about Formal Technical Reviews (FTR) in software development?

I. FTR is a software quality control activity performed only by a project leader.II. The FTR is actually a class of reviews that includes walkthroughs, inspections, round robin reviews and

other small group technical assessments of software.III. Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled and

attended.

(a) Only (I) above(b) Only (II) above(c) Only (III) above(d) Both (I) and (II) above

(e) Both (II) and (III) above.

20.To control and manage software configuration items, each should be separately named and then organized usingan object-oriented approach. Two types of objects can be identified namely Basic object and Aggregate objects.Which of the following is an example of Aggregate object?

(a) DesignSpecification(b) Source code for a component(c) Suite of test cases(d) Part of design model(e) Section of requirement specification.

21.Configuration status reporting is a Software Configuration Management (SCM) task that answers number oquestions. Which of the following questions is not included in configuration status reporting?

(a) What happened?(b) Who did it?(c) How it happened?(d) When did it happen?(e) What else will be affected?

22.Which of the following is/are the objectives of Software Configuration Management (SCM) process?

I. To identify all items that collectively defines the software configuration.II. To facilitate the construction of different versions of an application.III. To ensure that software quality is maintained as the configuration evolves over time.

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

(c) Both (I) and (III) above(d) Both (II) and (III) above(e) All (I), (II) and (III) above.

23.By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.

Which of the following characteristics of testability refers to the above statement?

(a) Operability(b) Observability(c) Controllability(d) Decomposability(e) Stability.

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

5/18

Page 5 of18

24.Which of the following is not an example of black box testing technique?

(a) Equivalence partitioning(b) Graph based testing(c) Boundary value analysis(d) Basis path testing(e) Orthogonal array testing.

25.The physical connections between elements of the object-oriented design is called

(a) Complexity(b) Coupling(c) Cohesion(d) Primitiveness(e) Volatility.

26.A strategy for software testing is developed by

I. Project managers.II. Software engineers.III. Testing specialists.


27.Which of the following statements is/are true about Unit testing?

I. Unit testing focuses verification effort on the smallest unit of software design-the software component ormodule.

II. The unit test focuses on the internal processing logic and data structures within the boundaries of thecomponent.

III. Smoke testing is an unit testing approach commonly used when software products are being developed.

(a) Only (I) above

(b) Both (I) and (II) above(c) Both (I) and (III) above(d) Both (II) and (III) above(e) All (I), (II) and (III) above.

28.Which of the following tests executes a system in a manner that demands resources in abnormal quantity,frequency, or volume?

(a) Recovery testing(b) Security testing(c) Stress testing(d) Alpha testing(e) Smoke testing.

29.PERT and CPM provide quantitative tools that allow the software planner toI. Determine the critical path.II. Establish most likely time estimates for individual tasks by applying statistical models.

III. Calculate boundary times that define a time window for a particular task.


7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

6/18

Page 6 of18

30.Which of the following tests is the re-execution of some subset of tests that have already been conducted toensure that changes have not propagated unintended side effects?

(a) Regression testing(b) Integration testing(c) Unit testing(d) Smoke testing

(e) System testing.

END OF SECTION A


Section B : Caselets (50 Marks)

This section consists of questions with serial number 1 7.

Answer all questions.

Marks are indicated against each question.

Detailed explanations should form part of your answer.

Do not spend more than 110 - 120 minutes on Section B.

Caselet 1

Read the case let carefully and answer the following questions:

1. If you are the project manager at TechnoPark Corp., what are the factors you willconsider for accuracy of the software project estimation? ( 5 marks)

2. Critically analyze the objectives of software cost estimation. ( 6 marks)

3. Explain in detail about COCOMO II model that help in accurate software project costestimation.

( 10 marks)

When it comes to developing software, accurate projections are 80% of the challenge.In an effort to improvement its internal budgeting and to further reduce surprises toclients, TechnoPark Corp. went on a quest to find the most successful method ofestimating project cost and duration at the start of each project. In March 2007, amodified COCOMO II model went into operation at TechnoPark Corp. Read on tolearn more on the secrets of effective project estimation as revealed by this successfulU.S.-based outsourcing software development firm. Pre-sales estimation of projectcosts and durations has been a software dilemma that started with the professionitself. Despite all good intentions, Murphy's Law seems to leave everyone room to beunhappy about something. Customers expect accuracy and often are disappointedeven by what software companies consider minor post-sales adjustments. IT projectmanagers dread giving pre-sales estimates because they know that just about every

project has hidden work. The burning question has been, "Is it possible to make anaccurate estimation before the project architecture is built?" The dream answer of"YES" is all the more desirable for outsourcing software firms, such as TechnoParkCorp., because accuracy is also related to trust and reputation, the cornerstonequalities of any outsourcing company. Since the 1970s, there have been manyattempts to attain this dream of accurate pre-sales estimations of projects. Nonehowever have stood up to the rigors of real world challenges and client expectations.Today, TechnoPark Corp. shares its successful experience in the fine art of pre-salesestimation. First, let's review the basis of the estimation process. There are somecommon mistakes and some important issues ignored by many estimators. A commoninitial mistake by software development companies is that they estimate the project asif everything will go "just right." However, it shall not. It is best to estimate thereality of the process, and not some Pollyannaish scenario. Risks ought to be the firstthings analyzed. Any estimation not based on analysis of all probable risks, inconjunction with a company's true capabilities, inevitably will result in an estimation

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

7/18

Page 7 of18

of one's hopes and wishes and not probability. According to the new model byTechnoPark Corp a requirements-based model is the most suitable for pre-salesestimation. The source lines of code (SLOC) model, popular in the 1980s-90s, proveto not be effective coding is significantly more complex and interactive than thenumber of lines of a program. The SLOC model an admittedly still helps withmeasuring the efforts of a completed project, but that doesn't help much withestimating before the coding begins. Requirements-based estimation, on the other

hand, accounts in advance for a project's features, risks and complexity. Analysis ofthe requirements provides an estimator with a more abstract but accurate vision, asthe estimator views the whole project. Requirements-based estimation however is notthe solution either according to the new model by TechnoPark Corp. Pre-salesestimation needs a general understanding of the project but also needs to account forthe details, an area where requirements-based modeling comes up short. Anothergolden rule of estimating reads: Estimate the diapason or range, not the precisefigure. It usually is impossible to count the precise size of efforts and get a correctestimation at the pre-sales phase. It is better to estimate the spectrum of possibilitiesand set aside more precise estimation for detailed examination of the project. In orderto get the diapason, three figures for each task are needed: Worst Case (WC) is themaximum amount of person-hours needed to implement the feature and depicts thesituation when everything is going wrong; Best Case (BC) is an optimistic estimation

providing minimum amount of person-hours; and Most Likely (ML) depicts thesituation which is the most probable in an estimators" assessment, which may beclose to either the worst or best case.

"TechnoPark Corp involved three developers each time estimation is facilitated. Twoof them provide their versions of WC, BC and ML estimations, and the third oneestimates complexity and function points. When counting the diapason of person-hours, we use a number of additional coefficients such as maturity of process,required software reliability, programming language experience, etc. After allnecessary data are entered, automated counting is implemented by the system basedon COCOMO II", explains Victoria Malinovskaya, the estimation facilitator atTechnoPark Corp. COCOMO II, or the Constructive Cost Model, is growing in

popularity as an estimation model. Its first version, COCOMO 81, was introduced in1981 by Barry Boehm. The model is used for estimating the number of person-hours

and person-months it will take to develop a software product. The first version wasbased on SLOC counting. COCOMO II appeared in the 1990s.

The power behind COCOMO II is that it is based on function points instead ofSLOC. A function point is a rough estimate of a unit of delivered functionality of asoftware project. To calculate the number of function points for a software project,one counts all of the user inputs, user outputs, user inquiries, number of files andnumber of external interfaces, dividing them all into simple, average and complexcategories. COCOMO II coefficients and formulas are clear and useful for softwaredevelopment companies, both big and small. The model offered by TechnoPark Corp.is based on COCOMO II with only small fluctuations making it more suitable foroutsourcing software development companies. TechnoPark Corp. has adapted the

COCOMO II approach to client costing with great success.

END OF

CASELET 1

Caselet 2

Read the caselet carefully and answer the following questions:

4. After reading the caselet, critically analyze the elements which influence softwareproject management. ( 8 marks)

5. Sometimes the software projects will fail due to poor vision of the project manager.What are the ideal characteristics that define an effective project manager? Explain. ( 7 marks)

6. Why do software teams fail in any software project? What is the role of projectmanager in the above situation? ( 8 marks)

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

8/18

Page 8 of18

7. To manage a successful software project, we must understand what can go wrong sothat problems can be avoided. If you are the project manager, explain the signs that asoftware project is in jeopardy. ( 6 marks)

Corporate America spends more than $275 billion each year on approximately200,000 application software development projects. A great many of these projectswill fail for lack of skilled project management. The opportunities for project failure

are legion. Large-scale software development efforts today are conducted in complex,distributed IT environments. Development occurs in a fragile matrix of applications,users, customer demands, laws, internal politics, budgets, and project andorganizational dependencies that change constantly. Project managers who lackenterprise-wide multi project planning, control, and tracking tools often find itimpossible to comprehend the system as a whole. Underestimating projectcomplexity and ignoring changing requirements are basic reasons why projects fail.Under these conditions, software project management is almost an oxymoron.

Moreover, software today must not just automate processes; it must create businessvalue, by improving customer service or delivering a competitive advantage. Raisingthe stakes of every large-scale development project is Return On Investment (ROI):Software must have a measurable impact on a company's bottom line.

Finally, urgent multiproject, multisite projects like Y2K, Euro conversion, ERP, andthe rush to the Internet add to the daunting development burden.

For all these reasons, the business case for adapting project management disciplinesto large-scale software development is obvious. It's the implementation that's dicey.

Project management is a process that spans the full life cycle of a project frominception to completion. Its cornerstone tenets are planning, execution, and control ofall resources, tasks, and activities necessary to complete a project. Projectmanagement is not an isolated activity, but rather a team effort. In the end, projectmanagement is about people and process -- how work is being performed. The fourPs of project management are: People, product, process and project.

Most team efforts fail because members are not committed to winning. Why are theYankees the Yankees? Because they have an expectation of winning, not losing. And

they have a repeatable process that mitigates failure.

Project management is gaining traction in IT organizations, and the results areencouraging. Failure rates and costs are down, and project success rates are up. Largecompanies are taking a small approach to project management. Minimization meansscaled down features/functions as well as scope minimization. IT organizations areadopting standard project methodologies or building enterprise-level formal projectmanagement disciplines. This level of proactivity is quite a change.

For years project failure was simply not discussed. And it certainly was not discussedwith the CEO. But 1996 was a watershed year in IT project management, accordingto Standish surveys. We finally came to acknowledge the cost, size, and scope of the

problem. We discovered that there was no silver technology bullet. Technology wasneither the problem nor the solution.

The problem -- and the solution -- lay in people and processes. Valuable lessons hadbeen learned and were being applied to current projects. We learned to develop betterprocesses, to organize teams more effectively, and to deal with problems faster. Wedeveloped smaller, less complex projects. Troubled projects were euthanized quickly.With the advent of professional project managers, we learned to mitigate project riskthrough scope minimization, standard infrastructures, and improved communications.

History is replete with examples ambitious projects that failed. The Standish Groupbelieves that failure is critical to success. Only by examining our mistakes andapplying lessons learned can we stem the tide of project failures and enhance ourorganization's probability of success. Using project management practices, we have

begun to do just that.

The body of the five years of The Standish Group CHAOS research, our infamousreport including detailed information on IT project success and failure, shows decided

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

9/18

Page 9 of18

improvement in IT project management. Project success rates are up across the board,while cost and time overruns are uniformly down.

The best news is that we are learning how to succeed more often. In 1994, only 16%of application development projects met the criteria for success -- completed on time,on budget, and with all the features/functions originally specified. By 1998, 26% of

projects were successful.

END OFCASELET 2

END OF SECTION B

Section C : Applied Theory (20 Marks)

This section consists of questions with serial number 8 - 9.

Answer all questions.

Marks are indicated against each question.

Do not spend more than 25 - 30 minutes on Section C.

8. What is Capability Maturity Model (CMM)? Discuss the various models usedby organizations for the process improvement. ( 10 marks)

9. Explain in detail about spiral software process model with neat diagram. ( 10 marks)

END OF SECTION C

END OF QUESTION PAPER

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

10/18

Page 10 of18

Suggested Answers


Section A: Basic Concepts

Answer Reason1. B The prototyping model of software development is useful approach when a customer

cannot define requirements clearly.< TOP >

2. A The component-based development model composes applications from prepackagedsoftware components.The component-based development model incorporates manyof the characteristics of the spiral model. The component-based development modelleads to software reuse, and reusability provides software engineers with a number omeasurable benefits.

< TOP >

3. E The formal methods model encompasses a set of activities that leads to formalmathematical specification of computer software. Formal methods model enable asoftware engineer to specify, develop and verify computer-based system by applyinga rigorous, mathematical notation. The development of formal methods model iscurrently quite-time consuming and expensive.

< TOP >

4. C A synchronous paradigm relies on the natural compartmentalization of a problem andorganizes team members to work on pieces of the problem with little activecommunication among themselves. Heavy communication and consensus-baseddecision making are the trade marks of open paradigm teams. Open paradigm teamstructures are well suited to the solution of complex problems but may not perform asefficiently as other teams.

< TOP >

5. E Project management activity encompasses measurement and metrics, estimation andscheduling, risk analysis, tracking and control.

< TOP >

6. A FP-based estimation techniques require problem decomposition based on informationdomain values.

< TOP >

7. A Software process metrics are used for strategic purposes where as software projectmetrics are tactical. Software project metrics are used to assess product quality on anongoing basis and, when necessary, modify the technical approach to improve quality.Software project metrics are used to minimize the development schedule by making

the adjustments necessary to avoid delays and mitigate potential problems and risks.

< TOP>

8. D Defect Removal Efficiency (DRE) is defined by the given formula , DRE= E/(E+D)where E is the number of errors found before delivery of the software to the end-user,and D is the number of defects found after delivery.

< TOP >

9. C V(G) = 4

Where V(G) = Cyclomatic complexity (or) number of regions.

V(G ) = E N + 2

4 = E 2 + 2E = 4.

< TOP >

10. E The decision to outsource can be either strategic or tactical. Outsourcing can beviewed more generally as any activity that leads to the acquisition of software orsoftware components from a source outside the software engineering organization.Outsourcing improves business performance & profitability.

< TOP >

11. B Technical risk identifies the potential design, implementation, interface, andverification and maintenance problems.

< TOP >

12. D Risk projection is also called risk estimation. < TOP >

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

11/18

Page 11 of18

13. E Risk monitoring is a project tracking activity with three primary objectives:

To assess whether predicted risks do, infact, occur.

To ensure that risk aversion steps defined for the risk are being properly applied.

To collect information that can be used for future risk analysis.

< TOP >

14. B The basic principles that guides software project scheduling includesCompartmentalization, Interdependency, Time allocation, Effort validation, Desiredresponsibilities, Defined outcomes, and Defined milestones. Market assessment is nota guiding principle of software project scheduling.

< TOP >

15. Cintegrity = [1 (threat (1 security))]

= (1 (0.25 (1 0.30)))

=(1- (0.25 0.70))

=(1- 0.175)

=0.825.

< TOP >

16. D

Customization index C =dp

dp sp

N

N N+

Where dpN = number of dynamic web pages.

spN = number of static web pages.

Customization index C =65

0.448145

= .

< TOP >

17. D Software maturity index (SMI)=T a c d T

[M (F F F )] / M + +

Where TM =The number of modules in the current release

cF = The number of modules in the current release that have been changed

aF = The number of modules in the current release that have been added

dF = The number of modules from the preceding release that were deleted in the

current release.

SMI =940-(90+40+12)/940= 940-142/940 =0.848.

< TOP >

18. E Failure mode analysis is included in internal failure cost and rest of the options areincluded in external failure costs.

< TOP >

19. A FTR is a software quality control activity performed by software engineers (andothers). The FTR is actually a class of reviews that includes walkthroughs,inspections, round robin reviews and other small group technical assessments o

software.Each FTR is conducted as a meeting and will be successful only if it isproperly planned, controlled and attended.

< TOP >

20. A DesignSpecification is an example of Aggregate objects and rest of the other optionsare examples of Basic objects.

< TOP >

21. C The Software configuration Management task configuration status reporting does notask a question like How it happened?. Rest of the other options given is correct.

< TOP >

22. E The software configuration management process has the following objectives:

I. To identify all items that collectively define the software configuration.

II. To facilitate the construction of different versions of an application.

III. To ensure that software quality is maintained as the configuration evolves over

time.

< TOP >

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

12/18

Page 12 of18

23. D By controlling the scope of testing, we can more quickly isolate problems andperform smarter retesting. This statement refers to the characteristic:decomposability.

< TOP >

24. D Basis path testing is an example for white box testing technique. Remaining all areexamples of black box testing technique.

< TOP >

25. B The physical connections between elements of the object-oriented design is called

coupling (i.e., the number of collaborations between classes or the number omessages passes between objects represent coupling within an object orientedsystem).

< TOP >

26. E A strategy for software testing is developed by project manger, software engineersand testing specialists.

< TOP >

27. B Unit testing focuses verification effort on the smallest unit of software design-thesoftware component or module. The unit test focuses on the internal processing logicand data structures within the boundaries of the component. Smoke testing is anintegration testing approach commonly used when software products are beingdeveloped.

< TOP >

28. C Stress tests are designed to execute a system in a manner that demands resources inabnormal quantity, frequency, or volume.

< TOP >

29. E PERT and CPM provide quantitative tools that allow the software planner todetermine the critical path , establish most likely time estimates for individual tasks

by applying statistical models, calculate boundary times that define a time window fora particular task.

< TOP >

30. A Regression testing is the re-execution of some subset of tests that have already beenconducted to ensure that changes have not propagated unintended side effects.

< TOP >

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

13/18

Page 13 of18


Section B: Caselets

1.If i am the project manger at Technopark Corp, I will consider the following factors:

(1) The degree to which the planner has properly estimated the size of the product to be built;

(2) The ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability

of reliable software metrics from past projects);(3) The degree to which the project plan reflects the abilities of the software team; and

(4) The stability of product requirements and the environment that supports the software engineering effort.

2.The following are the objectives of software cost estimation:

To introduce the fundamentals of software costing and pricing

To describe three metrics for software productivity assessment

To explain why different techniques should be used for software estimation

To describe the principles of the COCOMO 2 algorithmic cost estimation model

3.In his classic book on "software engineering economics," Barry Boehm [BOE81] introduced a hierarchy osoftware estimation models bearing the name COCOMO, for constructive Cost Model. The original

COCOMO model became one of the most widely used and discussed software cost estimation models inthe industry. It has evolved into a more comprehensive estimation model, called COCOMO II [BOE96,BOE00]. Like its predecessor, COCOMO II is actually a hierarchy of estimation models that address thefollowing areas:

Application composition model. Used during the early stages of software engineering, whenprototyping of user interfaces, consideration of software and system interaction, assessment operformance, and evaluation of technology maturity are paramount.

Early design stage model Used once requirements have been stabilized and basic softwarearchitecture has been established.

Post-architecture stage model. Used during the construction of the software.

The four main elements of the COCOMO II strategy are:

Preserve the openness of the original COCOMO

Key the structure of COCMO II to the future software marketplace sectors

Key the inputs and outputs of the COCOMO II sub models to the level of information available

Enable the COCOMO II submodels to be tailored to a projects particular process strategy.

COCOMO II follows the openness principles used in the original COCOMO. Thus, all of its relationships andalgorithms will be publicly available. Also, all of its interfaces are designed to be public, well-defined, and

parametrized,so that complementary preprocessors(analogy, case-based, or other size estimation models),post-processors(project planning and control tools, project dynamics models, risk analyzers), and higher levelpackages (project management packages, project negotiation aids), can be combined straightforwardly withCOCOMO II.

Like all estimation models for software, the COCOMO II models require sizing information. Three differentsizing options are available as part of the model hierarchy: object points, function points, and lines o

source code.The COCOMO II application composition model uses object points an indirect software measure that iscomputed using counts of the number of (1 ) screens (at the user interface), (2) reports, and (3) componentslikely to be required to build the application. Each object instance (e.g., a screen or report) is classified intoone of three complexity levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm[BOE96]. In essence, complexity is a function of the number and source of the client and server datatables that are required to generate the screen or report and the number of views or sections presentedas part of the screen or report.

Once complexity is determined, the number of screens, reports, and components are weighted accordingto the table illustrated below. The object point count is then determined by multiplying the originalnumber of object instances by the weighting factor in the figure (1) and summing to obtain a total object

point count. When component-based development or general software reuse is to be applied, the percent

of reuse (%reuse) is estimated and the object point count is adjusted:NOP = (object points) x [(100 - %reuse)/100]

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

14/18

Page 14 of18

Where NOP is defined as new object points.

To derive an estimate of effort based on the computed NOP value, a "productivity rate" must be derived.

Figure (2) represents the productivity rate.

PROD = NOP/person-month

for different levels of developer experience and development environment maturity. Once the productivityrate has been determined, an estimate of project effort can be derived as

estimated effort = NOP/PROD

Figure (1). Complexity weighting for object types

Figure (2). Productivity rate for object points

In more advanced COCOMO II models, a variety of scale factors, cost drivers, and adjustment proceduresare required.

4.Effective software project management focuses on the four Ps: people, product, process and project.The people factor is so important that the Software Engineering Institute has developed a people managementcapability maturity model to enhance the readiness of software organizations to undertake increasinglycomplex applications by helping to attract, grow, motivate, deploy and retain the talent needed to improvetheir software development capability. Organizations that achieve high levels of maturity in the peoplemanagement area have a higher likelihood of implementing effective software engineering practices.

Before a project can be planned, product objectives and scope should be established, alternative solutionsshould be considered and technical and management constraints should be identified. Without productinformation, it is impossible to define reasonable estimates of the cost, an effective assessment of risk, arealistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indicationof progress. Once the product objectives and scope are understood, alternatives enable managers and

practitioners to select a best approach, given the constraints imposed by delivery deadlines, budgetaryrestrictions, personnel availability, technical interfaces and myriad other factors.

A software process provides the framework from which a comprehensive plan for software development canbe established. A small number of framework activities are applicable to all software projects, regardless otheir size or complexity. A number of different task sets-tasks, milestones, work products and qualityassurance points-enable the framework activities to be adapted to the characteristics of the software projectand the requirements of the project team.

The software projects should be planned and controlled so that complexity to a great extent can be managed.Although the success rate for software projects has improved somewhat, the project failure rate remainedhigher than it should be. To avoid project failure, a software project manger and the software engineers who

build the product must heed a set of common warning signs, understand the critical success factors that leadto good project management, and develop a commonsense approach for planning, monitoring and controllingthe project.

5.The following are the ideal characteristics of a project manager:

Problem solving:

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

15/18

Page 15 of18

An effective software project manger can diagnose the technical and organizational issues that are mostrelevant, systematically structure a solution or properly motivate other practitioners to develop the solution,apply lessons learned from past projects to new situations, and remain flexible enough to change direction iinitial attempts at problem solution are fruitless.

Managerial identity:

A good project manger must take charge of the project and must have the confidence to assume control whennecessary and the assurance to allow good technical people to follow their instincts.

Achievement:To optimize the productivity of a project team, a manager must reward initiative and accomplishment anddemonstrate through his own actions that controlled risk taking will not be punished.

Influence and team building:

An effective project manager must be able to read people; and must be able to understand verbal and nonverbal signals and react tot the needs of the people sending these signals. The manager must remain under

control in high-stress situations.

>

6.Software teams fails due to the following factors:

1. Frenzied work atmosphere

2. High frustration that causes friction among team members

3. Fragmented or poorly coordinated software process

4. Unclear definition of roles on the software team5. Continuous and repeated exposure to failure.

To avoid a frenzied work environment, the project manger should be certain that the team has access to allinformation required to do the job and the major goals and objectives, once defined, should not be modifiedunless absolutely necessary. A software team can avoid frustration if it is given as much responsibility fordecision making as possible. An inappropriate process can be avoided by understanding the product to be

built and the people doing the work, and by allowing the team to select its own process model. The team itselshould establish mechanisms for accountability and define a series of corrective approaches when a memberof the team fails to perform. And finally, the key to avoiding an atmosphere of failure is to establish team-

based techniques for feedback and problem solving.

7.To manage a successful software project, a project manger must understand what can go wrong so thatproblems can be avoided. The following are the 10 signs that indicate an information systems project in

eopardy:1. Software people dont understand their customers needs.

2. The product scope is poorly defined.

3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs change or is ill-defined.

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost or was never properly obtained.

9. The project team lacks people with appropriate skills.

10. Managers avoid best practices and lessons learned.

Section C: Applied Theory

8. The Software Engineering institute (SEI) has developed a comprehensive process meta-modelthat is predicated on a set of system and software engineering capabilities that should be presentas organizations reach different levels of process capability and maturity.

The CMMI represents a process meta-model in two different ways: (1) as a continuous modeland (2) as a staged model. The continuous CMMI meta-model describes a process in twodimensions as illustrated in figure below. Each process area (e.g., project planning orrequirements management) is formally assessed against specific goals and practices and is ratedaccording to the following capability levels:

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

16/18

Page 16 of18

CMMI process area capability profile

Level 0: Incomplete. The process area (e.g., requirements management) is either not performedor does not achieve all goals and objectives defined by the CMMI for level 1 capability.

Level 1: Performed. All of the specific goals of the process area (as defined by the CMM1) havebeen satisfied. Work tasks required to produce defined work products are being conducted.

Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work associated with

the process area conforms to an organizationally defined policy; all people doing the work haveaccess to adequate resources to get the job done; stakeholders are actively involved in the processarea as required; all work tasks and work products are "monitored, controlled, and reviewed; andare evaluated for adherence to the process description"

Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is "tailoredfrom the organization's set of standard processes according to the organization's tailoringguidelines, and contributes work products, measures, and other process-improvement informationto the organizational process assets".

Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, theprocess area is controlled and improved using measurement and quantitative assessment."Quantitative objectives for quality and process performance are established and used as criteriain managing the process".

Level 5: Optimized. All capability level 4 criteria have been achieved. In addition, the processarea is adapted and optimized using quantitative (statistical) means to meet changing customerneeds and to continually improve the efficacy of the process area under consideration".

The staged CMMI model defines the same process areas, goals, and practices as] the continuousmodel. The primary difference is that the staged model defines five maturity levels, rather thanfive capability levels. To achieve a maturity level, the specific goals and practices associated witha set of process areas must be achieved.

The relationship between maturity levels and process area is shown below:

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

17/18

Page 17 of18

Process areas required to achieve a maturity level

9. The spiral mode!, originally proposed by Boehm [BOE88], is an evolutionary software processmodel that couples the iterative nature of prototyping with the controlled and systematic aspectsof the waterfall model. It provides the potential for rapid development of increasingly more

complete versions of the software. Boehm [BOE01] describes the model in the followingmanner: The spiral development model is a risk-driven process modelgenerator that is used toguide multi-stakeholder concurrent engineering of software intensive systems. It has two maindistinguishing features. One is a cyclic approach for incrementally growing a system's degree odefinition and implementation while decreasing its degree of risk. The other is a set of anchor

oint milestones for ensuring stakeholder commitment to feasible and mutually satisfactorysystem solutions. Using the spiral model, software is developed in a series of evolutionaryreleases. During early iterations, the release might be a paper model or prototype. During later it-erations, increasingly more complete versions of the engineered system are produced.

A spiral model is divided into a set of framework activities defined by the software engineeringteam. Each of the framework activities represent one segment of the spiral path illustrated infigure. As this evolutionary process begins, the software team performs activities that are implied

by a circuit around the spiral in a clockwise direction, beginning at the center. Risk is considered

as each revolution is made. Anchor point milestonesa combination of work products andconditions that are attained along the path of the spiralare noted for each evolutionary pass.

The first circuit around the spiral might result in the development of a product specification;subsequent passes around the spiral might be used to develop a prototype and then progressivelymore sophisticated versions of the software.

7/31/2019 52530-20225-0901 ITS-SPM (MB3G2IT)

18/18

Page 18 of18

Each pass through the planning region results in adjustments to the project plan. Cost andschedule are adjusted based on feedback derived from the customer after delivery. In addition,the project manager adjusts the planned number of iterations required to complete the software.

Unlike other process models that end when software is delivered, the spiral model can be adaptedto apply throughout the life of the computer software. Therefore, the first circuit around the spiralmight represent a "concept development project" which starts at the core of the spiral and

continues for multiple iterations until concept development is complete. If the concept is to bedeveloped into an actual product, the process proceeds outward on the spiral and a "new productdevelopment project" commences. The new product will evolve through a number of iterationsaround the spiral. Later, a circuit around the spiral might be used to represent a "productenhancement project." In essence, the spiral, when characterized in this way, remains operativeuntil the software is retired. There are times when the process is dormant, but whenever a changeis initiated, the process starts at the appropriate entry point (e.g., product enhancement).

The spiral model is a realistic approach to the development of large-scale systems and software.Because software evolves as the process progresses, the developer and customer betterunderstand and react to risks at each evolutionary level. The spiral model uses prototyping as arisk reduction mechanism but, more importantly, enables the developer to apply the prototypingapproach at any stage in the evolution of the product. It maintains the systematic stepwise

approach suggested by the classic life cycle but incorporates it into an iterative framework thatmore realistically reflects the real world. The spiral model demands a direct consideration otechnical risks at all stages of the project and, if properly applied, should reduce risks before they

become problematic.

But like other paradigms, the spiral model is not a panacea. It may be difficult to convincecustomers (particularly in contract situations) that the evolutionary approach is controllable. Itdemands considerable risk assessment expertise and relies on this expertise for success. If amajor risk is not uncovered and managed, problems will undoubtedly occur.

< TOP OF THE DOCUMENT >

Documents

52530-20225-0901 ITS-SPM (MB3G2IT)