1 1Определение Требований 4



Скачать 209.48 Kb.
Дата26.07.2014
Размер209.48 Kb.
ТипРеферат
Содержание

Содержание 1

Введение 3

1Определение Требований 4

1.1Предметная область (мне не нравится) 4

1.2Постановка задачи 4

1.3Анализ предметной области 5

1.4Определение требований к программным системам 6

2Проектирование (нужен заголовок) 7

2.1Анализ модифицируемой системы (надо ли вдаваться в технические подробности???) 7

2.2Выбор жизненного цикла разработки системы (пока что поменяла только подписи к рисункам) 8

2.3Выбор модели проектирования (Надо ли это?) 12

2.4Решения по комплексу технических средств (смущают требования) 14

2.5Выбор программных средств 16

19

2.6C# 3.5, ASP.NET 19



2.7MS SQL 2008 Express 19

3Архитектура разрабатываемого приложения 22

3.1Описание и модели архитектуры системы, общее описание принципов функционирования 22

3.2Описание архитектуры пользовательского интерфейса 22

4Описание интерфейса 24

4.1Интерфейс преподавателя 24



ЗАКЛЮЧЕНИЕ 26

ЛИТЕРАТУРА 26

БД — база данных

ВУЗ — высшее учебное заведение

Гб — гигабайт

ЖЦ — жизненный цикл

ИС — информационная система

Мб — мегабайт

ОС — операционная система

ОЗУ — оперативное запоминающее устройство (оперативная память)

ПО — программное обеспечение

ПЭВМ — персональная ЭВМ

СУБД — система управления базами данных

СПБГУАП – Санкт-Петербургский государственный университет аэрокосмического приборостроения

ТЗ — техническое задание

ЭВМ — электронная вычислительная машина


Введение

1Определение Требований



1.1Предметная область (мне не нравится)


Рассматриваемая предметная область – кафедра СПБГУАП и рейтинговая система оценки успеваемости студентов.

1.2Постановка задачи


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

  1. Систему отчетности успеваемости студентов, позволяющую:

  • Добавлять, удалять и редактировать сведения об успеваемости студентов

  • Распечатать ведомость об успеваемости

  • Обеспечить возможность экспорта данных в традиционные форматы

  1. Систему просмотра и редактирования данных о предметах, позволяющую:

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

  • просматривать данные о предметах на web-странице

Для выполнения поставленных задач необходимо:



  • Провести анализ созданного проекта

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

  • Разработать интерфейс взаимодействия пользователя с системой



1.3Анализ предметной области


На основе описания предметной области и поставленной задачи проводится анализ предметной области с целью выявления:

  • Пользователей системы

  • Недостатков системы и способов их устранения

  • Ограничений для разных групп пользователей

Из описания предметной области можно выделить несколько ролей для внешних пользователей системы:



  • Студент – лицо, которое может просматривать информацию о своей текущей успеваемости, данных о предмете.

  • Преподаватель – основное действующее лицо – занимается редактированием успеваемости студентов, их посещаемости занятий, редактированием данных о предмете.

  • Администратор – редактирует список групп, создает резервные копии

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

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

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




1.4Определение требований к программным системам


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

Система отчетности должна быть:



  • универсальной,

  • простой в использовании,

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

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

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



  • просмотра данных,

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

  • удаления невостребованных данных.

Система просмотра методических пособий должна подходить для всех типов файлов, что делает ее универсальной. Также данная система должна иметь простой интерфейс.

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



  • Определение предметной области

  • Проектирование систем

  • Реализация систем


2Проектирование (нужен заголовок)



2.1Анализ модифицируемой системы (надо ли вдаваться в технические подробности???)


Информационная система LabTracker позволила значительно увеличить качество и удобство ведения практических лабораторных занятий в рамках рейтинговой системой ВУЗа. В настоящее время в системе реализован web-интерфейс пользователей, разделенный на 2 группы: преподаватели и студенты.

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

Студенты имеют открытый доступ к данным. При аутентификации пользователя студент выбирает свою группу, имя пользователя (из списка группы) и вводит единый для них пароль – user. Ему выводится на странице баллы за лабораторные работы по тем дисциплинам, которые у него преподаются.

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

Из этих данных можно сделать вывод, что данной системе необходимо усовершенствовать систему методических пособий и создать систему отчетности с экспортом данных в различные форматы.

2.2Выбор жизненного цикла разработки системы (пока что поменяла только подписи к рисункам)

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

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

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:



  • каскадная модель (70-85 г.г.);

  • спиральная модель (86-90 г.г.).

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

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






image336

Рис. 1. Каскадная модель ЖЦ


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

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

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

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

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






Рис. 2. Спиральная модель ЖЦ

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



2.3Выбор модели проектирования (Надо ли это?)

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



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

  • метод потоков данных;

  • объектно-ориентированное проектирование.

В 60-70-е годы было разработано много методов, помогающих справится с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху вниз. Метод был непосредственно основан на топологии традиционных языков высоко уровня типа FORTRAN или COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное программирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на более мелкие. Необходимо отметить, что большинство существующих программ написано, по-видимому, в соответствии с этим методом. Тем не менее, структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный подход не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектно-ориентированных языках программирования.

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

Объектно-ориентированное проектирование (object-oriented design, OOD) – это подход, в основу которого положено представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию. Объектно-ориентированный подход отражает топологию языков высокого уровня, таких как Delphi, C++ и C#.

Общая концепция ИС предполагает реализацию совокупности объектов и их взаимодействие, поэтому реализацию системы было решено создавать на базе объектно-ориентированного подхода с применением языка высокого уровня C# 3.5.



2.4Решения по комплексу технических средств (смущают требования)

Среди всего множества критериев отбора технических средств нас интересуют:



  • достаточный объем оперативного запоминающего устройства сервера;

  • достаточный объем накопителя на жестком магнитном диске сервера;

  • приемлемый тип видеоадаптера и дисплея для работы пользователя;

  • достаточная производительность центрального процессора сервера;

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

  • достаточная скорость передачи данных в локальной сети;

  • приемлемая стоимость составляющих комплекса технических средств.

Объем необходимого ОЗУ рассчитывается, исходя из размеров памяти, занимаемой загружаемой операционной системой, из необходимого объема памяти, выделяемого под драйверы для обслуживания ЭВМ, программы-оболочки, основного загружаемого модуля программного комплекса, динамических библиотек, подгружаемых по мере выполнения программы и резерва памяти для обработки информации.

Исходя из вышеизложенного, приходим, что для нормальной работы системы необходимо не менее 512 Мбайт ОЗУ (1024 Мбайт рекомендуется). По современным понятиям, это уже не слишком высокое требование объясняется тем, что для нормальной работы, выбранной в качестве рекомендуемой ОС системы Windows 2003 необходимо не менее 256 Мбайт оперативной памяти.

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

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

Скорость передачи данных в ЛВС зависит от выбранного сетевого программного и технического обеспечения. Парк применяемых машин на предприятии заказчика оснащен Ethernet-адаптерами и прочими сетевыми устройствами со скоростью передачи данных 100Mбит/сек. Учитывая достаточность этой скорости для работы системы, принято решение использовать имеющиеся средства.

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


Сервер (минимальные требования):

  • процессор не хуже Pentium IV 1ГГц

  • объем ОЗУ не менее 512 Мб

  • объем жесткого диска не менее 10 Гб (свободно не менее 1ГБ)

  • Сетевая карта

Клиент:

  • процессор не хуже Pentium II 400 МГц

  • объем ОЗУ не менее 128 Мб;

  • графический адаптер не хуже SVGA 8 Мб;

  • монитор не хуже SVGA 0.26, 15 дюймов

  • cетевая карта


