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

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

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

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

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

4
Time: 2 ½ Hours Total Marks: 75
NOTES:
(1) All Question are Compulsory.
(2) Make Suitable Assumptions Wherever Necessary And State The Assumptions Made.
(3) Answer To The Same Question Must Be Written Together.
(4) Number To The Right Indicates Marks.
(5) Draw Neat Labeled Diagrams Wherever Necessary.
(6) Use of Non – Programmable Calculator is allowed.
Q.1. Attempt Any Two Questions: (10 Marks)
Q "You can compress software development schedule 25% of nominal, but no
more". Discuss with reference to conventional software management
performance. .............................................................................................................6
Q Explain the process of Cost Estimation.....................................................................7
Q Explain any two staffing principles to improve team effectiveness........................7
Q Explain the importance of Quality Parameter to improve Software Economics....8
Q List the phases of Life Cycle process. Explain the Elaboration Stage.......................9
Q Compare Meta and Macro processes.....................................................................10
Q Explain Architecture-First Approach of Modern Software Management. ............10
Q Explain the concept of architecture from management perspective....................10
Q Define the term Workflow. Explain requirement and Design Workflows. ...........12
Q What are the Check Points of the process? Explain the sequence of Check
Points. ......................................................................................................................13
Q Explain Iteration Readiness and Assessment Review............................................13
Q Define Work Breakdown Structure. Explain the issues with conventional WBS..14
Q What is Software Change Orders (SCO)? Explain the basic fields of SCO..............15
Q What are the responsibilities of Software Architecture Team? ............................16
Q Explain Project Environment with features to prototyping...................................16
Q Define the term Configuration Baseline. What are two classes of Baseline?.......17

5
Q What are Management Indicators? Explain any two.............................................18
Q Write a short note on Software Project Control Panel..........................................19
Q Explain the concept of process maturity................................................................20
Q Compare small commercial project with large, complex project on the basis of
workflow priorities..................................................................................................21
Q Explain Continuous Integration Approach of Modern Project Management. ......22
Q "80% of the errors are caused by 20% of the components". Discuss with
reference to early risk resolution. ..........................................................................23
Q Compare Conventional Software Process with Modern Iterative Process
Framework...............................................................................................................24
Q What do you understand by Culture Shifts with reference to Modern Process
Transition?...............................................................................................................24
Q What are the Basic Parameters of Software Economics?......................................25
Q List and explain the Implementation Set Artifact. .................................................26
Q Explain Bottom-Up Approach of Cost and Schedule Estimation. ..........................26
Q Write a note on Round Trip Engineering................................................................27
Q Describe any four Quality Indicators in detail........................................................28
Q What are the benefits of Next Generation Cost Estimation Models?...................29

6
Q.1.Attempt Any Two Questions: (10 Marks)
Q.1. (A)
"You can compress software development schedule 25% of
nominal, but no more". Discuss with reference to conventional
software management performance.
SOLUTION
"You can compress software development schedule 25% of nominal, but no
more."
• One reason for this is that an N% reduction in schedule would require an M%
increase in personnel resources (assuming that other parameters remain fixed).
• Any increase in the number of people requires more management overhead.
• In general, the limit of flexibility in this overhead, along with scheduling concurrent
activities, conserving sequential activities, and other resource constraints, is about
25%.
• Optimally, a 100-staff-month effort may be achievable in 10 months by 10 people.
• Could the job be done with 20 people? Clearly, these alternatives are unrealistic.
• The 25% compression metric says that the limit in this case is 7.5 months (and
would require additional staff-months, perhaps as many as 20).
• Any further schedule compression is doomed to fail.
• On the other hand, an optimal schedule could be extended almost arbitrarily and,
depending on the people, could be performed in a much longer time with many
staff resources.

7
• For example, if you have the luxury of 25-month schedule, you may need only 75
staff-months and three people.
Q.1. (B) Explain the process of Cost Estimation.
SOLUTION
Process of Cost Estimation:
Software Cost Estimation is not known for Iterative Development Approach. Software
industry has inconsistently defined metrics on automatic units of measure of data from
actual projects are highly suspicious in terms of consistency and comparability.
 Measurement and Comparability size has two points of view: source lines of code
and function points.
 Most experts feel that SLOC is miserable measure of size.
 As language advance use of component automatic code generation, etc. have
made SLOC an ambiguous measure.
 Use of function points has the advantage that it is independent of technology
and much better primitive units for comparison among project and
organizations.
 Primitive definitions are abstract and measurements are not easily directly
derived.
 Most real world use of cost modes are bottom up rather than top down
approach.
 Software manager defines the target cost software then manipulates the
parameter and sizing until the target.
Q.1. (C)
Explain any two staffing principles to improve team effectiveness.
SOLUTION
 Principle of Top Talent: Use better and fewer people.
 Principle of Job Matching: Fit the task to the skills and motivation of the people
available.
 Principle of Career Progression: An organization does but in long run by helping
its people to self-actualize.
 Principle of Team Balance: select the people who will complement and
harmonize with one another.
 Principle of Phase-Out: Keeping a label on the team doesn’t fit anyone.

8
Q.1. (D)
Explain the importance of Quality Parameter to improve Software
Economics.
SOLUTION
Quality Parameter:
 Requirements, misunderstanding, development risk, commercial component,
change management, deign error, automation, resource adequacy, scheduler,
target performance and software process rigors.
 Focus on driving requirements and critical use car early in the life cycle focusing
on requirements completeness and traceability late in the life cycle and focusing
through 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 a
architecture as it evolves from a high level prototype into a fully compliant
product.

9
Q.2. (A)
List the phases of Life Cycle process. Explain the Elaboration
Stage.
SOLUTION
Phases of Life Cycle Process:
 Inception Phase
 Elaboration Phase
 Construction Phase
 Transition Phase
Elaboration Stage:
 The elaboration phase is the most critical of the four phases. At the end of this
phase, the "engineering" is considered complete and the project faces its
reckoning: The decision is made whether or not to commit to the production
phases.
 The elaboration phase activities must ensure that the architecture,
requirements, and plans are stable enough, and the risks sufficiently mitigated,
that the cost and schedule for the completion of the development can be
predicted within an acceptable range.
 During the elaboration phase, an executable architecture prototype is built in
one or more iterations, depending on the scope, size, risk, and novelty of the
project.

10
Q.2. (B) Compare Meta and Macro processes.
SOLUTION
Meta Vs. Macro Processes:
Separation of implementation set from the deployment set is from the deployment
set is important become there are very different concerns with each set.
 The structure of the information delivered to the over is very different from the
structure of the some code information.
 It is better to separate the source code implementation concern from the
deployment source code.
 Each state of development represents a certain amount of precision in the final
system description.
Q.2. (C)
Explain Architecture-First Approach of Modern Software
Management.
SOLUTION
Architecture-First Approach of Modern Software Management:
 Base of process on an architecture first approach. It requires that a demonstrable
balance be achieved among the arriving requirements. The architecturally
significant design decisions and the life cycle plans before the resources are
committed for full scale development.
 Establish an iterative life cycle process that controls risk early. With today’s
software system it is not possible to define the entire problem, design the entire
solution, build the software, 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 iteration encourages a balance
treatment of all stakeholders’ objectives.
Q.2. (D)
Explain the concept of architecture from management
perspective.
SOLUTION
Concept of architecture from Management Perspective:
 From Management Perspective there are three different aspects.
 An architecture is the design of the software system. Significant make as
busy decisions are resolved and all custom components are elaborated.
 An architecture baseline as a slice of information across the engineering
sets sufficient to satisfy all stakeholders.

11
 An architecture description is an organized subset of information
extracted from the design set models.
 For example, an architecture of the software for an air traffic control
system is very different from the software architecture of small
development tool.

12
Q.3. (A)
Define the term Workflow. Explain requirement and Design
Workflows.
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.
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 – Define Architecture and Components

13
Q.3. (B)
What are the Check Points of the process? Explain the sequence
of Check Points.
SOLUTION
Checkpoints of the Process:
Three sequences of project checkpoints are used to synchronize customers’
expectations throughout the life cycle major milestones, minor milestones and major
states assessments milestones, must have well defined expectations and provide
tangible results.
1) Major Milestones: These Systemwide Events held at the end of each
development phase. They provide visibility to systemwide issues, synchronize
the Management and engineering perspectives, and verify that the aims of the
phase have been achieved.
2) Minor Milestones: These iteration-focused events conducted to review the
content of an iteration in detail and to authorize continued work.
3) Status Assessment: These Periodic Events provide management with frequent
and regular insight into the progress being made.
Q.3. (C) Explain Iteration Readiness and Assessment Review.
SOLUTION
Iteration Readiness and Assessment Review:
For most iteration only two minor milestones are needed the iteration readiness,
review and iteration assessment review.
An iteration can take different forms depending on where the project is in Life-Cycle.
 Iteration Readiness Review: It is conducted at the start of each iteration to
