Project Management (May - 2018) [CBSGS - Paper Solution] {Mumbai University}

BOOK CODE: TYBSCIT-PM-009
APRIL – 2019
Mumbai University
B.Sc.IT (Information Technology)
CBSGS: Semester – VI
YEAR: MAY – 2018
PROJECT
MANAGEMENT
By
Kamal Thakur

1
© Mumbai B.Sc.IT Study Kamal T.
Project Management
Paper Solution
 University: University of Mumbai
 Year: May – 2018
 Course: B.Sc.IT (Information Technology)
 Semester: VI
 Subject: Project Management
 Syllabus: CBSGS – 75:25 Pattern
BY
Kamal Thakur
B.Sc.IT (Mumbai University)
Web Designer | Blogger | YouTuber | E-Books Designer & Maker

2
Contact Me @
Email ID:
kamalthakurbscit@gmail.com
WhatsApp No.:
+91 – 8454975016
Social Network @
YouTube
http://bit.do/KamalT
Official Site
http://mumbaibscitstudy.com
Facebook
https://facebook.com/mumbaibscitstudy
Instagram
https://instagram.com/mumbaibscitstudy
Twitter
https://twitter.com/kamaltuniverse
Pinterest
https://in.pinterest.com/kamaltuniverse

3
PROJECT MANAGEMENT
(PAPER SOLUTION)
MAY – 2018 | CBSGS – 75:25 PATTERN
BY
KAMAL THAKUR

4
Time: 2 ½ Hours Total Marks: 75
NOTES:
(1) All Question are Compulsory.
(2) Make Suitable Assumptions Wherever Necessary And State The Assumptions Made.
(3) Answer To The Same Question Must Be Written Together.
(4) Number To The Right Indicates Marks.
(5) Draw Neat Labeled Diagrams Wherever Necessary.
(6) Use of Non – Programmable Calculator is allowed.
Q.1. Attempt Any Two Questions: (10 Marks)
Q Explain Boehm's principle for examining how to staff for Software Project. .........6
Q Explain the three levels of processes and its attributes. .........................................8
Q What are the five basic parameters that are involved in estimating the cost of a
Software Project? ......................................................................................................8
Q Explain the five Symptoms of a project that is headed for trouble.........................9
Q List out the Life-Cycle Phases of Modern Software Development process. State
the objectives of each phase...................................................................................11
Q Briefly explain the different Artifacts in the Management Set. ............................12
Q Explain the Technical Perspective of Software Architecture.................................14
Q Map the process exponent parameters of the COCOMO II Model to the principles
of a modern process................................................................................................15
Q What is a Workflow? Describe the major Workflows involved in Software
Development. ..........................................................................................................16
Q Write short note on Life-Cycle Architecture Milestone. List the Engineering
Artifacts available at the Life-Cycle Architecture Milestone. ................................17
Q What is Work Breakdown Structure? What are the issues associated with
Conventional Work Breakdown Structure?............................................................18
Q Write short note on Minor Milestones in a Project Life-Cycle. .............................18
Q With the help of diagram explain the default roles and responsibilities in a
Software Line-Of-Business Organization................................................................20
Q Briefly explain the four important disciplines that are critical to the Management
Context and the success of a Modern Iterative Development process.................21

5
Q What is Configuration Baseline? What are the different types of Software
Change?....................................................................................................................22
Q Explain the activities of Software Management Team over the Project Life
Cycle.........................................................................................................................23
Q Explain the Quality Indicators that provide an indication of the quality of
Software System......................................................................................................25
Q Define Metrics. List out basic characteristics of a Good Metric. ...........................26
Q Summarize process discrimination that result from difference in Stakeholder
Cohesion. .................................................................................................................27
Q With the help of diagram explain the two Primary Dimensions of process
variability.................................................................................................................28
Q With the help of diagram explain the difference between the Progress Profile of
a Modern Project and Conventional Project..........................................................29
Q Explain how a Software Cost Model should be structured to best support the
estimation of a Modern Software Process.............................................................30
Q Briefly explain the Culture Shifts in order to avoid friction in transitioning to
Modern Software Process.......................................................................................30
Q How does balancing the top 10 Software Management Principles achieve
balance in Software Economics Equation?.............................................................31
Q State Boehm's top 10 Principles about Conventional Software Management
Performance. ...........................................................................................................33
Q Write short note on Requirement and Design Set.................................................34
Q Explain Top-Down and Bottom-Up approach of Cost and Schedule Estimating
Process.....................................................................................................................35
Q Explain the Automation Aids and Tool Components that support the process
Workflows................................................................................................................36
Q Define the terms – Earned Value, Actual Cost, Cost Variance, Expenditure Plan
and Schedule Variance ............................................................................................37
Q List the characteristics of Modern Iterative Development Framework. Explain the
steps to follow to transition to a mature Iterative Development process............38

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A)
Explain Boehm's principle for examining how to staff for Software
Project.
SOLUTION
Boehm's Staffing Principles:
In examining how to staff a software project, Boehm offered the following five staffing
principles [Boehm, 1981]:
1) The Principle Of Top Talent: Use better and fewer people.
 This tenet is fundamental, but it can be applied only so far.
 There is a "natural" team size for most jobs, and being grossly over or under this