2.5Выбор программных средств


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

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

При выборе средства программирования и генерации отчетов необходимо определить основные требования:


  • Удобство разработки / модификации – т.е. является ли генератор встроенным приложением или отдельным программным продуктом, требующим внедрения

  • Экспорт в различные форматы – позволяет расширить возможности отчетности

  • Печать отчетов

  • Стоимость – крайне важный параметр при ограниченном бюджете ВУЗа.

В таблице 1 дана сравнительная характеристика всех выбранных для анализа ИС.

Табличка будет!
При просмотре таблицы 1 можно сделать вывод, что оптимальным программным средством для разрабатываемой ситсемы отчетности является Microsoft Reporting Services. Данный компонент является встроенным в Visual Studio 2008, он поставляется в комплекте с SQL Server, который предоставлен в бесплатной Express-версии, соответственно тоже является бесплатным, он предоставляет возможность экспортирования данных в Excel и PDF, печать сформированных отчетов.

В процессе выбора модели проектирования был выбран объектно-ориентированный подход и язык программирования C# 3.5 и следующие средства:



  • СУБД – MS SQL Server 2008 Express

  • IDE – MS Visual Studio 2008 Express

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

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

AJAX


ASP.NET

LINQ


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


2.6C# 3.5, ASP.NET


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

В качестве языка программирования для разработки системы может использоваться язык C# 3.5, который был выбран при выборе модели проектирования

Полная интеграция с СУБД MS SQL Server 2008

Полная поддержка спецификации IE 7.0, как наиболее используемого веб-браузера

Язык C# 3.5 был выбран как наиболее подходящий для разработки в связи с выбором объектно-ориентированного подхода к проектированию системы и позволяющий, использовать все возможности .NET Framework, ASP.NET и LINQ , фактически являясь частью этих технологий.

2.7MS SQL 2008 Express


Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

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

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

Снимок: Производится «снимок» базы данных, который сервер отправляет получателям.

История изменений: Все изменения базы данных непрерывно передаются пользователям.

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


В SQL Server 2008 встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2008, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

Основаниями для выбора стали следующие свойства SQL Server 2008:

Бесплатность SQL Server 2008 Express

Полная поддержка .NET Framework

Полная интеграция с используемой средой разработки MS Visual Studio 2008

3Архитектура разрабатываемого приложения



3.1Описание и модели архитектуры системы, общее описание принципов функционирования



3.2Описание архитектуры пользовательского интерфейса


Взаимодействие пользователя с системой производится с помощью web-интерфейса, который предоставляет полную функциональность всей системы, а также некоторую дополнительную информацию. Схема компонентов модуля web-интерфейса представлена на рис. 3

Элементы общего дизайна системы

(Design)

Клиентские скрипты

(Scripts)

Базовые формы интерфейса (BaseForms)

Пользовательские элементы управления (UserControls)

Ядро приложения

(Core)
Рис. 3. Схема компонентов модуля web-интерфейса

Модуль состоит из следующих компонентов:

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

Scripts – набор клиентских скриптов, написанных на языке JavaScript, используемых для взаимодействия со сложными элементами управления системы;

UserControls – набор пользовательских серверных элементов управления, используемых в интерфейсе системы;

BaseForms – набор базовых web-страниц и мастер страниц, составляющих основной интерфейс приложения.



4Описание интерфейса



4.1Интерфейс преподавателя


В связи с тем, что основным пользователем системы является преподаватель, то именно часть интерфейса, предназначенная для работы с этим пользователем, содержит наибольшее количество элементов.

Общий вид рабочей страницы преподавателя изображен на рис. 4. Отображение посещаемости студентов производится на этой же странице путем выбора пользователем вкладки «Посещение» в центральной части основного рабочего пространства (рис. 5)



Вид страницы выставления оценок

main

Рис 24



Вид страницы редактирования посещения студентов

teacherattendance3

