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




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

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

    Количественные требования не должны фиксироваться в виде качественных характеристик типа "быстрый ответ", а должны быть записаны, например, в виде "время ответа должно быть не более X сек", или вместо "в большинстве случаев" должно быть указано "для У% случаев среднее время ответа должно быть менее 2 сек" и т. п.

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

    3. Требования к интерфейсам. Эти требования описывают эле­
    менты технических средств, программного обеспечения, баз данных, с которыми
    должен взаимодействовать программный продукт. Требования к интерфейсам с тех­
    ническими средствами могут определять необходимую их конфигурацию. Требова­
    ния к программному обеспечению могут включать требования к типу и версии опе­
    рационной системы, прикладным пакетам, типу СУБД. Требования к внешним ин­
    терфейсам могут потребовать, например, использования конкретного сетевого про­
    токола передачи информации, определенного языка описания документов и т.п.

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

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

    1. Требования к ресурсам. Они обычно устанавливают верхние
      пределы для характеристики технических средств, таких как скорость процессора,
      емкость внешней и оперативной памяти и т.д.

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

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

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

    16

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

    9. Требования к надежности. Они определяются либо значением
    допустимого среднего времени между отказами, либо значением минимального
    времени между отказами.

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

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

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

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

    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Е-средства и систематические обзоры про­ектных решений.

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

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

    , 20

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

    1.6. Детальное проектирование и изготовление программного изделия

    1.6.1. Основные виды деятельности

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

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

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

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

    • нисходящая декомпозиция;

    • структурное программирование;
      -одновременное изготовление и документирование.

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

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

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

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

    21

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

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

    • начинаем с функциональной спецификации и спецификации интерфейсов;

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

    • откладываем объявление данных до фазы кодирования;

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

    • проводим обзор каждого шага после его выполнения.

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

    1.6.2. Кодирование модулей

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

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

    • наименования программ, подпрограмм, файлов, переменных;

    • ограничения размеров модулей;

    • использования библиотек;

    • определения констант;

    • использования специальных средств компилятора, которых нет в языке;

    • обработки ошибок и т.п.

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

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

    Код должен быть структурным, так как это уменьшает ошибки и улучшает со-провождаемость.

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

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

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

    22

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

    1.6.3. Тестирование программного изделия

    Процесс тестирования включает несколько этапов: поблочное тестирование, комплексное тестирование и системное тестирование.

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

    При тестировании блоков обычно проверяется правильность не только того, что функционально выполняет модуль, но и того как он это делает. Таким образом^ при тестировании блоков используется не только функциональное тестирование (тестирование "черного ящика"), но и структурное тестирование (тестирование "бе­лого ящика").

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

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

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

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

    Системное тестирование - это процесс тестирования интегриро­ванного программного изделия. Этот этап тестирования может быть выполнен в процессе разработки или в условиях моделирования эксплуатации. Системное тес­тирование должно подтверждать соответствие разработанного программного изде­лия целям, установленным в документе «Требования пользователя».

    Системное тестирование включает такие виды деятельности:

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

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

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

    • предварительная оценка надежности и пригодности к сопровождению;

    • проверка правильности «Руководства пользователя».

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

    23

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

    1.6.4. Документирование работ по проектированию программного изделия

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

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

    Часть 2 документа постепенно расширяется по мере разработки проекта.

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

    Основным требованием, предъявляемым к содержанию документа является его завершенность, т.е. полный охват всех требований к программному изделию, изложенных в соответствующем документе. В связи с этим документ «Детальный проект» должен содержать таблицу перекрестных ссылок между отдельными требо­ваниями к программному изделию и компонентами детального проекта.

  • 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
    обратиться к администрации
    Библиотека
    Главная страница