DEPARTMENT OF MANAGEMENT (LSM)

TERM PAPER
OF
SOFTWARE ENGENEERING

SUBMITTED TO : SUBMITTED BY :
MS. SHAINA SHUJA QAMMER
REG NO: 10904442
ROLL NO: A 03 &
MANHOHAN SINGH
ROLL NO: B 30
REG NO: 10901701
SECTION: S1906 MBA (I.T)
 ACKNOWLEDGEMENT

The most precious moments are those when we get an opportunity to remember
and thank everyone who has in some way or the other motivated and
facilitated us to achieve our goals.

First of all I thank to GOD ALMIGHTY ALLAH for giving us power to pen
down the term paper in its present shape. I thank the entire teaching staff
especially Ms . SHAINA for sharing his valuable knowledge with us & for
providing his able guidance and support. I also thank to my classmate who
every time helped me out and encouraged me for carrying out the task.

I fall short of words to thank my family, who stood beside me while completion
of my task.
Table of Contents
.............................................................................................................................1
The most precious moments are those when we get an opportunity to remember
and thank everyone who has in some way or the other motivated and facilitated
us to achieve our goals..........................................................................................2
First of all I thank to GOD ALMIGHTY ALLAH for giving us power to pen down the
term paper in its present shape. I thank the entire teaching staff especially Ms .
SHAINA for sharing his valuable knowledge with us & for providing his able
guidance and support. I also thank to my classmate who every time helped me
out and encouraged me for carrying out the task.................................................2
I fall short of words to thank my family, who stood beside me while completion of
my task.................................................................................................................. 2
Table of Contents...................................................................................................3
INTRODUCTION..................................................................................................4
HISTORY OF SOFTWARE ENGINEERING..................................................................6
CURRENT TRENDS IN SOFTWARE ENGINEERING....................................................8
NEED FOR SOFTWARE ENGINEERING.....................................................................9
Evolution of Software...........................................................................................12
Software Engineering Goals.................................................................................12
Software Engineering Basics................................................................................14
THE SPECIFICATION PHASE...............................................................................15
REFRENCES.......................................................................................................... 18
 INTRODUCTION
SOFTWARE
Software is a methodical set of instructions (computer program) for execution on hardware (a
computer) to provide the desired features, function, and performance. Software can
adequately manipulate information in data structures. The manufacturing methods of
software and hardware are different. Software is more of an engineering or development type
process and unlike traditional systems; software does not wear out.

SOFTWARE ENGINEERING

Software Engineering is a systematic approach of applying sound engineering principles in

order to obtain software, which will run reliably and effectively on a computer. Software
engineering applies various stages to implement all of the components needed to satisfy the
requirements. Software engineering follows traditional engineering which is “to contrive or
plan out, usually with more or less subtle skill and craft” or “to guide the course of” MER01].

COMPUTER SCIENCE

Computer science is the methodical study of computing systems and computation. The
organization of knowledge resulting from this order contains theories for understanding
computing systems, design methodology, algorithms, the testing methods of concepts;
methods of analysis and verification.

DESIGN
Design is “to create, fashion, execute, or construct according to plan” or “to conceive and
plan out in the mind”. Design is the effort, which the engineer performs to create an answer
to satisfy the customer requirements or problems.
PROGRAMMER

Programmers are individuals who take the software design which the software engineers have
developed and produce the instructions (software code) for the computer. The instructions are
the components, which make up the software. The computer is then able to execute those
instructions or software.

FORMAL METHOD
A method is formal when determined to have a sound mathematical basis when given by a
formal specification. These are the basis for providing precisely the necessary components so
that the software is consistent and complete.

ESTIMATING
Estimating is the process of determining how much the product will cost to design, produce,
and test a piece of software that will satisfy all of the given requirements. Estimating is used
to describe the amount of time and money needed to accomplish the design, production and
testing of the software.
PROJECTS

Projects are tasks or problems engaged in usually by a team or teams. Projects will include all
of the elements, which the customer has requested or ordered. The completion of these
elements can determine when the customer will make payments.

PROJECT MANAGEMENT
Project Management is the act or art of managing the individual projects. Effective
management can result in a successful project. It is questionable whether Project
Management applies across all corporations consistently and generically. Project
management is typically responsible for all aspects of the project This effort includes
planning, monitoring, control of the people assigned to the project (engineering staff,
programmers, estimators, cost/schedule planners, etc.), control of the processes and control of
the events as the software evolves from a conceptual phase to an operational phase.

PROCESSES
Processes are systematic and disciplined steps taken which lead to the completion of the
projects. The software process is the outline for the tasks that are necessary to design,
produce, and test high-quality software .

PROCESS MANAGEMENT
Process Management is controlling the processes used in developing software. Management
of software engineering processes has a significant bearing on the quality of the software
product. “The software process is characterized by the complexity of both the product and the
process and the dynamically changing environment”.

COST DRIVERS
Cost Drivers are different scalars or effort multipliers used in some of the software cost
estimating tools. These drivers are broken up into four categories; product, system platform,
personnel and project factors .

SOFTWARE CONFIGURATION MANAGEMENT (SCM)

Software Configuration Management (SCM) is a management discipline to control the
software application development. SCM is to assist project management to ensure product
integrity and control software changes in an orderly method that will satisfy the customer
requirements.

SOFTWARE ENGINEERING
The need for Software Engineering came soon after the invention of computers. In the
beginning, the individual programmer used whatever means worked to build software.
Formal methods of design or programming did not exist. The programmer was never able to
give a definitive estimate as to how much time a project would take or the amount of
resources needed to complete the project. Management had no way of accurately estimating
the cost of a new project. The software projects often were behind schedule, over cost, poorly
documented, poorly designed, and contained items other than the requirements. These
projects were costing corporations thousands of dollars. The software industry was quite
undisciplined and it was obvious. One management view was that “I would rather have the
project wrong than to have it late”.
 PROJECT IMPACTS
A 1984 survey revealed that from a sample of twenty-three corporations with seventy-two
software projects, cost overruns were an average of 67 percent and schedule slippages about
22 percent. A 1987 survey revealed that the average cost overruns per project were
approximately 225,000 dollars with a three-month schedule slippage . A study performed by
Peat Marwick Mitchell and Co. revealed over 35 percent of their 600 largest customers had
major software project cost overruns and schedule slippages.
SOFTWARE ENGINEERING PROCESS MANAGEMENT
Software Engineering Process Management evolved out of the need to manage the increased
size and complexity of software projects. Process management came about because of the
belief that the software processes could be analyzed, designed and maintained just as if it
were a piece of software. This view lends itself to software process modeling (SPM) .

HISTORY OF SOFTWARE ENGINEERING

In the history of software engineering the software engineering has evolved steadily from its
founding days in the 1940s until today in the 2000s. Applications have evolved continuously.
The ongoing goal to improve technologies and practices, seeks to improve the productivity of
practitioners and the quality of applications to users.

There are a number of areas where the evolution of software engineering is notable:

Emergence as a profession: By the early 1980s, software engineering had already emerged as
a bona fide profession, to stand beside computer science and traditional engineering..

The most important development was that new computers were coming out almost every year
or two, rendering existing ones obsolete. Software people had to rewrite all their programs to
run on these new machines. Programmers did not have computers on their desks and had to
go to the "machine room". Jobs were run by signing up for machine time or by operational
staff. Jobs were run by putting punched cards for input into the machine's card reader and
waiting for results to come back on the printer.

The field was so new that the idea of management by schedule was non-existent. Making
predictions of a project's completion date was almost impossible. Computer hardware was
application-specific. Scientific and business tasks needed different machines. Due to the need
to frequently translate old software to meet the needs of new machines, high-order languages
like FORTRAN, COBOL, and ALGOL were developed. Hardware vendors gave away
systems software for free as hardware could not be sold without software. A few companies
sold the service of building custom software but no software companies were selling
packaged software.

THE ORIGINS
The term software engineering first appeared in the late 1950s and early 1960s. Programmers
have always known about civil, electrical, and computer engineering and debated what
engineering might mean for software.

1965-1985: THE SOFTWARE CRISIS

Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and
1980s, which identified many of the problems of software development. Many software
projects ran over budget and schedule. Some projects caused property damage. A few
projects caused loss of life. The software crisis was originally defined in terms of
productivity, but evolved to emphasize quality. Some used the term software crisis to refer to
their inability to hire enough qualified programmers.

1985-1989: NO SILVER BULLET

For decades, solving the software crisis was paramount to researchers and companies
producing software tools. Seemingly, they trumpeted every new technology and practice
from the 1970s to the 1990s as a silver bullet to solve the software crisis. Tools, discipline,
formal methods, process, and professionalism were touted as silver bullets.

In 1986, Fred Brooks published the No Silver Bullet article, arguing that no individual
technology or practice would ever make a 10-fold improvement in productivity within 10
years.

1990 TO 1999: PROMINENCE OF THE INTERNET

The rise of the Internet led to very rapid growth in the demand for international information
display/e-mail systems on the World Wide Web. Programmers were required to handle
illustrations, maps, photographs, and other images, plus simple animation, at a rate never
before seen, with few well-known methods to optimize image display/storage (such as the use
of thumbnail images).

The growth of browser usage, running on the HTML language, changed the way in which
information-display and retrieval was organized. The widespread network connections led to
the growth and prevention of international computer viruses on MS Windows computers, and
the vast proliferation of spam e-mail became a major design issue in e-mail systems, flooding
communication channels and requiring semi-automated pre-screening. Keyword-search
systems evolved into web-based search engines, and many software systems had to be re-
designed, for international searching, depending on Search Engine Optimization (SEO)
techniques. Human natural-language translation systems were needed to attempt to translate
the information flow in multiple foreign languages, with many software systems being
designed for multi-language usage, based on design concepts from human translators. Typical
computer-user bases went from hundreds, or thousands of users, to, often, many-millions of
international users.

2000 TO PRESENT: LIGHTWEIGHT METHODOLOGIES

With the expanding demand for software in many smaller organizations, the need for
inexpensive software solutions led to the growth of simpler, faster methodologies that
developed running software, from requirements to deployment, quicker & easier. The use of
rapid-prototyping evolved to entire lightweight methodologies, such as Extreme
Programming (XP), which attempted to simplify many areas of software engineering,
including requirements gathering and reliability testing for the growing, vast number of small
software systems. Very large software systems still used heavily-documented methodologies,
with many volumes in the documentation set; however, smaller systems had a simpler, faster
alternative approach to managing the development and maintenance of software calculations
and algorithms, information storage/retrieval and display.

CURRENT TRENDS IN SOFTWARE ENGINEERING

Software engineering is a young discipline, and is still developing. The directions in which
software engineering is developing include:

ASPECTS

Aspects help software engineers deal with quality attributes by providing tools to add or
remove boilerplate code from many areas in the source code. Aspects describe how all
objects or functions should behave in particular circumstances. For example, aspects can add
debugging, logging, or locking control into all objects of particular types. Researchers are
currently working to understand how to use aspects to design general-purpose code. Related
concepts include generative programming and templates.

AGILE

Agile software development guides software development projects that evolve rapidly with
changing expectations and competitive markets. Proponents of this method believe that
heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in
importance. Some people believe that companies and agencies export many of the jobs that
can be guided by heavy-weight processes]. Related concepts include Extreme Programming,
Scrum, and Lean software development.

EXPERIMENTAL
Experimental software engineering is a branch of software engineering interested in devising
experiments on software, in collecting data from the experiments, and in devising laws and
theories from this data. Proponents of this method advocate that the nature of software is such
that we can advance the knowledge on software through experiments only..

MODEL-DRIVEN

Model Driven Design develops textual and graphical models as primary design artifacts.
Development tools are available that use model transformation and code generation to
generate well-organized code fragments that serve as a basis for producing complete
applications.

