Project Management (April - 2015) [CBSGS - Paper Solution] {Mumbai University}

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

1
© Mumbai B.Sc.IT Study Kamal T.
Project Management
Paper Solution
 University: University of Mumbai
 Year: April – 2015
 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)
APRIL – 2015 | 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 Discuss the significance of reducing the product size on ROI (Returns On
Investment). Explain briefly how the product size can be reduced. .......................6
Q Discuss the key practices that improve overall Software Quality...........................7
Q Discuss Boehm's Staffing Principles..........................................................................8
Q Evolution of Software Economics over three Generations......................................9
Q Discuss the Lifecycle, defined for Modern Software Development. .....................12
Q Define the term "Artifacts". List the five sets of artifacts. Define – Vision
Document, Software Architecture Description and Release Specifications. ........13
Q Discuss three different aspects of Software Architecture from a Management
Perspective. .............................................................................................................14
Q Map the Process Exponent Parameters of COCOMO to top 10 principles of
Modern Process.......................................................................................................14
Q What do you mean by Workflow? Discuss briefly its types...................................16
Q Write a short note on Major Milestone. ................................................................17
Q Define Work Breakdown Structure. Give the difference between Conventional
and Evolutionary WBS. List issues related to Conventional WBS..........................17
Q Explain Forward-Looking Approach for Cost and Schedule Estimating Process. ..18

5
Q Discuss briefly, default roles in a software Line-Of-Business Organization..........19
Q Define Process Automation. Mention its significance. Also, mention the extent of
automation at each level of the process. ...............................................................20
Q Explain mapping between Process Workflows and Software Development
Tools.........................................................................................................................21
Q "The Project Environment Artifacts evolve through three Discrete States".
Explain......................................................................................................................22
Q Define metrics and discuss characteristics of a Good Metric. ...............................23
Q Write a short note on "Earned Value System".......................................................24
Q Discuss the "Tailoring" concept in the context of software development. Explain
the two Primary Dimensions of Process Variability...............................................24
Q Explain the process discriminators resulting from differences in process
maturity. ..................................................................................................................25
Q Discuss the five recurring issues of Conventional Process. How are they resolved
by Modern Process Framework? ............................................................................27
Q How is risk resolution carried out in the Iterative Process? What is its
advantage? ..............................................................................................................28
Q How, balancing the top 10 Software Management Principles, Achieve Balance In
Software Economics Equation. ...............................................................................29
Q Discuss nine best practices of Software Management. .........................................31
Q.7. Attempt Any Three Questions: (15 Marks)
Q How "Peer Inspection" helps in improving ROI? Explain.......................................33
Q Explain in detail "Transition Phase" of Software Development Life Cycle with the
following details: Primary Objectives, Essential Activities & Evaluation Criteria.33
Q What is the significance of Periodic Assessments? Discuss the contents of Status
Assessment Review.................................................................................................35
Q Discuss the primitive components of a Software Change Order...........................36
Q Write a short note on SPCP (Software Project Control Panel). .............................39
Q Write a short note on "Next Generation Cost Models".........................................40

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A)
Discuss the significance of reducing the product size on ROI
(Returns On Investment). Explain briefly how the product size
can be reduced.
SOLUTION
Significance Of Reducing The Product Size On ROI:
 One important aspect of software economics is that the relationship between
effort and size exhibits a diseconomy of scale.
 The more software you build, the more expensive it is per unit item.
 For e.g. 10, 000 line software solution will cost less per line than a 100,000 line
software solution.
 Hence, the most significant way to improve ROI is usually to produce a product
that achieves the goal with the minimum possible human-generated source
material.
Reducing Software Product Size:
Languages: UFP (Universal Function Points):
 These points are language independent.

7
 The basic units of the UFP are external user inputs, external outputs, internal
logical data groups, external data interfaces, and external inquiries.
Object-Oriented Methods and Visual Modelling:
 OO (Object-Oriented) Technology reduces the size of the program.
 An Object-Oriented methodology improves the team work and interpersonal
communications by improving the understanding between the end users and
developers of the system.
 Prevent change in one part of system to affect another.
 Early Risk Resolution.
Reusability:
 The "Reusability" is mostly implemented with stored functions and subprograms.
 The main reason for reuse is "lack" of money.
 Reuse is implemented across many projects if they are similar.
 Costs needed to build reusable and configure reusable components.
Commercial Components:
 Main advantage of using Commercial Components is that it saves custom
development efforts.
 Commercial Components usually need tailoring.
 Commercial Components have an impact on quality, cost, supportability, and the
architecture.
Packages:
 Various elements of analysis model are categorized into packages that are given
a representative name.
 Packages is a model element that can contain other model elements.
 The components help to model the physical aspect of an Object-Oriented
Software system representing the relationship between various components.
Q.1. (B) Discuss the key practices that improve overall Software Quality.
SOLUTION
Key practices that improve overall software quality include the following:
 Focusing on driving requirements and critical use cases early in the life cycle,
focusing on requirements completeness and traceability late in the life cycle, and
focusing throughout the life cycle on a balance between requirements evolution,
design evolution, and plan evolution

8
 Using metrics and indicators to measure the progress and quality of architecture
as it evolves from a high-level prototype into a fully compliant product
 Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods,
document automation, and regression test automation
 Using visual modeling and higher level languages that support architectural
control, abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-
based evaluations.
Q.1. (C) Discuss Boehm's Staffing Principles.
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.
 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.

9
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.
Q.1. (D) Evolution of Software Economics over three Generations.
SOLUTION
Evolution of Software Economics over three Generations:
The three generations of software development are defined as follows:
Conventional:
1960’s and 1970’s, craftsmanship. Organizations used custom tools, custom
processes, and virtually all custom components built in primitive languages. Project
performance was highly predictable in that cost, schedule, and quality objectives were
almost always underachieved.
Transition:
1980’s and 1990’s, software engineering. Organizations used more-repeatable
processes and off-the-shelf tools, and mostly (>70%) custom components built in
higher level languages. Some of the components (<30%) were available as commercial
products, including the operating system, database management system, networking,
and graphical user interface. During the 1980’s, some organizations began achieving

10
economies of scale, but with the growth in applications complexity (primarily in the
move to distributed systems), the existing languages, techniques, and technologies
were just not enough to sustain the desired business performance.
Modern Practices:
2000 and later, software production. The modern generation philosophy is rooted in
the use of managed and measured processes, integrated automation environments,
and mostly (70%) off-the-shelf components. Perhaps as few as 30% of the components
need to be custom built. With advances in software technology and integrated
production environments, these component-based systems can be produced very
rapidly.

11
Figure 1: Three Generations of Software Economics leading to the Target Objectives

12
Q.2. (A)
Discuss the Lifecycle, defined for Modern Software Development.
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.

13
 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)
Define the term "Artifacts". List the five sets of artifacts. Define –
Vision Document, Software Architecture Description and Release
Specifications.
SOLUTION
Project Artifacts:
 Project Artifacts are the lowest levels of project document-based objects
(diagrams, design schemes, templates, and agendas) that explore project work
by phases and determine what results to produce upon completion of each
phase. They define and document a planned outcome to be delivered under
preset requirements and specifications.
 Artifacts create project documentation. They are generated by the team
throughout the project lifecycle. Each activity creates an artifact that documents
a deliverable. All activity deliverables are defined by project artifacts.
Artifact Sets:
There are five types of Artifact Sets as listed below:
1) Requirements Set
2) Design Set
3) Implementation Set
4) Deployment Set
5) Management Set
Vision Document:
Vision Statement (or user need), Which captures the contract between the
development group and the buyer.
Software Architecture Description:
It is extracted from the design model and includes views of the design,
implementation, and deployment sets sufficient to understand how the operational
concept of the requirements set will be achieved.
Release Specifications:
It mainly contains Evaluation criteria. Evaluation criteria are the snapshots of
objectives for a given intermediate lifecycle milestone.

