N. B.: (1) are compulsory Make suitable assumptions...

1

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

_________________________

2

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.

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

System requirements

definition

Software requirements

definition

Analysis

Program Design

Coding

Testing

Operational

3

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:-

4

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:-

System requirements

Software requirements

Preliminary design

Analysis

Detailed design

Coding

Testing

Operational

5

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.

6

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.

7

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.

13

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)

14

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)

15

1. Architecture

2. Architecture Baseline

3. Architecture Description

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

16

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)

17

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

20

Construction Phase:-

21

Transition Phase:-

23

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.

24

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.

25

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)

26

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.

27

A default WBS consistent with the process framework (phases, workflows

and artifacts) as shown below in the diagram

28

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

Enlist:( All seven workflows-1 mark)

29

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.

30

Ans.

Features: (any 2 feature 1 mark)

Diagram to show the roles : (1 mark)

Explanation of the diagram in brief (3 marks)

32

b) Explain the term ‘software project team evolution’

Ans:

Diagram 2 marks

Explanation 3 arks

33

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.

34

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.

35

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)

36

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

37

2. Budgeted cost and Expenditures

38

3. Staffing and Team Dynamics

39

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)

41

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)

42

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)

43

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

45

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

50

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

51

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

52

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

53

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.

N. B.: (1) are compulsory Make suitable assumptions...

Documents

Transcript of N. B.: (1) are compulsory Make suitable assumptions...