HARDWARE PROJECT MANAGEMENT

What we Can Learn from the Software Development Process for Hardware Design?

Rolf Drechsler and Andreas Breiter

Institute of Computer Science, University of Bremen, 28359 Bremen, Germany

Keywords:

Hardware design, description language, project management, software engineering, project.

Abstract:

Nowadays hardware development process is more and more software oriented. Hardware description lan-

guages (HDLs), like VHDL or Verilog, are used to describe the hardware on the register-transfer level (RTL)

or on even higher levels of abstraction. Considering ASICs of more than 10 million gates and a HDL to gate

ratio of approximately 1:10 to 1:100, i.e. one line of HDL code on the RTL corresponds to 10 to 100 gates in

the netlist, the HDL description consists of several hundred thousand lines of code.

While classical hardware design focuses purely on the development of efﬁcient tools to support the designer,

in industrial work processes the development cycle becomes more and more important. In this paper we

discuss an approach, where known concepts from software engineering and project management are studied

and transferred to the hardware domain. Several aspects are pointed out that should ensure high quality designs

and by this the paper presents a way working towards a more robust design process by a tight integration

of hardware design and project management. The intention of this work is not

to provide an exhaustive

discussion, but many points are addressed that with increasing circuit complexity will become more and more

important for successful ASIC design.

1 INTRODUCTION

Nowadays application-speciﬁc integrated circuits

(ASICs) consist of several million gates. To handle

this complexity a high level of abstraction is needed as

provided by hardware description languages (HDLs),

like VHDL or Verilog. Efﬁcient tools exist to guaran-

tee the translation of HDLs to netlists that can be au-

tomatically placed and routed. Even though in most

cases experienced designers have to optimize man-

ually the description to result in high performance

circuits, the tool support is very satisfying. Sev-

eral methods for efﬁcient high-level and logic syn-

thesis have been developed in the past few years that

are well understood (for an overview see (DeMicheli,

1994; Hachtel and Somenzi, 1996)). Due to changes

in the technology, these techniques are steadily im-

proved, e.g. by also considering layout aspects dur-

ing the synthesis step, but the overall ﬂow of the de-

sign process remained the same. In contrast the form

of the description changed signiﬁcant over the past

years. While ASICs described in HDLs contained

only a few thousand lines some years ago, today’s

design can consist of up to several hundred thousand

lines of code. By this observation it is only a small

step to ask whether the concepts that evolved over the

last couple of years (and are still applied in indus-

trial practice) are adequate to cope with the emerg-

ing complexity of ASICs to be developed in the near

future. The same problem - in a different formula-

tion - arose in the context of software development 30

years ago. Starting from very simple programs huge

software systems grew. Detailed studies showed the

high demand for a structured development process.

The important parameters to guarantee high quality

designs were determined and evaluated resulting in

the ﬁeld of software engineering (Naur and Randell,

1969; Sommerville, 2004). Moreover, the cost of

software projects increased, making it necessary to

develop adequate cost estimation models. In this pa-

per we will study the concepts proposed for the soft-

ware development process and point out that most of

409

Drechsler R. and Breiter A. (2007).

HARDWARE PROJECT MANAGEMENT - What we Can Learn from the Software Development Process for Hardware Design?.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 409-416

DOI: 10.5220/0001324204090416

 SciTePress

the aspects also apply to hardware design based on

HDLs. We will discuss important aspects, like speci-

ﬁcation, (interface) design, and documentation. The

analysis leads to the formulation of a concept that

covers the complete hardware development process

and can easily be integrated in existing ﬂows. This

results from the observation that several of the steps

described in the following are quite intuitive and some

might already be integrated in the development cy-

cle, but in most cases without considering the overall

structure, e.g. some well accepted rules are used as

coding guidelines. As a consequence of the discus-

sion it follows that modern hardware design can and

should consider and incorporate techniques known

from software engineering and project management

to allow high quality designs. Analogously to the

software domain, the resulting process describes the

tight integration of project management and hardware

design. Note, that the points addressed in the follow-

ing are not complete and the paper can only be seen

as ﬁrst step in this direction. Starting with the anal-

ysis of similarities between hardware and software

development processes, we will introduce a process

model for hardware-engineering. The three constitut-

ing layers will be explained in detail, focusing espe-

cially on project management and aspects of quality

management within the hardware development pro-

cess. The paper closes by reﬂecting core problems in

hardware design which might occur during the devel-

opment process.

2 SIMILARITY BETWEEN

HARDWARE AND SOFTWARE

DEVELOPMENT PROCESS

The “classical” hardware development process - in

a simpliﬁed way - is shown in Figure 1. Starting

from an initial idea, a speciﬁcation is written as a

text. This is later formalized, such that it can be sim-

ulated, e.g. in a programming language like C. Then

a designer writes the code in a hardware description

language, like VHDL or Verilog. In a next step the

netlist is generated by automatic logic synthesis tools

and mapped to the layout later. From this description

the ﬁnal chip is produced. It can be observed that the

main part has to do with coding, similar to software

development.

Recent years have seen a pronounced shift in soft-

ware engineering practice away from linear water-

fall process models toward the iterative approaches

pioneered by Boehm (Boehm, 1988) and others.

Boehm’s spiral model point out the basic phases of

software development: inception - analysis - risk as-

sessment - design - implementation - test - deploy-

ment - maintenance. Modern process models tend to

cycle through basic phases (iterative model) and to

use at each development step all information avail-

able from artefacts created in the process. Addition-

ally, we can ﬁnd further similarities between hard-

ware and software description languages. For hard-

ware and software high level languages have been de-

ﬁned to simplify the development process. For soft-

ware, the goal was to leave the low level descriptions,

like assembler, while on the hardware level the cor-

responding format was the schematic entry. Start-

ing from small descriptions, in the meantime com-

plex systems - hardware and software - can have up

to several thousand lines of code. While in the early

beginning single developers build a system, today up

to hundred designers work on a project in parallel.

Even though in ﬁrst programming languages for hard-

ware were very similar to software descriptions (see

e.g. (Chu, 1965)), aspects of concurrency have been

added to HDLs in the meantime. But successful con-

cepts from software are also integrated in HDLs, like

e.g. object orientation.

3 HARDWARE-ENGINEERING:

MANAGING THE HARDWARE

DEVELOPMENT PROCESS

Taking this into account, it becomes obvious that

many problems occurring in hardware development

are very similar to what has been considered in soft-

ware several years ago. In this section, different topics

are considered and their importance to high quality

hardware development is discussed. Here, it should

be noted that several recent studies of larger hardware

design projects showed that many of the design bugs

that are found during the veriﬁcation step do not result

from “real” design errors, but from an incompletely

speciﬁed design ﬂow (see e.g. (Krishnamurthy et al.,

2001; Bentley, 2001)). We will separate the process in

three interconnected layers (see Figure 2) which will

then be described in more detail.

3.1 Product Development Cycle

To get a better understanding of the project work-

ﬂows, the development process is subdivided in three

(more or less) independent steps which are identical

with the “classical” management cycle from planning

to organizing and to controlling.

ICSOFT 2007 - International Conference on Software and Data Technologies

410

Figure 1: Hardware Development Process.

Planning. This phase includes the description of

the hardware architecture and the resulting sub-

components. Additionally, general aspects of avail-

ability of human and technical resources, ﬁnancing,

costs etc. as should be integrated. Especially, already

at this stage methods of quality assurance and pre-

vention, i.e. what happens in an “emergency”, should

be discussed to allow a risk management. During the

planning phase it is also important to describe the re-

sponsibilities of each team member with in the pro-

duction process.

Production. Assuming that all CAD tools are se-

lected, sub-tasks are assigned and the design and cod-

ing phase starts. Already during the creation, the in-

