Министерство образования Красноярского края

краевое государственное бюджетное

профессиональное образовательное учреждение

«КАНСКИЙ ТЕХНОЛОГИЧЕСКИЙ КОЛЛЕДЖ»

Междисциплинарный

курс:

Методы

и

средства

проектирования

информационных систем

Наименование работы:

Методическая разработка теоретического занятия

Тема: Стандарт жизненного цикла ПО ISO 12207

Специальность: 230401 (090204)

Информационные системы (по отраслям)

2 (3) курс

Автор: Федорова Александра Станиславовна, преподаватель специальных

дисциплин

Место выполнения

Канский технологический колледж, г. Канск

2017 г.

Пояснительная записка

Данное теоретическое занятие по междисциплинарному курсу «Методы

и средства проектирования информационных систем» проводится в Канском

технологическом колледже со студентами групп второго (третьего) курса,

обучающихся по специальности 230401 (090204) Информационные системы

(по отраслям).

Учебно-методическая карта занятия

Тема: Стандарт жизненного цикла ПО ISO 12207

Цели:

Образовательные:



Сформировать представление о стандартах жизненного цикла

программного обеспечения



Систематизировать и закрепить знания о моделях жизненного цикла

программного обеспечения, полученные на других дисциплинах

Развивающие:



Развивать мыслительные операции, внимание, восприятие, память;



развивать речь студентов

Воспитательные



Воспитывать интерес к профессии

Вид урока: лекция

Тип урока: Урок постановки учебной задачи

Средства обучения

1.

Персональные компьютеры

2.

Видеопроектор

3.

Система электронного обучения

План урока:

1.

Организационный момент

2.

Подготовка обучающихся к усвоению нового материала

3.

Изучение нового материала

4.

Проверка домашнего задания

5.

Первичная проверка усвоения знаний

6.

Первичное закрепление знаний

7.

Контроль и самопроверка знаний

8.

Информация о домашнем задании

Описание урока:

Этапы урока

Цели этапа

Содержание обучения

Организация процесса

обучения

(методы, организационные

формы, средства)

Орг. момент

(1-2 мин.)

Создание условия для

возникновения у

обучающихся внутренней

потребности включения в

учебную деятельность,

способствовать повышению

мотивации учения.

Приветствие. Настрой студентов

на работу. Отмечаем

отсутствующих. Определение

целей урока.

Форма: фронтальная.

Подготовка

обучающихся к

усвоению нового

материала

(5-10 мин.)

Актуализация, обобщение и

закрепление знаний,

необходимых на занятии,

стимулировать активность и

инициативу обучающихся при

опросе.

Повторение необходимых

определений..

Метод: беседа, дискуссия.

Форма: фронтальная.

Средства: Проектор,

мультимедиа презентация.

Изучение нового

материала

(5 мин.)

Систематизировать знания,

полученные студентами при

самостоятельном чтении

лекции дома.

Объяснение нового материала.

Метод: рассказ.

Форма: фронтальная.

Средства: Проектор.

Проверка

домашнего

задания

(60 мин.)

.Определить степень

изучаемым владения

материалом

Выступления студентов по темам

индивидуальных заданий

Метод: доклад, беседа

Средства: Проектор,

мультимедиа презентация.

Первичная

проверка усвоения

знаний

(5 мин.)

Установление правильности,

осознанности и полноты

владения материалом

Ответы на вопросы

Форма: беседа

Первичное

закрепление

знаний

Научить обоснованно

выбирать модель жизненного

цикла ПО

Самостоятельная работа

Индивидуальная

Контроль и

самопроверка

знаний

Установление правильности,

осознанности и полноты

владения материалом

Защита выполненного тзадания

Дискуссия

Домашнее задание

(1 мин.)

На основе выявленных

результатов усвоения умений

и навыков дать домашнее

задание, которое было бы

направлено на дальнейшее

развитие.

Сообщить домашнее задание,

проинструктировать учащихся о

его выполнении.

Фронтальная форма.

Итог

(1-2 мин.)

Подвести итог урока,

выставить оценки учащимся.

Подведение итогов, выставление

оценок.

Форма: фронтальная.

Ход урока

1.

Орг. Момент

- В прошлом году на некоторых дисциплинах вы уже сталкивались с

понятием жизненного цикла ПО, модели жизненного цикла. Сегодня мы

соберём эту информацию воедино.

2.

Подготовка обучающихся к усвоению нового материала

- Вспомним определения

Информационная система…

Жизненный цикл …

Модель жизненного цикла…

3.

Изучение нового материала

(текст лекции есть в электронном курсе и выдан студентам на

предыдущем уроке)

Понятие жизненного цикла ПО

Ранее мы говорили о том, что сложную программную систему построить

"простыми" методами невозможно. Ее разработка с неизбежностью будет

тоже сложной деятельностью.

Привести такое предприятие к успеху возможно на основе общих принципов

работы со сложными системами: организовав его в виде набора модулей,

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

разных

местах

так,

чтобы

изменения

в

таком

элементе

автоматически

отражались всюду, где он используется.

Разработка ПО — разновидность человеческой деятельности. Выделить ее

компоненты

можно,

определив

набор

задач,

которые

нужно

решить

для

достижения конечной цели — построения достаточно качественной системы

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

организуется

вспомогательная деятельность,

к

которой

можно

также

применить декомпозицию на отдельные, более мелкие деятельности, и т.д. В

итоге должно стать понятно, как решать каждую отдельную подзадачу и всю

задачу целиком на основе имеющихся решений для подзадач.

В

качестве

примеров

деятельностей,

которые

нужно

проводить

для

построения

программной

системы,

можно

привести проектирование —

выделение отдельных модулей и определение связей между ними с целью

минимизации зависимостей между частями проекта и достижения лучшей

его

обозримости

в

целом, кодирование —

разработку

кода

отдельных

модулей, разработку пользовательской документации, которая необходима

для достаточно сложной системы.

Однако

для

корректного

с

точки

зрения

инженерии

и

экономики

рассмотрения вопросов создания сложных систем необходимо, чтобы были

затронуты и вопросы эксплуатации системы, внесения в нее изменений, а

также самые первые действия в ходе ее создания — анализ потребностей

пользователей

и

выработка

решений,

"изобретение"

функций,

удовлетворяющих эти потребности. Без этого невозможно, с одной стороны,

учесть реальную эффективность системы в виде отношения полученных

результатов ко всем сделанным затратам и, с другой стороны, правильно

оценивать в ходе разработки степень соответствия системы реальным нуждам

пользователей и заказчиков.

Все эти факторы приводят к необходимости рассмотрения всей совокупности

деятельностей,

связанных

с

созданием

и

использованием ПО,

начиная

с

возникновения идеи о новом продукте и заканчивая удалением его последней

копии.

Весь

период

существования ПО,

связанный

с

подготовкой

к

его

разработке, разработкой, использованием и модификациями, начиная с того

момента,

когда

принимается

решение

разработать/приобрести/собрать

из

имеющихся

компонентов

новую

систему

или

приходит

сама

идея

о

необходимости

программы

определенного

рода,

до

того

момента,

когда

полностью

прекращается

всякое

ее

использование,

называют жизненным

циклом ПО.

В ходе жизненного цикла ПО проходит через анализ предметной области,

с бор

т ребований,

про ектирование, кодирование,

т е с т и р о в а н и е ,

сопровождение и другие виды деятельности. Каждый вид представляет собой

достаточно однородный набор действий, выполняемых для решения одной

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

эксплуатации ПО.

При

этом

создаются

и

перерабатываются

различного

рода артефакты —

создаваемые человеком информационные сущности, документы в достаточно

общем смысле, участвующие в качестве входных данных и получающиеся в

качестве

результатов

различных

деятельностей.

Примерами

артефактов

являются:

модель предметной

области,

описание

требований, техническое

задание, архитектура системы, проектная документация на систему в целом и

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

код, пользовательская документация, документация администратора системы,

руководство по развертыванию,

база

пользовательских

запросов,

план

проекта и пр.

На

различных

этапах

в

создание

и

эксплуатацию ПО вовлекаются

люди,

выполняющие различные роли.

Каждая роль может

быть

охарактеризована

как

абстрактная группа заинтере сованных

лиц,

участвующих

в

деятельности по созданию и эксплуатации системы и решающих одни и те же

задачи

или

имеющих

одни

и

те

же

интересы по отношению

к

ней.

Примерами ролей я в л я ю т с я :

б и з н е с - а н а л и т и к ,

инженер потребованиям, архитектор,

проектировщик

пользовательского

и н т е р ф е й с а ,

п р о г р а м м и с т - к о д и р о в щ и к ,

т е х н и ч е с к и й

писатель, тестировщик, руководитель проекта по разработке, работник отдела

п

р

о

д

а

ж , к о н е ч н ы й

п о л ь з о в а т е л ь, администратор системы,

инженер по поддержке и т.п.

Похоже,

что

общую

структуру жизненного

цикла любого ПО задать

невозможно,

поскольку

она

существенно

зависит

от

целей,

для

которых

это ПО разрабатывается

или

приобретается,

и

от

решаемых

им

задач.

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

форматирования кода, которая сначала делалась программистом для себя, а

впоследствии

была

признана

перспективной

в

качестве

продукта

и

переработана, и у комплексной системы автоматизации предприятия, которая

с самого начала задумывалась как таковая. Тем не менее, часто определяют

основные элементы структуры жизненного цикла в виде модели жизненного

цикла ПО.

Модель

жизненного

цикла

ПО выделяет

конкретные

наборы видов

деятельности (обычно

разбиваемых

на

еще

более

мелкие

активности),

а р т е ф а к т о в ,

р о л е й

и

и х

в з а и м о с в я з и ,

а

т а к ж е

д а е т

рекомендации по организации

процесса

в

целом.

Эти

рекомендации

включают ответы на вопросы о том, какие артефакты являются входными

данными

у

каких видов

деятельности,

а

какие

появляются

в

качестве

результатов, какие роли вовлечены в различные деятельности, как различные

деятельности связаны друг с другом, каковы критерии качества полученных

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

задачам проекта и когда можно переходить от одной деятельности к другой.

Ж и з н е н н ы й

ц и к л

П О я в л я е т с я

с о с т а в н о й

ч а с т ь ю

жизненного цикла п р о г р а м м н о - а п п а р ат н о й

с и с т е м ы ,

в

ко т о р у ю

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

связи с элементами жизненного цикла системы в целом.

Существует

набор

стандартов,

определяющих

различные

элементы

в

структуре жизненных

циклов

ПО и

программно-аппаратных

систем.

В

качестве основных таких элементов выделяют технологические процессы —

структурированные

наборы

деятельностей,

решающих

некоторую

общую

задачу

или

связанную

совокупность

задач,

такие

как

проце сс

сопровождения ПО, процесс

обеспечения качества,

процесс

разработки

документации и пр. Процессы могут определять разные этапы жизненного

цикла и

увязывать

их

с

различными видами

деятельностей,

артефактами

и ролями заинтересованных лиц.

Стоит отметить, что процессом (или технологическим процессом) называют

и

набор

процессов,

увязанных

для

совместного

решения

более

крупной

задачи, например, всей совокупности деятельностей, входящих в жизненный

цикл

ПО.

Таким

образом,

процессы

могут

разбиваться

на

подпроцессы,

решающие частные подзадачи той задачи, с которой работает общий процесс.

Стандарты жизненного цикла

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

обратимся

сначала

к

соответствующим

стандартам,

описывающим

технологические процессы. Международными организациями, такими как:



IEEE

—

читается

"ай-трипл-и",

Institute

of

Electrical

and Electronic

Engineers, Институт инженеров по электротехнике и электронике;



ISO — International Standards Organization, Международная организация

по стандартизации;



EIA —

Electronic

Industry

Association,

Ассоциация

электронной

промышленности;



IEC

—

International Electrotechnical Commission,

Международная

комиссия по электротехнике;

а

также

некоторыми

национальными

и

региональными

институтами

и

организациями

(в

основном,

американскими

и

европейскими,

поскольку

именно

они

оказывают

наибольшее

влияние

на

развитие

технологий

разработки ПО во всем мире):



ANSI

—

American

National

Standards