Рис 25










ЗАКЛЮЧЕНИЕ



ЛИТЕРАТУРА




  1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес - Gang of Four, Приемы объектно-ориентированного проектирования, паттерны проектирования – издательство Питер, 2007;

  2. Мартин Фаулер, Рефакторинг, улучшение существующего кода – издательство Символ-Плюс, 2007;

  3. Эрик Аллен, Типичные ошибки проектирования – издательство Питер, 2003;

  4. Дж. Рамбо, М. Блаха, UML 2.0, объектно-ориентированное моделирование и разработка – 2е издание, издательство Питер, 2007.

  5. Д. Крёнке, Теория и практика построения баз данных – издательство Питер, 2005;

  6. Ричард Веймаер, Microsoft SQL Server 2000 – издательский дом Вильямс, 2001.

  7. Г. Шилдт, C# - учебный курс - издательство Питер, 2003;

  8. Джеффри Рихтер, CLR via C#: программирование на платформе .NET 2.0 на языке C# – издательство Питер, 2007;

  9. Мэтью Мак-Дональд, Марио Шпушта, Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов – издательский дом Вильямс, 2006;

  10. Дино Эспозито, Знакомство с ASP.NET 2.0 – издательство Питер, 2006;

  11. Дино Эспозито, ASP.NET 2.0 углубленное изучение – издательство Питер, 2007;

  12. О.Н. Рева, JavaScript – издательство Эксмо, 2007.

  13. Shakhgeldyan C., Kryukov V. Integration of University Information Resources into the Unified Information Environment // Proceedings of the 10-th International Conference of European University Information Systems . Slovenia, 2004.

  14. “СанПиН 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы”, Госкомсанэпиднадзор России, 1996, 43 с.






Похожие:

1 1Определение Требований 4 icon1 1Определение Требований 4
Описание и модель системы отчетности, общее описание принципов функционирования 21
1 1Определение Требований 4 icon1 1Определение Требований 4
Описание и модель системы отчетности, общее описание принципов функционирования 22
1 1Определение Требований 4 iconПисьмо Министерства образования и науки РФ от 24 января 2008 г. N ик-137/03 "О перечне государственных требований к минимуму содержания и уровню требований к специалистам для получения дополнительных квалификаций на 31 декабря 2007 года"
Нтября 2000 г. N 2571, зарегистрированным Минюстом России 24 октября 2000 г. N 2424, Минобрнауки России направляет для использования...
1 1Определение Требований 4 icon10-Анализ требований к аис
Разумеется, ведь в нём сосредоточено развёрнутое описание основных требований к автоматизированной информационной системе, которую...
1 1Определение Требований 4 iconЗарегистрировано в Минюсте РФ 9 февраля 2012 г. Регистрационный n 23191
Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра
1 1Определение Требований 4 iconВерификация программных требований к по. Инструменты автоматизации этапа
По и в спецификации требований к функциональным компонентам низкого уровня, которые удовлетворяют требованиям высокого уровня; 8
1 1Определение Требований 4 iconO услуги и продукты конкурирующих компаний сотовой связи
Необходимо соблюдение технических требований к приложениям, разработанным для операционных систем Android, Symbian,Java (ссылки на...
1 1Определение Требований 4 iconПроверено 14 филиалов и 4 состава экспертных бюро фгу «Главное бюро мсэ по Амурской области»
...
1 1Определение Требований 4 icon2. Деятельность по систематическому наблюдению за исполнением обязательных требований
А соблюдением владельцами лицензии (лицензий) на осуществление деятельности в области оказания услуг электросвязи установленных обязательных...
1 1Определение Требований 4 iconГрафик проверок соблюдения членами Некоммерческого партнерства «Саморегулируемая организация «Объединение Волго-Вятских Строителей»
Требований к выдаче Свидетельств о допуске к работам, которые оказывают влияние на безопасность объектов капитального строительства,...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org