Project Management (October - 2017) [CBSGS - Paper Solution] {Mumbai University}

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

1
© Mumbai B.Sc.IT Study Kamal T.
Project Management
Paper Solution
 University: University of Mumbai
 Year: October – 2017
 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)
OCTOBER – 2017 | 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 how software product size can be reduced. Also discuss how it
contributes to the improvement of Software Economics?......................................6
Q What are the best practices to be followed for improving the Overall Quality of
Software?...................................................................................................................7
Q Explain five symptoms of a project that is headed for trouble. ..............................8
Q Explain the three generations of Software Economics............................................9
Q What are the Primary Objectives during engineering stage of a Modern Software
Development Process?............................................................................................11
Q Explain the top five principles of Modern Management.......................................12
Q What is an Artifact? What are the two forms of requirements addressed in
release specification?..............................................................................................13
Q Explain the importance of Software Architecture. State the three different
aspects of Software Architecture from management perspective........................14
Q List the purpose of milestones in the Project Life Cycle. State the three types of
Joint Management Review......................................................................................15
Q Explain Forward and Backward – Looking approach of cost and schedule
estimating process...................................................................................................16
Q What is the significance of Periodic Status Assessments? Explain the Default
Content of Status Assessment Reviews..................................................................17
Q Explain the concept of Workflow? Describe Major Workflows involved in
Software Development. ..........................................................................................18

5
Q Why an independent team is used for Software Assessment? Explain the
activities of Software Assessment team over the Project Life Cycle.....................19
Q Explain the Automation Aids and tool components that support the process
workflows. ...............................................................................................................20
Q What are the main features of default Line-Of-Business Organization? What are
the typical components of the organizational infrastructure?..............................21
Q What is Software Change Order? What are the primitive components of a
Software Change Order?.........................................................................................22
Q What is Software Project Control Panel? Describe the basic operational concept
for an SPCP?.............................................................................................................25
Q Explain the differences in schedule distribution and workflow priorities for small
and large projects....................................................................................................26
Q Explain the key differences in the process primitives for varying levels of
Architectural Risk. ...................................................................................................27
Q What are the three fundamental sets of Management Metrics? Explain any two
Management Indicators..........................................................................................28
Q What are the characteristics of Modern Iterative Development Framework?
What are the steps to follow to transition to a mature iterative development
process? ...................................................................................................................29
Q Give an account of Next-Generation Software Cost Estimation Models. .............30
Q Discuss nine best practices of Software Management. .........................................30
Q With the help of diagram explain risk profile of a modern project across its Life
Cycle.........................................................................................................................32
Q.7. Attempt Any Three Questions: (15 Marks)
Q With the help of diagram explain Predominant Cost Estimation process. What
are the characteristics of a good estimate? ...........................................................33
Q Write short note on Implementation and Deployment Set...................................34
Q Define WBS. Write short note on evolutionary WBS.............................................35
Q Write short note on Organization Policy................................................................35
Q Define the terms – Adaptability, Breakage, Rework, Maturity and Stability. ......36
Q Explain any five indicators of a successful transition to a modern culture focused
an improved software business performance........................................................37

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A)
Explain how software product size can be reduced. Also discuss
how it contributes to the improvement of Software Economics?
SOLUTION
Software Product Size can be reduced by –
(i) Use of Higher Order Languages
(ii) Use of Object-Oriented Methodology
(iii) Reuse
(iv) Use of Commercial Components
Use of HLL:
Universal Function Points can be used to indicate the relative program sizes required
to implement a given functionality.
Program size varies depending on the language used to program the same Universal
Function Point.
Use of OOPM:
 An Object-Oriented Model of the problem and its solution creates a shared
understanding of the problem being solved.
 The use of continues integration creates opportunities to recognize risk early &
make incremental correction w/o destabilizing the entire development effort.

7
 An Object-Oriented Architecture provides a clear separation of concerns
amongst disparate elts of a system.
Reuse
 Most truly reusable components of value are transitioned to commercial
products supported by organization with following characteristics.
 They have an economic motivation for continue a support.
 They take ownership of improving product quality, adding new features &
transitioning to new technologies.
 They have a sufficiently broad customer base to be profitable.
Use of Commercial Components:
 Advantages Include
 Predictable License Costs
 Broadly used Mature Technology
 Available Now
 Dedicated Support Organisation
 Hardware and Software Independence
 Rich in Functionality
 How reduction in Software Product Size contributes to improvement of Software
Economics.
 Mature & reliable size reduction technologies are extremely powerful at
producing Economic benefits.
 Reduction is defined in terms of Human-generated source material. Reducing
this return on investment (ROT).
Q.1. (B)
What are the best practices to be followed for improving the
Overall Quality of Software?
SOLUTION
Five Key practices improve overall software quality:
 Following on driving requirements & critical use cases easily in the life cycle.
 Using metrics & indicators to measure the progress & quality of an architecture
as it evolves from a high-level prototype into a fully compliant product.
 Providing Integrated Life Cycle Environments that support easily & continuous
configuration control, Change Management, Regression Design Methods
Document Automation & Regression Text Automation.
 Using visual modelling & HLL that support architectural control, abstraction,
reliable programming reuse & self-documentation.

8
 Early & continuous insight into performance issues through demonstration based
evaluations.
Q.1. (C) Explain 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:
 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.
4) 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.
5) 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.

9
 Presenters & audience reviewed simple things rather than complex & important
issues.
Q.1. (D) Explain the three generations of Software Economics.
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
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.

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

11
Q.2. (A)
What are the Primary Objectives during engineering stage of a
Modern Software Development Process?
SOLUTION
Engineering Stage of a Modern Software Development process involves two phases
(viz. Inception & Elaboration). Each Phase has its own Primary Objectives.
Inception Phases - Primary Objectives:
 Establishing the project’s software scope and boundary conditions, including an
operational concept, acceptance criteria, and a clear understanding of what is
and is not intended to be in the product.
 Discriminating the critical use cases of the system and the primary scenarios of
operation that will drive the major design trade-offs.
 Demonstrating at least one candidate architecture against some of the primary
scenarios.
 Estimating the cost and schedule for the entire project.
 Estimating potential risks.
Elaboration Phases - Primary Objectives:
 Baselining the architecture as rapidly as practical (establishing a configuration-
managed snapshot in which all changes are rationalized, tracked, and
maintained).

12
 Baselining the vision.
 Baselining a high-fidelity plan for the construction phase.
 Demonstrating that the baseline architecture will support the vision at a
reasonable cost in a reasonable time.
Q.2. (B) Explain the top five principles of Modern Management.
SOLUTION
Top Five Principles Of Modern Management:
Figure 2: The Top Five Principles of a Modern Process
1) Base the process on an architecture-first approach.
 This requires that a demonstrable balance be achieved among the driving
requirements, the architecturally significant design decisions, and the life-cycle
plans before the resources are committed for full-scale development.
2) Establish an iterative life-cycle process that confronts
risk early.
 With today's sophisticated software systems, it is not possible to define the entire
problem, design the entire solution, build the software, and then test the end
product in sequence.
 Instead, an iterative process that refines the problem understanding, an effective
solution, and an effective plan over several iterations encourages a balanced
treatment of all stakeholder objectives.

13
 Major risks must be addressed early to increase predictability and avoid expensive
downstream scrap and rework.
3) Transition design methods to emphasize component-based
development.
 Moving from a line-of-code mentality to a component-based mentality is
necessary to reduce the amount of human-generated source code and custom
development.
 A component is a cohesive set of preexisting lines of code, either in source or
executable format, with a defined interface and behaviour.
4) Establish a change management environment.
 The dynamics of iterative development, including concurrent workflows by
different teams working on shared artifacts, necessitates objectively controlled
baselines.
5) Enhance change freedom through tools that support round-
trip engineering.
 Round-trip engineering is the environment support necessary to automate and
synchronize engineering information in different formats (such as requirements
specifications, design models, source code, executable code, test cases).
 Without substantial automation of this bookkeeping, change management,
documentation, and testing, it is difficult to reduce iteration cycles to manageable
time frames in which change is encouraged rather than avoided.
 Change freedom is a necessity in an iterative process, and establishing an
