Оформление результатов
К представляемым руководителю основным составляющим курсового проекта относятся: -разработанная программная система на подписанной дискете, -пояснительная записка, содержащая вышеотмеченный набор проектных и эксплуатационных документов (системные и пользовательские документы - согласно утвержденного в техническом задании перечня). Материалы в пояснительной записке следует размещать в следующем порядке: - титульный лист; - оглавление; - задание на курсовое проектирование; - результаты анализа существующей системы в виде документопотоков, ха - технико-экономическое обоснование осуществимости и целесообразности - требования к программному изделию; результаты системного структурного анализа в виде схем потоков данных с подробной детализацией и описанием логики отдельных функций; логическая схема базы данных с описанием структур всех таблиц и словарь метаданных; - функциональная архитектура программной системы; - алгоритмы модулей в виде схем действий; техническое задание на разработку программного изделия (может включать перечисленные выше материалы); - документированные тексты исходных программных модулей; - план приемо-сдаточных испытаний программного изделия; - результаты тестирования (прогона контрольного примера); - расчет экономической эффективности; - руководство пользователя; - другие документы (по согласованию с преподавателем); - список использованной литературы; - приложения (например, словарь системы). При оформлении курсового проекта необходимо руководствоваться следующим: - все материалы оформляются на бумаге стандартного формата А4 на одной - в случае набора пояснительной записки на компьютере рекомендуется - таблицы, схемы и прочий графический материал должны иметь название и
- каждое приложение должно снабжаться заголовком вида: слово - титульный лист курсового проекта должен соответствовать типовой форме Организация защиты В ходе курсового проектирования руководитель принимает защиту промежуточных материалов. К подобным промежуточным материалам относятся: - технико-экономическое обоснование целесообразности разработки систе- мы; техническое задание; архитектура программной системы; логическая схема базы данных; словарь системы; демонстрация работы ядра (прототипа) системы; спецификации модулей системы; демонстрация работы отдельных модулей; документированные тексты программ; расчет экономической эффективности; отдельные проектные и эксплуатационные документы; план приемо-сдаточных испытаний. 10 Промежуточные материалы представляются и защищаются студентами в сроки, установленные в техническом задании. По результатам приема каждого промежуточного материала студенту разъясняются ошибки и недоработки, требующие исправления. Подведение итогов курсового проектирования включает следующие этапы: - сдача курсового проекта (пояснительной записки) на проверку руководителю; - проведение приемо-сдаточных испытаний системы; - доработка проекта с учетом замечаний руководителя; - сдача готового курсового проекта; - защита курсового проекта. Курсовой проект должен быть сдан на проверку в срок, указанный в задании (не позднее предпоследней недели учебных занятий в семестре). Приемо-сдаточные испытания разработанной системы могут проводиться по мере ее готовности, но не позднее последней недели учебных занятий в семестре. Срок доработки проекта устанавливается руководителем с учетом сущности замечаний и объема необходимой доработки. Курсовой проект, удовлетворяющий предъявляемым требованиям, допускается к защите в день и час, назначенные руководителем. Оценка проекта производится с учетом: - соответствия продемонстрированных на испытаниях возможностей систе - полноты и качества разработанных проектных и эксплуатационных доку - соблюдения международных и государственных стандартов при разработ - исполнения требований госстандартов и кафедры к оформлению поясни - практической полезности разработанной системы; - качества ответов на вопросы при защите. ЛИТЕРАТУРА 1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с 2. Венчковский Л.Б. Разработка сложных программных изделий: Учеб. Посо 3. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы: Пер. 4. Липаев В.В. Документирование и управление конфигурацией программных 5. Липаев В.В. Системное проектирование сложных программных средств для 6. Человеческий фактор: Пер. с англ.. (т. 6. Эргономика в автоматизированных 11 Приложение 1 Содержание работ по курсовому проектированию 1.1. Общие замечания Работы по курсовому проектированию проводятся в соответствии с этапами жизненного цикла программного изделия (ЖЦПИ) и характеризуются последовательным уточнением принимаемых проектных и управленческих решений. Это означает, что процесс разработки принципиально является итерационным как в части планов, так и в определении функций системы, показателей качества, архитектуры программного объекта. Последовательность этапов разработки и содержание работ определяются мировой практикой создания программных систем, которые нашли отражение в ряде международных стандартов: 13О 12207: 1995. Процессы жизненного цикла программных средств. 18О 9000-3: 1991. Общее руководство качеством и стандарты по обеспечению качества. 15О 9126: 1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению. Укрупненно этапы ЖЦПИ (при использовании каскадной модели) включают: • определение требований пользователя (заказчика); • определение требований к программному изделию; • архитектурное проектирование программного изделия; • детальное проектирование программного изделия; • изготовление программного изделия; • эксплуатация и сопровождение программного изделия. Первые три этапа соответствуют системному проектированию новой информационной системы. Методологической основой этого раздела работ служит системный анализ, основными целями которого являются: • определение потребностей заказчика; • оценка осуществимости концепции новой системы и исследование возмож • технико-экономический анализ альтернативных вариантов и обоснование • определение трудозатрат на проектирование и разработку программной • распределение функций между элементами системы и между ее подсисте • создание описания информационной системы и формулирование требова Результаты этих исследований оформляются в виде отдельных документов и служат основой и обоснованием пунктов технического задания и входят в качестве приложений к техническому заданию. На основе согласованного с заказчиком (преподавателем) технического задания на разработку начинается детальное проектирование программного изделия: алгоритмизация, кодирование, тестирование и отладка. Результаты этого комплекса работ должны быть представлены в пояснительной записке в виде схем алгоритмов модулей, соответствующих им прокомментированных программ, а также необходимой эксплуатационной документации. Курсовой проект должен быть представлен в виде функционирующей информационной системы и его аттестация проводится на ЭВМ в соответствии с планом приемо-сдаточных испытаний. 12 1.2. Определение требований пользователя Первая фаза жизненного цикла связана с подробным определением решаемой проблемы. Цель этой фазы - определить задачу, которая должна быть выполнена с использованием компьютера, а также определить, что предполагается получить в результате автоматизации. Основным видом деятельности в этой фазе является обследование объекта автоматизации, сбор и тщательное документирование требований пользователей. Сбор требований пользователя к будущей автоматизированной системе осуществляется путем обследования существующей технологии обработки данных (обычно путем изучения документопотоков), путем опроса специалистов, специально проводимыми интервью с пользователями. Поскольку по мере сбора требования могут изменяться, уточняться и добавляться, то вся эта деятельность в общем случае представляет собой итеративный процесс, предполагающий многократные повторения с целью достижения все большей детализации, четкости и однозначности в формулировке каждого требования, а также достижения полноты охвата всех требований пользователя. Первым шагом в определении требований пользователя должно быть определение операционной обстановки, т.е. должна быть выработана ясная картина реальной обстановки, в которой будет функционировать разрабатываемый программный продукт. Повествовательное описание окружающей обстановки и условий работы целесообразно дополнить схемами потоков документов и указать связи с внешними по отношению к рассматриваемой системами. Все требования пользователей удобно разделить на две группы. 1. Требования, отражающие возможности системы, реализация которых обес 2. Требования, определяющие ограничения на способы и пути решения про Требования первой группы описывают функции и операции, необходимые пользователю. Важную часть в этих требованиях составляют атрибуты точности. Во многих случаях появляются временные и пространственные требования, которые целесообразно представить в виде последовательности выполняемых операций, в виде регламента подготовки выходных документов с указанием периодичности и времени их выдачи с привязкой к соответствующим документам. Требования-ограничения могут включать требования использования определенных форм документов для взаимодействия с другими системами, стандартных описаний данных, форматов, а также требования применения определенных компьютеров, операционных систем и т.п. Для диалоговых систем пользователь может пожелать, например, использовать определенные экранные формы или шаблоны, специальные средства помощи, создаваемые программными средствами. Ограничения могут включать и требования качественного типа. Защита данных от несанкционированного доступа, приспособленность изделия к адаптации, переносимость в другие операционные среды - все это может быть отнесено к требованиям-ограничениям. При этом пользователь должен подробно описать потери, порождаемые нарушением подобных требований, чтобы разработчик мог критически оценить каждое требование. Каждое требование пользователя должно описываться следующими атрибутами: 1. Идентификатор, позволяющий проследить выполнение каждого ус 2. Уровень важности, устанавливаемый в соответствии со шкалой 13 3. Стабильность требования, указывающая степень его постоянства на 4. Приоритет, указывающий определенную временную последователь 5. Источник возникновения требования должен указываться либо в виде 6. Проверяемость требования, предполагающая, что каждое требова 7. Ясность формулировки, означающая определенность и однозначность 1.3. Анализ осуществимости разработки программного изделия объекта информатизации проводится анализ осуществимости и экономико-социальной целесообразности разработки программного изделия, проводится предварительная оценка технико-экономических показателей проектируемой системы, сроков и стоимости разработки, возможных рисков. Проводится сравнительный анализ альтернативных вариантов решения проблемы автоматизации. 1.4. Определение требований к программному изделию Второй фазой ЖЦПИ является фаза определения требований к программному изделию, которая является фазой "анализа проблемы". Главной целью этой фазы является разработка полной, непротиворечивой и корректной совокупности требований к программному обеспечению на основе всестороннего изучения требований пользователя. За выработку этих требований всегда отвечает разработчик. В качестве участников этой фазы должны привлекаться пользователи, инженеры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение этой работы, как правило, назначается системный аналитик. Руководитель проекта организует взаимные консультации и обсуждения, поскольку участники этих обсуждений могут иметь разное представление о конечном продукте и их взгляды должны синтезироваться в четкие и непротиворечивые формулировки требований. Основным выходным результатом этой фазы жизненного цикла является формализация функций программного изделия, установление характеристик системы и среды, в которой система должна будет функционировать. Эта фаза должна дать ответ на вопрос, что должен делать программный продукт, а также как будет осуществляться проверка правильности и полноты выполняемых функций как на этапах проектирования, так и при проверке конечного продукта. Работы на этой фазе выполняются в соответствии с планом, разработанным на предыдущем этапе. Основная деятельность - это транссрормация требований пользователя в требования к программному изделию и составление подробного описания того, что должно выполнять программное изделие. Подготавливаемый документ должен отражать взгляд разработчика на решаемую проблему. Этот взгляд базируется на логической модели системы обработки данных, построенной на основе использования 14 структурного системного анализа потоков данных. В соответствии с принятой методологией логическая модель изображается в виде совокупности схем потоков данных с последовательной пошаговой детализацией функций разрабатываемой системы. Основной задачей на этом этапе является согласование представлений и требований пользователя (заказчика) и разработчика программного изделия. Многоуровневая схема потоков данных, созданная в результате структурного системного анализа разрабатываемой информационной системы включается вместе со словарем данных и соответствующим описанием в качестве приложения к техническому заданию. Выработка требований к программному изделию может потребовать сосадания прототипа для проверки, пояснения или уточнения требований и их согласования с заказчиком. 1.4.2. Разработка логической модели программного изделия Как уже отмечалось, разработчик должен сконструировать логическую модель проектируемого программного изделия, независимую от последующей физической реализации, которая должна отражать требования пользователя. Эта модель используется для выработки совокупности требований к программному обеспечению. Существующие структурные методологии используют для построения модели принцип нисходящей декомпозиции основной функции программного изделия в иерархию функций с последовательной детализацией функции на следующих уровнях иерархии. Средством логического моделирования является структурный системный анализ, позволяющий подробно описывать схемы потоков данных, которые будут существовать при функционировании автоматизированной системы (программного продукта). Для описания схем потоков данных используются компоненты: источник/приемник данных, линия потока данных, хранилище данных, блок обработки данных. Процесс структурного анализа осуществляется по функциональным уровням. Прежде, чем переходить к детальному рассмотрению следующего уровня необходимо провести сквозной просмотр всех спецификаций каждого функционального блока данного уровня, чтобы убедиться в согласованности всех требований. Обычно число уровней не превышает 3-4-х. Логическая модель должна удовлетворять следующим правилам: 1. Каждая функция в модели должна отражать единственную и четко опреде 2. Функции должны соответствовать уровню иерархии, на котором они пред 3. Связи между функциями (функциональными блоками модели) должны быть 4. Каждая функция должна разделяться не более чем на 7 подфункций сле 5. В модели не должна присутствовать информация, связанная с последую 6. Для каждой функции должны быть указаны входные данные. 7. Каждой функции должен соответствовать список выходных данных (выход 1.4.3. Классификация требований к программному изделию Требования к программному изделию должны быть систематизированы в соответствии со следующими категориями: 15 1. Функциональные требования. Они определяют, что должно 2. Эксплуатационные требования. Они определяют значения Количественные требования не должны фиксироваться в виде качественных характеристик типа "быстрый ответ", а должны быть записаны, например, в виде "время ответа должно быть не более X сек", или вместо "в большинстве случаев" должно быть указано "для У% случаев среднее время ответа должно быть менее 2 сек" и т. п. Атрибуты эксплуатационных характеристик могут быть также представлены в виде диапазона значений. 3. Требования к интерфейсам. Эти требования описывают эле Требования к интерфейсам могут быть проиллюстрированы с помощью специальных структурных схем, описывающих взаимодействие программного изделия с окружающей обстановкой. 4. Операционные требования. Они определяют, как система бу 5. Требования к ресурсам. Они обычно устанавливают верхние 6. Требования на верификацию программного изделия и на 7. Требования к защите информации. Они включают требо 8. Требования к качеству. Они определяют специфические атрибу 16 Такие показатели качества, как надежность программного изделия, пригодность его к сопровождению, безопасность описываются отдельно. 9. Требования к надежности. Они определяются либо значением 10. Требования на пригодность к сопровождению. Они могут Эти требования должны быть по возможности представлены количественными показателями, такими, как время исправления отказа или коэффициент готовности. Они могут также включать ряд ограничений, отражающих возможности организации, занятой сопровождением. 11. Требования к безопасности. Они могут определять ряд до 12. Требования к документации. Они обычно дополняют требо 1.4.4. Атрибуты требований к программному изделию Каждое требование к программному изделию после всестороннего изучения и согласования должно быть документировано. При этом описание каждого требования должно включать следующие атрибуты: 1) идентификатор, обеспечивающий возможность контроля реализа 2) уровень важности, указывающий, насколько существенным явля 3) приоритет, указывающий некоторый порядок очередности в выполне 4) стабильность, отражающая степень постоянства требования. Долж 5) пригодность к верификации, означающая возможность про При описании требований особое внимание должно быть уделено ясным и четким формулировкам, обеспечивающим однозначную интерпретацию каждого требования. В перечне требований к программному изделию должны быть учтены все требования пользователя и для каждого возможного набора входных данных должны быть точно описаны действия, выполняемые программным изделием. Наконец, совокупность требований должна содержать непротиворечивые требования. Несогласованность требований может возникать при использовании разных терминов для описания одинаковых сущностей и, наоборот, один и тот же термин - для описания разных предметов. Другим источником несогласованности могут быть случаи, когда одновременно должны выполняться несовместимые действия или выполняться в недопустимой последовательности. Противоречивость требова- 17 ний может проявиться и в случае дублирования требований, особенно, когда одно требование перекрывает другое. 1.4.5. Документ «Требования к программному изделию» Выходным материалом рассматриваемой фазы исследований должен быть документ «Требования к программному изделию». Главным показателем качества этого документа является полнота охвата требований пользователя. Для контроля и доказательства полноты в документ целесообразно поместить таблицу (матрицу), показывающую, как требования пользователя соотносятся с требованиями к программному обеспечению. Таблица позволяет организовать трассировку требований как вручную, так и с использованием автоматизированных средств. Непротиворечивость описания требований должна проверяться и при проведении критического обзора документа. Основными в документе являются функциональные требования, которые структурируются по нисходящему принципу с последовательной детализацией требований предыдущего, более высокого уровня. Нефункциональные требования должны быть подключены к функциональным, поэтому они могут появиться на всех уровнях иерархии функциональной декомпозиции. Документ не должен включать описания деталей реализации программного изделия, т.е. функциональные требования должны отражать лишь то, что должен выполнять программный продукт. Многие из функциональных требований вытекают из схем потоков данных, которые являются результатом структурного системного анализа проектируемого продукта. При этом схема потоков данных верхнего уровня дает общий обзор функций будущего изделия. В документе каждое требование, снабженное идентификатором и атрибутами степени важности и приоритета, должны иметь ссылку на документ «Требования пользователя для облегчения обратной трассировки». Документ «Требования к программному изделию» должен быть написан на естественном языке. В рассмотрении и критическом обзоре этого документа, кроме разработчиков, принимают участие пользователи, операционный персонал и менеджеры, поэтому стиль и форма изложения требований должна быть понятна всем участникам этой фазы. Вместе с тем при описании ряда специфических требований может потребоваться использовать формальные языки описания спецификаций, которые позволяют описать требования более строго без нежелательных неточностей и многозначности естественного языка. В этом случае формальное описание (например, в виде таблиц или деревьев решений и т.п.) должно быть дополнено пояснениями на естественном языке. Все установленные требования к программному изделию включаются в соответствующий раздел технического задания. 1.5. Архитектурное проектирование программного изделия 1.5.1. Общее содержание работ фазы Фаза архитектурного проектирования может быть названа фазой "принятия решения". Цель этой фазы - определить совокупность компонент программного изделия и их интерфейсы, чтобы дать каркас для последующей разработки программного изделия. Архитектурный проект должен охватывать все требования, сформулированные на предыдущей фазе. За определение архитектурного проекта несут ответственность инженеры -разработчики программного обеспечения. Во время выполнения работ они могут консультироваться с другими специалистами и представителями заказчика, а опера- 18 ционный персонал должен провести обзор архитектурного проекта. Выходным результатом этой фазы является документ «Архитектурный проект», который должен документировать каждую компоненту программного изделия и ее связи с другими компонентами. Документ считается завершенным, когда уровень описания компонент и их интерфейсов достаточен для того, чтобы над каждой из них могли независимо работать отдельные исполнители или их небольшие группы во время следующей фазы детального проектирования. Рассматриваемая фаза ЖЦПИ заканчивается формальным утверждением документа «Архитектурный проект» после всестороннего его рассмотрения и критического обзора. Деятельность на этой фазе выполняется в соответствии с планами, разработанными на предыдущей фазе. Основным видом деятельности во время этой фазы является разработка и документирование архитектурного проекта. Эта деятельность включает: - конструирование физической модели программного изделия; - описание требований к архитектурному проекту; - выбор языка программирования; - обзор проекта. 1.5.2. Конструирование физической модели Разработчик должен сконструировать физическую модель, описывающую проект программного изделия, используя терминологию разработчика. Физическая модель должна быть выведена из логической модели, описанной в «Требованиях к программному изделию». При трансформации логической модели в физическую принимаются проектные решения, связанные с распределением функций по компонентам и определением входов и выходов каждой компоненты. Проектные решения также должны удовлетворять и нефункциональным требованиям, критериям качества проекта и соображениям технологической реализуемости. Все проектные решения должны фиксироваться документально. Моделирование - это итеративный процесс. Необходимо после описания каждой части проекта повторно возвращаться к описанию предыдущих частей, пока не будет достигнуто ясного и точного описания каждой компоненты. Для построения модели в последние годы стали использоваться средства автоматизации, позволяющие получить непротиворечивую модель более простую для конструирования и модификации. 1.5.3. Декомпозиция программного изделия на компоненты Программное изделие должно быть представлено в виде иерархии компонент в соответствии с методами функциональной декомпозиции. Все компоненты должны располагаться по уровням иерархии и каждая компонента при этом должна занимать точно определенное место. Функциональная декомпозиция осуществляется с помощью метода нисходящего проектирования. Как уже отмечалось, нисходящая декомпозиция является важным средством для управления сложностью. Кроме этого, она реализует принцип "сокрытия информации", требуя, чтобы компоненты нижнего уровня рассматривались как "черные ящики" для компонент более высокого уровня. Это означает, что для верхнего уровня известны только функции и интерфейсы компонент более низкого уровня, а особенности их внутреннего функционирования остаются неизвестными. Нисходящее проектирование также требует, чтобы каждый уровень проекта был описан с использованием терминов, отражающих степень абстракции, соответствующую данному уровню. Компоненты нижнего уровня проекта должны быть достаточно независимы, чтобы дать возможность проводить независимое и параллельное их дальнейшее 19 детальное проектирование и кодирование с минимальными взаимосвязями между программистами. Документ «Требования к программному изделию» содержит множество групп нефункциональных требований, поэтому проектирование каждой компоненты должно включать ее анализ с точки зрения требований каждой из этих групп. Однако при этом следует учитывать, что к разным компонентам могут иметь отношение лишь некоторые из этих групп. 1.5.4. Критерии качества архитектурного проекта Архитектурный проект должен быть понятным, простым для модификации и обеспечивать высокую эффективность программного изделия. Эффективность определяется минимальным использованием имеющихся ресурсов, а простота модификации - снижением затрат на сопровождение. Для достижения этих целей обычно стремятся упрощать форму и функции каждой части архитектурного проекта. Для измерения сложности имеется ряд метрик, которые целесообразно использовать при проектировании. Функциональная простота характеризуется "связностью" отдельных компонент, т,е, внутренней структурой компоненты. При проектировании стремятся максимизировать связность каждой компоненты. Простота формы достигается в результате: - минимизация "сцепления" между компонентами; - обеспечения соответствия функции, выполняемой компонентой, уровню ие - согласования программного обеспечения со структурами данных; - максимизации числа компонент, использующих данную компоненту; - ограничения числа подчиненных компонент; - удаления дублирования между компонентами путем создания новых компо Архитектурный проект должен быть модульным с минимальным сцеплением между компонентами и с максимальной связностью внутри каждой компоненты. Компоненты модульной схемы должны описываться как "черные ящики", скрывая информацию о их внутренней структуре от других компонент. Важно знать, что они делают, а не как они работают. Для упрощения понимания при описании проектов всегда должны использоваться стандарты и соответствующая терминология, для решения одинаковых проблем всегда должны использоваться одинаковые решения. Для достижения единообразия и сопоставимости описаний разных частей проекта необходимо использовать стандарты на проектирование, СА8Е-средства и систематические обзоры проектных решений. Выбор альтернативных решений может явиться хорошим и эффективным средством повышения качества проекта. Для выбора лучшего варианта необходимы соответствующие критерии, которые зависят от типа системы. Например, для системы реального времени важным является время ответа или время реакции системы, а для административной системы - стабильность базы данных. Для оценки альтернативных вариантов или для проверки сделанных допущений может использоваться прототип изделия. Н
Популярное: Генезис конфликтологии как науки в древней Греции: Для уяснения предыстории конфликтологии существенное значение имеет обращение к античной... Как вы ведете себя при стрессе?: Вы можете самостоятельно управлять стрессом! Каждый из нас имеет право и возможность уменьшить его воздействие на нас... ©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (150)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |