Программирование методов принятия решений

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Оглавление

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

Введение

1. Основные этапы процесса принятия решений

1.2 Основные понятия и определения

1.3 Классификация задач принятия решений

1.4 Методы поддержки принятия решений

2. Анализ этапов создания программных продуктов с использованием стандартов ГОСТ и ISO

2.1 Международный стандарт ISO/IEC 12207

2.2 Стандарт ГОСТ 34.601-9018

2.3 ГОСТ 19.102-77

3. Выбор методов принятия решений для нахождения наиболее рационального решения на каждом этапе проектирования

3.1 Этап выбора проекта реализации при проведении научно-исследовательских работ

3.2 Этап выбора языка программирования

3.3 Этап выбора тестового обеспечения

4. Разработка алгоритмов, реализующего выбранные методы поддержки принятия решения

5. Выбор языка программирования

5.1 Характеристика языка программирования C#

5.2Роль платформы .NET

6. Описание программных средств для решения задач ВКР

6.1Описание фреймворка ASP.NET

6.2 Общие сведения о веб-страницах ASP.NET

6.3 Платформа ASP.NET MVC

7. Создание пробной версии программы

7.1 Разворачивание веб-приложения, реализованного с помощью технологии ASP.NET MVC и Framework 4.0 на бесплатном ASP.NET хостинге somee.com

7.2 Тестирование работоспособности приложения

7.3 Требования к аппаратным средствам для оптимальной работы приложения

7.4 Безопасность системы

Вывод

Список литературы

Приложение



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

1. Исходные данные

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

2. Выходные данные

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

3. Ограничения, накладываемые на входные данные

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

4. Актуальность поставленной задачи:

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

5. Обзор аналогов

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



Введение

Термин «принятие решений» встречается во многих научных дисциплинах: экономике, психологии, исследовании операций, прикладной математике и др. Все они изучают правила, механизмы и особенности поведения людей в процессе принятия решений. В течение дня каждый из нас может принимать десятки решений, большинство из которых мы принимаем автоматически. Говоря «решение», мы понимаем под этим либо процесс выбора одного или нескольких вариантов действий из множества возможных, либо результат выбора определенного варианта. В обоих случаях решение - это выбор альтернативы, т.е выбор одного из нескольких взаимоисключающих друг друга варианта ,а также каждый из этих вариантов. Теорию принятия решений можно воспринимать как совокупность знаний, позволяющих анализировать со всех сторон принципы и методы, применяемые лицами, принимающих решения, а также, их организационные формы, принципы регулирования и организации труда и суть решений. Принятие решений сопровождает человечество на протяжении всей истории его существования, но все то, что относилось к выбору рациональных решений, долго не являлось наукой. Это был всего лишь набор правил, в которых учитывался опыт человека или субъективное представление того или иного лица.

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



1. Основные этапы процесса принятия решений

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

Сформулировав задачу принятия решений, переходят к поиску решения (этап4). Эта стадия включает в себя, во- первых, подбор некоторого метода решения задачи из уже известных или разработку нового метода; во-вторых, собственно сам процесс решения, состоящий в оценке и анализе различных вариантов решения и выборе среди них наиболее предпочтительного. В ряде задач получение окончательного результата не представляет больших трудностей. Однако чаще это достаточно сложные и трудоемкие процедуры, требующие привлечения знаний и умения многих людей и возможностей современной вычислительной техники. Вместе с тем, даже пройдя все этапы процесса решения проблемы, не всегда оказывается возможным сделать окончательный выбор. Встречаются ситуации, когда не удается найти лучшее решение. Нужного варианта может просто не быть в наличии. Тогда можно либо изменить формулировку исходной проблемы, либо возвратиться на предыдущие этапы и собрать необходимую дополнительную информацию, внести изменения в формальную постановку задачи или модель проблемной ситуации, расширить или сузить число рассматриваемых альтернатив, сконструировать новые варианты. В любом случае проделанный поиск лучшего варианта решения, даже если он не привел к положительному результату, не будет бесполезным. Он может натолкнуть на новое понимание рассматриваемой проблемы, обратить внимание на какие-то новые аспекты, которые необходимо учесть, указать на иные пути решения задачи. Если приемлемый вариант найден, наступает стадия исполнения решения (этап 5), на которой происходит реализация принятого решения, осуществляется контроль над процессом реализации и оценивается результат разрешения проблемной ситуации. Строго говоря, эта стадия не относится к процедуре принятия решения. Однако включение исполнения решения в общую структуру важно с методологической и практической точек зрения, так как эта стадия замыкает жизненный цикл процесса возникновения, разрешения и исчезновения проблемной ситуации. А кроме того, реализация принятого решения может породить новую проблему, требующую поиска своего решения.