integrated environment is crucial.
Q.2. (C)
What is an Artifact? What are the two forms of requirements
addressed in release specification?
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.

14
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 life- cycle milestone.
Q.2. (D)
Explain the importance of Software Architecture. State the three
different aspects of Software Architecture from 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.

15
Q.3. (A)
List the purpose of milestones in the Project Life Cycle. State the
three types of Joint Management Review.
SOLUTION
Purpose of Milestones in the Project Life Cycle:
 Synchronize stakeholder expectations and achieve concurrence on three
evolving perspectives: the requirements, the design, and the plan.
 Synchronize related artifacts into a consistent and balanced state.
 Identify the important risks, issues, and out-of-tolerance conditions.
 Perform a global assessment for the whole life cycle, not just the current
situation of an individual perspective or intermediate product.
Three types of Joint Management Review:
Major Milestones:
These system wide events 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.
Minor Milestones:
These iteration-focused events are conducted to review the content of an iteration in
detail and to authorize continued work.

16
Status Assessments:
These periodic events provide management with frequent and regular insight into the
progress being made.
Q.3. (B)
Explain Forward and Backward – Looking 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.

17
These estimates tend to incorporate the project-specific parameters in an
exaggerated way.
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.3. (C)
What is the significance of Periodic Status Assessments? Explain
the Default Content of Status Assessment Reviews.
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

18
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.
Q.3. (D)
Explain the concept of Workflow? Describe 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: 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.

19
Q.4. (A)
Why an independent team is used for Software Assessment?
Explain the activities of Software Assessment team over the
Project Life Cycle.
SOLUTION
Reasons for using an Independent Team:
To ensure an independent quality perspective.
To exploit the concurrency of activities.
Activities over the Project Life Cycle:
Inception Phase:
 Planning of infrastructure.
 Prototyping of primary scenario.
Elaboration Phase:
 Baselining the Infrastructure.
 Testing of Architecture Release.
 Change Management.
 Initial User Manual.

20
Construction Phase:
 Infrastructure Upgrades.
 Release Testing.
 User Manual Baseline.
 Requirements Verification.
Transition Phase:
 Infrastructure Maintenance.
 Release Baselining.
 Deployment To Users
 Verification of Requirements.
Q.4. (B)
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.

21
Environment Workflow & Automation Aids:
 Configuration Management
 Version Control
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.4. (C)
What are the main features of default Line-Of-Business
Organization? What are the typical components of the
organizational infrastructure?
SOLUTION
Main features of 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.

22
Typical Components of the Organizational Infrastructure:
Project Administration:
 Time Accounting System
 Pricing, Terms and Conditions
 Corporate Information Systems Integration
Engineering Skill Centers:
 Custom Tools Repository and Maintenance
 Bid and Proposal Support
 Independent Research and Development
Professional Development:
 Internal Training Boot Camp
 Personnel Recruiting
 Personnel Skills Database Maintenance
 Literature and Assets Library
 Technical Publications
Q.4. (D)
What is Software Change Order? What are 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.

23
Figure 3: The Primitive Components Of A Software Change Order
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).

24
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).

25
Q.5. (A)
What is Software Project Control Panel? Describe the basic
operational concept for an SPCP?
SOLUTION
Software Project Control Panel:
 The concept was first recommended by the Airlie Software Council.
 SPCP maintains an online version of the status of evolving artifacts and thus
provides a key advantage.
 It provides a display panel that integrates data from multiple sources to show
the current status of some aspect of the project basic operational concept for a
SPCP.
To implement a complete SPCP, it is necessary to define and develop the
following:
Metrics Primitives:
Indicators, Trends, Comparisons, And Progressions.
Graphical User Interface:
GUI support for a software project manager role and flexibility to support other roles.

26
Metrics Collection Agents:
Data extraction from the environment tools that maintain engineering notations for
various artifacts sets.
Metrics Definitions:
Actual Metrics Presentations for Requirements Progress, Design Progress,
Implementation Progress, Assessment Progress, and other Progress Dimensions.
Actors:
Typically, the monitor and the administrator.
Q.5. (B)
Explain the differences in schedule distribution and workflow
priorities for small and large projects.
SOLUTION
Schedule Distribution across Phases for Small and Large Projects:
 A small project may require only 1 month of inception, 2 months of elaboration,
