(2½ Hours) [Max Marks: 60

N. B.: (1) All questions are compulsory.

(2) Make suitable assumptions wherever necessary and state the assumptions made.
(3) Answers to the same question must be written together.
(4) Numbers to the right indicate marks.
(5) Draw neat labeled diagrams wherever necessary.

I. Answer any two of the following: 10

a. Explain “Royce’s analysis” towards waterfall model.
b. What are the factors that can be abstracted with software economics? Explain in detail.
c. How can the team effectiveness be improved? Explain.
d. Write a short note on “Function Points”.

II. Answer any two of the following: 10

a. Enlist any ten principles of conventional process.
b. Explain the significance of vision document.
c. Write a short note on management perspective architecture.
d. Explain the different lifecycle phases in detail.

III. Answer any two of the following: 10

a. Explain interaction workflows.
b. “In order to ensure the consistency on various artifacts, the major milestones
concentrate on objective, operational capabilities, & release issues”. Explain this
statement.
c. Explain different levels of evolutionary work breakdown structure
d. Enlist the top seven workflows and explain any four of them in detail.

IV. Answer any two of the following: 10

a. Explain about “Line-of-business” organization.
b. Explain the term “software project team evolution”.
c. Explain the basic fields of Software Change Order with the help of a template of the
same.
d. “Project software standard is to be set by organization policy.” Explain the statement.

V. Answer any two of the following: 10

a. Explain the three management indicators’ metrics in detail.
b. Write a short note on pragmatic software metrics.
c. Explain the two dimensions of process discriminate with neat diagram.
d. Enlist the factors of tailoring a software process framework. Explain the scale factor in
detail.

VI. Answer any two of the following: 10

a. Explain the term “Next Generation software economics”.
b. Explain the steps or strategies to make error-free software.
c. Write an exhaustive note on “Culture shift”.
d. Explain how modern process transition claims that to be fruitful.

_________________________

1
I. Answer any two of the following:

a. Explain “Royce’s analysis” towards waterfall model?

Ans:
In 1970’s, Winston Royce presented a paper titled “Managing the development
of large scale software systems at IEEE WENSON.
The paper made 3 primary points:- (3 marks)
1. There are 2 essential steps common to the development of computer
programs: analysis and coding.
2. In order to manage and control the development of software extra steps must
be introduced which are system requirements definition, software
requirements definition, program design and testing. These steps are added
in analysis and coding steps. The resulting are added in analysis and coding
steps. The resulting project profile and basic steps in developing a large scale
program.

System requirements
definition

Software requirements
definition

Analysis

Program Design

Coding

Testing

Operational

3. testing is at end in the new waterfall model diagram which is risky and
invites failure. Therefore the resultant changes might violate the design
hence either the requirements must be modified or a substantial design
changes is warranted by breaking the software in different phases.

Suggestions to improve: (2 marks with brief explanation)

Due to these problems in the waterfall model Winston suggested 5 ways to
improve the development of the model.
1. Program design comes first:- this is the 1st step towards a fix to insert a
preliminary program design phase between the software requirements and
2
 the analysis phase. The software will not fail because of storage timing and
data fluctuations.
2. Document the design:- It is necessary to maintain complete and current
documentation as the amount of documentation required by software
programs are quite a lot.
Need of documents:-
Documents are required to identify the risk.
Designer can communicate easily with interfaces, peers and customers.
Documents gives clear view about the process.
Documentation helps in creating future versions of the software.
Documentation support later modifications by later teams such as test team,
maintenance team and operations personal who are not software literate.
3. Do it twice:- if the computer program is developed for the first time, arrange
matters so that the version finally developed and delivered to the customer
for operational deployment is actually the second version insofar as critical
design/operational are concerned.
“Do it N times” approach is the principle of modern day iterative
development.
4. Plan, monitor and control testing:- The biggest user of project resources is
the test phase. This is the phase of greatest risk in terms of cost and schedule.
In order to carryout testing the test team should be a separate team which do
not include designers and should check for visual errors and process flows.
5. 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
by conducting some reviews such as preliminary software review during
preliminary program design step. Critical software review during program
design. Final software acceptance.
The final diagram after improvements is as follows:-

3
 System requirements

Software requirements

Preliminary design

Analysis

Detailed design

Coding

Testing

Operational

b. What are the factors that can be abstracted with software economics? Explain in detail?
Ans.
Five factors (5 marks)(with relevant explanation)
Software economics gives 5 fundamental features which are abstracted from
software economics which are:-
1. Size:- the size of the end product is measured in terms of the number of lines
of source code or the number of function points required to develop the
required functionality.
2. Process:- Process is used to develop the end product. The process has the
ability to avoid non value adding activities (rework, bureaucratic, delays,
communications overhead). Process is a support heading towards target and
eliminating essential/less important activities it is critical in determining the
software economics like component based development, application domain,
use case driven.
3. Personnel:-the capabilities of software engineering personnel and their
experience with computer science issues and application domain issues of the
project.
4. Environment:- environment is made of tools and the techniques which are
available to support efficient software development and to automate the
process. The example of tools available for support of software development
are:- Integrated tools, automated tools for modeling, testing, configuration,
managing change, defect tracking etc.
5. Quality:- the quality parameter of software economics includes its features,
performance, reliability, maintainability, scalability, portability, user
interface utility, usability.
The relationship among these parameters and estimated cost can be
calculated by using:-
4
 Effort=(personnel)(environment)(quality)(size^process)

c. How can the team effectiveness be improved? Explain?

Ans:- (any 4 principles with brief explanation 2 marks)

The team effectiveness can be improved by applying the principles given by
bohem for improving the team effectiveness which are:
1. Principle of top talent:- use better and fewer people.
2. Principle of job matching: fit the tasks to the skills and motivation of the
people available.
3. principle of career progression:- an organization does best in the long run by
helping its people to self actualize.
4. principle of team balance:- select people who will compliment and
synchronize with one another.
5. Principle of phase out:- keeping a misfit in the team doesn’t benefit anyone.

In general staffing is achieved by these common methods:- (4 methods---2 marks)

a. if people are already available with required skill set just take them.
b. If people are already available but do not have the required skill retrain
them.
c. If people are not available recruit skilled people.
d. If you are not able to recruit skilled people recruit and train people.

Also the Project Manager must have the following skills to improve Team
Effectiveness: (Enlist any 4 skills-1 mark)

1. Hiring Skills
2. Customer-Interface Skills
3. Decision Making Skills
4. Team Building Skills
5. Selling Skills

d. Write a short note on function points”.

Ans:-
What is FP and Why FP? (1 mark)
1.There were some of the disadvantages found in method of SLOC cost estimation
technique like it was not useful or a new invention projects and not useful for fully
component based models. So FP as a measure of estimation cost of software is being
used.
2. It is one of the measure/mechanism to know the size of the project
3. it is used when it is brand new invented project and no case studies or prior
documents for refence are available for help of the project.
4. It can be used when the project is 100% customized or 100% component based.
5. It is world wide accepted forum as it has its own consortium for universal
function point.
6. the primary advantage of using function point is that this method is independent
of technology and is therefore a much better primitive unit for comparisons among
project and organizations the main disadvantage is that the primitive definitions are
abstract and measurements are not easily derived directly from the evolving
artifacts.
5
7. Function points are also probably a more accurate estimator in the early phases
of the project life cycle.

About UFP (1 mark)

8. As function point has its own universal functional point these points depend on
the following table:-
Language SLOC
Ada 71
Aishell 49
Apc 32
Assembly 320
Ansi 85
Cobol 91
Fortan 77 105
Forth 64
Jovial 105
Lisp 64
C 128
C++ 29
Modulo 80
Pascal 91
Report generator 80
Spreadsheet 6

There are 5 rules used to calculate LOC they are:- (5 rules 3 marks)

a. How many number of input screen are going to be in the project:- The LOC
depends on the no of input forms/screens available for the project.
b. Number of output achieved:- The no of output achieved also helps to calculate
LOC as based on number of outputs the particular coding will be required.
c. Logical units:- It provides interaction between interfaces and logical units so
based on number of logical units provided interfaces can communicate and that too
helps in calculating LOC.
d. Interfaces:- Interfaces enable communication between different parts of the
project and can be a measure to calculate LOC.
e. Graphical user interface:- the more Gui based interfaces provided the LOC
differs so it is also a measure to calculate LOC.
In this way function point is also a metric added to calculate the cost
estimation of the project or software. It is added due to the disadvantages of SLOC
technique.

6
 II. Answer any two of the following:

a. Enlist any 10 principles of conventional process.

Any 10 principles (out of 30) with very brief explanation-5 marks
Ans.

7
8
9
10
11
12
b. Explain the significance of vision document?
Ans:-
What is vision document? (1 mark)
Significance of Vision document (1 mark)
Template of vision document (1 mark)
13
Explanation of template (2 marks)

c. Write a short note on management perspective architecture?

Ans:- Three aspects of management perspective: (3 aspects With relevant

explanation 3 marks)
14
 1. Architecture
2. Architecture Baseline
3. Architecture Description

Importance of software architecture: (any 4 points out of 6 –2 marks)

15
d. Explain the different life cycle phases in detail?
Ans:- There are 4 life cycle phases which are:- (Enlist the phases with simple
diagram-1 mark)

16
 a. Inception phase
b. Elaboration phase
c. Construction phase
d. Transition phase
Explanation of all the four phases (4 marks)
Pattern to explain the phases:
Primary objectives
Essential Activities
Primary Evaluation Criteria

17
18
19
Construction Phase:-

20
Transition Phase:-

21
22
III. Answer any 2 of the following:

a) Explain interaction workflows .

