С е р и я в н у т р и в у з о в с к и х м е т о д и ч е с к и х у к а з а н и й С и б А Д И

Министерство науки и высшего образования Российской Федерации Федеральное государственное бюджетное образовательное учреждение

высшего образования «Сибирский государственный автомобильно-дорожный университет (СибАДИ)»

Кафедра «Прикладная информатика в экономике»

ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Методические указания к практическим, лабораторным

и контрольным работам

Составитель С.Ю.Пестова

Омск 2018

Рецензент

Доктор технических наук В.А Мещеряков (Проректор по информационным технологиям ФГБОУ ВО СибАДИ.)

Работа утверждена редакционно-издательским советом университета в

качестве методических указаний.

Т38 Технологии разработки программного обеспечения [Электронный ресурс] : методические указания к практическим, лабораторным и контрольным работам / сост. С.Ю.Пестова. – (Серия внутривузовских методических указаний СибАДИ). – Электрон. дан. – Омск : СибАДИ, 2018. – Режим доступа:…..……………………………………………….., свободный после авторизации. – Загл. с экрана.

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

Имеется интерактивное оглавление в виде закладок. Методические указания предназначены для обучающихся направления

магистратуры 09.04.01 «Информатика и вычислительная техника» и направления подготовки бакалавров 09.03.03 «Прикладная информатика». Также могут быть использованы как дополнительный учебный материал в различных информационных дисциплинах для формирования профессиональных компетенций.

Издание подготовлено на кафедре «Прикладная информатика в экономике».

Текстовое (символьное) издание

Системные требования: Intel, 3,4 GHz; 150 Мб; Windows XP/Vista/7; DVD-ROM; 1 Гб свободного места на жестком диске; программа для чтения pdf-файлов:

Adobe Acrobat Reader; Foxit Reader

Издание первое. Дата подписания к использованию 20.12.2018 Издательско-полиграфический комплекс СибАДИ. 644080, г. Омск, пр. Мира, 5

РИО ИПК СибАДИ. 644080, г. Омск, ул. 2-я Поселковая, 1

© ФГБОУ ВО «СибАДИ», 2018

УДК 004 ББК 32,97

Т38

_____________________________ Согласно 436-ФЗ от 29.12.2010 «О защите детей от информации, причиняющей вред их здоровью и развитию» данная продукция маркировке не подлежит. _____________________________

СОДЕРЖАНИЕ

ВВЕДЕНИЕ ............................................................................................................................... 3 1. ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ К ПРАКТИЧЕСКИМ РАБОТАМ И КОНТРОЛЬНЫМ ЗАДАНИЯМ ............................................................................................. 5 1.1. Основы разработки программного обеспечения ............................................................ 5 1.2. Методы разработки программного обеспечения ........................................................... 8 1.3. Проектирование программного обеспечения. .............................................................. 11 1.4. Документация по сопровождению программных средств .......................................... 13 1.5. Международные стандарты в сфере разработки программного обеспечения ......... 15 1.6. Тестирование, отладка и оценка качества программного обеспечения ..................... 17 3. ПРАКТИЧЕСКИЕ РАБОТЫ ............................................................................................. 19 3.1 Практическая работа №1 «Работа с CASE-средствами. Построение диаграмм потоков данных» .................................................................................................................... 19 3.2 Практическая работа №2 «Применение методов ООП. Разработка программного продукта с использованием объектно-ориентированного программирования» .............. 20 3.3 Практическая работа №3 «Технологии разработки технического задания» .............. 20 3.4 Практическая работа №4 «Стандартизация в области открытых систем» ................. 21 4. ТЕМЫ ДЛЯ ПОДГОТОВКИ К ИТОГОВОЙ ФОРМЕ КОНТРОЛЯ ............................ 21 5. КОМПЛЕКТ ЗАДАНИЙ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ ............................... 33 5.1 Самостоятельная работа № 1 по теме «Методы разработки программного обеспечения» .......................................................................................................................... 33 5.2 Самостоятельная работа № 2 по теме «Проектирование программного обеспечения» .......................................................................................................................... 34 5.3 Самостоятельная работа № 3 по теме «Документация по сопровождению программных средств» .......................................................................................................... 35 СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ ................................................................ 37 ПЕРЕЧЕНЬ РЕСУРСОВ СЕТИ «ИНТЕРНЕТ», РЕКОМЕНДУЕМЫХ ДЛЯ ОСВОЕНИЯ ДИСЦИПЛИНЫ ..................................................................................................................... 37

ВВЕДЕНИЕ В настоящее время существует достаточно много различных ме-

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

Для освоения дисциплины необходимы знания, полученные при изучении следующих дисциплин:

− «Распределенные информационные системы» − «Проектирование информационных систем с учетом про-

ектных рисков» Изучение дисциплины «Технологии разработки программного

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

− «Тестирование программного обеспечения» − «Высокопроизводительные вычисления и облачные серви-

сы» − «Производственная практика (по получению профессио-

нальных умений и опыта профессиональной деятельности (производ-ственно-технологическая))»

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

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

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

практик и написания выпускной квалификационной работы (маги-стерской диссертации).

В результате изучения дисциплины студент должен: − Знать: методики, языки и стандарты информационной под-

держки изделий (CALS-технологий) на различных этапах их жизнен-ного цикла.

− Умеет: использовать CASE-средства для решения проект-ных и технологических задач

− Владеет: методами, средствами проектирования и разра-ботки программных продуктов на основе CASE-средств

1. ТЕОРЕТИЧЕСКИЙ МАТЕРИАЛ К ПРАКТИЧЕСКИМ РАБОТАМ И КОНТРОЛЬНЫМ ЗАДАНИЯМ

1.1. Основы разработки программного обеспечения

Вопросы для рассмотрения: Основные определения:

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

Рекомендуемая литература: 1 Перечень дополнительных ресурсов: 2, 4, перечень ресурсов

в сети Интернет. Наименование вида самостоятельной работы: изучение

литературы и выполнение тестовых заданий. Технология разработки программного обеспечения(ПО) пред-

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

Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необхо-димости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

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

Методики, базирующиеся на каскадной модели, характеризу-ются тем, что переход на следующую стадию проектирования осуще-ствляется только после того, как будет завершена работа на текущей стадии. Возврат на предыдущие стадии не предполагается. Измене-ния, вносимые в проект, могут сильно повлиять на время и сроки про-ектирования. Обычные сроки реализации проект 6 - 12 месяцев. Такие методики применимы к простым программным системам, когда неоп-ределенность в проекте минимальна и изменений в процессе проекти-рования не предполагается, а используемые технологические решения

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

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

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

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

Методики, базирующиеся на каскадной модели, характеризу-ются тем, что переход на следующую стадию проектирования осуще-ствляется только после того, как будет завершена работа на текущей стадии. Возврат на предыдущие стадии не предполагается. Измене-ния, вносимые в проект, могут сильно повлиять на время и сроки про-ектирования. Обычные сроки реализации проект 6 - 12 месяцев. Такие методики применимы к простым программным системам, когда неоп-ределенность в проекте минимальна и изменений в процессе проекти-рования не предполагается, а используемые технологические решения проверены и хорошо известны членам команды.

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

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

Спиральная модель жизненного цикла ПО лежит в основе ме-тодологии создания ИТ-решений компании Microsoft - MSF(MicrosoftSolutionFramework). В данной методологии компания Microsoft отразила свое видение на процессы создания программных систем различного назначения.

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

К итеративным методам разработки ПО относится методоло-гия, созданная компанией RationalSoftware - RationalUnifiedProcess (RUP). Унифицированный процесс RUP определяет виды деятельно-сти, необходимые для проектирования программного продукта на ос-нове требований пользователя, которые могут изменяться в процессе разработки системы. Данный процесс может быть адаптирован для разработки различных программных систем.

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

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

− анализ требований к проекту; − проектирование; − реализация; − тестирование продукта; − внедрение и поддержка.

1.2. Методы разработки программного обеспечения

Вопросы для рассмотрения: Проект. Состав и структура

коллектива разработчиков, их функции. Нисходящий анализ процесса управления проектированием программного изделия. Восходящее проектирование. Метод последовательной модернизации. Блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы. Исполь-зование CASE-средств для создания программных комплексов и их компонентов.

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 1, 3, 4, перечень

ресурсов в сети Интернет. Наименование вида самостоятельной работы: изучение ли-

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

Проектная команда – это коллектив специалистов,

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

Существует два основных принципа формирования команды для управления проектом.

Ведущие участники проекта - заказчик и подрядчик (кроме них, могут быть и другие участники) создают собственные группы, которые возглавляют руководители проекта, соответственно, от заказчика и подрядчика. Эти руководители подчиняются единому руководителю проекта.

2. Для управления проектом создается единая команда во главе с руководителем проекта. В команду входят полномочные представители всех участников проекта для осуществления функций согласно принятому распределению зон ответственности.

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

1. Технические и/или функциональные, профессиональные, навыки.

2. Навыки по решению проблем и принятию решений 3. Навыки межличностного общения (принятие риска, полезная

критика, активное слушание и т д.). Выделяют три типа проектных команд: 1. Команда проекта: основная роль данной группы – активная

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

. Рабочая/процессная команда: роль данной группы – выполнение определенных задач или работ. Совместное решение поставленных задач в ходе выполнения проекта, позволяет создать высокоэффективную группу специалистов, способных включаться в проекты на любом этапе.

3. Команда управления проектом: Роль данной группы – координация, мониторинг и контроль выполнения задач проекта. Результаты исполнения организационных и управленческих функций данной группы позволяют следовать стратегии проекта и реализовывать стратегические решения.

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

− базовые концепции проектирования ПО (Software Design Basic Concepts),

− ключевые вопросы проектирования ПО (Key Issue in Software Design),

− структура и архитектура ПО (Software Structure and Architecture),

− анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),

− нотации проектирования ПО (Software Design Notations), − стратегия и методы проектирования ПО (Software Design

Strategies and Methods). На этапе проектирования, команда разработчиков должна

следовать одному из типов: − Если решение задач высоких иерархических уровней

предшествует решению задач более низких иерархических уровней, − Проектирование называют нисходящим (пошаговая

детализация). Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называют восходящим.

Методологии проектирования в настоящее время: 1) Нотация BPMN (Business Process Model and Notation - модель

бизнес-процессов и нотация) используется для описания процессов нижнего уровня. Диаграмма

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

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

4) Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0.

5) Нотация EPC (Event-Driven Process Chain - событийная цепочка процессов) используется для описания процессов нижнего уровня.

6) SADT (Structured Analysis And Design technique) – методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком.

7) UML (Unified Modeling Language – унифицированный язык моделирования).

8) Стандарт описания бизнес-процессов DFD – Data Flow Diagram переводится как диаграмма потоков данных.

9) ER-модель (от англ. entity-relationship model, модель «сущность – связь») – модель данных, позволяющая описывать концептуальные схемыпредметной области.

10) ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных.

1.3. Проектирование программного обеспечения.

Вопросы для рассмотрения: Проектирование программного

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

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 1, 3, перечень ресурсов

в сети Интернет. Наименование вида самостоятельной работы: изучение

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

Проектированием программного обеспечения является процесс

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

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

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

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

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

Проектирование состоит из следующих этапов: − Описания. Данный этап включает в себя совместную работу

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

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

− Разработки технического задания (ТЗ). ТЗ составляет архитектор в соответствии с описанием и ответами на вопросы заказчика. Затем ТЗ согласовывают с менеджером проекта, далее передают клиенту и производят правки.

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

− Контроля. В ходе этого этапа архитектором устраняются замечания менеджера проектов.

− Утверждения. На данном этапе заказчиком проверяется и меняется самостоятельно ТЗ, либо сообщается список правок проект-менеджеру. После устранения замечаний ТЗ утверждают и прилагают к контракту.

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

− Что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?

− Как делать (содержит описание архитектуры)? Как проверить, достигнута ли цель (варианты тестирований, критерии оценки)?

1.4. Документация по сопровождению программных средств

Вопросы для рассмотрения: Стандарты и практические

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

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 3, 4, перечень ресурсов

в сети Интернет. Наименование вида самостоятельной работы: изучение

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

Документация по сопровождению ПС (system documentation)

описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение

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

Документация по сопровождению ПС можно разбить на две группы:

1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2) документацию, помогающую вносить изменения в ПС. Документация первой группы содержит итоговые документы

каждого технологического этапа разработки ПС. Она включает сле-дующие документы:

− Внешнее описание ПС (Requirements document). − Описание архитектуры ПС (description of the system archi-

tecture), включая внешнюю спецификацию каждой ее программы (подсистемы).

− Для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.

− Для каждого модуля - его спецификация и описание его строения (design description).

− Тексты модулей на выбранном языке программирования (program source code listings).

− Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каж-дой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.

Документация второй группы содержит: − Руководство по сопровождению ПС (system maintenance

guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможно-сти развития ПС в его строении (конструкции). В нем также фикси-руются, какие части ПС являются аппаратно- и программно-зависимыми.

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

Стандарт сопровождения программных средств - ГОСТ Р ИСО/МЭК 14764-2002.

1.5. Международные стандарты в сфере разработки

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

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

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 2, 4, перечень ресурсов

в сети Интернет. Наименование вида самостоятельной работы: изучение ли-

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

Среди всех стандартов в области разработки программного

обеспечения, используемых в настоящее время в мире, наиболее по-пулярными моделями являются: ISO 9001, TickIT, SEI SW-CMM.

Стандарты международной организации по стандартизации ISO являются наиболее известными и распространенными в мире. Стандарты ISO универсальны, их можно применять в качестве моде-лей независимо от отрасли, в которой функционирует компания. В следствие этого у модели ISO есть свои неоспоримые преимущества и недостатки. Но основным преимуществом модели ISO является из-вестность, распространенность, признание на мировом уровне. Сей-час стандарты ISO являются обязательным минимумом который должна иметь любая организация существующая на рынке. Но конеч-но же, вследствие своей универсальности, модель на основе стандар-тов ISO серии 9000 получилась достаточно «высокоуровневой».

Достаточно широкую известность получил британский стан-дарт TickIT. Этот отраслевой стандарт регламентирует требования к системе качества для организаций разработчиков программного обес-печения и базируется на модели ISO 9001:94. В отличие от модели ISO 9001, которая регламентирует “что необходимо сделать”, разра-ботчики данного стандарта попытались ответить на вопрос “как” можно выполнить требования, определенные в ISO 9001. TickIT объ-единяет в себе модель ISO 9001 с набором рекомендательных стан-дартов ISO 12207 и ISO 9000-3.

Очень интересный подход к улучшению внутренних процессов разработки программного обеспечения определен в модели SEI SW-

CMM. В основу данной модели (также как и в основу стандартов ISO серии 9000) положена теория TQM. Теория TQM основывается на по-степенном улучшении внутренних производственных процессов за счет множества небольших внедряемых в компании улучшений. Од-нако, модели ISO и CMM несколько различаются в своих подходах к построению самосовершенствующихся систем управления качеством и улучшению производственных процессов.

Одним из важных моментов, который необходимо иметь в виду при внедрении каких-либо стандартов (ISO 9000, SEI SW-CMM, TickIT, Spice ISO 15504 и т.п.), связан с тем, что структура производ-ства компаний, разрабатывающих программное обеспечение, связана со спецификой продукта. Каждый продукт, разрабатываемый IT-компанией, уникален. И для его разработки, как правило, использует-ся проектный тип организации производства, который тесно связан с матричной структурой управления проектами.

В 1987 г корпорация IBM объявила о намерении создать еди-ную среду разработки приложений (Systems Application Architecture — SAA). Данный проект предусматривал не только разработку еди-ных принципов создания приложений, но и «материализацию» этих принципов на основе соответствующей технологической базы.

1.6. Тестирование, отладка и оценка качества программного

обеспечения

Вопросы для рассмотрения: Стратегии и методы

тестирования. Прямое и обратное тестирование. Программные средства автоматизации тестирования. Методики оценки качества ПО. Процессный подход к оценке качества ПО.

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 2, 4, перечень ресурсов

в сети Интернет. Наименование вида самостоятельной работы: изучение ли-

тературы, выполнение тестовых заданий. Отладка – этап разработки компьютерной программы, на

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

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

Отладка ПО включает в себя: тестирование, локализацию ошибок, редактирование; тестирование, оптимизацию; тестирование, локализацию ошибок, оптимизацию; тестирование, оптимизацию, документирование.

Основной задачей отладки ПО являются: выявление максимального количества ошибок; определение момента окончания отладки; создание тестов; тестирование и оптимизация ПО.

Тестирование – процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом. Общая схема тестирования выглядит следующим образом:

− Программа и требования поступают к тестировщику. − Он совершает необходимые операции, ведет наблюдение за

тем, как ПО выполняет поставленные задачи.

− По результатам проверки формируется список соответствий и несоответствий.

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

В контексте общего процесса разработки, процесс тестирования (зеленая ветка схемы) выглядит следующим образом:

− Юзабилити тестирование (проверка эргономичности) помогает определить: удобен ли сайт или пользовательский интерфейс для его предполагаемого применения.

− Создание чек-листа – подготовка набора тестов, внесение необходимых предложений в разрабатываемые требования (с точки зрения качества).

− Тестирование. Получив готовую для проверки программу или её часть, специалист проверяет её соответствие требованиям на выбранном наборе тестов. В случае обнаружения дефектов — передаёт разработчикам набор задач, необходимых для улучшения продукта до состояния соответствия требованиям.

− Верификация — проверка, которая показывает: были ли исправлены ошибки, обнаруженные в результате тестов. Обычно тесно связана с регрессионным тестированием(regression testing), направленным на обнаружение дефектов в участках кода, которые уже были протестированы.

− Тест производительности (performance testing) проводится на стендах, где в дальнейшем будет эксплуатироваться софт. Цель — выявление проблем стенда (не софта), имитация работы пользователей, проверка на стрессоустойчивость.

С помощью всех эатпов тестирования формируется качество ПО.

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

Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)[8] определяет модель качества продукта, которая включает восемь характеристик верхнего уровня: функциональная пригодность; уровень производительности; совместимость; удобство использования (юзабилити); надёжность; защищённость; сопровождаемость; переносимость (мобильность).

3. ПРАКТИЧЕСКИЕ РАБОТЫ

3.1 Практическая работа №1

«Работа с CASE-средствами. Построение диаграмм потоков

данных»

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 1, 3, 4, перечень

ресурсов в сети Интернет. Цель работы: Освоить работу с CASE-средствами при

построении диаграмм потоков данных. Ход работы: 1) Изучить методологию структурного анализа предметной

области с использованием диаграмм потоков данных (DFD), а также возможности моделирования DFD в Case-системах MS Visio / BPWin.

2) Определить функции, подлежащие автоматизации в рамках выбранной предметной области.

3) Построить функциональную модель ИС автоматизирующую выбранные процессы предметной области варианта задания с использованием методологии DFD.

4) Построить модели бизнес процессов «как есть» и «как должно быть».

5) Составить отчет по проделанной работе. 6) Защитить работу. В качестве программного обеспечения использовать: MS Visio

и ErWin. Вопросы к самопроверке: − Для чего служит DFD - диаграмма? − В чем отличие DFD - диаграммы от IDFE0? − Какой инструмент используется для построения внешних

сущностей? − Каким инструментом можно построить Хранилище данных? − Какие графические элементы используются для обозначения

на диаграмме Работы, Потоков данных, Хранилищ данных?

3.2 Практическая работа №2

«Применение методов ООП. Разработка программного продукта

с использованием объектно-ориентированного

программирования»

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 1, 3, перечень ресурсов

в сети Интернет. Цель работы: Освоить применение методов ООП для.

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

Ход работы: В рамках практического занятия необходима оформить отчет в

электронном в виде, содержащий описание следующих пунктов: − Определение термина «ООП» и его основные концепции. − Описание принципов ООП. − Этапы разработки ООП. − Классификация подвидов ООП. − Особенности реализации ООП. − Проектирование ПО для разработки методом ООП. − Среды реализации ООП. − Примеры языков ООП.

3.3 Практическая работа №3

«Технологии разработки технического задания»

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 3, 4, перечень ресурсов

в сети Интернет. Цель работы: научиться писать технического задания для

разработки информационных систем. Ход работы: В рамках практического занятия необходимо разработать

техническое задание по стандарту «ГОСТ 19.201-78 Техническое

задание, требования к содержанию и оформлению». В качестве предметной области разработки обозначить предметную область из практического занятия № 1.

Обозначенный стандарт написания ТЗ необходимо взять в сети Интернет. Техническое задание оформить в электронном виде с помощью MS Word.

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

3.4 Практическая работа №4

«Стандартизация в области открытых систем»

Рекомендуемая литература: 1. Перечень дополнительных ресурсов: 2, 4, перечень ресурсов

в сети Интернет. Цель работы: изучить особенности стандартизации в области

открытых систем. Ход работы: В рамках практического занятия необходима оформить отчет в

электронном в виде, содержащий описание следующих пунктов: − Определение открытых систем. − Свойства открытых систем. − Технический состав открытых систем. − Примеры открытых систем. − Международные стандарты открытых систем. − Российские стандарты открытых систем.

4. ТЕМЫ ДЛЯ ПОДГОТОВКИ К ИТОГОВОЙ ФОРМЕ КОНТРОЛЯ

− Основные определения: программные средства, программ-

ное обеспечение, программный продукт. − Методики оценки качества ПО − Классификация типов программного обеспечения. − Виды тестирования ПО. − Жизненный цикл программного обеспечения. Характери-

стика каждого из этапов. − Стратегии и методы тестирования ПО. − Понятие «ядра» программы и основы его разработки. − Международные стандарты пользовательского интерфей-

са. − Рынок современных программных продуктов. − Международные стандарты оформления документации. − Характеристика этапов разработки программного обеспе-

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

го обеспечения. − Основные понятия надежности программных систем − Жизненный цикл программного обеспечения. Характери-

стика каждого из этапов. − Организация выпуска документации в фазах оценки и ис-

пользования. − Архитектурное проектирование. − Организация выпуска документации в фазах исследования

и анализа осуществимости. − Характеристика этапов разработки программного обеспе-

чения. − Организация выпуска документации в фазах конструиро-

вания и программирования. − Краткая характеристика методов разработки программно-

го обеспечения. − Техническое задание на разработку ПО. Основные разделы

ТЗ. − Детальное проектирование. − Метод последовательной модернизации. − Проектирование пользовательского интерфейса. − Стандарты разработки ПО. − Модели жизненного цикла программного обеспечения. − Стандарты проектирования ПО. − Системный подход к разработке ПО. − Способы формирования трехмерных изображений.

− Стандарты по разработке ПО. Виды значение стандартов. − Этапы разработки трехмерного изображения. − Проблемы разработки программного обеспечения. − CASE-технологии разработки ПО.

5. ТИПОВЫЕ ТЕСТОВЫЕ ЗАДАНИЯ

5.1 Типовой вариант по всем темам дисциплины

«Технологии разработки программного обеспечения»

1.

Архитектура программного обеспечения (ПО) A) это совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также иерархия подсистем, объединяющих структурные элементы B) Инструментарий технологии программирования C) Структура программных средств, документов программно-го обеспечения D) Структура программного и информационного обеспечения E) Структура информационной системы, программных средств, документации по программным средствам

2. Комплекс взаимосвязанных программ для решения задач определенного класса конкретной предметной области A) Системное программное обеспечение B) Инструментарий технологии программирования C) Пакет прикладных программ D) Операционная система E) Средства технического обслуживания

3. Программный продукт - это: A) Задачи, автоматизированные на персональном компьютере и облегчающие труд пользователя; B) Набор компьютерных программ, имеющихся на персональ-ном компьютере; C) Задачи, решаемые на персональном компьютере D) Задачи, которые автоматически вводят, обрабатывают и со-храняют данные пользователей; E) Комплекс взаимосвязанных программ для решения опреде-ленной проблемы (задачи) массового спроса, подготовленный к

реализации как любой вид промышленной продукции. 4. CASE – технологии (Computer Aided Software Engineering) –

это A) программная инженерия с компьютерной поддержкой B) технологии создания Ole–объектов; C) технологии создания процедур и функций с использованием объектно – ориентированного языка D) задачи, которые автоматически вводят, обрабатывают и со-храняют данные пользователей; E) технологии, связанные с обработкой данных на компьюте-рах.

5. Программный продукт разрабатывается на основе A) Инструментального программного обеспечения B) Новейших технических средств C) С использованием инструментария технологий программи-рования D) промышленной технологии выполнения проектных работ с применением современных инструментальных средств про-граммирования

E) С использованием современных средств создания базы данных

6. CASE – технологии представляет собой A) методологию проектирования программных средств, а также набор инструментальных средств (ПС), которые позволяют в наглядной форме моделировать наглядную область, анализиро-вать эту модель на всех этапах разработки и сопровождения ПС B) методологию проектирования информационных систем C) методологию проектирования справочной системы и общей документации к программным средствам; D) инструментарий технологий программирования

E) методология проектирования предметной области зада-чи

7. Технология конструирования программного обеспечения (ТКПО) представляет собой A) методы, средства, процедуры B) Процедуры, функции, методы; C) Обработчики событий, методы; D) свойства, функции, методы;

E) Процедуры, функции, свойства. 8. Методы технологии конструирования программного обес-

печения обеспечивают решение следующих задач: A) проектирование проекта, реализацию и сдачу проекта; B) подготовку проектирования проекта, проектирование проек-та, сдача проекта в эксплуатацию; C) планирование и определение функций проекта, определение информационной системы проекта; D) планирование проекта, создание информационной системы, проектирование алгоритмов; E) планирование и оценку проекта; анализ и оценка проекта; проектирование алгоритмов, структур данных и программных структур; кодирование; тестирование; сопровождение

9. Средства (утилиты) технологии конструирования про-граммного обеспечения обеспечивают A) автоматизированную поддержку методов; B) автоматизированную поддержку свойств; C) автоматизированную поддержку средств; D) автоматизированную поддержку процедур; E) выполнение процедуры, функции, свойства.

10. Процессы технологии конструирования программного обеспечения определяют: A) порядок применения свойств, методов; B) порядок применения функций, методов; C) порядок применения методов, средств и поддержку свойств; D) порядок применения процедур; E) порядок применения методов и средств (утилит); формиро-вание отчетов, форм по соответствующим требованиям; кон-троль, который помогает обеспечивать качество и координиро-вать изменения

11. Критерии качества, предъявляемые к программе A) программа должна быть спроектирована согласно техниче-скому заданию, эффективна по быстродействию и памяти, ши-роко использоваться и быть доступной, модернизуемой, доста-точно надежна в процессе расчета; B) программа должна выполнять все функции, заложенные в техническом задании; C) программа должна функционировать в любых операцион-

ных системах; D) программа не должна завершаться аварийно; E) программа должна правильно вычислять все операции зада-чи

12. Мобильность программных продуктов означает A) их независимость от технического комплекса системы обра-ботки данных, операционной среды, сетевой технологии обра-ботки данных, специфики предметной области; B) бессбойность и устойчивость в работе программ, точностью выполнения функций; C) программа не должна зависеть от операционной системе; D) программа должна функционировать с любыми технически-ми средствами; E) программа не должна зависеть от того, выполняется она мо-нопольно или выполняется в сети.

13. Надежность работы программного продукта определяется A) независимостью от технического комплекса системы обра-ботки данных; B) независимостью от операционной среды, сетевой техноло-гии обработки данных, специфики предметной области; C) бессбойностью и устойчивостью в работе программ, точно-стью выполнения предписанных функций обработки возмож-ностью диагностики возникающих в процессе работы программ ошибок; D) корректностью выполнения функций задачи; E) корректностью выхода из задачи.

14. Коммуникативность программных продуктов основана на A) декомпозиции; B) интеграции с другими приложениями; C) интеграции с другими информационными системами; D) передаче данных из одной БД в другую БД; E) работу в любой операционной системе.

15. Декомпозиция – это A) разбивка системы на подсистемы. B) разбивка программы на части; C) разбивка решения задачи; D) разбивка системы на главные функции и вспомогательные функции;

E) разбивка разработки программы на стадии и этапы. 16. Жизненный цикл ПО – это

A) Время выполнения программного обеспечения B) Время создания программного обеспечения C) Время работоспособности программного обеспечения D) время эксплуатации программного продукта E) непрерывный процесс, который начинается с момента при-нятия решения о необходимости создания ПО и заканчивается в момент полного изъятия его из эксплуатации

17. Основным нормативным документом, регламентирующим ЖЦ ПО является A) Международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – Electrotechnical Commission – Между-народная комиссия по электротехнике). B) ISO/IEC DTR 15504 (SPICE) – Оценка и улучшение процес-сов разработки программного обеспечения; C) ISO/IEC 9294. Основные принципы управления разработкой документации на программное обеспечение; D) Серия ISO 9000 (9000-1.9000-2.10013.9004-5. Это стандарты в области управления качеством и обеспечения качества. E) ГОСТ 34.ххх. Информационная технология, комплекс стан-дартов и документов на автоматизированные системы.

18. Требования к разработке ПО включают A) оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспо-собности и соответствующего качества программных продук-тов (ПП), материалов, необходимых для организации обучения персонала, этапы создания программного продукта; B) оформление проектной и эксплуатационной документации, оформление общего вида программных средств; C) выполнения всех требований заказчика, оформление доку-ментации к программному обеспечению; D) срок сдачи программного продукта, качество ПП, докумен-тация к ПП; E) качественная реализация ПП, сроки выполнения, стоимость ПП.

19. Процесс разработки ПО состоит из следующих основных частей:

A) ознакомление с предметной областью задачи, оформление требований заказчика; разработка структуры информационной системы, проектирование задачи; B) оформление договора с заказчиком, оформление предпро-ектной документации, создание программного обеспечения, передача заказчику; C) ознакомление с предметной областью, создание документа «Техническое задание», анализ имеющихся ПП, разработка структуры ПО, кодирование и тестирование, передача заказчи-ку; D) ознакомление с предметной областью, анализ предметной области, формирование требований к ПО, разработка структу-ры ПО, кодирование и тестирование, передача заказчику; E) подготовительная работа; анализ требований к системе; про-ектирование архитектуры системы; анализ требований к ПО; проектирование архитектуры ПО; детальное проектирование ПО; кодирование и тестирование ПО; установка ПО; приемка ПО.

20. Анализ требований к системе – это A) определение функциональных возможностей системы, поль-зовательских требований, требований к надежности и безопас-ности, требований к внешним интерфейсам; B) определение операционной системы; C) определение информационной системы; D) определение требований к интерфейсу; E) определение требований к надежности и безопасности, структуре информационной системы.

21. К вспомогательным процессам относятся: A) процесс приобретения, процесс поставки, процесс разработ-ки, процесс эксплуатации, процесс сопровождения; B) процесс покупки, процесс установки, процесс эксплуатации, процесс снятия с учета; C) процесс продажи, процесс передачи, процесс сопровожде-ние, процесс эксплуатации; D) процесс документирования; процесс управления конфигура-цией; процесс обеспечения качества; процесс верификации; процесс аттестации; процесс совместной оценки; процесс ауди-та; процесс разрешения проблем; E) процесс приобретения; процесс внедрения; процесс эксплуа-

тации; процесс снятия с учета. 22. Процесс документирования предусматривает

A) формализованное описание информации, созданной в тече-ние ЖЦ ПО; B) описание требований к созданию программного продукта C) описание структуры информационной системы, требования разработчика; D) описание требований заказчика, функциональные описания ЖЦ ПО; E) описание всего процесса разработки ПО.

23. Под стадией создания ПО понимается A) этап для разработки ПО; B) временной отрезок, в течении которого создается часть ПО; C) временной отрезок ПО, ограниченный сроком выполнения и необходимый для выполнения для выполнения некоторого эта-па ПО; D) этап разработки ПО, после окончания которого начинается следующий этап проектирования; E) часть процесса ПО, ограниченная некоторыми временными рамками и заканчивающая выпуском конкретного продукта (моделей ПО, компонентов, документации).

24. Стадии создания ПО выделяются в следующие группы: A) формирование требований к ПО; Анализ; Проектирование; Реализация (кодирование); Внедрение и сопровождение; Сня-тие с эксплуатации; B) формирование требований к ПО; Анализ; разработка доку-ментов: «Техническое задание», «Технический проект»; C) формирование требований к ПО; Разработка; Отладка; Вне-дрение; Эксплуатация; D) формирование требований к разработке ПО; Определение входных и выходных данных; E) обследование предметной области, формирование требова-ний к разработке ПО, Разработка; Отладка; Внедрение; Экс-плуатация.

25. На стадии «Формирования требований к ПО» выполняют-ся следующие работы: A) разработку системного проекта; разработку технического проекта; B) планирование работ, предваряющее работы над проектом;

проведение обследования деятельности объекта/организации, для которой проектируется система; построение моделей дея-тельности объекта/организации; C) формирование предпроектной и проектной документации; D) обследование предметной области, формирование докумен-та: Технический проект; E) анализ деятельности предприятия, для которой проектирует-ся система, обоснование разработки системы.

26. Стадия «Анализ и проектирование» включает в себя: A) разработку системного проекта; разработку технического проекта; B) планирование работ, предваряющее работы над проектом; проведение обследования деятельности объекта/организации, для которой проектируется система; построение моделей дея-тельности объекта/организации; C) формирование предпроектной и проектной документации; D) обследование предметной области, формирование докумен-та: Технический проект; E) анализ деятельности предприятия, для которой проектирует-ся система, обоснование разработки системы.

27. Стандартным графическим обозначением актера на диа-граммах является A) прямоугольник; B) квадрат; C) фигурка человечка; D) окружность; E) трапеция.

28. Документ «Техническое задание» составляется A) разработчиком; B) программистом; C) исполнителем; D) заказчиком; E) разработчиком вместе с заказчиком.

29. К основной проектной документации относятся: A) «Рабочее задание», «Технический проект», «Рабочий про-ект»; B) «Техническое задание», «Технический проект», «Рабочий проект»;

C) «Задание заказчика», «Разработка проекта», «Создание про-екта»; D) «Договор с заказчиком», «Требования заказчика», «Разра-ботка проекта»; E) «Договор с заказчиком», «Обследование предметной облас-ти», «Разработка проекта».

30. На предпроектной стадии разработки информационной системы составляется A) «Техническое задание»; B) «Технический проект»; C) «Разработка проекта»; D) «Рабочий проект»; E) «Договор с заказчиком».

31. На проектной стадии разработки разрабатываются A) «Техническое задание» и «Технический проект»; B) «Технический проект» и «Разработка проект» ; C) «Рабочий проект» и «Техническое задание»; D) «Технический проект» и «Рабочий проект»; E) «Договор с заказчиком» и «Техническое задание».

32. Технический проект (ТП) определяет A) организационно – информационные, функциональные ре-шения, необходимые для создания информационного обеспе-чения; B) функционально – информационные, технические решения, необходимые для создания информационного обеспечения; C) организационно – экономические, технические и методиче-ские решения, необходимые для создания информационного обеспечения; D) организационно – функциональные, технологические реше-ния, необходимые для создания информационного обеспече-ния; «Технический проект» и «Рабочий проект»; E) функциональные, организационные и технические решения, необходимые для создания информационного обеспечения.

33. В рабочий проект входят: A) программная документация, включающая описание алго-ритмов, контрольный пример для отладки программ, инструк-ции пользователя; B) описание предметной области, требования заказчика;

C) требования заказчика, постановка задачи, реализация задачи; D) обоснование для разработки информационной системы; E) документация, описывающая требования заказчика.

34. На этапе разработки рабочего проекта осуществляется: A) разработка программных модулей; программирование или создание программного кода; отладка программного продукта; B) испытание работоспособности программных модулей и ба-зовых программных средств; описание предметной области, требования заказчика; C) подготовка контрольного примера, для проверки соответст-вия ПП заданию, создание эксплуатационной документации на программный продукт; D) Описание применения; Руководство пользователя; Руково-дство программиста; Обучающей системы (для ПП массового применения); E) Все ответы правильные.

35. Сопровождение программного продукта A) эксплуатация программного продукта вместе с разработчи-ком; B) исправление разработчиком ошибок при эксплуатации про-граммного продукта; C) внедрение программного продукта на предприятии; D) это процесс адаптации поставляемого программного про-дукта к новым условиям, внесения изменений в ПП и соответ-ствующую документацию, вызванных возникшими проблемами или потребностями в модификации, при сохранении неизмен-ными его основных функций; E) отладка программного продукта на базе заказчика.

36. Документация по эксплуатации ПП включает A) характеристика ПП, аннотация по установке и работе ПП; B) документ по установке ПП, инструкция пользователя; C) техническое задание, технический проект, рабочий проект; D) справочник пользователя, справочник программиста, спра-вочник по обучению персонала; E) руководство пользователя, руководство программиста, обу-чающая система.

37. Стандартизация в программировании - A) правила организации в программах связей между процеду-

рами B) применение разнообразных законов и процедур для разра-ботки ПО C) поиски решения задачи по программированию D) поиск и единообразное применение законов (общих согла-шений об интерфейсах между разрозненными элементами) и процедур (алгоритмов) E) правила организации в программах связей по передачам управления

38. Для моделирования поведения системы в рамках различ-ных вариантов использования, или потоков управления используются - A) диаграммы состояний B) диаграммы деятельности C) диаграммы размещения D) диаграммы взаимодействия E) диаграммы вариантов

5. КОМПЛЕКТ ЗАДАНИЙ ДЛЯ САМОСТОЯТЕЛЬНОЙ

РАБОТЫ

5.1 Самостоятельная работа № 1 по теме

«Методы разработки программного обеспечения»

Провести структурный анализ программного комплекса (по ва-

риантам) и построить следующие модели: a) диаграмм потоков данных, описывающих взаимодействие

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

b) диаграмм «сущность-связь», описывающих базы данных разрабатываемой системы

c) диаграмм переходов состояний, характеризующих поведе-ние системы во времени;

d) функциональных диаграмм; e) спецификаций процессов; f) словаря терминов.

Варианты индивидуальных заданий: 1. Разработка программного комплекса «Автотранспорт». 2. Разработка программного комплекса «Деканат института». 3. Разработка программного комплекса «Обслуживание

банкомата». 4. Разработка программного комплекса «Управление

гостиницей». 5. Разработка программного комплекса «Выдача кредитов в

банке». 6. Разработка программного комплекса «Строительная

фирма». 7. Разработка программного комплекса «Управление

библиотечным фондом». 8. Разработка программного комплекса «АРМ работника

склада» 9. Разработка программного комплекса «АРМ

администратора ателье по ремонту оргтехники 10. Разработка программного комплекса «АРМ

администратора автосалона» 11. Разработка программного комплекса «АРМ

администратора ресторана». 12. Разработка программного комплекса «АРМ сотрудника

ЖЭСа». 13. Разработка программного комплекса «АРМ

администратора аэропорта». 14. Разработка программного комплекса «АРМ работника

отдела кадров». 15. Разработка программного комплекса «АРМ

администратора спорткомплекса».

5.2 Самостоятельная работа № 2 по теме

«Проектирование программного обеспечения»

Проведите сравнительный анализ стратегий разработки про-

граммного обеспечения, перечисленных ниже: 1. Базовые стратегии разработки программных средств и сис-

тем

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

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

4. Эволюционная стратегия разработки программных средств и систем

Заполните таблицу: Характеристика

проекта Стратегия

Новизна разработки и обес-печенность ресурсами

Масштаб проекта Срок выполнения проекта Заключение отдельных дого-воров на отдельные версии

Определение основных требо-ваний в начале проекта

Изменение требований по ме-ре развития проекта

Разработка итерациями Распространение промежу-точного ПС

5.3 Самостоятельная работа № 3 по теме

«Документация по сопровождению программных средств»

Разработать техническое задание на разработку программного

комплекса (по вариантам). Техническое задание должно содержать следующие разделы: − название программы и область применения; − основание для разработки; − назначение разработки; − технические требования к программе или программному

изделию; − технико-экономические показатели; − стадии и этапы разработки: − порядок контроля и приемки;

− приложения. Варианты индивидуальных заданий: 1. Разработка программного комплекса «Автотранспорт». 2. Разработка программного комплекса «Деканат института». 3. Разработка программного комплекса «Обслуживание

банкомата». 4. Разработка программного комплекса «Управление

гостиницей». 5. Разработка программного комплекса «Выдача кредитов в

банке». 6. Разработка программного комплекса «Строительная

фирма». 7. Разработка программного комплекса «Управление

библиотечным фондом». 8. Разработка программного комплекса «АРМ работника

склада» 9. Разработка программного комплекса «АРМ

администратора ателье по ремонту оргтехники 10. Разработка программного комплекса «АРМ

администратора автосалона» 11. Разработка программного комплекса «АРМ

администратора ресторана». 12. Разработка программного комплекса «АРМ сотрудника

ЖЭСа». 13. Разработка программного комплекса «АРМ

администратора аэропорта». 14. Разработка программного комплекса «АРМ работника

отдела кадров». 15. Разработка программного комплекса «АРМ

администратора спорткомплекса».

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ 1. Лаврищева, Е. М. Программная инженерия и технологии программиро-

вания сложных систем : учебник для вузов / Е. М. Лаврищева. — М. : Издатель-ство Юрайт, 2018. — 432 с. — (Серия : Бакалавр. Академический курс). — ISBN 978-5-534-04591-8. — Режим доступа : www.biblio-online.ru/book/DCD7188A-4AAB-4B59-84CD-40A05E3676A7

1. Григорьев М. В. Проектирование информационных систем : учебное пособие для вузов / М. В. Григорьев, И. И. Григорьева. — М. : Издательство Юрайт, 2018. — 318 с. — (Серия : Университеты России). — ISBN 978-5-534-01305-4. — Режим доступа : www.biblio-online.ru/book/394E4411-7B76-4F47-BD2D-C3B981BEC3B8

2. Казарин, О. В. Надежность и безопасность программного обеспечения : учебное пособие для бакалавриата и магистратуры / О. В. Казарин, И. Б. Шубин-ский. — М. : Издательство Юрайт, 2018. — 342 с. — (Серия : Бакалавр и ма-гистр. Модуль.). — ISBN 978-5-534-05142-1. — Режим доступа : www.biblio-online.ru/book/6A637EC7-8B78-4DA6-B404-71DE0202E2EF

3. Рыбальченко, М. В. Архитектура информационных систем : учебное пособие для вузов / М. В. Рыбальченко. — М. : Издательство Юрайт, 2018. — 91 с. — (Серия : Университеты России). — Режим доступа: https://biblio-online.ru/book/453CB056-891F-4425-B0A2-78FFB780C1F1 — Загл. с экрана.

4. Степанов, Е.О. Учебно-методическое пособие по дисциплине Архитек-туры и технологии разработки распределенного программного обеспечения [Электронный ресурс] : учеб.-метод. пособие / Е.О. Степанов, Б.М. Ярцев. — Электрон. дан. — Санкт-Петербург : НИУ ИТМО, 2012. — 103 с. — Режим дос-тупа: https://e.lanbook.com/book/43816. — Загл. с экрана.

ПЕРЕЧЕНЬ РЕСУРСОВ СЕТИ «ИНТЕРНЕТ», РЕКОМЕНДУЕМЫХ ДЛЯ ОСВОЕНИЯ ДИСЦИПЛИНЫ

1. http://www.osp.ru – электронный журнал «Открытые системы» 2. http://www.infoart.ru – Каталог компьютерной прессы