Разработка Windows приложения для формирования справок в деканате ФЗО ПГУТИ

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

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

Введение

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

Основные задачи деканата заключаются в следующем:

1. Коммуникация с приемной комиссией по зачислению студентов

2. Организация учебного процесса на факультете

3. Информационно-справочные услуги для студентов по вопросам обучения

4. Подготовка приказов и распоряжений по факультету

Основными функциями, выполняемыми деканатом, являются:

1. Организация воспитательной и учебно-методической работы

2. Организация образовательно-профессиональных программ по направлениям и специальностям обучения

3. Учет студентов и их успеваемости

4. Контроль над состоянием помещений и имущества, находящихся в распоряжении деканата.

5. Организация профессионально-ориентационной работы с выпускниками факультета.

6. Документооборот на факультете.

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

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

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

Для достижения поставленной цели, необходимо решить следующие задачи:

· Проведение анализа деятельности деканата

· Изучение теоретических основ разработки программного обеспечения

· Формирование требований к разработанному приложению

· Разработка программного обеспечения

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

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

1. Описание предметной области и постановка задачи

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

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

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

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

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

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

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

Схема подчинённости личного состава факультета представлена на Рис. 1.1.

Рис. 1.1- Схема подчиненности личного состава факультета

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

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

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

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

1. Управление учебным процессом

2. Заполнение документов

3. Контроль успеваемости

Схема деятельности деканата приведена на рис.1.2.

Рис. 1.2 - Схема деятельности деканата

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

Основными недостатками в функционировании деканатов на данный момент являются:

· Использование устаревшей технологии регистрации и хранения информации

· Дублирование информации в различных подразделениях и отчетах

· Повторяющиеся операции обработки информации

1.2 Актуальность

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

1.3 Постановка цели

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

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

1.4 Инструменты и методы

Для разработки программного обеспечения ориентированного на персональные компьютеры с операционной системой Windows 7 и выше, выбрана технология Windows Forms. В качестве языка разработки был выбран язык C#. Для разработки на выбранном языке, в качестве интегрированной среды разработки была выбрана ИСР от компании Microsoft,Visual Studio 2010. С целью создания и редактирования PDF файлов используется библиотека iTextSharp.

Для написания документации и справочной системы было выбрано программное обеспечение, состоящее в реестре отечественного ПО Минкомсвязи РФ, Dr.Explain.

1.6 Список задач

Для достижения поставленной цели, необходимо решить следующие задачи:

1. Провести анализ деятельности деканата

2. Сформировать требования к разрабатываемому программному обеспечению

3. Изучить теоретические основы разработки программного обеспечения

3.1. Выбрать методологию разработки программного обеспечения

3.2. Выбрать технологию разработки пользовательского интерфейса

3.3. Выбрать язык, реализации программного продукта

3.4. Выбрать библиотеку для работы с PDF файлами

4. Разработать программное обеспечение

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

6. Изучить теоретические основы написания документации и разработки справочных систем

6.1. Разработать справочную систему по работе с программным обеспечением

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

2. Теоретические основы разработки программного обеспечения

2.1 Теоретические основы

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

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

· Для удовлетворения конкретных потребностей конкретного клиента / бизнеса (случай с заказным программным обеспечением)

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

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

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

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

2.2 Методологии разработки программного обеспечения

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

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

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

· Модель водопада

· V-Модель

· Инкрементальная модель

· RAD модель

· Гибкая модель

· Итерационная модель

· Спиральная модель

· Прототип модели

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

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

Каскадная модель.

Каскадная модель (Водопад) - традиционная методология разработки программного обеспечения, состоящая из набора шагов в определенном порядке (Рис. 2.1).

Рис. 2.1 - Диаграмма каскадной модели

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

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

Рис. 2.2 - Диаграмма итерации между этапами

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



Рис. 2.3 - Диаграмма повторения этапов

Так же возможны ситуации, когда итерация происходит внутри этапов.

Основные плюсы каскадной разработки:

· четкая документация процесса.

· точное определение бюджета.

· определение сроков сдачи проекта.

· низкая степень зависимости от человеческого фактора.

Минусы каскадной разработки:

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

· большой объем документов.

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

· невозможность внесения изменений в динамическом режиме.

Анализ.

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

На этапе анализа некоторые подготовительные задачи выполняются системным аналитиком:

· Встретиться с клиентом, чтобы обсудить потребности клиента

· Создание проектного предложения

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

· Обзор и наблюдение за используемой системой.

· Обзор всей документации.

· Проведение опросов и / или анкетирование.

· Создание спецификации программного обеспечения.

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

Спецификация программного обеспечения описывает:

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

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

· Предполагаемый бюджет на развитие.

· Оценочная шкала времени.

· Данные испытаний.

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

Дизайн.

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

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

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

Реализация.

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

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

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

· Создание графического пользовательского интерфейса.

· Инструменты для устранения неполадок.

· Инструменты совместной работы и облако.

· Эмуляторы.

· Мини-среды разработки с помощью программного обеспечения для браузера.

Тестирование.

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

· Построение плана тестирования

· Всестороннее тестирование: нормальные, исключительные и экстремальные данные.

· Тестирование синтаксиса, выполнения и наличия логических ошибок.

· Пробные запуски, таблицы трассировки, точки останова и точки наблюдения.

· Документация во время тестирования.

Кроме того, необходимо понимать, что существуют различные виды тестирования (Рис. 2.4).

Рис. 2.4 - Виды тестирования

· Тестирование программистом.

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

· Альфа-тестирование

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

· Бета-тестирование.

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

· Приёмочное тестирование.

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

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

· Тестирование развертывания.

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

Документация.

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

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

· Руководство пользователя.

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

· Техническое руководство.

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

· Хранилища документации.

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

· Спецификация программного обеспечения - включая план тестирования.

· Дизайн - в письменной или графической форме. Включая каркасы для проектирования пользовательских интерфейсов.

· Структурированный листинг - исходный код.

· Записи тестирования.

Оценка.

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

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

· Читаемость / изменяемость - Легко понимается другим программистом. Использование значащих идентификаторов, отступов и внутреннего комментирования, что позволяет легко обновлять код позднее.

· Надежность - Программное обеспечение надежно, если нет дефектов в дизайне или ошибок в исходном коде.

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

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

· Эффективность - программное обеспечение эффективно, если оно позволяет наилучшим образом использовать системные ресурсы (CPU и RAM).

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

Обслуживание.

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

Рис. 2.5 - Диаграмма видов поддержки

· Корректирующее обслуживание

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

· Адаптивное обслуживание.

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

· Совершенствующее обслуживание.

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

Гибкая модель.

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



Рис. 2.6 - Диаграмма этапов гибкой методологии

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

Основные плюсы гибкой разработки:

· Минимизация рисков

· Постепенное наращивание функционала программного продукта

· Небольшой объем письменной документации

· Запуск базовой версии программы в кратчайшие сроки

Существуют и минусы:

· Минимизация рисков

· Постепенное наращивание функционала программного продукта

· Небольшой объем письменной документации

· Запуск программ в кратчайшие сроки

· Требует мотивации от ответственных представителей заказчика

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

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

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

V-Модель.

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

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



Рис. 2.7 - Диаграмма этапов V-модели

Различают следующие фазы V-модели:

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

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

· Фаза низкоуровневого проектирования - это фаза, на которой разрабатываются фактические программные компоненты. Данная фаза определяет фактическую логику для каждого компонента системы. Так же, на этом этапе строится диаграмма классов со всеми методами и отношения между классами, и создаются тесты компонентов.

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

· Кодирование находится в нижней части модели V-модели. Конструкции модулей преобразуется разработчиками в один код. Затем выполняется модульное тестирование.

Преимущества V-модели:

· Легкость использования

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

· Возможность отслеживания дефектов - обнаружение на ранней стадии.

· Отлично подходит для небольших проектов, где требования просты для понимания

Недостатки V-модели:

· Очень жесткая и наименее гибкая.

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

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

Когда использовать V-модель:

· Модель V-образной формы должна использоваться для проектов малого и среднего размера, где требования четко определены и фиксированы.

· V Модель выбирается, в случае когда имеются достаточные технические ресурсы и необходимые технические знания.

· V-Модель выбирается, при условии высокой степени доверия заказчика к компании - разработчику. Поскольку никаких прототипов не создаётся, существует очень высокий риск неудовлетворения ожиданий клиентов.

Инкрементная модель.

В данной модели, каждый модуль проходит через следующие этапы:

· Формирование требований

· Проектирование

· Реализация

· Тестирование

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

Рис. 2.8 - Диаграмма приращения

Схема инкрементной модели приведена ниже (Рис. 2.9).

Рис. 2.9 - Диаграмма инкрементной модели

Преимущества инкрементной модели:

· Позволяет быстро по частям разрабатывать программное обеспечение в течение всего жизненного цикла программного обеспечения

· Эта модель является более гибкой и менее дорогостоящей, что позволяет изменять масштаб и требования

· Позволяет более просто тестировать и отлаживать

· В этой модели клиент может реагировать на каждую сборку

· Снижение стоимости первой реализации

· Легче управлять рисками, так как риски идентифицируются и обрабатываются во время итерации

Недостатки инкрементной модели:

· Требуется хорошая планировка и дизайн

· Требуется четкое и полное описание всей системы, прежде чем она будет разбита на части и постепенно разработана

· Общая стоимость выше, чем при разработке по модели водопадом

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

· Требования ко всей системе четко определены и понятны

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

· Необходимо рано отправить продукт на рынок.

· Используется новая технология

· Ресурсы с необходимым набором навыков недоступны

· Есть некоторые особенности и особенности, или высокие риски

RAD Модель.

Быстрая разработка приложений (RAD) часто используется в качестве альтернативы традиционному методу водопада. Быстрое выполнение разработки приложений, а не жесткое следование инструкциям, позволяет уделить больше внимания созданию прототипов как можно быстрее и упорядочению каждой фазы, так что некоторые процессы выполняются параллельно по сравнению с методом водопада. Этапы быстрой разработки приложений приведены на диаграмме ниже (Рис. 2.10).

Рис. 2.10 - Диаграмма этапов быстрой разработки

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

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

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

Планирование потребностей.

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

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

Фаза проектирования.

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

Фаза разработки.

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

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

Фаза перехода.

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

Итеративная модель.

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

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

Рис. 2.11- Диаграмма итеративного создания продукта

Схема итеративной модели приведена ниже (Рис. 2.12).



Рис. 2.12 - Диаграмма этапов итеративной модели

Преимущества итеративной модели:

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

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

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

· В итеративной модели меньше времени тратится на документирование и больше времени дается для проектирования.

Недостатки итеративной модели:

· Каждая фаза итерации является жесткой, без перекрытий

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

Когда использовать итеративную модель:

· Требования полной системы четко определены и понятны.

· Когда проект большой.

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

Спиральная модель.

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

· Фаза планирования: требования собираются на этапе планирования. Требования, такие как бизнес требования к спецификации и характеристики и системные требования.

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

· Фаза проектирования: на этом этапе разрабатывается программное обеспечение, а также тестирование в конце фазы. Поэтому на этом этапе разработка и тестирование завершаются.

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

Диаграмма спиральной модели приведена ниже (Рис. 2.13).



Рис. 2.13 - Диаграмма спиральной модели

Преимущества спиральной модели:

· Повышенный уровень анализа рисков, предотвращение рисков

· Хорошо подходит для крупных и критически важных проектов

· Сильный контроль за документации

· Дополнительные функциональные возможности могут быть добавлены позднее

· Программное обеспечение создается на раннем этапе жизненного цикла программного обеспечения

Недостатки спиральной модели:

· Исправления могут быть излишне дорогостоящими

· Анализ рисков требует высокоспециализированной экспертизы

· Успех проекта сильно зависит от этапа анализа рисков

· Не подходит для небольших проектов

Когда следует использовать спиральную модель:

· Когда важны затраты и оценка риска

· Для проектов среднего и высокого риска

· Долгосрочное обязательство проекта неразумно из-за потенциальных изменений в экономических сферах

· Пользователи не уверены в своих потребностях

· Требования сложны

· Ожидаются значительные изменения

2.3 Технологи разработки пользовательского интерфейса приложения

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

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

Windows Forms Application.

Технология Windows Forms Application - это первая технология UI в .NET Framework для создания настольных приложений. До сих пор хорошо подходит для многих бизнес - приложений для настольных компьютеров. Windows Forms проще в использовании и легче по весу, чем WPF. Windows Forms является инструментом для создания пользовательского интерфейса, созданным компанией Microsoft для платформы .NET . Этот инструмент позволяет создавать графические пользовательские интерфейсы (GUI) для ОС Windows. Благодаря WFA есть возможность оборачивать существующий Windows API, в управляемый код. В рамках проекта Mono, технология Windows Forms так доступна для Linux и MacOS.

Библиотека Windows Forms изначально была разработана как часть .NET Framework для упрощения разработки компонентов графического интерфейса пользователя (Рис. 2.14). Технология Windows Forms разработана на основе Windows API и представляет собой, обертку низкоуровневых компонентов Windows.

Рис. 2.14 - Структурная схема .NET Framework

Так же Windows Forms позволяет вести разработки кроссплатформенного графического пользовательского интерфейса. Однако, Windows Forms является лишь оберткой Windows API-компонентов, и ряд её методов осуществляют прямой доступ к Win32-функциям обратного вызова, которые недоступны на других платформах. Приложения Windows Forms являются событийно-ориентированными приложениями, использующими для работы Microsoft .NET Framework.

По сравнению с классами Microsoft Foundation (MFC), которые основаны на языке программирования C++, введение в программирование с использованием Windows Forms значительно проще. Структура основана не на парадигме Model View Controller (MVC), но при помощи некоторых сторонних библиотек есть возможность получить все эти функции - большинство используются в «Process Application Block» . Библиотека группы разработчиков Microsoft, модели и методы были, присутствуют в общем доступе и доступны для свободного скачивания. Она содержит исходный код библиотеки, ядро и примеры, которые помогут начать работу. Windows Forms не использует XAML, поэтому при необходимости расширить приложение на Windows Phone или Windows Store придется полностью повторно переписать весь пользовательский интерфейс.

Пример кода на языке C# с использованием технологии WFA.

using System;

using System.Windows.Forms;

public class HelloWorld

{

[STAThread]

public static void Main()

{

Form form = new Form();

Button b = new Button();

b.Text = "Click!";

b.Click += (s,e)=>{MessageBox.Show("Click!");};

form.Controls.Add(b);

form.Show();

Application.Run(form);

}

}

Главное окно приложения:

Рис. 2.15 - Главное окно приложения

Нажатие на кнопку:

Рис. 2.16 - Всплывающее уведомление

Windows Presentation Foundation.

Windows Presentation Foundation является графической подсистемой от компании Microsoft для разработки пользовательского интерфейса в приложениях на базе Windows. WPF, ранее известный как «Avalon», первоначально был выпущен как часть .NET Framework 3.0 в 2006 году. Данная технология не использует устаревающую подсистему GDI, а использует вместо нее DirectX. WPF позволяет обеспечить последовательную модель программирования для создания приложений и отделяет ость создания пользовательского интерфейса. Данная технология является предпочтительной для разработки настольных приложений на базе Windows, которым необходим сложный пользовательский интерфейс, стили, настройки и графически ресурсоемкие сценарии для рабочего стола. WPF использует расширяемый язык разметки для приложений - XAML. Разработка с и использованием WPF похожа на разработку для Windows Store, поэтому миграция приложений из WPF в приложения Windows Store проще, чем миграция из Windows Forms.

WPF приложения могут быть развернуты как отдельные программы либо размещены в качестве внедренного объекта на веб-сайте. WPF стремится объединить несколько общих пользовательский интерфейс элементов, такие как 2D / 3D - рендеринг, векторная графика, анимация. Эти элементы могут быть связаны между собой и позволять манипулировать различными данными под действием событий возникающих при взаимодействии с пользователем.

Основные компоненты архитектуры WPF показаны на Рис. 2.17. Красные участки диаграммы (PresentationFramework, PresentationCore и milcore) являются основными кодовыми частями WPF. Из них только один является неуправляемым, компонент - milcore. Milcore записывается в неуправляемом коде для того, чтобы обеспечить тесную интеграцию с DirectX. Все отображения в WPF осуществляется с помощью двигателя DirectX, что позволяет производить эффективный и аппаратный рендеринг программного обеспечения. WPF также необходим точный контроль над памятью и исполнением.



Рис. 2.17 - Архитектура WPF

Пример приложения на языке C# с использованием технологии WPF.

using System.Windows;

namespace SDKSample

{

public partial class AWindow : Window

{

public AWindow()

{

// InitializeComponent call is required to merge the UI

// that is defined in markup with this class, including

// setting properties and registering event handlers

InitializeComponent();

}

void button_Click(object sender, RoutedEventArgs e)

{

// показывает сообщение при нажатии кнопки

MessageBox.Show("Hello, Windows Presentation Foundation!");

}

}

}

Код XAML разметки:

<Window

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

x:Class="SDKSample.AWindow"

Title="Window with Button"

Width="250" Height="100">

<!--Добавление кнопки к окну -->

<Button Name="button" Click="button_Click">Click Me!</Button>

</Window>

Результат работы приложения представлен на Рис. 2.18.

Рис. 2.18 - Пример приложения с использованием WPF

Java Swing.

Swing - это инструмент для создания GUI на языке Java. Он является частью Oracle Java Foundation Classes (JFC) - API для предоставления графического интерфейса пользователя (GUI) для Java-программ.

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

В отличие от компонентов AWT компоненты Swing не реализуются с помощью кода, специфичного для платформы. Вместо этого они полностью написаны на Java и поэтому не зависят от платформы.

Swing не зависит от платформы, а использует GUI-структуру «Model-View-Controller», которая следует за однопоточной моделью программирования. Кроме того, эта структура обеспечивает уровень абстракции между структурой кода и графическим представлением GUI на основе Swing.

Та же Swing является высокомодульной архитектурой, которая позволяет «подключаться» к различным пользовательским реализациям определенных интерфейсов инфраструктуры. Так же пользователи могут предоставлять свою собственную реализацию этих компонентов, чтобы переопределить реализации, заданные по умолчанию, используя механизм наследования Java. Кроме того, Swing является компонентной структурой, компоненты которой в конечном итоге получаются из класса javax.swing.JComponent (Рис. 2.19). Объекты Swing асинхронно запускают события, имеют связанные свойства и реагируют на документально определенный набор методов, специфичных для компонента.

Рис. 2.19 - Архитектура Java Swing

Swing элементы можно условно разделить на четыре категории:

· Окна и диалоговые окна. Они содержат все другие элементы и составляют базовую основу для GUI

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

...