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

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

1
© Mumbai B.Sc.IT Study Kamal T.
Project Management
Paper Solution
 University: University of Mumbai
 Year: April – 2014
 Course: B.Sc.IT (Information Technology)
 Semester: VI
 Subject: Project Management
 Syllabus: CBSGS – 60:40 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 – 2014 | CBSGS – 60:40 PATTERN
BY
KAMAL THAKUR

4
Time: 2 ½ Hours Total Marks: 60
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 "Royce's Analysis" towards Waterfall Model..............................................6
Q What are the factors that can be abstracted with Software Economics? Explain in
detail..........................................................................................................................8
Q How can the team effectiveness be improved? Explain. .........................................9
Q Write a short note on "Function Points"................................................................10
Q Enlist any ten principles of Conventional Process..................................................11
Q Explain the significance of Vision Document. ........................................................13
Q Write a short note on Management Perspective Architecture. ............................14
Q Explain the different Lifecycle Phases in detail......................................................14
Q Explain Iteration Workflows. ..................................................................................16
Q "In order to ensure the consistency on various Artifacts, the Major Milestones
Concentrate on Objective, Operational Capabilities, & Release Issues". Explain
this statement. ........................................................................................................18
Q Explain different levels of evolutionary work Breakdown Structure....................19
Q Enlist the Top Seven Workflows and explain any four of them in detail. .............19
Q Explain about "Line-of-Business" Organization. ....................................................21
Q Explain the term "Software Project Team Evolution". ..........................................22
Q Explain the basic fields of Software Change Order with the help of a template of
the same. .................................................................................................................23

5
Q "Project software standard is to be set by organization policy." Explain the
statement. ...............................................................................................................25
Q Explain the three Management Indicators' Metrics in detail. ...............................27
Q Write a short note on Pragmatic Software Metrics. ..............................................29
Q Explain the two dimensions of process discriminate with neat diagram..............30
Q Enlist the factors of tailoring a software process framework. Explain the scale
factor in detail. ........................................................................................................31
Q Explain the term "Next Generation Software Economics"....................................33
Q Explain the steps or strategies to make Error-Free Software................................34
Q Write an exhaustive note on "Culture Shift". ........................................................35
Q Explain how Modern Process Transition claims to be Fruitful. .............................37

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A) Explain "Royce's Analysis" towards Waterfall Model.
SOLUTION
Waterfall Model in Theory:
The waterfall model is a sequential design process, used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of conception, initiation, analysis, design, construction, testing,
production/implementation and maintenance.

7
Figure 1: The Waterfall Model
Program Design Comes First:
The first improvement is to insert a preliminary program design phase between the
software requirements generation phase and the analysis phase.

8
Document The Design:
The amount of documentation for most software programs is very large. This much
documentation is required because
 Each designer must communicate with interfacing designers, managers, and
possibly customers.
Do It Twice:
If a computer program is being developed for the first time, arrange matters so that
the version finally delivered to the customer for operational deployment is actually
the second version insofar as critical design/operations are concerned.
Plan, Control and Monitor Testing:
All the project resources such as manpower, computer time, and/or management
judgment will be gone through in the testing phase, which is the phase of greatest risk
in terms of cost and schedule.
Involve The Customer:
It is important to involve the customer in a formal way so that he has committed
himself at earlier points before final delivery.
Q.1. (B)
What are the factors that can be abstracted with Software
Economics? Explain in detail.
SOLUTION
Factors that can be abstracted with Software Economics
Most software cost models can be abstracted into a function of five basic parameters:
size, process, personnel, environment, and 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.
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.

9
Environment:
The environment, which is made up of the tools and techniques available to support
efficient software development and to automate the process.
Required Quality:
The required quality of the product, including its features, performance, reliability,
and adaptability.
Q.1. (C) How can the team effectiveness be improved? Explain.
SOLUTION
Team Effectiveness can be Improved:
Team Effectiveness can be improves by following 5 ways:
1) 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) On software teams, however, it is common for talented programmers to seek
promotions to architects and managers. I think the skill sets are equally different,
because most superstar programmers are innately unqualified to be architects
and managers, and vice versa. Yet individuals and even their organizations often
view such promotion as desirable. There are countless cases of great software
engineers being promoted prematurely into positions for which they were
unskilled and unqualified. This makes a B Player out of an A Player, taking an A
Player out of a moderate-to high-leverage position and putting a B Player in a
higher leverage position. It’s a double whammy.
3) Organizational training programs are typically strategic undertakings with
educational value. Project training programs are purely tactical, intended to be
useful and applied the day after training ends.
4) These dimensions include:
 Raw Skills: intelligence, objectivity, creativity, organization, analytical
thinking
 Psychological Makeup: Leaders and followers, risk takers and conservatives,
visionaries and nitipickers, cynics and optimists.

10
Q.1. (D) Write a short note on "Function Points".
SOLUTION
Function Points:
The Function Points Methodology:
 Input files and input transactions (batch interfaces)
 Screens (adds, changes, deletes)
 Control Information
 Internal Logical Files (tables, files with data, control files)
 External tables and referenced files from other applications.
 Output files and transactions (batch interfaces)
 Other outputs – Reports Files, DVD's, Views, Notices, Warnings

11
Q.2. (A) Enlist any ten principles of Conventional Process.
SOLUTION
Principles of Conventional Process:
There are many descriptions of engineering software "the old way." After years of
software development experience, the software industry has learned many lessons
and formulated many principles.
1) Make Quality #1:
 Defining quality commensurate with the project at hand is important but is not
easily done at the outset of a project.
 Consequently, a modern process framework strives to understand the trade-offs
among features, quality, cost, and schedule as early in the life cycle as possible.
 Until this understanding is achieved, it is not possible to specify or manage the
achievement of quality.
2) High-quality Software is Possible:
 Techniques that have been demonstrated to increase quality include involving
the customer, prototyping, simplifying design, conducting inspections, and
hiring the best people.
 This principle is mostly redundant with others.

12
3) Give Products to Customers Early:
 This is a key tenet of a modern process framework, and there must be several
mechanisms to involve the customer throughout the life cycle.
 Depending on the domain, these mechanisms may include demonstrable
prototypes, demonstration based milestones, and alpha/beta releases.
4) Determine the Problem Before Writing the Requirements:
 This principle is a clear indication of the issues involved with the conventional
requirements specification process.
 The parameters of the problem become more tangible as a solution evolves.
 A modern process framework evolves the problem and the solution together
until the problem is well enough understood to commit to full production.
5) Evaluate Design Alternatives:
 This principle seems anchored in the waterfall mentality in two ways:
(1) The requirements precede the architecture rather than evolving together.
(2) The architecture is incorporated in the requirements specification.
 While a modern process clearly promotes the analysis of design alternatives,
these activities are done concurrently with requirements specification.
6) Use An Appropriate Process Model:
 It's true that no individual process is universal.
 The term process framework is used to represent a flexible class of processes
rather than a single rigid instance.
7) Use different Languages for different Phases:
 Our industry's eternal thirst for simple solutions to complex problems has driven
many to declare that the best development method is one that uses the same
notation throughout the life cycle.
 This is an important principle.
8) Minimize Intellectual Distance:
 To minimize intellectual distance, the software's structure should be as close as
possible to the real-world structure.
 This principle has been the primary motivation for the development of object
oriented techniques, component-based development, and visual modeling.

13
9) Put Techniques before Tools:
 Although this principle is valid, it misses two important points:
(1) A disciplined software engineer with good tools will out-produce disciplined
software experts with no tools.
(2) One of the best ways to promote, standardize, and deliver good techniques
is through automation.
10) Get it right before you make it Faster:
 It is far easier to make a working program run faster than it is to make a fast
program work.
 Don't worry about optimization during initial coding.
 This is an insightful statement.
Q.2. (B) Explain the significance of Vision Document.
SOLUTION
Significance of Vision Document:
 The vision statement should include a description of what will be included as
well as those features considered but not included.
 It should also specify operational capacities, user profiles, and interoperational
interfaces with entities outside the system boundary, where applicable.
 The vision should not be defined only for the operating level, its likely evolution
path should be addressed so that there is a context for accessing design
adaptability.
 The operational concept involves specifying the use cases and scenarios for
nominal and off-nominal usage.
 The use-case representation provides a dynamic context for understanding and
refining the scope, for assessing the integrity of a design model, and for
developing acceptable procedures.
 The vision document provides the contractual basis for the requirements visible
to the stakeholders.

14
Q.2. (C) Write a short note on Management Perspective Architecture.
SOLUTION
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) Explain the different Lifecycle Phases in detail.
SOLUTION
Different Lifecycle Phases:
Figure 2: The phases of the life-cycle process

