Sie sind auf Seite 1von 16

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 sidetracking 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 recompiled 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-toc/ch06_sec9_xhtml

Das könnte Ihnen auch gefallen