Содержание:

Введение

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

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

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

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

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

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

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

Задачи курсовой работы следующие:

- рассмотреть понятие программного обеспечения;

- рассмотреть процесс разработки программного обеспечения;

- рассмотреть процесс управления разработкой программного обеспечения и его особенности;

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

- проанализировать построение прототипа пользовательского интерфейса.

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

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

1.1. Понятие программного обеспечения

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

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

Общее определение понятия «программное обеспечение» включает в себя множество систем обработки данных программ и политических инструментов для работы этих программ [8, с. 221]. Эта интерпретация, может быть использована, особенно когда речь идет о актуальных проблем развития и функционирования программных систем как таковых. Но с точки зрения пользователей в рамках соответствующих технологий должны быть отделены от состава их документов по техническому обслуживанию программного обеспечения. Так как в соответствии со структурой активов и методов информационных технологий они относятся к организационной и методической поддержки.

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

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

В рамках программного обеспечения выделяются [6, с. 92]:

- программное обеспечение;

- разработка инструментов программы технического обслуживания;

- прикладное программное обеспечение.

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

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

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

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

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

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

- система управления базами данных (СУБД), позволяет превратить компьютер в справочник на любую тему;

- табличные процессоры, позволяющие организовать очень распространенную практику в расчетах таблицы;

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

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

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

Основная часть системного программного обеспечения является операционная система (ОС).

Операционная система - это набор программ, которые контролируют основные память, процессор, периферийные устройства и файлы, что ведет диалог [2, с. 94].

В операционной системе много работы, и она почти всегда находится в рабочем состоянии.

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

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

1.2. Процесс разработки программного обеспечения

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

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

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

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

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

Рис. 1.1. Модифицированная каскадная модель разработки программного обеспечения

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

Для того, чтобы устранить недостатки каскадной модели была предложена V-образная, или шарнирная модель разработки программного обеспечения (рис. 1. 2).

Рис. 1.2. V-образная модель разработки программного обеспечения

V-образная модель позволяет гораздо лучше контролировать результат на предмет соответствия ожиданиям, так как ориентирована на тестирование [5, с. 47].

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

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

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

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

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

Спиральная модель Боэма представлена на рисунку 1.3.

Рис. 1.3. Спиральная модель Боэма

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

Самый известный и авторитетный стандарт качества следует рассматривать как Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки программного обеспечения, вместе с производными. Он был создан SEI (Software Engineering Institute). Первая официальная версия стандарта была опубликована в 1993 году, хотя работа над ней началась гораздо раньше - ее основные положения были опубликованы в 1986 году. Успех CMM предопределен несколькими факторами. Этот стандарт был одним из первых изначально учитывая специфику создания программного обеспечения. Это было довольно просто и прозрачно, как понять и использовать, и регулировать, «что», а не «как», и поэтому подходит для различных моделей жизненного цикла, методологий разработки, и не накладывает каких-либо ограничений в отношении стандартов документации, инструментов.

Стандарт CMM был очень успешным, а затем на его основе создан целый ряд стандартов и она получила новое название - SW-CMM. Что точно отражает его положение в довольно большом семействе стандартов.

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

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

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

Для того, чтобы исключить необходимость «выравнивать» процессов организации и быть более адаптированым к его потребностям бизнеса, а не наоборот, стандарт CMMI имеет две формы представления - классический, многоуровневые, соответствующий CMM, и новый, непрерывнф . Непрерывное представление рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процесса (Process Areas, PA).

Соответствие уровней зрелости стандартов CMM, CMMI представлен в таблице 1.1.

Таблица 1.1

Соответствие уровней зрелости стандартов CMM, CMMI

Уровень зрелости CMM	Уровень зрелости многоуровневого представления CMMI	Уровень возможностей непрерывного представления CMMI
0 — Незавершенный	-	-
1 — Начальный	Начальный	Выполнимый
2 — Повторяющийся	Управляемый	Управляемый
3 — Определенный	Определенный	Определенный
4 — Управляемый	Управляемый количественно	Управляемый количественно
5- Оптимизируемый	Оптимизируемый	Оптимизируемый

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

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

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

Таблица 1.2

Уровни зрелости разработки программного обеспечения

Уровень 1 — начальный уровень	Процесс разработки программного обеспечения является спонтанным, и регулируют лишь несколько процессов. Успех развития может зависеть от отдельных сотрудников.
Уровень 2 — уровень повторяемости	Создать основные процессы управления проектами для отслеживания стоимости, графика и функциональности.
Уровень 3 — уровень регламентируемости	Процесс разработки программного обеспечения документировано, стандартизировано и интегрировано в стандартной разработке программного обеспечения организации процесса для операций по управлению и развитию операций. Все проекты используют стандартизированный процесс.
Уровень 4 — уровень управляемости	Проводится сбор детальных показателей по качеству процесса разработки продукта, что позволяет понять процесс и продукты и управлять ими.
Уровень 5 — уровень оптимизируемости	Оптимизация непрерывного процесса при условии количественной обратной связи от процесса и от пилотных инновационных идей и технологий.

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

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

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

Виды деятельности, с которыми приходится иметь дело менеджеру проекта или группе управления проектом, чтобы обеспечить ее успешное осуществление можно разделить на следующие области [7, с. 63]:

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

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

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

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

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

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

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

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

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

В управлении разработкой программного обеспечения необходимо учитывать некоторые его характеристики [17, с. 37]:

1) Установленные программы нематериальны. Это создает проблемы двух видов:

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

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

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

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

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

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

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

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

3) Есть много аргументов в пользу того, что код является проектом, а не конечным продуктом.

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

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

2. Анализ процесса разработки программного обеспечения на примере бибилиотеки

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

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

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

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

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

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

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

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

Оба подхода имеют как недостатки так и достоинства. Подход, который ограничен числом функций, позволяет упростить интерфейс, но он требует, чтобы пользователь понял, сколько функций низкого уровня «собирать» более сложные. Подход, который в дополнение к функциям низкого уровня является высокого уровня, что позволяет потенциально обеспечить большую скорость (из-за отсутствия зазоров между функциями низкого уровня), но это требует знания пользователя о том, где эти функции высокого уровня найти и как с ними работать, при этом не перегружая интерфейс [11, c. 63].

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

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

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

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

После того, как истинные цели пользователей, установленны, приходит время, выбрать конкретный способ реализации функции, для чего используется второй метод [9, c. 20].

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

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

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

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

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

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

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

2.2. Высокоуровневое и низкоуровневое проектирование

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

По существу, отдельные функциональные блоки выделяются на данном этапе. Под функциональными блоками подразумевается функция или группа функций, связанных по назначению или области применения в случае программы и группу функций/фрагментов информационного наполнения в случае сайта[8, c. 12].

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

Функциональные блоки клиентской части приложения представлены в таблице 2.1.

Таблица 2.1

Функциональные блоки клиентской части приложения

Основной экран Навигация между различными наименованиями книг

Поиск необходимой книги

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

Экран краткой информации о книге Описание книги

Получение полного содержания книги

Экран содержания книги Текст книги

Функциональные блоки администраторской части приложения представлены в таблице 2.2.

Таблица 2.2

Функциональные блоки администраторской части приложения

Основной экран Навигация между различными наименованиями книг

Поиск необходимой книги

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

Добавление книги в список

Редактирование книги из списка

Удаление книги из списка

Экран добавления и редактирования книги Заполнение и изменение информации о книге

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

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

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

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

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

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

На основе разработанных ранее экранов структуры на этапе проектирования система навигации выбирает наиболее адекватную систему навигации и разработывает подробный интерфейс [6, c. 32].

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

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

Рис. 2.1. Функциональная схема приложения

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

Рис. 2.2. Функциональная схема взаимодействия модулей информационной системы библиотеки

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

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

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

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

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

Проектирование экранов клиентской части.

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

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

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

Форма поиска позволяет искать пользователю, заинтересованного в книге из списке.

Отображение информации о книге. Этот экран содержит краткое изложение книги, такие как: название, автор, издатель и небольшое описание.

В нижней части формы расположена пара кнопок. Кнопка «Читать» откроет содержание книги, а кнопка «Каталог» вернёт пользователя к списку литературы.

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

Для более удобной навигации, в этой форме есть поле поиска. Чтобы вернуться к списку литературы следует нажать на «Каталог».

Проектирование экранов администраторской части.

Основной экран. Основной экран администратора не сильно отличается от экрана клиента. В дополнение к ранее упомянутых элементов, на нем появляются пара новых. Существует кнопка рядом с полем поиска «Добавить», предназначенная для добавления новых книг в список. Чтобы изменить или удалить существующие записи, есть две кнопки, расположенные слева от названия – «Удалить» и «Редактировать».

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

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

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

После этого нужно улучшить этот список. Сделать следующее:

- уменьшить длину полученных клеток;

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

- убедится в том, что та же концепция не называется в разных местах по-разному;

- проверить совпадение в стиле текста для выбранных платформ;

- уменьшить длину полученных клеток;

- убедится, что в всех командных кнопках глаголы-инфинитивы.

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

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