size is bad for team dynamics because it results in too little or too much pressure
on individuals to perform.
2) The Principle Of Job Matching: Fit the tasks to the
skills and motivation of the people available.
 This principle seems obvious.
 However with software engineers, it is more difficult to discriminate the mostly
intangible personnel skills and optimal task allocations.
 Personal agendas also complicate assignments. On software teams, however, it
is common for talented programmers to seek promotions to architects and
managers.

7
 There are countless cases of great software engineers being promoted
prematurely into positions for which they were unskilled and unqualified.
3) The Principle Of Career Progression: An organization
does best in the long run by helping its people to self-
actualize.
• Good performers usually self-actualize in any environment. Organizations can help
and hinder employee self-actualization. Organizational training programs are typically
strategic undertakings with educational value. Project training programs are purely
tactical, intended to be useful and applied the day after training ends.
4) The Principle Of Team Balance: Select people who will
complement and harmonize with one another.
 Although this principle sounds a little drippy, its spirit is the paramount factor in
good teamwork.
 Software team balance has many dimensions, and when a team is unbalanced in
anyone of them, a project becomes seriously at risk.
 These dimensions include:
i) Raw Skills: Intelligence, Objectivity, Creativity, Organization, Analytical
Thinking
ii) Psychological Makeup: Leaders and Followers, Risk Takers and
Conservatives, Visionaries and Nitpickers, Cynics and Optimists
iii) Objectives: Financial, Feature Set, Quality, Timeliness
5) The Principle Of Phaseout: Keeping a misfit on the team
doesn't benefit anyone.
 This is really a subprinciple of the other four.
 A misfit gives you a reason to find a better person or to live with fewer people.
 A misfit demotivates other team members, will not self-actualize, and disrupts
the team balance in some dimension.
 Misfits are obvious, and it is almost never right to procrastinate weeding them
out.

8
Q.1. (B) Explain the three levels of processes and its attributes.
SOLUTION
Three Levels of Processes and its Attributes:
Attributes Metaprocess Macroprocess Microprocess
Subject Line of Business Project Iteration
Objectives Line-of-Business
Profitability
Competitiveness
Project Profitability
Risk Management
Project Budget,
Schedule, Quality
Resource
Management
Risk Resolution
Milestone Budget,
Schedule, Quality
Audience Acquisition
Authorities,
Customers
Organizational
Management
Software Project
Managers
Software Engineers
Subproject
Managers
Software Engineers
Metrics Project
Predictability
Revenue, Market
Share
On Budget, On
Schedule
Major Milestone
Success
Project Scrap and
Rework
On Budget, on
Schedule
Major Milestone
Progress
Release/Iteration
Scrap and Rework
Concerns Bureaucracy Vs.
Standardization
Quality Vs. Financial
Performance
Content Vs.
Schedule
Time Scales 6 to 12 Months 1 to Many Years 1 to 6 Months
Q.1. (C)
What are the five basic parameters that are involved in
estimating the cost of a Software Project?
SOLUTION
Parameters of the Software Cost Model:
Five basic Parameters of the Software Cost Model are listed below:
1) Size
2) Process
3) Personnel
4) Environment
5) Required Quality

9
Size:
The size of the end product, which is typically quantified in terms of the number of
source instructions or the number of function points required to develop the required
functionality.
Process:
The process used to produce the end product, in particular the ability of the process
to avoid non-value-adding activities.
Personnel:
The capabilities of software engineering personnel, and particularly their experience
with the computer science issues and the application domain issues of the project.
Environment:
The environment, which is made up of the tools and techniques available to support
efficient software development and to automate the process.
Required Quality:
The required quality of the product, including its features, performance, reliability,
and adaptability.
Q.1. (D)
Explain the five Symptoms of a project that is headed for trouble.
SOLUTION
Five Symptoms are:
1) Protracted Integration & Late Design Breakage:
 Conventional techniques that imposed a waterfall model on the design process
resulted in the integration & performance showstoppers.
 The entire system was designed on paper, then implemented all at once, then
integrated.
2) Late Risk Resolution:
 Early risk resolution was lacking in waterfall model.
 Resolving issues late in the Life Cycle when there was great inertia inhibiting
changes to the mass of artifacts was very expensive.
 Late fixes & patches into the existing implementation did not conserve the
overall design integrity and its corresponding maintainability.
3) Requirements – Driven Functional Decomposition:

10
 Requirements were to be specified completely and unambiguously before
the development activities began.
 Requirements were specified in a functional manner.
 Functional decomposition became anchored in Contracts, Sub-Contracts,
WBS.
1) Adversarial Stakeholder Relationship:
 Conventional process resulted in adversarial stakeholder relationships
because of difficulties of requirements specification & exchange of
information solely through paper documents.
 Lack of rigorous notation resulted in subjective reviews.
 This approach resulted in customer-contractor relationships degenerating
into mutual distrust.
 This made it difficult to achieve a balance among requirements, schedule
and cost.
2) Focus on Documents and Review Meetings:
 Conventional process focused on producing various documents that
attempted to describe the software product with insufficient focus on
producing tangible increments of the products themselves.
 Major milestones were implemented specifically in terms of documents.
 Presenters & audience reviewed simple things rather than complex &
important issues.

11
Q.2. (A)
List out the Life-Cycle Phases of Modern Software Development
process. State the objectives of each phase.
SOLUTION
Two stages of the Life-Cycle:
1. The Engineering Stage – Driven by smaller teams doing design and synthesis
activities.
2. The Production Stage – Driven by larger teams doing construction, test, and
deployment activities.
Engineering Stage:
Engineering Stage has following phases:
 Inception Phase: Goal to achieve concurrence among stakeholders on the life-
cycle objectives.
 Elaboration Phase: During the elaboration phase, an executable architecture
prototype is built.
Production Stage:
Production Stage has following phases:
 Construction Phase: All remaining components and application features are
integrated into the application. All features are thoroughly tested.

12
 Transition Phase: The transition phase is entered when baseline is mature
enough to be deployed in the end-user domain. This phase could include beta
testing, conversion of operational databases, and training of users and
maintainers.
Q.2. (B) Briefly explain the different Artifacts in the Management Set.
SOLUTION
Artifacts in the Management Set:
Planning Artifacts:
1. Work Breakdown Structure
2. Business Case
3. Release Specifications
4. Software Development Plan
Operational Artifacts:
5. Release Descriptions
6. Status Assessments
7. Software Change Order Database
8. Deployment Documents
9. Environment
1. Work Breakdown Structure:
 Work Breakdown Structure (WBS) is a base for budgeting and cost estimation
used to monitor and control the project’s financial performance.
 The project manager must have an insight into project costs and expenditure.
 The WBS is a serious planning constraint.
2. Business Case:
 This artifacts gives all the information that is required to decide whether the
project is worth investing in or not.
 It describes the expected cost, expected technical and management plans, and
backup data necessary to face risks and realism of the plans.
 The main objective is to transform the vision into economic terms which can help
the organization to make an accurate assessment of ROI (Return on Investment).
 The financial forecasts are updated step by step with more accurate forecasts as
the life cycle progresses.

13
3. Release Specifications:
 This artifacts includes the scope, plan, and objective evaluation criteria for each
release and all these details are derived from the vision statement as well as
many other sources such as from the Analysis, Risk Management Concerns,
Architectural Considerations, Implementation Constraints, Quality Thresholds.
 All these artifacts of release specification evolve and get updated along with the
process, thus, achieving greater fidelity and maturity in understanding the
requirements.
4. Software Development Plan:
 The Software Development Plan (SDP) elaborates the process framework into a
fully detailed plan.
 It is the defining document for the project's process.
 It must comply with the contract (if any), comply with organization standards (if
any), evolve along with the design and requirements, and be used consistently
across all subordinate organizations doing software development.
5. Release Descriptions:
 It describes the results of each release that includes the performance details
against each of the evaluation criteria in the corresponding release specification.
 Release Description also describe the evaluation criteria for that configuration
baseline and also provides substantiation, i.e. through demonstration, testing,
inspection, or analysis of each criterion that has been addressed as required
6. Status Assessments:
 These artifacts provide periodic snapshots of project health and status, including
the Software Project Manager's Risk Assessment and the Quality and
Management Indicators.
 It also includes a review of Resources, Staffing, Financial Data (cost and revenue),
Top 10 Risks, Technical Progress, Major Milestone Plans and results, and scope
of the project.
7. Software Change Order Database:
 Managing and tracking the change is one of the important activities in an
iterative development process.
 As the iterative development process provides a "Greater Change Freedom", a
project can be iterated again and again to achieve more and more productively.
 This flexibility of making greater changes in the project ultimately increases the
number of iterations and thus increases the content and also the quality of the
software product and that too within a given schedule.

14
8. Deployment Documents:
 This artifacts includes several document subsets for transitioning the product
into operational status.
 If the system is delivered to a separate Maintenance Organization, then in such
cases, the Deployment Artifacts must include Computer System Operations
Manuals, Software Installation Manuals, Plans and Procedures, Site Surveys, etc.
 If the product is used for commercial purpose, the deployment artifacts must
include Marketing Plans, Sales Rollout Kits, and Training Courses.
9. Environment:
 Mostly, all the modern approaches define the development and maintenance
environment as a first-class artifact of the process. A development environment
is said to be robust and integrated if it supports automation of the development
process.
 Such an environment includes Requirements Management, Visual Modeling,
