Файл: Модели процессов разработки программного обеспечения (Анализ процесса разработки программного обеспечения на примере бибилиотеки).pdf

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

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

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

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

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

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

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

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

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