2.3. Построение прототипа пользовательского интерфейса

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

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

Бумажный.

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

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

Презентационный.

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

Псевдореальный.

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

Реальный.

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

3. Тестирование и модификация программного обеспечения

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

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

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

- не имеют всю необходимую информацию о системе;

-  ничего не знают о проектировании интерфейсов;

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

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

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

При регистрации нового читателя в базе данных библиотеки необходимо заполнить все поля, в противном случае система будет отображать сообщения об ошибках. Если поле «ФИО» (Фамилия Имя Отчество) не введены данные, появится сообщение (рис. 3.1).

Рис. 3.1. Сообщение системы об ошибке при некорректном заполнении поля номера телефона читателя

Рис. 3.2. Сообщение системы об ошибке при отсутствующих данных в поле «ФИО»

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

Рис. 3.3. Сообщение системы об ошибке в случае незаполненного поля при внесении информации о книге

При входе в систему зарегистрированный пользователь ввел неверный логин или пароль, то система выдаст сообщение об ошибке (рис. 3.4).

Рис. 3.4 Сообщение об ошибке при входе в систему в случае неверно введённого логина или пароля зарегистрированного пользователя

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

Заключение

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

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

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

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

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

Электронная форма позволяет хранить больше информации в безопасной, компактной и удобной форме. Значительно увеличивает скорость поиска необходимой информации, простота ее распределения.

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

Список использованных источников

1. Андерсон К. Минаси М. Локальные сети. Полное руководство: К.: ВЕК+, М.: ЭНТРОП, СПб.: КОРОНА принт, 2012. – 624 с.

2. Бажин И. И. Информационные системы менеджмента: Учебник для вузов. — М.: ГУ-ВШЭ, 2010. — 688 с.

3. Вайнштейн В. Управление качеством в процессах разработки программного обеспечения// Компьютера. -2013.- № 4.

4. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-е изд. М. «Издательство Бином», 2013. - с. 15-102.

5. Гради Буч, Джеймс Рамбо, Айвар Якобсон. UML. Руководство пользователя. М. ДМК, 2010. - с. 28-56.

6. Головкин Б.А. Параллельные вычислительные системы. М.: Наука, 1980. – 520 с. 3. Избачков Ю. С., Петров В. Н. Информационные системы: Учебник для вузов. -2-е изд. -СПб: Питер, 2016. -656 с.: ил.

7. Кознов Д. В., Бугайченко Д. Ю. Введение в программную инженерию/ [Электронный ресурс]. Точка доступа: http: //www. intuit. ru/department/se/inprogeng/2/

8. Колтунова Е. В. Выбор методов, моделей и стандартов управления разработкой программного обеспечения// Диссертационное исследование.- СПб.: Питер, 2011.- 184 с.

9. Курсовое проектирование. Организация, порядок проведения, оформление расчётно-пояснительной записки и графической части: Стандарт предприятия / Г.Д. Дель; Воронеж. гос. тех. ун-т. - Воронеж, 2013.- 48 с.

10. Корнеев И. К. Информационные технологии: Учебник для вузов/ И. К. Корнеев, Г. Н. Ксандопуло, В. А. Машурцев.- М.: Т К Велби, Проспект. -2016.- 224 с.

11. Кулямин В. В. Технологии программирования. Компонентный подход: Учебник для вузов/[Электронный ресурс]. Точка доступа: http: //panda. ispras. ru/~kuliamin/

12. Норенков И.П. Системы автоматизированного пректирования: Учебное пособие для ВТУЗов: в 9 кн/Кн. 3: Федорук В.Г. Черненький В.М. Информационное и пограмное обеспечение. - М.: Высшая школа, 2014.-159 с.

13. Першиков В. М., Савинков В. М. Толковый словарь по информатике. М.: Финансы и статистика, 2013−543 с.

14. Сорока Т. Обзор процессов разработки программного обеспечения/[Электронный ресурс]. Точка доступа: http: //cppbuilder. Ru

15. Технология разработки программных средств: Методические указания / Э.И.Воробьёв, О.Ю.Макаров, А.В.Антиликаторов; Воронеж. гос.тех. ун-т.- Воронеж, 2011.- 24 с.

16. Шауцукова Л. З. Информатика 10−11: Учебное пособие.- М.: Просвещение, 2014. -240 с.

17. Фаулер М., Скотт К. UML в кратком изложении. М. Мир, 2012. - с. 5-50.

18. Экономическая информатика и вычислительная техника: Учебник/ Под ред. В.П. Косарева. – М.: Финансы и статистика, 2012. – 336 с.