Шляхом побудови дерева виводу.

23.5.Розгляньте наступні рядки паралельного програмного коду, знайдіть та поясніть помилку, перепишіть код для виправлення помилки:

int a = 0;

#pragma omp parallel for num_threads(4)

for (int i = 0; i < 100000; i++) {

a++;}

+-23.1.Утилізація обладнання.

Утилізація електронних компонентів дуже важливий екологічний аспект информаційних систем. Практично всі апаратні елементи інформаційних систем містять шкідливі речовини (рис.1) і виділяють вуглекислий газ (рис.2) . Існують стандарти, які спрямовані на вирішення проблем електронни відходів. Очевидно, що ще при проектуванні інформаційної системи слід приймати до уваги ліквідацію її компонентів. Наприклад, можна скористатися інструментом ЕРА для вибору чистих компонентів інформаційної системи. У США можна шукати центри з ліквідації обладнання. В цілому при ліквідації інформаційних систем реалізуються такі процеси:

• повторне використання - передача обладнання виробникам для застосування або користувачам, вимогам яких воно відповідає;

• відновлення - заміна частин компонентів діючих інформаційних систем;

• ліквідація - знищення (переробка) електронних відходів.

+23.2.Стратегії структурування рішення і проекту.

Одиночне рішення. При розробці невеликої системи, створюється одиночне рішення, в якому розміщуються всі проекти.

При роботі над невеликою системою рекомендується розміщувати всі проекти в одиночному рішенні Visual Studio. Така структура спрощує розробку, тому що при відкритті рішення доступний весь вихідний код. При такій стратегії також дуже легко працювати з посиланнями, тому що всі вони є посиланнями на проекти одного рішення. Але все-таки, можливо, доведеться використовувати посилання на файли збірок сторонніх виробників, наприклад на куплені компоненти, що знаходяться поза рішення.

Головними причинами вибору даної структури є:

• Прості сценарії складання.

• В рамках рішення можна без праці відображати залежності між проектами.

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

Сегментоване рішення. При розробці великої системи взаємозалежні проекти групуються в різні рішення. Для кожної логічної групи проектів, з якою розробник, найімовірніше, буде працювати як із сукупністю, створюється окреме рішення. Потім всі ці рішення об'єднуються в одне головне рішення, яке буде містити всі проекти. При такому підході скорочується кількість даних, які з системи контролю версій, оскільки робота ведеться тільки над певними проектами.

Сегментоване рішення використовується для логічної угруповання підмножин проектів, які розробники, найімовірніше, будуть змінювати спільно. При цьому створюється одне головне рішення, що містить всі проекти. Для створення певних уявлень підсистем та скорочення часу завантаження і збірки додатку використовується кілька рішень. Сегментоване рішення відмінно підходить для більшості великих проектів, тому що забезпечує гнучкість рішення і при цьому надає одне рішення, яке може використовуватися для збірки додатку.

Підстави використання цієї структури:

• Підвищення продуктивності при завантаженні і складання складових рішень.

• Можливість використання складових рішень для створення уявлень наборів проектів, створених певною підгрупою, або на підставі кордонів спільного використання коду.

• Можливість використання головного рішення для складання всієї програми.

• Можливість без праці відображати залежності між проектами в кожному становить рішенні.

• Спрощення системи в цілому, якщо рішення логічно виділені. Наприклад, якщо рішення виділено відповідно технологічним або функціональним характеристикам, новим розробникам набагато простіше зрозуміти, над яким з рішень працювати.

Кілька рішень. При створенні дуже великої системи, що вимагає десятків і більше проектів, слід працювати з підсистемами. Для відображення залежностей і з міркувань продуктивності не потрібно створювати головне рішення, що містить всі проекти.

Отже:

• Використовувати стратегію одиночного рішення, якщо розмір одержуваного в результаті рішення не надто великий і не призводить до проблем завантаження в Visual Studio.

• Використовувати кілька рішень для створення окремих уявлень підсистем додатків.

• Використовувати кілька рішень для скорочення часу завантаження рішення і скорочення часу зборки для розробників.

+***23.3.Визначте основні етапи впровадження програмного забезпечення та розкрийте зміст стандартів що регламентують дії пов’язані з впровадженням програмного забезпечення.

Основные этапы внедрения программного продукта:

• 1. Обследование

• 2. Разработка технического задания

• 3. Настройка программного комплекса

• 4. Тестирование системы

• 5. Опытная эксплуатация

• 6. Сдача проекта

• Первый этап проекта – диагностика предприятия или его обследование. Под обследованием подразумевается диагностика на предприятии всех бизнес-процессов, которые будет охватывать система «АНТРА ОФИС». Количество дней для обследования напрямую зависит от объемов предприятия, количества сотрудников и бизнес-процессов предприятия. Обычно на обследование отводится от 1 недели до 1 месяца ( средняя продолжительность этапа «обследование» – 2 недели).

• Второй этап внедрения программного продукта – разработка технического задания. Техническое задание (ТЗ) включает в себя описание всех справочников системы, всех алгоритмов расчета, создания шаблонов используемых на предприятии документов, АРМ (Автоматизированных рабочих мест) пользователей и описание разграничения прав доступа пользователей. Разработка технического задания занимает от 1 до 3 недель (средняя продолжительность этапа «разработка технического задания» - 1,5-2 недели).

• Третий этап проекта – настройка системы (автоматизация). Настройка системы включает в себя формирование в программе всех справочников системы, создания шаблонов документов, настройка всех алгоритмов работы пользователей, форм и видов документов, составления шаблонов отчетных форм, ввод пользователей системы и настройка прав доступа. Продолжительность данного этапа напрямую зависит от квалификации специалистов и от уровня сложности поставленной задачи. Среднее время, отводимое на настойку системы, составляет 1 -1,5 недели.

• Четвертый этап проекта – тестирование программного продукта (системы). Тестирование системы включает в себя подготовку демонстрационного примера, внесение тестовых данных, проверку алгоритмов расчета и исправление обнаруженных ошибок. В среднем на этап тестирование отводится 1-2 недели.

• Пятый этап проекта – опытная эксплуатация системы. Опытная эксплуатация системы включает в себя работу с реальными данными, но при пристальном наблюдении и курировании специалистов по внедрению. В среднем на этап опытной эксплуатации занимает отчетный период равный 1-му месяцу.

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

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

==============

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

Процессы и этапы сопровождения охватывают: подготовку процесса; анализ дефектов и модификаций; внесение изменений; поставку, проверку и приемку ПО при сопровождении; перенос на иные платформы. Они завершаются окончательным снятием программного продукта с эксплуатации. Исходные данные преобразуют или используют в работах по сопровождению для получения выходных результатов – модифицированных версий программного продукта. Рекомендуется проводить регулярный контроль с целью проверки корректности выходных результатов конкретных работ по сопровождению . Для обеспечения работ по сопровождению рекомендуется использовать вспомогательные и организационные процессы по стандартам ISO 12207 и ISO 15504.

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

Стандартом ISO 14764 рекомендуется сопроводителям формализовать конкретный план сопровождения ПС из представленного общего состава процессов ЖЦ, который уточнить и адаптировать с учетом объема и особенностей проекта и содержащим разделы:

• описание сопровождаемой системы, в которую входит

ПС;

• концепция сопровождения комплекса программ; описа-ние уровня сопровождения системы и ПС; установление дли-тельности процессов сопровождения; адаптация стандартизиро-ванных процессов сопровождения;

• организационные работы по сопровождению, роли и

обязанности специалистов ;

• ресурсы: состав специалистов; инструментальные средст -ва; технические средства; документы и планы;

• процессы– как должна быть выполнена конкретная дея-тельность;

• определение уровня обучения , необходимого для со-проводителей и для пользователей;

• протоколы и отчеты по сопровождению; контрольные

данные, собранные при работах по сопровождению.

Сопровождаемость про-граммного средства может быть улучшена при учете характери-стик качества, регламентированных в стандарте ISO 9126.

Анализ дефектов и модификаций в стандарте ISO 14764 рекомендуется реализовать в следующем порядке:

• анализируются предложения о модификации и отчеты о дефектах;

• дублируется или проверяется реальность каждого дефек-та;

• разрабатываются варианты реализации изменения ;

• документально оформляются: предложения о модифи-кации и отчеты о дефектах, результаты их рассмотрения и ва-рианты реализации изменений;

• проводится согласование выбранного варианта реализа-ции изменения с заказчиком.

Сопроводитель должен реализовать процесс управления конфигурацией для управления изменениями существующей системы или определить организационный интерфейс с данным про-цессом. При выполнении работы по подготовке процесса сопровождения используют следующие вспомогательные и организационные процессы жизненного цикла ПС (стандарт ISO 12207): документирование; управление конфигурацией; обеспечение качества; совместный анализа; управление проектом; создание инфраструктуры; обучение .

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

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

Контроль за рассматриваемыми работами следует прово-дить посредством процесса совместного анализа (ISO 14764).

Сопроводитель должен выполнить анализ использования процессов разработки комплекса программ при внесении изменений (ISO 12207).

Результаты испытаний корректировок должны быть до-кументально оформлены .

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

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

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

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

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

+23.4.Показати, що ланцюг –1/18 належить мові, що задається граматикою G4={T, N, P, D}:

T={0, .., 9, +, –, /} N={D, G, P, ЦИФРА} Правила P D ::= G | +G | –G G ::= P | P/P P ::= ЦИФРА | ЦИФРА P ЦИФРА ::= 0 | 1 . . . | 9