15
Construction Phase: Objectives
 Minimize development costs by optimizing resources.
 Avoid unnecessary restarts (modeling, coding).
 Achieve adequate quality as fast as possible.
 Achieve useful version.
 Alpha, beta, and other test releases.
Transition Phase:
 The transition phase is entered when a baseline is mature enough that it can be
deployed to the user community.
 For some project the transition phase is the starting point for the next version.
 For other projects the transition phase is a complete delivery to a third party
responsible for operation, maintenance and enhancement of the software
system.

16
Q.3. (A) Explain Iteration Workflows.
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:

17
Figure 3: 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

18
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)
"In order to ensure the consistency on various Artifacts, the
Major Milestones Concentrate on Objective, Operational
Capabilities, & Release Issues". Explain this statement.
SOLUTION
 The life-cycle objectives milestones occurs at the end of the inception phase.
 The goal is to present to all stakeholders a recommendation on how to proceed
with development, including a plan, estimated cost and schedule, and expected
benefits and cost saving.
 The initial operational capability milestone occurs late in the construction phase.
 The goals are to assess the readiness of the software to begin the transition into
customer/user sites and to authorize the start of acceptance testing.
 Issues are addressed concerning installation instructions, software version
descriptions, user and operator manuals, and the ability of the development
organization to support user sites.
 Software quality metrics are reviewed to determine whether quality is sufficient
for transition.

19
Q.3. (C)
Explain different levels of evolutionary work Breakdown
Structure.
SOLUTION
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.
 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)
Enlist the Top Seven Workflows and explain any four of them in
detail.
SOLUTION
Workflow-wise Life Cycle & Emphasis:
(1) Management Workflow
(2) Environment Workflow
(3) Requirements Workflow
(4) Design Workflow
(5) Implementation Workflow
(6) Assessment Workflow
(7) Deployment Workflow
Management Workflow:
 Inception – Prepare Business Case and Vision
 Elaboration – Plan Development
 Construction – Monitor and Control Development
 Transition – Monitor and Control Development

20
Environment Workflow:
 Inception – Define Development Environment and Change Management
Infrastructure.
 Elaboration – Install Development Environment and Change Management
Database.
 Construction – Maintain Development Environment and Software Change order
Database.
 Transition – Transition Maintenance Environment and Change Order Database.
Requirements Workflow:
 Inception – Define Operational Concept
 Elaboration – Define Architecture Objectives
 Construction – Define Iteration Objectives
 Transition – Refine Release Objectives
Design Workflow:
 Inception – Formulate Architecture Concept
 Elaboration – Achieve Architecture Baseline
 Construction – Design Components
 Transition – Refine Architecture and Components
Implementation Workflow:
 Inception – Support Architecture Prototypes
 Elaboration – Produce Architecture Baseline
 Construction – Produce Complete Componentry
 Transition – Maintain Components

21
Q.4. (A) Explain about "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.
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.

22
Q.4. (B) Explain the term "Software Project Team Evolution".
SOLUTION
Software Project Team Evolution:
 The Project Organization represents the Architecture of the team and needs to
evolve consistent with the project plan captured in the work breakdown structure.
 The figure given below illustrates how the team’s center of gravity shifts over the
life cycle, with about 50% of the staff assigned to one set of activities in each phase
Figure 4: Software Project Team Evolution over the Life Cycle
A different set of activities is emphasized in each phase, as follows:
Inception Team:
An organization focused on planning, with enough support from the other teams to
ensure that the plans represent a consensus of all perspectives
Elaboration Team:
An architecture-focused organization in which the driving forces of the project reside
in the software architecture team and are supported by the software development
and software assessment teams as necessary to achieve a stable architecture baseline
Construction Team:
A fairly balanced organization in which most of the activity resides in the software
development and software assessment teams

23
Transition Team:
A customer-focused organization in which usage feedback drives the deployment
activities
Q.4. (C)
Explain the basic fields of Software Change Order with the help
of a template of the same.
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.

24
Figure 5: 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).

25
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).
Q.4. (D)
"Project software standard is to be set by organization policy."
Explain the statement.
SOLUTION
 The organization policy is the defining document for the organization's software
policies.
 In any process assessment, this is the tangible artifact that says what you do.
 From this document, reviewers should be able to question and review projects
and personnel and determine whether the organization does what it says.
 The figure below shows a general outline for an organizational policy.

26
Figure 6: Organization Policy Outline