Ans:
What is interaction workflow? (Either description or diagram)(1 mark)
Iteration consists of a loosely sequential set of activities in various
proportions depending on where the iteration is allocated in the development
cycle. Each iteration is defined in terms of a set of allocated usage scenarios.

23
The role of iteration in every work flow: (7 workflows—3marks)
Management: this iteration planning to determine the content of release and
develop the detailed plan for iteration, and assignment of work packages, or
tasks, to the development team.
Environment: evolving the software change order database to reflect all the
new baselines and changes to existing baselines for all product, test and
environment components.
Requirements: analysing the baseline plan,the baseline architecture and the
baseline design 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.
Design: evolving the baseline architecture and the baseline design set
artifacts to fully elaborate the design model and test model components
necessary to demonstrate against the evaluation criteria allocated to this
iteration; updating any design set artifacts to reflect changes necessitated by
results of this iteration’s engineering activities.
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
Assessment: evaluating results of this 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.

24
 Deployment: transitioning the release either to an external organization or to
internal closure by conducting a past-mortem so that lessons learned can be
captured and reflected in the next iteration.

Diagram : (1 mark)

b) “In order to ensure consistency on various artifacts, the major milestones

concentrate on objective, operational capabilities, & release issues”. Explain this
statement.
Ans:

About Life-cycle objective milestone ( 2 marks)

About operational capabilities (2 marks)
Release issues(1 mark)

25
c) Explain different levels of evolutionary work breakdown structure
Ans:

What is WBS? ( 1 mark)

Three levels of WBS (3 marks)
Diagram to show the levels (1 mark)

WBS is simply a hierarchy of elements that decomposes the project plan into
the discrete work tasks.
An evolutionary WBS should organize the planning elements around the
process framework rather than the product framework. This approach
better puts up the expected changes in the evolving plan.
WBS organizes the hierarchy into three levels.

26
A default WBS consistent with the process framework (phases, workflows
and artifacts) as shown below in the diagram

27
d) Enlist the top seven workflows and explain any four of them in detail

Enlist:( All seven workflows-1 mark)

28
Ans:
The term workflow is used to mean a thread of cohesive and mostly
sequential activities. Workflows are mapped to product artifacts and to
project teams.
Top 7 workflows
1. Management workflow
2. Environment workflow
3. Requirements workflow
4. Design workflow
5. Implementation workflow
6. Assessment workflow
7. Deployment workflow

Any four workflows with brief explanation (4 marks-1 mark each)

Management workflow:
It is used in controlling the process and ensuring win conditions for all
stakeholders. Used to determine the content of release and develop the
detailed plan and assigning the task to the development team

Environment workflow
It is used in automating the process and evolving the maintenance
environment. Used to evolve the software change order database to
reflect all the new baselines and changes to existing baselines for all
product, test and environment components.

Requirements workflow
It is used in analyzing the problem space and evolving the
requirement artifacts. Used in analysing the baseline plan,the baseline
architecture and the baseline design set artifacts to fully elaborate the
use cases to be demonstrated at the end of this iteration and their
evaluation criteria .

Design workflow
It is used in modeling the solution and evolving the architecture and
design artifacts. Used in evolving the baseline architecture and the
baseline design set artifacts to fully elaborate the design model and test
model components necessary to demonstrate against the evaluation
criteria.

IV. Answer any 2 of the following:

a) Explain about “Line-of-business” organization.

29
Ans.
Features: (any 2 feature 1 mark)

Diagram to show the roles : (1 mark)

Explanation of the diagram in brief (3 marks)

30
31
b) Explain the term ‘software project team evolution’
Ans:
Diagram 2 marks
Explanation 3 arks

32
c) Explain the basic fields of Software Change Order with the help of a
template of the same.
Ans:
Template (2 marks)
Explanation of the same (3 marks)

SCO is the atomic unit of software work that is authorized to create,

modify components within a configuration baseline. SCO is a key
mechanism for partitioning, allocating and scheduling software work
against an established software baseline and for assessing progress and
quality. The basic fields are as follows:
1. Title
This field represents the report name finalized upon acceptance by
the configuration control board (CCB). It is suggested by the
originator.
2. Description
This includes the details of the mentioned titles, error occurred,
summarized report, date and name of the originator that helps to
define the changes required.
3. Metrics
This field defines the category of the initiated process and the
comparison between actual and processed estimates. This is
important for planning, scheduling & for assessing quality
improvements.
4. Resolution
It includes the name of the analyst who is responsible for the
implementation of components changed and its description.
5. Assessment
This describes the method of evaluation, its tester, platform and
date of assessing the title
6. Disposition
It specifies different set of states as proposed, accepted, rejected,
archived, in progress, in assessment and closed together with the
specified date.

33
States are described as
 Proposed: written, pending CCB review
 Accepted: CCB approved for resolution
 Rejected: closed with rationale as not a problem, duplicate,
obsolete change, resolved by another SCO
 Archived: accepted but postponed until a later release
 In progress: assigned and actively being resolved by the
development organization.
 In assessment: resolved by development team, being assessed by a
test team
 Closed: completely resolved, with the concurrence of all CCB
members.

34
d) “Project software standard is to be set by Organisation Policy.”
Explain the statement.
Ans.
About organization policy (2 marks)
Explanation Three levels of policy (Highest, intermediate and
lower)(3 marks)

35
 Therefore, the organizational policy is the defining document for the
organization’s software policies where reviewers are able to question
and determine whether the project is worth meeting what is specified or
not.

IV. Answer any 2 of the following:

a. Explain the three management indicators metrics in detail.

Enlist the three management indicator: (1 mark)
Explanation of all the three in brief (4 marks)
1. Work and progress
2. Budgeted cost and expenditures
3. Staffing and team dynamics

1. Work and Progress

36
2. Budgeted cost and Expenditures

37
3. Staffing and Team Dynamics

38
b. Write a short note on pragmatic software metrics.
What is software metric and its significance(1 mark)
Characteristics of good metrics: (Any 4—4 marks)

39
40
c. Explain the two dimensions of process discriminate with neat diagram.
Enlist two dimensions: (1 mark)
 Technical complexity
 Management complexity
Diagram: (2 marks)
Explanation of the diagram: (2 marks)

41
d. Enlist the factors of tailoring a software process framework. Explain the scale factor
in detail.
Factors : (enlist 1 mark)
1. Scale
2. Stakeholder cohesion and contention
3. Process flexibility or rigor
4. Process maturity
5. Architectural risk
6. Domain experience
About Scale: (Concept 1 mark)

42
 Diagram : (1 mark)

Several size of the project: (Explanation of different size of project---3 marks)

1. Trivial
2. Small
3. Medium-sized
4. Large
5. Huge

43
44
VI Answer any 2 of the following:

a. Explain the term “Next Generation software economics”

Ans
Diagram: that shows the balanced application to achieve economic results (2
marks)

Explanation of the diagram: (3 marks)

b. Explain the steps or strategies to make error-free software

Ans:

4 steps with relevant explanation: (4 marks)

(Diagrams to support the strategies---1 mark)
The steps or strategies to make error-free software are as follows:
1. Continuous integration
2. Early risk resolution
3. Evolutionary requirements
4. Teamwork among stakeholders

45


46


47


48


49
 b. Write an exhaustive note on ”Culture Shift”
Ans:
What is culture shift: (1 mark)

CULTURE SHIFTS
Culture Shift successfully overcome the transition of software management process but
for some process it is difficult to distinguish between objective opposition and stubborn
contention
Indicators derived from the process framework: ( any 8 indicators with very brief
explanation---4 marks)

->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. Hands-on
50
management skills vary, but competent managers typically spend much of their time
performing, especially with regard to understanding the status of the project firsthand and
developing plans and estimates. Above all, the person managing an effort should plan it.
This does not mean the manager should approve the plan; it means the manager should
participate in developing it. In independent project assessments I have performed, a good
indicator of trouble ahead is a manager who did not author the plan nor take ownership of
it. The stakeholders affected by this transition are software project managers.
->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. Major
milestones were defined solely in terms of specific documents. Development
organizations for large contractual projects were driven to produce tons of paper in order
to meet milestones and receive progress payments, rather than spend their energy on tasks
that would have reduced risk and produced quality software. An iterative prom cess
requires actual construction of a sequence of progressively more com prehensive systems
that demonstrate the architecture, enable objective requirements negotiations, validate the
technical approach, and address resolution of key risks. Ideally, 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. The transition to a less
document driven environment will be embraced by the engineering teams; it will
probably be resisted by traditional contract monitors.
->Ambitious demonstrations are encouraged. The purpose of early life-cycle
demonstrations is to expose design flaws, not to put up a facade. Stake-holders must not
overreact to early mistakes, digressions, or immature designs. Evaluation criteria in early
release plans are goals, not requirements. If early engineering obstacles are
overemphasized, development organizations will set up future iterations to be less
ambitious. On the other hand, stakeholders should not tolerate lack of follow-through in I
I resolving issues. If negative trends are not addressed with vigor, they can cause serious
downstream perturbations. Open and attentive follow-through is necessary to resolve
issues. The management team is most likely to resist this transition (especially if the
project was oversold), because it will expose any engineering or process issues that were
easy to hide using the conventional process. Customers, users, and the engineering team
will
embrace this transition for exactly the same reason.
->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. It is therefore of paramount importance to ensure that the very
best team possible performs the planning and architecture phases. If these
phases are done right and with good teams, projects can be completed successfully by
average teams evolving the applications into the final product.
If the planning and architecture phases are not performed adequately, all
the expert programmers and testers in the world probably will not achieve
success. No one should resist early staffing with the right team. However,
most organizations have scarce resources for these sorts of early life-cycle
roles and are hesitant to make the necessary staff allocations.
->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
51
increments. The trends will indicate convergence toward specification. Objectively
quantifying changes, fixes, and upgrades will indicate the quality
of the process and environment for future activities. Customers and users
will have difficulty accepting the flaws of early releases, although they
should be impressed by later increments. Management and the development team will
accept immaturity as a natural part of the process.
->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. While the development team will embrace
this transition whole- heartedly, traditional contract monitors will resist the early de-
emphasis on completeness.
->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. On a healthy project that is making progress, it should be easy to differentiate
between real and apparent issues. Depending on the situation, this culture shift could
affect almost any team.
->Quality assurance is everyone’s job, not a separate discipline. Many organizations
have a separate group called quality assurance. I am generally against the concept of
separate quality assurance activities, teams, or artifacts. Quality assurance should be
woven into every role, every activity, every artifact. True quality assurance is measured
by tangible progress and objective data, not by checklists, meetings, and human
inspections. The software project manager or designee should assume the role of ensuring
that quality assurance is properly integrated into the process. The traditional policing by a
separate team of inspectors is replaced by the self-policing teamwork of an organization
with a mature process, common objectives, and common incentives. Traditional
managers and quality assurance person- net will resist this transition. Engineering teams
will embrace it.
->Performance issues arise early in the life cycle. Early performance issues have
surfaced on almost every successful project I know of. These issues are a sign of an
immature design but a mature design process. Stakeholders will usually be concerned
over early performance issues. Development engineers will embrace the emphasis on
early demonstrations and the ability to assess and evaluate performance tradeoffs in
subsequent releases.
->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. Otherwise, interactions
with the development organization will degenerate to paper exchange and many of the
issues of the conventional process. These investments may be opposed by organization
managers overly focused on near-term financial results or by project personnel who favor
the preference of the individual project over the global solution that serves both the
project and the organization goals.
->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. As part of the adversarial nature of the
acquisition and contracting process, there is considerable focus on ensuring that
contractor profits are within a certain acceptable range (typically 5% to 15%).
Occasionally, excellent contractor performance, good value engineering, or significant
52
reuse results in potent ial contractor profit margins in excess of the acceptable initial bid.
As soon as customers (or their users or engineering monitors) become aware of such a
trend, it is inevitable that substantial pressure will be exerted to apply these “excess”
resources to out of scope changes until the margin is back in the acceptable range.
As a consequence, the simple profit motive that underlies commercial transactions and
incentivizes efficiency is replaced by complex contractual incentives (and producer-
consumer conflicts) that are usually suboptimal. Very frequently, contractors see no
economic incentive to implement major cost savings, and certainly there is little incentive
to take risks that may have a large return. On the other hand, contractors can easily
consume large amounts of money (usually at a small profit margin) without producing
results and with little accountability for poor performance.