review the detailed iteration plan and the evaluation criteria that have been
allocated to this iteration.
 Iterating Assessment Review: It is conducted at the end of each iteration to
assess the degree to which the iteration achieved its objectives.
The format and the content of their milestones highly on project and organizational
culture.

14
Q.3. (D)
Define Work Breakdown Structure. Explain the issues with
conventional WBS.
SOLUTION
Work Break Down Structures (WBS):
 A Work Breakdown Structures (WBS) is simply a hierarchy of elements that
decomposes the project plan into the discrete work tasks.
 A WBS provides the following information structure:
 A Delineation of all significant work.
 A Clear task decomposition for assignment of responsibilities.
 A Framework for Scheduling, Budgeting and Expenditure Tracking.
Conventional Work Breakdown Structures (WBS):
There are three fundamental issues with Conventional WBS as follows:
 They are prematurely structured around the product design.
 They are prematurely decomposed, planned, and budgeted in either too much
or too little detail.
 They are Project-Specific, and Cross-Project Comparisons are usually difficult or
impossible.

15
Q.4. (A)
What is Software Change Orders (SCO)? Explain the basic fields of
SCO.
SOLUTION
Software Change Order (SCO):
 Software units that authorized to create or modify components within a configuration
baseline are called Software Change Order (SCO).
 It is a key mechanism for partitioning, allocating and scheduling a software work against
an established software baseline.
 By automating the data-entry and maintaining change records on line the change
management activities can also be automated.
Basic Fields of SCO:
 Title: Suggested by originator.
 Description: Problem description providing details.
 Metrics: Metrics collected for each SCO.
 Resolution: Person responsible for changes and its description.
 Assessment: The assessment technique like inspection, analysts etc.
 Disposition: The SCO is assigned one of the following state by CCB proposed,
Accepted, Rejected, archived, in progress in Assessment Closed.

16
Q.4. (B) What are the responsibilities of Software Architecture Team?
SOLUTION
Responsibilities of Software Architecture Team:
 The Software Architecture Team is responsible for the architecture.
 This responsibility encompasses the engineering necessary to specify a complete
bill of materials for the software and the engineering necessary to make
significant make trade-offs so that all custom components are elaborated to the
extent that construction/assembly costs are highly predictable.
 It provides the framework for facilitating team communications, achieving
system-wide qualities and for implementing the applications.
 With good architecture team an average development team can succeed.
 Architecture team is responsible for system level quality which include reliability,
performance and maintainability.
Q.4. (C) Explain Project Environment with features to prototyping.
SOLUTION
Project environment artifacts evolve through three discrete states:
 The prototyping environment includes an architecture area to evaluate
compromises during the inception and elaboration phases of the life-cycle.
 The development environment should include a full suite of development tools
needed to support the various process workflows and to support sound trip
engineering to the maximum extent possible.
 The maintenance environment should coincide with a mature version of
development environment.
 Tools must be integrated to maintain consistency and traceability.
 Change Management must be automated and enforced to manage multiple
iteration.
 Organizational infrastructures enable project environments to be derived from
common base of tools.
 Extending automation support for stakeholder environment enables further
support for paperless exchange of information.

17
Q.4. (D)
Define the term Configuration Baseline. What are two classes of
Baseline?
SOLUTION
Configuration Baseline:
A configuration baseline is a named collection of software components and supporting
documentation that is upgraded, maintained, tested as a unit.
There are three level of baseline releases for most of the systems.
 Major (N): Represent a new generation of product.
 Minor (M): Same basis product with some enhanced features, performance and
quality.
 Interim (X): Corresponds to developmental configuration that intended to be
transient.
Once software is placed in controlled baseline all changes are tracked and distinction
are made for the cause of changes which are as follows:
Type 0: Critical Failures which are defects that are nearly always fixed before any
external release.
Type 1: A bug or defect that either does not impair the usefulness of the system or can
be worked around.
Type 2: A change that is an enhancement rather than a response to a defect.
Type 3: A change that is necessitated by an update to the requirements.
Type 4: Changes that are not accommodated by above all types.

18
Q.5. (A) What are Management Indicators? Explain any two.
SOLUTION
Management Indicators:
Work and Progress:
Various activities of an iterative development project can be measured by defining a
planned estimate of work then tracking the progress against that plan.
Default perspective of this metric are:
 Software Architecture Team: use cares demonstrated.
 Software Development Team: SLOC under Baseline Change Management.
 Software Assessment Team: Test Hours Executed, Evaluation Criteria Met.
 Software Management Team: Milestones completed.
Budgeted Cost and Expenditures:
 Tracking financial progress usually takes on an organization specific format.
 One common approach to financial performance measurement is use of an
