PROJECT & TEST ENGINEERING SYSTEM (PTESY) 
What it is

PTESY is a complete system for the Project and Test Engineering, fully conceived and designed by Andromeda. It allows to manage all the meaningful aspects of project life cycle, by means of tools based on relational database. 

Such tools allow - among other functionalities - to automatically produce and re-produce (each time is needed) the documents in the most used electronic format (MS Word). PTESY produces the following MSWord documents: I/O List and Terminal List, Test Procedure Documents, Fathers-Children Requirements Traceability Matrixes, Test Cases vs. Requirements Traceability Matrixes. Several tools allow to check the design completeness as well.

The real innovation of the described methodology is that it is a technology-based one: the paper documentation is not neglected, but definitely out of the project loop, therefore it doesn't burden anymore the scheduling of the activities. The Project Management methodology is compliant to quality standard, but no more based on paper.

PTESY is based on electronic support and commercial platforms, usable on whatever PC or NoteBook. It was born and evolved on the job, pressed by the contractual milestones; it was conceived with the scope to conciliate apparently incompatible needs. It represents, therefore, a conspicuous qualitative step, in the management of all the project phases.

What do we intend with "meaningful elements of the Cycle of Life of the System?" At least the following macro-elements: Customer Functional Requirements, Software (or Technologic) Requirements,Test procedures, Problems found during the test phases, at the different integration levels, Problems found by the Customer during the life of the system. 

Each-one of the listed information categories have the proper electronic notebook:

• ReqBook for the Requirements 

• TestBook for the Test Procedures 

• LogBook for the Problems 

• DocBook for the technical management of the Project Documents

• IO_Manager for the Input/Output signals of the system, the generation and handling of I/O Tables

• SysBook for the Operators Accounts, Access Privileges, Data Safety management and Changes Tracing.

AUTOMATED DOCUMENTATION FUNCTIONS

PTESY automatically produces the following documents:

REQUIREMENTS
	Automated creation of the following MSWord, fully formatted, Traceability Matrixes documents:
		links between Children Requirements and Fathers Requirements, ordered by Children
		links between Fathers Requirements and Children Requirements, ordered by Fathers
	Selections of Orphans Requirements and Without Children Requirements
	Automated creation of the following MSWord, fully formatted, documents:
		Events and Notes Report, based on a user selection (in compact and extended shape)
		Requirements Document, based on a user selection
TEST CASES
	Automated creation of the MSWord, fully formatted, Traceability Matrixes documents:
		links between Test Cases and covered Requirements, ordered by Test Cases
		links between covered Requirements and Test Cases, ordered by Requirements
		list of the Requirements not covered by any Test Case
	automated creation of the MSWord, fully formatted complete Test Procedures documents.
I/O SIGNALS
	Automated creation of the MSWord, fully formatted, Signals Lists documents:
		I/O List, ordered by tags, Local Control Unit, Peripheral I/O Unit
		Terminal List, ordered by Terminal Strip Pin, Local Control Unit, Peripheral I/O Unit, Terminal Strip
PROBLEMS
	Automated creation of the following MSWord, fully formatted, documents:
		Events and Notes Report, based on a user selection (in compact and extended shape)
		Problems Document, based on a user selection (in compact and extended shape)
DOCUMENTS
	Automated creation of the following MSWord, fully formatted, documents:
		Documentation Tree
		Table of the Applicable Documents
		Table of the Referred Documents
Warning: in order to use the automated documentation functions, the user must have MSWord 2000 installed on the workstation.

ELECTRONIC VS. PAPER METHODOLOGIES: MANAGEMENT KEYS

ELECTRONIC VS. PAPER METHODOLOGIES: TECHNICAL KEYS

Functions and benefits of PTESY 

PTESY allows the user to save enormous amounts of time, namely in the following areas:

SYSTEM DESIGN

• Requirements discussing, issueing, tracing and reviewing 

• Being fully open to the Microsoft world, PTESY is fully exportable/importable from to the most known Office tools (MSWord, MSExcel, MSAccess)

• When used to deal the project of a monitoring /supervisory system, PTESY can be used as a documentation data source, integreted with the SCADA development system, allowing the automated generation of the real time objects from a unic source.

• Test Procedures and Test Cases definition. 

• IO definition and harmonization.

• Understanding the real work in progress of the design: detect possible overdesign, detect what is still to be done in the objects decomposition. 

TEST ENGINEERING

• Tracing Test Cases vs. Requirements.

• Problems recording, tracing and analyzing during the different test phasis.

PROJECT MANAGEMENT

• Valuation Meetings of ongoing test campaigns and related Minutes of Meeting composition.

• Tracing Problems vs. Requirements, discussion about Error Corrections vs. Change Proposals.

• Efficient management of the whole project documentation.

• Easier cost calculation during offer and proposal activities. 

• Many times increased efficiency of the quality methodology management: the quality becomes a tool for a more efficient development.

• Project development cost reduction. 

OPERATION

• Maintenance and Problems Solving of licensed systems, during the normal operative life of them. 

• Being fully open to the Microsoft world, PTESY is fully exportable/importable from to the most known Office tools (MSWord, MSExcel, MSAccess).

During the whole project life: 

>>>>>> AUTOMATED PRODUCTION OF THE MAIN STANDARD DOCUMENTS <<<<<<

Who gets profit by using PTESY (the plus of PTESY)

PTESY was fully designed and developed in Italy, in the "fire" of complex ESA projects, where the respect of the schedule and the respect of the quality methodologies had the same relevance: PTESY showed that it is possible to manage both the needs in an harmonic, and nomore conflictual, way. 

Possible configurations and supply conditions

Both the single modules and the integrated system can be installed on a single machine (Stand Alone configuration), or in Client Server architecture (Client Server configuration), on a Local Area Network.

Using a VPN tunnel, on an ADSL internet connection, PTESY can be shared among remotely connected users.

In Single Application / Stand Alone configuration each module can be easily installed by the User in few minutes.

The Integrated and/or Client Server configurations require the intervention of skilled personnel, in order to install and configure the system. Such intervention, together with the minimum needed training of the user personnel, does not require usually more than one or two days, according to the dimension of the network on which the system shall be installed.

Customer-Suppliers configurations: using a VPN connection, it is possible – e.g. for a system integrator – to place Client PTESY applications at the supplier’s home, in order to share, and develop in an integrated way, the relevant project & test information, the i/o signals archive, the project documents, etc…

WHAT IS REQBOOK

• by the final user during the  conceptual system design phase;

• by the designers and the systemists during the development and the system integration phases; 

• by the test engineers during the commissioning and acceptance test phases;

• by the final user and by the designers during the phases of engineering change and extension of the system functions. 

Some topic ReqBook's functions are briefly described below.

ReqBook is equipped by a powerful comments section, that allows the user to easily deal with the requirements discussion phase, among all the involved people.

ReqBook can import requirements generated by means of other tools or word processors. For this purpose it only requires the insertion of few key-words, to allow the import parser to correctly isolate each requirement during the import operation.

ReqBook automatically produces the MSWord, fully formatted, Traceability Matrix documents: of the Children Requirements vs. Fathers Requirements, ordered by Children; of Fathers Requirements vs. Children Requirements, ordered by Fathers. 

ReqBook also produces selections of Orphans Requirements and Without Children Requirements.

ReqBook can be used integrated with LogBook. Such use allows to quickly retrieve the requirements violated by the detected problems, avoiding thus time-eating searches on the paper documents. In many cases also are very simplified correction vs. change discussions. 

ReqBook can be installed in integrated configuration with LogBook, TestBook, DocBook, IO_Manager, to share the common archives and to directly select references to Test Cases, Problems, Documentation.

WHAT IS TESTBOOK

• by the final user during the of conceptual system design phase;

• by the test engineers during the commissioning and acceptance test phases; 

• by the final user and by the maintenance technicians during the normal operative life of the system, when it is necessary to re-execute some tests, in order to get the functional state of the system.

TestBook allows to develop the following layers of the Test Procedures:

1. the Test Procedure, including general informations about the test procedure and the list of the contained Test Sessions; 
2. the Test Session, including informations about the test environment, the hardware and software tools to be used, the peculiar configuration of the class of tests included by the session, the list of the included Test Cases; 
3. the Test Case, including the list of the verification steps (Test Steps) foreseen for each single test, with the vbasic fields of action, expected result, actual result and other, related to the detail of the single verification steps; 
4. the Test Step, including other detail informations of each verifcation step. 

TestBook automatically produces the complete Test Procedure documents, in MS Word format (with all the proper font, formatting, tables, etc...), extracting the proper information from the database, each time the test engineer needs to re-issue the document.

TestBook also automatically produces, in MS Word, fully formatted, the Traceability Matrixes documents, of Test Cases vs. covered Requirements, ordered by Test Cases, of covered Requirements vs. Test Cases, ordered by Requirements, of the Requirements not covered by any Test Case.

TestBook can be installed in integrated configuration with LogBook, ReqBook, DocBook, IO_Manager, to share the common archives and to directly select references to Requirements, Problems, Documentation.

WHAT IS LOGBOOK

• the different test phases during the system development, commissioning, acceptance test, 

• the life of the system after the commissioning. 

LogBook is therefore a multiuser tool, since it is used by the Test Engineers during the test phasis, and by the Final Customer during the operative life of the system.

LogBook can run on the same workstation used for making the test, allowing to record the problems directly when they are detected, with the following benefits:

1. Each problem is described according to a methodology, teherefore no key aspect can be forgotten. 

2. Each problem is described once. 
3. Each recorded problem can be retrieved very easily and quickly, by means of powerful search keys. 
4. During the meetings, held to valuate the test campaign and to decide the next actions to be done, all the problems are already written, ready to be printed and annexed to the Minutes of Meeting.

The Problems selection/search function allows the user to compose complex queries, using all the key-fields. The selection queries can be saved for future use.

The problem record includes all the analytical information usufel to manage the problem itself and its solution. The user can make his/her templates to guide the problem description as well as the solutions. It is possible to insert up to 3 pictures (any MS OLE object), and to refer to max. 3 electronic documents (which are copied into a PTESY directory).

A powerful Notes and Events section allows the User to keep a diary of the project activities.
LogBook can be integrated with:

• ReqBook, to quickly find out the requirements violated by the problem and to insert the references to such requirements. 

• TestBook, to quickly find out to insert the references to the tests that allowed to detect the problem.
• DocBook, to quickly refer to project documents.
• IO_Manager, to easily and quickly insert references to Input/Output signals

thus allowing a great reduction of the times to search references on paper documents.

See also the section "Why to log problems".

WHAT IS I/O MANAGER

IO_Manager is used, in different phases:

• by the designers and the systemists during the development and the system integration phases; 
• by the test engineers during the commissioning and acceptance test phases; 

• by the final user and by the maintenance technicians during the normal operative life, to keep trace of the history of the different digital signals and analogue magnitudes dealed by the system. 

IO_Manager includes the following sections:

• I/O Dictionary, to record, document in detailed way and quickly-easily select/retrieve all the signals of a project, a system, a subsystem, a subassembly, a package. 

• I/O List / Terminal List Creation - I/O Manager automatically produces the following MSWord fully formatted documents:

  • I/O List, ordered by tags, Local Control Unit, Peripheral I/O Unit
  • Terminal List, ordered by terminal strip pin, Local Control Unit, Peripheral I/O Unit, Terminal Strip 

• I/O Export, with selectable column-fields. 

• Gloxary, of the terms, abbreviations and acronyms used in the project documentation. 

IO_manager can be installed in integrated configuration with LogBook, ReqBook, TestBook, to share the common archives and to directly select references to Test Cases, Problems, Requirements.

WHAT IS DOCBOOK

DocBook is used, during the whole project - and after the end of the project - to archive the following information related to project documents:

• title, code (generated by an automated standard procedure), date, author, release, issueing company, and all the anagraphic information; 

• the electronic address, with possibility to open it directly from database; 

• the index, imported directly from the document, with possibility to navigate among the index levels.

DocBook includes the following sections:

• Project Documents, to record, document in detailed way and quickly-easily select/retrieve all the documents of a project, by several search keys: system, subsystem, subassembly, package, author, etc... 

• Project Management, to maintain the different project information cathegories. 