Document Automation, Programming Tools, Automated Regression Testing, and
continuous and Integrated Change Management and also a feature and defect
tracking.
Q.2. (C) Explain the Technical Perspective of Software Architecture.
SOLUTION
Architecture: A Technical Perspective:
 An Architecture Framework is defined in terms of views that are abstractions of
the UML Models in the Design Set.
 The Design Model includes the full breadth and depth of information.
 An Architecture View is an Abstraction of the design model; it contains only the
architecturally significant information.
 Most real-world systems require four views: Design, Process, Component, and
Deployment.
 The purpose of these views are as follows:
1) Design: Describes architecturally significant structures and functions of the
Design Model.
2) Process: Describes concurrency and control thread relationships among the
Design, Component, and Deployment Views.
3) Component: Describes the structure of the implementation set.
4) Deployment: Describes the structure of the deployment set.

15
Q.2. (D)
Map the process exponent parameters of the COCOMO II Model
to the principles of a modern process.
SOLUTION
Exponent Parameters of COCOMO Model are:
(1) Application Precedentedness
(2) Process Flexibility
(3) Architecture Risk Resolution
(4) Team Cohesion
(5) Software Process Maturity
Mapping of each COCOMO Parameter to Modern Principles:
1) Application Precedentedness:
Domain experience is a critical factor in understanding how to plan and execute a
software development project.
2) Process Flexibility:
Development of Modern Software is characterized by such a broad solution space and
so many interrelated concerns that there is a paramount need for continuous
incorporation of changes.
3) Architecture Risk Resolution:
Architecture-First Development is a crucial theme underlying a successful iterative
development process. A project team develops and stabilizes an architecture before
developing all the components that make up the entire suite of applications
components.
4) Team Cohesion:
Successful teams are cohesive, and cohesive teams are successful. Cohesive teams
avoid sources of project turbulence and entropy that may result from difficulties in
synchronizing project stakeholder expectations.
5) Software Process Maturity:
The Software Engineering Institute's Capability Maturity Model (CMM) is a well-
accepted benchmark for software process assessment.

16
Q.3. (A)
What is a Workflow? Describe the major Workflows involved in
Software Development.
SOLUTION
Workflow:
 It is used to mean a thread of cohesive and mostly sequential activities.
 They are mapped to product artifacts.
 Form a Primary Source of Management Complexity.
 Are also referred to as Microprocess.
Major Workflow:
Management Workflow:
Controlling the process and ensuring win conditions for all Stakeholders.
Environment Workflow:
Automating the process and evolving the Maintenance Environment.
Requirements Workflow:
Analyzing the problem space and evolving the Requirements Artifacts.
Design Workflow:

17
Modeling the solution and evolving the Architecture and Design Artifacts.
Implementation Workflow:
Programming the components and evolving the implementation and Deployment
Artifacts.
Assessment Workflow:
Assessing the trends in process and product quality.
Deployment Workflow:
Transitioning the end products to the user.
Q.3. (B)
Write short note on Life-Cycle Architecture Milestone. List the
Engineering Artifacts available at the Life-Cycle Architecture
Milestone.
SOLUTION
Life-Cycle Architecture Milestone:
 The Life-Cycle Architecture Milestone occurs at the end of the elaboration phase.
 The primary goal is to demonstrate an executable architecture to all
stakeholders.
 A more detailed plan for the construction phase is presented for approval.
 Critical issues relative to requirements and the operational concept are
addressed.
 This review will also produce consensus on a baseline architecture, baseline
vision, baseline software development plan, and evaluation criteria for the initial
operational capability milestone.
 The baseline architecture consists of both a human-readable representation (the
architecture document) and a configuration-controlled set of software
components captured in the engineering artifacts.
 A successfully completed life-cycle architecture milestone will result in
authorization from the stakeholders to proceed with the construction phase.
Engineering Artifacts available at the Life-Cycle Architecture Milestone:
I. Requirements
A. Use Case Model
B. Vision Document (text, use cases)
C. Evaluation Criteria for Elaboration (text, scenarios)
II. Architecture

18
A. Design View (Object Models)
B. Process View (if necessary, Run-Time Layout, Executable Code
Structure)
C. Component View (Subsystem Layout, Make/Buy/Reuse Component
Identification)
D. Deployment View (Target Run-Time Layout, Target Executable Code
Structure)
E. Use Case View (Test Case Structure, Test Result Expectation)
III. Source and Executable Libraries
A. Product Components
B. Test Components
C. Environment and Tool Components
Q.3. (C)
What is Work Breakdown Structure? What are the issues
associated with Conventional Work Breakdown Structure?
SOLUTION
Work Break Down Structures (WBS):
 A Work Breakdown Structures (WBS) is simply a hierarchy of elements
that decomposes the project plan into the discrete work tasks.
 A WBS provides the following information structure:
 A Delineation of all significant work.
 A Clear task decomposition for assignment of responsibilities.
 A Framework for Scheduling, Budgeting and Expenditure Tracking.
Conventional Work Breakdown Structures (WBS):
There are three fundamental issues with Conventional WBS as follows:
 They are prematurely structured around the product design.
 They are prematurely decomposed, planned, and budgeted in either too much
or too little detail.
 They are Project-Specific, and Cross-Project Comparisons are usually difficult or
impossible.
Q.3. (D) Write short note on Minor Milestones in a Project Life-Cycle.

19
SOLUTION
Minor Milestones:
 The number of iteration-specific, informal milestones needed depends on the
content and length of the iteration. For most iterations, which have a one-month
to six-month duration, only two minor milestones are needed: the iteration
readiness review and the iteration assessment review. For longer iterations,
more intermediate review points may be necessary.
 All iterations are not created equal. An iteration can take on very different forms
and priorities, depending on where the project is in the life cycle.
 Early iterations focus on analysis and design, with substantial elements of
discovery, experimentation, and risk assessment.
 Later iterations focus much more on completeness, consistency, usability, and
change management.
 The milestones of an iteration and its associated evaluation criteria need to focus
the engineering activities on the project priorities as defined in the overall
software development plan, business case, and vision.
 The figure given below identifies the various minor milestones to be considered
when a project is being planned.
Figure 1: Typical Minor Milestones in the Life Cycle of an Iteration

20
Q.4. (A)
With the help of diagram explain the default roles and
responsibilities in a Software Line-Of-Business Organization.
SOLUTION
Line of Business Organization:
Software Line of Business Organizations are motivated by ROI, new Business
Discriminators, and Market Diversification & Profitability.
Roles and Responsibilities to a Default Line-Of-Business
Organization:
 Responsibility for process definition and maintenance is specific to a cohesive
line of business, where process commonality makes sense.
 Responsibility for process automation is an organizational role and is equal in
importance to the process definition role.
 Organizational roles may be fulfilled by a single individual or several different
teams, depending on the scale of the organization.

21
Figure 2: Default Roles in a Software Line-Of-Business Organization
Q.4. (B)
Briefly explain the four important disciplines that are critical to
the Management Context and the success of a Modern Iterative
Development process.
SOLUTION
Environment Disciplines that are critical to the Management Context and the
success of a Modern Iterative Development process:
Traceability:
 Tools must be integrated to maintain consistency and traceability.
 Roundtrip engineering is the term used to describe this key requirement for
environments that support iterative development.
Change Management:
 Change Management must be automated and enforced to manage multiple
iterations and to enable change freedom.
 Change is the fundamental primitive of iterative development.

22
Infrastructures:
 Organizational infrastructures enable project environments to be derived from a
common base of processes and tools.
 A common infrastructure promotes inter-project consistency, reuse of training,
reuse of lessons learned, and other strategic improvements to the organizations
metaprocess.
Stakeholder:
 Extending automation support for stakeholder environments enables further
support for paperless exchange of information and more effective review of
engineering artifacts.
Q.4. (C) What is Configuration Baseline? What are the different types of
Software Change?
SOLUTION
Configuration Baseline:
 A configuration baseline is a named collection of software components and
supporting documentation that is subject to change management and is
upgraded, maintained, tested, statused, and obsolesced as a unit.
 With complex configuration management systems, there are many desirable
project-specific and domain-specific standards.
 There are generally two classes of baselines: external product releases and
internal testing releases.
 A configuration baseline is a named collection of components that is treated as
a unit.
 It is controlled formally because it is a packaged exchange between groups.
 Generally, three levels of baseline releases are required for most systems: major,
minor, and interim.
 Each level corresponds to a numbered identifier such as N.M.X, where N is the
major release number, M is the minor release number, and X is the interim
release identifier.
Types of Software Change:
Type 0: critical failures, which are defects that are nearly always fixed before any
external release. In general, these sorts of changes represent showstoppers that have
an impact on the usability of the software in its critical use cases.

23
Type 1: a bug or defect that either does not impair the usefulness of the system or can
be worked around. Such errors tend to correlate to nuisances in critical use cases or
to serious defects in secondary use cases that have a low probability of occurrence.
Type 2: a change that is an enhancement rather than a response to a defect. Its
purpose is typically to improve performance, testability, usability, or some other
aspect of quality that represents good value engineering.
Type 3: a change that is necessitated by an update to the requirements. This could be
new features or capabilities that are outside the scope of the current vision and
business case.
Type 4: changes that are not accommodated by the other categories. Examples
include documentation only or a version upgrade to commercial components.
Q.4. (D)
Explain the activities of Software Management Team over the
Project Life Cycle.
SOLUTION
Activities of Software Management Team over the Project Life Cycle:
Inception:
 Elaboration Phase Planning
 Team Formulation
 Contract Baselining
 Architecture Costs
Elaboration:
 Construction Phase Planning
 Full Staff Recruitment
 Risk Resolution
 Product Acceptance Criteria
 Construction Costs
Construction:
 Transition Phase Planning
 Construction Plan Optimization
 Risk Management

24
Transition:
 Customer Satisfaction
 Contract Closure
 Sales Support
 Next-Generation Planning

25
Q.5. (A)
Explain the Quality Indicators that provide an indication of the
quality of Software System.
SOLUTION
Quality Indicators
i) Change Traffic and Stability
ii) Breakage and Modularity
iii) Rework and Adaptability
iv) MTBF and Maturity
Change Traffic and Stability:
Progress and Quality Parameters of the software measure by the change traffic
indicator.
 Change Traffic: The number of the SCO's open and closed over the whole life
cycle is known as Change Traffic.
 Stability: Relationship between open and closed SCO's is known as Stability.
This information relates to the metrics is collected through overall change, its release
type, all number of release, by team, by all its components, by all its subsystems, and
so on.

26
Breakage and Modularity
 Breakage: The average extents of change, which is the amount of software
baseline that needs rework is known as Breakage.
 Modularity: The average breakage trend over time is known as Modularity.
As time increase breakage trend is also increase, this indicates that product
maintainability is suspect.
Rework and Adaptability
 Rework: The average cost of change, which is the effort to analyze, resolve and
reset all changes to the software baseline is known as rework.
 Adaptability: The rework trend over time is known as adaptability.
MTBF and Maturity:
 Mean Time between Failures (MTBF): The average usage time between
software faults is known as Mean Time between Failures. It is calculated by
dividing the test hours by the number of type 0 -1 SCOs.
 Maturity: The MTBF trend over time is known as Maturity.
As an error comes in the software projects then that are revised and prevent from
those error. Such errors are categorized into two types: Deterministic errors and non-
deterministic error.
Q.5. (B) Define Metrics. List out basic characteristics of a Good Metric.
SOLUTION
Metrics:
Software process and project metrics are quantitative measures that enable software
engineers to gain insight into the efficiency of the software process and the projects
conducted using the process framework.
The basic characteristics of a good metric are as follows:
 It is considered meaningful by the customer, manager, and performer.
 It demonstrates quantifiable correlation between process perturbations and
business performance.
 It is objective and unambiguously defined.
 It displays trends.
 It is a natural by-product of the process.
 It is supported by automation.

27
Q.5. (C)
Summarize process discrimination that result from difference in
Stakeholder Cohesion.
SOLUTION
Process Discrimination that result from difference in Stakeholder Cohesion:
Process
Primitive
Few
Stakeholders,
Cohesive Teams
Multiple Stakeholders,
Adversarial
Relationships
Life-Cycle Phases Weak boundaries
between phases
Well-defined phase transitions to
synchronize progress among
concurrent activities
Artifacts Fewer and less detailed
management artifacts
required
Management artifacts paramount,
especially the business case,
vision, and status assessment
Workflow Effort
Allocations
Less overhead in
assessment
High assessment overhead to
ensure stakeholder concurrence
Checkpoints Many Informal events 3 or 4 formal events
Many informal technical
walkthroughs necessary to
synchronize technical decisions
Synchronization among
stakeholder teams, which can
impede progress for weeks
Management
Discipline
Informal planning,
project control and
organization
Formal planning, project control,
and organization
Automation
Discipline
(insignificant) On-line stakeholder environments
necessary

28
Q.5. (D)
With the help of diagram explain the two Primary Dimensions of
process variability.
SOLUTION
Two Primary Dimensions of process variability are:
(1) Technical Complexity
(2) Management Complexity
Figure 3: The Two Primary Dimensions of Process Variability

29
Q.6. (A)
With the help of diagram explain the difference between the
Progress Profile of a Modern Project and Conventional Project.
SOLUTION
The figure below illustrates the differences between the progress profile of a
healthy modern project and that of a typical conventional project.
Figure 4: Progress Profile of a Modern Project

30
Q.6. (B)
Explain how a Software Cost Model should be structured to best
support the estimation of a Modern Software Process.
SOLUTION
Two major improvements in next-generation software cost estimation models
are:
 Separation of the engineering stage from the production stage will force
estimators to differentiate between architectural scale and implementation size.
This will permit greater accuracy and more-honest precision in lifecycle
estimates.
 Rigorous design notations such as UML will offer an opportunity to define units
of measure for scale that are more standardized and therefore can be automated
and tracked. These measures can also be traced more straightforwardly into the
costs of production.
Q.6. (C)
Briefly explain the Culture Shifts in order to avoid friction in
transitioning to Modern Software Process.
SOLUTION
Culture Shifts for the Transition to Modern Software Process:
Culture Shifts necessary for the transition to Modern Software Process as follows
below:
 Lower Level and Mid-Level Managers are performers.
 Requirements and Designs are fluid and tangible.
 Ambitious Demonstrations are encouraged.
 Good and Bad Project Performance is much more obvious earlier in the Life Cycle.
 Early Increments will be immature.
 Artifacts are less important early, more important later.
 Real issues are surfaced and resolved systematically.
 Quality Assurance is everyone's job, not a separate discipline.
 Performance issues arise early in the Life Cycle.
 Investments in Automation are necessary.
 Good Software Organizations should be more profitable.

