Управление конфигурациями сетевого программного обеспечения. Способ установки и конфигурирования программного обеспечения

Последнее обновление: 04.09.2017

Конфигурация по умолчанию

Начиная с версии 2.0, необязательно явным образом подключать конфигурацию в проект. Инфраструктура ASP.NET Core автоматически может это сделать. Единственное ограничение состоит в том, что в качестве файла конфигурации должен выступать файл с именем appsettings.json .

Итак, добавим в проект файл appsettings.json со следующим содержимым:

{ "color": "navy", "text": "Hello ASP.NET Core 2.0!" }

Используем этот файл конфигурации в классе Startup:

Using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Configuration; namespace ConfigurationApp { public class Startup { public Startup(IConfiguration config) { AppConfiguration = config; } public IConfiguration AppConfiguration { get; set; } public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app) { var color = AppConfiguration["color"]; var text = AppConfiguration["text"]; app.Run(async (context) => { await context.Response.WriteAsync($"

{text}

"); }); } } }

Чтобы получить конфигурацию из файла appsettings.json, достаточно передать в конструктор класса объект IConfiguration, который и будет содержать все настройки. И затем полученную конфигурацию можно использовать в приложении.

Dependency Injection

Более того конфигурация, составленная из файла appsettings.json, доступна по всему приложению, и мы можем ее получить через механизм Dependency Injection, например, в конструкторе какого-нибудь класса. Так, можно определить компонент middleware - ConfigMiddleware, который будет использовать конфигурацию:

Using System.Threading.Tasks; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.Configuration; namespace ConfigurationApp { public class ConfigMiddleware { private readonly RequestDelegate _next; public ConfigMiddleware(RequestDelegate next, IConfiguration config) { _next = next; AppConfiguration = config; } public IConfiguration AppConfiguration { get; set; } public async Task Invoke(HttpContext context) { var color = AppConfiguration["color"]; var text = AppConfiguration["text"]; await context.Response.WriteAsync($"

{text}

"); } } }

И затем использовать данный компонент в классе Startup:

Public class Startup { public Startup(IConfiguration configuration) { AppConfiguration = configuration; } public IConfiguration AppConfiguration { get; set; } public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app) { app.UseMiddleware(); } }

Передача конфигурации из разных источников

Однако выше приведенный способ получения конфигурации в middleware и в других классах будет работать, если в приложении определен файл appsettings.json, который и хранит все настройки. Однако если файл называется иначе, или настройки хранятся в файлах xml, ini, каких-то других источниках или просто определяются в памяти, то по умолчанию передача конфигурации в качестве сервиса работать не будет. И в этом случае необходимо явным образом указать, с каким объектом будет сопоставляться сервис IConfiguration.

Например, мы хотим хранить конфигурационные настройки в памяти и передавать их в качестве сервиса в middleware:

Public class Startup { public Startup() { var builder = new ConfigurationBuilder() .AddInMemoryCollection(new Dictionary { {"color", "red"}, {"text", "Hello ASP.NET Core 2.0"} }); AppConfiguration = builder.Build(); } public IConfiguration AppConfiguration { get; set; } public void ConfigureServices(IServiceCollection services) { services.AddTransient(provider => AppConfiguration); } public void Configure(IApplicationBuilder app) { app.UseMiddleware(); } }

В метод AddTransient() через фабрику сервисов передается объект, который будет использоваться в качестве сервиса IConfiguration. При этом код ConfigMiddleware не меняется, он также получает IConfiguration через конструктор.

Профессиональным программистам этот вопрос покажется странным. У начинающих же часто наблюдается явное непонимание важности этой возможности. При этом получается программа, похожая на каменную глыбу с высечеными на ней надписями - если захочется изменить надпись, то придётся делать новый камень.

Есть и другая крайность - когда практически всё выносится в настройки. Такие программы напоминают разлитую жидкость, а чтобы заставить её работать надо прочитать толмуд описания и настроить несколько сотен параметров, к тому же часто взаимосвязанных противоестественным образом.

Как всегда нужно найти золотую середину - с одной стороны надо постараться удовлетворить различные прихоти пользователей, с другой стороны нужно сделать так, чтобы большинству пользователей ничего настраивать не пришлось.

Что именно стоит настраивать.

Вот типичные примеры данных, которые часто стоит вынести в настройки:

Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
Сетевые настройки. Имена серверов, IP-адреса, порты, имена и пароли для автоматического доступа.
Настройки баз данных. Имена JDBC-драйверов, URL базы данных, SQL-запросы, зависимые от используемой БД.
Настройки внешнего вида. Настройки Swing-овского Look & Feel-а, используемые шрифты, размеры, цвета, настройки горячих клавиш.
Прочее... Любые другие вещи, которые могут менятся от пользователя к пользователю.

Например, довольно часто встречаемая ситуация - настройка соединения с БД. Начинающие программисты часто пишут нечто подобное:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:MyDatabase",user,password);

Таким образом программа привязывается к конкретному JDBC драйверу. Использовать другой драйвер, например заменить мост на RMI-прокси или, в случае Oracle, OCI на Thin без перекомпиляции уже нельзя.

В объектном программировании всё представляется в виде объектов. Настройки лучше всего при этом рассматривать как свойства определённых объектов, которые хранятся в файлах конфигураций. То, каким образом эти настройки считываются и записываются тесно взаимосвязано с форматом файлов и выбраной стратегией администрирования. Рассмотрим идеальный вариант:

Настраиваемый объект не должен содержать знаний о формате файлов и способе чтения/записи. Это позволило бы, в случае необходимости, заменить один способ другим.
Большинство настроек должны выполняться при помощи программы (подпункт меню или отдельная программа настройки). Это сильно облегчает жизнь человека, который занимается администрированием. У большинства "юниксоидов" это может вызвать непонимание:-), но редактированием текстовых файлов в современном мире во многих случаях не обойтись.
Должно быть установлено разумное умолчание для отсутствующих параметров. Другими словами - необходимо, чтобы большинству пользователей для запуска программы нужно было бы сделать минимум настроек. Как правило это оставляет благоприятное первое впечатление о программе, а часто именно оно - самое важное.

К сожалению этот идеальный вариант довольно трудно сделать на практике. Первое требование предполагает разработку универсального механизма сохранения объектов. Такие системы уже есть готовые, но часто они не подходят по тем или иным параметрам. Разработать же самому такую систему - далеко не каждому под силу.

Второе требование подразумевает, что для каждого объекта пишется своя панель (или диалог) для редактирования настроек. В случае большого количества объектов стоит попробовать использовать универсальные механизмы. Один из вариантов - использование стандарта JavaBeans. Этот стандарт разрабатывался для визуальных систем программирования, но, из-за сходства решаемых задач, также хорошо подходит для универсального конфигурирования. Но это тоже не самая простая задача, поэтому часто разумно предусмотреть возможность альтернативного варианта конфигурирования для пожарных случаев - например, при помощи обычных текстовых редакторов в случае использования текстовых форматов файлов.

Разумное же умолчание для параметров часто просто невозможно представить. Например, что поставить в качестве имени SMTP-сервера? В случае Unix-систем можно попробовать поставить localhost, но для Windows-мира это редко кому подойдёт.

Рассмотрим наиболее распространённые варианты:

Ini-файлы.

Ini-файлы - это был самый распространённый вариант в эпоху Windows 3.x. Сейчас в виндовых программах он стал вытесняться хранением настроек в реестре. Тем не менее ini - это один из простейших вариантов хранения настроек. К сожалению довольно часто эта простота заставляет прибегать к различно рода ухищрениям. Пример типичного ini-файла:

InputDir=INPUT OutputDir=OUTPUT ArchDir=ARHIV TransferPath = a:\cour NoReceived=No Numb = 3 MenuName1 = ~N~orton ProgName1 = mousesav c:\command.com /c nc MenuName2 = Win - ~Б~локнот ProgName2 = notepad MenuName3 = Импорт из формата АБ "Инкомбанк" ProgName3 = incom.bat

В Java нет стандартного класса для чтения ini-файлов, но это не проблема. Т.к. формат очень прост, его легко сделать самому:

Файлы Properties.

Этот формат распространён в Unix-мире. Он ещё проще ini-файлов, т.к. в нём отсутствует понятие секций - всё состоит из ключей и значений. Пример типичного файла:

# Database configuration Database.Driver=sun.jdbc.odbc.JdbcOdbcDriver Database.DataURL=jdbc:odbc:MyDatabase Database.Prop.user=user Database.Prop.password=password

В Java есть готовый класс для чтения/записи таких файлов (java.util.Properties), но с ним есть некоторые проблемы. Во первых для чтения невозможно задать кодировку файла, а это означает проблемы с русскими буквами. Во вторых стандартная функция записи сохраняет данные в порядке следования хэш-значений ключей, что значит - как ей больше понравится. Но это тоже легко разрешимо - достаточно написать свою читалку/писалку.

XML-файлы.

Этот формат подходит для многих целей, в том числе и для хранения настроек. XML-формат ориентирован на древовидные структуры, что довольно естественым образом отображается на объекты. Пример типичного файла:

user password

Для чтения и записи таких файлов предназначены специальные библиотеки - так называемые XML-парсеры. Таких парсеров уже сделано довольно много, так что писать его самому нет большого смысла - достаточно лишь подобрать подходящий. Для парсеров было разработано два стандартных программных интерфейса - событийный (SAX) и иерархический (DOM). Есть также и парсеры со своим интерфейсом. Размер jar-а с парсером может варьироваться от нескольких килобайт до мегабайта - в зависимости от поддерживаемых интерфейсов и возможностей.

Для XML также написано несколько библиотек для универсального сохранения (сериализации) объектов в файлах XML. Такие библиотеки позволяют отделить алгоритм сохранения от самого объекта, а это, как уже упоминалось, имеет много плюсов.

Сериализация.

Под термином "сериализация" понимают запись содержимого объекта в поток двоичных данных. Обычно имеется в виду универсальный алгоритм, реализуемый классами java.io.ObjectOutputStream и java.io.ObjectInputStream . Пользоваться ими просто настолько, насколько это вообще возможно - обычно достаточно лишь отметить в классе поддержку при помощи интерфейса Serializable и отметить ключевым словом transient те поля объекта, которые сохранять не нужно. Собсно и всё. :-) Пример:

public class SerialObject implements java.io.Serializable { private String name; private transient int state; public SerialObject() {} public SerialObject(String n) { name = n; } public String getName() { return name; } public void setState(int s) { state = s; } }

Запись объектов:

SerialObject o = ...; OutputStream os = ...; ObjectOutputStream oos = new ObjectOutputStream(os); oos.writeObject(o);

Чтение объектов:

InputStream is = ...; ObjectInputStream ois = new ObjectInputStream(is); SerialObject o = (SerialObject)ois.readObject();

Использование сериализации - это один из самых простых вариантов по реализации, но и у него есть свои недостатки. Получаемые файлы являются двоичными, а значит в текстовом редакторе их уже не подправить - придётся делать редактирование параметров из программы. Кроме того, необходимо следить за изменением сохраняемых объектов, дабы не нарушить совместимость при изменении и развитии программы.

Базы данных.

В базах данных можно хранить любые данные, конфигурация программы - не исключение. Это имеет смысл в нескольких случаях:

Настройки связаны весьма сложным образом и древовидные структуры типа XML подходят плохо.
Доступ к настройкам должен быть только у авторизованых пользователей.
Доступ к этим данным должен быть и из других программ, например из генератора отчётов типа Crystal Reports.

БД могут применятся объектные или реляционные. Другие типы сейчас широкого распространения не имеют. Использовать хорошую объектную БД часто так же просто, как и сериализацию. Для реляционых баз можно применить объектную надстройку, которая также позволяет сильно упростить жизнь. Ну а можно делать обычные SELECT-ы.

Скрипты.

Использование скриптов - это один из самых экстремальных способов конфигурирования. Они позволяют добится максимальной гибкости программы за счёт вынесения логики наружу. В использовании скриптов надо тоже знать меру - в конце концов заказчик платит Вам за программу, решающую задачи, а не за ещё один интерпретатор или компилятор за который ему потребуется посадить ещё одного программиста. А то получается, как в том анекдоте - какую программу не начнёшь писать, всё компилятор получается.

Но часто без скриптов действительно тяжело. Типичные примеры - алгоритмы импорта/экспорта, алгоритмы проверок данных. Вы можете подготовить стандартный набор, а дальше настраивать скриптами под конкретные требования заказчика.

Для программ на Java в качестве скрипт-языка хорошо использовать язык Pyton в его Java-инкарнации под названием JPyton. Там легко организовать двусторонюю связь между программой и скриптом. Если не будет хватать скорости интерпретации, то код на Pyton-е можно скомпилировать в байт-код - получится обычный Java-класс. Про JPyton можно почитать на сайте http://www.jpyton.org/ или в новой книжке Брюса Эккеля Thinking In Patterns with Java (доступна на http://www.bruceeckel.com/).

Пример программы с конфигурацией в XML.

В качестве примера можете посмотреть простенькую программы, использующей XML-файл в качестве конфигурационного. Сохраняемые параметры можно редактировать как из программы, так при помощи текстового редактора.

Пример содержимого конфигурационного файла:

Просто строчка Вторая строчка

В качестве XML-парсера используется Sun-овский парсер в режиме DOM. На таком простом примере не видно особых преимуществ формата XML над теми же файлами properties. Они становятся заметны только в достаточно сложных программах, где становится необходимо хранить списки однотипных параметров или же содержимое объектов с уровнем вложенности два или более.

На всех уровнях тестирования применяются методы:

функционального тестирования , обеспечивающие проверку реализации функций, которые определены в требованиях, а также правильность их выполнения;
регрессионного тестирования , ориентированные на повторное выборочное тестирование системы или ее компонентов после внесения в них изменений на тех же тестах, что и до модификации;
тестирования эффективности , проверяющие производительность, пропускную способность, максимальный объем данных и системные ограничения в соответствии со спецификациями требований;
стресс-тестирования , проверяющие поведение системы при максимально допустимой нагрузке или при ее превышении;
альфа и бета тестирования , выполняющие внутреннее тестирование кодов системы и внешнее тестирование интерфейсов. Альфа - это внутреннее тестирование (функций и алгоритмов), а бета - внешнее (взаимосвязей с другими системами и средой)
конфигурационного тестирования , проверяющие структуры и идентификации системы на различных наборах данных, а также работу системы на различных конфигурациях аппаратуры и оборудования.

К методам тестирования относятся также методы проведения испытаний ПО, проверки реализации требований и обеспечения параметров настройки и размещения компонентов ПО на заданном количестве и типах компьютеров, среды и ОС.

Техники тестирования базируются на некоторых теоретических и практических положениях, например, на природе подхода к проектированию (компонентного, объектно-ориентированного, сервисного и т.п.), а также на следующих данных:

информация о структуре ПО или системы в документации ("белый ящик" ) ;
подбор тестовых наборов данных для проверки правильности работы компонентов и системы в целом без знания их структуры ("черный ящик");
анализ граничных значений, таблиц принятия решений, потоков данных, статистики отказов и др.;
блок-схемы построения программ и составления наборов тестов для покрытия системы этими тестами;
обнаруженные и зафиксированные в таблицах системы дефекты, пред- и постусловия выполнения, структурные характеристики системы (количество модулей, объем данных и др.).

Метрики тестирования .Для измерения результатов тестирования ПО, а также при проведении анализа качества используются метрики. Измерение как часть планирования и разработки тестов базируется на размере программ, их структуре и количестве обнаруженных ошибок и дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Процесс тестирования документируется и согласно стандарту IEEE 829-98 включает описание тестовых документов, их связи между собой и с задачами тестирования. Без документации по процессу тестирования невозможно провести сертификацию продукта по модели СММ [1.20 ]. После завершения тестирования рассматриваются вопросы стоимости и оценки рисков, вызванных сбоями или недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или его продолжении.

Управление тестированием :

планирование процесса тестирования (составление планов, тестов, наборов данных) и оценивание показателей качества ПО;
проведение тестирования компонентов повторного использования и паттернов как основных объектов сборки ПО;
генерация необходимых тестовых сценариев, соответствующих среде выполнения ПО;
верификация правильности реализации системы и валидация правильности реализации требований к ПО;
сбор данных об отказах, ошибках и др. непредвиденных ситуациях при выполнении программного продукта;
подготовка отчетов по результатам тестирования и оценка характеристик системы.

Заметим, что стандарт ISO/IEC 12207 и гармонизированный ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование как неотъемлемую часть всего ЖЦ.

1.1.5. Сопровождение ПО (Software maintenance)

Сопровождение ПО - совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или улучшению других характеристик ПО. В связи с решением проблемы 2000 года сопровождение стало рассматриваться как более важный процесс, который должны осуществлять разработчики. Новая версия системы должна решать те же самые задачи, иметь план переноса информации в другие обновленные БД и учета стоимости сопровождения. Сопровождение (в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.

Область знаний "Сопровождение ПО ( Software maintenance )" состоит из следующих разделов:

основные концепции (Basic Concepts),
процесс сопровождения (Process Maintenance),
ключевые вопросы сопровождения ПО (key Issue in Software Maintenance ) ,
техники сопровождения (Techniques for Maintenance)

Сопровождение рассматривается с точки зрения удовлетворения требований к созданному ПО, корректности его выполнения, процессов обучения и оперативного учета процесса сопровождения.

Основные концепции описывают базовые определения и терминологию, подходы к эволюции и сопровождению ПО, а также к оценке стоимости сопровождения и др.

К основным концепциям можно отнести ЖЦ ПО (стандарт ISO/IEC 12207) и составление документации. Главное назначение этой области знаний состоит в выполнении готовой программной системы, фиксации возникающих ошибок при выполнении, исследовании причин ошибок, анализа необходимости модификации системы в целях устранения ошибок, оценки стоимости работ по проведению изменений функций и системы в целом. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и методы ее преодоления.

Процесс сопровождения включает : модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений. Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:

корректировки, т.е. изменения продукта для устранения обнаруженных ошибок или нереализованных задач;
адаптации, т.е. настройки продукта в изменившихся условиях эксплуатации или в новой среде выполнения данного ПО;
улучшения, т.е. эволюционного изменения продукта для повышения производительности или уровня сопровождения;
проверки ПО с целью поиска и исправления ошибок, обнаруженных при эксплуатации системы.

Ключевые вопросы сопровождения ПО .Основными из этих вопросов являются управленческие, измерительные и стоимостные. Сущность управленческих вопросов состоит в контроле ПО в процессе модификации, совершенствовании функций и недопущении снижения производительности системы. Вопросы измерения связаны с оценкой характеристик системы после ее модификации, а также повторного тестирования и оценки показателей качества. Стоимостные вопросы связаны с оценкой затрат на сопровождение ПО в зависимости от его типа, квалификации персонала, платформы и др. Знание этих факторов часто позволяет уменьшить затраты.

Эволюция ПО .Известный специалист в области ПО Дж. Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становится более сложной и плохо управляемой, возникает проблема уменьшения ее сложности. К технологиям эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.

Реинженерия - это усовершенствование устаревшего ПО путем его реорганизации или реструктуризации, а также перепрограммированием отдельных элементов или настройки параметров на другую платформу или среду выполнения с сохранением удобства его сопровождения.

Реверсная инженерия состоит в восстановлении спецификации ( графов вызовов , потоков данных и др.) по полученному коду системы для наблюдения за ней на более высоком уровне. Восстанавливается идентификация программных компонентов и связей между ними для обеспечения перепрограммирования системы к новой форме.

Чаще всего реверсная инженерия применяется после того, как в код ПО было внесено много изменений и оно стало неуправляемым.

Рефакторинг - это реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения. Этот процесс реализуется путем постепенного изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО. Если сохраняется форма существующей системы при изменении, то рефакторинг - один из вариантов реверсной инженерии.

1.1.6. Управление конфигурацией ПО

Управление конфигурацией (Software Configuration Management - SCM ) состоит в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта; составляются отчеты об изменениях, внесенных в конфигурацию, и степени их реализации, а также проводится проверка соответствия внесенных изменений заданным требованиям.

Конфигурация системы - состав функций, программного и технического обеспечения системы, возможные их комбинации в зависимости от наличия оборудования, общесистемных средств, обозначенных в технической документации системы, и требования к продукту.

Конфигурация ПО включает набор функциональных и технических характеристик ПО, заданных в технической документации и реализованных в готовом продукте. Это сочетание разных элементов продукта вместе с заданными процедурами сборки и настройки на среду в соответствии с назначением системы. Примерами элементов конфигурации являются график разработки, проектная документация, исходный и исполняемый код, библиотека компонентов, инструкции по установке и развертыванию системы.

Область знаний "Управление конфигурацией ПО" состоит из следующих разделов:

управление процессом конфигурации (Management of SCM Process),
идентификация конфигурации ПО (Software Configuration Identification ),
контроль конфигурации ПО (Software Configuration Control ),
учет статуса (положение конфигурации в ПО или состояние) конфигурации ПО (Software Configuration Status Accounting ),
аудит конфигурации ПО (Software Configuration Auditing ),
управление версиями ПО и доставкой (Software Release Management and Delivery).

Управление процессом конфигурации .Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетной информацией, касающейся конфигурации. Включает:

систематическое отслеживание вносимых изменений в отдельные составные части конфигурации, выполнение аудита изменений и автоматизированного контроля за внесением изменений в конфигурацию системы или ПО;
поддержку целостности конфигурации, ее аудит и обеспечение внесения изменений в элементы конфигурации;
ревизию конфигурации в целях проверки наличия разработанных программных или аппаратных средств и согласования версии конфигурации с заданными требованиями;
трассировка изменений в конфигурацию на этапах сопровождения и эксплуатации ПО.

Идентификация конфигурации ПО заключается в документировании функциональных и физических характеристик элементов конфигурации ПО, а также в оформлении технической документация на элементы конфигурации ПО.

Контроль конфигурации ПО состоит в проведении работ по координации, утверждению или отбрасыванию реализованных изменений в элементах конфигурации после формальной ее идентификации, а также в анализе входящих компонентов в конфигурацию и соответствия их идентификации.

Учет статуса или состояния конфигурации ПО проводится с помощью комплекса мероприятий, позволяющих определить степень изменения конфигурации, полученной от разработчика, а также правильность внесенных изменений в конфигурацию ПО при ее сопровождении. Информация и количественные показатели накапливаются в соответствующей БД и используются при управлении конфигурацией, составлении отчетности, оценивании качества и выполнении других процессов ЖЦ.

Аудит конфигурации - это деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам. Аудит определяет степень, в которой элемент конфигурации удовлетворяет заданным функциональным и физическим (аппаратным) характеристикам системы. На основе функционального и физического аудита конфигурации фиксируется базовая линия изготовленного продукта.

Управление версиями ПО - это отслеживание имеющейся версии элемента конфигурации; сборка компонентов; создание новых версий системы на основе существующих путем внесения изменений в конфигурацию; согласование версии продукта с требованиями и проведенными изменениями на этапах ЖЦ; обеспечение оперативного доступа к информации об элементах конфигурации и системы, к которым они относятся. Управление выпуском охватывает идентификацию, упаковку и передачу элементов продукта и документации заказчику. При этом используются следующие основные понятия.

Базис (baseline) - формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.

Библиотека ПО - контролируемая коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО.

Сборка ПО - объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.

Изобретение относится к области приборостроения. Его использование для установки и настройки программного обеспечения современных цифровых вычислительных машин позволяет обеспечить возможность объективного контроля над процессом выполнения инсталляции программного продукта в установочных пакетах, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем. Этот технический результат достигается тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования в фазу, которой присваивается один или несколько атрибутов; каждая фаза установочного пакета выбирается, идентифицируется и помечается; при этом, если очередная фаза помечена как обработанная, осуществляется переход к следующей фазе, в противном случае осуществляется вызов очередной фазы в каждом вложенном установочном пакете; при этом, если текущая фаза найдена в одном из установочных пакетов, то в нем последовательно выбираются, анализируются и идентифицируются все фазы, расположенные до найденной, и сама найденная фаза, каждая из которых после обработки помечается как обработанная. 1 з.п. ф-лы.

Данное предложение относится к области приборостроения и может быть использовано в программных системах установки и настройки программного обеспечения современных цифровых вычислительных машин с воздействием на порядок выполняемых операций.

Способы установки и конфигурирования программного обеспечения известны . Эти способы реализованы в современных цифровых вычислительных машинах в виде программ инсталляции, которые выполняют копирование файлов программного обеспечения на компьютер назначения, а также запись параметров конфигурации и другие действия по настройке программного обеспечения. Последовательность технологических операций в известных способах установки и конфигурации программного обеспечения должна строго выполняться в порядке, заданном разработчиком программы инсталляции. Наиболее современной программой инсталляции является Windows Installer - составная часть технологии IntelliMirror, используемая для работы с приложениями Windows 200 . С ее помощью упрощается установка приложений и их обновление, устраняется возможность "конфликта версий", появляются дополнительные возможности по управлению программами, установленными в системе. Программа инсталляции состоит из главного установочного пакета и связанных с ним установочных пакетов. В свою очередь каждый установочный пакет состоит из одной или нескольких операций, объединенных согласно логике функционирования установочного пакета. Установочный пакет может содержать ссылки на другие установочные пакеты. При этом при выполнении установки и конфигурирования программного обеспечения могут быть использованы не все операции каждого установочного пакета, а только их произвольная выборка, определяемая целями и составом программного обеспечения, а также конфигурацией технических средств. Способ установки и конфигурирования программного обеспечения требует выполнения установочных операций в составе этих пакетов в строгой последовательности, заданной разработчиком. С целью оптимизации инсталляционных процессов внутри каждого установочного продукта к каждому параметру установки может быть назначен весовой коэффициент . Каждый весовой коэффициент в комбинации с состоянием параметров инсталляции, информацией о разбиении потенциальных компьютеров назначения используется в процедуре выбора для каждой потенциально возможной компьютерной системы назначения соответствующего пакета установочных пакетов.

Способ установки и конфигурирования программного обеспечения является одним из самых совершенных и наиболее близких к заявляемому способу. Каждый установочный пакет, составляющий программную систему установки и настройки программного обеспечения по способу , разрабатывается независимо от других пакетов и может впоследствии быть использован в других программах инсталляции в комбинации с иными установочными пакетами без каких-либо модификаций. Поэтому, во-первых, в рамках каждого установочного пакета задается абсолютный порядок выполнения всех действий, а выполнение установочных пакетов начинается с главного установочного пакета методом последовательного перебора. Во-вторых, возможно наличие однотипных действий в двух или более установочных пакетах. Следовательно, в процессе установки и настройки программного обеспечения однотипные действия будут выполняться такое число раз, в скольких установочных пакетах они повторяются. Это существенно затрудняет осуществление объективного контроля над последовательностью выполнения действий в установочных пакетах, это снижает надежность, делает невозможным процесс установки сложных программных систем.

Цель данного предложения состоит в обеспечении возможности объективного контроля над процессом выполнения инсталляции программного продукта в установочных пакетах, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем.

Поставленная цель достигается тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования данного установочного пакета в фазу, которой присваивается один или несколько атрибутов. После загрузки главного установочного пакета обрабатываются все его фазы методом последовательного перебора. Каждая обработанная фаза помечается как обработанная. При этом во всех установочных пакетах, связанных с главным, осуществляется поиск фазы с идентификатором, равным идентификатору обрабатываемой фазы главного установочного пакета. Если в одном из установочных пакетов такая фаза обнаружена, то обрабатывается каждая непомеченная фаза, предшествующая обнаруженной в этом установочном пакете. При этом обработка каждой фазы обязательно включает поиск во всех установочных пакетах фазы с идентификатором, идентичным идентификатору обрабатываемой в данный момент фазы. После завершения поиска и возвращения в исходную фазу все обработанные фазы помечаются как обработанные. Аналогичным образом после завершения перебора фаз главного установочного пакета последовательно перебираются непомеченные фазы каждого из остальных установочных пакетов. Благодаря такому способу установки и конфигурирования программного обеспечения обеспечивается возможность по помеченным фазам осуществить объективный контроль над последовательностью выполнения фаз в комплектах установочных пакетов, что повышает надежность инсталляции и обеспечивает безотказность процесса установки сложных программных систем.

Сущность способа установки и конфигурирования программного обеспечения состоит в следующем. Вначале осуществляется выделение и загрузка установочных пакетов, начиная с главного установочного пакета. В каждом из загруженных установочных пакетов согласно логике функционирования установочного пакета выделяется одна или несколько операций, которым присваивается один или несколько атрибутов. Кроме того, в каждом установочном пакете одному или нескольким значениям одного или нескольких параметров установки присваивается вес. Эти параметры установки должны быть связаны с процессом установки и конфигурирования установочного пакета. Затем определяется множество компьютеров назначения, на которых может быть осуществлена установка данного установочного пакета. После чего задается процедура вычисления каждого установочного параметра и осуществляется разбиение множества компьютеров назначения на подмножества. При разбиении используются заданные веса в комбинации с состоянием параметров установки и вычисляется критерий соответствия каждого параметра установки для каждой из потенциальных систем компьютеров назначения с целью их дальнейшего конфигурирования. В процессе загрузки главного установочного пакета методом последовательного перебора обрабатываются все его фазы, начиная с начальной. После окончания обработки каждой фазы, то есть после окончания выполнения логически объединенных одной или нескольких операций, эта фаза помечается как обработанная. Факт обработки данной фазы может быть отображен визуально на мониторе. Одновременно с постановкой метки на обработанной фазе во всех остальных установочных пакетах, связанных с главным, осуществляется поиск фазы с атрибутами, соответствующими атрибутам данной обработанной фазы. Если в одном из установочных пакетов фаза с такими атрибутами обнаружена, то начинают обрабатываться фазы этого установочного пакета, которые, во-первых, не помечены; во-вторых, предшествуют найденной в этом установочном пакете фазе. Обработка фаз этого установочного пакета заканчивается на первоначально обнаруженной фазе с идентичными атрибутами. После возвращения в исходную фазу все обработанные фазы помечаются как обработанные. При этом обработка каждой фазы в каждом установочном пакете обязательно включает поиск фаз с аналогичными атрибутами во всех установочных пакетах. После завершения перебора фаз главного установочного пакета последовательно перебираются непомеченные фазы каждого из остальных установочных пакетов. Благодаря тому, что все обработанные фазы наряду с атрибутами имеют проставленные метки, заявляемый способ установки и конфигурирования программного обеспечения представляет возможность контролировать ход инсталляции программного продукта и наблюдать за его ходом с помощью любого устройства отображения. Группирование серии идентичных, одной или нескольких, операций вокруг фазы с общим для всех них набором атрибутов позволяет повысить надежность инсталляции программного продукта, что способно обеспечить безотказность процесса установки и конфигурирования сложных программных систем.

При формулировании существа изобретения были использованы следующие патентные, научно-технические источники:

1. Андреев А.Г. и др. Microsoft Windows 2000 Server и Professional / Под общим редактированием Чекмарева А.Н. и Вишнякова Д.Б. - СПб: БХВ - Санкт-Петербург, 2000 - 992 с.: стр 145, 373.

2. Integrates with Microsoft. Visual Studio. Net Help. 1992-2003. Microsoft Corporation. 0103 Part № X 09-19409, 19410, 19411.

3. Патент США №2003/0163807, М.Кл. G 06 F 009/445, зарегистрирован 27 февраля 2002 г., опубликован 28 августа 2003 г.

1. Способ установки и конфигурирования программного обеспечения, включающий выделение и загрузку установочных пакетов, начиная с главного, назначение в каждом установочном пакете веса каждому одному или более чем одному выбранному значению одного или нескольких параметров установки, связанных с установкой и конфигурацией установочного пакета программного обеспечения, определение множества компьютеров назначения, на которых может быть осуществлена установка установочного пакета программного обеспечения, определение процедуры вычисления каждого из параметров установки, разбиение множества компьютеров назначения в соответствии с каждым параметром установки с использованием назначенных весов в комбинации с состоянием параметров установки, вычисление соответствия каждого параметра установки для каждой из потенциальных систем компьютеров назначения, отличающийся тем, что одна или несколько операций в каждом установочном пакете объединяются согласно логике функционирования установочного пакета в фазу, которой присваивается один или несколько атрибутов, последовательно выбирается, анализируется, идентифицируется и помечается меткой каждая очередная фаза текущего установочного пакета, при этом, если очередная фаза загруженного установочного пакета помечена как обработанная, осуществляется переход к следующей фазе загруженного установочного пакета, а если очередная фаза загруженного установочного пакета не помечена как обработанная, то осуществляется вызов очередной фазы в каждом вложенном установочном пакете, при этом если очередная фаза не имеет вызовов в каждый вложенный установочный пакет, то ее идентификатор заносится в абсолютную последовательность выполнения фаз, а если текущая фаза найдена в одном из установочных пакетов, то в нем последовательно выбираются, анализируются и идентифицируются все фазы, расположенные до найденной, и сама найденная фаза, каждая из которых после обработки помечается меткой как обработанная.

Программа – это упорядоченная последовательность команд. Конечная цель любой компьютерной программы – управление аппаратными средствами. Программное и аппаратное обеспечение в компьютере работают в неразрывной связи и в непрерывном взаимодействии. Состав программного обеспечения вычислительной системы называют программной конфигурацией. В программной конфигурации между её программами существует взаимосвязь, то есть имеет место межпрограммный интерфейс. Возможность существования такого интерфейса основана на существовании технических условий и протоколов взаимодействия. На практике межпрограммный интерфейс (взаимодействие) обеспечивается путём распределения программного обеспечения по нескольким взаимодействующим между собой уровням. Эти уровни представляют собой пирамидальную конструкцию. Каждый следующий уровень опирается на программное обеспечение предшествующих уровней. Уровни программного обеспечения подразделяются на: базовый, системный, служебный и прикладной уровни.

Базовый уровень – самый низкий уровень программного обеспечения представляет базовое программное обеспечение. Оно отвечает за взаимодействие с базовыми аппаратными средствами и, как правило, программные средства входят непосредственно в состав базового оборудования и хранятся в специальных микросхемах ПЗУ. Программы и данные записываются в микросхемы ПЗУ на этапе производства и не могут быть изменены в процессе эксплуатации.

Системный уровень – переходной. Программы, работающие на этом уровне, обеспечивают взаимодействие прочих программ компьютерной системы с программами базового уровня и непосредственно с аппаратным обеспечением, то есть выполняют “посреднические” функции. Конкретные программы, отвечающие за взаимодействие с конкретными устройствами, называются драйверами устройств. Они входят в состав программного обеспечения системного уровня. Программы, отвечающие за взаимодействие с пользователем, называют средствами обеспечения пользовательского интерфейса. Совокупность программного обеспечения системного уровня образует ядро операционной системы компьютера. Если компьютер оснащён программным обеспечением системного уровня, то он уже подготовлен к установке программ более высоких уровней, к взаимодействию программных средств с оборудованием и с пользователем. Наличие ядра операционной системы – непременное условие для возможности практической работы человека с вычислительной системой.

Служебный уровень – это служебные программы, обеспечивающие взаимодействие с программами базового и системного уровней. Служебные программы (утилиты) предназначены для автоматизации работ по проверке, наладке и настройке компьютерной системы.