Software Development

SOFTWARE DEVELOPMENT

1

PERSPECTIVES ON SOFTWARE PRODUCT DEVELOPMENT

iques for estimating how much more engineering are relatively new. The communicati

8 times faster than the worst at coding and debugging an exercise and that the be

Sec 20 SOFTWARE DEVELOPMENT

2

PERSPECTIVES ON SOFTWARE PRODUCT DEVELOPMENT

ately answerable for choices. Here are two examples of what results from a lack of

slipping schedule. The Army failed, having specified no way to know if the projec

Sec 20 SOFTWARE DEVELOPMENT

3

PERSPECTIVES ON SOFTWARE PRODUCT DEVELOPMENT

upermarket scanner or the video store rental), is scarcely addressed beyond some

needed to develop applications must be addressed. Project managers need to be awar

emes such as software rejuvenation acknowledge that it is impossible to catch eve

Sec 20 SOFTWARE DEVELOPMENT

4

HISTORY

(NATO) conference that set the stage for the early large-scale system development

he integration of a program administration, control, and build function, called “s

intenance work. The practice of involving the customer in using prototypes first

Sec 20 SOFTWARE DEVELOPMENT

5

HISTORY

ustomized, one-use-only software. Each application program had to know how to physi

rk of managing the files and disk space and allowed several applications to share

Sec 20 SOFTWARE DEVELOPMENT

6

HISTORY

ody the first view. This view acts as a driver to help system integrators and prog

ic organization in its development environment.

view. These scenarios are developed around the functions that are the most import

Sec 20 SOFTWARE DEVELOPMENT

7

HISTORY

Sec 20 SOFTWARE DEVELOPMENT

8

HISTORY

are rigorously managed. The organization adheres to “tribal folklore.”

in specific development stages (design, coding, testing), time spent in defining re

l 4; feedback to the appropriate processes is automatic.

Sec 20 SOFTWARE DEVELOPMENT

9

THE LIFE CYCLE OF SOFTWARE

ptual, functional, and technical operating components to reduce its complexity and

Sec 20 SOFTWARE DEVELOPMENT

10

THE LIFE CYCLE OF SOFTWARE

Sec 20 SOFTWARE DEVELOPMENT

11

THE LIFE CYCLE OF SOFTWARE

ication servers that have replaced departmental databases benefit from profession

Sec 20 SOFTWARE DEVELOPMENT

12

THE LIFE CYCLE OF SOFTWARE

odule descriptions contain explanations of the processing of the module inputs an

chine for the system. A data dictionary made up of file descriptions, data element

Sec 20 SOFTWARE DEVELOPMENT

13

THE LIFE CYCLE OF SOFTWARE

f a system should do that too, by eliminating redundant functions, making algorith

e for linking all modules together into a single load module. Finally the code exe

covering errors at this late point is twice that of finding them during static de

eding phases in the life cycle should have been thoughtfully accomplished. (2) The

Sec 20 SOFTWARE DEVELOPMENT

14

THE LIFE CYCLE OF SOFTWARE

am subfunctions into blocks from program start to end. Branching back to earlier

tures of a particular language direct to some degree the data and logic structure

Sec 20 SOFTWARE DEVELOPMENT

15

THE LIFE CYCLE OF SOFTWARE

ting of the earlier phases gives way to dynamic testing.

require the presence of modules that are still in development, dummy programs cal are satisfied during system testing.

g no load at all, and by offering the appropriate load in a very short time frame.

Sec 20 SOFTWARE DEVELOPMENT

16

THE LIFE CYCLE OF SOFTWARE

manufacturing is a systematic approach to building systems, producing user manual

ll the software and controls the source code for various

environment.

er. Maintenance consumes a whopping 70 percent of the total effort of owning a wo

be repeated as each need arises. As the system ages, its structure starts to deter

Sec 20 SOFTWARE DEVELOPMENT

17

WHAT CAN GO WRONG DURING THE SOFTWARE LIFE CYCLE?

ere are tools, techniques, and technology to treat many problems. There are also ar

on facts and disagreements with the customer, particularly on delivery, indicate s

e without a development plan to produce them), it means that management is not co

Sec 20 SOFTWARE DEVELOPMENT

18

WHAT CAN GO WRONG DURING THE SOFTWARE LIFE CYCLE?

oblems and stimulate the organization to produce its own recovery plan. In a nont

ude just-in-time training, jump starts with technology experts assigned to the deve

Sec 20 SOFTWARE DEVELOPMENT

19

WHAT CAN GO WRONG DURING THE SOFTWARE LIFE CYCLE?

a on which to base an estimate of costs and schedules. The project manager has to

ality checks for customer and designer alike. Useful metrics are availability of t

the problem difficulty pays off by a factor of 5 in radically compressed developm

Sec 20 SOFTWARE DEVELOPMENT

20

WHAT CAN GO WRONG DURING THE SOFTWARE LIFE CYCLE?

t all stages of development. The best results come when system designers and huma

ility. Rigorous design review is required to be sure these components perform as

Sec 20 SOFTWARE DEVELOPMENT

21

WHAT CAN GO WRONG DURING THE SOFTWARE LIFE CYCLE?

t number, communication problems wash out any advantage of extra hands. When the s

ebugging cannot eliminate. A theory of software dynamics promises to ensure that s

er this scheme, instead of a system running for a year, it would run for 1 day, 365

Sec 20 SOFTWARE DEVELOPMENT

22

STANDARDS

ue pressure from any one of those groups. Standards also define approaches that s

Sec 20 SOFTWARE DEVELOPMENT

23

CONCLUSION

toward incorporating it within distributed computing systems. The Java language

, software quality depends on a project manager’s extreme attention to detail.

Sec 20 SOFTWARE DEVELOPMENT

24