27
Q.5. (A) Explain the three Management Indicators' Metrics in detail.
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):
The basic parameters of an earned value system, usually expressed in units of dollars,
are as follows:

28
 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.
(3) Staffing and Team Dynamics (Staffing Progress):
 An iterative development should start with a small team until the risks in the
requirements and architecture have been suitably resolved.
 Depending on the overlap of iterations and other project-specific circumstances,
staffing can vary.
 For discrete, one of-a-kind development efforts (such as building a corporate
information system), the staffing profile in the figure given below would be
typical.
 It is reasonable to expect the maintenance team to be smaller than the
development team for these sorts of developments.
 For a commercial product development, the sizes of the maintenance and
development teams may be the same.

29
Figure 7: Typical Staffing Profile
Q.5. (B) Write a short note on Pragmatic Software Metrics.
SOLUTION
Pragmatic Software Metrics:
 Measuring is useful, but it doesn’t do any thinking for the decision makers.
 It only provides data to help them ask the right questions, understand the
context, and make objective decisions.
 Because of the highly dynamic nature of software projects, these measures must
be available at any time, tailorable to various subsets of the evolving product
(release, version, component, class), and maintained so that trends can be
assessed (first and second derivatives with respect to time).
 This situation has been achieved in practice only in projects where the metrics
were maintained on-line as an automated by-product of the
development/integration environment.
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.

30
Q.5. (C)
Explain the two dimensions of process discriminate with neat
diagram.
SOLUTION
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
Figure 8: The Two Primary Dimensions of Process Variability

31
Q.5. (D)
Enlist the factors of tailoring a software process framework.
Explain the scale factor in detail.
SOLUTION
Factors of Tailoring a Software Process Framework:
Technical Complexity:
Higher Technical Complexity:
 Embedded, Real-Time, Distributed, Fault-Tolerant
 High-Performance, Portable
 Unprecedented, Architecture Re-Engineering
Lower Technical Complexity:
 Straightforward Automation, Single Thread
 Interactive Performance, Single Platform
 Many Precedent Systems, Application Reengineering
Management Complexity:
Higher Management Complexity:
 Large Scale
 Contractual
 Many Stakeholders
 "Projects"
Lower Management Complexity:
 Smaller Scale
 Informal
 Few Stakeholders
 Few Stakeholders
 "Products"
Scale Factor:
 The single most important factor in tailoring a software process framework to the
specific needs of a project is the total scale of the software application.
 There are many ways to measure scale, including number of source lines of code,
number of function points, number of use cases, and number of dollars.
 From a process tailoring perspective, the primary measure of scale is the size of
the team.
 As the headcount increases, the importance of consistent interpersonal
communications becomes paramount. Otherwise, the diseconomies of scale can
have a serious impact on achievement of the project objectives.

32
 There is fundamentally different management approaches needed to manage a
team of 1 (trivial), a team of 5 (small), a team of 25 (moderate), a team of 125
(large), a team of 625 (huge), and so on.
 As team size grows, a new level of personnel management is introduced at
roughly each factor of 5. This model can be used to describe some of the process
differences among projects of different sizes.

33
Q.6. (A) Explain the term "Next Generation Software Economics".
SOLUTION
Next Generation Software Economics:
 Next-Generation software economics means several provocative hypotheses
about the future of software economics.
 A general structure is proposed for a cost estimation model that would be better
suited to the process framework.
 This new approach would improve the accuracy and precision of software cost
estimates, and would accommodate dramatic improvements in software
economies of scale.
 A next-generation software cost model should explicitly separate architectural
engineering from application production.
 The cost of designing, producing, testing, and maintaining the architecture
baseline is a function of scale, quality, technology, process, and team skill.

34
Q.6. (B) Explain the steps or strategies to make Error-Free Software.
SOLUTION
Steps or Strategies to make Error-Free Software:
(1) Continuous Integration
(2) Early Risk Resolution
(3) Evolutionary Requirements
(4) Teamwork among Stakeholders
Continuous Integration:
 Iterative development produces the architecture first, allowing integration to
occur as the verification activity of the design phase and enabling design flaws
to be detected 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.
 The continuous integration inherent in an iterative development process also
enables better insight into quality trade-offs.
Early Risk Resolution:
 The engineering stage of the life cycle focuses on confronting the risks and
resolving them before the big resource commitments of the production stage.
 Conventional projects usually do the easy stuff first, thereby demonstrating
early progress.
 A modern process attacks the important 20% of the requirements, use cases,
