Крючков Фундаменталс оф Нуцлеар Материалс Пхысицал Протецтион 2011

seals. All this is virtual, i.e. the connection to real seals is the responsibility of the operator.

∙Generation of reports. In general terms, the system enables new reports to be easily added and you will do it as part of your lab practice. The base reports are reports for the following groups:

containers (transactions with containers and the content of containers); content of physical locations;

MBAs (transactions in the MBA selected and the MBA content); transactions (output of transactions as arranged by dates and users). Besides, the system supports generation of special reports for the

Federal NM Accounting System. As no form for such reports has been specified by the system establishment time, the system contains an arbitrary report.

There should be also an understanding that “report” , as seen by the E/Z MAS developers, is an ordered table, formed according to specific rules, that has been chosen from the database with the aid of an SQL query. Russian requirements to A&C systems demand that an electronic system should be backed up by collection and keeping of hard information copies. This does not imply anything that cannot be done, still one should understand that, in addition to the electronic version, a potential Russian user of the E/Z MAS is expected to make so that to be able to get printouts of reports in any form. It can be easily done in the MS Access environment.

∙Configuration of data. As mentioned hereinabove, the system includes rarely updatable tables (locations, MBAs, enterprises, users). These tables can be updated only for special authorized users with the administrator status.

∙DB interoperation with peripherals. The most recent E/Z MAS version offers a capability to database information directly from peripherals. Functions of communication with two types of devices (barcode equipment and scales) have been built in. The communication is via a com–port from a dedicatedly equipped workstation. Programmatically, Active–X that communicates with this port is used in the asp-file. This function entails a problem still requiring solution. When peripherals are off the computer, there are no these functions in the system interfaces. When a workstation gets connected to peripherals, the functions are on in all interfaces because of having been uploaded from one file on the Web–se rver. It is not a big problem and one solution to this is to switch on this function for users with special logins who have measurement and inspection authorizations.

361

∙ System access security also has a key role in operations. Each user has his/her name linked to a set of functions he/she is authorized to perform. The E/Z MAS supports three user types:

users with the right of viewing only authorized information; users with the right of modifying authorized information;

database administrators – users with the right of a uthorizing the rights of other users.

Examples of E/Z MAS interfaces

To conclude with, we shall consider examples of the system’s interfaces, that is, how the above-described functionality is realized in asppages. Here are some of the typical examples to illustrate how a script technique and a system form design can be used.

Fig. 7.13 shows the E/Z MAS home page opening in the browser as the system is logged in. The user is offered to enter the login and the password. There is a version of the E/Z MAS A&C system that requires two independent user identifiers to be entered. This version is realized for enterprises where the so-called two-person rule is practiced (two persons only may have access to an activity with NM or information thereon).

Fig. 7.13. The E/Z MAS initial page

362

The system has one uncertified component, the MS Access DBMS, which limits, mostly, its applicability. To be recertified, the system is being given a profound upgrade based on open-code base software.

To finalize this chapter on computerized NM A&C systems, we shall discuss how such systems are developed and commissioned and the whole process is regulated.

7.5. Development of computerized NM A&C systems

A study of computerized NM A&C systems has one important point to consider. This is about how a software product is being built throughout the series of phases, from the inception to the commercial implementation. In this respect, it is not only the system creation procedures that matter but also the documentation that becomes required.

Russian standards are fairly regulatory in this regard. The USA, with a much greater experience in establishing large software projects than Russia, has however in effect diverse procedures and techniques to plan, design, test and commission software. Software development concepts and methods demand a separate consideration, so these will be overviewed in brief further in this Chapter with some guidance provided.

Industry standard’s requirements to development, commissioning and operation procedures

The respective industry standard [1] identifies a number of phases involved in creation of A&C systems. The initial one is the predesign stage opened with a site survey. This needs a feasibility study and an analytical (data security) justification to be prepared for the A&C system development. A design specification is developed with well-defined information protection requirements included.

Next comes the design. The final step in this is the detail design, including organizational and technological concepts, software development, and data protection provisions and practices. All concepts accepted are to satisfy to the regulations and requirements of standards and the design specification requirements.

The hardware and software designed need to go through a series of tests. Hardware:

∙tests for functionality in the installing site’s environment;

∙tests for conformity to data security requirements.

364

The base and applied software undergoes a laboratory test series. Data security features shall be certified for conformity to respective data security regulations.

The system is commissioned at the subsequent phase. To commission an A&C system, it is required to:

∙develop the listing of operating documentation;

∙submit a general description of the system, including performance, application and required hardware data;

∙develop a package of regulatory working documentation;

∙submit a description of a package of organizational and technical measures, the institutional structure and the manning schedule of the enterprise to the extent concerned with the A&C system;

∙develop a systems programmer guide to include information on the system installation, setup, testing and crash recovery (reference to GOST State Standards follows);

∙develop a user guide with the information to support the user and A&C system software/hardware dialog;

∙submit the software acceptance certificate;

∙submit the A&C system commissioning schedule.

The commissioning shall involve the A&C system software certification for the conformity to information security requirements.

There can be pilot and commercial operation. Pilot operation of the system requires its prior certification by a special commission. The commission formed to bring the system into pilot operation shall be composed of the developer, customer and operator representatives. Where the A&C system is connected to the central information system, the commission shall also include a representative of the inspecting agency. A technical acceptance certificate shall be made out.

No further steps are regulated by the standard. Other standards exist on automated systems and information technologies. This is where maintenance, support and decommissioning issues are regulated. There is also an abundance of engineering documentation that accompanies the project.

Software lifecycle

The US standard introduces the concept of software lifecycle. This represents all processes relating to a particular software product, from conceptualization to decommissioning and substitution for a newer product.

365

No software lifecycle stages are expressly identified, still the most important steps are as follows:

∙concept;

∙review of requirements to software;

∙development;

∙implementation;

∙tests;

∙deployment and testing;

∙operation and servicing.

Depending on the purpose and scope, the effort and cost relation for various steps may vary between projects. Planning/design (covers the three initial steps) and testing/deployment are the two most costly stages.

One should also remember something some US developers call a 1:10:100 rule, which is understood like this. The cost involved in correcting an error (inaccuracy) at the planning/design stage is assumed to be 1. The error correction cost at the programming stage will then be equal to 10. The error correction during the final test stage will ultimately require a 100 times greater effort to spend. This estimate gives an idea about how important predesign is.

The USA has up to 175 thousand program projects undertaken yearly in various fields, the total spending for these reaching 250 billion dollars. Only 16% of these are implemented on time and at the cost planned. 31% of the projects simply fail and are not brought to fruition. This has given US developers rather a broad experience, both positive and negative, and has led to the underlying requirements having been shaped on all system development stages that are decisive to the success of the project.

Planning of accounting and control systems

The system planning opens with a requirements review. This review has the purpose of formulating, analyzing and documenting functional, information, operating, interface, characteristic and design constraints for the software product. This is the stage for the designer to detail WHAT the system must do and, by no means, HOW this must be done. This is also the reason for software developers not to be preferably involved in this project stage. Anyone with an experience in building systems inevitably thinks about how to realize requirements, and so, when doing this, may turn to ready-made solutions to satisfy the customer requirements.

The following is involved in the requirements review:

∙determination of the initial project scope;

366

∙analysis of the task membership region;

∙determination of the region’s key functions;

∙determination of alternative project decision patterns;

∙selection of the unique decision;

∙generation of the output document (Software Requirements Specification or SRS);

∙determination of the deployment program.

A work unit is formed to implement these stages. This unit is expected to include the following roles:

∙a business leader. This is an expert in the subject matter (business) for which the project is established. He/she is in charge of business decisions;

∙a coordinator – chairs meetings (a project manageme nt and performance expert). The physical project leader;

∙an administrator – a representative of the develope r in charge of the overall guidance, budget and project implementation;

∙a sponsor – the person responsible for funding;

∙a technical leader – a representative of the develo per in charge of technical guidance;

∙a user representative – acts on behalf of end users ;

∙a program project unit – a work unit.

Work starts. So now we shall talk in brief about the project planning and design key stages.

Determination of the initial project scope. This stage requires the developer to expressly:

∙define what shall be or shall not be included in the project, i.e. identify a subtask in the overall task region that can be solved for the money and time allocated;

∙conceive the problem in general;

∙select the requirements review procedures and tools;

∙secure the customer’s and the sponsor’s documented approval for the project scope.

A project unit is formed at this stage to prepare activities and equipment and to outline the general concept.

Workshops and interviews are used to acquire data at the planning stage. The most important thing to focus on is to have all information recorded and do not permit leaders to suppress the opinions of other people involved. Often it is required to keep division or enterprise leaders away from these workshops. The discussion should be as free as it can be. The main thing at this stage is to have immediate users involved. As the experience of