• Utilities, including a Gloxary, of the tems, abbreviations and acronyms used in the project documentation.

DocBook can be installed in integrated configuration with LogBook, ReqBook, TestBook, IO_ Manager, to share the common archives and to directly select references to Test Cases, Problems, Requirements.

WHAT IS SYSBOOK

SysBook is used, in different phases:

• by the PTESY system administrator; 
• by the Project Managers;
• by the Technical Project Coordinators; 

SysBook includes the following sections:

• Operators Account, to define and maintain the accounts of the different operators (Administrator, Auditors, Supervisors, Designers). 

• Personnel Management, to maintain the anagraphic archive of the company personnel. 

• Changes Tracing, to see and maintain all the tracing data (old versions and deleted items).

• Data Safety, including functions to setup automated periodic data backup operations.

SysBook is installed in integrated configuration with LogBook, ReqBook, TestBook, IO_ Manager, DocBook, to share the common archives. 

Why to log problems

 There are several cultural and/or behavioural items against the practice of a scrupolous problems tracing, namely:

Item

Description

Comment

Superstition

If we don't think about problems, they will disappear, or, better, never occur.

No need for comments.

Time wasting

The designers are "sure" that they are perfectly able to manage the problems, and they have no time to write everything.

If the designer is young, it is possible that his/her memory will help him not to forget the problems.

But the young age brings also some minus: low methodologic experience, high possibility to solve similar problems in not standard ways, etc...

Lack of tools

In the moment the problem is detected, I have no paper, no pencil, no time to log the problem.

LogBook solves this problem: it is an electronic notebook, that can be used on the same machine where we are running the test.

Psichology

When I find a problem, I don't like to give emphasis to it (I was so sure to have no errors in my system!)

Understandable feeling, in young designers, but they should learn to change.

Psichology

If I can solve the problem at once, why to mention it again later?

Because whatever Quality Methodology (ISO 9000, ESA PSS05,  etc...) you are using, it requires you two things:

1. never modify the source code while doing the test

2. trace all modifications

Therefore the problem cannot be solved at once, and shall be traced anyway.

Minimizing

If I cannot solve the problem at once, it will take me five minutes later, no need to mention it.

That's not true: you will find many other problems, and all together will take considerable time to be solved.

Minimizing

I will write everything, later in the afternoon, at the end of the tests.

Are you quite sure that you will remember everything, later in the afternoon, about the tents of problems you will detect today?

The best moment to log a problem is when you detect it, you analyze it, you have it "fresh" in your mind.

Later you could be forced to spend mother time, in order to make the analysis again (most likely, you will write less than what you had written now).

Professionality

A good designer should make very few errors.

Completely false:

• the professionality of a designer is measured on his/her capacity to deliver systems as more as possible errors free;

• in order the final product is errors free all the errors must be detected and eliminated;

• the test phasis are properly targeted to detect the errors and allow their removal.

Lack of testing culture

Each time I find an error in my system I enter a depression state.

Completely reverse:

• each time that I detect a problem in my system, I am very happy, because it will not be detected by my Customer, and it will not cause damages.

Finally, we can say the following:

• The Test Phasis would be a complete waste of time if the detected problems were not properly logged, and made available to the designer entitled to remove the problems from the system. 

• Once we recognize that the problems must be logged, the best way to do it is to follow a predefined format, in order to be sure not to forget any key item. 

• Since we are in the Electronic Age, why to use paper? Save a tree, using Electronics! We get a lot of benefits if we decide to use Electronics. First of all we write each information one only time (during tests), and the informations are then available for all the following activities (valuation meetings, recovering actions, etc...) 

LogBook is designed properly to make easy to log and trace problems during the test phases, but it can be used even later, during the operative life of the systems, to help the solution of all the problems detected during the normal use. 

THE SYSTEM LIFE CYCLE DERIVED FROM ESA STANDARD:

---

Ron Moritz, senior vice president and chief technology officer at Symantec Corp. (stock: SYMC), said part of the problem is "we have forgotten 30 years of data processing." "In the rush to get things ready for the Web, we've forgotten principles that allow software to be of high quality and high reliability", Moritz said.

Ask for more information and/or a demo CD of PTESY