технология разработки программного обеспечения
реклама
Министерство образования и науки Российской Федерации Амурский государственный университет ББК 32.973-018.2 Т38 Рекомендовано учебно-методическим советом университета Рецензент: Е.Ф Алутина, канд. физ.-мат. наук, доцент, зав. кафедрой информатики Благовещенского государственного педагогического университета ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Учебно-методическое пособие Т38 Технология разработки программного обеспечения. Учебно-методическое пособие / сост. Т.А. Галаган. – Благовещенск: Изд-во АмГУ, 2015. – 49 с. Пособие предназначено для самостоятельной работы, в качестве дополнительной литературы. Краткие теоретические сведения содержат основные понятия и определения, этапы проектирования программного обеспечения и создания программного обеспечения в рамках его жизненного цикла. ББК 32.973-018.2 Благовещенск 2015 Амурский государственный университет, 2015 2 ОГЛАВЛЕНИЕ Тема 9. Документация по сопровождению программных средств.......................31 ВВЕДЕНИЕ ......................................................................................................................5 Вопросы для повторения и самостоятельного изучения........................................33 Тема 1. Основные понятия и определения. Классификация типов программного Вопросы самопроверки................................................................................................33 обеспечения. Этапы разработки программного обеспечения .................................7 Литература .....................................................................................................................35 Вопросы для повторения и самостоятельного изучения..........................................8 Приложение. Техническое задание............................................................................36 Вопросы самопроверки..................................................................................................8 Тема 2. Понятие жизненного цикла программного обеспечения. Модели жизненного цикла программного обеспечения: каскадная, итерационная, спиральная......................................................................................................................................9 Вопросы для повторения и самостоятельного изучения........................................11 Вопросы самопроверки................................................................................................11 Тема 3. Структура приложения, построенного на архитектуре «клиент-сер вер»..................................................................................................................................12 Вопросы для повторения и самостоятельного изучения........................................14 Вопросы для самопроверки.........................................................................................14 Тема 4. Разработка технического задания ................................................................14 Вопросы для повторения и самостоятельного изучения........................................16 Вопросы для самоконтроля .........................................................................................16 Тема 5. Модульное проектирование программных средств. Методы структурного проектирования ........................................................................................................16 Вопросы для повторения и самостоятельного изучения........................................19 Вопросы самоконтроля ................................................................................................19 Тема 6. Анализ требований и определение спецификаций при объектно-ориентированном подходе................................................................................................19 Вопросы для повторения и самостоятельного изучения........................................23 Вопросы для повторения и самостоятельного изучения........................................27 Вопросы самоконтроля ................................................................................................27 Тема 8. Тестирование программного обеспечения .................................................28 Вопросы для повторения и самостоятельного изучения........................................30 Вопросы самоконтроля ................................................................................................31 3 4 ВВЕДЕНИЕ тию следующих профессиональных компетенций: способен проявлять инициативу, в том числе в ситуациях риска, брать на себя всю полноту ответственности (ОК-5); Методические указания составлены в соответствии с рабочими программами по одноименной дисциплине, разработанными в рамках основных образовательных программ магистратуры по направлениям подготовки 230100.68 – Информатика и вычислительная техника и 231000 – Программная инженерия. Целью освоения дисциплины «Технология разработки программного обеспечения» является изучение этапов проектирования, разработки, тестирования и отладки программного обеспечения, в том числе и больших программных систем с точки зрения требований заказчика и разработчика. Задача дисциплины – обобщение знаний, полученных студентами в таких дисциплинах как «Программирование», «Разработка программных комплексов», «Проектирование АСОИУ» и изучение современных технологий проектирования и разработки программного обеспечения. В результате освоения дисциплины обучающийся должен демонстрировать следующие результаты образования: для направления подготовки 230100.68: Знать разрабатывать и реализовывать планы информатизации предприятий и их подразделений на основе Web- и CALSтехнологий (ПК-3); формировать технические задания и участвовать в разработке аппаратных и/или программных средств вычислительной техники (ПК-4); организовывать работу и руководить коллективами разработчиков аппаратных или/и программных средств информационных и автоматизированных систем (ПК-7); для направления подготовки 231000.68: Знать - профили стандартов жизненного цикла программного продукта; - этапы и принципы управления качеством процессов разработки в течении жизненного цикла производства программного обеспечения; Уметь осуществлять выбор технической модели эволюции и сопровождения программного обеспечения; Владеть навыками управления версиями и релизами программного продукта, навыками поддержки целостности конфигурации в течении жизненного жизненный цикл программ, оценку качества программных продуктов, технологии разработки программных комплексов, CASE-средства; методы и алгоритмы объектно-ориентированного программирования; методики, языки и стандарты информационной поддержки изделий (CALS-технологий) на различных этапах их жизненного цикла; Уметь использовать типовые программные продукты, ориентированные на решение научных, проектных и технологических задач; Владеть методиками сбора, переработки и представления научно- цикла программного проекта. Способно к развитию следующих компетенций: использование на практике умения и навыки в организации (ПК-4); умение формировать технические задания и способность руководить разработкой программного обеспечения (ПК-7). Материал пособия разбит на девять тем, каждая из которых содержит краткие теоретические сведения, а также вопросы для повторения и самостоятельного изучения и вопросы самоконтроля. технических материалов по результатам исследований к публикации и печати, а также в виде обзоров, рефератов, отчетов, докладов и лекций. Обучение студентов данной дисциплине должно способствовать разви5 6 Тема 1. Основные понятия и определения. Классификация типов программного обеспечения. Этапы разработки программного обеспечения стоятельно или в составе другого комплекса. Понятие жизненного цикла программного обеспечения включает все этапы его развития от возникновения в нем потребности до полного прекращения Существует множество форм, определяющих термин «программное обеспечение». Согласно международных и российских стандартов данный термин трактуется следующим образом: его использования. Наиболее часто говорят о следующих моделях жизненного цикла: каскадная (водопадная) или последовательная; Программное обеспечение (ПО) – итеративная и инкрементальная – эволюционная (гибридная, смешанная); все или часть программ, процедур, правил и соответствующей докумен- спиральная (spiral) или модель Боэма. тации системы обработки информации (ISO/IEC 2382-1:1993); компьютерные программы, процедуры и, возможно, соответствующая Согласно ISO/IEC 12207, разработка ПО – это форма разработки, которая применяет принципы информатики, информационной технологии, документация и данные, относящиеся к функционированию компьютерной сис- математики и прикладной области к достижению экономичных решений для темы (IEEE Std 829-2008); практических проблем посредством ПО. программа или множество программ, используемых для управления компьютером (IEEE Std 829-2008); Этапами разработки программного обеспечения являются: 1. Анализ требований к системе, определение спецификаций совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ (ГОСТ 19781-90). Существует и множество классификаций ПО. По назначению оно делится на следующие виды: 2. Проектирование 3. Кодирование 4. Тестирование и отладка 5. Эксплуатация и сопровождение системное, обеспечивающее взаимодействие всех программ с программами базового уровня и непосредственно с аппаратным обеспечением и отвечающее за взаимодействие с пользователем, прикладное – обеспечивающее непосредственное выполнение работ, необходимых пользователю; Вопросы для повторения и самостоятельного изучения 1. Классификация системного программного обеспечения 2. Содержание стандарта ГОСТ 19.001-77 Общие положения 3. Содержание стандарта ГОСТ 19.102-77 Стадии разработки инструментальное – необходимое в процессе создания программ. 4. Инструментарий технологии программирования. Классификация По видам программ выделяют: компонент – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе ком- Вопросы самопроверки 1. На какой из этапов разработки программного обеспечения приходится основная часть расходов жизненного цикла? плекса, комплекс – программа, состоящая из двух или более компонентов и (или) 2. К какому виду программного обеспечения относятся операционные комплексов, выполняющих взаимосвязанные функции, и применяемая само- системы, текстовые редакторы, среды разработки для различных языков про- 7 8 модели. граммирования? 3. На какие виды делят средства для создания информационных систем (CASE-технологии)? Итерационная модель разработки программного обеспечения является поэтапной моделью с промежуточным контролем и содержит обратные связи 4. Приведите классификацию пакетов прикладных программ и их основные тенденции развития. между этапами. Здесь существенно снижается трудоемкость отладки. При обнаружении ошибки на каком-либо из этапов проводится лишь его повторение. Итерационная модель может оказаться неэффективной в случае, когда в про- Тема 2. Понятие жизненного цикла программного обеспечения. Модели цессе разработки были изменены первоначальные требования. жизненного цикла программного обеспечения: каскадная, итерационная, спи- Недостатки итерационной модели заключаются в следующем: ральная. возможное достаточно долгое отсутствие целостного понимания возможностей и ограничений проекта; Каждому этапу разработки ПО должен соответствовать определенный результат и набор документации, являющейся исходными данными для следующего этапа. В заключение каждого этапа должна быть проведена верификация документов и решений с целью проверки их соответствия первоначальным требованиям заказчика. отбрасывание части сделанной ранее работы при итерациях; психологическое давление на разработчиков, возникающее вследствие ощущения, что «всё равно всё можно будет переделать и улучшить позже». Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки Моделью жизненного цикла программного обеспечения называют структуру, определяющую последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. В ходе эволюционного развития теории проектирования программного обеспечения сложились три основные модели жизненного цикла, соответствующие структурного подходу в программировании. Каскадная модель жизненного цикла предполагает переход на каждый следующий его этап только после полного окончания работ на предыдущих этапах. Эта модель широко не оправдалась при разработке больших сложных систем, поскольку затягивала процесс отладки и не давала гарантий безошибочной работы программ. программного обеспечения. В спиральной модели поддерживается итерационная природа, но особое внимание здесь уделяется начальным этапам проектирования. Каждый виток спирали должен соответствовать поэтапной модели создания некоторого фрагмента или некоторой версии программного продукта. А после уточнения целей проектирования и проведения оценки качества планируется следующий виток спирали. Количество этапов жизненного цикла, их последовательность и перечень для каждого программного обеспечения должен определяться на первых этапах проектирования с учетом требований эксплуатации, коллектива разработчиков, а также множества других факторов. Общим набором контрольных точек в сегодняшней спиральной модели являются: Concept of Operations (COO) – концепция использования системы; Альтернативой каскадной модели является модель итеративной и инкрементальной разработки, получившая также от Т. Гилба название эволюционной 9 Life Cycle Objectives (LCO) – цели и содержание жизненного цикла; Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же 10 возможно говорить о готовности концептуальной архитектуры целевой программной системы; граммировании? 5. Что обозначает термин «управление требованиями»? Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации; 6. Какие виды ограничений должны быть выявлены в процессе работы над требованиями для создаваемого программного обеспечения? FinalOperationalCapability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации. Появление и широкое распространение объектно-ориентированного про- Тема 3. Структура приложения, построенного на архитектуре «клиентсервер» граммирования привело к появлению объектно-ориентированного проектирования, которое повлекло за собой и создание модели жизненного цикла. Фирма Rational Software предложила собственную модель жизненного цикла Rational В рамках однопользовательской архитектуры различают: программы; пакеты программ; программные комплексы; программные системы. Objectory Process. ROP-процесс разбит на циклы, каждый из которых состоит из Распространенной многопользовательской архитектурой является «кли- следующих фаз: начальная стадия, разработка, конструирование, ввод в экс- ент-сервер», в которой все задания распределяются между поставщиками ус- плуатацию. Самым главным этапом разработки является описание архитекту- луг, называемыми серверами, и заказчиками услуг, называемыми клиентами. ры, которая включает модель предметной области и технологическую плат- Клиент и сервер взаимодействуют через компьютерную сеть средства- формы, на основе которой эта модель будет реализована. На стадии конструи- ми сетевых протоколов и могут находиться как на разных вычислительных ма- рования создается продукт, готовый к использованию. Как правило, он содер- шинах, так и на одной. В простейшем случае доступ к данным сервера осуще- жит руководство пользователя и имеет возможность применения в требуемых ствляется на уровне файлов, а разделение доступа к файлам обеспечивается платформах. средствами операционной системы. Сервер данных в этом случае выполняет только примитивные функции, предназначенные для хранения, копирования и Вопросы для повторения и самостоятельного изучения защиты данных от несанкционированного доступа. Такие приложения иногда 1. Особенности моделей жизненного цикла программного обеспечения называют построенными по принципу «файл-сервер». Главными их недостат- 2. Жизненный цикл UML ками являются: 3. Управление требованиями. Последовательность работы с требованиями невозможность разделения доступа к данным при их одновременном использовании несколькими пользователями; высокая нагрузка на сеть при передачи данных, в случаях если серверное Вопросы самопроверки 1. На какой из этапов разработки программного обеспечения приходится основная часть расходов жизненного цикла? и клиентские приложения располагаются на различных компьютерах. Полноценное приложение клиент-серверной архитектуры получается при 2. В чем заключаются недостатки каскадной модели жизненного цикла? использовании базы данных (БД), а для хранения данных – системы управле- 3. Какие из моделей жизненного цикла наиболее актуальны? ния базами данных (СУБД), осуществляющую все функции по хранению, дос- 4. Какие модели жизненного цикла используются в структурном про- тупу, резервному копированию данных. СУБД делятся на реляционные, сете- 11 12 вые, и объектно-ориентированные. Кроме того, они разделяются по способам доступа и хранения информации. Вопросы для повторения и самостоятельного изучения 1. Принципы построения современных серверов данных. Многоуровневая архитектура клиент-сервер – разновидность архитекту- 2. Язык описания запросов SQL. ры клиент-сервер, в которой функция обработки данных вынесена на один или 3. Преимущества и недостатки архитектуры «клиент-сервер». несколько отдельных серверов. Это позволяет разделить функции хранения, 4. Технологии взаимодействия с сервером приложений RPC(Remote Pro- обработки и представления данных для более эффективного использования cedure Call, вызов удаленных процедур), MOM (Message Oriented Middleware, возможностей серверов и клиентов. ориентированное на сообщения промежуточное программное обеспечение), Архитектура клиент-сервер широко используется в различных типах се- ORB (Object Request Broker, брокер запросов к объектам). тевых технологий, которые отражаются для доступа к таким сетевым сервисам 5. Особенности разработки программного обеспечения для сети Интернет как: 6. Особенности однопользовательской архитектуры серверы приложений, предназначенные для централизованного решения прикладных задач в некоторой предметной области; серверы баз данных, применяемые с целью обработки пользовательских запросов на языке SQL, в этом случае СУБД принято располагать на сервере, к которому обращаются «клиенты»; Вопросы для самопроверки 1. Что означает понятие архитектура программного обеспечения? Каковы ее виды? 2. Назовите особенности таких однопользовательских архитектур как па- файл-серверы, представляющие пользователям доступ к разделяемым данным и обеспечивающие защиту хранимой информации; серверы удаленного доступа, обеспечивающие соединения по коммутируемым линиям; кеты программ и программные комплексы. 3. Каковы отличия функций сервера приложений и сервера данных? 4. Почему в сети Интернет часто используются интерпретируемые языки? 5. В чем заключается принципиальное отличие динамических веб- прокси-серверы, позволяющие пользователям получить информацию из Интернета, обеспечивая защиту сети, и сохраняющие часто запрашиваемую страниц от статических? 6. Какие виды серверов выделяют? информацию в кэш-памяти локального диска; брандмауэры – межсетевые экраны, анализирующие и фильтрующие се- Тема 4. Разработка технического задания тевой трафик, с целью обеспечения безопасности сети. почтовые серверы, представляющие услуги по отправке и получению Техническое задание – документ, формулирующий основные цели разработки, требования к программному продукту, определяющие этапы разработки электронных почтовых сообщений; web-серверы, представляющие доступ к гипертекстовым документам по протоколу HTTP и поддерживающие расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т.п.). и их конкретные сроки, а также регламентирующие процесс приемо-сдаточных испытаний. В разработке технического задания необходимо участие представителей и со стороны заказчика, и со стороны разработчика. Техническое задание с одной стороны не должно быть слишком подробным, а с другой слишком 13 14 кратким. Его состав и степень проработки определяется в каждом конкретном случае отдельно. Вопросы для повторения и самостоятельного изучения Порядок разработки технического задания: 1. Содержание разделов технического задания. 1. определение набора выполняемых функций и перечня исходных дан- 2. Функциональные и эксплуатационные требования к программному ных; продукту. 2. определение перечня результатов, их характеристик, способов пред- ставления выходных данных; Вопросы для самоконтроля 3. выбор среды функционирования программного обеспечения (версия операционной системы, используемые технические средства и их комплекта- 1. Что включают в себя предпроектные исследования? 2. Изучите представленное в приложение техническое задание. Все ли ция, параметры программного обеспечения, с которым планируется взаимодей- требования стандарты в нем выполнены. Выделите достоинства и недостатки в ствие разрабатываемого программного продукта); этого материала 4. регламент действий программы в случае сбоя работы оборудования, электроснабжения или отказ в работе обеспечивающего программного обеспечения. Тема 5. Модульное проектирование программных средств. Методы Техническое задание разрабатывается в соответствии с требованиями структурного проектирования ГОСТ 2.301 – 68. Для внесения изменений и дополнений в техническое задание на дальнейших стадиях разработки программного обеспечения выпускаются Модульное проектирование является одним из первых подходов к разработке структуры ПО. В нем могут использоваться как методы структурного дополнения к нему. Титульный лист технического задания и лист утверждения оформляются проектирования, так и методы объектно-ориентированного проектирования. Их целью является формирование структуры создаваемой программы – ее разделе- в соответствии с ГОСТ 19. 104 – 78. Техническое задание должно содержать следующие разделы: ние по некоторым установленным правилам на структурные компоненты с по- введение, следующей иерархической организацией данных компонентов. Для различных наименование и область применения, языков программирования такими компонентами могут быть подпрограммы, основание для разработки, внешние модули, объекты и др. Такие методы ориентированы на формирование назначение разработки, структуры программного средства по функциональному признаку. технические требования к программе, К достоинствам модульного проектирования относят: технико-экономические показатели, упрощение разработки ПО; стадии и этапы разработки, отсутствие сильной детализации обработки данных; порядок контроля и приемки, простота этапа сопровождения; приложения. улучшение читаемости и понимания алгоритма работы программ; 15 16 облегчение работы с данными сложной структуры. уровней. На их основе проектируются программные компоненты более высоко- Методы структурного проектирования модульных программ делятся на го уровня, и так продолжается, пока не будет завершена разработка всего про- следующие группы: граммного средства. В чистом виде метод восходящего проектирования ис- нисходящее проектирование, пользуется крайне редко. Основным его недостатком является затраты на раз- методы расширения ядра, работку несущественных, вспомогательных деталей, что затрудняет проектиро- восходящее проектирование. вание ПО в целом. Назначение нисходящего проектирования – разбиение большой задачи При проектировании ПО используется различные способы сочетания ме- на меньшие независимые подзадачи. На начальном шаге в соответствии с об- тодов нисходящего и восходящего проектирования. Например, выделяются щими функциональными требованиями разрабатывается укрупненная структу- ключевые модули промежуточных уровней разрабатываемой программы, даль- ра программного обеспечения, не содержащая детальной проработки отдель- нейшее проектирование которых проводится нисходящим и восходящим мето- ных частей. Затем выделяются функциональные требования более низкого дами одновременно. Другой способ заключается в проектировании модулей уровня, в соответствии с которыми разрабатываются отдельные компоненты, не нижнего уровня, а затем – одновременно нисходящим и восходящим методами. детализированные на предыдущем шаге. Изложенные действия являются ре- В этом случае наиболее важной задачей является согласование интерфейса ме- курсивными, и каждый компонент детализируется до тех пор, пока его состав- жду верхними и нижними уровнями программы, выполняемое в последнюю ные части не будут окончательно уточнены. На каждом из шагов шаге нисхо- очередь, что является существенным недостатком данного. дящего проектирования производится оценка правильности вносимых уточне- При использовании методов расширения ядра создается основная часть ний в контексте правильности функционирования разрабатываемого ПО в це- (ядро) программы. Затем оно постепенно расширяется. Здесь также существует лом. несколько подходов. Первый подход основывается на проектировании струкКомпоненты нижнего уровня ПС называются программными модулями. тур данных, используемых при иерархическом проектировании модулей. Дан- Для модулей характерны достаточная простота и прозрачность, позволяющие ный подход применяется в методах JSP и JSD, разработанных Майклом Джек- выполнять их непосредственное программирование. соном. Второй подход основан на определении областей хранения данных с по- Основными классическими стратегиями, на которых основана реализация метода нисходящего проектирования, являются пошаговое уточнение (раз- следующим анализом связанных с ними функций. Он базируется на методе определения спецификаций модуля, разработанный Парнасом. работана Э. Дейкстрой) и анализ сообщений (стратегия базируется на работах группы авторов – Йодана, Константайна, Мейерса). Стратегии отличаются способами определения начальных спецификаций, требований, методами разбиения задачи на части и правилами записи (нота- Вопросы для повторения и самостоятельного изучения 1. Основные концепции метода JSP Джексона 2. Эксплуатационные требования циями), положенными в основу проектирования. В методах восходящего проектирования в первую очередь выделяются функции нижнего уровня, реализация которых начинается с самых нижних 17 Вопросы самоконтроля 1. Какой из методов проектирования служит средством разбиения боль18 шой задачи на меньшие подзадачи так, чтобы каждую подзадачу можно было диаграммы кооперации, рассматривать независимо? диаграммы деятельностей, 2. При использовании какого из методов проектирования в первую оче- диаграммы состояний объектов, редь реализуются функции нижнего уровня программы, а на основе получен- диаграммы компонентов, ных модулей проектируются программные компоненты более высокого уров- диаграммы размещения. ня? Основное место в объектно-ориентированном подходе к проектированию 3. Каковы основные конструкции данных в методе JSP Джексона? программного обеспечения занимает разработка логической системы в виде диаграммы классов. Тема 6. Анализ требований и определение спецификаций в объектноориентированном подходе Одной из основных диаграмм UML является диаграмма классов, которая чрезвычайна удобна для сопоставления различных вариантов проектных решений. Кроме того, она используется для описания шаблонов проектирования, ко- Для создания моделей анализа и проектирования объектно- торые в сочетании с объектно-ориентированной парадигмой программирования ориентированных программ используются языки визуального проектирования, лежат в основе современного подхода к разработке программного обеспечения. самым популярным из которых является UML – Uniefied Modeling Language. Спецификация программного обеспечения при использовании UML объединяет несколько моделей: На диаграмме класс изображается в виде прямоугольника, состоящего из трех частей, расположенных вертикально. В верхней части указывается имя класса. В средней части приводится список полей, называемых в диаграмме логическую модель, описывающую ключевые понятия проектируемого программного обеспечения, UML атрибутами. Возможно, указание типов и атрибутов полей после двоеточия. Список методов (операций) приводится в нижней части, возможно, с ука- модель реализации, определяющую организацию программных модулей в среде разработке, занием возвращаемого значения. Имена абстрактных классов и операций принято обозначать курсивом. модель процессов, отображающую организацию вычислений, а также по- Перед именами полей и методов указывается спецификатор доступа с помощью зволяющую оценить такие характеристики как производительность, масштаби- одного из трех символов: + для public, - для private, # для protected. Для стати- руемость и надежность программного обеспечения, ческих элементов класса после спецификатора доступа записывается символ $. модель развертывания, показывающую размещение программных компонент на конкретном оборудовании. Во второй и третьих частях могут указываться не все элементы класса, а только представляющие интерес на данном уровне абстракции. Эти части Всего UML включает возможность построения диаграмм девяти типов: могут быть совсем пусты, и в этом случае их можно не указывать (рис. 1). диаграммы вариантов использования, диаграммы классов, диаграммы пакетов, диаграммы последовательных действий, 19 20 Рис. 1. – Примеры диаграммы класса Triangle Существуют следующие отношения между классами: ассоциация, насле- Рис. 3 – Обозначение отношения «наследование» на диаграмме классов дование, агрегация, зависимость. Если два класса взаимодействуют друг с другом концептуально, то их Отношение «агрегация» подразумевает включение в качестве составной взаимодействие называется ассоциацией. На диаграмме ассоциация показыва- части объектов другого класса (отношение целое/часть). На диаграмме такая ется соединительной линией, над которой может быть указана кратность, т.е. связь обозначается стрелкой в виде не закрашенного ромба. При этом стрелка сколько объектов данного класса может быть связано с одним объектом друго- указывает на «целое». В программе для реализации нестрогой агрегации го класса. В случае произвольного количества указывается символ звездочка «часть» включается в «целое» по ссылке. Такой компонент может динамически (рис. 2). появляться и исчезать. Рис. 2. – Обозначение отношения «ассоциация» на диаграмме классов Ассоциация выявляется на ранней стадии проектирования, и в дальнейшем, как правило, конкретизируется. Рис. 4 . – Обозначение отношения «агрегация» на диаграмме классов Строгая агрегация имеет название – композиция. Она означает, что компонент не может исчезнуть, пока объект «целое» существует. Композиция обо- Наследование на диаграмме классов показывается линией со стрелкой в значается линией со стрелкой в виде закрашенного ромба. виде не закрашенного треугольника, которая указывает на базовый класс. Допускается объединение несколько стрелок в одну для разгрузки диаграммы. Рис. 5. – Обозначение отношения «композиция» на диаграмме классов Отношение зависимости (использования) между классами показывает, 21 22 что один класс пользуется некоторыми услугами другого класса. На диаграмме она обозначается пунктирной линией со стрелкой. Рис. 6 – Обозначение отношения «зависимость» на диаграмме классов В зависимости от степени детализации UML предлагает три уровня диаграмм: концептуальный уровень, на котором отображаются связи между основ- Рис. 7. Диаграмма классов ными понятиями предметной области (реализуется на этапе анализа); уровень спецификаций, отображающий связи между классами (создается на этапе проектирования); 3. Изучите диаграмму, представленную на рисунке 8. Ответьте по рисунку на вопросы из предыдущего задания. уровень реализации, непосредственно показывающий элементы конкретных классов (строится на этапе реализации). Вопросы для повторения и самостоятельного изучения 1 Определение прецедентов (вариантов использования). 2 Правила построения диаграмм использования Вопросы самоконтроля 1. Дайте определение понятия «прецедент». 2. Изучите диаграммы классов, представленные на рис. 7. Содержит ли Рис. 8 Пример диаграммы классов представленная диаграмма ошибки? Если да, то в чем они заключаются? Перечислите имена классов, отношения между ними. Каковы отношения между классами? На каком этапе детализации использована данная диаграмма? Тема 7. Проект. Состав и структура коллектива разработчиков, их функции Выполнение проекта предполагает выполнение различных видов работ, отличающихся как по своему назначению, так и по квалификационным требованиям. Функции, выполняемые разработчиками в проекте, делятся на органи23 24 зационные, которые создают условия для выполнения проекта, и производственные, непосредственно реализующие проект. заказчик – реально существующий инициатор разработки или представитель сторонней организации заказчика, уполномоченный принимать текущие и Согласно концепции Microsoft Solution Framework (MSF) выделяются окончательные результаты разработки; группы функций (области функциональной специализации), определены роле- планировщик ресурсов – выдвигающий и координирующий требования к вые кластеры, структурирующие проектные функции разработчиков. К ним от- проектам в организации, осуществляющей данную разработку, а также разви- носятся: вающий и направляющий план выполнения проекта с точки зрения организа- 1. Управление продуктом обеспечивает удовлетворение интересов заказ- ции; чика и содержит области компетенции (области профессиональной специали- менеджер проекта – отвечает за развитие проекта в целом, гарантирует зации), такие как: планирование продукта, планирование доходов, представле- выполнение работ по графику, и соответствие результата исходным требова- ние интересов заказчика, маркетинг. ниям; 2. Управление программой позволяет реализовать проектные решения в руководитель команды – проводит техническое руководство командой, рамках его ограничений. Его области компетенции: управление проектом, его функции могут быть поделены между несколькими руководителями подко- разработка архитектуры решения, контроль производственного процесса, ад- манд, отвечающих за решение частных задач; министративные службы. архитектор – отвечает за проектирование архитектуры системы, согласо- 3. Разработка обеспечивает решения в соответствии со спецификацией. вывает развитие работ, связанных с проектом; Области компетенции кластера: технологическое консультирование, проекти- проектировщик подсистемы – отвечает за проектирование подсистемы рование и осуществление реализации, разработка приложений, разработка ин- или категории классов, определяет реализацию и интерфейсы с другими под- фраструктуры. системами; 4. Тестирование позволяет выявлять и устранять все дефекты проекта до его внедрения. Области компетенции кластера: разработка тестов, отчетность о эксперт предметной области – изучает сферы приложения, поддерживает направленность проекта на решение задач конкретной области; тестах, планирование тестов. разработчик – реализует проектные компоненты, владеет и создает от- 5. Удовлетворение потребителя повышает эффективность использования дельные классы и методы, осуществляет кодирование и автономное тестирова- продукта. Областями компетенции кластера являются: общедоступность, ин- ние, строит продукт; эта роль может быть разделена на специальные роли (на- тернализация, обеспечение технической поддержки, обучение пользователей, пример, разработчик классов, количество которых зависит от сложности проек- эргономика, дизайн. та); 6. Управление выпуском обеспечивает беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера: инфраструктура, сопровождение, бизнес-процессы, управление выпуском готового продукта. Согласно предложению Центра объектно-ориентированной технологии компании IBM структура проекта включает следующие типовые роли: 25 разработчик информационной поддержки – создает сопровождающую документацию, для сложных проектов таких разработчиков также может быть несколько, специалист по пользовательскому интерфейсу – отвечает за удобство применения системы и удовлетворение требованиям заказчика, 26 тестировщик – проверяет функциональность, качество и эффективность продукта, строит и исполняет тесты на каждой фазе развития проекта, библиотекарь – отвечает за создание и ведение общей библиотеки проек- Архитектор и руководитель команды Проектировщик и руководитель та, которая содержит все проектные рабочие продукты, а также за соответствие команды рабочих продуктов стандартам. Менеджер и разработчик В этом перечне характеристика каждой роли определяет производственные функции. Менеджер и специалист по интерфейсу Существует также перечень ключевых ролей для программных проектов: Библиотекарь и разработчик архитектор проекта, проектировщики подсистем, руководители команд разработки подсистем, специалист по пользовательскому интерфейсу, эксперт пред- Тема 8. Тестирование программного обеспечения метной области. Вопросы для повторения и самостоятельного изучения 1. Методологические стратегии – варианты развития проекта разработки программного обеспечения. 2. Принципы построения системы деятельностей программного обеспечения Вопросы самоконтроля 1. Каковы требования к коллективу разработчиков в случае экстремального программирования? 2. В каких случаях возможны совмещения ролей? Является ли это совмещение произвольным? Совмещение каких ролей является невозможным? 3. 3аполните таблицу: Совмещаемые роли Характеристика ролей (возможно, невозможно, нежелательно, допустимо, не допускается и др.) Менеджер и архитектор Менеджер и руководитель команды 27 28 Согласно IEEE Std.610-12.1990 отладкой называют процесс поиска, ло- пользователей. кализации и исправления ошибок в программе. В отечественной литературе К свойствам теста относятся: этот термин используется и для обозначения активности по поиску ошибок детективность – тест должен обнаруживать ошибки с большой вероятно- (тестирование), и для деятельности по нахождению причин их появления и исправлению. стью, покрывающая способность – один тест должен выявлять как можно Тестирование обеспечивает выявление фактов расхождений с требованиями (ошибок). На фазе тестирования осуществляется и исправление идентифицированных ошибок, включающее локализацию ошибок, нахождение причин ошибок. больше ошибок, воспроизводимость – ошибка должна выявляться вне зависимости от изменяющихся условий функционирования программного продукта. Количество тестов, достаточное для проверки программы, определяется Если программа прошла компиляцию, она не содержит синтаксических на основании выбранного критерия. Критерии бывают двух видов: функцио- ошибок и может быть выполнена на компьютере. Судить о правильности или нальные и структурные. К первым относятся: тестирование классов входных и неправильности результатов ее выполнения можно, только сравнивая специфи- выходных данных, тестирование функций. Ко вторым: тестирование команд, кацию желаемой функции с результатами ее вычисления, что и осуществляется тестирование ветвей, тестирование путей. в процессе тестирования. В терминологии профессионального тестирования используются тестиро- Тестирование программного обеспечения может проводиться после за- вание «черного ящика» и тестирование «белого ящика». В первом случае тес- вершения разработки продукта перед передачей его заказчику, либо начинается тировщик имеет доступ к программному обеспечению только через интерфей- в начале проекта и продолжается параллельно с его разработкой. Во втором сы пользователя, а во втором он имеет доступ к исходной программе и может случае трудозатраты значительно выше, но при этом возрастает качество тести- дополнять код, связывая его с библиотеками тестируемого ПО. рования. Аксиомы тестирования: Уровни тестирования: 1. Тест должен быть направлен на обнаружение ошибок, а не на под- 1. Модульное тестирование предполагает тестирование минимально возможной компоненты программы, например отдельного класса или функции. 2. Интеграционное тестирование выявляет проблемы в интерфейсе пользователя или между отдельными компонентами программы. 3. Системное тестирование определяет соответствие системы исходным требованиям и включает: тверждение правильности программы. 2. Автор теста не должен являться автором программы. 3. Тесты разрабатываются одновременно или до разработки программы. 4. Необходимо предсказывать ожидаемые результаты теста до его выполнения и анализировать причины возникших расхождений результатов. 5. Предыдущее тестирование необходимо повторять после каждого ис- альфа-тестирование – имитацию работы реальной работы с системой потенциальных пользователей (заказчиков); бета-тестирование выполняется либо для версии с функциональными ограничениями, либо для получения обратной связи о продукте от его будущих 29 правления программы. 6. Полное тестирование программы следует повторять после внесения изменений или переноса программы в другую среду. 7. В тестировании программы, в которых обнаружено множество оши30 бок, требуется дополнить первоначальный набор тестов. - стандарты (международные, национальные, фирменные), предписывающие принципы и соглашения, которым должны следовать разработчики в Вопросы для повторения и самостоятельного изучения 1. Автоматизация тестирования процессе создания ПО; - рабочие документы, обеспечивающие связь между разработчиками, в 2. Модульное тестирование том числе и временные версии документов, которые в дальнейшем войдут в в 3. Тестирование на основе потока управления состав ПО; 4. Основные принципы тестирования на основе потока данных - заметки и переписка между менеджерами и разработчиками. 5. Метод тестирования тестовых путей Ко второй категории относятся документы, входящие в состав программ- 6. Основные принципы интеграционного тестирования 7. Классификация причин отказов. ного обеспечения: - техническая документация – текст, описывающий аспекты того, что выполняет код ПО; - пользовательская документация описывает принципы и особенности ис- Вопросы самоконтроля 1. Что гласят 5-ая и 6-ая аксиомы Майерса? пользования программного продукта (инструкция или руководство пользовате- 2. Дайте характеристику каждому из критериев выбора теста. ля, руководство программиста); 3. Как соотносятся модульное тестирование и тестирование «белого ящика»? - маркетинговая документация – рекламные материалы, информирующая о возможностях ПО и его отличия с конкурирующими решениями. 4. Перечислите принципы, по которым строятся тесты структурного тестирования. Формальные требования к документации программного обеспечения описаны в ЕСПД – Единой системе программной документации. Стандарты ЕСПД 5. Сравните монолитное и интегральное тестирование. были приняты в конце 70-х годов 20 века. Они содержат требования к составу, 6. Каковы категории тестов в системном тестировании? содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла. Кроме того, несколько документов посвящено Тема 9. Документация по сопровождению программных средств порядку хранения и обновления документации. В состав ЕСПД входят: При разработке программного обеспечения создается и используется разнообразная документация, которая является как средством координации работы разработчиков, так и средством сопровождения программного обеспечения в ходе его эксплуатации пользователем. К первой категории документов относятся документы следующих типов: ГОСТ 19.001-77 Общие положения; ГОСТ 19.002-80 Схемы алгоритмов и программ. Правила выполнения; ГОСТ 19.004-80 Термины и определения; ГОСТ 19.005-85 Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения; - планы, оценки, расписания, отчеты, создаваемые менеджерами для прогнозирования и управления процессами разработки ПО; 31 ГОСТ 19.101-77 Виды программ и программных документов; ГОСТ 19.102-77 Стадии разработки; 32 ГОСТ 19.103-77 Обозначение программ и программных документов; 1. Какой стандарт устанавливает правила оформления экранов (шрифты ГОСТ 19 105-78 Общие требования к программным документам; и цветовая палитра), состав и расположение окон и элементов управления; пра- ГОСТ 19.201-78 Техническое задание. Требования к содержанию и вила использования клавиатуры и мыши; правила оформления текстов помощи; оформлению; перечень стандартных сообщений; правила обработки реакции пользователя? ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению и др. А) ИСО 6385:1981, Эргономические принципы проектирования рабочих систем Наряду с ними используются международные стандарты SO/IEC В) ИСО 6592:1985, Обработка информации. Руководящие указания по 12207:2008 Systems and software engineering – Software life cycle processes – документированию автоматизированных прикладных систем стандарт ISO, описывающий процессы жизненного цикла программного обес- С) ISO/IEC 2382-20:1990, Information technology ~ Vocabulary – Part 20 : печения. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов. Systems development. (Разработка систем) 2. Какой из перечисленных стандартов является стандартом оформления проектной документации? А) ИСО 6385:1981, Эргономические принципы проектирования рабочих Федеральным агентством по техническому регулированию и метрологии систем РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р В) ИСО 6592:1985, Обработка информации. Руководящие указания по ИСО/МЭК 12207-2010 «Информационная технология. Системная и программ- документированию автоматизированных прикладных систем ная инженерия. Процессы жизненного цикла программных средств», идентич- С) ISO/IEC 2382-20: 1990, Information technology ~ Vocabulary - Part 20 : ный международному стандарту ISO/IEC 12207:2008 «System and software Systems development. (Разработка систем) engineering – Software life cycle processes». Стандарты ИСО/МЭК содержат много разумных правил содержательного характера, но сложно представить себе процедуру их формальной проверки. Вопросы для повторения и самостоятельного изучения 1. Содержание стандарта ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению. 2. Содержание стандарта ГОСТ 19.103-77 Обозначение программ и программных документов. 3. Содержание стандарта SO/IEC 12207:2008. Вопросы самопроверки 33 34 Приложение Литература: 1.1 Полное наименование системы 1. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения: учебное пособие / под. Ред. Л.Г. Гагариной. – М.: ИД «Форум», ИНФРА-М, 2008. – 400 с. 2. Брауде Э.Д. Технология разработки программного обеспечения. СПб: Автоматизированная система «ВетУправление». 1.2 Заказчик 1.3 Разработчик 1.4 Перечень документов Перечень документов, на основе которых проектируется система: Питер, 2004. – 659 с. 3. Иванова Г. С., Технология программирования. М.: Изд-во МГТУ им. – федеральные законы; – приказы Минсельхоза РФ; Баумана, 2006 – 334 с. 4. Кане С., Фолк Д., Нгуен Е.К. Тестирование программного обеспече- – устав организации; – должностные инструкции работников организации; ния. Киев: ДиаСофт, 2000. – 544 с. 5. Молчанов А.В., Системное программное обеспечение. – СПб: Питер, – инструкция по ветеринарному учету и ветеринарной отчетности. 1.5 Плановые сроки начала и окончания работы 2010. – 416 с. 6. Скопин И.Н, Основы менеджмента программных проектов. Курс лекций. Учебное пособие для вузов – М: Интуит.РУ, 2004 – 336 с. 7. Павловская Т.А. Программирование на языке C++. М.: ИнтернетУниверситет Информационных Технологий, 2010. – 153 с. 8. Павловская Т. А., Щупак Ю. А. C/C++. Структурное и объектноориентированное программирование: практикум. – СПб: Питер, 2011. – 352 с. Плановые сроки начала и окончания работ по созданию системы: начало разработки – 31.01.2011, окончание – 31.05.2011. 1.6 Сведения о порядке финансирования работ Источником финансирования выступает организация-заказчик – управление ветеринарии с Госветинспекцией Амурской области. Финансирование осуществляется после выполнения работ. Период выполнения – два календарных месяца. 2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ 2.1 Назначение системы Система предназначена для автоматизации работы сотрудников отдела планирования противоэпизоотических мероприятий управления ветеринарии с Госветинспекцией Амурской области, занимающихся осуществлением государственного ветеринарного надзора. Проектируемая система реализует автоматизированное составление отчетной документации, т.к. в управление ветеринарии из районов приходит 35 36 большое количество разнообразной информации. Основные задачи системы: – предупреждение и ликвидация заразных и массовых незаразных болезней животных; – сбор и хранение данных в базу данных; – выборка данных по болезням, вакцинации, поголовью; – обеспечение безопасности продуктов животноводства в ветеринарносанитарном отношении; – формирование отчетов; – защита населения от болезней, общих для человека и животных; – администрирование базы данных. – осуществление государственного ветеринарного надзора в соответст- 2.2 Цели создания системы вии со статьями 8-9 Закона РФ «О ветеринарии» и Положением о государст- На предприятии информация вручную сводится в различные отчеты, венном ветеринарном надзоре в РФ, утвержденным постановлением Прави- что является трудоемкой и время затратной задачей, не исключающей воз- тельства РФ. можные дублирования. Следовательно, необходима автоматизация процес- Управление возглавляет начальник управления, который замещает сов работы, что позволило бы исключить трудоемкий ручной труд специали- высшую группу должностей государственной гражданской службы области стов управления ветеринарии с Госветинспекцией Амурской области и за- категории «руководители», назначается на должность и освобождается от метно сократить бумажный документооборот. должности губернатором области по согласованию с Главным государствен- Цель разработки состоит в переходе от бумажной технологии хранения информации к электронной и, как следствие, упрощении работы сотрудников, увеличении оперативности работы, повышении качества представления информации. Проектирование системы позволит уменьшить затраты времени сотрудников на оформление документов, поиск необходимой информации по различным критериям, составление различных отчетов. Ввод в действие автоматизированной системы приведет к повышению ным ветеринарным инспектором РФ. Начальник является главным государственным ветеринарным инспектором области. В отсутствие начальника его обязанности исполняет заместитель начальника в соответствии с распоряжением губернатора области. Слаженную работу предприятия обеспечивают, выполняя свои функции, все его подразделения и отделы, взаимодействующие друг с другом в соответствии с утвержденными положениями, указаниями и приказами. производительности труда и качества функционирования, а также к повы- Управление является комплексом, обрабатывающим множество раз- шению эффективности процесса за счет использования единой информаци- личных документов, осуществляющим связь с городскими, районными гос- онной базы данных. На практике это приведет к стандартизации вида доку- ветинспекциями. Данная связь организована с помощью ресурсов глобаль- ментов и к более быстрому формированию необходимых отчетов. ной сети Internet. 3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ Для передачи из районов Амурской области необходимых отчетов и Объектом автоматизации является деятельность специалистов отдела другой информации в Управление ветеринарии с госветинспекцией Амур- планирования противоэпизоотических мероприятий управления ветеринарии ской области используется электронная почта. Таким образом, в управление с Госветинспекцией Амурской области, занимающихся осуществлением го- из районов приходит большое количество необходимой информации, кото- сударственного регулирования в сфере ветеринарии. рая обрабатывается и формируется в отчеты: ежемесячные, квартальные, го- Данная деятельность характеризуется следующими задачами: 37 довые. Такие отчеты посредством специализированного сайта и программ38 ного обеспечения VetMonitor 2009 сдаются в ФГУ «Центр ветеринарии» город Москва. – администратор – специалист, осуществляющий обслуживание и настройку системы, обеспечивающий ее работоспособность. Он должен кон- 4 ТРЕБОВАНИЯ К СИСТЕМЕ тролировать правильное функционирование системы, следить за оператив- 4.1 Требования к системе в целом ностью получения информации, устранять возникшие неполадки в системе, 4.1.1 Требования к структуре и функционированию системы иметь расширенные права для просмотра и внесения изменений, составлять Проектируемая система должна быть функционально разделена на не- требуемые отчеты; сколько вложенных в нее подсистем: – пользователь – специалисты, непосредственно работающие с систе- – подсистема ввода данных, представленная понятным для восприятия мой. Квалификация – опытный пользователь. Эта группа сотрудников имеет и удобным для работы интерфейсом, содержащим специальное меню, кото- доступ к данным, т.е. имеет право редактировать, обновлять и удалять необ- рое значительно упрощает работу и сокращает сроки обучения использова- ходимую информацию в БД. Также в их обязанности входит формирование нию данной системы. Также подсистема предназначена для введения ин- отчетов, требуемых для работы; формации в базу данных и заполнения форм документов; – подсистема сопровождения БД, которая представлена программными модулями, состоящими из различных функций и процедур. Осуществляется процесс обработки и хранения данных, т.е. подсистема проверяет соответствие типов входных данных соответствующим типам полей и представляет данные в виде физических таблиц, реализованных в СУБД; – гость – специалисты, имеющие право на ознакомление с отчетными документами в соответствие с правилами и нормами управления. Режим работы пользователей системы определяется режимом работы организации. Перед началом работы с системой пользователям рекомендуется прочитать руководство пользователя. 4.1.3 Требования к показателям назначения – подсистема составления отчетов, представленная в виде выводимой Программное обеспечение автоматизированной системы должно ус- отчётности, генерируемой по различным критериям на основании хранимых тойчиво функционировать при различных конфигурациях программно- и некоторых промежуточных данных; технических средств системы. Должна быть учтена возможность вносить – подсистема администрирования, представленная управлением учет- требуемые изменения в параметры проектируемой системы, для чего всю ными записями пользователей. Данная подсистема позволяет легко управ- информацию необходимо хранить в удобной для изменения форме – базе лять подсистемой администратору, позволяет добавлять, удалять и изменять данных. хранящуюся информацию, а также осуществлять мониторинг работы специалистов. Важными показателями назначения проектируемой системы являются доступность ресурсов ограниченному кругу лиц, что достигается с помощью 4.1.2 Требования к численности и квалификации персонала процесса разграничения доступа. Данный процесс необходим для защиты Проектируемая система не накладывает ограничений на численность информации от различных ошибок, связанных с нарушением целостности и персонала и предназначена для специалистов с базовыми навыками работы на персональном компьютере. Всех пользователей системы можно разделить на группы: непротиворечивости хранимых данных. Также система должна иметь такой показатель как простота эксплуатации, так как многие сотрудники не имеют специального технического обра- 39 40 зования. и стандартизация способов и средств защиты информации. Система должна быть легко масштабируема и пригодна к применению 4.1.6 Требования к эргономике и технической эстетике на протяжении всего срока эксплуатации. 4.1.4 Требования к надежности Проектируемая автоматизированная система должна соответствовать требованиям эргономики и технической эстетики. Требования к надежности подсистемы устанавливаются в соответствии со следующими стандартами: Система должна обеспечивать комфортную работу пользователя в среде самой системы и обеспечивать максимально возможную скорость ввода – ГОСТ 27.002-89 Надежность в технике. Основные понятия. Термины и определения. данных. Интерфейс пользователя не должен вводить в заблуждение, его организация должна быть похожа на организацию интерфейса большинства – ГОСТ 27.003-90 Надежность в технике. Состав и общие правила задания требований по надежности. программных продуктов (главное меню, панель управления, статусная строка, кнопки закрытия и свертывания). Также разрабатываемая система должна Для обеспечения требований к надежности необходимо: выбрать отказоустойчивое оборудование; использовать источник бесперебойного пита- содержать необходимые надписи и пояснения всех имеющихся кнопок, областей ввода, что способствует удобной работе пользователя. ния; выбрать топологию сети, обеспечивающую защищенность от возмож- Отдельные управляющие элементы интерфейса должны быть про- ности вторжения из внешней информационной среды; обеспечить контроль странственно сгруппированы по функциональному назначению. Необходимо за выходными данными ответственным лицом – администратором системы. обеспечить удобную систему ввода с клавиатуры, для чего реализуются раз- 4.1.5 Требования к безопасности личные формы для заполнения. Все перечисленные рекомендации по эрго- Требования к безопасности включают в себя все требования, предъяв- номичности системы должны сопровождаться использованием понятной для ляемые к монтажу, наладке, эксплуатации, обслуживанию и ремонту всех пользователя терминологией. технических средств и требования к безопасности работы операторов ЭВМ (требования к допустимым уровням освещенности, вибрационных и шумо- 4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению комплектов системы вых нагрузок). Пользователи должны быть ознакомлены с правилами эксплуатации Данные требования определены различными стандартами и должны всех технических средств и регламентов работы системы. соблюдаться в организации. Технические средства подсистемы должны быть установлены так, что- В целях предотвращения угроз безопасности надо предусмотреть организацию следующих программно-технических мероприятий: – безопасное хранение перерабатываемых данных; бы обеспечивалась их безопасная эксплуатация и техническое обслуживание. Качественная работа системы обеспечивается только при жестком со- – безопасную работу в режиме обмена данными; блюдении пользователями требований эксплуатационной документации из- – проведение работ с информацией квалифицированным персоналом; делия. Кроме соблюдения норм, предписанных технической документацией, – соблюдение технологических инструкций при работе с данными; для поддержания изделия в работоспособном состоянии должны соблюдать- – лицензирование деятельности в сфере информационной безопасности ся все графики планово-предупредительных мероприятий и профилактик. 41 42 Устройство хранения данных должно быть защищено от внешних фи- 4.1.10 Требования к средствам защиты от внешних воздействий зических воздействий. Для надежного хранения информации в автоматизи- Технические средства системы должны быть надежно защищены от рованной системе будут предусмотрены разграничение прав доступа между физических воздействий, способных вывести из строя части программно- пользователями, а также предусмотрена система паролей. аппаратного комплекса. 4.1.8 Требования к защите информации от несанкционированного доступа Компьютеры должны быть снабжены устройствами бесперебойного питания для предохранения от перепадов напряжения и непредвиденного Автоматизированная система должна соответствовать требованиям к отключения электричества. Также компьютеры, на которых будет установ- защите информации от несанкционированного доступа. Система должна лена автоматизированная система, должны находиться в специально обору- иметь разграничения прав доступа к данным в соответствии с функциями дованных помещениях, в отдалении от отопительных приборов и электриче- пользователя. Необходима защита данных от несанкционированного досту- ских кабелей. па, утери, искажений или других нежелательных действий со стороны зло- 4.1.11 Требования к стандартизации и унификации умышленников. Разработка системы регламентируется следующими стандартами: Для решения проблем информационной безопасности необходимо сочетание законодательных, организационных, технологических и стандартизационных мероприятий. Основное внимание при обеспечении безопасности применения системы сосредоточено на защите от злоумышленных разрушений, искажений и хищений программных средств и информации баз данных. 4.1.9 Требования к сохранности информации при авариях Данные требования заключаются в сохранности информации в случае возникновения аппаратных и программных сбоев, сбоев операционной системы, а также в случае возникновения ошибок пользователей при работе с системой. – ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы; – ГОСТ 24.104-85 Автоматизированные системы управления. Общие требования; – ГОСТ 34.601-90 Автоматизированные системы. Стадии создания; – ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем; – ГОСТ 25861-83 Автоматизированные системы управления. Требования по безопасности средств вычислительной техники; – ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и Специализированные программные средства администратора системы должны обеспечивать: оформлению; – ГОСТ 19.508-79 Руководство по техническому обслуживанию. Тре- – замену технического средства без потери функциональности системы в случае его выхода из строя; бования к содержанию и оформлению; – ГОСТ 7.1-2003 Библиографическое описание документа. Общие тре- – наличие системы дублирования на резервные устройства хранения с последующим восстановлением; бования и правила составления; – ГОСТ 19.102-77 ЕСПД. Стадии разработки; – наличие документов, регламентирующих действия персонала при возникновении нештатных и аварийных ситуаций. 43 – ГОСТ 19.104-78 ЕСПД. Основные надписи; – ГОСТ 19.105-78 ЕСПД. Требования к программным документам, вы44 полненным печатным способом; – защита от несанкционированного доступа к системе; – ГОСТ 19.402-78 ЕСПД. Описание программы. – архивирование, резервное копирование базы данных; 4.2 Требования к функциям, которые выполняются системой – восстановление базы данных. Модуль ввода данных должен выполнять следующие функции: 4.3 Требования к видам обеспечения – ввод сведений о выполнении плана противоэпизоотических меро- 4.3.1 Требования к математическому обеспечению приятий в районных станциях по борьбе с болезнями животных; – ввод сведений о заболеваниях животных (заразных и незаразных); – ввод информации о диагностических исследованиях, прививках и лечебно-профилактических мероприятиях, ветеринарно-санитарных работах; В работе автоматизированной системы «ВетУправление» не используются математические модели и методы. 4.3.2 Требования к информационному обеспечению Информационное обеспечение подразумевает под собой совокупность – ввод сведений о движении и расходовании биопрепаратов на проти- входных и выходных потоков данных. Наиболее важным компонентом ин- воэпизоотические мероприятия, оплачиваемые за счет средств федерального формационного обеспечения является БД системы. В ней содержится ин- бюджета; формация, необходимая для формирования выходных данных. Информация, – ввод сведений о диагностических исследованиях сельскохозяйственных животных, движении диагностикумов по плану мониторинга; – проведение контроля правильности и целостности данных при вводе информации пользователем в базу данных. поступающая в БД, должна быть полной, правдивой и непротиворечивой. 4.3.3 Требования к лингвистическому обеспечению и выбору СУБД Требования к лингвистическому обеспечению включают требования к применению в системе языков взаимодействия пользователей и технических Модуль сопровождения БД должен выполнять следующие функции: средств системы, а также требования к языкам ввода-вывода данных, языкам – хранение данных в базе; манипулирования данными, средствами описания предметной области (объ- – выполнение запросов пользователей системы; екта автоматизации). – быстрый поиск информации в базе данных; – обеспечение целостности и непротиворечивости данных, а также контроль уникальности хранимой информации. Необходимо использование единого логического и понятийного интерфейса для пользователей. Пользовательский интерфейс должен обеспечивать единство представления данных с учетом ограничений, налагаемых Модуль составления отчетов должен выполнять следующие функции: операционными средами, осуществлять взаимодействие с пользователями на – формирование видов отчетной документации за месяц; русском языке, а также предоставлять различного вида отчеты на русском – формирование видов отчетной документации за квартал; языке. Должны быть предусмотрены простые, легкие и удобные в исполь- – формирование видов отчетной документации за полгода; зовании, методы выбора операций для ввода данных, формирования отчетов, – формирование видов отчетной документации за год. выполнения запросов. Модуль администрирования должен выполнять следующие функции: Наиболее целесообразно выбрать в качестве СУБД для написания ав- – аутентификация и идентификация пользователя; томатизированной системы СУБД Firebird. Firebird является кроссплатфор- – обеспечение прав доступа сотрудников; менным продуктом, поддерживающим большое количество операционных 45 46 систем, и отличается чрезвычайно низкими системными требованиями и при этом высокой производительностью. Firebird отвечает всем необходимым требованиям: реализует архитектуру клиент-сервер, работа с данными осу- лов производим в пакете BPWin. Процесс проектирования системы необходимо производить с использованием средства разработки структуры базы данных ERWin. ществляется средствами языка структурированных запросов SQL, распола- 4.3.5 Требования к техническому обеспечению гает необходимыми средствами для распределения прав доступа и т.п. Кроме Регистрация, сбор, обработка, отображение, защита и хранение инфор- того, внедрение, настройка и сопровождение данной СУБД не требует высо- мации осуществляется с помощью персональных компьютеров и специально кой квалификации пользователей и администрирующего персонала. выделенных вычислительных машин – серверов. Для эффективной работы с В то же время, в отличие от других СУБД Firebird имеет версионную документами в организации имеется оргтехника (принтеры, копиры). архитектуру, что позволяет «пишущим» пользователям не блокировать «чи- Так как автоматизированная система будет хранить большое количест- тающих». А так же отсутствие протокола транзакций делает Firebird надёж- во информации и осуществлять быстрый поиск по запросу, то она должна ным и устойчивым сервером (базы данных после сбоя не требуют переин- быть максимальной по быстродействию, иметь большой объем памяти и дексации). Для снижения вероятности конфликтов при многопользователь- дисковое пространство. ском режиме в IB существует оптимистическая блокировка на уровне запи- Используемый сервер должен отвечать следующим требованиям: си. Т.е., сервер блокирует только те записи, которые были реально изменены – процессор Intel Pentium IV от 2 ГГц; пользователем, причём вся страница данных не попадает под блокировку. – объем оперативной памяти от 1 Гбайт; 4.3.4 Требования к программному обеспечению – накопители на жестких магнитных дисках не менее 200 Гбайт; Система должна обеспечивать: – источник бесперебойного питания; – интерфейс взаимодействия с пользователем на доступном языке, по- – сетевая карта для реализации локальной вычислительной сети; нятному пользователю; – устройства ввода информации – клавиатура, мышь. – использование аббревиатур, понятных пользователю; – должны соблюдаться правила написания слов, словосочетаний и законченных предложений; В качестве основных требований к аппаратному обеспечению рабочих станций можно выделить: – минимальный объем оперативной памяти 256 Мбайт; – конкретные сообщения, выводимые на экран не должны вводить в заблуждение пользователя и нести двусмысленную информацию; – представление отчетов пользователю должно предоставляться на русском языке. – общий объем дискового пространства 10 Гбайт; – монитор с разрешающей способностью 1024x768; – жесткий диск – объемом от 60 Гбайт; – рабочая станция должна быть оснащена сетевым адаптером; Информация на экране должна выводиться полностью, без скрытия – источник бесперебойного питания; смысла. Для этого в приложении должны быть предусмотрены специальные – устройства ввода информации – клавиатура, мышь. прокручивающиеся ленты, для полного отображения данных на экране. В качестве операционной системы рекомендуется использовать версию Построение модели информационных потоков предприятия и его отде47 не ниже Windows XP. Выбор данного типа программного обеспечения объ48 ясняется тем, что система Windows XP имеет ряд очень выгодных преимуществ, таких как – высокоразвитый графический интерфейс, что очень ценится пользователями, а также высокое быстродействие и повышенная надежность. 4.3.6 Требования к организационному обеспечению Для работы с автоматизированной системой необходимо разработать руководство пользователя, внести изменения в организационную документацию, а также провести инструктаж сотрудников предприятия. После ввода в действие автоматизированной системы потребуется внесение соответствующих изменений в должностные инструкции сотрудников, которые будут выполнять какие-либо работы с использованием этой системы. Со всеми сотрудниками должен быть проведен инструктаж по работе с вычислительной техникой и инструктаж по работе с персональными данными. Сотрудники должны иметь в распоряжении документацию по работе с системой. Инструктаж по работе с системой проводит разработчик системы или администратор. Татьяна Алексеевна Галаган, доцент кафедры ИиУС АмГУ, канд. техн. наук Технология разработки программного обеспечения. Учебно-методическое пособие Заказ 587. 49