1.2 Основные понятия и определения

(ЛПР) - Лицо, принимающее решение в теории принятия решений - субъект решения, наделённый определёнными полномочиями и несущий ответственность за последствия принятого и реализованного решениях

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

Бывает что ЛПР и владелец проблемы - разные люди.

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

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

Альтернатива - необходимость выбора одного из двух(нескольких) возможных решений. программный государственный стандарт фреймворк

Критерий - мерило оценки, суждения.

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

Решение -- это выбор альтернативы.

1.3 Классификация задач принятия решений

Классификация задач ПР в зависимости от степени полноты и достоверности информации :

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

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

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

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

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

1.Многоцелевой характер. Бывает что при принятии решений, ЛПР может преследовать несколько целей одновременно, при этом цели могут противоречить друг другу. В таких случаях при достижении одной цели, ухудшается результат по другой. В результате ЛПР вынужден выбирать между целями, которые противоречивы.

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

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

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

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

6. Динамические аспекты. В результате принятия некоторого решения, возможен итог, при котором задача не будет полностью выполнена и решение придется принимать ещё раз спустя какое-то время. Очень важно определять такие аспекты проблемы заранее, чтобы увидеть все возможные результаты, которые откроются в будущем благодаря выбранному решению.

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

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

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

1.4 Методы поддержки принятия решений

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

рис 1.(методы поддержки принятия решений)

Индивидуальные методы принятия решений

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

· Простая приоритезация: выбор альтернативы с наибольшей вероятностно-взвешенной полезностью.

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

· Уступка авторитету или «эксперту»: исполнение приказа или распоряжения

· Антиавторитаризм: принятие наиболее противоположных действий в сравнении с советом не имеющих доверия властей или авторитетов.

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

· Автоматизированная поддержка решения: установка критериев для автоматизированных решений.

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

Групповые методы принятия решений.

· Метод консенсуса

· Методы, основанные на голосовании

· Метод Дельфи.

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

2. Анализ этапов создания программных продуктов с использованием стандартов ГОСТ и ISO

Анализ стандартов в IT .

Рассмотрим какие бывают стандарты в области IT.

1. Международные. Главный признак - принят международной организацией ISO. Пример стандарта : ISO 15288 ("Системная инженерия"). Так же существуют совместные стандарты ISO и IEC -международной электротехнической комиссии(МЭК).Например ISO/IEC 30170:2012 (Информационные технологии. Языки программирования. Ruby)

2. Региональные. Главный признак - принимается комиссией по стандартизации в регионе. В настоящее время большая часть советских ГОСТ'ов являются региональными, т.к. они приняты советом(межгосударственным), в состав которых входят бывшие советские республики. Этим же советом принимаются и новые стандарты ГОСТ. Пример: ГОСТ 18421-93

3. (Аналоговая и аналого-цифровая вычислительная техника)

4. Стандарты общественных объединений. К ним можно отнести стандарты IEC(МЭК): 61850 (автоматизация электрических под-станций)

5. Национальные стандарты. В России обозначаются как ГОСТ Р.

Существует 3 типа ГОСТ Р стандартов

1. точные копии региональных или международных.

2. копии региональных или международных с дополнениями. Сначала указывается отечественный стандарт и к нему приписывается номер международного, который взяли за основу. Например: ГОСТ Р ИСО/МЭК 9126-93 (Информационная технология. Оценка программной продукции)

3. Национальные стандарты. ГОСТ Р 53624-2009

4. (Информационные технологии. Информационно-вычислительные системы. Программное обеспечение)



