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

There are three processes involved in checking the performance quality of different project stages: tests, debugging and testing. Tests and checks take place at all project stages to identify errors as early into the development process as possible. Defects may occur at any project stages, e.g. some of the required functions may be neglected at the requirements review stage or mutually incompatible requirements may be introduced.

Reviews and inspections are used to localize defects at the development stage. These are performed by teams of experts other than involved directly in the given development work. There is no fixed standard so respective reports may have any form.

Testing and debugging take place during and immediately after the coding stage. Debugging is different from testing in that the programmer who does debugging corrects the error, if any, while testing just records inaccuracies. Testing begins during planning, the earliest design development stage. As the development goes on, the software testing program is generated or updated for each stage. Unit testing takes place at the coding stage. After the product is completed, system testing is performed, this including detection and correction of inaccuracies. Finally, the software system undergoes user acceptance testing when installed for the customer. Final testing is subject to documentation. Practical evidence exists that testing, however careful, can never completely eliminate all the defects within real designs. Testing, on the average, identifies about half of the existing errors. The rest are identified and, where possible, removed as late as at the software maintenance stage. There are special firms in the USA providing services in independent testing of software.

Commissioning of A&C systems

Deployment is a frequently used alternative term for this, as viewed by US experts, important software lifecycle stage. The following principles are identified which make it possible for the process to run smoothly.

Realization of how important the early and careful deployment process planning is. This is of special importance to the client/server environment. Keeping in mind the future deployment when at the design and testing stages will help avoiding a great deal of painful problems when a designed and carefully tested system fails to perform as efficiently as required in a real environment. The cause for this is that the system was debugged on other equipment, on more powerful computers or on a more productive network.

371

∙There should be an understanding that deployment is a scheduled process and must not violate normal cause of business.

∙There should be one person responsible for the deployment.

There is an example to illustrate the complexities involved in deployment of software. It took Mitsubishi, California, two years to deploy a software product instead of one year planned initially. This raised the cost of deploying the Oracle system to nearly 3 times as high as that of the software development effort.

So what are the problems involved in software deployment? The major of these are:

∙Cost of network equipment, DBMS and so on.

∙No computer hardware and software standards on the client’s side.

∙Personnel training in new user interface standards.

∙Incorporation of software that changes standard work procedures.

∙Unfriendly user.

This leads to recommendations on how some of the said concerns to be removed. The simplest and one of the most efficient ways is to have particular users involved in the system creation process since its earliest phases. User training needs to be started well in advance with equipment and software standards to be phased in as the system development process goes on (management of configuration). The user must be a partner.

Deployment stages:

∙Analytical phase. Starts in parallel with the development of requirements and runs continuously until the deployment begins. The following should be defined at this stage:

–the user qualification level and presence of hard ware/software;

–requirements to parameters of existing computers;

–operating environment, access and security contro l requirements;

–the need for conversion of the existing data;

–roles, duties and costs for the maintenance phase ;

–if new hardware and software should be acquired a nd license rights granted.

∙Construction phase. Hardware and software is acquired in this step. Data conversion systems are tested. User, operation and other manuals are compiled.

∙Training is a very important activity given special emphasis in the USA. Timely training is essential. Skills may be lost if acquired too early, while the user may not accept innovations if the training was late. Rather a great spending is required (course preparation, training logistics).

372

∙Deployment phase. All documents are released, training is given, data is converted and the system begins to operate.

∙Closing phase. The powers of servicing the system are delegated.

Servicing, maintenance and decommissioning

Servicing is the personnel activities on ensuring normal operations in the stage of production. Servicing includes support of performance, support of data accessibility, support of information security and fallback recovery.

Servicing of a system requires a particular staff of personnel. These include systems administrators, database administrators, security experts, network administrators and operators.

Maintenance means the developer’s activities on correction of errors, as well as on the system upgrading and evolution after delivery to consumer. This is a very important activity. As analytical survey data shows, software maintenance in the USA accounts for 70% of the corporate spending on software. Only 30% is spent to purchase new software. The following maintenance types are identified:

∙corrective (emergency and routine);

∙adaptive (new hardware and software as conditions change);

∙perfection;

∙preventive.

It should be remembered that an intervention with the software operations bears the risk of an error. This stage normally involves the minimum volume of testing with no minor changes documented. No earlier standards are observed. Hence the best strategy is to minimize maintenance. Maintenance should be largely reduced to emergency maintenance. User demands for the system updates should be accumulated and lead to a new release of the system. Updates should be dealt with as new designs with the maximum volume of testing and documentation for all updates.

Where the system maintenance cost goes in excess of the gain from the system’s operations, the time is ripe for having this decommissioned. Normally, the existing system is replaced by a similar but a more advanced system.

373

References

1.Стандарт отрасли. Оснащение программно– аппаратное систем учета и контроля ядерных материалов. Общие требования. ОСТ 95 10537–97.

2.Веске Дж. Л., Гандерлоу М., Чипмен М. Access и SQL. Руководство разработчика: Пер. с англ. М.: Лори, 1997.

3.Fedorov A., Francis B., Harrison R. et al. Professional Active Server Pages 2.0/ Wrox Press Ltd, 1998.

4.Гостехкомиссия России. Министерство Российской Федерации по атомной энергии. Руководящий документ. Требования по защите от несанкционированного доступа к информации в автоматизированных системах учета и контроля ядерных материалов. М., 1997.

5.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–1–2001. Информационная технология. Методы и средства обеспечения безопасности критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель.

6.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–2–2001. Информационная технология. Часть 2.

7.Государственный стандарт Российской Федерации. ГОСТ Р ИСО/МЭК 15408–2–2001. Информационная технология. Часть 3.

8.Пискарев А.С., Шеин А.В. О состоянии и перспективах использования Общих критериев оценки безопасности информационных технологий в России для оценки применяемых в СУиК программных средств. – Материалы 5 международного рабочего семинара «Разработка Федеральной автоматизированной информационной системы учета и контроля ядерных материалов России», г. Новоуральск, Свердловской обл., 26–30 мая 2003 г.

9.Федосеев В.Н., Мизин П.П., Шанин О.И. Проблемы и перспективы развития СУиК ЯМ в России с точки зрения системного программного обеспечения. – Материалы 7 международного рабочего семинара «Разработка Федеральной автоматизированной информационной системы учета и контроля ядерных материалов России», г. Звенигород, 11–15 сентября 2006 г.

10.Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. М., 1992.

11.Зегжда Д.П., Ивашко А.М. Основы безопасности информационных систем. М.: Горячая линия – Телеком, 2000.

374

12.Руссинович М., Соломон Д. Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мастер класс./ Пер. с англ. – 4– е изд. М.: Издательско– торговый дом «Русская редакция», 2005.

13.Уинкуп С. Microsoft SQL Server 6.5 в подлиннике: Пер. с англ. СПб.: BHV – Санкт– Петербург, 1998.

14.Андреев А.Г. и др. Windows SQL Server 2000. Русская версия / Под общ. ред. А.Н. Чекмарева и Д.Б. Вишнякова. С– Пб.: БХВ, 2003.

15.Шмидт В. Microsoft Visual Basic 5.0 – М.: ABF, 1997.

16.Иванова Е.Б., Вершишнин М.М. Java 2, Enterprise Edition.

Технология проектирования и разработки. С– Пб.:, 2003.

17.Посполит А.В. Visual Studio.NET: разработка приложений баз данных. СПб.: БХВ – Санкт– Петербург, 2003.

18.Коннэлл Дж. Visual Basic 6. Введение в программирование баз данных: Пер. с англ. М.: ДМК, 2000.

19.Сеппа Д. Microsoft ADO.NET: Пер. с англ. М.: Издательско– торговый дом «Русская редакция»; 2003.

20.Ерыгин А.И., Кушнарев М.С. Интеграция систем учета и контроля ядерных материалов. Проблемы и перспективы. – Материалы 7 международного семинара «Разработка Федеральной автоматизированной системы учета и контроля ядерных материалов России». Звенигород, 11–15 сентября 2006 г.

21.Румянцев А.Н. От учета и контроля – к управлению. Компьютерная СУиК ЯМ, радиоактивных веществ и радиационных источников РНЦ «Курчатовский институт» – система КИ– МАКС // Новости Фис. Информационный бюллетень, №5, 2004.

22.Кондаков В.В. Компьютеризированные системы учета и контроля ядерных материалов: Учеб. пособие. М.: МИФИ, 2001.

23.Кондаков В.В., Ожерельев С.А. Опыт эксплуатации и перспективы развития системы учета и контроля ядерных материалов МИФИ – Материалы 7 международного семинара «Разработка Федеральной автоматизированной системы учета и контроля ядерных материалов России». Звенигород, 11–15 сентября 2006 г.

375