Institute,

Американский

национальный институт стандартов;



SEI —

Software

Engineering

Institute, Институт

программной

инженерии;



ECMA —

European

Computer

Manufactures Association,

Европейская

ассоциация производителей компьютерного оборудования;

разработ ан

набор

ст андартов,

регламентирующих

р а з л и ч н ы е

аспекты жизненного цикла и вовлеченных в него процессов. Список и общее

содержание этих стандартов представлены ниже.

Группа стандартов ISO



ISO/IEC 12207 Standard for Information Technology — Software Life

Cycle

Processes (процессы

жизненного

цикла

ПО,

есть

его

российский

аналог ГОСТ Р-1999).

Определяет общую структуру жизненного цикла ПО в виде 3 ступенчатой

модели,

состоящей

из

процессов, видов

деятельности и

задач.

Стандарт

описывает вводимые элементы в терминах их целей и результатов, тем

самым задавая неявно возможные взаимосвязи между ними, но не определяя

четко структуру этих связей, возможную организацию элементов в рамках

проекта и метрики, по которым можно было бы отслеживать ход работ и их

результативность.

Самыми крупными элементами являются процессы жизненного цикла ПО

(lifecycle processes). Всего выделено 18 процессов, которые объединены в 4

группы.

Таблица 2.1. Процессы жизненного цикла ПО по ISO 12207

Основные

процессы

Поддерживающие

процессы

Организационные

процессы

Адаптация

Приобретение

ПО;

Передача ПО (в

использование);

Разработка ПО;

Эксплуатация

ПО;

П о д д е р ж к а

П О

Документирование;

Управление

конфигурациями;

Обеспечение

качества;

Верификация;

Валидация;

Совместные

экспертизы;

Аудит;

Разрешение

Управление

проектом;

Управление

инфраструктурой;

Усовершенствование

процессов;

Управление

персоналом

Адаптация

описываемых

стандартом

процессов

под

нужды

конкретного

проекта

проблем

Процессы строятся из отдельных видов деятельности (activities).

Стандартом определены 74 вида деятельности, связанной с разработкой и

поддержкой ПО. Ниже мы упомянем только некоторые из них.

o

Приобретение ПО включает такие деятельности, как инициация

приобретения,

подготовка

запроса

предложений,

подготовка

контракта,

анализ поставщиков, получение ПО и завершение приобретения.

o

Разработка

ПО

включает

развертывание процесса

разработки,

анализ

системных

требований,

проектирование

программно-аппаратной

системы в целом, анализ требований к ПО, проектирование архитектуры

ПО, детальное проектирование, кодирование и отладочное тестирование,

интеграцию

ПО,

квалификационное

тестирование

ПО,

системную

интеграцию,

квалификационное

тестирование

системы,

развертывание

(установку или инсталляцию) ПО, поддержку процесса получения ПО.

o

Поддержка

ПО

включает

развертывание

процесса

поддержки,

анализ

возникающих

проблем

и

необходимых

изменений,

внесение

изменений, экспертизу и передачу измененного ПО, перенос ПО с одной

платформы на другую, изъятие ПО из эксплуатации.

o

Управление проектом включает запуск проекта и определение его

рамок, планирование, выполнение проекта и надзор за его выполнением,

экспертизу и оценку проекта, свертывание проекта.

Каждый вид деятельности нацелен на решение одной или нескольких задач

(tasks). Всего определено 224 различные задачи. Например:

o

Развертывание п р о ц е с с а

р а з р а б о т к и с о с т о и т

и з

определения модели

жизненного

цикла,

документирования

и

контроля

результатов отдельных работ, выбора используемых стандартов, языков,

инструментов и пр.

o

Перенос ПО между платформами состоит из разработки плана

переноса, оповещения пользователей, выполнения анализа произведенных

действий и пр.

Современные стандарты стараются максимально общим образом определить

набор видов деятельности, которые должны быть представлены в рамках

жизненного цикла (с учетом целей отдельных проектов — т.е. проект, не

стремящийся достичь каких-то целей, может не включать деятельностей,

связанных с их достижением), и описать их при помощи наборов входных

документов и результатов.

Стоит

заметить,

что

стандарты

могут

достаточно

сильно

разойтись

с

реальной

разработкой,

если

в

ней

используются

новейшие

методы

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

и IEEE построены на основе имеющегося эмпирического опыта разработки,

полученного в рамках распространенных некоторое время назад парадигм и

инструментальных средств. Это не значит, что они устарели, поскольку их

авторы

имеют

достаточно

хорошее

представление

о

новых

методах

и

технологиях разработки и пытались смотреть вперед. Но при использовании

новаторских технологий в создании ПО часть требований стандарта может

обеспечиваться совершенно иными способами, чем это предусмотрено в нем,

а

часть

артефактов

может

отсутствовать

в

рамках

данной

технологии,

исчезнув внутри автоматизированных процессов.

4.

Проверка домашнего задания

Вам были даны индивидуальные задания. Расскажите о различных моделях

жизненного цикла, их преимуществах и недостатках.

Модели жизненного цикла

Все обсуждаемые стандарты так или иначе пытаются описать, как должен

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

слишком общие модели жизненного цикла ПО, которые тяжело использовать

при организации конкретного проекта.

В рамках специфических моделей жизненного цикла, которые предписывают

правила

организации

разработки ПО в

рамках

данной

отрасли

или

организации,

определяются

более

конкретные процессы

разработки.

Отличаются

они

от

стандартов,

прежде

всего,

большей

детальностью

и

четким

описанием

связей

между

отдельными видами

деятельности,

определением потоков данных (документов и артефактов) в ходе жизненного

цикла. Таких моделей довольно много, ведь фактически каждый раз, когда

некоторая

организация

определяет

собственный процесс

разработки,

в

качестве

основы

этого

процесса

разрабатывается

некоторая модель

жизненного

цикла

ПО.

В

рамках

данной

лекции

мы

рассмотрим

лишь

н е с ко л ь ко

м од е л е й .

К

с ож а л е н и ю ,

оч е н ь

т я ж е л о

в ы б р а т ь

критерии, по которым можно было бы дать хоть сколько-нибудь полезную

классификацию известных моделей жизненного цикла.

Наиболее широко известной и применяемой долгое время оставалась так

называемая каскадная или водопадная (waterfall) модель жизненного цикла,

которая,

как

считается,

была

впервые

четко

сформулирована

в

работе и

впоследствии запечатлена в стандартах министерства обороны США в 70-80-

х годах XX века. Эта модель предполагает последовательное выполнение

различных видов

деятельности,

начиная

с

выработки

требований

и

заканчивая сопровождением, с четким определением границ между этапами,

на которых набор документов, созданный на предыдущей стадии, передается

в качестве входных данных для следующей. Таким образом, каждый вид

деятельности выполняется

на

какой-то

одной

фазе жизненного

цикла.

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

2.2.

"Классическая" каскадная

модель предполагает

только

движение

вперед по этой

схеме:

все

необходимое

для

проведения

очередной

деятельности должно быть подготовлено в ходе предшествующих работ.

Рис. 2.2. Последовательность разработки согласно "классической" каскадной

модели

Однако,

если

внимательно

прочитать

статью,

оказывается,

что

она

не

предписывает

следование

именно

этому

порядку работ,

а,

с ко р е е ,

представляет

модель

итеративного

процесса

(см. рис.2.3)

—

в

е е

последовательном

виде

эта

модель

закрепилась, по-видимому,

в

представлении

чиновников

из

министерств

и

управленцев

компаний,

работающих с этими министерствами по контрактам. При реальной работе в

соответствии с моделью, допускающей движение только в одну сторону,

обычно

возникают

проблемы

при

обнаружении

недоработок

и

ошибок,

сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями

окружения,

в

котором

разрабатывается ПО (это

могут

быть

изменения

требований, смена подрядчиков, изменения политик разрабатывающей или

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

конкурирующих продуктов и пр.).

Работать

в

соответствии

с

этой

моделью

можно,

только

если

удается

предвидеть заранее возможные перипетии хода проекта и тщательно собирать

и интегрировать информацию на первых этапах, с тем чтобы впоследствии

можно

было

пользоваться

их

результатами

без

оглядки

