Программа - это упорядоченная последовательность команд. Конечная цель любой компьютерной программы - управление аппаратными средствами. Даже если на первый взгляд программа никак не взаимодействует с оборудованием, не требует никакого ввода данных с устройств ввода и не осуществляет вывод данных на устройства вывода, все равно ее работа основана на управлении аппаратными устройствами компьютера.
Состав программного обеспечения (ПО) вычислительной системы называют программной конфигурацией .
Ппрограммные средства можно разделить на автоматические и автоматизированные. Автоматическое ПО выполняется без вмешательства человека, результаты его работы могут быть даже незаметны для пользователя. Часто оно бывает защищено от проникновения в программный код, изменить автоматическое ПО трудно или в принципе невозможно.
Автоматизированное ПО не может функционировать без пользователя, здесь человек, работающий на компьютере, ставит компьютеру задачи и оценивает их выполнение. Эти программы человек использует для достижения своих целей: подготовки документов, получения информации из тех или иных источников, просмотра текста, графики, видео и так далее. Человек выполняет творческую часть работы, а компьютер – рутинную.
С точки зрения объекта работы ПО подразделяют на системное и прикладное. Первое обеспечивает работу компьютера, второе позволяет с помощью компьютера решать задачи в различных сферах человеческой деятельности.
Более подробную классификацию можно получить при рассмотрении этапов работы компьютера после его включения. Здесь можно выделить три уровня программной конфигурации: базовый, системный и пользовательский. При включении компьютера последовательно загружается каждый из уровней (рисунок). Операционная система начинает загружаться после установки базовых программ, а все прочие программы становятся доступными только после завершения установки операционной системы.
Каждый следующий уровень опирается на программное обеспечение предшествующих уровней. А каждый вышележащий уровень увеличивает возможности компьютера. Так, например, компьютер с программным обеспечением базового уровня не способен к практическому использованию, но позволяет установить системное программное обеспечение и часть служебного ПО.
Программы пользовательского уровня можно подразделить на:
служебные, с помощью которого пользователь может повысить эффективность работы компьютера, оптимизировать функции программного и аппаратного обеспечения;
инструментальные, предназначенные для программирования, то есть разработки новых программ;
прикладные – это все остальное программное обеспечение, предназначенное для решения широкого круга задач: производственных, творческих, обучающих, развлекательных и пр.
Программное обеспечение, предназначенное для персональных компьютеров велико и разнообразно. Изучить его в рамках одной главы невозможно. Необходимые специальные программы изучаются студентами в других курсах. Здесь же мы рассмотрим лишь самую распространенную и универсальную часть программного обеспечения для ПК.
1. Программы базового уровня, действующие от момента включения компьютера до начала загрузки операционной системы. Основные функции и виды операционных систем для ПК уже рассматривались в главе 1.
2. Важнейшее служебное ПО, а именно:
служебные программные средства ОС Windows;
диспетчеры файлов;
архиваторы.
3. Из прикладного ПО в данной главе будет рассмотрен только программный пакет MicrosoftOffice– самое распространенная среда для делопроизводства. А на практике расширенные возможностиWord,Excel,PowerPoint,Accessосваиваются в рамках лабораторного практикума.
Управление конфигурацией ПО — это один из вспомогательных процессов, поддерживающих основные процессы ЖЦ ПО, прежде всего процессы разработки и сопровождения ПО.
Под конфигурацией ПО понимается совокупность его функциональных и физических характеристик , установленных в технической документации и реализованных в ПО.
В крупном проекте большие объемы информации меняются очень быстро и неконтролируемые изменения могут быстро ввергнуть проект в хаос. Работая над программным проектом, группа программистов, тестеров и менеджеров сталкивается с проблемой отслеживания версий программ, внесения в них изменений. Чем больше проект, тем больше времени разработчики тратят на согласования изменений в исходных текстах и получения работающих версий программного продукта. Данная задача может усугубиться наличием в компании регионально удаленных групп-разработчиков.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
При групповой разработке сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, необходимо :
- выделить набор объектов , определяющих структуру будущей системы, чтобы затем контролировать их состояния и ход работ по каждому из них. Такими объектами могут быть функционально-логическая модель системы, реляционная модель базы данных, модули прототипов системы (экраны, меню, отчеты, тексты процедур или классов), системные и программные спецификации, документация, планы проведения тестирования, спецификации тестовых процедур;
- контролировать запросы на доработку модуля, сообщения о найденной ошибке или неисправности оборудования, запросы на модификацию оборудования или ПО, задания на установку рабочего места, задания разработчику, аналитику и т.п., так как эти объекты влияют на состояние текущих версий других объектов и относятся к сфере управления изменениями;
- вести журнал всех изменений , внесенных в систему в процессе разработки или сопровождения (это касается состояния создаваемой системы, бюджета, сроков, интерфейса, контрольных отчетов и т.д.);
- вести полный и достоверный архив всех версий всех объектов системы;
- контролировать состояние и развитие коллективно используемых компонентов ПО и их версий, учитывая связи компонентов системы для согласования между собой измененных частей ; обеспечивать адекватность реально изменяющихся компонентов и их комплектной документации;
- проводить оценку конфигурации — оценивать функциональную полноту компонентов ПО, а также соответствие их физического состояния текущему техническому описанию.
- изготавливать эталонные копии ПО и документации, хранить и поставлять их пользователям в соответствии с порядком, принятым в организации. Это упрощает выпуск и поставку ПО;
- обеспечивать развитие всей системы, ограничивая усложнение проекта.
Рассмотрим, как пример, управление исходным кодом .
Для групповой разработки важны системы контроля исходного кода . Такие системы решают, по крайней мере, две задачи: хранение всех версий каждого экземпляра исходного кода (версии файлов) и разрешение конфликтов одновременного доступа разработчиков к одному экземпляру исходного кода (слияние исходных текстов, согласованность группы файлов проекта и т.п.).
Контролю подвергается не только собственно код модулей, но и код скриптов генерации схемы базы данных, а также собственно схема базы данных, которая может храниться в виде версий бинарных файлов, экспортированных во внутренний формат СУБД схем баз данных.
Прикладные программисты должны придерживаться установленных правил групповой разработки.
После того как основной код модуля будет создан и зарегистрирован в системе контроля исходных текстов, каждая правка в нем должна быть помечена датой и именем автора правки. Правки должны сопровождаться ясными комментариями , которые располагаются в начале файла исходного кода.
Формат комментария к правке может быть таким:
Это делается для того, чтобы через некоторое время можно было понять, кто и зачем внес данную правку. Также это помогает корректировать слияние исходного кода, если система контроля обнаружила несовместность правок и не может разрешить ее сама.
Часто ведущие исполнители проектов не доверяют системам контроля исходного кода сливать правки в исходных текстах автоматически и частично или полностью контролируют этот процесс. Эта перестраховка во многих случаях себя оправдывает.
Также в начале исходного кода (в комментариях) описывается: для чего данный файл исходного кода создан, основные его функции, к какой части информационной системы он относится, кто автор.
Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида K1, Function10.
Для крупных подсистем должен фиксироваться интерфейс обмена с другими подсистемами — формат данных, передаваемых подсистеме и получаемых из нее, а также формат вызовов функций и методов подсистемы. Это позволяет добиться относительной независимости подсистем и снизить влияние изменений кода одной подсистемы на другую.
Такой подход облегчает взаимодействие разработчиков разных модулей. Документировать нужно только интерфейс обмена, а не весь код модуля целиком.
Зачастую разработчику, вызывающему функцию модуля, требуется знать, что нужно передать и как обработать результат, а что происходит внутри — знать не обязательно. Единственное, что его интересует, — это правильная инициализация модуля, правильный прием результатов его работы и правильная выгрузка модуля.
Взаимодействие компонентов не должно быть произвольным. Контролировать эти правила создания исходного кода в большинстве случаев приходится вручную.
Группа разработчиков должна иметь свой выделенный сервер баз данных, и, возможно, не один, а также выделенные рабочие места. Часто эти моменты далеко не очевидны руководству, и оно воспринимает это как совершенно ненужную трату средств. Сервер, обеспечивающий контроль исходного кода, также должен быть выделенным.
Рынок систем конфигурационного управления
Без хорошего инструментария невозможно оперативно управлять конфигурациями ПО.
Специализированные системы конфигурационного управления позволяют выполнять автоматизированную сборку готового продукта из множества изменяющихся частей по типовой схеме, исключая "человеческий фактор" на этом рутинном этапе, а, следовательно, и дорогостоящие ошибки.
Можно выделить четыре группы таких продуктов :
1) обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe);
2) обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional);
3) обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (PVCS Dimensions, CCC:Harvest фирмы Computer Associates);
4) обеспечивающие все вышеуказанные возможности при взаимодействии нескольких географически удаленных команд (Rational MultiSite, PVCS Replicator).
Продукт ClearCase наиболее мощный и, соответственно, дорогой. Он лучше всего подходит для проектов, в которых участвует не менее 10 разработчиков и которые направлены на создание крупных систем или на выпуск тиражируемого ПО, когда особенно актуальны проблемы отслеживания версий. ClearCase поддерживает множество репозитариев проекта с их автоматической синхронизацией; координирует совместную работу всех участников проекта; управляет конфигурацией сборки ПО; обеспечивает визуальный контроль над происходящим.
В числе недостатков ClearCase — необходимость серьезного администрирования, т.е. нагрузка при работе с продуктом перекладывается с конечных пользователей на администратора.
Продукт PVCS , встроен во многие системы разработки, предлагает более простой версионный контроль. Он хуже автоматизирует работу пользователей и сложнее в применении, но зато не требует отдельного сотрудника-администратора для поддержки небольших групп разработчиков. Существуют проблемы переходов от одного продукта PVCS к другому. Имеет меньшую стоимость. Может оказаться хорошим решением, если разработка идет под разными платформами (аппаратная платформа и ОС).
Продукт Microsoft Visual Source Safe осуществляет простой контроль исходных текстов и подходит для индивидуальной работы или для проектов, объединяющих нескольких человек. В нем нельзя организовать связь между участниками проекта, но он значительно дешевле и проще. Используется для ОС Windows 98, NT, 2000.
В ноябре 2002 г. компания Merantвыпустилановую версию популярного инструмента для управления конфигурациями ПО PVCS Professional 7.5 .
В состав пакета входят:
PVCS Version Manager 7.5 — система контроля версий;
PVCS Tracker Manager 7.5 — утилита формирования журнала изменений и задач;
Configuration Builder 7.5 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.
Совокупность настроек программы, задаваемая пользователем.
Существуют различные подходы к хранению конфигурации. Многие программы хранят настройки в текстовых файлах; особенно характерно это для UNIX-подобных систем . В Windows текстовые конфигурационные файлы так же используются и часто имеют формат .ini . Несмотря на то, что почти во всех случаях эти файлы можно редактировать вручную, во многих случаях для этого создаётся специальный интерфейс (который может быть как консольный, так и графический).
Иногда в UNIX-подобных системах конфигурация задаётся на этапе сборки программы, и для её изменения программу необходимо пересобирать. Ярким примером может служить ядро Linux . Почти во всех приложениях, собираемых на основе autoconf , можно подключать или отключать те или иные внешние библиотеки через параметры к скрипту configure .
Часто для хранения конфигурации используется специальная база данных. В Windows используется реестр Windows , а в GNOME - GConf ; в обоих случаях конфигурация имеет древовидную структуру.
Источники
Wikimedia Foundation . 2010 .
Смотреть что такое "Конфигурация программного обеспечения" в других словарях:
Содержание 1 Бразилия 2 Великобритания 3 Индия … Википедия
Конфигурация: В Викисловаре есть статья «конфигурация» Конфигурация (астрономия) … Википедия
В области информационных и компьютерных систем под конфигурацией понимают определенный набор комплектующих, исходя из их предназначения, номера и основных характеристик. Зачастую конфигурация означает выбор аппаратного и программного обеспечения … Википедия
У этого термина существуют и другие значения, см. Конфигурация. Совокупность параметров программного обеспечения. В операционных системах *NIX изменение конфигурации производится путем редактирования текстовых файлов настройки, расположенных, как … Википедия
ГОСТ Р МЭК 61508-4-2007: Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения - Терминология ГОСТ Р МЭК 61508 4 2007: Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения оригинал документа: 3.7.4 анализ влияния (impact analysis) …
Инфраструктура - (Infrastructure) Инфраструктура это комплекс взаимосвязанных обслуживающих структур или объектов Транспортная, социальная, дорожная, рыночная, инновационная инфраструктуры, их развитие и элементы Содержание >>>>>>>> … Энциклопедия инвестора
система - 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечание 1 Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 На практике… … Словарь-справочник терминов нормативно-технической документации
СТО Газпром 2-2.3-141-2007: Энергохозяйство ОАО "Газпром". Термины и определения - Терминология СТО Газпром 2 2.3 141 2007: Энергохозяйство ОАО "Газпром". Термины и определения: 3.1.31 абонент энергоснабжающей организации: Потребитель электрической энергии (тепла), энергоустановки которого присоединены к сетям… … Словарь-справочник терминов нормативно-технической документации
Р 50.1.048-2004: Информационно-телекоммуникационные игровые системы. Термины и определения - Терминология Р 50.1.048 2004: Информационно телекоммуникационные игровые системы. Термины и определения: 2.3.25 адаптивное сопровождение: Изменение программного продукта после поставки, обеспечивающее его работоспособное состояние в измененных… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р МЭК 61513-2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования - Терминология ГОСТ Р МЭК 61513 2011: Атомные станции. Системы контроля и управления, важные для безопасности. Общие требования оригинал документа: [МАГАТЭ 50 SG D8] Примечание 1 См. также «система, важная для безопасности», «класс систем контроля… … Словарь-справочник терминов нормативно-технической документации
На всех уровнях тестирования применяются методы:
- функционального тестирования , обеспечивающие проверку реализации функций, которые определены в требованиях, а также правильность их выполнения;
- регрессионного тестирования , ориентированные на повторное выборочное тестирование системы или ее компонентов после внесения в них изменений на тех же тестах, что и до модификации;
- тестирования эффективности , проверяющие производительность, пропускную способность, максимальный объем данных и системные ограничения в соответствии со спецификациями требований;
- стресс-тестирования , проверяющие поведение системы при максимально допустимой нагрузке или при ее превышении;
- альфа и бета тестирования , выполняющие внутреннее тестирование кодов системы и внешнее тестирование интерфейсов. Альфа - это внутреннее тестирование (функций и алгоритмов), а бета - внешнее (взаимосвязей с другими системами и средой)
- конфигурационного тестирования , проверяющие структуры и идентификации системы на различных наборах данных, а также работу системы на различных конфигурациях аппаратуры и оборудования.
К методам тестирования относятся также методы проведения испытаний ПО, проверки реализации требований и обеспечения параметров настройки и размещения компонентов ПО на заданном количестве и типах компьютеров, среды и ОС.
Техники тестирования базируются на некоторых теоретических и практических положениях, например, на природе подхода к проектированию (компонентного, объектно-ориентированного, сервисного и т.п.), а также на следующих данных:
- информация о структуре ПО или системы в документации ("белый ящик" ) ;
- подбор тестовых наборов данных для проверки правильности работы компонентов и системы в целом без знания их структуры ("черный ящик");
- анализ граничных значений, таблиц принятия решений, потоков данных, статистики отказов и др.;
- блок-схемы построения программ и составления наборов тестов для покрытия системы этими тестами;
- обнаруженные и зафиксированные в таблицах системы дефекты, пред- и постусловия выполнения, структурные характеристики системы (количество модулей, объем данных и др.).
Метрики тестирования .Для измерения результатов тестирования ПО, а также при проведении анализа качества используются метрики. Измерение как часть планирования и разработки тестов базируется на размере программ, их структуре и количестве обнаруженных ошибок и дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Процесс тестирования документируется и согласно стандарту 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С Предприятие 7.7 . Таким образом, если приобретается типовой продукт, необходимо наличие 1С Предприятие 7.7 Комплексная Торголя Бухгалтерия Расчет. При необходимости программа может быть внедрена в любую другую конфигурацию буквально за 1-3 дня. Конфигурация может быть как разработки 1С, так и разработки дилеров, а также разработана самостоятельно.
В этом случае необходимо объединение конфигурации клиента с поставляемой разработчиками, которое может выполнить как специалист клиента, так и дилер 1С, а также непосредственно разработчики. Программа хранит промежуточные данные в регистрах, поэтому необходимо наличие компоненты Оперативный учет. Остальные компоненты необязательны.
Важно, чтобы конфигурация в этом случае была сохранена в 1С Предприятие 7.7 . Допускается, если она была разработана в 1С Предприятие 7.5 и затем просто сохранена в новом формате. 8,12,21,22,24
Конец работы -
Эта тема принадлежит разделу:
Бюджетное управление предприятием
Это система, которая ведется в формате бюджетов по центрам ответственности. Бюджет - это точный расчет всех ресурсов предприятия для достижения.. Почему компании переходят на бюджетное управление? В условиях жесткой конкуренции, руководители компаний задумываются..
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:
Что будем делать с полученным материалом:
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
| Твитнуть |
Все темы данного раздела:
Преимущества бюджетирования
Преимущества бюджетирования. Бюджет вudget в переводе с английского это план или стандарт, причем не обязательно финансовый.
Так, бюджет продаж, с которого, в соответствии с маркетинговыми п
Основные виды бюджетов
Основные виды бюджетов. Существует много разновидностей бюджетов, применяемых в зависимости от структуры и размера организации, распределения полномочий, особенностей деятельности и т.п. К двум осн
Cистема бюджетного управления
Cистема бюджетного управления. Во всем мире финансовое управление в конечном счете описывается в формате трех основных отчетов, которые определяют собой систему координат для оценки финансовых резу
Планирование бюджета
Планирование бюджета. Бюджетирование представляет собой метод распределения ресурсов, охарактеризованных в количественной форме, для достижения целей, также представленных количественно. Его также
Контроль учета затрат
Контроль учета затрат. В современных условиях хозяйствования эффективность работы предприятия зависит в первую очередь от качества управления бизнесом, основа которого - система управленческого уче
Место бюджетирования в системе финансового управления и его внедрение на предприятии
Место бюджетирования в системе финансового управления и его внедрение на предприятии. Сопоставление инструментов финансового управления Таблица 1 показывает характерные особенности бюджетирования,
Описание программного продукта
Описание программного продукта. Обычно в компаниях существуют практически несвязанные контуры программной поддержки для отдельных функций и служб бухгалтерской, коммерческой, финансовой.
Час
Этапы внедрения системного решения
Этапы внедрения системного решения. Методология разбивает процесс внедрения на 8 этапов? Выяснение потребностей организации? Описание системного решения? Адаптация системы к нуждам пользователей
Заполнение констант
Заполнение констант. В момент первого запуска конфигурации появляется диалоговое окно заполнения констант программного продукта Бюджетное управление обработка ввода начальных данных. При этом часть
Настройка безопасности
Настройка безопасности. Информация, хранящаяся в программе, часто имеет конфиденциальный характер, поэтому разработчики заранее предусмотрели гибкую систему безопасности.
Можно выделить неск
Первый запуск программы
Первый запуск программы. Если в конце установки программы она не может запустить 1С Предприятие это связано с особенностями установки 1С, поэтому запустите ее через меню Программы. 2. После нормал
Работа с программой
Работа с программой. После того, как программа установлена и запущена в первый раз в монопольном режиме, ею можно полноценно пользоваться. 2. Если происходит первый запуск с компьютера, на который
Демонстрация программы
Демонстрация программы. Рекомендуется демонстрацию программы проводить через показ презентации в MS PowerPoint. Если зритель требует показа нюансов, то возможно параллельно разъяснять отдельные асп
Приобретение программы
Приобретение программы. Лицензируются и приобретаются только рабочие места модуля планирования.
То есть нужно покупать программу на то количество мест, которые будут планировать вводить доку