Управление командной разработкой ПО АСОИУ. Инструментальные средства командной разработки

 

Управление командной разработкой ПО АСОИУ.

Одним из ключевых аспектов успешной реализации проекта разработки программного обеспечения является сплоченная команда. Для повышения эффективности реализации существуют дисциплины управления командной разработкой. К ним относится модель проектной группы MSF (Team model). Данный документ в редакции 3.1 описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь [48]. В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. В команде выделены 6 ролевых кластеров: “Управление продуктом” (product management), “Управление программой” (program management), “Разработка” (development), “Тестирование” (test), “Удовлетворение потребителя” (user experience) и “Управление выпуском” (release management).

 

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

К таким инструментам в первую очередь относятся системы управления версиями (Version Control System VCS). Основное назначение таких систем является хранение различных версий одной и той же информации и совместная работа с ней. Наряду с Microsoft Visual SourceSafe, Rational ClearCase  одной из распространенных систем VCS является система Subversion, представляющая собой централизованную систему для совместного использования информации. В её основе лежит хранилище, являющееся центром хранения данных. В хранилище информация представлена в виде дерева файловой системы - типичной иерархии файлов и папок. Любое количество клиентов подключаются к хранилищу, а затем читают или записывают эти файлы. Записывая данные, клиент делает информацию доступной для остальных; читая данные, клиент получает информацию от других. Для работы с Subversion разработана TortoiseSVN – свободный и бесплатный, с открытыми исходными кодами клиент системы управления версиями Subversion. TortoiseSVN интегрируется в проводник Windows и таким образом осуществляется управление версиями (см рисунок 24.1) Subversion, CVS и другие системы управления версиями используют модель копирование-изменение-слияние в качестве альтернативы модели блокирования для совместного использования. В этой модели клиент каждого пользователя считывает из хранилища проект и создает персональную рабочую копию - локальное отражение файлов и каталогов хранилища. После этого пользователи работают параллельно, изменяя свои личные копии. В конце концов, личные копии сливаются в новую, финальную версию. Обычно система управления версиями помогает в слиянии, но, разумеется, в конечном итоге за его корректное выполнение всё равно отвечает человек.

Работа с Subversion начинается с создания хранилища данных.

Рисунок 24.1 Контекстное меню TortoiseSVN

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

С использованием TortoiseSVN можно разрешать конфликты, возникающие при редактировании одного и того же ресурса.

 

25. Принципы создания пользовательского интерфейса ПО АСОИУ. Процесс разработки (дизайна) интерфейса

 

Существует четыре основных критерия качества любого интерфейса [49]:

1) скорость работы пользователей;

2) количество человеческих ошибок;

3) скорость обучения;

4) субъективное удовлетворение пользователей.

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

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

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

Для оценки критерия скорости работы Кард, Моран и Ньювел разработали неэвристический метод GOMS (Goals, Operators, Methods, and Selection Rules).Для расчета скорости работы действия пользователей раскладываются на составляющие, замеряется время их выполнения на массе пользователей, получаются статистически верные значения длительности этих составляющих.

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

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

Для повышения скорости обучения можно повысить общую «понятность» системы, и/или использовать обучающие материалы.

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

 

Элементы графического интерфейса

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

Кнопка - элемент управления, всё взаимодействие пользователя с которым ограничивается одним действием – нажатием. Виды кнопок: командные кнопки кнопки прямого действия, чекбоксы, радиокнопки. Чекбоксы и радиокнопки, - это кнопки отложенного действия.

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

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

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

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

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

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

 

Процесс разработки интерфейса

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

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

Логические характеристики пользовательского интерфейса:

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

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

3) конфигурация экрана или ограничения разрешения;

4) стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;

5) быстрые клавиши;

6) стандарты отображения сообщений;

7) стандарты конфигурации для упрощения локализации ПО;

8) специальные возможности для пользователей с проблемами со зрением.

 

Модуль V. Автоматизация проектирования АСОИУ и элементы управления проектом

26. CASE системы.

Под CASE-системами (от Computer Aided Software/System Engineering) понимают системы автоматизации процесса проектирования и разработки программного обеспечения. Все современные технологии проектирования ПО должны быть поддержаны комплексом CASE средств на всем жизненном цикле ПО [28].

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

1) средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области:

а. функциональное моделирование (Design/IDEF (Meta Software);

б. моделирование бизнес-процессов (CA ERwin Process Modeler (ранее: BPwin);

в. моделирование бизнес-процессов и баз данных (Oracle Designer);

г. определение и управление полным набором требований к разрабатываемой системе (Rational Suite AnalystStudio.

2) Средства объектно – ориентрованного проектирования ПО с использованием стандарта языка UML. К ним относятся следующие CASE-системы:

а. средство визуального моделирования (анализа и проектирования), использующее язык UML (Rational Rose (Rational Software),

б. Object Team (Cayenne),

в. Microsoft Visio (Microsoft).

3) Средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся

а. CA ERwin Data Modeler (ранее: ERwin),

б. S-Designor (SDP);

в. Oracle Designer - моделирование бизнес-процессов и баз данных;

г. CA ERwin Data Model Validator (ранее: ERwin Examiner).

4) Средства разработки приложений. К ним относятся средства

а. Microsoft Visual Studio (Microsoft),

б. IntelliJIDEA (Jet Brain) – IDE для реализации приложений на языке Java,

в. Delphi (Borland),

г. PowerBuilder (Sybase).

5) Средства тестирования приложений

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

б. Rational Purify - средство для локализации трудно обнаружи-ваемых ошибок времени выполнения программы;

в. Rational PureCoverage - средство идентификации участков кода, пропущенных при тестировании;

г. Rational TestManager - средство планирования функционального и нагрузочного тестирования;

д. Rational Robot - средство записи и воспроизведения тестовых сценариев;

е. Rational TestFactory - средство тестирования надежности;

ж. Rational Quality Architect - средство генерации кода для тестирования.

Вспомогательные типы включают:

1) средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

2) средства конфигурационного управления (PVCS (Intersolv);

3) средства тестирования (Quality Works (Segue Software);

4) средства документирования (SoDA (Rational Software).

 

 

⇐ Предыдущая11121314151617181920Следующая ⇒

Поделиться: