Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств»




НазваниеМетодические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств»
страница2/5
Дата19.01.2013
Размер0.72 Mb.
ТипМетодические указания
1   2   3   4   5
5. Оформление результатов

К представляемым руководителю основным составляющим курсового проекта относятся:

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

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

  • титульный лист;

  • оглавление;

  • задание на курсовое проектирование;

  • результаты анализа существующей системы в виде документопотоков, ха­
    рактеризующих технологический процесс обработки информации;

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

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

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

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

  • функциональная архитектура программной системы;

  • алгоритмы модулей в виде схем действий;

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

  • документированные тексты исходных программных модулей;

  • план приемо-сдаточных испытаний программного изделия;

  • результаты тестирования (прогона контрольного примера);

  • расчет экономической эффективности;

  • руководство пользователя;

  • другие документы (по согласованию с преподавателем);

  • список использованной литературы;

  • приложения (например, словарь системы).

При оформлении курсового проекта необходимо руководствоваться следую­щим:

  • все материалы оформляются на бумаге стандартного формата А4 на одной
    стороне, рукописно или машинописно, с оставлением полей, все страницы должны
    быть пронумерованы;

  • в случае набора пояснительной записки на компьютере рекомендуется
    шрифт №№ 12, 14, формат набираемого материала 17,5 х 24 см (длина строки, вы­
    сота печатаемого текста), поля: левое - 2 см, правое - 2 см, верхнее - 2 см, нижнее
    - 2 см;

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




  • каждое приложение должно снабжаться заголовком вида: слово
    "ПРИЛОЖЕНИЕ", его порядковый номер и наименование, отражающее содержание
    данного приложения;

  • титульный лист курсового проекта должен соответствовать типовой форме
    (см. прилож. 2).

6. Организация защиты

В ходе курсового проектирования руководитель принимает защиту промежу­точных материалов.

К подобным промежуточным материалам относятся:

- технико-экономическое обоснование целесообразности разработки систе-

мы;

техническое задание;

архитектура программной системы;

логическая схема базы данных;

словарь системы;

демонстрация работы ядра (прототипа) системы;

спецификации модулей системы;

демонстрация работы отдельных модулей;

документированные тексты программ;

расчет экономической эффективности;

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

план приемо-сдаточных испытаний.

10

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

По результатам приема каждого промежуточного материала студенту разъяс­няются ошибки и недоработки, требующие исправления.

Подведение итогов курсового проектирования включает следующие этапы:

  • сдача курсового проекта (пояснительной записки) на проверку руководителю;

  • проведение приемо-сдаточных испытаний системы;

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

  • сдача готового курсового проекта;

  • защита курсового проекта.

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

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

Срок доработки проекта устанавливается руководителем с учетом сущности замечаний и объема необходимой доработки.

Курсовой проект, удовлетворяющий предъявляемым требованиям, допускает­ся к защите в день и час, назначенные руководителем.

Оценка проекта производится с учетом:

  • соответствия продемонстрированных на испытаниях возможностей систе­
    мы требованиям, зафиксированным в техническом задании;

  • полноты и качества разработанных проектных и эксплуатационных доку­
    ментов;

  • соблюдения международных и государственных стандартов при разработ­
    ке и оформлении программных и информационных средств;

  • исполнения требований госстандартов и кафедры к оформлению поясни­
    тельной записки;

  • практической полезности разработанной системы;

  • качества ответов на вопросы при защите.

ЛИТЕРАТУРА

  1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с
    англ. - М.: Радио и связь. 1985. - 512 с.

  2. Венчковский Л.Б. Разработка сложных программных изделий: Учеб. Посо­
    бие для вузов / Под ред. В.А. Машурцева; ГУУ.- М.: ЗАО "Финстатинформ", 1999.-
    109с.

  3. Гейн К., Сарсон Т. Структурный системный анализ: средства и методы: Пер.
    с англ. Ч. 1,2. - М.: "Эйтекс", 1993.

  4. Липаев В.В. Документирование и управление конфигурацией программных
    средств. Методы и стандарты. Серия "Информатизация России на пороге XXI века".-
    М.:СИНТЕГ, 1998.-220с.

  5. Липаев В.В. Системное проектирование сложных программных средств для
    информационных систем. Серия "Информатизация России на пороге XXI века".- М.:
    СИНТЕГ, 1999.-224с.

  6. Человеческий фактор: Пер. с англ.. (т. 6. Эргономика в автоматизированных
    системах). - М.: Мир, 1992.

