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

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

1
© Mumbai B.Sc.IT Study Kamal T.
Project Management
Paper Solution
 University: University of Mumbai
 Year: October – 2016
 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 – 2016 | 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 What are the key practices that improve Overall Software Quality? .....................6
Q Explain Predominant Cost Estimation process. List the attributes of Good
Software Cost Estimate.............................................................................................7
Q List Boehm's Top Ten Principles of Conventional Software Project Management.8
Q What are the five fundamental parameters of Software Cost Model?...................8
Q Explain the modern process approaches for solving top ten risks in the
conventional process...............................................................................................10
Q Explain the importance of software architecture. State the three different
aspects of software architecture from management perspective. .......................11
Q Give a brief account of Management Set Artifacts................................................12
Q Explain the primary objectives and essential activities for the elaboration
phase........................................................................................................................13
Q With the help of diagram, explain the workflow of an iteration. .........................14
Q Explain the four Major Milestones in a Project Life Cycle. ....................................16
Q Define WBS. Write a short note on evolutionary WBS..........................................17
Q Write short note on Periodic Status Assessment. List the contents of Status
Assessment Reviews. ..............................................................................................18
Q What are the main features of each Default Project Organization? List the
responsibilities of Software Management Team. ..................................................20
Q Explain the different states through which the Project Environment Artifacts
evolve.......................................................................................................................21

5
Q Discuss Organization’s Infrastructure from phase automation perspective.........22
Q State the responsibilities of PRA and SEEA. ...........................................................22
Q What are the three fundamental sets of Management Metrics? Explain any two
Management Indicators..........................................................................................23
Q Define the term – Change Traffic, Breakage, Rework, MTBF and Modularity......24
Q Explain the process discriminators that result from differences in Stakeholder
Cohesion. .................................................................................................................25
Q What are the different ways to measure scale of the project? Compare Trivial-
Sized Projects and Moderate-Sized Projects..........................................................25
Q Explain the nine best practices of Software Management listed by "Airline
Software Council"....................................................................................................27
Q Discuss Continuous Integration Approach of Modern Project Management. ......29
Q Discuss some indicators of a successful transition to a modern culture focused an
improved software business performance.............................................................29
Q Give an account of Next-Generation Software Cost Estimation Models. .............30
Q.7. Attempt Any Three Questions: (15 Marks)
Q Explain how Object Oriented Technology contributes to Software Economics. List
Booch’s reasons for the success of object-oriented projects. ...............................33
Q Define Artifact. Write a short note on Vision Document and Software User
Manual.....................................................................................................................34
Q Discuss Bottom-Up Approach for Cost and Schedule Estimating process.............34
Q Write short note on Configuration Baseline. .........................................................35
Q Explain the basic characteristics of a Good Metric. ...............................................35
Q Compare the characteristics of Conventional Software Process with Modern
Iterative Development Process Framework...........................................................36

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A)
What are 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
 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.

7
Q.1. (B)
Explain Predominant Cost Estimation process. List the attributes
of Good Software Cost Estimate.
SOLUTION
Predominant Cost Estimation Process:
Figure 1: The Predominant Cost Estimation Process
 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.

8
Q.1. (C)
List Boehm's Top Ten Principles of Conventional Software Project
Management.
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.
Q.1. (D)
What are the five fundamental parameters of Software Cost
Model?
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
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.

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

10
Q.2. (A)
Explain the modern process approaches for solving top ten risks
in the conventional process.
SOLUTION
Modern process approaches for solving conventional problems:
Conventional Process: Top
10 Risks
Impact Modern Process: Inherent Risk
Resolution Features
Late Breakage and Excessive
Scrap/Rework
Quality,
Cost,
Schedule
Architecture-First Approach
Iterative Development
Automated Change Management
Risk-Confronting Process
Attrition of Key Personnel Quality,
Cost,
Schedule
Successful, Early Iterations
Trustworthy Management and Planning
Inadequate Development
Resources
Quality,
Cost,
Schedule
Environment as first-class artifacts of
the process
Industrial-strength, integrated
environments
Model-Based Engineering Artifacts
Round-Trip Engineering

11
Adversarial Stakeholders Cost,
Schedule
Demonstration-Based Review
Use-Case-Oriented
Requirement/Testing
Necessary Technology
Insertion
Cost,
Schedule
Architecture-First Approach
Component-Based Development
Requirements Creep Cost,
Schedule
Iterative Development
Use Case Modeling
Demonstration-Based Review
Analysis Paralysis Schedule Demonstration-Based Review
Use-Case-Oriented
Requirements/Testing
Inadequate Performance Quality Demonstration-Based Performance
Assessment
Early Architecture Performance
Feedback
Overemphasis On Artifacts Schedule Demonstration-Based Assessment
Objective Quality Control
Inadequate Function Quality Iterative Development
Early Prototypes, Incremental Releases
Q.2. (B)
Explain the importance of software architecture. State the three
different aspects of software architecture from management
perspective.
SOLUTION
Importance of Software Architecture:
 Achieving a stable software architecture represents a significant project
milestone at which the critical make/buy decisions should have been resolved.
This life-cycle event represents a transition from the engineering stage of a
project, characterized by discovery and resolution of numerous unknowns, to the
production stage, characterized by management to a predictable development
plan.
 Architecture representations provide a basis for balancing the trade-offs
between the problem space (requirements and constraints) and the solution
space (the operational product).
 The architecture and process encapsulate many of the important (high-payoff or
high-risk) communications among individuals, teams, organizations, and
stakeholders.

12
 Poor architectures and immature processes are often given as reasons for project
failures.
 A mature process, an understanding of the primary requirements, and a
demonstrable architecture are important prerequisites for predictable planning.
 Architecture development and process definition are the intellectual steps that
map the problem to a solution without violating the constraints; they require
human innovation and cannot be automated.
Q.2. (C) Give a brief account of Management Set Artifacts.
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:
 Activity Breakdown and Financial Tracking Mechanism.
2. Business Case:
 Cost, Schedule, Profit Expectations.
3. Release Specifications:
 Scope, Plan, Objectives for Release Baselines.
4. Software Development Plan:
 Project Process Instance.
5. Release Descriptions:
 Results of release baselines.

13
6. Status Assessments:
 Periodic Snapshots of Project Progress.
7. Software Change Order Database:
 Description of Discrete Baseline Changes.
8. Deployment Documents:
 Cutover Plan, Training Course, Sales Rollout Kit.
9. Environment:
 Hardware and Software Tools, Process Automation, Documentation,
Training Collateral necessary to support the execution plan and the
production of the engineering artifacts.
Q.2. (D)
Explain the primary objectives and essential activities for the
elaboration phase.
SOLUTION
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).
 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.
Essential Activities:
 Elaborating the vision.
 Elaborating the process and infrastructure.
 Elaborating the architecture and selecting components.

14
Q.3. (A) With the help of diagram, explain the workflow of an iteration.
SOLUTION
Iteration Workflows:
 An iteration consists of a loosely sequential set of activities in various
proportions, depending on where the iteration is located in the development
cycle.
 Each iteration is defined in terms of a set of allocated usage scenarios.
 The components needed to implement all selected scenarios are developed and
integrated with the results of previous iterations.
 An individual iteration’s workflow, illustrated in the figure given below, generally
includes the following sequence:

15
Figure 2: The Workflow of an Iteration
1) Management:
Iteration planning to determine the content of the release and develop the detailed
plan for the iteration; assignment of work packages, or tasks, to the development team
2) Environment:
Evolving the software change order database to reflect all new baselines and changes
to existing baselines for all product, test, and environment components
3) Requirements:
Analyzing the baseline plan, the baseline architecture, and the baseline requirements
set artifacts to fully elaborate the use cases to be demonstrated at the end of this
iteration and their evaluation criteria; updating any requirements set artifacts to
reflect changes necessitated by results of this iteration's engineering activities
4) Design:
Evolving the baseline architecture and the baseline design set artifacts to elaborate
fully the design model and test model components necessary to demonstrate against
the evaluation criteria allocated to this iteration; updating design set artifacts to reflect
changes necessitated by the results of this iteration’s engineering activities