dividual modules are veriﬁed by simulation or formal

techniques. From the experience of several projects of

large size, it can be concluded that it does not make

much sense to start with the complete team at once.

It is better to ﬁrst take a few - but highly qualiﬁed -

designers. These ﬁrst clarify the technical ﬂow, since

in some cases it can be necessary to go back to the

planning phase, if problems occur. Usually, one can

distinguish between the hardest-ﬁrst strategy and the

easiest-ﬁrst strategy depending on the goals and the

schedule of the project.

Checking. This process does not

start after the

product has been build, but has to be considered dur-

ing the complete project cycle. (Of course, at the end

the overall functionality is checked.) This veriﬁca-

tion process already starts at the module level, but

several test, like consistency of interfaces, can only

be considered after all sub-components are available.

Still, most of nowadays ASICs are veriﬁed by simula-

tion, while formal veriﬁcation (equivalence checking,

property checking) or semi-formal veriﬁcation (sym-

bolic simulation, assertion checking) become more

and more important. But the checking phase also in-

volves evaluation of the complete project. It has to

consider the instruction and motivation of the team,

decision making, adaptation of goals (if needed), val-

idation, product delivery, and the ﬁnal evaluation of

the project.

Dependent on the phases a high interaction might

be necessary. From the initial project planning to the

ﬁnal product delivery it usually takes more than three

years for multi-million gate ASICs. Thus, the require-

ments can change during this time and the organiza-

tion structure of a project must be ﬂexible enough to

take these ”re-deﬁnitions” into account.

3.2 Hardware Development Process

The hardware development process can be divided

into several sub-phases which are quite similar to

those in software engineering. In the following the

project phases are addressed, not

the design phases.

The design steps as described in e.g. (DeMicheli,

1994) remain the essential part of the design phase.

HARDWARE PROJECT MANAGEMENT - What we Can Learn from the Software Development Process for Hardware

Design?

411

Figure 2: Three Layer Model of Hardware Engineering.

But to run a successful project, it is important to con-

sider and understand the overall workﬂows.

Initialization. Beside getting to know the project

partner, in the very early phase of the project it has to

be clariﬁed, whether everyone involved has enough

knowledge about the hardware to build. Already in

this phase all “constraints” of the project (resources,

available know-how, time, etc.) should be consid-

ered and written down in the form of a protocol. It

is important in this phase to be as realistic as possible

and not to be to euphoric about the chance of a new

project.

Offer/contract. Based on the ﬁrst contact an of-

fer should be made and if accepted the contracts can

be signed. The offer must be as speciﬁc as possible

and should cover a detailed project description, dates,

structure, warranty etc.

Design: The design phase has been studied inten-

sively over the past twenty years and in the meantime

is well understood. Several commercially available

tools support the designer. From the project man-

agement side, it is important to ﬁrst concentrate on

the main features of the hardware to be build, while

some special “extensions” can often be added in a

later stage.

Prototype. For larger projects it is often helpful

to ﬁrst build a prototype. Depending on the type of

hardware, the prototype can later be extended to a

complete project. The role of the prototype should be

determined ﬁrst, and then the implementation should

start. In the software domain a classiﬁcation in hori-

zontal and vertical prototypes is used which cannot be

transferred directly to the hardware domain. But the

way to build the prototypes, i.e. exploratory prototyp-

ing, experimental prototyping and evolutionary pro-

totyping (see e.g. (Floyd, 1984; Vonk, 1990)), gives

helpful insights. Most prototyping approaches draw

the attention to the end user as the key actor in the

adoption process. The development of a prototype is

also often used to evaluate new CAD tools and to try

to integrate them in an existing workﬂow. This be-

comes especially important, if new design processes

are used.

Maintenance. The IEEE deﬁnes software mainte-

nance as “the modiﬁcation of a software product after

delivery to correct faults, to improve performance or

other attributes, or to adapt the product to a changed

environment.” (IEEE, 1993). It can either be per-

fective (increasing performance, maintainability, efﬁ-

ciency), adaptive (changing software to match differ-

ent requirements or processing environments) or cor-

rective (identifying and correcting failures in perfor-

mance and/or implementation) (Lientz and Swanson,

1980). In hardware development, while the compo-

nent is in use - we ideally assume that no re-design

was necessary - the requirements may change. Nowa-

days hardware is in use only for about two to three

years on average. But often slight modiﬁcations are

ICSOFT 2007 - International Conference on Software and Data Technologies

412

sufﬁcient to extend the product to satisfy the new de-

mands. Here it is very important to have already

considered reuse aspects in the design phase (see

e.g. (Keating and Bricaud, 1999)).

Re-use. If we take reuse into account, many com-

ponents are in use for 10 years (or even longer). For

this, the interface design and conforming with stan-

dards is becoming a key issue. This should already be

considered during the planning phase (see above).

The decisions in the early project phases inﬂuence

many individual steps that become very important in

the later stages. If they are not taken into account at

the beginning, it can become difﬁcult - or even im-

practical - to run a successful overall project.

3.3 Hardware Project Management

The complete design process - from the initial plan-

ning phase until the ﬁnal delivery of the product - can

be regarded as a project. The general tasks of project

management are shown in Figure 3.

From the description above, it easily follows that

the project organization and management has cru-

cial impact on the overall success of the hardware

design. Relating this to the previous section, there

are different roles within project teams: management

(planning and checking, but not production), devel-

opment (planning (in the sense of working within the

deﬁned goals, meeting the deadline, staying within

the planned resources) and production, but not check-

ing

), and monitoring and controlling (checking and

production, but not planning). These roles have to

be clearly assigned to each team member prior to the

project start. Otherwise, the competence and - in case

of problems - the responsibility are not clear. There

are many different ways of organization that can be

applied in a hardware design process. Even though of-

ten forgotten during the planning phase, each project

is only as good as the weakest team member.

• Forms of organization: Starting from small

groups which are exclusively working for one

project (task force), in larger teams some people

might be involved in different projects that are

headed by different project managers. Conﬂicts

may results from the unclear responsibility.

• Motivation of team: The topic is not directly

related to hardware design, but practice shows

that many project managers - even though having

very high technical skills - are not very compe-

tent when leading a group. Psychological and so-

cial components play a very important role. To

Of course, the checking of the modules can be done

by the designer himself/herself, but he/she should not be

involved in the controlling of the overall project.

keep the group members motivated the planning

has to be realistic, competences must be clear,

each individual most know about its importance

and must participate in the success of the project.

The project manager has to identify conﬂicts and

has to solve them within the team without having

“winners” and “losers” in the end.

• Workﬂow management: The classical software de-

velopment models for the organization, like step-

wise, sequential, or cyclic, can also be applied in

the hardware domain. Techniques that have been

developed along new methods for object orienta-

tion, like tool-smithing, can be applied when us-

ing HDLs having the same features.

• Documentation: Even though not very popular,

the documentation of the individual steps in a

project is very

important. Looking at principles

like design reuse the availability of a complete de-

scription becomes crucial. Often, components are

still in use for years even after the designer left

the company. Having a standard for documenta-

tion in this case helps signiﬁcantly to guarantee a

high quality of the modules.

The organization form determines the long term

success of a hardware development group. Looking at

the availability of hardware designers on the market,

each company has to ensure good working conditions

to keep the teams motivated. To guarantee a success-

ful development it is important to introduce the differ-

ent aspects of the project to all members of the team.

For this, ﬁrst a list of different project aspects is given

(the list is not complete, but covers the most relevant

topics) including some questions that should be an-

swered prior to the project start:

• Strategic goals: In-house or outsourcing? Type of

project? (consulting/coaching, turn-key develop-

ment, joint venture)

• Product / goals deﬁnition: What exactly do we

build?

• Timeline / Duration: When will the project start?

How long will it take, and who will be involved in

the different phases?

• Resources: Which and how many sub-tasks are

deﬁned? What is the number of people involved

in each phase? How much do we get/invest for the

project?

• Complexity / difﬁculty: How many tasks are de-

ﬁned and how are their mutual dependencies? Is

the technology needed known or is research re-

quired? What is the risk in the calculations on

investment?

HARDWARE PROJECT MANAGEMENT - What we Can Learn from the Software Development Process for Hardware

Design?

413

Figure 3: Project Management Tasks.

• Priority: How does the success of the project

inﬂuence other projects or sub-tasks? Has the

project a strategic position?

• Costs: Can the costs and the risk of the project

be estimated? Can further studies or information

give a better picture?

• Coordination/Organization: Who is responsible

for the deﬁned sub-tasks and who manages the

complete project?

• Risk analysis: Which potential items might en-

danger a successful project outcome? How can

the tasks be prioritized and how to establish alter-

natives?

Some of the aspects mentioned seem to be obvi-

ous, but in practice it happens too often that some

(or even most) of the questions cannot be clearly an-

swered. It is also easy to see that not all points can

be optimized at the same time. E.g. the costs be-

come lower, when the project takes less time, but this

usually has a negative inﬂuence on the quality of the

product. Especially, the missing clear deﬁnition of

the responsibility with respect to project coordination

and organization in the early phase often results in se-

rious problems later. A comprehensive understand-

ing of the technical, organizational and social aspects

of any project help to make it successful. Following

the developments in software engineering, the cost-

effectiveness of large-scale projects will become more

and more important. In software engineering, using

source lines of code (SLOC) was one of the earli-

est, straightforward methods to estimate the effort of

a software project. As timeliness was one key argu-

ment against the use of SLOC, because this number

can only be calculated after a project has been ﬁn-

ished, there are further problems with SLOC. There

is no relation to complexity of functions or numer-

ical equations. A term that occupies three lines in

the code, but took 4 weeks to be developed by ex-

perts counts as much as a three line code for an in-

put/output device. As an organizational obstacle, the

number that refers to the estimation is hard to under-

stand for non-experts, i.e. top-level management. In

more advanced cost estimation models, most of the

attributes are also weighted according to their prior-

ities. This leads to a complex estimation which out-

performs SLOC methods. Function points (FP), ﬁrst

introduced in (Albrecht and Gaffney, 1983), has been

developed historically for business applications. FPs

are a weighted sum of the number of inputs, outputs,

user inquiries, ﬁles, and interfaces to a system. How

to transfer these cost estimation models to hardware

projects is still an open research question.

3.4 Quality Management

As for software, it is a difﬁcult task to measure the

quality of a description in a HDL. The coding guide-

lines used in companies are not sufﬁcient. Follow-

ing the criteria well accepted in the software domain,

some measures for hardware are outlined. We now

distinguish between the goals that should be achieved

and the methods and standards used:

Goals. It is obvious that the quality should be as

high as possible, but it is also critical to consider the

available resources. The following criteria have to be

considered: correctness, reliability, user friendliness,

reuseability, efﬁciency, and portability. Quality goals

ICSOFT 2007 - International Conference on Software and Data Technologies

414

have to be deﬁned and methods have to be developed

that ensure that these goals are met. It is not sufﬁcient

to just deﬁne a process and hope that the quality will

be satisfying. Even though, some of the criteria above

might be contradicting, a careful analysis what is ex-

pected and what can and should be created leads to a

robust development ﬂow.

Methods. To guarantee a high quality some mea-

sures or standards have to be deﬁned. The currently

most popular ones in the software domain are the Ca-

pability Maturity Model (CMM) and ISO9000. In his

CMM, (Humphrey, 1995) distinguishes between ﬁve

stages of organizational development: 1. Initial (ad

hoc, reactive), 2. Repeatable (intuitive, depending

on isolated staff, using former experience), 3. De-

ﬁned (qualitative, deﬁned process, controlling along

the entire software process), 4. Managed (quantita-

tive, development and use of metrics, data collection

and analysis), 5. Optimizing (improving and adjust-

ing the entire process). He also points out the steps

that have to be made in order to improve the develop-

ment process, which include understanding the cur-

rent status of their development process and develop-

ing a vision of the desired process. This is the source

of a potential conﬂict: the persons that measure are

also the ones being measured. If the assessment re-

veals, that the stage the development processes are in

is not the one expected to be but rather below that, the

management is responsible. Accordingly, this implies

the danger, that evaluations might be forged, so that

the management appears in a better light. One way

to avoid this conﬂict is to make use of outside con-

sultant, whose perspective on that is neutral and not

disturbed by such inﬂuences. A big disadvantage of

such a procedure is, that is is costly and takes a lot

of time, as outsiders have to become familiar with the

present circumstances. Therefore, it might be helpful

to ask a person within the company who is not directly

involved in the development processes that are to be

discussed. Again, this contains potential for a con-

ﬂict, as the unit concerned might not see the necessity

why somebody should get an insight is not really in-

volved. It is human pride and maybe stubbornness

that account for that. Finally, this remains a difﬁcult

and incalculable problem as it is often the case when

human factors are involved.

Standards. Also in the hardware domain, us-

ing standards has been observed as being very im-

portant and resulted in HDLs, like VHDL or Verilog,

for the synthesis step. In other domain, like ”veri-

ﬁcation languages” standards are not established yet

(see e.g. (Goering, 2001))

. But the certiﬁcation of a

Even though recently SUGAR has been selected as a

property language standard there are still more than 10 other

development process is not used. Many of the rules

developed for ISO900X on quality management and

quality assurance can be directly transferred to hard-

ware, while some aspects need to be modiﬁed.

To provide a high quality in the development pro-

cess, clear goals have to be deﬁned and methods have

to be developed that ensure the realization of these

goals.

4 PROBLEMS IN HARDWARE

DESIGN

Beside the “optimal project ﬂow” described so far,

several problems can occur that should be consid-

ered when starting a hardware development project,

although not unique for hardware projects.

• Uniqueness of hardware systems: Most hardware

systems are only developed once and later on

modiﬁed to meet new requirements. This often

makes the requirement analysis and risk manage-

ment (costs, ﬁnancing etc.) difﬁcult.

• Technically oriented management: Many (maybe

most) of the project managers have a technical

background and have been designers before. They

are very qualiﬁed regarding the hardware itself,

but do not necessarily have good management

skills in leading a group. Often they start to de-

sign on their own or try to inﬂuence the designers

in their group. This might leads to problems re-

garding the role of each team member. (On the

other hand “pure managers” without sufﬁcient in-

sight in the technology have problems of getting

accepted by the design teams!)

• Weak planning: In practice the time invested in

the early project phase for specifying the details

of the behavior of the hardware to build is not suf-

ﬁcient. An unclear speciﬁcation is one of the main

reasons for delayed or even failing projects.

• High number of possible solutions: Usually, there

is not one unique way of realizing a circuit. The

main bounds are given by the constraints of the

resources of the hardware and are very difﬁcult to

restrict regarding nowadays hardware complexity.

• Individuality of designers: Many designers see

themselves more as artists than as hardware de-

signers. They are individualists and are often not

willing to work in a team. This is especially some-

thing they do not learn during their education at

the universities. Even though this is changing

languages around.

HARDWARE PROJECT MANAGEMENT - What we Can Learn from the Software Development Process for Hardware

Design?

415

more and more, as group oriented working be-

comes a topic.

• Rapid technological changes: The technology

evolves very fast, and often the tools and tech-

niques have to be modiﬁed during the develop-

ment cycle. This makes an exact planning re-

garding the resources nearly impossible. The

project managers must have ﬂexibility to incorpo-

rate these and must also have the leader quality

to communicate these “negative messages” to the

project team.

• Missing standards: Even though there are many

standardization committees in the hardware do-

main, there are still many problems related to in-

compatibility of data formats or language deﬁni-

tions.

• Status monitoring: Many systems cannot be tested

under “real” conditions until the ﬁnal design is

done. Thus, during the project it is often difﬁ-

cult to say what the current status of the project is.

A project might seem in time, since most of the

code is written, while a lot of effort is needed for

debugging, if the quality is poor.

5 CONCLUSIONS

Over the last 25 years the number of components of

an integrated circuit has grown from a few thousand

to more than 20 million in nowadays ASICs. While

in the beginning of this process one or two design-

ers were doing the complete development, today in

a project group more than 30 designers are working

in parallel. This demands for a closer integration of

project engineering and hardware design. Problems

that might occur during a chip design have been dis-

cussed in this paper. Hardware designers can make

use of many concepts that have been developed over

the last couple of years in the software domain. This

transfer is justiﬁed by the similarities between hard-

ware and software development. Only by applying

structured methods of project management high qual-

ity designs can be obtained and successful tape-outs

of multi-million gate ASICs can be expected.

REFERENCES

A. J. Albrecht, J.E. Gaffney, Software Function, Source

Lines of Code and Development Effort Prediction: A

Software Science Validation, IEEE Transactions on

Software Engineering, (9)6, pp.639-648, 1983

B. Bentley, Validating the Intel Pentium 4 Microprocessor,

Design Automation Conference, pp. 244-248, 2001

B. W. Boehm, A spiral model of software development and

enhancement, IEEE Computer, 21(5), pp. 61-72, 1988

Y. Chu, An Algol-like Computer Design Language, Comm.

ACM, p. 607-615, October 1965.

G. DeMicheli, Synthesis and Optimization of Digital Cir-

cuits, McGraw-Hill, 1994

T. DeMarco, Controlling Software Projects: Management,

Measurement and Estimation, Prentice-Hall, 1982

C. Floyd, A Systematic Look at Prototyping, in R. Budde,

K. Kuhlenkamp, L. Mathiassen, H. Z

ullinghoven (ed-

itors), Approaches to Prototyping, pp. 1-9, Springer,

1984

R. Goering, Assertion’s Babel Tower? EE Times,

August, 2001, available online under url:

http:www.eedesign.com/story/OEG20010828S0054

W. Humphrey, A Discipline for Software Engineering.

Reading, Addison-Wesley, 1995.

G. Hachtel, F. Somenzi, Logic Synthesis and Veriﬁcation

Algorithms, Kluwer Academic Publisher, 1996

IEEE Standard 1219: Standard for Software Maintenance.

Los Alamitos CA., USA. IEEE Computer Society

Press, 1993.

N. Krishnamurthy, M. Abadir, A. Martin, J. Abraham, De-

sign and Development Paradigm for Industrial Formal

Veriﬁcation CAD Tools, IEEE Design & Test of Com-

puters, pp. 26-35, July-August 2001

M. Keating, P. Bricaud, Reuse Methodology Manual,

Kluwer Academic Publisher, 1999

C.F. Kemerer, Software Project Management, Readings and

Cases, McGraw-Hill, 1997

B.P. Lientz, E. Swanson, Software Maintenance Manage-

ment: A Study of the Maintenance of Computer Ap-

plication Software in 487 Data Processing Organiza-

tions, Addison-Wesley, 1980

P. Naur, B. Randell (editors), Software Engineering: A Re-

port on a Conference sponsored by the NATO Science

Committee, NATO, 1969

Sommerville, I., Software Engineering (7th Edition). Pear-

son Addison Wesley, 2004

R. Vonk, Prototyping - The effective use of CASE Technol-

ogy, Prentice Hall, 1990

ICSOFT 2007 - International Conference on Software and Data Technologies

416