2.1.

Overview of Software Development

Software development is a discipline in the computer science field that focuses on the creation of
programs that control computer hardware. These programs, also referred to as 'software
applications' or in short 'apps', are groups of instructions that tell a computer what is to be done.
The software development field consists of several computer programming languages, each
designed to fulfill various requirements depending on the project at hand.

It is almost unbelievable to think that a few decades back, the programmers did not even have
desktop computers to work on. Instead they punched instructions into paper cards which were
input into a mainframe computer centrally located in a "machine room". In those times, these
instructions were written in assembly language or machine code, the native language used by
hardware of the computer. As software development evolved, 'higher level' languages were
developed patterning natural languages and better reflecting the human problem-solving process.
Even today, assembly language is still used, especially by low-level engineers developing
computer components and embedded systems. But, most of the desktop and web-based
development is done using high-level languages like ASP, C++, C#, Java, Perl, etc.

If hundred programmers were asked, 'What do they think is the best programming language for
beginners?' you might get one hundred and one answers. Each individual has an opinion. The
question is akin to asking what is the best vehicle to drive - there is simply no right or wrong
answer. Fortunately, some general guidelines exist to get the novice programmer off to a good
start. However, those who are completely new to computers and unsure of whether they are up to
the task (or whether software development will be of interest to them) should start with a
language that is designed to teach basic principles with very minimal complexity. The BASIC
and LOGO programming languages were early attempts to bring computer programming to the
masses. Today a language like Microsoft's Visual Basic would be ideal for a beginner. Visual
Basic helps you to make practical applications with a visual interface in a matter of hours
without getting bogged down by the technical details. Unlike BASIC and LOGO, Visual Basic
has practical applications that can be used in both casual and commercial environments.

Those who are technically inclined or already have a fair amount of experience with computers
may be prepared for more advanced programming concepts. For many years, Pascal was
considered the entry language for such people, and was generally used in schools and
universities to teach programming at a professional level. Nowadays more "practical" languages
like C++, C#, and Java are taught for the reason that they provide a more direct approach to
learning how to develop software with tools that are more commercially viable than Pascal.

Life Cycle of a Software Development Project

Software development is a complicated process comprising different stages. Each stage requires
a lot of paperwork and documentation in addition to the process of development and planning.
This is in contrast to the common thinking of newcomers to the software industry who believe
that software development is just writing code.
Every software development project has to go through the following stages at least once:

Requirement gathering

Writing functional specifications

Creating architecture and design documents

Implementation and coding

Testing and quality assurance

Software release

Documentation

Support and new features

There may be many additional steps and stages depending upon the nature and the type of the
software product. You may have to go through more than one cycle during the testing phase as
software testers to find problems and bugs. The developers need to fix them before a software
product is officially published or released. Let us go into these stages in detail.

Requirement Gathering

Requirement gathering is usually the first stage of any software product. This stage officially
commences when you are thinking about developing software. In this phase, you meet customers
or prospective customers, and do a market analysis of the requirements and features that are in
demand. You might as well find out if there is a real need in the market for the software product
you are trying to develop. In this stage, most of the work is done by the marketing and sales
people, or people who have direct contact with the customers. These people talk to customers
and try to understand what exactly their requirements are.

A comprehensive understanding of the customers needs and writing down features of the
proposed software product are the keys to success in the requirement gathering phase. This phase
is actually a base for the whole development of the software. If the base is not laid appropriately,
the product will not find a place in the market. If a very good software product which is not
required in the market is developed, it does not sell no matter how well you build it. You can find
many instances of software products that failed in the market because the customers did not
require them. The marketing people usually create a Marketing Requirement Document or MRD
that contains formal representation of the market data gathered. You can also consider your
competitors products (if any). This process is called competitive analysis.
Finally, list down the features required by the product. Appropriate consideration must be given
to the economics of software creation at this point. Questions that must be asked are: is there a
market? Can I make some profit? will the revenue justify the cost of development?

Writing Functional Specifications

Functional specifications may consist of one or more documents. These documents show the
behavior or functionality of a software product on an abstract level. Assuming the product is a
black box, these specifications define its input/output behavior. The product requirements
documentation put forward by people who have contact with the end user of the product or the
customers, forms the basis of the functional specifications.