16
5) Implementation:
Developing or acquiring any new components, and enhancing or modifying any
existing components, to demonstrate the evaluation criteria allocated to this iteration;
integrating and testing all new and modified components with existing baselines
(previous versions)
6) Assessment:
Evaluating the results of the iteration, including compliance with the allocated
evaluation criteria and the quality of the current baselines; identifying any rework
required and determining whether it should be performed before deployment of this
release or allocated to the next release; assessing results to improve the basis of the
subsequent iteration’s plan
7) Deployment:
Transitioning the release either to an external organization (such as a user,
independent verification and validation contractor, or regulatory agency) or to internal
closure by conducting a post-mortem so that lessons learned can be captured and
reflected in the next iteration.
Q.3. (B) Explain the four Major Milestones in a Project Life Cycle.
SOLUTION
Major Milestones in a Project Life Cycle:
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
Milestones Plans Understanding
of problem
space
(requirements)
Solution
Space
Progress
(Software
Product)
Life-Cycle
Objectives
Milestone
Definition of
stakeholder
responsibilities
Low-fidelity life-
cycle plan
Baseline vision,
including growth
vectors, quality
attributes, and
priorities
Demonstration of
at least one feasible
architecture
Make/buy/reuse
trade-offs

17
High-fidelity
elaboration
phase plan
Use case model Initial Design Model
Life-Cycle
Architecture
Milestone
High-fidelity
construction
phase plan (bill
of materials,
labor allocation)
Low-Fidelity
Transition Phase
Plan
Stable Vision and Use
Case Model
Evaluation Criteria for
Construction Releases,
Initial Operational
Capability
Draft User Manual
Stable Design Set
Make/buy/reuse
decisions
Critical Component
Prototypes
Initial
Operational
Capability
Milestone
High-Fidelity
Transition Phase
Plan
Acceptance Criteria for
Product Release
Releasable User
Manual
Stable
Implementation Set
Critical features and
core capabilities
Objective insight
into Product
Qualities
Product
Release
Milestone
Next-Generation
Product Plan
Final User Manual Stable Deployment
Set full features
Compliant Quality
Q.3. (C) Define WBS. Write a short note on evolutionary 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.
Evolutionary Work Break Down Structures:
 First-Level WBS Elements are the workflows (Management, Environment,
Requirements, Design, Implementation, Assessment, and Deployment). These
elements are usually allocated to a single team and constitute the anatomy of a
project for the purposes of planning and comparison with other projects.

18
 Second-Level Elements are defined for each phase of the life cycle (Inception,
Elaboration, Construction, and Transition). These elements allow the fidelity of
the plan to evolve more naturally with the level of understanding of the
requirements and architecture, and the risks therein.
 Third-Level Elements are defined for the focus of activities that produce the
artifacts of each phase. These elements may be the lowest level in the hierarchy
that collects the cost of a discrete artifacts for a given phase, or they may be
decomposed further into several lower level activities that, taken together,
produce a single artifact.
Q.3. (D)
Write short note on Periodic Status Assessment. List the contents
of Status Assessment Reviews.
SOLUTION
Periodic Status Assessments:
 Periodic Status Assessments Serve as project snapshots. While the period may
vary, the recurring event forces the project history to be captured and
documented.
 Status assessments provide the following:
 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.
 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

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

20
Q.4. (A)
What are the main features of each Default Project Organization?
List the responsibilities of Software Management Team.
SOLUTION
Features Of Default Organization:
The main features of Default Organization are as follows:
 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.
Responsibilities of Software Management Team:
1) Resource Commitments
2) Personnel Assignments
3) Plans and Priorities
4) Stakeholder Satisfaction
5) Scope Definition
6) Risk Management

21
7) Project Control
Q.4. (B)
Explain the different states through which the Project
Environment Artifacts evolve.
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.

22
Q.4. (C)
Discuss Organization’s Infrastructure from phase automation
perspective.
SOLUTION
From a process automation perspective the organisation infrastructure provides the
organization capital assets, including two key artifacts viz. organization policy and an
environment.
Organisation Policy:
 Captures standards for Project Software Development processes.
 Defines the lifecycle & the process primitives (major milestones, intermediate
artifacts, engineering repositors, metrics, roles and responsibilities).
Environment:
 Provides many of the answers to how things get done as well as the tools &
techniques to automate the process as much as practical.
Q.4. (D) State the responsibilities of PRA and SEEA.
SOLUTION
Project Review Authority (PRA):
 The Project Review Authority (PRA) responsible for ensuring that a software
project complies with all organizational and business unit software policies,
practices, and standards.
 The PRA reviews both the project’s conformance to contractual obligations and
the project’s organizational policy obligations.
 The PRA reviews customer commitments as well as adherence to organizational
policies, organizational deliverables, financial performance, and other risks and
accomplishments.
Software Engineering Environment Authority (SEEA):
 The Software Engineering Environment Authority (SEEA) is responsible for
automating the organization’s process, maintaining the organization’s standard
environment, training projects to use the environment, and maintaining
organization-wide reusable assets.
 The SEEA is responsible for supporting and administering a standard
environment.

23
Q.5. (A)
What are the three fundamental sets of Management Metrics?
Explain any two Management Indicators.
SOLUTION
Management Indicators:
There are three fundamental sets of management metrics:
(1) Work and Progress (Technical Progress)
(2) Budgeted Cost and Expenditures (Financial Status)
(3) Staffing and Team Dynamics (Staffing Progress)
(1) Work and Progress (Technical Progress):
The default perspectives of this metric would be as follows:
 Software Architecture Team: use cases demonstrated
 Software Development Team: SLOC under baseline change management, SCOs
closed
 Software Assessment Team: SCOs opened, test hours executed, evaluation
criteria met
 Software Management Team: milestones completed
(2) Budgeted Cost and Expenditures (Financial Status):

24
The basic parameters of an earned value system, usually expressed in units of dollars,
are as follows:
 Expenditure Plan: 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.
 Actual Progress: The technical accomplishment relative to the planned progress
underlying the spending profile. In a healthy project, the actual progress tracks
planned progress closely.
 Actual Cost: The actual spending profile for a project over its actual schedule. In
a healthy project, this profile tracks the planned profile closely.
 Earned Value: The value that represents the planned cost of the actual progress.
 Cost Variance: The difference between the actual cost and the earned value.
Positive values correspond to over-budget situations; negative values
correspond to under-budget situations.
 Schedule Variance: The difference between the planned cost and the earned
value. Positive values correspond to behind-schedule situations; negative values
correspond to a head-of-schedule situations.
Q.5. (B)
Define the term – Change Traffic, Breakage, Rework, MTBF and
Modularity.
SOLUTION
Change Traffic:
Defined as the number of software change orders opened & closed over the life cycle.
Breakage:
Defined as the average extent of change, which is the amount of software baseline
that needs rework.
Rework:
Defined as the average cost of change, which is the effort to analyse, resolve and retest
all changes to software baselines.
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.
Modularity:
The average breakage trend over time is known as Modularity.

25
Q.5. (C)
Explain the process discriminators that result from differences in
Stakeholder Cohesion.
SOLUTION
Process Discrimination that result from difference in Stakeholder Cohesion:
Q.5. (D)
What are the different ways to measure scale of the project?
Compare Trivial-Sized Projects and Moderate-Sized Projects.
SOLUTION
There are many ways to measure scale of the project, including SLOC, FP, numbers of
use cases, and number of dollars. From a process tailoring perspective, the primary
measure of scale is the size of the team.
Trivial-Sized Projects:
 Trivial-sized projects require almost no management overhead (planning,
communication, coordination, progress assessment, review, administration).
 There is little need to document the intermediate artifacts.
 Workflow is single-threaded.
 Performance is highly dependent on personnel skills.

26
Moderate-Sized Projects:
 Moderate-sized projects (25 people) require moderate management overhead,
including a dedicated software project manager to synchronize team workflows
and balance resources.
 Overhead workflows across all team leads are necessary for review,
coordination, and assessment.
 There is a definite need to communicate the intermediate artifacts among
teams.
 Project milestones are formally planned and conducted, and the impacts of
changes are typically benign.
 Performance is highly dependent on the skills of key personnel, especially team
leads.
 Process maturity is valuable.

27
Q.6. (A)
Explain the nine best practices of Software Management listed by
"Airline Software Council".
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.

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

29
Q.6. (B)
Discuss Continuous Integration Approach of Modern Project
Management.
SOLUTION
Continuous Integration Approach of Modern Project Management:
Iterative development produces the architecture first allowing integration to occur as
the verification activity of the design phase and enabling design flaws to be defected
and resolved earlier in the Life-Cycle.
 This approach avoids the big bang integration at the end of a project by stressing
continuous integration throughout the project.
 Architecture first approach forces integration into the design phase through the
construction of demonstrations.
 The continuous integration inherent in an iterative development process also
enables better insight into quality trade-offs.
Q.6. (C)
Discuss some indicators of a successful transition to a modern
culture focused an improved software business performance.
SOLUTION
Requirements and designs are fluid and tangible
 The conventional process focused too much on producing documents that
