Конспект лекционных занятий
Тема 1.Стандарты - дисциплины и процесса разработки.(4 час.)
Лекция 1. Вводная. Порядок разработки и требования к содержанию и документам разработки программ.
Введение. Методика ведения записей и выполнения работ по дисциплине. Афоризмы: Конфуций. Слушаю – забываю. Вижу – запоминаю. Делаю – понимаю.
А. Анастази. Научить нельзя. Можно только научиться.
Р. Бэндлер. Существует иллюзия, что люди понимают друг друга, если они произносят одни и те же слова. Но поскольку внутренне эти слова обеспечивают доступ к различным элементам опыта, смысл всегда будет различен… Я думаю Вам крайне полезно вести себя так, чтобы у ваших клиентов возникала иллюзия будто Вы понимаете что они говорят. Я хочу предостеречь Вас самих от этой иллюзии.
ПРАВИЛА СТРАТЕГИИ ОБУЧЕНИЯ
1. Пpи изучении матеpиала ищи смысл- Для наиболее эффективного использования памяти обучающийся должен активновыделять смысловую стоpонутого матеpиала, котоpый он изучает. Так еще, обучающийся должен не только пассивно кодиpовать поступающую инфоpмацию, но и активноискать сложные связив матеpиале и перестpуктуриpовать его.
2.Используй стpатегии минимизиpующие обьем запоминаемого матеpиала -Повтоpное воспpоизведение только того матеpиала, котоpый нужно запомнить (без избыточных данных по каналу пpиема инфоpмации).Укpупнениеединиц инфоpмации.
3. Изучай, изучай, изучай.- Нет пpеделаглубине изучения инфоpмации.
4. Избегай отвлечения на постоpонние детали. Если в матеpиале есть сообщения подpобностей не относящиеся пpямо к делу, то тpудно опpеделить, что является главным, а что втоpостепенным. Очень эффективноанализиpовать кpаткое содеpжаниетемы.
5. Отводи вpемя для свободного воспpоизведения. Если пpоизошел сбой пpи вспоминании, следует пpосмотpетьассоциативные связи, мысленно пpоанализиpовав, какие факты могли иметь отношение к искомому следу в памяти (Где я был? Какой это был день недели? Кто мне это сказал? и т.д.).
6. Используй кpаткое содеpжание. Когда вы анализиpуете кpаткое содеpжание, думайте, что в нем отpажено и что опущено. На основе этого анализа попытайтесьсфоpмулиpовать вопpосы, котоpые помогут вам пpи чтении текста.
7. Используй метод повтоpного цитиpования (для самопpовеpки). Повтоpноцитиpуйтекак можно большее числофактовиз того матеpиала, котоpый вы только что пpочитали.
8. Делай пеpеpывы в тpениpовке. Если 14 часов тpениpовки pастянуть на неделю (7 дн. по 2 часа), то овладение навыком будет более глубоким, чем 14 часов тpениpовки в один день. В один день pекомендуется2 часатpатить наодин пpедмет, следующие 2 часа на дpугой и т.д.
9. Начинай обучение по частям. Интенсивноизучать и повтоpятьна пpактике 1 или 2 составляющие навыка, после чего еще 1 или 2 составляющие. Это лучше, чем сначала теоpетически изучать все методы, потом пpактиковаться, а уж затем пеpеходить к смешанному способу научения.
10. Тщательно изучи составляющие навыка. Тщательноотpаботатьосновы(освоение пpостейших пpиемов) и толькопотом пытаться, напpимеp, писатьсложные пpогpаммы со многими функциями. Полезновозвpащаться к основамнавыка даже пpофессионалам.
11. Ищи хоpошие модели с теми же чеpтами, что и нужный навык. Напpимеp,изучение пpогpамм, написанныххоpошими пpогpаммистами, для освоения методики и стиля пpогpаммиpования.
12. Ищи способы узнать pезультаты.Обpатная связьдолжна обеспечивать обучающемуся немедленную инфоpмацию о pезультатах, пока еще свежи в памяти контекст и подход к pешению данной задачи.
13. Концентpиpуй внимание на изучаемом матеpиале.Избегайте помехпpоцессам научения (pадио, телевидение).
14. Расслабься и создай хоpошее настpоение. Поддеpживайтехоpошее настpоениес помощью вызова пpедставлений, имеющих положительную окpаску.»
При записи лекций необходимо: 1) Проставлять номер лекции и дату - на полях. 2) Страница записи вертикально разбивается на левую и правую части. В левой части конспектируется лекция. В правой – результаты самостоятельной работы над темой лекции, в т.ч. вопросы к лектору для прояснения на следующей лекции или СРСП. Определения, заголовки, подзаголовки и т.п. должны быть выделены в тексте записей подчеркиванием, шрифтом, окаймлением и т.п.
Разберем понятия, составляющие название дисциплины – инструмент, разработка, программа.
Определение понятий: программа, уровни и категории (направления) программирования, инструмент и разработка программ. Инструменты,средства для выполнения работ, т.е.разработки и реализации программ делятся на аппаратные и программные. Аппаратные – микропроцессор и подключаемые (внешние) устройства. Программные – программы, позволяющие выполнить все работы, определенные методологией проектирования. Предлагаемая к изучению дисциплина ориентирована на программные инструментальные средства, используемые для разработки и установки программ на компьютер. Разработка программного продукта (ПП) представляет множество связанных фрагментарных действий - таких как:
- создание модели данных и методики вычислений;
- описание функциональности, обеспечивающей вычисления;
- определение структуры данных – модели представления в компьютере и в алгоритме;
- определение и описание способа реализации задачи (алгоритма решения и тестов);
- определение и описание интерфейса пользователя;
- определение средств поддержки ПП;
- спецификация задачи;
- написание текста программы, включая программы тестирования;
- трансляция и отладка, тестирование программы;
- связывание и подключение библиотек поддержки;
- создание среды выполнения; размещения исходного модуля и загрузка;
- создание встроенной помощи и документирование разработки;
- создание устанавливаемого (инсталляционного) пакета ПП.
В рамках RationalUnifiedProcess(RUP) набор действий по разработке программ сконцентрирован в следующих этапах:- определение требований; - проектирование; - программирование; - тестирование; - внедрение.
Для выполнения указанных работ разработан и постоянно пополняется огромный набор программ - инструментов, позволяющих формализовать и автоматизировать процесс разработки программ. Использование этих средств существенно сокращает сроки разработки и внедрения программных продуктов.
Программадля компьютера – предписание поведения, нарисованное - написанное или построенное - на языке программирования.Язык программирования выбирается с целью обеспечить эффективное, надежное, быстрое, экономное проектирование и реализацию поставленной задачи.
Уровень языка – уровень программирования.Низкоуровневоепрограммирование – программирование с использованием команд и форматов данных микропроцессора в кодовой или мнемонической форме (ассемблер).Проблемно- ориентированное (алгоритмическое) программирование (текстуальное) – программирование с использованием команд, функций, форматов данных проблемно-ориентированных языков.Визуальноепрограммирование – программирование с использованием команд, компонент, форматов данных, определенных в визуальных средствах разработки программ.Объектное или компонентноепрограммирование предполагает использование различных конструктивов в качестве единичных элементов программ.
Командное (атомарное), структурное, модульное программирование– категории, определяемые типом языковых конструкций, используемых при разработке программ.Проблемная область,для которой строится программа, определяетнаправление программирования– научное, для задач бизнеса, для управления объектами и процессами, для управления и представления информации, для общения в Интернет, для общения с хранилищами данных и т.п.
Концепция структурного программирования.
«Структурное программирование - методологияпрограммирования, основанная на системном подходе к анализу, проектированию и реализации ПО. Появилась в начале 70-х годов и оказалась настолько жизнеспособной, что интенсивно используется и сегодня. Основу технологии составляют следующие положения:
Сложная задача разбивается на более мелкие, функционально лучше управляемые задачи. Каждая задача имеет один вход и один выход. В этом случае управляющий поток программы состоит из совокупности элементарных подзадач с ясным функциональным назначением.
Простота и атомарность управляющих структур, используемых в задаче. Это означает, что логически задача должна состоять из минимальной, функционально полной совокупности достаточно простых управляющих структур.
Разработка программы ведется поэтапно. На каждом этапе должно решаться ограниченное число четко поставленных задач с ясным пониманием их значения и роли в контексте всей задачи. Если такое понимание не достигнуто,это говорит о том, что данный этап слишком велик и его нужно разделить на более элементарные шаги.
Концепция модульного программирования.
Так же как и для структурной технологии, концепцию модульного программирования можно сформулировать в виде нескольких понятий и положений:
Функциональная декомпозиция задачи - разбиение большой задачи на ряд более мелких, функционально самостоятельных подзадач - модулей. Модули связаны между собой только по входным и выходным данным.
Модуль - основа концепции модульного программирования. Каждый модуль в функциональной декомпозиции представляет собой "черный ящик" с одним входом и одним выходам. Модульный подход позволяет безболезненно производить модернизацию программы в процессе ее эксплуатации и облегчает ее сопровождение. Дополнительно модульный подход позволяет разрабатывать части программ одного проекта на разных языках программирования, после чего с помощью компоновочных средств объединять их в единый загрузочный модуль.
Реализуемые решения должны быть простыми и ясными. Если назначение модуля непонятно, то это говорит о том, что декомпозиция начальной или промежуточной задачи была проведена недостаточно качественно. В этом случае необходимо еще раз проанализировать задачу и, возможно, провести дополнительное разбиение на подзадачи. При наличии сложных мест в проекте их нужно подробнее документировать с помощью продуманной системы комментариев. Этот процесс нужно продолжать до тех пор, пока вы действительно не добьетесь ясного понимания назначения всех модулей задачи и их оптимального сочетания.
Назначение всех переменных модуля должно быть описано с помощью комментариев по мере их определения.
Объектно-ориентированная парадигма.
Идея ООП заключается в стремлении связать данные с обрабатывающими эти данные процедурами в единое целое - объект. ООП основано на трех важнейших принципах, придающих объектам новые свойства. Этими принципами являются инкапсуляция, наследование и полиморфизм.
Инкапсуляция- объединение в одно целое данных и алгоритмов обработки этих данных. В рамках ООП данные - поля объекта, алгоритмы - объектные методы. Поля и алгоритмы м.б. доступны извне, - общие, внешние или только внутри объекта – приватные, внутренние или группы связанных объектов – защищенные.
Наследование- свойство объектов порождать своих потомков и наделять их своими возможностями по умолчанию. Объект - потомок, может дополнять эти возможности собственными или заменять (перекрывать) их.
Полиморфизм- свойство родственных объектов (т.е. объектов, имеющих одного общего родителя) решать схожие по смыслу проблемы разными способами в зависимости от места и времени использования.»
Инструмент разработкипрограмм определяется на основе выбранного уровня, направления, категории разработки и носит текстуальный или визуальный характер.Современное программирование – компонентное (объектное), событийное и визуальное.(Определить понятия.)
Разработка программ ведется в соответствии со стандартами – республиканскими и международными, по типовым или предлагаемым разработчиком технологиям и методикам.
Классификация инструментальных средств. По месту в процессе разработки и реализации, по временному принципу, по применяемым технологиям и методикам, по качеству продукта и т.п.
Предмет и задачи дисциплины. См. силлабус.
Роль и место инструментальных средств в процедуре разработки программ. Каждый этап разработки программы имеет свой набор инструментов. В силлабусе перечислены все шаги разработки. Каждый шаг определяется результатом разработки – основным документом, и вспомогательными документами, обеспечивающими закрытие этапа. Инструмент, соответственно, является основным или вспомогательным.
Характеристики качества и использования инструментария. Пространственные, временные, устойчивые, надежные, современные, интуитивно понятные, визуальные, статические и динамические, обеспечивающие изменяемость и настройку разработки, по характеристикам результата, соответствующие стандартам и технологиям, по избыточности целей и т. п.
Краткий исторический обзор развития инструментальных систем. Этапы 1960 – 1975 – 1985 – 2000 - 2005 годов. Языки, компиляторы, компоновщики, построители, загрузчики, операционные системы, средства разработки и тестирования, средства внедрения и поддержки программ – назначение, порядок использования, функциональный и структурный (конструктивы) состав. Схема развития языков программирования за последние 20 лет.
Основная литература: 3[12-24]
Контрольные вопросы:
Что такое программа?
Что такое инструменты?
Назовите уровни и категории программирования?
Лекция 2.Документы международного и государственного. стандарта, определяющие состав разработки.RUP.
Методы проектирования и обеспечение жизненного цикла программ.Командное (групповое) и индивидуальное проектирование, необходимые инструменты. Текстуальное и визуальное проектирование – технологии и методики, инструменты. Стандарт 12207 – Процессы жизненного цикла программных систем (ЖЦ ПС). Определяет процессы, работы, задачи. Кому предназначен. Адаптация к конкретике и ограничения. Нормативные ссылки. Определения. Прикладное применение стандарта – 5 основных (заказ, поставка, разработка, эксплуатация, сопровождение), 8 вспомогательных (документирование, управление конфигурациями, обеспечение качества, верификация, аттестации, совместный анализ, аудит, решение проблем), 4 организационных (создание инфраструктуры, управление,усовершенствование, обучение) процесса. Программа разработки – анализ требований, проектирование, программирование, сборка, тестирование, ввод в действие, приемка. Список работ на этапах. Содержание работ на этапах по стандарту. Инструменты.
Современные инструментальные средства.Визуализация всех этапов разработки и базовые технологии визуализации. Основы визуальных технологий. Библиотеки компонент, объектов, средств разработки. Разработки фирм по производству инструментов. Интерфейсная составляющая разработок. Возрастающая роль интерфейса Стандарты интерфейса. Состав современного визуального инструментария. Разнообразие и единство подходов к проектированию состава инструментов разработки программ.
Технология RUP, ее фазы и документы разработки, инструментарий. Rational Unified Process «На сегодняшний день это одна из самых известных методологий. Разработана компанией Rational Software для поддержки своих продуктов, которых насчитывается более десятка (среди самых знаменитых - Rational Rose и Requisite Pro). RUP создан тремя небезызвестными личностями - это Гради Буч, Ивар Якобсон и Джеймс Рамбо (Rumbaugh). Все они имеют огромный опыт разработки сложного программного обеспечения, что нашло отражение в RUP. Итеративность RUP, как и любой современный продвинутый процесс, является итеративным. Это значит, что создание проекта происходит за несколько итераций. В конце каждой итерации получается работающая версия продукта, но с неполным функционалом. В последующих итерациях функционал дорабатывается и в конце последней получается полностью готовый продукт. Идею итеративного процесса можно показать следующим образом (см. рис.1).
|
|
|
|
Рис. 1. Каждый виток спирали - итерация. Т.о. система постепенно обрастает функционалом. | |
У итеративной разработки много плюсов. Большое количество релизов сильно влияет на качество конечного продукта, который тестируется в каждой итерации. Уже на ранних стадиях можно проверить ожидания пользователей и внести изменения в продукт, если требуется. Кроме того, планировать проект гораздо проще, потому что уже после первой итерации все становится более предсказуемым, и управляющий проектом сможет с большей достоверностью прогнозировать реальные сроки окончания следующих итераций. Надо сказать, что в RUP прямо не сказано о корректной итеративности процесса. Так что RUP можно успешно использовать и для водопадного процесса, где все стадии следуют строго друг за другом и готовый продукт выходит в самом конце. Поэтому при настройке RUP надо обязательно обратить внимание на итеративность и внедрить ее корректно. Сценарии пользователей. Сценарий пользователя (Use Case) - это описание последовательности действий пользователя при выполнении определенной операции. Например, можно написать сценарий пользователя для открытия нового документа и т.п. RUP управляется сценариями пользователей (или прецедентами). Сценарии пользователей позволяют более точно представить разработчикам, что должна делать система и как именно она должна это делать. Сценарии пользователя являются частью функциональной спецификации системы. Вообще такие сценарии крайне полезны при разработке программы, потому что они:
понятны заказчику и служат как бы общим языком и главным связующим звеном между заказчиком и разработчиком;
помогают на ранней стадии выявить многие ошибки в логике работы программы;
помогают более четко определить требования заказчика к программе;
служат базой для разработки интерфейса и для написания тестовых сценариев.
В RUP сценариям пользователей отведено почетное место, процесс является use-case driven, то есть управляемый сценариями пользователей. Структура RUP Процесс имеет четыре фазы:1.Исследование (Inception) 2.Уточнение плана (Elaboration) 3.Построение (Construction) 4.Развертывание (Transition). На каждой из фаз основное внимание уделяется разным процессам. На фазе исследования идет сбор и анализ требований, на фазе уточнения плана - анализ требований и проектирование системы, на фазе построения - разработка и кодирование, на фазе развертывания - тестирование и распространение. Методология RUP основана на 9 основных потоках: 1)Бизнес-анализ (анализ потребностей); 2) Сбор требований и управление требованиями (перевод требований в функциональные спецификации); 3) Анализ и моделирование (перевод требований в программную модель); 4)Кодирование; 5)Тестирование (проверка того, что программа соответствует требованиям); 6) Управление конфигурацией и изменениями (отслеживание изменений в разных версиях продукта); 7)Управление проектом ; 8) Создание и поддержка среды разработки; 9) Развертывание (все что нужно для продажи или передачи продукта). Любой проект в RUP проходит четыре фазы. Через эти фазы проходят и все девять потоков. Каждая фаза, в свою очередь, разбивается на итерации. Если взять, например, первую итерацию на фазе "Исследования", то основное внимание на этой итерации уделяется бизнес-анализу, сбору требований и моделированию, но кодирование тоже есть. Если взять одну из последних итераций на фазе "Построения", то основное внимание уделяется кодированию, тестированию и управлению конфигурацией. Иными словами, по мере развития проекта в каждой итерации смещаются акценты. Это и правильно, ближе к концу особо анализировать нечего, а требования собирать как-то поздно. Артефактом (Artefact) называется продукт, который создается и используется в процессе разработки ПО. Например, артефактами являются документы, модели, исходный код. Примеры артефактов: руководство пользователя, диаграмма классов в UML и т.п. Неотъемлемую часть RUP составляют артефакты и роли. При разработке программы создаются разные артефакты, и за создание того или иного артефакта отвечает определенная роль. Например, диаграмму классов создает "Архитектор", а сценарии тестирования пишет "Дизайнер тестов". Все визуальное моделирование осуществляется с помощью CASE-средств. Основой для него служит язык UML (Unified Modeling Language), что не удивительно, потому что UML разрабатывался авторами RUP. Лучшие практики Сама RUP основывается на шести лучших практиках (best practices):
Итеративная разработка
Управление требованиями
Использование модульных архитектур
Визуальное моделирование
Проверка качества
Отслеживание изменений
Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса.
Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки, кроме того, в итоге продукт получается более качественным, потому что база тестируется столько раз, сколько итераций проходит продукт.
Управление требованиями - один из важнейших процессов при разработке более-менее серьезных продуктов. Благодаря ему продукт более точно соответствует ожиданиям заказчика. Инструментальная поддержка обеспечивается Requisite Pro.
В теории модульная архитектура позволяет повторно использовать код, и система получается более гибкой. На практике это практически невозможно реализовать.
Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом работает система, что она делает и как она это делает. Кроме того, модели являются средствами коммуникаций между разработчиками, но для этого они должны быть понятны каждому. Вот для этого в RUP используется UML, который позволяет разработчикам говорить на одном языке. Инструментальная поддержка обеспечивается Rational Rose.
Качество продукта - одна из важнейших его характеристик. Заявляется, что RUP ориентирован на достижение приемлемого уровня качества, однако в процессе адаптации этой методологии с качеством могут возникать проблемы, если адаптация будет не совсем удачной. Инструментальная поддержка обеспечивается целым рядом программ: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot.
Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика либо на изменяющиеся условия внешней среды. RUP имеет процессы, которые позволяют эффективно отслеживать изменения. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest.
Настройка RUP RUP является адаптируемым процессом, то есть его можно настраивать под нужды конкретной команды и под конкретный проект. Более того, это делать совершенно необходимо, поскольку в противном случае эффективность использования RUP будет стремиться к нулю. В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов. Естественно, что если команда состоит из 5 человек, то просто нет смысла вводить все эти роли и создавать все артефакты. Вообще чем меньше команда, тем легче должен быть процесс. То есть надо создавать минимум артефактов и вводить минимум ролей.
Так вот RUP позволяет настроить процесс. Из общего описания RUP можно взять только те процессы, роли и артефакты, которые действительно нужны команде для разработки качественного продукта в срок и в пределах бюджета. Например, возьмем управление требованиями. В общем описании RUP присутствуют следующие артефакты: план управления требованиями, модель сценариев пользователей, спецификация требований системы, видение, репозиторий требований. Для маленького проекта вполне достаточно спецификации требований и набора отдельных сценариев. Но для крупного проекта совершенно необходим репозиторий, потому что без него отслеживание и изменение требований превратится в головную боль системного аналитика. Однако настройка RUP под конкретный проект - нетривиальная задача. Если решать ее будет тот, кто до этого внедрением RUP не занимался, есть риск получить на выходе совершенно неподходящий процесс, состоящий из бестолкового нагромождения артефактов, потоков и ролей, на которые тяжелым грузом лягут продукты Rational Software. Вообще считается, что RUP достаточно тяжелая методология, которая лучше подходит для больших команд. Одной из попыток облегчить RUP является методология dX. Методология Rational Unified Process (RUP) включает следующие процессы (Workflows):
бизнес-моделирование;
управление требованиями;
анализ и проектирование;
реализацию;
тестирование;
развертывание;
управление конфигурациями и изменениями;
управление проектом;
инструментальную поддержку.
RUP — итерационная методология. Итерационный подход позволяет добиться лучшего понимания задачи посредством последовательного уточнения и найти эффективное решение в ходе ряда итераций. Организация итераций возможна только при тщательном управлении требованиями и контроле за изменениями. RUP основан на разработке и поддержке моделей, а не на создании бумажных документов — вследствие семантической содержательности представления разрабатываемой системы в моделях.
На ранних этапах разработки RUP предписывает выбор и фиксацию архитектуры системы. Это позволяет организовать параллельную разработку проекта, минимизировать переделки, обеспечить повторное использование компонентов и облегчить сопровождение. Выбранная архитектура используется для планирования разработки программных компонентов. Разработка продукта осуществляется на основе определения сценариев использования системы (Use cases). Сценарии направляют весь процесс жизненного цикла (бизнес-моделирование, выработка требований, анализ и проектирование, тестирование) и обеспечивают согласованность выполняемых задач при разработке и развертывании системы.
RUP поддерживает объектно-ориентированную технологию. Многие визуальные модели являются объектно-ориентированными моделями, базирующимися на концепциях объектов, классов и отношений между ними. Общим языком при этом является Unified Modeling Language (UML).
RUP обеспечивает компонентную разработку системы. Компонентами считаются нетривиальные модули, подсистемы с заданной функциональностью, которые могут быть агрегированы в систему.
RUP ориентирован на контроль качества всех создаваемых в проекте материалов как залог качества создаваемой системы. Оценка качества встроена в процессы методологии.
RUP используется при создании сложных информационных систем (ИС) масштаба предприятия и поддерживается инструментальными средствами Rational Software, обеспечивающими командную работу над проектом.»
Международные и отечественные стандарты, используемые при разработке программных продуктов. Стандарт ИСО, определяющий качество разработки.
ИСО 4001-96. Системы качества. Модель обеспечения качества при проектировании.
ИСО МЭК 9126-93. ИТ. Оценка программной продукции. Характеристики качества и руководство по их применению. ИСО МЭК 8402-94. Управление качеством и обеспечение качества. Словарь. Стандарты 34.601-90, 34.603-92,ИСО4001-96 и др.
Реализация стандартов в инструментальных средствах.Набор заготовок визуальных элементов разработок. Возможности оперативной настройки состава библиотек элементов. Добавления отсутствующих стандартных элементов проектирования. Оперативность изменений.
Стандарты информационной безопасности.Р511.88-98. Защита информации. Испытание программных средств на наличие компьютерных вирусов. Р512.41- 98. Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний. Устойчивость защиты от несанкционированного доступа – значение кодовых комбинаций. Что должна обеспечить программа устройства управления доступом. Устойчивость программы к воздействиям.
Основная литература: 1осн. [7-57], 5 осн.[7-15];
Контрольные вопросы:
Какие основные ГОСТы определяют порядок и состав процесса разработки программ?
Как организовать процесс освоения дисциплины?
Этапы процесса разработки программ?
Какие требования к набору ключей доступа при повышенном уровне защиты?
Какие характеристики обеспечивают качество разработки?
Что такое артефакт в RUP?
Что такое программа?
Какие уровни и направления программирования Вам известны?
Что такое инструмент и какие инструменты используются в процессе разработки
программ?
Что такое утилита и какие утилиты Вам известны?
Как понимать слово TOOLSв меню ПП?