In larger products, functional specifications may consist of separate documents for each feature
of the product. For example, if the product is a router, you may have a functional specification
document for RIP (Routing Information Protocol), another for features on security, and so on.
Functional specifications are important because developers use them to create design documents.
The documentation people also use them when they create manuals for end users. If different
groups are working in different physical locations, functional specifications and architecture
documents (discussed next) are also a means to communicate.

Keep in mind that sometimes during the product development phase you may need to amend
functional specifications keeping in view new marketing requirements.

Creating Architecture and Design Documents

When you have all of the requirements collected and arranged, it is the turn of the technical
architects team, which usually consists of highly qualified technical specialists, to create the
architecture of the product. This defines different components of the product and how they
interact with each other. Often, the architecture also defines the technologies used to develop the
product. While creating the architecture documents, the team also needs to consider the timelines
of the project. This is the target date when the product is required to be on the market. Often
excellent products fail because they are either too early or late to market. The marketing and
sales people usually decide a suitable time frame to release the product. Based on this timeline,
the architecture team may drop some features of the product if it is not possible to bring the full-
featured product to market within the required time frame. After deciding the components of the
product and defining their functionalities, interfaces are designed for these components to work
together.

Most often, no component works in isolation; each one has to coordinate with other components
within the project. Interfaces are the rules and regulations that define how these components will
interact with each other. There maybe major problems down the road if these interfaces are not
designed properly and appropriately detailed. Different people will work on different
components of any large software development project and if they dont fully understand how a
particular component will communicate with others, major problems arise during integration. For
some products, new hardware is also required to make use of technology advancements. The
architects of the product also need to consider this aspect of the product. Once the architecture,
software components and their interfaces are defined, design documents are created as the next
phase of development. At the architecture level, a component is defined as a black box that
provides certain functionality. At the design documents stage, you have to define what is in that
black box.

The design documents are usually created by the senior software developers and these
documents define individual software components to the level of functions and procedures. This
is the last document completed before development of the software starts. These design
documents are passed on to software developers as they begin coding. Architecture documents
and MRDs usually need to stay in sync, as sales and marketing will work from MRDs while
engineering works from engineering documents.

Implementation and Coding

The software developers use the design documents and development tools (editors, compilers,
debuggers etc.) and start writing software. This is often the longest phase in the product life
cycle. Every developer has to write his/her own code and collaborate with other developers to
make sure that the different components can inter-operate with each other. A revision control
system such as CVS (Concurrent Versions System) is needed in this phase. There are many open
source revision control systems as well as commercial ones available these days. The version
control system provides a central repository to store the individual files. A normal software
project may contain anywhere from hundreds to thousands of files. In larger and complex
projects, directory hierarchy must also be decided beforehand so that files are stored in
appropriate locations. During the development cycle, different developers may modify the files.
If the rules are not followed by everybody, this may easily break the whole compilation and
building process. A typical example is duplicate definitions of the same variables causing
problems.

Similarly, if included files are not written properly, loops get created easily. Other problems pop-
up when multiple files are included in a single file with conflicting definitions of variables and
functions. Coding guidelines must also be defined by architects or senior developers. As an
example, if software is intended to be ported to some other platform, it must be written on a
standard like ANSI. During implementation, developers must write enough comments inside the
code so that if anybody starts working on the code in the future, he/she would be able to
understand what has already been written. Writing good comments is extremely important as all
other documents, no matter how good they are, will be lost eventually. Ten years subsequent to
the initial work, it's probable that you may find only that information which is in the form of
comments, present inside the code. Development tools also play an important role in this phase
of the project.

Good development tools save a lot of time for the developers. They also help to save money in
terms of improved productivity. In terms of time saving the most important development tools
are editors and debuggers. An editor helps a developer to write the code quickly.

A good debugger helps to make the code operational in a short period of time. Before the start of
the coding process, considerable time must be spent in choosing good development tools. During
the development phase, review meetings also prove helpful. Through review meetings, potential
problems are identified earlier in the development. Review meetings are also helpful to keep
track of whether the product is on time or if more effort is needed to complete it within the
required time frame. There will be times when you may also need to make changes in the design
of some components because of new requirements from the marketing and sales team. Review
meetings are a great tool to convey these new requirements. Here, architecture documents and
MRDs are kept in sync with any changes/problems encountered during development.

Testing

Testing is probably the most important phase for long-term support as well as for the company's
reputation. If you dont control the software quality, it will not be able to compete with other
products on the market. If software crashes at the site of the customer, he loses productivity as
well money and you lose credibility. On most occasions these losses are huge. Unhappy
customers will never buy other products from the same vendor and will not refer other potential
customers. You can avoid this situation by doing extensive testing. This testing is often called as
Quality Assurance, or QA, in the software world. Generally testing starts as soon as the initial
software components are available. There are multiple types of testing. Each of these has its own
importance.

1. Unit Testing - Unit testing is testing one part or one component of the product. The developer
generally does this when he/she has completed writing code for that part of the software. This
makes sure that the component is doing what it is intended to do. This also helps the software
testers as well as developers save time by eliminating many cycles of software being passed back
and forth between the developer and the tester. When a developer is ready with a particular part
of the software, he/she can write test cases to test the functionality of this part of the software.
The component is then passed on to the testers who run test cases to make sure that the unit is
working properly.

2. Sanity Testing - Sanity testing is a very basic check to see if all the software components
compile with each other without any problems. This is to ensure that developers have not defined
conflicting or multiple functions or global variable definitions.

3. Regression or Stress Testing - Regression or stress testing is a process done in some projects
to carry out a test for a longer time period. This type of testing is used to determine the behavior
of a product when used continuously over a period of time. It can expose some bugs in software
like the ones related to memory leakage. In some cases, developers allocate memory but forget to
release it. This is usually referred to as memory leakage. When testing goes on for many days or
weeks, it often results in allocation of all of the available memory until no memory is left. This is
the point where your software starts showing abnormal behavior. Another potential problem in
long-term operation is counter overflow. This happens when you increment a counter but forget
to decrement it resulting in an overflow when the product is used for long time. The regression
testing may be started as soon as some components are ready. This type of testing requires, by its
very nature, a very long period of time. The process should be continued as more components of
the product are integrated. The process of integration and communication through interfaces may
create new bugs in the code.
4. Functional or System Testing - Functional testing is carried out to make sure that the
software is doing exactly what it is supposed to do. This must be done before any software is
released to customers. Functional testing is done by testers whose primary job is software testing,
and not the developers themselves. In small software projects where a company cant afford
dedicated testers, other developers may also do functional testing. The key point to keep in mind
is that the person who wrote a software component should not be the person who tested it. A
developer will always have a tendency to test the software the way he/she wrote it. He/she may
easily miss any problems in the software. The testers need to prepare a testing plan for each
component of the software. A testing plan would contain test cases that are run on the software.
The tester can prepare these test cases using functional specifications documents. The tester may
also get assistance from the developer to create test cases. Each test case must include
methodology used for testing and expected results. Additionally, the tester may also need to
create certain infrastructure or environment to test the functionality of a piece of code. For
instance, you may simulate a network to test the routing algorithms that may be part of a router.
The next important job of the tester is to create a service request if an anomaly is found. The
tester must include as much information in the service request as possible.

Typical information included in reporting bugs includes:

Test case description

How the test was carried out

Expected results

Results obtained

A description of that environment, if a particular environment was created for testing

The bug should be forwarded to the developer so that the developer may correct the problem.
Many software packages are available in the market to track bugs and fix problems in software.

Software Releases

Any software product is officially released before you start selling it. This means that you create
a state of the software in your repository, ensure that it has been tested for functionality and the
code is frozen. A version number is assigned to the released software. After releasing,
development may continue but it will not make any change in the released software. The
development is often carried on in a new branch and it may contain new features. The released
software is updated only if a bug fixed version is released. Generally companies assign
incremental version numbers following some scheme when the next release of the software is
sent to market. The version number change depends on whether the new software contains a
major change to the previous version or it contains bug fixes and enhancement to the existing
functionality. Software releases are also important because they are typically compiled versions
of a particular code version, and thus provide a stable set of binaries for testing.
1. Branches - In almost all serious software development projects, a version control system is
used. This system keeps a record of changes in source code files and is usually built in a tree-like
structure. During the release of the software, the state of each file that is part of the release
should be recorded. By creating branches to this state, future developments can be made.
Sometimes special branches may also be created that are solely used for bug fixing.

2. Release Notes - Every software version contains release notes. These are prepared by people
releasing the software version with the help of the developers. Release notes show what
happened in this software version.

Typically the information includes:

Bug fixes

New functionality

Details of new features added to the software

Any bugs that are not yet fixed

Future enhancements

If a user needs a change in the configuration process, it is also mentioned

Generally a user must be given enough information to understand the new release enhancements
and decide whether an upgrade is required or not.

Documentation

There are broadly three categories of documentation related to software development processes:

Technical documentation developed during the development process, such as the

architecture, functional and design documents.

Technical documentation prepared for technical support staff, including technical

manuals that support staff use to provide customer support.

End-user manuals and guides. This is the documentation for use of the end user. It assists
the user in getting started with the product and using it.

All three types of documents are necessary for different aspects of the support of the product.
Technical documents are necessary for future development, bug fixes, and adding new features.
Documentation for technical support staff contains information that is too complicated for the
end user to understand and use. The support team needs this information in addition to user
manuals to provide better support to customers. Finally each product should have the user
manuals. Technical writers often develop user manuals which are based on functional
specifications. In the timelines of most software development projects, even before the start of
code development, functional specifications are prepared. So the technical writers can start
writing user manuals while developers write the code. So when the product is ready, the user
manual is almost completed.

Support and New Features

Your customers need support when you sell a product. This is true regardless of the size of the
product, and even for non-software related products.

The most common support requests from customers are related to one of the following:

Help in installation and getting started

To release a patch or update to the whole product

A new feature required by the customer

In addition to these, you may also want to add new features to the product for the next release
because competitor products have other features. Better support will increase your customer
loyalty and will create referral business. You may adopt two strategies to add new features. You
may provide an upgrade to the current release as a patch, or wait till you have developed a list of
new features and make a new version. Both these strategies are useful depending how urgent the
requirement for new features is.

2.2. Overview of problem solving Techniques

Good problem solving skills empower managers in their professional and personal lives. Good
problem solving skills seldom come naturally; they are consciously learnt and nurtured. Good
problem solving skills should include:

developing innovative and creative solutions;

developing solutions which are practical;

showing independence and initiative in identifying problems and solving them;

applying a range of strategies to problem-solving;

applying problem-solving strategies across a range of areas;

What is a Problem?
A problem can be defined as an opportunity for improvement. Every problem has a gift for you
in its hands, says Richard Bach. An optimist looks at challenging or problematic events as
potential opportunities for improvement. He will be always seeking answers for the questions
such as:

Is there more than one probortunity? "Probortunity a synonym by combining the

words problem and opportunity.

Is it my personal probortunity or Is it the probortunity of the organization?

Is it an annoyance or an actual probortunity?

Is this the real probortunity, or merely a symptom of a larger one?

A problem can be defined as the difference between the actual state and the desired state. A
problem could also be the result of the knowledge that there is a gap between the actual and
desired or ideal state of objectives. Clarity of the problem is determined by the clarity of the
knowledge which one precisely wants and which one has. Greater clarity of the problem will
help in finding a better and an effective solution.

A problem can also result from the recognition of an imperfect present and the belief in the
possibility of a better future. The belief that one's hopes can be achieved will give one the will to
aim towards a better future.

Key approaches to Problem solving

There are different ways of problem solving each has its own advantages and disadvantages.
The process an individual adopts as a manager will be influenced by organizational policies,
his/her own personality and communication style, and the kind of information available about the
problem. Broadly, there are two problem solving models available to a manager.

A. Rational Problem-Solving

Rational problem solving rests on the following principles (R. K. Wagner - Learning to solve
practical problems):

Problems are identified by comparing actual performance with an expected standard

performance

Problems are deviations in actual performance from the expected standard

A precise and complete description of the problem is needed to identify a solution

What is happening?
 Where is it happening?

When is it happening?

To what extent is it happening?

The cause of the problem can be found by comparing the problem and non-problem
situations.

Recent problems are due to some change in the situation that has caused an unwanted
deviation from expectations.

The Rational Decision-Making model requires the following steps, which if followed, are
assumed to lead to "value-maximising choices." These steps are as follows:

need to define the problem,

identify the decision criteria,

weigh the criteria which can be used to determine rank of importance,

generate alternative solutions,

rate each alternative on a different criteria, and

compute the optimal decision.

B. Lateral or Creative Problem-Solving

Lateral or creative problem solving does not follow any standard set of procedures. It is a
subconscious process based on past distilled experiences. It is based more on the gut feeling of
the manager than on an objective process of weighing alternatives.

There are a set of conditions and it is accepted that under those conditions intuitive approach is
generally preferred to rational approach. Intuitive method is preferred when:

there is a high level of uncertainty,

little precedence to draw on exists,

variables are not that easily predictable,

facts are limited or facts are contradictory,

 analytical data is not of much use,

there are several plausible solutions; and

decision needs to be made in a short period of time

The creative/lateral problem solving is very flexible. So it can be used to examine real problems
and issues.

Problem solving process

There are a variety of problem-solving processes. But each process consists of a series of steps
which include identifying the problem, searching for possible solutions, selecting the most
optimal solution and implementing a possible solution. It is useful to view problem solving as a
cycle because, sometimes, a problem needs several attempts to solve it or at times the problem
itself changes. The diagram below shows a seven-step problem solving process.

2.1 : Seven-Step Problem Solving Process

1. Identifying the Problem: The first step in the problem solving process is sizing up the
situation to identify the problem. This may sound simple enough, but sometimes managers might
be uncertain about even what the problem is; they might just be feeling anxious or be confused
about what is getting in the way of their objectives. If that is the case, they can ask themselves or
consult with their friends or a professional expert. Other useful techniques for identifying the
problem include-

Comparison with others

Monitor for weak signals

Brainstorming

Checklists

Comparison of current performance with objectives or past performance

Listing complaints & role playing

2. Exploring the Problem: Having identified the problem, managers should analyze the problem
to see what is the root cause for it. Often people get caught up in symptoms or effects of a
problem or issue and never drill down to the real cause. They get mad at someones attitude,
anger, or actions, which is not the real cause of the problem. The key here is to focus on
analyzing the problem for the real root cause without being affected by emotional issues. Seeking
answers to questions such as the following will help explore the problem:

Identify the Problem Ask Who?

Who says that this is a problem?

Who caused or is causing the problem?

Whom does it or will it affect?

Who has done something about the problem?

Identify the Problem Ask What?

What happened or will happen?

What are the symptoms?

What are the consequences for others?

What circumstances surround the occurrence of the problem?

What is not functioning as desired?

Identify the Problem Ask When?

Did it or will it happen?

Why did it happen?

When did it first occur?

Identify the Problem Ask Where?

Where is the problem occurring?

Did it or will it have an impact?

Where did it have an impact?

Identify the Problem Ask Why?

Why is this, a problem?

Did it or will it occur?

Why did it occur?

Why was nothing done to prevent the problem from occurring?

Why did no one recognize and do something about the problem at the earliest?

Why is a response needed now?

Identify the Problem Ask How?

How should the process be working?

How are others dealing with this or similar problems?

How do you know this is a problem; what supporting information do you have?

Once the root cause is found, plans can be made to fix it. Analyzing implies gathering
information. If there is not enough information, they should find some ways to research and
collect it.

3. Set Goals: Having explored and analyzed the problem, managers should be able to write a
goal statement that focuses on what is the successful end of the process. Once the root cause is
found, plans can be made to fix it. Analyzing implies gathering information. If there is not
enough information, they should find some ways to research and collect it.

Making and writing down a goal statement will:

help them to clarify the direction to be taken in solving the problem; and

give them something definite to focus on

That is, what will occur as a result of the solution? This whole process is about fixing or closing
the gap between the problem and the goal. Writing down the problem ensures that they are not
side-tracking from, but addressing the problem.

4. Look at alternatives: Now that the problem has been analyzed, the managers can start
developing possible solutions. This is a creative as well as practical step where every possible
solution needs to be identified. They should identify the various alternative solutions available to
them through techniques such as

Analysis of past solutions

Reading

Researching & thinking

Discussing

Asking Questions

Viewing the problem with fresh eyes

Sleeping on it

Brainstorming

The idea is to collect as many alternative solutions as possible. Mind mapping is another
technique that can be used for finding alternative solutions. Mind mapping uses pictures and/or
word phrases to organize and develop thoughts in a non-linear fashion. It helps people see a
problem and its solution.

Heres how to do mind mapping:

Take a sheet of plain paper and turn it sideways (if using flipchart paper you dont need to
turn it sideways - it is large enough); Using colored felt pens, draw a small picture (or
 write a phrase) in the centre of the paper representing the issue you want to solve; Draw
lines out from the main problem (it helps to use different colors for each line).

Each line should represent a different aspect of your problem or issue;

Write down what each line represents either on top of or on the line;

Add other lines flowing off these main lines;

Write a word or short phrase on the smaller lines indicating what each new line represents
(you may find that mind mapping works best for you if you write down the phrases or
draw the images first and then connect them with the lines); and

If you want, add images next to your main line that illustrate what each line means to you
(some people think better with pictures, others with words).

5. Select the best solution: Now that there are a wide variety of possible solutions available, it is
time to select the best solution from among them to fix the problem, given the circumstances,
resources and other considerations. Here the managers are trying to figure out what exactly
would work best given the nature of the problem. There are always a number of things that can
affect a solution, for instance, money, time, resources, procedures, rules, policies, and so on. All
of these factors must be thought about. Managers should prioritize the solutions by their
effectiveness. This is a slow process of elimination. There may be some possible suggestions that
may need to be immediately eliminated. Eventually, managers should narrow down the choices
to one best possible solution which will promise them the best or optimal outcomes.

6. Implementation: Implementation is a crucial part of problem-solving process. In order to

implement the solutions chosen, managers must have an action plan and communicate it to those
people who are directly and indirectly affected. Gemmy Allen (Problem-Solving & Decision-
Making) says that communication is most effective when it precedes action and events. In this
way, events conform to plans and events happen when, and in the way, they should happen.
Managers should answer the below vital questions before they are asked, like

What should be communicated?

What is the possible reason for the decision?

Whom all will it affect and how?

What are the benefits expected for the individual, department, and the organization as a
whole?

What adjustments will be required in terms of how work will be done?

What is each individuals role in implementing the decision?

 What are the results expected from each individual?

When does the action called for by the decision go into effect?

7. Evaluation: This is the final step in the problem-solving process. Managers should review the
effectiveness of the solution against desired outcomes. Questions like did the solution work? If
not, why? What went right, and what went wrong? What adjustments do they have to make to
ensure that the solution will work better? This stage will require careful analysis that improves
upon the best solution.

The review of your progress can help a manager identify any problem. Steps may need to be
revised or new steps need to be added. One may need to consider a different solution, if the
current one, with which he/she has been, is not helping.

Essentials of Effective Problem Solving

Clear description of the problem

Description of the negative or limiting factors involved in the problem

A description of the positive or the constructive factors involved in the problem

A clear delineation of the ownership of the problem - Whose problem is it: mine, yours,
the other guys, my boss, my spouses, my childs, my parents, my teachers?

Scope of the problem need to be clearly defined: How extensive a problem is it? How
long has this problem existed? How many people are affected by this?

A clear description of the consequences if the problem were not solved - What is the
possible impact on my family, job, life in this community, etc., if this problem isnt
solved? What is the worst possible thing that could happen if this problem isnt solved?

A list of brainstormed solutions to the problem, with each alternative analyzed as to its
reality, its benefits, and the consequences for following each one.

A system of ranking each solution to finalize the decision-making process - A rating

system for analyzing each solution is developed, e.g., 100% chance of success, 75%
chance of success, 50% chance of success.

A clear description of myself as a problem-solver - When it comes to this problem, am I

procrastinating? Am I avoiding the problem? Am I denying the problem? Am I shutting
down or blocking my creativity on this problem? Am I ignoring it, hoping it will go
away? Am I using magical and/or fantasy thinking in addressing the problem?
 Determination to follow through on the solution decided upon jointly. This will involve
full motivation to take the risk and pursue the solution to its fullest.

For further reading you may refer the websites below.

www.cls.utk.edu/pdf/ls/Week3_Lesson21.pdf

www.pitt.edu/~groups/probsolv.html

2.3. Phases in the Execution of a Computer Program

In computer science, a computer program specifies the behavior that is invoked at some point,
causing that behavior to be exhibited by a running program. That means, a program has a
lifetime that includes distinct phases, starting with editing the code that specifies the behavior,
and extending till the execution of the code, which exhibits the specified behavior. The major
phases of a program's lifecycle are edit time, compile time, distribution time, installation time,
link time, load time, and run time.

It is important to be aware that these phases do not necessarily happen in a linear order. But, they
can be intertwined in various ways. For instance, during development of the program, edit time
and compile time are repeatedly performed, without any link, load, or execution.

Edit time is the phase during which the code of the program is being edited. During this phase,
the code may not be finalised. The editing is usually performed by a human programmer.

Compile time is the phase during which the edited program or the source code is translated into
machine code by a compiler.

A compiler is a computer program (or set of programs) that transforms source code written in a
programming language into another computer language (often having a binary form known as
object code). The reason for wanting to transform source code is to create an executable
program. The name "compiler" is primarily used for programs that translate source code from a
high-level programming language to a lower level language (e.g., assembly language or machine
code).

The operations performed at compile time usually include syntax analysis, various kinds of
semantic analysis (e.g., type checks and instantiation of template) and code generation.
Programming language definitions usually specify compile time requirements that source code
must meet to compile successfully. For example, the amount of storage required by types and
variable can be deduced.

Distribution time is the phase during which the program is sent from the entity that created it, to
the one that will invoke it. The format is typically an executable file, but sometimes source code,
especially in the case of a program written in an interpreted language. The distribution method
varies, from physical media such as CD-ROM, to online download via the internet.

Installation time is the phase occurring just after distribution. Here, a program is received into a
system that must perform some form of installation process. The process of installation makes
the program available to be executed within the system. The installation process is able to invoke
different phases of a program's lifecycle. For instance, an executable may be analyzed and re-
compiled during installation in order to improve the execution on the particular hardware of the
system being installed on.

Link time is the phase during which the names of implementations are looked up and connected
together. For instance, a program that invokes libraries does so by stating the name and an
interface of the library. During link time the particular implementation of that interface is
connected to the program that invokes it. This connection can be done inside the compilation
system, or during the installation, as a part of starting execution, or even invoked during the
process of execution.

Load time is the phase in which an executable image is taken from its stored form, and placed
into active memory, as part of starting execution.

Run time is the phase during which the behavior of the program is exhibited. Run time is the
time during which a program is running (executing), in contrast to other phases of a program's
lifecycle such as compile time, link time, load time, etc.

A run-time error is detected after or during the execution of a program, but a compile-time error
is detected by the compiler before the program is ever executed. Storage allocation, type
checking, code generation, and code optimization are typically done at compile time; however it
may be done at run time depending on the particular language and compiler.

For further reading you may refer the websites below.

http://my.safaribooksonline.com/book/programming/9789332514836/chapter-6dot-introduction-
to-c/ch06_sec9_xhtml

1.

1 Dennis Ritchie

2 Ken Thompson

3 Martin Richards
2 C is a

1. high-level language

2. low-level language

3. middle-level language

4. assembly language

2 The C programs are converted into machine language using

1. an assembler

2. a compiler

3. an interpreter

4. an operating system

3 The C was developed in the year

1. 1972

2. 1980

3. 1975

4. 1971

4 The C language has been developed at

1. AT &T Bell Labs, USA

2. IBM, USA

3. Borland International, USA

4. Sun Microsystems

5 The C language is an offspring of the

1. B language

2. ALGOL language
 3. Basic language

4. None of the above

6 The C programs should be written only in

1. lower case

2. upper case

3. title case

4. sentence case

7 The role of a compiler is to translate source program statements to

1. object codes

2. octal codes

3. decimal codes

4. none of the above

8 The extension for C program files by default is

1. .c

2. .d

3. .obj

4. .exe

9 The C language can be used with

1. only Unix operating system

2. only Linux operating system

3. only MS-DOS operating system

4. all the above

10 The C language is closely associated with

1. MS-DOS

2. Linux

3. Unix OS

4. Windows OS

11 The C programs are highly portable. It means

1. same programs execute on different computers

2. program executes only on the same computer

3. program needs a lot of modification to run

4. none of the above

12 Each instruction in C program is terminated by

1. dot (.)

2. comma (,)

3. semi-colon (;)

4. .curly brace ({})

13 Which one of the following statements is incorrect?

1. A compiler compiles the source program

2. An assembler takes an assembly program as input

3. A compiler does the same type of function as interpreter

4. None of the above

14 The program that translates high-level program into its equivalent machine-language
program is called

1. transformer

2. language processor
 3. converter

4. none of the above

15 An interpreter reads the source code of a program

1. one line at a time

2. two lines at a time

3. complete program in one stroke

4. none of the above

16 A compiler compiles the source code

1. complete program in one stroke

2. one line at a time

3. two lines at a time

4. none of the above

Answer key for multiple choice questions

1. (b)

2. (c)

3. (b)

4. (a)

5. (a)

6. (a)

7. (a)

8. (a)

9. (a)

10. (d)
11. (c)

12. (a)

13. (c)

14. (c)

15. (a)

16. (a)

17. (a)