Prior Art Discussion One of the problems in such development is that of accurately and comprehensively tracking progress to completing functionality required in the end product. For example, silicon engineers may believe that certain functionality is being developed by software engineers, and vice versa. Resources must be allocated in some projects on the basis that some functionality is provided by silicon only, some by software only, and some by both.

The paper"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management"by Hamer Van Denp et al in Proceedings of the IEEE, IEEE. New York, US vol. 84 no. 1,1996, pages 42-56 discusses design decomposition with view, hierarchy, and status dimensions.

While such decomposition strategies assist with tracking design progress the problems of software and hardware design breakdown and management remain.

Thus, the invention is directed towards providing an improved development method to address these problems.

SUMMARY OF THE INVENTION

According to the invention, there is provided a method of controlling development of a system comprising software and hardware, the method comprising the steps of identifying activities to be performed and monitoring progress of completion of the activities, characterised in that, functional blocks of the system to be developed and interfaces between the blocks are identified; each functional block and each interface is correlated with a system required feature of operation; and each such correlation is treated as a work package or activity to be monitored whereby traceability at the level of functional blocks and interfaces is obtained.

In one embodiment, the step of monitoring progress comprises tracking a series of discrete stages for each activity in a traceability table.

In another embodiment, a value is captured for the extent of work completed for each stage.

In a further embodiment, the discrete stages comprise design, implementation, test, and integration.

In one embodiment, each activity is named with a name derived from a name of both the associated functional block or interface and the associated feature.

In another embodiment, an interface is defined for a set of signals between external entities and software modules, between software modules, between silicon modules

and software modules, between silicon modules, and between silicon modules and external entities.

In one embodiment, an interface is defined in terms of the signals.

In another embodiment, correlation of the functional blocks and interfaces with the features is performed in a matrix, in which matrix cells define the activities.

According to another aspect, the invention provides a development control system comprising a data processor comprising means for performing a method as described above.

DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:- Fig. 1 is a block diagram illustrating functional blocks for a communication system to be developed, and Fig. 2 is a traceability plot for the process.

Description of the Embodiments In a development process of the invention a project definition is initially drawn up to define the requirements for the end-product system. There is then functional decomposition, in which the functional blocks are identified. Each functional block

is a module which can be handled by an engineer or group of engineers, and which has clearly defined interfaces in the end product system. Thus, it is modular both in terms of allocating resources for project management and in terms of the end-product functionality.

Referring to Fig. 1, a set of functional blocks for handling communication signals is illustrated. In this case there is clear delimiting of software blocks 1 and silicon (hardware) blocks 2. Each block is accorded a unique name as follows.

Software: MDRS-Message Decoder MERS-Encoder LLSS-Link Layer Slave LLMS-Link Layer Master ALH S-Alarm Handler STAS-Statistics Accumulator Silicon (hardware): RXBH-Receive Buffer TXB H-Transmit buffer ALHH-Alarm Handler STAH-Statistic Accumulator DERH-Decoder/Encoder

In addition, the interfaces between the blocks are also identified and given names as follows: UPL_I-Upper Layer Interface USRI-User Interface DLLI-Decoder-Link Layer ELLI-Encoder-Link Layer Interface Interface LLR_I-Link Layer-RX Buffer LLT_I-Link Layer-TX Buffer Interface Interface ALHI-Alarm Handler Interface STAI-Statistics Accumulator Interface RXD I-RX Buffer-De/Encoder TXD I-TX Buffer-De/Encoder Interface Interface ALDI-Alarm-De/EncoderSTDI-Stats Buffer-De/Encoder Interface Interface

LOLI-Lower Layer Interface The interfaces are defined as a set of signals between: external entities and software modules, software modules, software modules and silicon modules, silicon modules, and silicon modules and external entities They are then defined in terms of each signal as follows:- Type of signal (function call, serial communication, messaging, read/write register for example) Direction (from module A to module B, from module B to module A, bi-directional for example) Size of signal (call with 3 parameters, 10KHz line, 10 byte message, 1-bit register for example) The process also involves identifying features, which are requirements for operation of the end product system. Again, the features must be clearly understandable and modular in nature. The following is a set of features for a communication system: Messaging according to specification Link control Tightly coupled Automatic link restore PSOS operating system Alarm handling Error correction Smart link and connection teardown 64Khz transmission speed 10K * 8-bit Statistics store 256-bit receive buffer Statistic buffer full indication lkbit transmit buffer Transmit Statistics 10 call per second set up ability Receive Statistics

Features are extracted from the project proposal which is agreed by the customer.

They are a concise high level list of the specific project requirements. Features describe the project in terms of someone looking at it from the outside with no knowledge of the internal architecture or structure (black box). The customer may be external (customer driven) or internal (sales/marketing driven).

The next step is to create a matrix of functional blocks and interfaces versus features.

In this matrix the features that are present within each functional block (or the functional block across which a feature exists) are defined, thus giving a list of work packages (activities).

Each work package name includes the functional block or interface, whether the package is in software, hardware or an interface and a feature identifier.

The work package names are subsequently used for traceability and as a basis for generation of all subsequent development process documents (for example, high level design, low level design, unit test, integration test, system test etc.) ensuring traceability of documentation.

The table below shows the statistics functions and features from the example project.

The complete table is 24 columns wide (13 interfaces and 11 functional blocks) by 14 rows (14 features). Block/Interface Features USR I STA S STA I STA H STD I DER H 10K * 8-bit Statistics store X X X Statistic buffer full indicate X X Transmit Statistics X X X X X X Receive Statistics X X X X X X

Each filled-in cell of the matrix is a work package, and for the statistic features the following work packages are generated. <BR> <BR> <BR> <BR> <BR> <BR> <P> STASSTR STAISTR STAHSTR<BR> <BR> <BR> <BR> <BR> USRIFUL STASFUL<BR> <BR> <BR> <BR> <BR> <BR> USRITXS STASTXS STAITXS STAHTXSSTDITXS DERHTXS<BR> <BR> <BR> <BR> <BR> <BR> USRIRXS STASRXS STAIRXS STAHRXSSTDIRXS DERHRXS Thus, each work package is named with the names of the cross-referenced and functional block or interface and features.

This procedure is applied for each feature and a complete list of work packages for the project is generated.

It is now possible to say, with a high degree of confidence, that once all of these packages are designed, implemented, integrated and tested that the project is complete and none of the elements of a feature or features of a functional block have been missed. Work packages now form the basis on which complete projects can be tracked. There are two tools used for tracking projects, namely traceability tables and schedules.

Traceability table The work package names are entered in a spreadsheet table and this table is made available via an intranet. The developer of each particular package enters on a regular basis a percentage figure estimation of the completeness of that package.

Technical managers then track the progress of these tasks. An example table is set out below, in which cells are populated with the percentage completeness of the relevant work package for the phase of the column. Work Package HL Design LL Design Implement Unit Test Integrate STA_S_STR 100 100 60 - - STA_I_STR 100 100 100 - STA_H_STR 100 60 - - - USR_I_FUL 100 100 45 - - STA_S_FUL 100 100 100 100 - USR I TXS 100 100 100-- STA-S_TXS 90 - - - - STA_I_TXS 100 100 100 - STA_H_TXS 100 80 - - - STD_I_TXS 100 100 85 - - DER_H_TXS 100 85 - - - USR I RXS 100 80--- STA_S_RXS 100 100 100 75 - STA I RXS 100 100--- STA_H_RXS 100 100 33 - - STD I RXS 100 20-- DER_H_RXS 100 100 70 - -

The traceability table is hosted on an internal Web site at which engineers can make regular updates. The project manager can use the table for the most up-to-date tracking information and can quickly take note of deviations from the schedule.

A project management system imports the traceability table data as raw data for generation and tracking of a project status schedule such as shown in Fig. 2.

It will be appreciated that the invention therefore provides for clear and comprehensive control of progress of a system development project. It allows full integration of control of both software and silicon aspects without risk of confusion and resulting overlap or omission. Another advantage is that the method does not require sophisticated and expensive processing tools.

The invention is not limited to the embodiments described but may be varied in construction and detail.