Школа естественных наук
Анализ тpебований заказчика
Скачать 1,07 Mb.
|
СД.Ф.4 Технология разработки программного обеспечения
| Анализ тpебований заказчика.
Анализ требований позволяет специфицировать функции и эксплуатационные характеристики ее программного обеспечения, указать его интерфейс с другими частями системы и установить ограничения, которым оно должно удовлетворять. Анализ требований может быть разделен на пять областей приложения усилий: (1) осознание проблемы; (2) оценивание проблемы и моделирование; (3) специфицирование и (4) экспертизу. Сначала аналитик изучает спецификацию системы (system specification) и план проекта программного обеспечения (software project plan). Целостное понимание требований к программному обеспечению является существенным для успеха в его разработке. Важно понять программное обеспечение в контексте всей системы и провести экспертизу сферы рассмотрения программного обеспечения, которая использовалась для количественных оценок при планировании. Возможно, для этого понадобится дополнительно выяснить, что же пользователи хотят полyчить от пpогpаммного пpодyкта. Это может быть интеpактивный пpоцесс. Каждый участник Fast–бригады должен приготовить список объектов (objects), которые являются частью среды, окружающей систему, генерируются системой и используются системой для выполнения ее функций. Программное обеспечение разрабатывается для обработки данных (data), для преобразования данных из одной формы в другую, т.е., приема входных данных, их обработки некоторым образом и генерации выходных данных. Однако, важно отметить, что программное обеспечение также обрабатывает и события (events). Событие представляет собой одну из сторон управления системой и является не чем иным, как булевыми данными – оно либо включено, либо выключено; либо верно, либо нет; есть или нет. Поэтому и данные (числа, символы, изображения, звуки и т.д.), и управление (события) одинаково свойственны области информации (information domain). После того, как созданы эти списки, бригада делится на подбригады, каждая из которых должна разработать мини-спецификаций (mini-specification) для одного или нескольких пунктов из каждого списка. Мини-спецификации являются уточнениями слов или фраз, содержащихся в списке. После того, как мини-спецификации завершены, каждый участник FAST-совещаний готовит список критериев подтверждения для продуктов/системы и представляет свой список бригаде. Затем создается поддержанный всеми список критериев подтверждения. FAST не являются панацеей для проблем, с которыми сталкиваются при раннем сборе требований, но этот бригадный подход имеет важные достоинства: учет многих точек зрения, мгновенные обсуждения и уточнения, а также конкретный шаг по направлению к разработке спецификаций. Один или более участников (или кто-то со стороны) получает задачу написания проекта полных спецификаций, используя всею информацию FAST-совещаний. Один из принципов анализа требует изучения области информации. Она содержит три различных видения данных и управления при их обработке программой ЭВМ: (1) содержание информации и взаимосвязи; (2) поток информации и (3) структура информации. Чтобы полностью понять область информации, должна быть рассмотрена каждое из этих видений. Содержание информации (information content) – это сами отдельные данные и объекты управления, заключающие в себе информацию, преобразуемую программным обеспечением. Объекты данных и управления могут соотноситься с другими объектами данных или управлений. Во время анализа области информации эти связи должны быть выявлены. Поток информации (information flow) представляет способ, которым изменяются данные и управление при их движении через систему. Входные объекты преобразуются в промежуточную информацию (данные и/или управление), которые в дальнейшем преобразуются в выходную. Вдоль этого пути (или путей) информации может вводиться другая информация из существующих хранилищ данных (data store) (например, файл на диске). Преобразования, применяемые к данным, являются функциями или подфункциями, которые должна выполнять программа. Данные и управление, перемещаемые между двумя преобразованиями (функциями) определяют интерфейс для каждой из функций. Структура информации (information structure) представляет внутреннюю организацию элементов данных и управления. Элементы данных и управления должны организовываться как n-мерная таблица или иерархическая древовидная структура? Какая информация связана с другой информацией в рамках этой структуры? Вся информация представлена в этой структуре, или должны использоваться разные структуры? Как информация в одной структуре соотносится с информацией в другой структуре? На эти и другие вопросы необходимо ответить при оценивании структуры информации. Необходимо отметить, что понятие структура данных (data structure), обсуждаемое далее в данном курсе, относится к проекту и реализации структуры информации. При оценивании проблемы аналитик создает модели системы, которые помогают в понимании информации, функций и поведения системы, делая посредством этого задачу анализа требований более легкой и систематической. Проектировщик программного обеспечения может преобразовать эти модели в проекты данных, архитектуры, интерфейсов и процедур. Кроме того, модели становятся главным объектом экспертизы и поэтому ключом для определения полноты, согласованности и точности спецификации. Модели создаются для достижения лучшего понимания создаваемого реального объекта, информации, которую преобразует программное средство, функций (и подфункций), которые осуществляют это преобразование, и поведение системы, когда осуществляется это преобразование. Скачать 1,07 Mb. Поделитесь с Вашими друзьями:
|