Programming languages and software engineering - The Computing Universe: A Journey through a Revolution - page 68

difficult. An additional challenge is that new researchers, who were not the
authors of the original program, may need to extend and modify the code.
Similarly, as the software for business applications became larger and more
complicated, it was no longer possible for a small team of talented program-
mers to write all the code. Teams of hundreds or even thousands of program-
mers now work on software systems consisting of hundreds of thousands or
millions of lines of code, and programmers now have to coordinate their work.
Accurate estimates of the time and cost of writing a complex software system
have become vitally important for software companies. Brooks discusses these
issues in his topic on the “mythical” man-month unit of programming effort.
As a result of his experience, he formulated “Brooks Law,” which says, “Adding
manpower to a late software project makes it later.” 8
Software companies have an urgent need for reliable answers to the
questions: How many lines of code will it take to provide the desired func-
tionality? How many programmers will be needed? How long will it take? If a
software project is behind schedule, what should you do? Software engineering
attempts to define methodologies and frameworks to answer these questions.
The Institute of Electrical and Electronics Engineers (IEEE), a professional orga-
nization devoted to promoting technological innovation, defines software engi-
neering in its Standard 610.12 as “The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of soft-
ware; that is, the application of engineering to software.” 9
One of the earliest attempts to apply engineering methodologies to soft-
ware development was the “waterfall” model ( Fig. 4.7 ). This identified four
distinct phases of software development - requirements analysis, design,
implementation, and testing. The waterfall method calls for completing each
phase before proceeding to the next, which requires the systematic description
and documentation of both the requirements and the design of the software
to be completed before any actual coding begins. In practice, the phases are
rarely completely separate. Software developers often find in later phases that
they must go back and change things in earlier phases. Backtracking and mul-
tiple versions of each phase are common. David Parnas says about the design
process:
Even if we knew the requirements, there are many other facts that we need
to know to design the software. Many of the details only become known to us
as we progress in the implementation. Some of the things we learn invalidate
our design and we must backtrack. 10
The recognition that software development is not a linear process has led to
a philosophy called agile software development . Agile methods break the task of
writing the whole system into smaller segments or “sprints,” each of which
involves all the four phases of software development - analyzing requirements,
designing, implementing, and testing. Based on the results of testing the lat-
est version of a design, the developers make changes and improvements. The
sprints typically last around four weeks, and the goal is to have a working
prototype with some of the functionality required of the final product by the
end of each sprint. One of the main motivations for these more flexible soft-
ware engineering methodologies is that customers often do not know all their