components, and risks.
 This is the essence of the most important principle of modern processes:
architecture first.
 Defining the architecture rarely includes simple steps for which visible progress
can be achieved easily.
 The effect of the overall life-cycle philosophy on the 80/20 lessons learned over
the past years of software management experience provides a useful risk
management perspective.
 80% of the engineering is consumed by 20% of the requirements.
 80% of the software cost is consumed by 20% of the components.
 80% of the errors are caused by 20% of the components.
 80% of software scrap and rework is caused by 20% of the changes.
 80% of the resource consumption (execution time, disk space, memory) is
consumed by 20% of the components.
 80% of the progress is made by 20% of the people.

35
Evolutionary Requirements:
 Conventional approaches decomposed system requirements into subsystem
requirements, subsystem requirements into component requirements, and
component requirements into unit requirements.
 The organization of requirements was structured so that traceability was simple.
With an early life-cycle emphasis on requirements first, design second, and then
complete traceability between requirements and design components, the
natural tendency was for the design structure to evolve into an organization that
closely paralleled the structure of the requirements organization.
 It was no surprise that functional decomposition of the problem space led to a
functional decomposition of the solution space.
Teamwork among Stakeholders:
 Many aspects of the classic development process cause stakeholder
relationships to degenerate into mutual distrust, making it difficult to balance
requirements, product features, and plans.
 A more iterative process, with more-effective working relationships between
stakeholders, allows trade-offs to be based on a more objective understanding
by everyone.
 This process requires that customers, users, and monitors have both
applications and software expertise, remain focused on the delivery of a usable
system (rather than on blindly enforcing standards and contract terms), and be
willing to allow the contractor to make a profit with good performance.
 It also requires a development organization that is focused on achieving
customer satisfaction and high product quality in a profitable manner.
Q.6. (C) Write an exhaustive note on "Culture Shift".
SOLUTION
Culture Shifts for the Transition to Modern Software Process:
Culture Shifts necessary for the transition to Modern Software Process as follows
below:
Lower Level and Mid-Level Managers are performers:
 There should be no "pure managers" in an organization or sub-organization with
25 or fewer people.
 The need for pure managers arises only when personnel resources exceed this
level.

36
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 of the products themselves.
 All stakeholders would be focused on these "real" milestones, with incremental
deliveries of useful functionality rather than speculative paper descriptions of
the end-item vision.
Ambitious Demonstrations are Encouraged:
 The purpose of early life-cycle demonstrations is to expose design flaws, not to
put up a facade.
 Stakeholders must not overreact to early mistakes, digressions, or immature
designs.
Good and Bad Project Performance is much more obvious earlier in the Life Cycle:
 In an iterative development, success breeds success, and early failures are
extremely risky to turn around.
 Real-world project experience has shown time and again that it is the early
phases that make or break a project.
Early Increments will be Immature:
 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.
 On the other hand, development organizations must be held accountable 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 (traceability, thoroughness, and
completeness) of the artifact sets until a baseline is achieved that is useful
enough and stable enough to warrant time-consuming analyses of these quality
factors.
 Otherwise, a project will squander early engineering cycles and precious
resources adding content and quality to artifacts that may quickly become
obsolete.
Real issues are surfaced and resolved systematically:
 Successful projects recognize that requirements and designs evolve together,
with continuous negotiation, trade-off, and bartering toward best value, rather
than blindly adhering to an ambiguous contract statement.

37
 On a healthy project that is making progress, it should be easy to differentiate
between real and apparent issues.
Quality assurance is everyone's Job, not a separate discipline
 Many organizations have a separate group called quality assurance.
 Quality assurance should be woven into every role, every activity, and every
artifact.
Performance issues arise early in the Life Cycle:
 Early performance issues are a sign of an immature design but a mature design
process.
 Stakeholders will usually be concerned over early performance issues.
Investments in automation are necessary:
 Because iterative development projects require extensive automation, it is
important not to underinvest in the capital environment.
 It is also important for stakeholders to acquire an integrated environment that
permits efficient participation in an iterative development.
Good software organizations should be more profitable:
 In the commercial software domain, this is not an issue.
 In most of the software contracting domain, especially government contracts, it
is definitely an issue.
Q.6. (D) Explain how Modern Process Transition claims to be Fruitful.
SOLUTION
Modern Process Transition claims to be Fruitful:
(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.

38
(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) 10. 80% of the contribution comes from 20% of the contributors.
☮☮☮

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

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

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

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