2.1 Международный стандарт ISO/IEC 12207

Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

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

В Российской федерации применяется ГОСТ Р ИСО-МЭК 12207-2010(последняя редакция 2010 года).Как нам уже известно ГОСТ Р ИСО-МЭК - это копия международного стандарта ISO с дополнениями .Его полное название : ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств".

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

Основные термины и определения, используемые в ГОСТ:

1.заказчик (customer): Организация или лицо, получающие продукт или услугу. Примечание 1 - Заказчик может быть внутренним или внешним по отношению к организации. Примечание 2 - Адаптировано из ИСО 9000:2005. Примечание 3 - Другие термины, используемые для термина "заказчик": "приобретающая сторона", "розничный покупатель", "оптовый покупатель".

2.разработчик (developer): Организация, которая выполняет разработку задач (в том числе анализ требований, проектирование, приемочные испытания) в процессе жизненного цикла. Примечание - В настоящем стандарте термины "разработчик" и "исполнитель" являются синонимами.

3.основные средства (facility): Физические устройства или оборудование, способствующие выполнению действий, например, здания, инструменты, принадлежности

4.жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.

5.проект (project): Попытка действий с определенными начальными и конечными сроками, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями. Примечание 1-Адаптировано из ИСО 9000:2005. Примечание 2 - Проект может рассматриваться как уникальный процесс, включающий в себя скоординированные и управляемые виды деятельности, а также может быть комбинацией видов деятельности из процессов проекта и технических процессов, определенных в настоящем стандарте.

6.задача (task): Требование, рекомендация или разрешенное действие, предназначенное для содействия достижению одного или более выходов процесса

7.тестовое покрытие (test coverage): Степень, с которой данный тест проверяет требования для системы или программного продукта.

8.пользователь (user): Лицо или группа лиц, извлекающих пользу из системы в процессе ее применения.

9.версия (version): Идентифицированный экземпляр составной части.

2.2 Стандарт ГОСТ 34.601-90

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

1. Система: Совокупность элементов, объединенная связями между ними и обладающая определенной целостностью.

2. Автоматизированный процесс: Процесс, осуществляемый при совместном участии человека и средств автоматизации.

3. Автоматический процесс: Процесс, осуществляемый без участия человека.

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

5. Алгоритм: Конечный набор предписаний для получения решения задачи посредством конечного количества операций.

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

7. Автоматизированный производственный комплекс:

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

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Описывает следующие стадии:1)Формирование требований к АС. 2) Разработка концепции АС. 3)Техническое задание. 4)Эскизный проект. 5)Технический проект. 6)Рабочая документация. 7)Ввод в действие.8)Сопровождение АС.

Этапы работ в ГОСТ 34.601-90 и ГОСТ 19.102-77 соответствуют процессам в ISO/IEC 12207.

Сопоставление разных стандартов (ГОСТ и ISO/IEC) показывает, что они в принципе регламентируют одни и те же работы при создании ПО. Но все же в отечественных разработках целесообразно использовать современные международные стандарты.

2.3 ГОСТ 19.102-77

Табл. 1 (Основные Стадии разработки, этапы и содержание работ по ГОСТ 19.102-77).

Стадии разработки	Этапы работ	Содержание работ
1.Техническое задание	Обоснование необходимости разработки программы	Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы Обоснование необходимости проведения научно-исследовательских работ
	Научно-исследовательские работы	Определение структуры входных и выходных данных Предварительный выбор методов решения задач Обоснование целесообразности применения ранее разработанных программ Определение требований к техническим средствам Обоснование принципиальной возможности решения поставленной задачи
	Разработка и утверждение технического задания	Определение требований к программе Разработка технико-экономического обоснования разработки программы Определение стадий, этапов и сроков разработки программы и документации на нее Выбор языков программирования Определение необходимости проведения научно-исследовательских работ на последующих стадиях согласование и утверждение технического задания
2. Эскизный проект	Разработка эскизного проекта	Предварительная разработка структуры входных и выходных данных Уточнение методов решения задачи Разработка общего описания алгоритма решения задачи Разработка технико-экономического обоснования
	Утверждение эскизного проекта	Разработка пояснительной записки Согласование и утверждение эскизного проекта
3. Технический проект	Разработка технического проекта	Уточнение структуры входных и выходных данных Разработка алгоритма решения задачи Определение формы представления входных и выходных данных Определение семантики и синтаксиса языка Разработка структуры программы Окончательное определение конфигурации технических средств
	Утверждение технического проекта	Разработка плана мероприятий по разработке и внедрению программ Разработка пояснительной записки Согласование и утверждение технического проекта
4. Рабочий проект	Разработка программы	Программирование и отладка программы
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77
	Испытания программы	Разработка, согласование и утверждение программы и методики испытаний. Корректировка программы и программной документации по результатам испытаний
5.Внедрение	Подготовка и передача программы	Подготовка и передача программы и программной документации для сопровождения и (или) изготовления Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление Передача программы в фонд алгоритмов и программ

Примечания:

1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях - вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании;

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

Выбор стандарта на практике зависит от проекта (не бывает двух одинаковых проектов), от организационных основ коллективов специалистов, от стратегии их работы, от числа задействованного персонала и сторон-участников.

Программный продукт, будь то простой сайт или сложная система, должен отвечать следующим основным требованиям : 1)Надежность ; 2) Безопасность ; 3)Возможность модернизации ; 4) Удобство в использовании для конечного пользователя.

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

В идеале Техническое задание (ТЗ) должно быть разработано заказчиком. Но чаще всего это делает исполнитель, в связи с отсутствием у заказчика специалистов, которые разбираются в разработке П.О. Техническое задание, чаще всего разрабатывается исходя из ГОСТа 19.201-78 «ЕСПД. Техническое задание. Требования к содержанию и оформлению». Если разрабатывается П.О. в составе автоматизированных систем ,то применяют ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы».

Разработчик и заказчик согласовывают между собой ТЗ ,после того как оно было проверено на правильность и отсутствие ошибок . Основываясь на утвержденном ТЗ, разрабатывается проект(документация проекта) Содержание проекта зависит от типа программного обеспечения и предпочтений разработчика.

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

· пояснительная записка (по ГОСТу 19.404-79 «ЕСПД. Пояснительная записка. Требования к содержанию и оформлению»).

· описание программы (по ГОСТу 19.402-78 «ЕСПД. Описание программы»).

· перечень терминов, используемых в проекте.

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

1. Определяется набор аппаратуры для производства тестирования.

2. Разрабатываются сценарии (контрольные примеры) для тестирования.

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

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

5. Производится тестирование на удобство управления программой и качество интерфейсов.

6. Данные тестирования и его результаты обрабатываются и оформляются в соответствии с ГОСТом 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».

7. По мере выявления ошибок последние исправляются, и тестирование производится повторно.

8. После исправления всех ошибок программа передается в опытную эксплуатацию.

Заказчику на стадии опытной эксплуатации передается программа и обязательный пакет документации:

· ведомость эксплуатационных документов (по ГОСТу 19.507-79 «ЕСПД. Ведомость эксплуатационных документов»)

· формуляр (по ГОСТу 19.501-78 «ЕСПД. Формуляр. Требования к содержанию и оформлению»)

· описание применения (по ГОСТу 19.502-78 «ЕСПД. Описание применения. Требования к содержанию и оформлению»)

· руководство системного программиста (по ГОСТу 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению»)

· руководство оператора (по ГОСТу 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению»).

В зависимости от вида задачи дополнительно могут передаваться:

· руководство программиста (по ГОСТу 19.504-79 «ЕСПД. Руководство программиста. Требования к содержанию и оформлению»)

· руководство по т/о (по ГОСТу 19.508-79 «ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению»).

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

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

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

· консультации;

· обслуживание аппаратных средств, на которых используется программа;

· проверка и анализ баз данных;

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

· документирование и анализ новых требований к программе.

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

Вывод. В этой главе мы проанализировали какие стандарты существуют. Подробно рассмотрели стандарты(как международные ,так и отечественные), которые относятся к сфере IT.



3. Выбор методов принятия решений для нахождения наиболее рационального решения на каждом этапе проектирования

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

4.1 Этап выбора проекта реализации при проведении научно-исследовательских работ

На этапе разработки ТЗ необходимо выделить стадию обоснования необходимости разработки и научно-исследовательские работы. Одна из основных задач на этапе обоснования необходимости разработки - выбор критериев эффективности и качества разрабатываемого программного продукта. Под качеством программного обеспечения понимается весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям .К основным критериям оценки эффективности и качества ПП относят: (К1) функциональные возможности, реализующие потребности пользователя; (К2) надежность - способность сохранять требуемый уровень качества функционирования; (К3) практичность - удобство и стоимость освоения и эксплуатации; (К4)эффективность - соотношение между уровнем качества функционирования ПП и объемом используемых ресурсов; (К5) сопровождение - объем работ для проведения модификаций ПП; (К6)мобильность - переносимость из одного окружения в другое. Лицо, принимающее решение, может выбрать предложенный набор критериев оценки ПП или создать собственный. Необходимо провести ранжирование указанных критериев по важности. Это можно сделать на основе методов аналитических иерархий, ранга и изучения предпочтений. Покажем пример ранжирования шести названных критериев на основе метода аналитических иерархий. Будем использовать шкалу относительной важности критериев К1, …, К6: равная важность - 1, умеренное превосходство - 3, существенное и сильное превосходство - 5, значительное превосходство - 7, очень большое превосходство - 9.

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

Табл. 2 (взаимная важность критериев)

Важность критерия по сравнению с критерием	j
	1	2	3	4	5	6
i	1	1	1/5	1/3	3	1/3	3
	2	5	1	5	9	3	7
	3	3	1/5	1	5	1/5	5
	4	1/3	1/9	1/5	1	1/3	3
	5	3	1/3	5	3	1	3
	6	1/3	1/7	1/5	1/3	1/3	1

Согласно таблице 2 найдем цену каждого критерия по формулам:

= ,i=1,...,6 ; j=1,...,6

Таким образом мы получаем ранжирование критериев по важности в порядке убывания: К2, К5, К3, К1, К4, К6.

Метод назначения весов критериев на основе метода ранга.

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

	К1	К2	К3	К4
Э1	6	2	8	10
Э2	10	2	8	4
Э3	3	6	10	8

рис 3.(матрица оценок)

Найдем суммарные оценки критериев по всем экспертам

3. Найдем сумму всех оценок.

Найдем веса критериев.

Наиболее важным, по мнению экспертов, является критерий, имеющий максимальный вес.

Одним из ключевых этапов разработки ПП при проведении научно-исследовательских работ является предварительный выбор метода решения задачи. На этом этапе обычно формируется несколько альтернативных проектов реализации. Данный этап является наиболее сложным, так как требует анализа большого объема разнородной информации. Для выполнения анализа целесообразно применять технологию нисходящего принятия решений, в основе которой лежит выбор базового подхода с последовательной детализацией его в иерархию частных методов и методик. Выбор базового проекта необходимо проводить с использованием групповых методов ППР: ранжирования альтернатив, минимального расстояния и кластеризации экспертных оценок. Для подбора частных реализаций проекта могут быть применимы методы аналитических иерархий, лексикографического упорядочивания и полуупорядочивания. Выбор базового проекта решения поставленной задачи требует при- влечения экспертов. По результатам обработки их мнений выбирается упорядоченная последовательность приемлемых подходов к решению задачи. Применение групповых методов ППР обусловлено сложностью однозначной оценки эффективности предлагаемых подходов, что позволит снизить субъективизм и риск принятия неверного решения. Рассмотрим пример выбора одного из пяти альтернативных проектов на основе метода ранжирования альтернатив (метода назначения ранга привлеченными экспертами). Каждый из приглашенных экспертов формирует оценку каждого из пяти проектов, назначая им по своему предпочтению ранг. Например, привлечены l экспертов (пусть l = 5), которые для k альтернатив (пусть k = 5) сформировали оценки . Значение оценок/рангов может быть от 1 до 5: 1 - наиболее важная альтернатива, 5 - наименее. Результирующая оценка каждого проекта определяется суммой соответствующих рангов. Наилучшим считается проект с минимальной суммарной оценкой. В табл. 3 показаны экспертные оценки пяти альтернатив четырьмя экспертами; наилучший - проект 2.

Таблица 3

Экспертные оценки	Альтернативные проекты R
	1	2	3	4	5
Эксперты l	1	3	1	4	2	5
	2	3	1	2	4	5
	3	2	3	1	5	4
	4	5	2	1	4	3
	Су ммарная оценка	13	7	8	15	17



3.2 Этап выбора языка программирования

На стадии разработки и утверждения ТЗ важным моментом является выбор языка программирования. Решение этой задачи может быть очень легким, если отталкиваться от наличия того или иного транслятора и умения программировать на некотором языке. Сегодня существует большой выбор разнообразных языков программирования, среди которых можно назвать: С, C#, C++, Java, Lisp, Perl, Ruby, Haskell, Lisp, Delphi, Common, Erlang, Python и др. Если в распоряжении пользователя имеется несколько языков программирования и программных пакетов, и нужно согласно ТЗ обосновать выбор некоторого языка, то необходимо учитывать множество факторов:

· возможности языка программирования;

· назначение разрабатываемого ПП;

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

· простоту написания программ и понятность языка программирования для широкого круга пользователей;

· простоту компиляции программ и установки их на различные компьютеры пользователей;

· долговременность использования ПП (временная или постоянная);

· возможность расширения, наращивания функционала;

· число пользователей (возможность единоличного использования или передачи/продажи третьим лицам);

· необходимость работы в режиме реального времени;

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

· предполагаемый размер программы (нужно ли минимизировать размер памяти, которую занимает программа во время работы);

· требования к структуре/архитектуре ПП (необходимость модульного проектирования, использование архитектуры клиент/сервер и т.д.);

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

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

· характер и уровень использования периферийных средств (монитора, клавиатуры и др.), необходимость в специальном программировании некоторых функций, чтобы работать с периферийными устройствами;

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

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

· необходимость отслеживания, отображения, управления текущим состоянием технических средств;

· парадигму языка программирования (стиль написания программ): императивное, объектно-ориентированное, функциональное, декларативное, рефлексивное программирование;

· вид типизации -набор операций, множество значений, применяемых к объектам в языках программирования ,а также способ хранения объектов: статический, динамический и автоматический; компилируемость или интерпретируемость кода;

· управление памятью - поддержку автоматической или ручной «сборки мусора» (освобождения более не нужной памяти);

· стандартизацию;

· переносимость кода на различные аппаратные платформы или операционные системы;

· сложность освоения и скорость разработки;

· скорость исполнения;

· возможности сетевого взаимодействия;

· поддержку многопоточности;

· стоимость решения.

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

Рассмотрим пример выбора языка программирования с помощью процедуры попарного сравнения альтернатив. После попарного сравнения заполняется матрица, где в i-й строке и j-м столбце стоит сравнительная оценка альтернатив i и j, полученная по следующему правилу: альтернативы равнозначны - оценка «0»; альтернатива j лучше альтернативы i - оценка «1»; альтернатива j хуже альтернативы i - оценка «-1». Допустим, трем экспертам требуется проанализировать семь возможных языков программирования. Получены три оценочные матрицы.



Суммарная экспертная оценка альтернатив Альтернативы Ранг

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



3.3 Этап выбора тестового обеспечения

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

Существует четыре класса тестов .

· 1. Класс структурных тестов («белого ящика») использует информацию о структуре ПП и проверяет корректность работы всех команд/ветвей/путей про- граммы. Структурный тест должен обеспечить прохождение каждой команды/ветви/пути программы не менее одного раза. Глубина и тщательность проверки ПП усиливается от команд к путям, но даже если получен положительный результат, то нет оснований утверждать, что ПП реализован в соответствии со спецификацией.