SOFTWARE PRODUCT LINES

Software Product Lines is a systematic way to produce families of software systems, instead
of creating a succession of completely individual products. This method emphasizes
extensive, systematic, formal code reuse, to try to industrialize the software development
process.

SOFTWARE ENGINEERING TODAY

The profession is trying to define its boundary and content. The Software Engineering Body
of Knowledge SWEBOK has been tabled as an ISO standard during 2006 (ISO/IEC TR
19759).In 2006, Money Magazine and Salary.com rated software engineering as the best job
in America in terms of growth, pay, stress levels, flexibility in hours and working
environment, creativity, and how easy it is to enter and advance in the field.

NEED FOR SOFTWARE ENGINEERING

To understand the necessity for software engineering, we must pause briefly to look back at
the recent history of computing. This history will help us to understand the problems that
started to become obvious in the late sixties and early seventies, and the solutions that have
led to the creation of the field of software engineering. These problems were referred to by
some as "The software Crisis," so named for the symptoms of the problem. The situation
might also been called "The Complexity Barrier," so named for the primary cause of the
problems. Some refer to the software crisis in the past tense. The crisis is far from over, but
thanks to the development of many new techniques that are now included under the title of
software engineering, we have made and are continuing to make progress.

In the early days of computing the primary concern was with building or acquiring the
hardware. Software was almost expected to take care of itself. The consensus held that
"hardware" is "hard" to change, while "software" is "soft," or easy to change. According,
most people in the industry carefully planned hardware development but gave considerably
less forethought to the software. If the software didn't work, they believed, it would be easy
enough to change it until it did work. In that case, why make the effort to plan?

The cost of software amounted to such a small fraction of the cost of the hardware that no one
considered it very important to manage its development. Everyone, however, saw the
importance of producing programs that were efficient and ran fast because this saved time on
the expensive hardware. People time was assumed to save machine time. Making the people
process efficient received little priority.

This approach proved satisfactory in the early days of computing, when the software was
simple. However, as computing matured, programs became more complex and projects grew
larger whereas programs had since been routinely specified, written, operated, and
maintained all by the same person, programs began to be developed by teams of
programmers to meet someone else's expectations.

Individual effort gave way to team effort. Communication and coordination which once went
on within the head of one person had to occur between the heads of many persons, making
the whole process very much more complicated. As a result, communication, management,
planning and documentation became critical.

Consider this analogy: a carpenter might work alone to build a simple house for himself or
herself without more than a general concept of a plan. He or she could work things out or
make adjustments as the work progressed. That's how early programs were written. But if the
home is more elaborate, or if it is built for someone else, the carpenter has to plan more
carefully how the house is to be built. Plans need to be reviewed with the future owner before
construction starts. And if the house is to be built by many carpenters, the whole project
certainly has to be planned before work starts so that as one carpenter builds one part of the
house, another is not building the other side of a different house. Scheduling becomes a key
element so that cement contractors pour the basement walls before the carpenters start the
framing. As the house becomes more complex and more people's work has to be coordinated,
blueprints and management plans are required.

As programs became more complex, the early methods used to make blueprints (flowcharts)
were no longer satisfactory to represent this greater complexity. And thus it became difficult
for one person who needed a program written to convey to another person, the programmer,
just what was wanted, or for programmers to convey to each other what they were doing. In
fact, without better methods of representation it became difficult for even one programmer to
keep track of what he or she is doing.

The times required to write programs and their costs began to exceed to all estimates. It was
not unusual for systems to cost more than twice what had been estimated and to take weeks,
months or years longer than expected to complete. The systems turned over to the client
frequently did not work correctly because the money or time had run out before the programs
could be made to work as originally intended. Or the program was so complex that every
attempt to fix a problem produced more problems than it fixed. As clients finally saw what
they were getting, they often changed their minds about what they wanted. At least one very
large military software systems project costing several hundred million dollars was
abandoned because it could never be made to work properly.
The quality of programs also became a big concern. As computers and their programs were
used for more vital tasks, like monitoring life support equipment, program quality took on
new meaning. Since we had increased our dependency on computers and in many cases could
no longer get along without them, we discovered how important it is that they work correctly.