31
Q.6. (D)
How does balancing the top 10 Software Management Principles
achieve balance in Software Economics Equation?
SOLUTION
Top 10 Software Management Principles:
Figure 5: Balanced Application of Modern Principles to Achieve Economic Results
1) Architecture-First Approach:
Base the process on an architecture-first approach. An early focus on the architecture
results in a solid foundation for the 20% of the stuff (requirements, components, use
cases, risks, and errors) that drives the overall success of the project. Getting the
architecturally important components to be well understood and stable should result
in scrap and rework rates to decrease or remain stable over the project life cycle.
2) Iterative Life-Cycle Process:
Establish an iterative life-cycle process that confronts risk early. A more dynamic
planning framework supported by an iterative process results in better risk
management and more predictable performance. Resolving the critical issues first
results in a predictable construction phase with no surprises, as well as minimal
exposure to sources of cost and schedule unpredictability.
3) Component-Based Development:
Transition design methods to emphasize component-based development. The
complexity of a software effort is mostly a function of the number of human-generated
artifacts. Making the solution smaller reduces management complexity.

32
4) Change Management Environment:
Establish a change management environment. The dynamics of iterative development,
including concurrent workflows by different teams working on shared artifacts,
necessitate highly controlled baselines.
5) Round-Trip Engineering:
Enhance change freedom through tools that support round-trip engineering.
Automation enables teams to spend more time on engineering and less time on
overhead tasks.
6) Model-Based Notation:
Capture design artifacts in rigorous, model-based notation. An engineering notation
for design enables complexity control, objective assessment, and automated analyses.
7) Objective Quality Control:
Instrument the process for objective quality control and progress assessment.
Progress and quality indicators are derived directly from the evolving artifacts,
providing more-meaningful insight into trends and correlation with requirements.
8) Demonstration-Based Approach:
Use a demonstration-based approach to assess intermediate artifacts. Integration
occurs early and continuously throughout the life cycle. Intermediate results are
objective and tangible.
9) Evolving Levels of Detail:
Plan intermediate releases in groups of usage scenarios with evolving levels of detail.
Requirements, designs, and plans evolve in balance. Useful software releases are
available early in the life cycle.
10) Configurable Process:
Establish a configurable process that is economically scalable. Methods, techniques,
tools, and experience can be applied straightforwardly to a broad domain, providing
improved return on investment across a line of business.

33
Q.7.Attempt Any Three Questions: (15 Marks)
Q.7. (A)
State Boehm's top 10 Principles about Conventional Software
Management Performance.
SOLUTION
Conventional Software Management Performance:
(1) Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the problem in early design phases.
(2) You can compress software development schedules 25% of nominal, but no
more.
(3) For every $1 you spend on development, you will spend $2 on maintenance.
(4) Software development and maintenance costs are primarily a function of the
number of source lines of code.
(5) Variations among people account for the biggest differences in software
productivity.
(6) The overall ratio of software to hardware costs is still growing. In 1955 it was
15:85; in 1985, 85:15.
(7) Only about 15% of software development effort is devoted to programming.
(8) Software systems and products typically cost 3 times as much per SLOC as
individual software programs. Software-system products (i.e., system of
systems) cost 9 times as much.
(9) Walkthroughs catch 60% of the errors.
(10) 80% of the contribution comes from 20% of the contributors.

34
Q.7. (B) Write short note on Requirement and Design Set.
SOLUTION
Requirements Set:
 Requirement Set Artifacts are evaluated, assessed, analyzed and measured
based on the:
 Consistency of the release specifications of the "Management Set".
 Consistency between the vision and the Requirements Models.
 Consistency, completeness and the semantic balance between information in the
Design, Implementation, and Deployment Sets derived from the mappings
against these sets.
 Changes analyzed between the current version of the artifact corresponding to
its previous versions (scrap, rework, and defect eliminations)
 Review of other quality factors.
Design Set:
 The models in the design set are engineered using the UML notations. These
design models are essential for achieving the solution.
 The design set consists of varied levels of abstraction that represent the
components of the product solution such as the "Class diagram" represents the
component's identities, attributes, static relationships, dynamic interactions and
etc.
 Design set artifacts are evaluated, assessed, analyzed and measured based on
the:
 The internal consistency and quality of the design model.
 The consistency with the requirements models.
 Translation of artifacts from design set into the implementation and
deployment sets.
 The consistency, completeness and the semantic balance between
information in these sets.
 Changes analyzed between the current version of the artifacts in design
model corresponding to its previous versions (scrap, rework, and defect
eliminations).
 Review of other quality factors.

35
Q.7. (C)
Explain Top-Down and Bottom-Up approach of Cost and
Schedule Estimating Process.
SOLUTION
Forward-Looking Approach:
 The first is a forward-looking, also called as "top-down approach".
 It starts with an understanding of the general requirements and constraints.
 Then derives a macro-level budget and schedule.
 Then decomposes these elements into lower level budgets and intermediate
milestones.
Planning Sequence for Forward-Looking Approach:
1. The software project manager (and others) develops a characterization of the
overall size, process, environment, people, and quality required for the project.
2. A macro-level estimate of the total effort and schedule is developed using a
software cost estimation model.
3. The software project manager partitions the estimate for the effort into a top-
level WBS. The project manager also partitions the schedule into major milestone
dates and partitions the effort into a staffing profile across the life-cycle phases.
These sorts of estimates tend to ignore many detailed project-specific
parameters.
4. At this point, subproject managers are given the responsibility for decomposing
each of the WBS elements into lower levels using their top-level allocation,
staffing profile, and major milestone dates as constraints.
Backward-Looking Approach:
 The second perspective is a backward-looking, also called as "bottom-up
approach".
 Start with the end in mind.
 Analyze the micro-level budgets and schedules.
 Then sum all these elements into the higher level budgets and intermediate
milestones.
Planning Sequence for Backward-Looking Approach:
1. The lowest level WBS elements are elaborated into detailed tasks, for which
budgets and schedules are estimated by the responsible WBS element manager.
These estimates tend to incorporate the project-specific parameters in an
exaggerated way.

36
2. Estimates are combined and integrated into higher level budgets and milestones.
The biases of individual estimators need to be homogenized so that there is a
consistent basis of negotiation.
3. Comparisons are made with the top-down budgets and schedule milestones.
Gross differences are assessed and adjustments are made in order to converge
on agreement between the top-down and the bottom-up estimates.
Q.7. (D)
Explain the Automation Aids and Tool Components that support
the process Workflows.
SOLUTION
Management Workflow & Automation Aids:
 Automate Project Planning and Control Activities.
 Software Cost Estimation Tools.
 WBS Tools.
 Workflow Management Tools.
Environment Workflow & Automation Aids:
 Configuration Management
 Version Control
 Change Management.

37
Requirements Workflow & Automation Aids:
 Evolve alongwith an Architecture.
 Slowly vary across the Life Cycle.
 Represented in a form that is understandable to the buyer.
Design Workflow & Automation Aids:
 Visual Modeling is the primary support required for design workflow.
 It is used for capturing design models, presenting them in human-readable
format, and translating them into source code.
Implementation Workflow & Automation Aids:
 Relies primarily on a Programming Environment.
 Must also include substantial integration with the change management tools,
visual modeling tools, and test automation tools.
Assessment and Deployment Workflow & Automation Aids:
 Defect Tracking.
 It provides the change Management Instrumentation.
Q.7. (E)
Define the terms – Earned Value, Actual Cost, Cost Variance,
Expenditure Plan and Schedule Variance
SOLUTION
Earned Value (EV):
The Earned Value (EV) is an estimate of the value of the physical work actually
completed. EV is based on the original planned costs for the project or activity and the
rate at which the team is completing work on the project or activity to date.
Actual Cost (AC):
The Actual Cost (AC) is the total direct and indirect costs incurred in accomplishing
work on an activity during a given period.
Cost Variance (CV):
Cost Variance (CV) is the earned value minus the actual cost. If cost variance is a
negative number, it means that performing the work cost more than planned. If cost
variance is a positive number, performing the work cost less than planned.
Expenditure Plan:

38
The planned spending profile for a project over its planned schedule. For most
software projects (and other labor-intensive projects), this profile generally tracks the
staffing profile.
Schedule Variance (SV):
Schedule Variance (SV) is the earned value minus the planned value. A negative
schedule variance means that it took longer than planned to perform the work, and a
positive schedule variance means that the work took less time than planned.
Q.7. (F)
List the characteristics of Modern Iterative Development
Framework. Explain the steps to follow to transition to a mature
Iterative Development process.
SOLUTION
Characteristics of Modern Iterative Development Framework:
 Continuous round-trip engineering from requirements to test at evolving levels
of abstraction.
 Achieving high-fidelity understanding of the drivers (the 20%) as early as
practical.
 Evolving the artifacts in breadth and depth based on risk management priorities.
 Postponing completeness and consistency analyses until later in the life cycle.
Steps to follow to transition to a Mature Iterative Development Process:
Ready:
Do your homework. Analyze modern approaches and technologies. Define (or
improve, or optimize) your process. Support it with mature environments, tools, and
components. Plan thoroughly.
Aim:
Select a critical project. Staff it with the right team of complementary resources and
demand improved results.
Fire:
Execute the organizational and project-level plans with vigor and follow-through.
☮☮☮

Project Management (May - 2018) [CBSGS - Paper Solution] {Mumbai University}

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Project Management (May - 2018) [CBSGS - Paper Solution] {Mumbai University}

Similar to Project Management (May - 2018) [CBSGS - Paper Solution] {Mumbai University} (20)

More from Mumbai B.Sc.IT Study

More from Mumbai B.Sc.IT Study (20)

Recently uploaded

Recently uploaded (20)

Project Management (May - 2018) [CBSGS - Paper Solution] {Mumbai University}