Last update PvD
|This document describes all kinds of aspects of a project to develop and deliver a fictitious system (hardware & software) to a customer.
The objective of this document is to identify the necessary tasks for this project, so the responsibility for the work can be assigned to some organisation/department, and the necessary work can be estimated/budgetted.
The completed list –with an organisation filled-in for each of the aspects– should serve as an agreement for the scope of work and for the distribution of responsibilities. It will also serve as a checklist to ensure that no major aspect is overlooked, and as a starting point to determine financial and manpower budgets (e.g. by adding an extra column to the tables below).
Types of development
for turn-key delivery (over-the-shelve delivery has less steps – e.g. the developing organisation is not involved in Installation).
Because of the different types of developement and delivery, some aspects might not be relevant for your current specific case. Also, for other domains of development you may have to modify and/or extend the list.
Application of this list
Short description of your project (narrative, objectives, …), or reference to such a description. To avoid future discussions, define what is in the scope and what not.
Create a separate section regarding References to all relevant documents, e.g. requirements, and a section regarding Specific Issues (bottlenecks, risks).
Definition of –the functionality of– the overall system. This is either done
Describe the goal of the system and its discriminating features, and provide a context diagram (scope & interfaces). Define the main components i.e. a System Architecture (preliminary System design).
Make a basic business case for the system. What is the market potential, how is the system changing operational practices, what are critical cost- and gain areas.
|Analyse the proposed system|
What are critical components regarding the required performance and the system's business case.
Analyse the trends in technology, economy and market: understand how the proposed system (& business case) affects and interacts with existing businesses, operational practices, market position, etc. It should also indicate in what area the system should be flexible.
Specification of what the system is to achieve.
For a Generic system, initially not all requirements will be 'hard'; many points are desirable or optional, open for discussion with the customer(s), or potential demands for a later releases (i.e. a 'roadmap'). During the Initial Phase the Requirement Specification (for the first release) should become concrete and fixed. See Architecture - Specifics for Requirement Specifications.
Consultancy may occur during the whole project, but the emphasis is likely to be in the initial phase (e.g. analysis, estimating, contract negotiations). It involves most departments (Sales, System Engineering, Logistics, Legal) and probably all parties (units, subcontractors, vendors). The completion of this Project Aspects List is part of that. It serves to describe the right conditions for the project.
Analysis of all requirements (System Requirements Specifications, formal and informal specs, functional, performance) for the system to be developed. Special attention to complex areas and risks.
|Statement of Compliance (SoC)|
A Statement of Compliance is a point-to-point answer on the Requirement Specification.
Specific studies to investigate specific problems, to consider the feasibility of solutions (prototyping), to estimate and optimise cost (i.e. sizing, configuration planning, alternate solutions).
Negotiations on the consequences of contract terms, including assistance by technical and operational departments.
Assistance to Marketing/Sales takes a continuous effort, with a peak during System Design (Bid Support).
|Factory Acceptance Test (FAT)|
This is an audit of development, manufacturing and (in particular) test procedures at the developer (the 'factory'). It is a quality assurance test to show to the customer that the development organisation is capable of developing the product. The customer may ask to demonstrate specific (test) procedures.
The Factory Acceptance Test Report is made by the customer, and usually shared with the development organisation.
See Testing for more on this subject.
Design & documentation of the whole system, definition of subsystems/components with their functionality, separation of functionality between components (in hardware and in software, including their interfaces). The other activities are related as they may impact the requirements for components. Scoping of all the work.
The purpose of the System Design is to obtain a work break-down (list of all components), and a basic development plan, so it is possible to estimate the costs (& risks) and time to build the total product (within ≈10% margin). To reach this purpose one does not need a fully completed design (that is only required after the go-ahead for product development), but one has to assure that all technical issues can be adequately solved, and the design must be sufficiently detailed to make reliable estimates.
Description/documentation of the solution in terms of components with their respective functionality and interfaces (external & internal). For performance critical systems, the component specifications should include expected performance indications.
How are all development tests (Integration & Qualification) and operational tests (Acceptance & Maintenance) envisioned. What test tools will be required.
This document should be superseded by the Test Plan.
|Customer/Market Adaptation Strategy (Customer Design Engineering)|
How is customer/market adaptation envisioned, what facilities must be available (how to create extensions & variants, e.g. Sw packaging).
|Site Engineering Strategy (Customer Application Engineering)|
How is site engineering envisioned, what facilities (dimensioning rules, tools) must be available to determine the required components (Hw & Sw, data) to configure/deliver a system instance for a specific site.
This document should be superseded by the Site Engineering Manual.
At the end-of-life of the system, it should be taken down and scrapped (environmental & commercial aspects). These should be considered during design, and responsibility assigned to an organisation.
Above table is for the development of a Generic System; when for Customer Adaptation Engineering the following applies:
All activities required to buy major (sub-)systems from some supplier (this is not considering the basic components for manufacturing like nuts & bolts, resistors, etc; those are assumed to be qualified).
Evaluation & Selection of candidate subsystems & components.
Testing whether a proposed component performs as required. When this component (and its vendor) are accepted, it includes the definition of the Confidence Test procedure/manual to be carried out on this component by manufacturing/assembly for Regular Delivery.
Check whether the vendor is capable of delivering sufficient quantities at sufficient quality of that subsystem.
When particular products/aspects are subcontracted to other company units or external organisations, contracts are required ensuring sustaining support by those organisations for those products/aspects.
|Know-how Transfer / Training|
The effort required to transfer system- and product area knowledge and documentation from the supplier (in particular for maintenance and diagnostics).
When the project will be carried-out (after the contract/'go-ahead'), co-ordination and support of all required development activities will be required (potentially at distributed sites). The main issue for Project Management is the scope of the project. Regular (follow-on) deliveries are commonly not part of Project Management (but of Logistics; see overthere), but the initial delivery usually is.
|Project Management Plan|
How the development and introduction of the system is going to be managed (procedures, rules, methods). What status reports need to be made at which interval, etc. See Project Management.
Covers the management of subcontractors (for development).
|Documentation Management Plan|
Definition of what type of documents must be created for each type of component, and how to manage all documents (i.e. documentation rules, archiving). See Documentation.
|Quality Management Plan|
A document assuring sufficient quality of the product to be developed (i.e. including project procedures). See Quality Management Plan.
Scope of all engineering work (work break-down: list of all components and work involved, e.g. documentation), and the development schedule.
How can one discern versions of components and their corresponding documentation, how will versions of system components and their mutual dependancies be handeled. For management of delivered configurations see Regular Delivery - Site Engineering.
Definition how to handle Change Requests, Change Proposals and Change Notes regarding the funtionality of the system. It includes Problem Management until the Acceptance Test has passed successfully. See Change Procedure.
When a conflict arises between parties (not only for customer/developer, but any customer/supplier relationship like developer/component supplier) which can evidently not be solved in normal meetings, there should be a planned strategy to resolve such a conflict. It involves the next higher level of management at both parties, and ultimately both CEO's. It may involve Change Management.
Development of all the software.
|Top Level Design (Sw)|
Potentially some additional design for the overall software architecture.
Software Design Specification [DS]
Test Plan [QP]
|Detailed Design (Sw)|
Design (/adaptations) of each Sw component.
Detailed Design Specification [DS]
|Coding & Module Test|
Module Test Specification [QT]
Module Test Report [QZ]
|Software Integration & Test (optional)|
Integrate software in artificial environment (hosted, simulated hardware)
Software Integration Test Specification [QT] (potentially part of the overall Integraton Test Specification).
|Sw Development Environment|
For proper software development equipment, tools and procedures (software engineering rules, Configuration Management).
|Development Engineers Training|
Software engineers have to be trained on the Development Environment (tools) and in the problem area with its specific constraints.
Development of all the hardware.
|Top Level Design (Hw)|
Potentially some additional design for the overall hardware architecture.
|Detailed Design (Hw)|
Design (/adaptations) of each hardware components, design of circuits & boards and corresponding documentation.
Layout, prototyping, testing and documentation of hardware components (i.e. for the manufacturing of PBA's).
Integrating and testing all the hardware (as much as feasible without software integration).
|Hw Development Environment|
For proper hardware development equipment and tools are to be acquired. It includes hardware engineering rules.
Selection of board sizes, shelve & rack types, connectors, configuration rules,etc.
Production of prototype hardware
The Integration Test is in fact 2 activities in 1 step: putting components together (integration), and test their interworking. Subsystems are already tested individually during subsystem development. And it is not only testing the interworking between components (modules), but also diagnosing the cause when it fails.
This is the strategy for step-wise integrating and testing components. It reflects the availability of components in time (i.e. the Schedule in the Development Plan). Initial version to be created during Project Management.
|Integration Test Specification [QT]|
A document decribing the individual tests to be executed during integration.
Execution of the integration test.
|Integration Test Report [QZ]|
The report on the results of the Integration Test (what test have beeen executed, and with what results).
This in-depth test verifies whether the developed system conforms to its Requirement Specification (potentially including specifics required by authorities); passing this test concludes the development of the system, and the system is now suitable for general delivery.
See Testing for more on this subject.
|Qualification Test Specification|
Description of all tests to be executed. Derived from the Requirements Specification.
Execution of the Qualification Test Specification.
|Qualification Test Report [QZ]|
Report on all qualification tests
This is an in-depth System Acceptance test by the customer to verify whether the system conforms to the customer's requirements (i.e. system qualification by the customer). Commonly the test is held in the customer's lab with live interfaces, and supported by the development organisation (corrective engineering possible).
This is not an Alpha test, nor is it the Delivery Acceptance Test done at Regular Delivery; for that see Installation.
|Customer Location Test||Org.|
|Customer Location Test Support|
Development support to the overall test by the customer to check whether the product conforms to the customer's requirement.
A limited number of systems applied as an operational pilot to experience the 'real world' and to smooth out operational procedures. Most documents and procedures for Regular Delivery are completed here. In some environments this corresponds to a Beta test.
Delivery, Installation & Test at the customer premises (however, procedures and documents are not yet complete). See Regular Delivery – Installation.
|System Introduction / Migration|
Assistance to various local departments and to the client to introduce the system. It includes other start-up effort such as interfacing with existing systems and migration from old systems.
Training the customer on how to use the system (various audiences, e.g. operators, users), and how to set-up system environment.
|Installation & Test Manuals|
Creation of Installation Manual & Installation Test Manual
Creation of System descriptions, Manuals, Guides, Tutorials and Training manuals for the customer on how to plan, install, maintain, operate and use the system.
How to keep track of delivered systems and their configuration (later by Site Engineering).
Various documents & procedures required for Regular Delivery (normal Roll-out) will be made during Initial Application.
Logistics takes care of all material and resource planning for regular delivery of a product.
Accept, verify and confirm incoming orders.
Plan manufacturing/acquisition of material involved; plan Site Engineering & Installation effort and resources.
Management of all subcontractors used in regular delivery (equipment & services).
Arrange transport for delivery.
|Invoice & tracking|
Send out bill and see that you get your money.
Site Engineering (Customer Application Engineering, CAE) is all engineering required for a delivery of an existing -rather complex- system.
|Acquire Site Dependant Data|
Get all relevant data concerning a particular location. This may involve site visits and meetings with the customer and/or documents (forms) per site from the customer.
Determine material (subsystems, hardware and software), configuration and effort (planning, installation, test) involved for this delivery.
|Software Generation / Data Production|
Assemble all software parts (possibly conditional build) and/or generate data for this particular delivery. This may involve database population.
|Site Specific Customer Documentation|
Floorplan, equipment distribution, cabling, power supply, cooling, software configuration, numbering/addressing, routing tables, etc.
|Installed Base Management|
Keep track of composition of delivered systems quantities and versions of items (deliveries and repairs).
|Site Engineering Environment|
For proper Site Engineering probably tools are required (as this is a repeating job, efficiency and quality are issues).
|Site Engineering Manual|
This manual should be created by the development department, but is possibly adapted to suit the client (CDE) and general operating procedures.
|Site Engineers Training|
Engineers have to be trained for good quality Site Engineering results.
Mass production of individual components & subsystems, including production tests.
|Validate Buy-in Components|
Confidence testing of bought components.
Assembly & confidence testing of components/subsystems to obtain the ordered system in shippable blocks.
All activities to get a system in the field in working order. The tests involved should only provide confidence that equipment is correctly manufactured, delivered & installed, not whether the system fulfills some Requirement Specification (it is no System Acceptance Test).
|Hardware Installation & Test|
|Software Installation & Test|
Migration of data/applications/users from the old system to the newly delivered system.
|Commisioning or Delivery Acceptance Test|
Formal test that should verify whether this particular configuration is operating correctly. For Commissioning the equipment is also put into active use for the customer (otherwise the customer is assumed to put the system into operation).
Now the system is assumed to be delivered and should be billed.
Training of engineers for Installation & Test (Hw & Sw, Commissioning).
All activities to support the product in the field.
|First Level Maintenance|
Simple preventive and corrective maintenance (exchanging dust filters, fans, faulty boards, etc). Quite often performed by the customer.
|Second Level Maintenance|
More sophisticated maintenance for more complex and obscure problems or major renovations. Also fall-back for level-1 maintenance. Performed by dedicated team (potentially by customer).
|Last Resort / Third Level Maintenance|
When first and second level maintenance can not solve a problem (in particular when these are performed by the customer), a fall-back on the expertise of the development engineers should be available.
When normal error correction procedures do not satisfy the customer, an escalation procedure should be activated (involving management). This may also involve other organisations/units through the Back-to-back agreements (i.e. with development organisations).
|Service Management, Complaint tracking|
Registration of calls to invoke corrective maintenance/complaints and completion of maintenance/complaint.
Facility for clients to call for telephonic support to (software) problems.
Keep spare stock, administer use, and replenish.
Repair faulty equipment from the field.
Replace out-dated (bugged) components in the field (and stock) by their up-to-date replacements.
Training of maintenance engineers; that is the own people and potentially the clients maintenance crews (ongoing business).
Training of the customer’s operators, provision of manuals.
Training of the customer’s users, provision of manuals.