14
Q.2. (C)
Discuss three different aspects of Software Architecture from a
Management Perspective.
SOLUTION
Software Architecture – Management Perspective:
From a management perspective, there are three different aspects of an architecture:
(1) An architecture (the intangible design concept) is the design of a software
system, as opposed to the design of a component. This includes all engineering
necessary to specify a complete bill of materials. Significant make/buy decisions
are resolved, and all custom components are elaborated so that individual
component costs and construction/assembly costs can be determined with
confidence.
(2) An architecture baseline (the tangible artifacts) is a slice of information across
the engineering artifact sets sufficient to satisfy all stakeholders that the vision
(function and quality) can be achieved within the parameters of the business case
(cost, profit, time, technology, and people).
(3) An architecture description (a human-readable representation of an
architecture) is an organized subset of information extracted from the design set
model(s). It includes the additional ad hoc notation (text and graphics) necessary
to clarify the information in the models. The architecture description
communicates how the intangible concept is realized in the tangible artifacts.
Q.2. (D)
Map the Process Exponent Parameters of COCOMO to top 10
principles of 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.

15
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 do you mean by Workflow? Discuss briefly its types.
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.
Types of Workflow:
There are Seven Top-Level Workflows:
(1) Management Workflow: Controlling the process and ensuring win conditions for
all Stakeholders.
(2) Environment Workflow: Automating the process and evolving the Maintenance
Environment.
(3) Requirements Workflow: Analyzing the problem space and evolving the
Requirements Artifacts.
(4) Design Workflow: Modeling the solution and evolving the Architecture and
Design Artifacts.
(5) Implementation Workflow: Programming the components and evolving the
implementation and Deployment Artifacts.

17
(6) Assessment Workflow: Assessing the trends in process and product quality.
(7) Deployment Workflow: Transitioning the end products to the user.
Q.3. (B) Write a short note on Major Milestone.
SOLUTION
Major Milestones:
 Major Milestones are system wide events that are held at the end of each
development phase.
 They provide visibility to system wide issues, synchronize the management and
engineering perspectives and verify that the aims of the phase have been
achieved.
 Major milestones at the end of each phase, use formal, stakeholder approved
evaluation criteria & release descriptions.
Types of Major Milestones:
There are four types of Major Milestones as follows:
(1) Life-Cycle Objectives Milestone
(2) Life-Cycle Architecture Milestone
(3) Initial Operational Capability Milestone
(4) Product Release Milestone
Q.3. (C)
Define Work Breakdown Structure. Give the difference between
Conventional and Evolutionary WBS. List issues related to
Conventional WBS.
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 Vs. Evolutionary:
Main difference is that,
 An evolutionary WBS organizes the planning elements around the PROCESS
Framework.

18
 Conventional WBS is organized using PRODUCT framework.
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)
Explain Forward-Looking Approach for Cost and Schedule
Estimating Process.
SOLUTION
Forward-Looking:
 The software project manager develops a characterization of the overall size,
process, environment, people, and quality required for the project.
 A macro-level estimate of the total effort and schedule is developed using a
Software Cost Estimation Model.
 The Software Project Manager Partitions the estimate for the effort into a top-
level WBS, also partitions the schedule into major milestone dates and partitions
the effort into a staffing profile.
 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.

19
Q.4. (A)
Discuss briefly, default roles 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.

20
Figure 2: Default Roles in a Software Line-Of-Business Organization
Q.4. (B)
Define Process Automation. Mention its significance. Also,
mention the extent of automation at each level of the process.
SOLUTION
Process Automation:
Automation means the loss of many organization jobs. Automation needs growth
depending on the scale of the effort. Process automation is critical to an iterative
process. There are many tools available to automate the software development
process.
Significance:
Process automation is necessary to perform against the development plan with
acceptable efficiency. Significant improvements of quality, shorter project durations
and ultimately reduction of overall engineering costs can be achieved through Process
automation. Hence increase in ROI.