367

successful US projects shows, the user involvement is decisive to the success of any project.

The next stage deals with design as such. This will analyze the functions and processes the designs will involve.

Functions are what is performed or is to be supported by the system. Process is a specific realization of a function – a process starts, continues and ends. Specified processes and functional requirements are documented and presented graphically. Development needs to include decomposition of functions. This means that global functions, say, a material movement function, are considered first. Then the function is subdivided into lowerlevel functions: movement of material inside MBA, offsite receipt of material or shipment of material. All this continues until one obtains elementary functions or functions one cannot subdivide into further lowerlevel functions.

Dependencies are established between functions. The following dependencies are identified:

∙direct dependency – a process starts after another process ends;

∙mutually exclusive dependency – conditions are used ;

∙recursive dependency – the process is rerun;

∙parallel dependency – the result leads to more than one process run.

Objects of activities and attributes thereof should be further identified. Object is a person, a place, a thing, an event or an idea, information on which needs to be obtained for the activity to be performed successfully. Objects have attributes; which are properties of an information object. Later into the database design stage, objects will be realized in tables, while attributes will become table fields (columns). This is a very important stage that requires immediate user involvement. If an object fails to be specified at this stage or no attributes thereof are identified but come out as late as at the programming or deployment stage, the whole of the database structure will need a change.

After objects are specified, relations between them are established. This process is close to the process of linking database tables.

Technical requirements are established at the next stage. This stage requires the following technical constraints to be established and documented for the future system:

∙capacity;

∙design;

∙information security;

∙accessibility;

368

∙interface;

∙DBMS in use.

Requirements need to have a particular measurable form. Let us take an example. The time of access to a table is 2 s. The number of users, clients and transactions is per day. The requirements of standards and reports should be taken into account. We were considering examples of such requirements when reviewing specific software products and the CoreMAS and E/Z MAS A&C systems.

Following the above procedures, the developers need to screen the potential decisions for the unique or the best decision. One screening technique is expert appraisal. An expert unit evaluates different key requirements giving them rankings and evaluating alternatives in these rankings. The parameters are tabulated. The ranking is multiplied by the appraisal value and summed up. The result specifies the options preferred. Then potential risks of the project failure are evaluated.

We proceed finally to the closing design planning stage when the software requirements specification (SRS) is prepared. This stage will result in a document that describes the key software requirements. Further on, this will be what will guide the design of essential software components. The extent to which the SRS is formal depends on the design dimensions and relevance. The specification shall contain:

∙functional requirements;

∙data requirements;

∙technical requirements;

∙decisions;

∙problems;

∙recommended decisions.

Software design

After the SRS is prepared, the developer starts software design. The deliverable at this stage is the database created, including fully structured tables with links and facilities to support information integrity (triggers, limits, saved procedures) and the Software Design Description (SDD), a detailed document about the data structure and functions. Following this preliminary review, the next postdesign step (coding proper) turns into merely a technical operation.

Let us now look at the software design process and some of the techniques this involves. The deliverables for the design stage are:

369

∙the architecture design which mutually relates the system’s major structural components;

∙the procedural design which supports the conversion of major structural components to a procedural software description leading to a program source code generation;

∙the data system design which converts the information model to the data structure (database and program data).

The first of these three stages is, normally, development of data. The most important thing in the development of data is selection of logic object representations identified when the SRS was being written. The following data development strategy has been proposed:

∙systems analysis, which is used to analyze functions and processes, is applicable to data as well;

∙all data structures and operations on these should be identified;

∙a data glossary should be generated and used during the program creation;

∙consistent detailing of data – low-level data is le ft for the next design stage,

∙data structures should be known only to the models that use them directly;

∙libraries of data structures and associated functions should be created;

∙the programming language should support abstract data types.

The program architecture development is aimed primarily at getting a developed modular structure and showing the relations among different modules. The program architecture development combines program structure development with development of data via the interface among the modules.

Procedures are developed after the program structure (architecture) and the data structure are established. The development of procedures involves largely two techniques: use of flow charts and a reference programming language (pseudocode).

Software testing

After the software is designed, the coding stage begins. It makes no difficulty with all the work done before. The coding stage accounts for just a small portion of all efforts spent. As evidenced by the US experience, the cost of code writing is negligibly low as compared to the program design and functional check costs. After codes are written, we set on a new step, which is a software test stage.

370