КОММЕНТАРИЙ К ТЕХНИЧЕСКОМУ ЗАДАНИЮ

Цель - цель приложения в целом, (а не цель программы). Здесь представлены все требования для приложения.

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

Определения, термины и сокращения – в виде таблицы:

Общее описание – достаточно общая часть описания.

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

Аппаратные интерфейсы – оборудование, на котором будет работать приложение, дополнительные устройства (например, джойстик и т.д.).

Программные интерфейсы – другие программы, с которыми приложение должно взаимодействовать, например, драйвер принтера, использовать сайт …

Коммуникационные интерфейсы – приложение будет иметь интерфейс для выхода в интернет посредством модема с минимальной скоростью 56 Кбайт/с.

Требования по адаптации – требования по выполнению на конкретном ПК, версии на к-л конкретном языке, например, англ., казахском, и т.д.

3.1 Функциональные требования – это требования, выражающие функции, которые должно выполнять приложение.

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

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

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

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

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

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

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

2) можно использовать классы, разработанные для требований в реальном объектно-ориентированном проектировании и реализации.

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

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

К недостаткам второго подхода относятся:

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

- выбор классов происходит достаточно рано, что приводит к совмещению выбора с процессом проектирования.

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

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

Алгоритм выбора классов предметной области для классификации требований:

1. Разработать полный набор не пересекающихся прецедентов.

2. Создать диаграмму последовательности для каждого прецедента. Не забыть отождествить классы и объекты.

3. Собрать все классы, использовавшиеся в диаграммах последовательности.

4. Определить важные дополнительные классы.

5. Распределить подробные функциональные требования по этим классам. При этом:

- Указать каждый атрибут как отдельное требование.

- Указать каждый конкретный объект класса, который должен существовать.

- Указать каждую функцию, необходимую для объектов в этой классификации.

- Перечислить события, на которые должны реагировать все объекты класса.

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

В) Организация требований по диаграммам потоков данных (DFD)

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

Г) Организация требований по диаграммам переходов состояний

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

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

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

Четыре альтернативные формы для выражения требований заказчика

Выбор формы зависит от заказчика, а также от типа описываемого требования.

1. Если требование простое и стоит само по себе, выразите его четкими предложениями в спецификации требований к ПО.

2. Если требование представляет собой взаимодействие пользователя и приложения, выразите его с помощью прецедента. Для этого:

- дайте имена прецедентам;

- определите действующие лица. Роль внешнего пользователя – обычно человек;

- запишите последовательность действий пользователя и приложения;

- минимизируйте ветвление;

- используйте общую форму;

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

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

- определите элементы обработки (обычно высокого уровня), покажите их в кругах или прямоугольниках;

- определите хранилища данных; покажите их как имена между двумя горизонтальными линиями;

- покажите пути передачи данных между обрабатывающими элементами. Укажите типы данных, передаваемых в каждом случае.

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

- определите состояния (каждое состояние обычно определяют отглагольным существительным, например, «ожидание»), покажите их в прямоугольниках со скругленными углами;

- укажите исходное состояние с помощью специальной стрелки;

- определите события (происходящие вне рассматриваемой части системы), приводящие к переходу состояний, покажите их как помеченные стрелки;

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

3.2 Нефункциональные требования

Нефункциональные требования – требования, которые предъявляются к приложению, но никак не влияют на его функциональность.

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

3.2.2 Надежность и доступность

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

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

3.2.3 Обработка ошибок

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

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

3.2.4 Интерфейсные требования

Интерфейсные требования описывают ФОРМАТ в котором программа общается с окружением, то есть либо с пользователями, либо с другими программами.

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

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

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

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

1. Узнайте своего пользователя

2. Поймите назначение проектируемой системы

3. Примените принципы хорошего экранного дизайна.

4. Подберите подходящий тип окон.

5. Разработайте системные меню.

6. Выберите соответствующие аппаратные устройства управления

7. Выберите соответствующие экранные элементы управления

8. Организуйте и создайте раскладку окон

9. Выберите подходящие цвета

10. Создайте осмысленные значки

11. Представьте эффективные сообщения, обратную связь и руководство

3.2.5 Ограничения

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

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

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

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

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

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

Приложение Д

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М.: Диалог-МИФИ, 2002. – 224 с.

2. Ильин В.В. Моделирование бизнес-процессов. Пособие по подготовке и внедрению корпоративной информационной системы управления компанией с использованием пакета ARIS. – М.: ИД «Вильямс», 2006. – 176 с.

3. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). – М.: ЛОРИ, 1996. – 250 с.

4. Бесплатная программа для типографий. TiSoft http://tisoft.ru/About

5. 1C:Полиграфия 8 http://asup.pechatnick.com/system.phtml?id=29

6. Программа для автоматизации в типографии http://forum.pechatnick.com/viewtopic.php?id=18352

7. TS Полиграфия 2003 http://softnic.ru/soft/programm_6142.html

8. Описание платформы «1С: Предприятие» http://v8.1c.ru/overview/

9. Гончаров Д. Сертифицированный курс. Введение в конфигурирование в системе «1C:Предприятие 8.1». Основные объекты. – М.: Фирма 1С, 2006.

10. Нуралиев C. Платформа «1С: Предприятие» как средство разработки бизнес-приложений // журнал «PC Magazine/RE», № 11, 2006.

11. «1С: Предприятие 8.1» Конфигурирование и администрирование. Часть №1. – М.: Фирма 1С, 2008. – 430 с.

12. «1С: Предприятие 8.1» Конфигурирование и администрирование. Часть №2. – М.: Фирма 1С, 2008. – 508 с.

13. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. – М.: Интернет-университет информационных технологий, Бином, 2006. – 320 с.

14. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: Диалог-МИФИ, 2001. – 304 с.

15. Габец А.П. 1С: Предприятие 8.1. Простые примеры разработки. – М.: Фирма 1С, 2008. – 382 с.

16. Радченко М. Г. «1С: Предприятие 8.1». Практическое пособие разработчика. – М.: Фирма 1С, 2007. – 512 с.

17. Богачева Т.Г. 1С:Предприятие 8.0. Управление торговлей в вопросах и ответах: Практическое пособие.– М.: ООО «1С-Паблишинг», 2004.-252 с

18. Рыбалка В. В. Hello, 1C(мастер-класс). Пример быстрой разработки приложений на платформе 1С: Предприятие 8. – М.: ООО «1С-Паблишинг», 2009

Приложение Е

Дата добавления: 2014-11-24; просмотров: 346; Нарушение авторских прав

Мы поможем в написании ваших работ!