d. Explain how modern process transition claims that to be fruitful.

Ans:
What the organization should focus on to make the transition
2 points---2 marks
As an organization transitions to new techniques and technologies, there is always
apprehension and concern about failing. Maintaining the status quo and relying on
existing methods is usually considered the safest path. In the software industry, where
most organizations succeed on only a small percentage of their projects, main- taming the
status quo is not always safe.
When an organization decides to make a transition, these two pieces of conventional
wisdom are usually offered by internal champions as well as external change agents:
( 1 ) Pioneer any new techniques on a small pilot program.
(2) Be prepared to spend more resources money and time -on your first project that
makes the transition. I see both recommendations as counter- productive.

About pilot program: (1 mark)

Small pilot programs outside the mainstream have their place, but they rarely achieve any
paradigm shift of consequence. Trying a new little technique, tool, or method on a very
rapid, small-scale effort—less than 3 months, say, and only a few people—-can
frequently show good results, initial momentum, or proof of concept. The problem with
pilot programs is that they are almost never on the critical path of the organization.
Consequently, they do not merit “A” players, adequate resources, or management
attention.

Immediate actions to perform: (4 actions---2 marks)

A better way to transition to a more mature iterative development process that supports
automation technologies and modern architectures is to take the following shot:
Ready. Do your homework. Analyze modern approaches and technologies.
Define (or improve, or optimize) your process. Support it with mature environments,
tools, and components. Plan thoroughly.
Aim:. Select a critical project. Staff it with the right team of complementary resources
and demand improved results.
Fire:. Execute the organizational and project-level plans with vigor and follow through.

53