Making a change within a complex program turned out to be very expensive. Often even to
get the program to do something slightly different was so hard that it was easier to throw out
the old program and start over. This, of course, was costly. Part of the evolution in the
software engineering approach was learning to develop systems that are built well enough the
first time so that simple changes can be made easily.

At the same time, hardware was growing ever less expensive. Tubes were replaced by
transistors and transistors were replaced by integrated circuits until micro computers costing
less than three thousand dollars have become several million dollars. As an indication of how
fast change was occurring, the cost of a given amount of computing decreases by one half
every two years. Given this realignment, the times and costs to develop the software were no
longer so small, compared to the hardware, that they could be ignored.

As the cost of hardware plummeted, software continued to be written by humans, whose

wages were rising. The savings from productivity improvements in software development
from the use of assemblers, compilers, and data base management systems did not proceed as
rapidly as the savings in hardware costs. Indeed, today software costs not only can no longer
be ignored, they have become larger than the hardware costs. Some current developments,
such as nonprocedural (fourth generation) languages and the use of artificial intelligence
(fifth generation), show promise of increasing software development productivity, but we are
only beginning to see their potential.

Another problem was that in the past programs were often before it was fully understood
what the program needed to do. Once the program had been written, the client began to
express dissatisfaction. And if the client is dissatisfied, ultimately the producer, too, was
unhappy. As time went by software developers learned to lay out with paper and pencil
exactly what they intended to do before starting. Then they could review the plans with the
client to see if they met the client's expectations. It is simpler and less expensive to make
changes to this paper-and-pencil version than to make them after the system has been built.
Using good planning makes it less likely that changes will have to be made once the program
is finished.

Unfortunately, until several years ago no good method of representation existed to describe
satisfactorily systems as complex as those that are being developed today. The only good
representation of what the product will look like was the finished product itself. Developers
could not show clients what they were planning. And clients could not see whether what the
software was what they wanted until it was finally built. Then it was too expensive to change.

Again, consider the analogy of building construction. An architect can draw a floor plan. The
client can usually gain some understanding of what the architect has planned and give feed
back as to whether it is appropriate. Floor plans are reasonably easy for the layperson to
understand because most people are familiar with the drawings representing geometrical
objects. The architect and the client share common concepts about space and geometry. But
the software engineer must represent for the client a system involving logic and information
processing. Since they do not already have a language of common concepts, the software
engineer must teach a new language to the client before they can communicate.

Moreover, it is important that this language be simple so it can be learned quickly.

Evolution of Software

In software engineering, change in requirements and context of use is the major factor in cost
and impacts the areas of requirements engineering, software maintenance, and software
evolution. Evolvability as a capacity to generate adaptive variability in tandem with
continued persistence of software artifacts would be welcome in software engineering.
Factors supporting evolvability in artifact and software design, systems theory, and digital
evolution have analogues in biological evolvability. Certain properties of artifacts and of
software are recognized as enhancing their capacity to support and be adapted to changing
requirements and context of use, yielding flexibility of use and variability tolerance.

Software maintenance - the process of changing a software system after its release - is the
most expensive part of software costs, estimated as accounting for as much as 80% of effort
(e.g. Sommerville 1996, ch. 22; Pressman 1992, ch. 20). Corrective, adaptive, and perfective
maintenance of software to satisfy mutable requirements provides a mechanism for
inheritance and (highly non-random) variability of software artifacts. Requirements,
economic and power relationships, accountability, and usefulness of the software in
functioning in context all contribute contribute to the dynamic and social process of software
requirements engineering as the reconcilation of technical and social issues (Goguen 1994,
1996). Brittleness of current software systems in the face of requirements change is thus a
huge problem for software engineering. Existing software is not robust changing
requirements and contexts of use. Re-use (not replication), modularity, information
hiding, encapsulation, and object-oriented `inheritance' are some mechanisms that software
engineers have developed in order to provide robustness to environmental and requirements
change in the course of software `evolution'. These are intended to improve the capacity of
software for adaptation. Nevertheless, practical methodologies and theoretical understanding
of how to build maintainable software are still for the most part a wide open research areas.
We still do not have really good methods for how to grow or evolve software systems.