5 months of construction, and 2 months of transition. A large, complex project
may require 8 months of inception, 14 months of elaboration, 20 months of
construction, and 8 months of transition.
 Biggest difference is the relative time at which the life cycle architecture
milestone occurs. This corresponds to the amount of time spent in the
engineering stage compared to the production stage.
Figure 4: Schedule Distribution across Phases for Small and Large Projects

27
Differences in Workflow Priorities between Small and Large Projects
Figure 5: Differences in Workflow Priorities between Small and Large Projects
Q.5. (C)
Explain the key differences in the process primitives for varying
levels of Architectural Risk.
SOLUTION
Process Discriminators that result from differences in Architectural Risk:
Process
Primitive
Complete
Architecture
Feasibility
Demonstration
No Architecture
Feasibility
Demonstration
Life-Cycle Phases More Inception and
Elaboration Phase Iterations
Fewer Early Iterations
More Construction
Iterations
Artifacts Earlier breadth and depth
Across Technical Artifacts
(insignificant)
Workflow Effort
Allocations
Higher level of design effort
lower levels of
implementation and
assessment
Higher levels of
implementation and
assessment to deal with
increased scarp and rework.
Checkpoints More emphasis on
executable demonstrations
More emphasis on
briefings, documents, and
simulations
Management
Discipline
(insignificant) (insignificant)

28
Automation
Discipline
More environment resources
required earlier in the Life
Cycle.
Less environment demand
early in the Life Cycle.
Q.5. (D)
What are the three fundamental sets of Management Metrics?
Explain any two Management Indicators.
SOLUTION
Fundamental Sets Of Management Metrics:
There are three fundamental sets of management metrics:
1. Technical Progress
2. Financial Status
3. Staffing Progress
Management Indicator - Work and Progress:
 Various activities of an iterative development project can be measured by
defining a planned estimate of the work in an objective measure, then tracking
progress against that plan.
Management Indicator - Staffing and Team Dynamics:
 Depending on the overlap of iterations and other project-specific circumstances,
staffing can vary.
 Tracking actual versus planned staffing is a necessary and well-understood
management metric.
 Attrition and Additions is a management indicators of changes in project
momentum.

29
Q.6. (A)
What are the characteristics of Modern Iterative Development
Framework? What are 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.

30
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.
Q.6. (B)
Give an account of Next-Generation Software Cost Estimation
Models.
SOLUTION
Account Of Next-Generation Software Cost Estimation Models:
 Should explicitly separate architectural engineering from application production.
 Should estimate large scale architectures with economy & scale.
 Two major improvements in next-generation software cost estimation models.
 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) 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

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

32
Q.6. (D)
With the help of diagram explain risk profile of a modern project
across its Life Cycle.
SOLUTION
Risk Profile of a typical Modern Project across its Life Cycle:
 The engineering stage of the life cycle focuses on confronting the risks and
resolving them before the big resource commitments of the production stage.
 A modern process attacks the important 20% of the requirements, use cases,
components, and risks.
Figure 6: Risk Profile of a typical Modern Project across its Life Cycle

33
Q.7.Attempt Any Three Questions: (15 Marks)
Q.7. (A)
With the help of diagram explain Predominant Cost Estimation
process. What are the characteristics of a good estimate?
SOLUTION
Predominant Cost Estimation Process:
Figure 7: The Predominant Cost Estimation Process

34
 The software project manager defines the target cost of the software, then
manipulates the parameters & sizing until the target cost can be justified.
 It is necessary to analyse the cost risks & understand the sensitivities & tradeoffs
objectively.
Characteristics of a Good Estimate:
 It is conceived & supported by the Project Manager, Architecture Team,
Development Team & Test Team.
 It is accepted by all stakeholders as ambitious but realizable.
 It is based on a well-defined software cost model with credible basis.
 It is based on a database of relevant project experience that includes similar
environments, similar quality requirements and similar people.
 It is defined in enough detail so that its key risk areas are understood and the