21
Extent Of Automation:
The extent of automation at each level of process is as follows:
Metaprocess:
An organization's policies, procedures, and practices for managing a software-
intensive line of business. The automation support for this level is called an
infrastructure. An infrastructure is an inventory of preferred tools, artifact templates,
microprocess guidelines, macroprocess guidelines, project performance repository,
database of organizational skill sets, and library of precedent examples of past project
plans and results.
Macroprocess:
A project's policies, procedures, and practices for producing a complete software
product within certain cost, schedule, and quality constraints. The automation support
for a project's process is called an environment. An environment is a specific collection
of tools to produce a specific set of artifacts as governed by a specific project plan.
Microprocess:
A project team's policies, procedures, and practices for achieving an artifact of the
software process. The automation support for generating an artifact is generally called
a tool. Typical tools include requirements management, visual modeling, compilers,
editors, debuggers, change management, metrics automation, document automation,
test automation, cost estimation, and workflow automation.
Q.4. (C)
Explain mapping between Process Workflows and Software
Development Tools.
SOLUTION
There are many tools available to automate the software development process. The
mapping of the software development tools to the process workflows is shown below:
Workflows Environment Tools and Process Automation
Management Workflow Automation, Metrics Automation
Environment Change Management, Document Automation
Requirements Requirements Management
Design Visual Modelling
Implementation Editor-Compiler-Debugger
Assessment Test Automation, Defect Tracking
Deployment Defect Tracking
Process Organization Policy
Life Cycle Inception | Elaboration | Construction | Transition

22
Each of the process workflows has a distinct need for automation support.
Q.4. (D)
"The Project Environment Artifacts evolve through three Discrete
States". Explain.
SOLUTION
The Project Environment Artifacts evolve through Three Discrete States:
(1) The Prototyping Environment
(2) The Development Environment
(3) The Maintenance Environment
The Prototyping Environment:
The Prototyping Environment includes an architecture testbed for prototyping project
architectures to evaluate trade-offs during the inception and elaboration phases of the
life cycle. This informal configuration of tools should be capable of supporting the
following activities:
 Performance trade-offs and technical risk analyses
 Make/buy trade-offs and feasibility studies for commercial products
 Fault tolerance/dynamic reconfiguration trade-offs
 Analysis of the risks associated with transitioning to full-scale implementation
 Development of test scenarios, tools, and instrumentation suitable for analyzing
the requirements
The Development Environment:
The development environment should include a full suite of development tools
needed to support the various process workflows and to support round-trip
engineering to the maximum extent possible.
The Maintenance Environment:
The maintenance environment should typically coincide with a mature version of the
development environment. In some cases, the maintenance environment may be a
subset of the development environment delivered as one of the project's end
products.

23
Q.5. (A) Define metrics and discuss 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.

24
Q.5. (B) Write a short note on "Earned Value System".
SOLUTION
Basic Parameters of Earned Value System (EVS) are:
 Expenditure Plan: Planned Spending Profile for a Project.
 Actual Progress: Technical Accomplishment Relative to Planned Progress.
 Actual Cost: Actual Spending Profile for a Project.
 Earned Value: Value that represents the Planned Cost of Actual Progress.
 Cost Valiance: Different between the Actual Cost and Earned Value.
 Schedule Valiance: Difference between Planned Cost & Earned Value.
Q.5. (C)
Discuss the "Tailoring" concept in the context of software
development. Explain the two Primary Dimensions of Process
Variability.
SOLUTION
Tailoring:
It is necessary to tailor the software management effort to the specific needs of
project. Tailoring in software development is the process of extracting a set of
processes, task and artifacts from the organization established process, task and
artifacts to achieve its objectives.
Two Primary Dimensions of process variability are:
(1) Technical Complexity
(2) Management Complexity

25
Figure 3: The Two Primary Dimensions of Process Variability
Q.5. (D)
Explain the process discriminators resulting from differences in
process maturity.
SOLUTION
Process Discriminators that result from differences in Process Maturity:
Process
Primitive
Mature, Level 3 or 4
Organization
Level 1
Organization
Life-Cycle Phases Well-established Criteria for
Phase Transitions
(insignificant)
Artifacts Well-Established Format,
Content, and Production
Methods
Free-form
Workflow Efforts
Allocations
Well-established Basis No Basis
Checkpoints Well-defined combination of
Formal and Informal Events
(insignificant)
Management
Discipline
Predictable Planning Objective
Status Assessments
Informal Planning and
Project Control

26
Automation
Discipline
Requires High levels of
automation for round-trip
engineering, change
management, and process
instrumentation
Little automation or
disconnected islands of
automation

27
Q.6. (A)
Discuss the five recurring issues of Conventional Process. How
are they resolved by Modern Process Framework?
SOLUTION
Protracted Integration and Late Design Breakage:
Protracted Integration and Late Design Breakage are resolved by forcing integration
into the engineering stage. This is achieved through continuous integration of an
architecture baseline supported by executable demonstrations of the primary
scenarios.
Late Risk Resolution:
Late Risk Resolution is resolved by emphasizing an architecture-first approach, in
which the high-leverage elements of the system are elaborated early in the life cycle.
Requirements-Driven Functional Decomposition:
The analysis paralysis of a Requirements-Driven Functional Decomposition is avoided
by organizing lower level specifications along the content of releases rather than along
the product decomposition (by subsystem, by component, etc.).

28
Adversarial Stakeholder Relationships:
Adversarial Stakeholder Relationships are avoided by providing much more tangible
and objective results throughout the life cycle.
The Conventional Focus on Documents and Review Meetings:
The Conventional Focus on Documents and Review Meetings is replaced by a focus on
demonstrable results and well-defined sets of artifacts, with more-rigorous notations
and extensive automation supporting a paperless environment.
Q.6. (B)
How is risk resolution carried out in the Iterative Process? What
is its advantage?
SOLUTION
 According to modern project management ways, risk resolution is done very
early in the life cycle.
 The engineering stage of the life cycle focuses on exploring the risk and
resolving them before production stage.
 Entire project life cycle is divided into three different time period related to Risk
resolution.
They are as follows:-
 Risk Exploration Period (REP)
 Risk Resolution Period (RRP)
 Controlled Risk Management Period (CRMP)

29
Figure 4: Risk Profile of a Typical Modern Project Across Its Life Cycle
Q.6. (C)
How, 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

30
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.
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.

31
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.
Q.6. (D) Discuss nine best practices of Software Management.
SOLUTION
The nine best practices are described next.
1) Formal Risk Management:
Using an iterative process that confronts risk is more or less what this is saying.
2) Agreement On Interfaces:
While we may use different words, this is exactly the same intent as architecture-first
principle. Getting the architecture baselined forces the project to gain agreement on
the various external interfaces and the important internal interfaces, all of which are
inherent in the architecture.
3) Formal Inspections:
The assessment workflow throughout the life cycle, along with the other engineering
workflows, must balance several different defect removal strategies. The least
important strategy, in terms of breadth, should be formal inspection, because of its
high costs in human resources and its low defect discovery rate for the critical
architectural defects that span multiple components and temporal complexity.
4) Metric-Based Scheduling and Management:
This important principle is directly related to the model-based notation and objective
quality control principles. Without rigorous notations for artifacts, the measurement
of progress and quality degenerates into subjective estimates.

32
5) Binary Quality Gates At The Inch-Pebble Level:
This practice is easy to misinterpret. Too many projects have taken exactly this
approach early in the life cycle and have laid out a highly detailed plan at great
expense. Three months later, when some of the requirements change or the
architecture changes, a large percentage of the detailed planning must be rebaselined.
6) Program Wide Visibility Of Progress Versus Plan:
This practice – namely, open communications among project team members – is
obviously necessary.
7) Defect Tracking Against Quality Targets:
This important principle is directly related to architecture-first and objective quality
control principles. The make-or-break defects and quality targets are architectural.
Getting a handle on these qualities early and tracking their trends are requirements
for success.
8) Configuration Management:
The Airlie Software Council emphasized configuration management as key to
controlling complexity and tracking changes to all artifacts. It also recognized that
automation is important because of the volume and dynamics of modern; large scale
projects, which make manual methods cost-prohibitive and error-prone. The same
reasoning is behind change management principle.
9) People-Aware Management Accountability:
This is another management principle that seems so obvious.

33
Q.7.Attempt Any Three Questions: (15 Marks)
Q.7. (A) How "Peer Inspection" helps in improving ROI? Explain.
SOLUTION
 Inspections are also a good vehicle for holding authors accountable for quality
products.
 Inspections is more tangibly focused on integrated and executable aspects of the
overall system.
 Inspections allow gross blunders to be caught and feedback can be appropriately
channeled.
 These inspections ensure professional development of a team.