attempted to describe the software product and focused too little on producing
tangible increments.
 Iterative process requires actual construction of a sequence of progressively
more comprehensive systems that demonstrate the architecture, enable
objective requirements negotiations, validate the technical approach, and
address resolution of key risks.
Ambitious demonstrations are encouraged
 Early life-cycle demonstrations is to expose design flaws.
 Stakeholders must not overreact to early mistakes, digressions, or immature
designs.
 Stakeholders should not tolerate lack of follow-through in resolving issues.
 The management team is most likely to resist this transition, but Customers,
users, and the engineering team will embrace it.
Early increments will be immature

30
 External stakeholders, such as customers and users, cannot expect initial
deliveries to perform up to specification, to be complete, to be fully reliable, or
to have end-target levels of quality or performance.
 Organizations should account for, and demonstrate, tangible improvements in
successive increments.
Artifacts are less important early, more important later
 It is a waste of time to worry about the details of the artifact sets until a baseline
is achieved.
Q.6. (D)
Give an account of Next-Generation Software Cost Estimation
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

31
Figure 3: Engineering Stage
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

32
Figure 4: Production Stage
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

33
Q.7.Attempt Any Three Questions: (15 Marks)
Q.7. (A)
Explain how Object Oriented Technology contributes to Software
Economics. List Booch’s reasons for the success of object-
oriented projects.
SOLUTION
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.
 An Object-Oriented Architecture provides a clear separation of concerns
amongst disparate elements of a system.
Reasons:
 A ruthless focus on the development of a system that provides a well understood
collection of essential minimal characteristics.
 The existence of a culture that is centered on results encourages communication
& yet is not afraid to fail.
 The effective use of Object-Oriented Modelling.
 The existence of strong architectural vision.

34
 The application of a Well-Managed Iterative & Incremental Development Life
Cycle.
Q.7. (B)
Define Artifact. Write a short note on Vision Document and
Software User Manual.
SOLUTION
Artifacts:
 It represents Cohesive Information that typically is developed & reviewed as a
single entity.
 The two forms of requirements addressed in the release specification are:
1) Vision Statement
2) Evaluation Criteria
Vision Statement (or user need):
 It captures the contract between the development group & the buyer.
 This information varies slowly across the Life Cycle.
 It should be represented in a form that is understandable to the buyer.
 A use case model in the vision statement context servers to capture the
operational concept in terms the user/buyer will understand.
Software User Manual
 The software user manual provides the user with the reference documentation
necessary to support the delivered software.
 Should include installation procedures, usage procedures and guidance,
operational constraints, and a user interface description.
 should be written by members of the test team
Q.7. (C)
Discuss Bottom-Up Approach for Cost and Schedule Estimating
process.
SOLUTION
Bottom-Up Approach of Cost and Schedule Estimation:
1. Lowest Level WBS elements are elaborated into detailed tasks, for which budgets
and schedules are estimated by the responsible WBS element manager.
2. Estimates are combined and integrated into higher level budgets and milestones.
3. Comparisons are made with the top-down budgets and schedule milestones and
then Gross differences are assessed and adjusted.
The following planning sequence occurs as:

35
 There two planning approaches should be used together in balance throughout
the life cycle of the project.
 During the Engineering Stage the Top-Down perspective will dominate because
there is not enough depth in understanding.
 During the production Stage Bottom-Up Planning perspective will dominate
because there is enough precedent experience and Planning Fidelity.
Q.7. (D) Write short note on Configuration Baseline.
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.
Q.7. (E) Explain the basic characteristics of a Good Metric.
SOLUTION
Basic Characteristics of a Good Metric:
 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.

36
Q.7. (F)
Compare the characteristics of Conventional Software Process
with Modern Iterative Development Process Framework.
SOLUTION
Conventional Software Process Vs. Modern Iterative Process Framework:
Conventional Software Process:
 Sequentially transitioning from requirements to design to code to test.
 Achieving 100% completeness of each artifact at each life-cycle stage.
 Treating all requirements, artifacts, components, and so forth, as equals.
 Achieving high-fidelity traceability among all artifacts at each stage in the life
cycle.
Modern Iterative Process Framework:
A Modern Iterative Development Process Framework is characterized by the following:
 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.
☮☮☮

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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