11

Приложение 1

1. Содержание работ по курсовому проектированию

1.1. Общие замечания

Работы по курсовому проектированию проводятся в соответствии с этапами жизненного цикла программного изделия (ЖЦПИ) и характеризуются последова­тельным уточнением принимаемых проектных и управленческих решений. Это озна­чает, что процесс разработки принципиально является итерационным как в части планов, так и в определении функций системы, показателей качества, архитектуры программного объекта.

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

13О 12207: 1995. Процессы жизненного цикла программных средств.

18О 9000-3: 1991. Общее руководство качеством и стандарты по обеспечению качества.

15О 9126: 1991. Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению.

Укрупненно этапы ЖЦПИ (при использовании каскадной модели) включают:

  • определение требований пользователя (заказчика);

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

  • архитектурное проектирование программного изделия;

  • детальное проектирование программного изделия;

  • изготовление программного изделия;

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

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

  • определение потребностей заказчика;

  • оценка осуществимости концепции новой системы и исследование возмож­
    ных вариантов решений;

  • технико-экономический анализ альтернативных вариантов и обоснование
    выбора автоматизированной информационной системы;

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

  • распределение функций между элементами системы и между ее подсисте­
    мами;

  • создание описания информационной системы и формулирование требова­
    ний к программному изделию.

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

На основе согласованного с заказчиком (преподавателем) технического зада­ния на разработку начинается детальное проектирование программного изделия: алгоритмизация, кодирование, тестирование и отладка. Результаты этого комплекса работ должны быть представлены в пояснительной записке в виде схем алгоритмов модулей, соответствующих им прокомментированных программ, а также необходи­мой эксплуатационной документации. Курсовой проект должен быть представлен в виде функционирующей информационной системы и его аттестация проводится на ЭВМ в соответствии с планом приемо-сдаточных испытаний.

12

1.2. Определение требований пользователя

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

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

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

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

  1. Требования, отражающие возможности системы, реализация которых обес­
    печивает решение поставленной проблемы.

  2. Требования, определяющие ограничения на способы и пути решения про­
    блемы или на пути достижения поставленной цели.

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

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

Каждое требование пользователя должно описываться следующими атрибу­тами:

  1. Идентификатор, позволяющий проследить выполнение каждого ус­
    тановленного требования через все фазы ЖЦПИ.

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

13

3. Стабильность требования, указывающая степень его постоянства на
протяжении ЖЦПИ. При этом должны быть отмечены те требования, которые могут
быть изменены в результате получения в процессе проектирования новой информа­
ции или в результате накопления опыта эксплуатации.

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

  1. Источник возникновения требования должен указываться либо в виде
    ссылки на конкретный внешний документ, либо на пользователя (группу пользовате­
    лей), который установил это требование.

  2. Проверяемость требования, предполагающая, что каждое требова­
    ние должно поддаваться проверке выполнения. Это необходимо для возможного
    контроля того, что требование включено в проект и реализовано программными
    средствами и для тестирования этого требования.

7. Ясность формулировки, означающая определенность и однозначность
требования и отсутствие какой-либо неопределенности,

1.3. Анализ осуществимости разработки программного изделия
Одновременно с исследованием существующей информационной системы и

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

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

Второй фазой ЖЦПИ является фаза определения требований к программному изделию, которая является фазой "анализа проблемы". Главной целью этой фазы является разработка полной, непротиворечивой и корректной совокупности требо­ваний к программному обеспечению на основе всестороннего изучения требований пользователя. За выработку этих требований всегда отвечает разработчик. В каче­стве участников этой фазы должны привлекаться пользователи, инженеры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение этой работы, как правило, назначается системный аналитик. Руководитель проекта организует взаимные консультации и обсуждения, поскольку участники этих обсуждений могут иметь разное представле­ние о конечном продукте и их взгляды должны синтезироваться в четкие и непроти­воречивые формулировки требований.

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

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

14

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

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

1.4.2. Разработка логической модели программного изделия

Как уже отмечалось, разработчик должен сконструировать логическую модель проектируемого программного изделия, независимую от последующей физической реализации, которая должна отражать требования пользователя. Эта модель ис­пользуется для выработки совокупности требований к программному обеспечению. Существующие структурные методологии используют для построения модели прин­цип нисходящей декомпозиции основной функции программного изделия в иерархию функций с последовательной детализацией функции на следующих уровнях иерар­хии. Средством логического моделирования является структурный системный ана­лиз, позволяющий подробно описывать схемы потоков данных, которые будут су­ществовать при функционировании автоматизированной системы (программного продукта). Для описания схем потоков данных используются компоненты: источ­ник/приемник данных, линия потока данных, хранилище данных, блок обработки данных.

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

Логическая модель должна удовлетворять следующим правилам:

  1. Каждая функция в модели должна отражать единственную и четко опреде­
    ленную цель. Имена функций должны определять, что должно быть сделано, а не
    как сделано.

  2. Функции должны соответствовать уровню иерархии, на котором они пред­
    ставлены в модели.

  3. Связи между функциями (функциональными блоками модели) должны быть
    минимизированы.

  4. Каждая функция должна разделяться не более чем на 7 подфункций сле­
    дующего уровня.

  5. В модели не должна присутствовать информация, связанная с последую­
    щей реализацией изделия, например, такие понятия, как модуль, файл, запись и т.п.

  6. Для каждой функции должны быть указаны входные данные.

  7. Каждой функции должен соответствовать список выходных данных (выход­
    ных отчетов).

1.4.3. Классификация требований к программному изделию Требования к программному изделию должны быть систематизированы в со­ответствии со следующими категориями:

15

  1. Функциональные требования. Они определяют,
1   2   3   4   5

Похожие:

Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания по курсовому проектированию по дисциплине «страхование»
Методические указания к курсовому проектированию по дисциплине «Страхование» / Сост. Н. П. Сахирова, гуу. М., 2008. – 63 с
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания к по курсовому проектированию для студентов специальности 130404 очного и заочного обучения
Технология подземной разработки месторождений: Метод, ука­зания по курсовому проектированию для студентов специ­альности 130404 «Подземная...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания к курсовому и дипломному проектированию по дисциплине «Технология и механизация строительства горных выработок»
Методические указания к курсовому и дипломному проектированию по дисциплине “Технология и механизация строительства горных выработок”...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания по курсовому проектированию на тему: «Пожарная безопасность в строительстве»
Методические указания по курсовому проектированию на тему: «Пожарная безопасность в строительстве» (для всех форм обучения специальности...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания к курсовой работе по дисциплине "Оборудование роботизированных производств" Ростов-на-Дону 2007
Методические указания к курсовому проектированию по дисциплине "Оборудование автоматизированных производств": Метод, указания /дгту,...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания к курсовому проектированию по дисциплине "проектирование автоматизированных систем управления непрерывными технологическими процессами" Часть 2
...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания к расчетно-графической работе по курсу «Основы построения микропроцессоров»
Методические указания к курсовому проектированию по дисциплине "Основы построения микропроцессоров" /Ю. Т. Котов. 1-е изд. – М.:...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconК курсовому проектированию по курсу «водоснабжение города»
Методические указания к курсовому проектированию по курсу «Водоснабжение города» (для студентов 2-3 курсов всех форм обучения, а...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconУчебно-методический комплекс по дисциплине разработка и стандартизация программных средств и информационных технологий
Спецкурс «разработка и стандартизация программных средств и информационных технологий» нацелен на формирование у будущих учителей...
Методические указания к курсовому проектированию по дисциплине «Эконо­мика, разработка и использование программных средств» iconМетодические указания по курсовому проектированию для студентов направления 071900 Составители: А. Е. Докторов
Р 17 курсовому проектированию для студентов направления 071900 / Сост.: А. Е. Докторов, Е. А. Докторова. – Ульяновск: Улгту, 2000....
Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница