Программа по формированию навыков безопасного поведения на дорогах и улицах «Добрая дорога детства» 2
Скачать 1.39 Mb.
|
| Глава 1. Цель и масштаб 1.1 Цель проекта? J.2 Заинтересованные лица 1.3 Что входит в систему, что выходит за ее рамки? Глава 2. Используемые термины (Глоссарий) Глава 3. Прецеденты
Глава 4. Используемые технологии 4.1 Требования к технологиям, которые будут использоваться в разрабатываемой системе 4.2 Будут ли другие системы взаимодействовать с разрабатываемой системой? 15 4.3 Требования к форматам и протоколам взаимодействия Глава 5. Другие требования, непосредственно касающиееся проекта 5.1 Организация процесса разработки (Кто является непосредственным участником проекта? Сроки. Желательный уровень обратной связи с заказчиком на разных этапах проекта. Что нужно приобрести, что нужно разработать самостоятельно? Обзор конкурирующих систем. Требования к тестированию и к процедуре развертывания системы у заказчика. Бизнес-правила. Производительность. Организация операций, безопасность, требования к документации. Простота обучения и использования. Переносимость и администрирование. Вопросы, решение которых неизвестно на данный момент, и возможности, которые будут реализованы в следующей версии.) Глава 6. Организационные вопросы: взаимодействие с руководством заказчика, политические, законодательные, человеческий фактор. (Требования к квалификации персонала. Законодательные требования, вопросы взаимодействия с властями. Возможные влияния человеческого фактора на успех/неудачу проекта. Требования к обучению персонала. Прочие организационные вопросы.) 2.2.5 Направления развития RUP Rational Unified Process поддерживает технологию разработки для различных платформ, предоставляет детальные рекомендации как для перехода команды разработчиков к технологии разработки на платформе Microsoft .NET так и для собственно разработки для этой платформы. Также поддерживается плагин WinDNA для тех, кто не собирается переходить к платформе .NET Поддерживается разработка для платформы Java 2 Enterprise Edition (J2EE). Доступны плагины для использования платформ IBM WebSphere, BEA WebLogic и HP Bluestone Total e-Server. База знаний Rational Unified Process постоянно развивается, вбирая в себя практический опыт тысяч людей. 16 3. Экстремальные технологии разработки прикладных программ В последние годы рынок программистских услуг стал глобальным, возникли и успешно работают множество виртуальных и офшорных команд. В подобных условиях возросла конкуренция за выгодные заказы и появилась потребность в методиках организации труда, которые должны давать эффект, когда в ходе работ возможны существенные изменения требований или когда вообще неизвестно, что будет собой представлять конечный продукт, но сделать его надо обязательно к сроку и в рамках бюджета. Методологии, используемые в таких случаях, получили название экстремальных. Они представляют собой наборы рекомендаций, которые по отдельности нередко выглядят противоречащими здравому смыслу и классическим схемам (отсюда и название - экстремальные методологии). Однако, будучи собраны в правильной комбинации, такие рекомендации превращаются в эффективно работающий инструмент. Экстремальные методологии нацелены на скорейшее получение конкретного результата, удовлетворение главных требований пользователя и более медленную доработку системы в соответствии с дополнительными пожеланиями. При этом требования, как уже говорилось, могут меняться весьма значительно. Поэтому длительность каждой итерации коротка, чаще всего неделя. Направление развития системы рассматривается, прежде всего, с точки зрения потенциальных рисков. Сложные или сомнительные, если говорить о прикладной полезности, функциональные возможности откладываются. Также учитывается близость конечного срока и объем оставшихся бюджетных средств. Экстремальные методологии будут работать только при наличии высокопроизводительной команды, в которой отлажен механизм взаимодействия, а каждый сотрудник способен переключаться на разные виды работ. Разработка программного обеспечения - это, прежде всего, организация сотрудничества между людьми и только потом - применение языков программирования Си или Java. 3.1 Экстремальное программирование Одним из вариантов экстремальных методологий является, так называемое, экстремальное программирование. В основе экстремального программирования лежат ряд принципов. 1. От каждого сотрудника требуется умение синхронизировать свою работу с деятельностью других людей и соответственно понимать структуру всего продукта. 17 18
3.2 Технология «Оберон-2000» Технология «Оберон-2000» призвана упорядочить работу небольшого коллектива программистов.(2-3 человека) и повысить качество создаваемых программ. При разработке прикладной программы по этой технологии придерживаются следующей схемы проведения работ.
19 9. Производится автономная отладка отдельных подсистем и программных модулей и проверка соответствия их документу «Справочное руководство». Ш.Производится сборка и комплексная отладка системы и проверка соответствия ее документу «Руководство пользователя». 11 .Производится доработка документов «Справочное руководство» и «Руководство пользователя» так, чтобы они соответствовали текущему состоянию программной системы. 12.Производятся приемо-сдаточные испытания системы, на которых проверяется соответствие системы документам: «Техническое задание», «Руководство пользователя» и «Справочное руководство». Если приемо-сдаточные испытания системы показывают, что заинтересованные в проекте стороны удовлетворены, то на этом проект заканчивается. Если в результате приемо-сдаточных испытаний системы выявлены существенные недостатки, то повторяют итерацию с самого начала. При этом корректируют техническое задание, уточняют концептуальную модель предметной области, дорабатывают функционально-структурную схему системы и т.д. Проект разрабатывается итерационно. Итерации по своим целям и расположению на временной оси объединяются в фазы проекта. В общем случае в проекте можно выделить следующие фазы:
3.2.1 Разработка технического задания Техническое задание должно содержать следующие разделы:
20 Подробнее о разработке технического задания см. в разделе 12.1.2.2. 3.2.2 Разработка концептуальной модели предметной области С помощью модели типа «Сущность-связь» описывается статика предметной области. Для описания динамики предметной области можно использовать блок-схемы, асинхронные блок-схемы, различные диаграммы. В модели типа «Сущность-связь» сущности - это объекты и субъекты, важные с позиции разработки данной прикладной программы.  — Номер группы Средний возраст  ссылается на — Номер заключения Дата участвует в Рис. 3. Пример графического изображения концептуальной модели предметной области «Работа лаборатории анализа крови» Для большей наглядности, обычно, модель «Сущность-связь» иллюстрируют графическим рисунком (см. рисунок 3). На нем сущности изображают прямоугольниками, внутри которых помещают названия сущностей, а связи между сущностями - направленными линиями, возле которых пишут их названия. 21 У сущностей и связей могут быть свойства. При графическом изображении свойства сущностей «подвешивают» к прямоугольникам, а свойства связей - к направленным линиям, изображающим связи. 3.2.3 Макетирование интерфейса прикладной программы Интерфейс - это «визитная карточка» прикладной программы. От того, насколько он удачно спроектирован, во многом зависит «судьба» программы. Если интерфейс интуитивно понятен пользователю, то его не нужно специально изучать и по долгу привыкать к программе. Особенно это важно для систем, с которыми ведется интенсивная работа в течение длительного времени (экономические программы, системы мониторинга экологических объектов [5], экспертные системы для генетических исследований [6] и др.). 3.2.3.1 Проблемы построения интерфейса прикладных программ За длительное время своего существования (а это иногда десятки лет!) прикладная программная система постоянно изменяется. При этом ее интерфейс также претерпевает значительные изменения. Радикальные изменения интерфейса требуют больших ресурсов и являются технически очень сложной задачей. Часто именно это является причиной «гибели» хорошей прикладной программы, не «вписавшейся» в быстро меняющийся рынок вычислительных средств. Обычно интерфейс прикладной системы выбирается по аналогии с уже существующими программами и затем «доводится» во время ее разработки. На это уходит много времени. Кроме этого разработка основных алгоритмов прикладной программы и интерфейса связаны друг с другом и задержка в разработке одной из частей затягивает разработку другой ее части. Принципы построения интерфейса, конструктивно независимого от содержательной части прикладной программы, хорошо известны [4]. В макете интерфейса разрабатываемой прикладной программы нужно схематично изобразить графически все основные формы и на каждой форме - все ее основные элементы (кнопки, окна, поля, текст и т.д.). Это будет макет интерфейса в статике. Кроме этого нужно описать динамику поведения интерфейса в основных режимах работы программы. Для этого можно выделить основные состояния интерфейса и построить матрицу переходов интерфейса из состояния в состояние под воздействием действий пользователя (нажатие кнопок мыши, ввод числовых данных и т.д.). Допускаются и другие формы описания динамики поведения макета интерфейса, например, написание программ-имитаторов интерфейса. 22 3.2.3.2 Технологический программный комплекс для макетирования интерфейса Опираясь на конструктивную независимость интерфейса от других частей прикладной программной" системы (базы данных, расчетных модулей и т.д.), можно сделать процесс выбора, доводки и изменения интерфейсной подсистемы независимым от разработки системы в целом. Для этого может использоваться технологический программный комплекс для макетирования интерфейсов прикладных программных систем [4]. Функционально-структурная схема комплекса показана на рисунке 4. В базе данных интерфейсов (будем называть ее репозитарием интерфейсов) хранятся макеты интерфейсных подсистем, которые уже нашли применение при создании конкретных прикладных программ. Один из них по вашему выбору может стать основой для макетирования нового интерфейса. В этом репозитарии будет также храниться текущий вариант макета создаваемого вами интерфейса или даже несколько альтернативных его вариантов. Предъявляя их заказчику программы, вы можете выбрать наиболее подходящий вариант и продолжить работу по его совершенствованию в соответствии с замечаниями заказчика. Необходимые для этого элементы берутся из базы данных элементов интерфейсов (будем называть ее репозитарием элементов интерфейсов). В случае необходимости создания нового элемента интерфейса, он разрабатывается традиционным способом и затем включается в репозитарии элементов интерфейса. Для обеспечения динамики в «поведении» макета интерфейса вы должны написать имитационную модель для «Программируемого имитатора внешней среды» (ПИВС) [4]. Затем необходимо подключить ее к ПИВС. Программируемый имитатор внешней среды представляет собой систему имитационного моделирования, ориентированную на моделирование как программных, так и аппаратных компонентов вычислительных систем и их окружения (пользователи вычислительной системы, объекты исследования, аппаратура сопряжения вычислительной системы и объекта исследования). Имитационная модель для ПИВС строится следующим образом. Каждый интерфейс описывается совокупностью параметров (р;). Это размеры, цвета форм, координаты размещения на форме и размеры окон, кнопок и т.д. Интерфейс имеет множество состояний (Sj). Состояние интерфейса характеризуется конкретными значениями его основных параметров. Выбор основных параметров из всего множества параметров ин- |
