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

ВАРІАНТ № 15

1. Послідовність операцій робочого елемента

67. Зелені інформаційні технології.

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

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

public class Calculator

{

bool _isDirty;

string _operation;

decimal _state;

public decimal Display { get; private set; }

public void Enter(decimal number)

{ _state = number;

_isDirty = true; }

public void PressPlus()

{ _operation = "+";

if (_isDirty) Calculate(); }

public void PressEquals()

{ if (_isDirty) Calculate(); }

void Calculate()

{ switch (_operation)

{ case "+":

Display += _state;

break; }

_isDirty = false; }

}

70. Показати, що ланцюг К1В14 належить мові, що задається граматикою

G1={T, N, P, I}:

T={a, .., z, 0, .., 9} N={I, P, ЛИТЕРА, ЦИФРА} Правила P I ::= ЛИТЕРА | ЛИТЕРА K K ::= ЛИТЕРА | ЦИФРА | ЛИТЕРА K | ЦИФРА K ЛИТЕРА ::= a | b . . | z ЦИФРА ::= 0 | 1 . . . | 9

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

+15.1.Послідовність операцій робочого елемента.

+15.2.Зелені інформаційні технології.

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

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

71. экологическая эффективность,

72. экологическая справедливость,

73. экологическая результативность.

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

Эко-справедливость - следуя принципу нужно равно распределять ресурсы между живущим и следующими поколениями.

Эко-результативность - следуя принципу надо полностью прекращать негативне влияние на окружающую среду.

1) Зеленые информационные технологии

Зеленые технологии состоят из следующих элементов: зеленый бизнес, зеленые информационные технологии и зеленая энергия.

Для зеленого бизнеса характерно внедрение зеленого производства, корпоративная и социальная ответственность.

Зеленые информационные технологии помогают сохранять ресурсы и рационально перерабатывать отходы.

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

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

Роли информационных технологий, при этом делят на три типа – информировать, автоматизировать и превращать.

Требования устойчивого развития предприятия содержат выполнение следующих условий:

• выпуск качественной продукции, которая отвечает потребностям целевой группы населения и не влияет вредно на окружающую среду;

• создание благоприятного зеленого имиджа предприятия в глазах населения и деловых партнеров;

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

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

***

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

• организовывать эффективное потребление электроэнергии, используя интерфейс ACPI и виртуализацию;

• переводить компьютер в режимы пониженного энергопотребления в промежутки времени, когда информационные технологии не обрабатывают данные;

• использовать в программном обеспечении многопоточную обработку данных;

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

• следить за распределением динамической памяти.

Чтобы озеленять информационные технологии можно использовать следующие подходы:

• тактический, инкрементный (ставятся отдельные цели)

• стратегический (выполняется аудит ор-ганизации и разрабатывается план)

• глубокий зеленый (ком-плексное озеленение всей организации).

+***15.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).

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

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

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

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

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

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

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

public class Calculator

{

bool _isDirty;

string _operation;

decimal _state;

public decimal Display { get; private set; }

public void Enter(decimal number)

{ _state = number;

_isDirty = true; }

public void PressPlus()

{ _operation = "+";

if (_isDirty) Calculate(); }

public void PressEquals()

{ if (_isDirty) Calculate(); }

void Calculate()

{ switch (_operation)

{ case "+":

Display += _state;

break; }

_isDirty = false; }

}

====================================== ОТВЕТ:

[TestMethod]

public void TestMethod1()

{

ConsoleApplication12.Calculator calc = new ConsoleApplication12.Calculator();

calc.Enter(10);

calc.PressPlus();

decimal dec = (decimal) 12.2;

calc.Enter(dec);

calc.PressEquals();

decimal factResult = calc.Display;

decimal exptResult = (decimal)22.2;

Assert.AreEqual(exptResult,factResult);

}

+15.5.Показати, що ланцюг К1В14 належить мові, що задається граматикою

G1={T, N, P, I}:

T={a, .., z, 0, .., 9} N={I, P, ЛИТЕРА, ЦИФРА} Правила P I ::= ЛИТЕРА | ЛИТЕРА K K ::= ЛИТЕРА | ЦИФРА | ЛИТЕРА K | ЦИФРА K ЛИТЕРА ::= a | b . . | z ЦИФРА ::= 0 | 1 . . . | 9

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

ВАРІАНТ № 16

1. Структура компілятора.

74. Шаблон процесу MSF CMMI.

75. Рівні абстракції дослідження програмного забезпечення.

76. Створіть модель своєї екосистеми програмного забезпечення і презентації її в нотації і*.

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

+16.1.Структура компілятора.

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

Входной информацией для компилятора (исходный код) является описание алгоритма или программа на проблемно-ориентированном языке, а на выходе компилятора — эквивалентное описание алгоритма на машинно-ориентированном языке (объектный код).

Процесс компиляции состоит из следующих этапов:

• Лексический анализ. На этом этапе последовательность символов исходного файла преобразуется в последовательность лексем.

• Синтаксический (грамматический) анализ. Последовательность лексем преобразуется в дерево разбора.

• Семантический анализ. Дерево разбора обрабатывается с целью установления его семантики (смысла) — например, привязка идентификаторов к их декларациям, типам, проверка совместимости, определение типов выражений и т. д. Результат обычно называется «промежуточным представлением/кодом», и может быть дополненным деревом разбора, новым деревом, абстрактным набором команд или чем-то ещё, удобным для дальнейшей обработки.

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

• Генерация кода. Из промежуточного представления порождается код на целевом языке.

В конкретных реализациях компиляторов эти этапы могут быть разделены или, наоборот, совмещены в том или ином виде.

Структура компилятора:

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

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

Пример:  begin length:= 6; end  begin | length | := | 6 | ; | end

Лексический блок устанавливает из каких частей состоит данная цепочка: ключевое слово begin, идентификатор переменной length, знака присваивания :=, целочисленной константы 6, точки с запятой ; и ключевого слова end. Таким образом, цепочка из 21 символа была преобразована в цепочку из 6 лексем.

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

Пример: A+B*C

Лексический анализ:

        А (30, 1)

        + (14, 0)

        B (30, 2)

        *  (15, 0)

        C  (20, 3)

Синтаксический анализ:

        умножить(B, C, R1) – атом №1

        сложить(A, R1, R2) – атом №2

Таким образом, 5 лексем, выданных лексическим блоком преобразуются в две новые единицы, которые описывают тоже действие. Эти единицы называют атомами и образуют выход синтаксического анализа. Последовательность атомов отражает действия и их порядок. Любой атом также состоит из класса и значения.

Атом №1 также может принадлежать к классу УМНОЖ и иметь значение, состоящее из трех указателей на элементы таблицы: умножить(2, 3, 1). При этом третий операнд указатель на таблицу вспомогательных регистров, а не на таблицу идентификаторов. Аналогично: сложить (1, 4, 2).

Во время обработки компилятором, атом будет представлен числом обозначающих умножить и тремя указателями на элементы таблиц: (5, 2, 3, 1).

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

Генератор кода «развертывает» атомы, построенные синтаксическим блоком в последовательность команд ЭВМ. Характер развертывания зависит от элементов таблицы, на которые ссылаются атомы, а также от ожидаемого состояния машины в момент выполнения команд.

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

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

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

+16.2.Шаблон процесу MSF CMMI.

В комплекте VSTS поставляются два шаблона процессов: MSF Agile и MSF CMMI.

MSF for Agile Software Development - простий шаблон для невеликих або неформальних проектів з розробки ПЗ. Він грунтується на сценаріях і діях за обставинами. Орієнтований на конкретний проект і його виконавців. У шаблоні MSF Agile передбачений стандартний набір робочих елементів з завданнями, достатніми для початку процесу розробки-ки ПЗ. В цьому шаблоні є такі типи робочих елементів:

• Сценарій (scenario) Використовується для представлення взаємодії користувача з додатком. Описує конкретні кроки, необхід-мі для досягнення мети. Сценарії мають бути конкретними, пос-Кольку можливих способів дії може бути декілька.

• Задача (task) Використовується для представлення блоку роботи. У каж-дой ролі свої вимоги до завдань. Наприклад, розробник використовує для розподілу робіт завдання розробки.

• Вимога QoS (Quality of Service requirement) документуються є характеристики системи, наприклад, продуктивність, навантаження, доступ-ність, стійкість до нештатних умовам експлуатації, спеціальні можливості і зручність обслуговування.

• Помилка (bug) Використовується для інформування про потенційну проблему в системі.

• Ризик (risk) Використовується для виявлення та управління ризиками в проекті.

+16.3.Рівні абстракції дослідження програмного забезпечення.

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

Рівень абстракції представляє собою конкретний спосіб приховати деталі реалізації визначеного набору функцій.

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

Рівні абстракції:

• програмний

• шаблонний (рівень паттернів)

• графів

• архітектурний

• даних

• прикладний

• бізнес

Програмний рівень:

• Окремі вирази

• Змінні

• Значення

• Типи процедури

Шаблонний рівень

Шаблони (паттерни) – повторяємо архітектурна конструкція, що представляє собою вирішення проблеми проектування в рамках деякого часто виникаючого контексту (абстрактна фабрика, компонувальник та інш.)

Стилі (процедурний, функціональний, логічний, об’єктно-орієнтований)

Процедурне програмування – програмування, при якому програма представляє собою послідовність операторів. Використовується в мовах високого рівня Basic, Fortran та інш.

Функціональне програмування – програмування, при якому програма представляє собою послідовність викликів функцій. Використовується в Lisp та інш.

Логічне програмування – програмування, при якому програма представляє собою сукупність визначення співвідношень між об’єктами. Використовується в мовах Prolog та інш.

Об’єктно-орієнтоване програмування – це програмування, при якому основою програми є об’єкт, що представляє собою сукупність даних і правил їх перетворення. Використовується в мовах Turbo-Pascal, C++ та інш.

Рівень графів

• зв’язки між процедурами

• зміни станів

Архітектурний рівень

• архітектурні стилі (клієнт-серверна модель, подійна архітектура, пошуково-орієнтована та інш);

• методології

• інтерфейси

Рівень даних

• Структури даних

• Потоки даних

• Атрибути баз даних

Прикладний рівень

• Обмін даними із зовнішнім середовищем/платформою

Бізнес рівень

• Концепція бізнес-домену

• Бізнес-умови/правила

• Їхня програмна реалізація

+16.4.Створіть модель своєї екосистеми програмного забезпечення і презентації її в нотації і*.

Розробимо модель в і*-нотації екосистеми підприємства ЗАТ «УкрСофт», яке займається розробкою програмного забезпечення.

Екосистема підприємства ЗАТ «УкрСофт», яке займається розробкою програмного забезпечення, зображена на рис. 1.

Визначимо акторів екосистеми:

• ЗАТ «УкрСофт»;

• Маркетолог;

• Проектувальник;

• Програміст;

• Тестувальник;

• Орган контролю якості;

• Кінцевий споживач.

Метою маркетолога є аналіз ринку програмного забезпечення, визначення вимог до нового програмного забезпечення

Метою проектувальника є вибір методів задоволення вимог та розробка завдання на проектування. Він розробляє технічний проект, який передає розробнику ПЗ – програмісту.

Програміст має за мету створити програмний код згідно з технічним проектом. Тобто він реалізує програмний код. Готовий програмний код передається на перевірку тестувальнику.

Метою тестувальника є здійснення верифікації, валідації та атестації програмного коду. Він тестує програмний код, і отримує в органі контролю якості сертифікат відповідності стандартам ПЗ і передає готове до експлуатації програмне забезпечення менеджеру збуту.

Орган контролю якості повинен забезпечити гарантію якості ПЗ. Він здійснює управління процесами забезпечення якості та оформляє дозвіл підприємству, а також видає сертифікат, який засвічує споживача, що дане ПЗ відповідає стандартам якості.

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

Кінцевий споживає купує та експлуатує дане програмне забезпечення. А також отримує сертифікат якості на придбане ПЗ. Його метою є задоволення вимог та очікувань.

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

Процесс разработки web-сайта. Стадии жизненного цикла и их особенности

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