earned value system which provides highly detailed costs and schedule insight.
 It major weakness was the inability to assess technical progress objectively and
accurately.
 The other core metrics provide a framework for detailed and realistic data to
plan and track against highest cost and schedule expenditures.

19
 Modern software processes are open to financial performance measurement
through an earned value approach.
Q.5. (B) Write a short note on Software Project Control Panel.
SOLUTION
Software Project Control Panel (SPCP):
The Software Project Control Panel (SPCP) is an example of metrics automation
approach that collects, organizes & reports values and trends extracted directly from
the evolving engineering artifacts.
Start the SPCP:
The SPCP starts and shows the most current information that was saved when the user
last used the SPCP.
Select a Panel Preference:
The user selects from a list of previously defined default panel preferences. The SPCP
displays the preference selected.
Select a Value or Graph Metric:
The user selects whether the metric should be displayed for a given point in time or in
a graph, as a trend.
Select to Superimpose Controls:
The user points to a Graphical Object and requests that the control values for that
metric and point in the time be displayed.
Drill down to trend:
The user points to a Graphical Object displaying a point in the time and drills down to
view the trend for the metric.
Drill down to Point In Time:
The user points to a Graphical Object displaying a trend and drills down to view the
values for the metric.
Drill down to lower levels of information:
The users points to a Graphical Object displaying a point in time and drills down to
view the next level of information.
Drill down to Lower Level of Indicators:

20
The user points to a Graphical Object displaying an indicator and drills down to view
the breakdown of the next level of indicators.
Q.5. (C) Explain the concept of process maturity.
SOLUTION
Process Maturity:
 Managing a mature process is much more simplex than managing an immature
process.
 Organizations with mature process have a high level of precedent experience in
developing software and a high level of existing process security that enables
predictable planning and execution of process.
 Security includes well defined methods, process automation tools, workflow
templates etc.
 Tailoring a mature organizations process is a straight forward task.
Example:
Process
Primitives
Mature, level – 3 or 4 Organization
Life Cycle Phases Well-established criteria for phase transitions.
Artifacts Well-established format, content, and production
methods.
Workflow Effort Well-established basis allocations
Checkpoints Well-defined combination of format and informal
events.

21
Q.5. (D)
Compare small commercial project with large, complex project
on the basis of workflow priorities.
SOLUTION
Workflow Priorities:
Higher Technical Complexity:
 Embedded, Real Time, Distributed, Fault-Tolerant
 High-Performance, Portable.
 Unprecedented, Architecture Re-Engineering

22
Q.6. (A)
Explain 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.

23
Q.6. (B)
"80% of the errors are caused by 20% of the components".
Discuss with reference to early risk resolution.
SOLUTION
 Engineering stage of the life-cycle focuses. On confronting the risks and resolving
them before the production stage.
 Conventional projects do the easy stuff first there by demonstrating early
progress.
 A modern process attacks the important 20% of the requirements, use cases,
components and risks.
80% of the engineering is consumed by 20% of the requirements.
Strive to understand the driving requirements completely before committing
resources to full-scale development.
80% of the software cost is consumed by 20% of the components.
Elaborate the cost-critical components first so that planning and control of cost drivers
are well understood early in the life cycle.
80% of the errors are caused by 20% of the components.
Elaborate the reliability-critical components first so that assessment activities have
enough time to achieve the necessary level of maturity.
80% of software scrap and rework is caused by 20% of the changes.
Elaborate the change-critical components first so that broad-impact changes occur
when the project is nimble.
80% of the resource consumption is consumed by 20% of the components.
Elaborate the performance-critical components first so that engineering trade-offs
with reliability, changeability, and cost-effectiveness can be resolved as early in the life
cycle as possible.
80% of the progress is made by 20% of the people.
Make sure that the initial team for planning the project and designing the architecture
is of the highest quality. An adequate plan and adequate architecture can then succeed
with an average construction team. An inadequate plan or inadequate architecture
will probably not succeed, even with an expert construction team.

24
Q.6. (C)
Compare Conventional Software Process with Modern Iterative
Process Framework.
SOLUTION
Conventional Software Process Vs. Modern Iterative Process Framework:
In summary, the conventional software process was characterized by the following:
 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.
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.
Q.6. (D)
What do you understand by Culture Shifts with reference to
Modern Process Transition?
SOLUTION
Culture Shifts for the Transition to Modern Software Process:
Culture Shifts necessary for the transition to Modern Software Process as follows
below:
 Lower Level and Mid-Level Managers are performers.
 Requirements and Designs are fluid and tangible.
 Ambitious Demonstrations are encouraged.
 Good and Bad Project Performance is much more obvious earlier in the Life Cycle.
 Early Increments will be immature.
 Artifacts are less important early, more important later.
 Real issues are surfaced and resolved systematically.
 Quality Assurance is everyone's job, not a separate discipline.
 Performance issues arise early in the Life Cycle.
 Investments in Automation are necessary.
 Good Software Organizations should be more profitable.

25
Q.7.Attempt Any Three Questions: (15 Marks)
Q.7. (A) What are the Basic Parameters of Software Economics?
SOLUTION
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.
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.

26
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.7. (B) List and explain the Implementation Set Artifact.
SOLUTION
Implementation Set Artifact:
1) Source Code Baselines
2) Associated Compile-Time Files
3) Component Executable
Separation of the implementation set from the deployment set is important because
there are very different concerns with each set.
 The structure of the information delivered to the user is very different from the
structure of the same code information.
 The important configuration information is captured either in implementation
set or deployment set.
 It is usually better to separate the source code implementation concern from the
Deployment Source Code.
 In early life cycle precision is low and it goes on increasing and at any stage the
five sets will be different states of completeness except for the final stage.
Q.7. (C) Explain Bottom-Up Approach of Cost and Schedule Estimation.
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:
 There two planning approaches should be used together in balance throughout
the life cycle of the project.

27
 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 a note on Round Trip Engineering.
SOLUTION
Round Trip Engineering:
 As the software industry moves into maintaining different information sets for the
engineering artifacts, more automation support is needed to ensure efficient and
error free transition of data from one artifact to another.
 Round-trip engineering is the environment support necessary to maintain
consistency among the engineering artifacts.
 The automated translation of design models to process models is also becoming
straightforward through technologies such as ActiveX and the Common Broker
Architecture (COBRA).
 The primary reason for round-trip engineering is to allow freedom in changing
software engineering data sources.
 The figure given below depicts some important transitions between information
repositories.
Figure 1: Round-Trip Engineering

28
Q.7. (E) Describe any four Quality Indicators in detail.
SOLUTION
Quality Indicators
i) Change Traffic and Stability
ii) Breakage and Modularity
iii) Rework and Adaptability
iv) MTBF and Maturity
Change Traffic and Stability:
Progress and Quality Parameters of the software measure by the change traffic
indicator.
 Change Traffic: The number of the SCO's open and closed over the whole life
cycle is known as Change Traffic.
 Stability: Relationship between open and closed SCO's is known as Stability.
This information relates to the metrics is collected through overall change, its release
type, all number of release, by team, by all its components, by all its subsystems, and
so on.
Breakage and Modularity
 Breakage: The average extents of change, which is the amount of software
baseline that needs rework is known as Breakage.
 Modularity: The average breakage trend over time is known as Modularity.
As time increase breakage trend is also increase, this indicates that product
maintainability is suspect.
Rework and Adaptability
 Rework: The average cost of change, which is the effort to analyze, resolve and
reset all changes to the software baseline is known as rework.
 Adaptability: The rework trend over time is known as adaptability.
MTBF and Maturity:
 Mean Time Between Failures (MTBF): The average usage time between
software faults is known as Mean Time between Failures. It is calculated by
dividing the test hours by the number of type 0 -1 SCOs.
 Maturity: The MTBF trend over time is known as Maturity.
As an error comes in the software projects then that are revised and prevent from
those error. Such errors are categorized into two types: Deterministic errors and non-
deterministic error.

29
Q.7. (F)
What are the benefits of Next Generation Cost Estimation
Models?
SOLUTION
Benefits of Next Generation Cost Estimation Models:
 It should explicitly separate architecture engineering from application
production.
 The cost of designing, producing, testing maintaining the architecture baseline
as a function of scale, quality, and technology process and team skill.
 Next generation software cost models should estimate large scale architectures
with economy of scale.
 In conventional process minimal level of automation was also Labour intensive
workflows.
 Next generation environments and infrastructure are moving to automate and
standardize many of the activities.
 Another important difference in this cost model is that architecture and
applications have different units of mass and are representation of solution
space. Two major improvements in Next Generation Cost Model are:
 Separation of engineering stage from production, which will force to
differentiate between architectural scale and implementation size and rigorous
design notations such as UML will offer an opportunity to define units for
measurements.
☮☮☮

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

Recommended

Recommended

More Related Content

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

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

More from Mumbai B.Sc.IT Study

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

Recently uploaded

Recently uploaded (20)

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