Software Engineering Goals

Programming has evolved over the years. Many modern software systems are much larger
and more complex than common applications of the past. Older programming techniques
have shown themselves to be grossly inadequate to implement these newer systems. From
this need for more sophisticated programming techniques the discipline called Software
Engineering was born. Software Engineering embodies many techniques that could arguably
require volumes to describe. Generally such practices as top-down design, structured
programming and design, pseudocode with iterative refinement, walk-throughs and OOP
(Object Oriented Programming) are considered to be part of this discipline. Many advanced
constructs in modern programming languages such as C++ were incorporated to meet
the Software Engineering Goals given below.

1. All programming projects should begin with functional descriptions which become
the highest level pseudocode. Every module and every routine, high or low level,
should have a functional description approptiate to its level of abstraction.

2. Functional descriptions determine high level pseudocode should be iteratively refined

to low level pseudocode. The pseudocode becomes internal documentation.

3. Pseudocode should be organized into modules, thus ultimately organizing the project
into modules.

4. Computer code for all routines and main programs should be generated from low
level pseudocode. The pseudocode should become internal documentation.

5. Module interface specifications should be created so that modules may be created

independently.

6. Programs should be constructed from modules.

7. All support routines should reside in separately compiled modules.

8. Each module should only contain routines whose functions are related.

9. Inter-module communication should be accomplished solely through passing

parameters. No global variables should be used. Parameters should be passed "by
value" where required access is read-only.

10. Communication between routines in the same module should also only be
accomplished through parameter passing.

11. Low level routines should have simple and explicit functions. For example low level
routines should not do any I/O (especially interaction with the user) unless that is the
sole function of that routine.

12. Support routines should be evaluated with respect to flexibility and efficiency.

13. Include files should be used where required to effect inter-module independence and
consistency. For example data-type definitions should be included to attain consistent
definitions global to all modules.

14. Changes (such as changes to underlying data structures) in low level routines should
not require source code changes in high level routines. This is accomplished by
carefully constructing the calling interface to adhere to data abstraction principles.

15. Changes (such as changes to the driving application) in high level routines should not
require source code changes in low level routines. This is accomplished by carefully
constructing the calling interface to adhere to data abstraction principles.

16. Changes to high level routines should not require low level routines to be recompiled.
 17. Changes to low level routines should not require high level routines to be recompiled.
(This is generally very difficult to achieve.)

18. Modules should be constructed so that private support routines are not accessible
outside the module. This may be accomplished using sub modules or language-
dependent protection mechanisms.

19. Modules should be constructed so that internal data structures can be accessed only
through authorized routines.

20. All program changes should start with a change to the highest level pseudocode
appropriate to that change. This ensures that pseudocode accurately reflects the
structure of the underlying code.

Software Engineering Basics

The goal of software engineering is to be discipline that provides models and processes that
lead to the production of well documented maintenable software in a manner that is
predictable. For a mature process it should be possible to determine in advance how much
time and effort will be required to produce the final product. This can only be done using data
from past experience which requires that onemeasure the software process.

Models of the development process are essential if it is to be possible to predict the cost of a
software project. Some of what you will see in this course may seem obvious or just common
sense. Experience will convince you that most software projects fail because they ignore this
common sense.

Whichever model of the software process you use they will all have some things in common.

1. A specification phase,
2. A design phase,
3. A planning phase,
4. A module specification phase,
5. A testing phase.
Software Engineering also calls for the ability to make precise specifications of the behaviour
of software systems. Several methods exist for doing this. Algebraic specification uses formal
techniques based upon specification languages, the Booch method is a graphical technique
for describing and thus specifying the behaviour of a system. In fact no one system is likely
to be able to do everything, the best software engineers will use a mixture of these
techniques.