на

возможные

изменения.

Рис. 2.3. Ход разработки, предлагаемый в статье

Среди

разработчиков

и

исследователей,

имевших

дело

с

разработкой

сложного ПО,

практически

с

самого

зарождения

индустрии

производства

программ

(см.,

например, [17])

большую

популярность

имели

модели

эволюционных

или

итеративных

процессов,

поскольку

они

обладают

большей гибкостью и способностью работать в меняющемся окружении.

Итеративные или инкрементальные

модели (известно

несколько

таких

моделей)

предполагают разбиение создаваемой

системы

на

набор

кусков,

которые

разрабатываются

с

помощью

нескольких

последовательных

проходов всех работ или их части.

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

При этом большая часть или даже полный цикл работ проходится на нем,

затем оцениваются результаты и на следующей итерации либо первый кусок

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

от первого, либо как-то совмещается доработка первого куска с добавлением

новых функций. В результате на каждой итерации можно анализировать

промежуточные результаты работ и реакцию на них всех заинтересованных

лиц,

включая

пользователей,

и

вносить

корректирующие

изменения

на

следующих

итерациях.

Каждая итерация может

содержать

полный

набор видов деятельности — от анализа требований до ввода в эксплуатацию

очередной части ПО.

Рис. 2.4. Возможный ход работ по итеративной модели

Каскадная модель с возможностью возвращения на предшествующий шаг

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

Итеративный

процесс

предполагает,

что

разные виды

деятельности не

привязаны

намертво

к

определенным

эт апам

разработки,

а

выполняются по мере необходимости, иногда повторяются, до тех пор, пока

не будет получен нужный результат.

Вместе

с

гибкостью

и

возможностью

быстро

реагировать

на

изменения, итеративные

модели привносят

дополнительные

сложности

в управление

проектом и

отслеживание

его

хода.

При

использовании

итеративного подхода значительно сложнее становится адекватно оценить

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

также

предсказать

сроки

и

ресурсы,

необходимые

для

обеспечения

определенного качества результата.

Р а з в и т и е м

и д е и

и т е р а ц и й

я в л я е т с я спиральная модель

жизненного цикла ПО,

предложенная

Боэмом

(Boehm).

Она

предлагает

каждую итерацию начинать с выделения целей и планирования очередной

итерации,

определения

основных

альтернатив

и

ограничений

при

ее

выполнении, их оценки, а также оценки возникающих рисков и определения

способов избавления от них, а заканчивать итерацию оценкой результатов

проведенных в ее рамках работ.

Основным

ее

новым

элементом

является

общая

структура

действий

на

каждой

итерации

—

планирование, определение задач,

ограничений

и

вариантов решений, оценка предложенных решений и рисков, выполнение

основных работ итерации и оценка их результатов.

Название " спиральная " эта модель получила из-за изображения хода работ в

"полярных координатах", в которых угол соответствует выполняемому этапу

в рамках общей структуры итераций, а удаление от начала координат —

затраченным ресурсам.

Рис. 2.5. Изображение хода работ по спиральной модели согласно Боему

Рис.

2.5 показывает

возможное

развитие

проекта по спиральной

модели.

Количество

витков,

а

также

расположение

и

набор видов

деятельности в

правом нижнем квадранте могут изменяться в зависимости от результатов

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

5.

Первичная проверка усвоения знаний

-Какие процессы жизненного цикла выделяются ПО по ISO 12207?

- Какие виды деятельности входят в каждый процесс?

- Назовите преимущества каскадной модели жизненного цикла.

-Назовите преимущества спиральной модели.

6.

Первичное закрепление знаний

Напишите, по какой модели ЖЦ нужно разрабатывать следующие

системы:

-система управления самолётом;

- система бухгалтерского учёта;

- система продажи билетов на междугородние автобусы;

-система для классного руководителя;

Обоснуйте свой выбор.

7.

Контроль и самопроверка знаний

- Обсудим ваши варианты

Оценки за урок…..

8.

Информация о домашнем задании

1.

Выучить материал лекции.

2.

Прочитать дополнительный материал по этой теме (находится в

сетевой папке)

3.

Прочитать материал лекции № 5