Q.7. (B)
Explain in detail "Transition Phase" of Software Development Life
Cycle with the following details: Primary Objectives, Essential
Activities & Evaluation Criteria.
SOLUTION
Transition Phase:
The transition phase is entered when a baseline is mature enough to be deployed in the
end-user domain. This typically requires that a usable subset of the system has been
achieved with acceptable quality levels and user documentation so that transition to

34
the user will provide positive results. This phase could include any of the following
activities:
(1) Beta testing to validate the new system against user expectations
(2) Beta testing and parallel operation relative to a legacy system it is replacing
(3) Conversion of operational databases
(4) Training of users and maintainers
The transition phase concludes when the deployment baseline has achieved the
complete vision. For some projects, this life-cycle end point may coincide with the
lifecycle starting point for the next version of the product. For others, it may coincide
with a complete delivery of the information sets to a third party responsible for
operation, maintenance, and enhancement. The transition phase focuses on the
activities required to place the software into the hands of the users. Typically, this phase
includes several iterations, including beta releases, general availability releases, and
bug-fix and enhancement releases. Considerable effort is expended in developing user-
oriented documentation, training users, supporting users in their initial product use, and
reacting to user feedback. At this point in the life cycle, user feedback should be
confined mostly to product tuning, configuring, installing, and usability issues.
Primary Objectives
 Achieving user self-supportability
 Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
 Achieving final product baselines as rapidly and cost-effectively as practical
Essential activities:
 Synchronization and integration of concurrent construction increments into
consistent deployment baselines
 Deployment-specific engineering (cutover, commercial packaging and production,
sales rollout kit development, field personnel training)
 Assessment of deployment baselines against the complete vision and acceptance
criteria in the requirements set.
Evaluation Criteria:
 Is the user satisfied?
 Are actual resource expenditures versus planned expenditures acceptable?

35
Q.7. (C)
What is the significance of Periodic Assessments? Discuss the
contents of Status Assessment Review.
SOLUTION
Significance Of Periodic Assessments:
 They provide a mechanism for Openly Addressing, Communicating, and Resolving
Management Issues, Technical Issues, and Project Risks.
 Objective data derived directly from On-Going Activities and Evolving Product
Configurations.
 Provide a mechanism for Disseminating Process, Progress, Quality Trends,
Practices, and Experience Information to and from all Stakeholders in an open
forum.
Default Content of Status Assessment Reviews:
Personnel:
 Staffing Plan Vs. Actuals
Financial Trends:
 Expenditure Plan Vs. Actuals for the Previous, Current, and Next Major Milestones
 Revenue Forecasts
Top 10 Risks:
 Issues and Critically Resolution Plans
 Quantification (cost, time, quality) of exposure
Technical Progress:
 Configuration Baseline Schedules for Major Milestones
 Software Management Metrics and Indicators
 Current Change Trends
Major Milestone Plans and Results:
 Plan, Schedule, and Risk for the Next Major Milestone
 Pass/Fail Results for all Acceptance Criteria
Total Product Scope:
 Total Size, Growth, and Acceptance Criteria Perturbations.

36
Q.7. (D) Discuss the primitive components of a Software Change Order.
SOLUTION
Software Change Order (SCO):
 The atomic unit of software work that is authorized to create, modify, or obsolesce
components within a configuration baseline is called a Software Change Order
(SCO).
 Software Change Orders (SCO) are a key mechanism for partitioning, allocating,
and scheduling software works against an established software baseline and for
assessing progress and quality.
 The example of SCO as shown in figure below is a good starting point for describing
a set of change primitives.

37
Figure 6: The Primitive Components Of A Software Change Order

38
Title:
 Title is composed by the user of the software who is an external person and tells
about his major problem regarding the software.
 Afterwards, this title is compiled by the originator and finalized by the
configuration control board (CCB).
Description:
 Description is composed of originators name, date is mentioned. When CCB
finalized title, then addition to that CCB also assigned SCO identifier and version.
These two fields are also mentioned in the description.
 The written description is in brief formats including all the details such as problem
codes, view snapshots, error and alert message and few other relevant data by
which change is stated in simple words.
Metrics:
 This is one of the important entities of the SCO.
 It is used for planning, scheduling and making improvement.