probability of success is objectively assessed.
Q.7. (B) Write short note on Implementation and Deployment Set.
SOLUTION
Implementation Set:
 Includes source code that represents the tangible implantations of components
and only executables.
 The set artifacts can also be translated into a subset of deployment set.
 They are human-readable formats that are evaluated, assessed and measured.
Deployment Set:
 Includes User Deliverables & Machine Language Notations, Executable
Software, Build Scripts, installation scripts & executable target specified data
necessary to use the product in its Target Environment.
 Set information can be installed, executed against scenarios of use (tested) and
dynamically are configured to support the features required in the end product.

35
Q.7. (C) Define WBS. Write short note on evolutionary WBS.
SOLUTION
WBS:
A WBS is simply a hierarchy of elements that decomposes the project plan into discrete
work tasks.
Evolutionary WBS:
 Should organize the planning elements around the process framework rather
than the product framework.
 This approach better accommodates the expected changes in the evolving plan
& allows the level of planning fidelity to evolve in a straight forward way.
 Organizes the WBS as
 First Level WBS Elements:
- Workflows
- Elements are usually allocated to single team
- Constitute anatomy of a project for the purposes of planning &
comparison with other projects.
 Second Level WBS Elements:
- Defined for each Phase.
- Elements allow the fidelity of the plan to evolve.
 Waivers are the exception, not the rule.
 Appropriate policy is written at the appropriate level.
Q.7. (D) Write short note on Organization Policy.
SOLUTION
Organization Policy:
 The organization policy is usually packaged as a handbook that defines the life
cycle and the process primitives.
 The handbook provides a general framework for answering the following
questions:
 What gets done? (activities and artifacts)
 When does it get done? (mapping to the life-cycle phases and milestones)
 Who does it? (team roles and responsibilities)
 How do we know that it is adequate? (checkpoints, metrics, and standards of
performance)

36
Effective organizational policies have several recurring
themes:
 They are concise and avoid policy statements that fill 6-inch-thick documents.
 They confine the policies to the real shalls, then enforce them.
 They avoid using the word should in policy statements. Rather than a menu of
options (should), policies need a concise set of mandatory standards (shalls).
 Waivers are the exception, not the rule.
 Appropriate policy is written at the appropriate level.
Q.7. (E)
Define the terms – Adaptability, Breakage, Rework, Maturity and
Stability.
SOLUTION
Adaptability:
 It is the rework trend over time. For a healthy project, the trend expectation is
decreasing or stable.
Breakage:
 It is defined at the average extent of change, which is the amount of software
baseline that needs rework.
Rework:
 It is defined as the average cost of change, which is the effort to Analyse, resolve
& retest all changes to software baselines.
Maturity:
 It is defined as the MTBF trend overtime; when MTBF (Mean Time between
Failures) is the average usage time between software faults.
Stability:
 It is defined as the relationship between opened vs closed scos.

37
Q.7. (F)
Explain any five indicators of a successful transition to a modern
culture focused an improved software business performance.
SOLUTION
Five Indicators:
i) Lower Level & Mid-Level managers ate performers:
 There should be no "pure managers" in an organisation with 25 or fewer people.
 The person managing an effort should plan it.
ii) Requirements & Designs are fluid & tangible:
 An iterative process requires actual construction of a sequence of progressively
more comprehensive systems that demonstrate architecture.
 All stakeholders would be focused on "real" milestones.
 The Transition will be embraced by engineering teams.
iii) Ambitious demonstrations are encouraged:
 Open and attentive follow-through is necessary to resolve issues.
 Customers, users & the engineering team will embrace this transition for the
reason that it will expose any engineering or process issues that were easy to
hide using conventional process.
iv) Good and Bad Project Performance is much more obvious
earliest in the life cycle:
 Early phases make or break a project.
 If these phases are done right & with good teams, project can be successfully
completed.
v) Early Increments will be immature:
 External Stakeholders such as customers & users should not expect initial
deliveries to perform upto specification.
 Development Organizations must be held accountable for and demonstrate
tangible improvements in successive increments.
☮☮☮

Project Management (October - 2017) [CBSGS - Paper Solution] {Mumbai University}

Recommended

Recommended

More Related Content

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

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