· 2. Класс функциональных тестов («черного ящика») проверяет соблюдение требований к ПП и отражает взаимодействие тестируемого приложения с окружением. Приведем некоторые частные виды функционального тестирования: Т0 - тестирование пунктов спецификации ТЗ (каждого пункта не менее одного раза); Т1 - тестирование классов входных данных (не меньше одного раза для каждого отдельно взятого класса входных данных); Т2 - тестирование правил (каждого правила не менее одного раза); Т3 - тестирование классов выходных данных (представителя каждого выходного класса с учетом ограничений на ресурсы или время); Т4 - тестирование функций (каждого действия, реализуемого тестируемым ПП или его модулем, не менее одного раза); Т5 - комбинированные критерии для программ и спецификаций (подтвердить все комбинации непротиворечивых условий и обнаружить и ликвидировать условия противоречий).

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

· 4. Класс мутационных тестов ориентирован для проверки свойств ПП на основе подхода Монте-Карло, позволяющего при искусственном внесении мутаций (мелких ошибок) оценить общее число ошибок. После формирования тестовых наборов проводится оценка достижения заданной степени тестированности ПП по критериям покрытия программы и проекта:

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

o полнота - для каждой ошибки должен существовать тест, который раскрывает эту ошибку;

o надежность - любые два множества надежных тестов должны одинаково раскрывать или не раскрывать ошибки программы;

o легкость проверки, например вычисляемость на тестах.

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

= < , , , , , >,

= < , , , , , >

= < , , , , , >

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

=(,)=-|

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

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

Вывод. В этой главе были рассмотрены этапы разработки ПО, в которых есть возможность использовать методы поддержки принятия решений. Были подобраны методы и обоснован их выбор.



4. Разработка алгоритмов, реализующего выбранные методы поддержки принятия решения

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



5. Выбор языка программирования

В связи с тем что наша задача - разработка веб-приложения мы будем выбирать язык веб-программирования. Язык веб-программирования это совокупность операторов, с помощью которых создаются коды веб-программ, или их еще называют скриптами, сценариями. Язык программирования передает понятные компьютеру инструкции для выполнения определенных операций. Так, с помощью языков программирования человек «разговаривает» с машиной. Обычно коды, написанные на веб-языках, читаются браузерами. Среди самых распространенных языков веб-программирования можно отметить:

PHP - лучший язык для создания динамических Веб-страницы;

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

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

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

ASP.NET это фреймворк веб-приложений, разрабатываемый Microsoft. Коды приложения ASP.NET могут быть записаны на любом из следующих языков: C#, Visual Basic.Net , Jscript, J#

Основным и главным критерием при выборе языка программирования для меня стал фактор знания основ языка. В связи с этим мой выбор остановился на фреймворке ASP.NET, т.к он поддерживает язык программирования C# (произносится си шарп)

5.1 Характеристика языка программирования C#

C# является объектно-ориентированным языком программирования, разработанным Microsoft , как часть их .NET инициативы.

Язык программирования C# от Microsoft основан на C++ и языке программирования Java . Некоторые языки жертвуют удобствами быстроты разработки ( RAD - Rapid Application Development) за полную власть и низким уровнем контроля. C# был разработан как баланс между полной властью и скоростью разработки.

Язык программирования C# не компилируется в двоичный код, который может быть выполнен непосредственно на целевом компьютере . Вместо этого, как и Java, он компилируется в промежуточный код, который выполняется на виртуальной машине, которая включена в рамках .NET. Все .NET языки (в том числе Visual Basic. NET и управляемый C++, а также C#) попадают к "посреднику" кода, который называется Microsoft Intermediate Language (MSIL). Для случайного наблюдателя обучающегося основам программирования, в результате программа выглядит как обычный исполняемый файл и имеет ". ЕХЕ" расширение так же, как обычное приложение. Тем не менее, выполнение программы не будет работать на компьютере, который не имеет установленного фреймворка (framework) .NET.

Когда программа выполняется, .NET Framework создает промежуточный код в двоичном виде, который затем выполняется (как раз вовремя компиляции, называется JIT ). В результате двоичный код хранится временно (в кэш-памяти), так что если программа использует эту часть кода снова, используется кэшированная версия. Однако это действительно только в течение выполнения программы. Если .NET приложение запускается снова, то процесс компиляции повторится снова.

...