Resolution:
 This filed contains the analyst that means the person who is perform change,
implement on that component which should be change, metrics and related
description.
Assessment:
 This field contains the assessment methods such as Inspection, Analysis,
Demonstrate and Testing etc.
Disposition:
 This field contains the state which is approved by the Configuration Control Board
(CCB).

39
Q.7. (E) Write a short note on SPCP (Software Project Control Panel).
SOLUTION
Software Project Control Panel (SPCP):
The Software Project Control Panel (SPCP) is an example of metrics automation
approach that collects, organizes & reports values and trends extracted directly from
the evolving engineering artifacts.
Start the SPCP:
The SPCP starts and shows the most current information that was saved when the user
last used the SPCP.
Select a Panel Preference:
The user selects from a list of previously defined default panel preferences. The SPCP
displays the preference selected.
Select a Value or Graph Metric:
The user selects whether the metric should be displayed for a given point in time or in
a graph, as a trend. The default for values is the most recent measurement available.
The default for trends is monthly.
Select to Superimpose Controls:
The user points to a Graphical Object and requests that the control values for that metric
and point in the time be displayed. In the case of trends, the controls are shown
superimposed with the metric.
Drill down to trend:
The user points to a Graphical Object displaying a point in the time and drills down to
view the trend for the metric.
Drill down to Point In Time:
The user points to a Graphical Object displaying a trend and drills down to view the
values for the metric.
Drill down to lower levels of information:
The users points to a Graphical Object displaying a point in time and drills down to view
the next level of information.
Drill down to Lower Level of Indicators:
The user points to a Graphical Object displaying an indicator and drills down to view the
breakdown of the next level of indicators.

40
Q.7. (F) Write a short note on "Next Generation Cost Models".
SOLUTION
Next Generation Cost Models:
𝑬𝒇𝒇𝒐𝒓𝒕 = 𝑭(𝑻 𝑨𝒓𝒄𝒉, 𝑺 𝑨𝒓𝒄𝒉, 𝑸 𝑨𝒓𝒄𝒉, 𝑷 𝑨𝒓𝒄𝒉) + 𝑭(𝑻 𝑨𝒑𝒑, 𝑺 𝑨𝒑𝒑, 𝑸 𝑨𝒑𝒑, 𝑷 𝑨𝒑𝒑, )
𝑻𝒊𝒎𝒆 = 𝑭(𝑷 𝑨𝒓𝒄𝒉, 𝑬𝒇𝒇𝒐𝒓𝒕 𝑨𝒓𝒄𝒉) + 𝑭(𝑷 𝑨𝒑𝒑, 𝑬𝒇𝒇𝒐𝒓𝒕 𝑨𝒑𝒑)
Where,
T = Technology Parameter (environment automation support)
S = Scale Parameter (such as use case, function points, source lines of code)
Q = Quality Parameter (such as portability, reliability, performance)
P = Process Parameter (such as maturity, domain experience)
Engineering Stage:
 Risk Resolution, Low-Fidelity Plan
 Schedule/Technology-Driven
 Risk Sharing Contracts/Funding
Figure 7: Engineering Stage

41
Team Size:
 Architecture: small team of software engineers
 Applications: small team of domain engineers
 Small and expert as possible
Product:
 Executable Architecture
 Production Plans
 Requirements
Focus:
 Design and Integration
 Host Development Environment
Phases:
 Inception and Elaboration
Production Stage:
 Low-Risk, High-Fidelity Plan
 Cost-Driven
 Fixed-Price Contracts/Funding
Figure 8: Production Stage

42
Team Size:
 Architecture: small team of software engineers.
 Applications: as many as needed
 Large and diverse as needed
Product:
 Deliverable, Useful Function
 Tested Baselines
 Warranted Quality
Focus:
 Implement, Test, and Maintain
 Target Technology
Phases:
 Construction and Transition
☮☮☮

Project Management (April - 2015) [CBSGS - Paper Solution] {Mumbai University}

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

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

Similar to Project Management (April - 2015) [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 (April - 2015) [CBSGS - Paper Solution] {Mumbai University}