THE SPECIFICATION PHASE

The goal of the specification phase is to produce a specification document that wil serve as
the contract between the system builder and the client. This document must be
understandable by both sides. It should be precise enough for the developer to use. It must
contain acceptance criteria.

Note that there is an important distinction between trustworthy and reliable software. Reliable
software has a long mean time between failures. Trustworthy software is guaranteed not to
fail. In the case of life critical systems reliable is not good enough. The phone service
switching software is relialbe, but not trustworthy. Nuclear power stations are supposed to
have trustworthy software.

THE DESIGN PHASE

There are many apporaches to the design phase. In this course we shall be using the Object
modelling technique. This method of systems analysis uses three models of the system:

THE OBJECT MODEL

Systems are regarded as collections of objects which communicate with one another
by sending messages. Daigrams are used to illustrate the relationships between the
objects.
The Dynamic Model
State diagrams and event traces are used to show the active processes of the system.
THE FUNCTIONAL MODEL
Data Flow diagrams model the movement of data through the system.

These models provide the basic documents from which the module specification will
be written.

PROJECT PLANNING

Planning for the carrying out of a project is a most important part of the process of managing
software. Effective planning depends on having good access to historical data for the purpose
of estimating how long various parts of the project will take.

Before planning can take place it is essential that one have an estimate for the size of the
project. If the size is given in thousand lines of delivered source code (KDSI) then there is a
formula (the COCOMO formula) for the nominal effort in person months that can be used:

Nominal effort = 2.8 * (KDSI)**1.20

Better estimates can be made by dividing the project into modules and estimating the time
required for each module. This is especially important when different groups will be working
on the different modules.

There are various tools that can aid in the planning process. One of the more useful is the
PERT chart which shows the dependencies between the subtasks and can this be used to
determine the critical path to give the estimate for completion time.

ALGEBRAIC SPECIFICATION

One of the goals of software engineering is to automate the process of writing software as
much as possible. Algebraic specification is one way in which this goal may be achieved.
(another is through the use of Computer Aided Software Engineering CASE for short.

The idea behind algebraic specification is that if the behaviour of a program can be specified
in enough detail then two things should be possible

1. It should be possible to prove things about the specification. For example that it is
complete and correct.
2. It should be possible to automatically generate the executable from the specification.

The following are representative methods for formal specifications.

1. Finite State Machines

2. Petri Nets
3. Z. Note that this is pronounced in ``English'' zed

While not formal or algebraic it is also possible to specify modules in English. This method is
usually adopted in the descriptions of interfaces to such things as the Microsoft Foundation
classes.

The ``holy grail'' of algebraic specification is executable specification.

The prolog programming language has been touted as an executable specification language.

THE TESTING PHASE

The Testing Phase: Improve Quality.

Phase Deliverable
Testing Regression Test
Internal Testing
Unit Testing
Application Testing
 Stress Testing

Simply stated, quality is very important. Many companies have not learned that quality is
important and deliver more claimed functionality but at a lower quality level. It is much
easier to explain to a customer why there is a missing feature than to explain to a customer
why the product lacks quality. A customer satisfied with the quality of a product will remain
loyal and wait for new functionality in the next version. Quality is a distinguishing attribute
of a system indicating the degree of excellence.
REFRENCES

1.^ http://www.peo.on.ca/enforcement/Software_engineering_page.html

2.^ http://www.apegga.com/pdf/Guidelines/32.pdf

3. http://www.hitmill.com/computers/intro.html

4. http://www.crews.org/curriculum/ex/compsci/articles/generations.htm

5. Software Engineering Code of Ethics

6. Association of Professional Engineers, Geoscientists and Geophysicists of Alberta

7. http://inventors.about.com/library/blcoindex.htm

8. Roger’s Pressman’s Software Engineering, the text book.

9. Peter, Naur; Brian Randell (7–11 October 1968). "Software engineering: Report of a
conference sponsored by the NATO Science Committee" (PDF). Garmisch, Germany:
Scientific Affairs Division, NATO. Retrieved 2008-12-26.