Школа естественных наук
Понятия и принципы анализа
Скачать 1,07 Mb.
|
СД.Ф.4 Технология разработки программного обеспечения
- Навигация по данной странице:
- Принципы анализа и специфицирований требований
- Методы, облегчающие специфицирования приложений
| Понятия и принципы анализа
Не имеет никакого значения, насколько хорошо спроектирована или закодирована программа, если плохо проведен анализ требований к ней и плохи ее спецификации. Она не будет удовлетворять пользователя и принесет огорчения разработчику. Задача анализа требований является процессом осознания, уточнения, моделирования и специфицирования. При этом уточняются детали сферы рассмотрения, первоначально установленной разработчиком системы и уточненной при планировании программного проекта. Анализ требований позволяет аналитику (analyst) уточнить его назначение и построить модели областей данных, функций и эксплуатационных характеристик, которые будут представлены в нем. И разработчик, и заказчик играют активную роль в анализе требований и специфицировании. Принципы анализа и специфицирований требований1. Необходимо понять проблему до начала создания модели анализа. Существует тенденция спешить с решением еще до того, как проблема понята. Это часто ведет к элегантному программному средству, которое решает совсем другую проблему! 2. Создаваемая модель должна быть познавательной, описывает систему так, как ее видят ее пользователи. Это значит, что в модели должны быть представлены объекты прикладной области и люди, в ней работающие. Спецификация должна позволить понять, как будет реагировать система на события в прикладной области в терминах этой области. 3. Необходимо определение среды, в которой работает система, и указание того, как реагирует система на события в среде. Другими словами, должна существовать не только спецификация системы, но и спецификация среды (что касается ее взаимодействия с системой). 4. Должен описываться контекст, в котором работает программное обеспечение, путем определения его взаимодействия с другими компонентами системы. Другими словами, спецификация должна охватывать не только программное обеспечение, но и те компоненты системы, с которыми оно взаимодействует. 5. Необходимо использовать три различных видения требований. Это уменьшает вероятность пропустить чего-нибудь, и увеличивает вероятность обнаружения противоречий. А. Должны быть понята и представлена информационная область проблемы. Б. Должны быть определены функции, которые должно выполнять программное обеспечение \ система. В. Должно быть представлено желаемое поведение программного обеспечения \ системы, описывающее информационную и функциональную реакцию системы на различные “раздражители” из ее окружения (среды). 6. Модели, которые описывают информацию, функции и поведение должны быть разбиты на части так, чтобы послойно раскрыть детали. 7. Процесс анализа должен двигаться от самой важной информации к деталям реализации. 8. Спецификация должна быть терпима к неполноте и быть расширяемой. Любая спецификация – это всегда модель, т.е. абстракция некоторой реальной (или воображаемой) ситуации, которая, обычно, очень сложна. Поэтому она всегда неполна и может существовать на нескольких уровнях детализации. 9. Записывайте источник и причину каждого требования. Это будет первым шагом в установлении прослеживаемости к заказчику. 10. Устанавливайте приоритеты требований. Стесненные сроки могут помешать реализации всех требований. Если применяется модель жизненного цикла с приращениями, должны быть идентифицированы те требования, которые будут представлены в первом приращении. Методы, облегчающие специфицирования приложенийМежду заказчиками и разработчиками программных средств часто возникает недопонимание. Сyществyет огpомная пpопасть междy идеями пользователей и пpедставлением о возможных способах pеализации этих идей конкpетными pазpаботчиками. Связь является здесь ключевым элементом. Hо даже самая хоpошая связь междy пользователями и пpогpаммистами не всегда является залогом понимания. Часто опускается важная информация, и не устанавливаются успешные рабочие связи. Для избежания этих проблем разработан ориентированный на бригадную работу подход по сбору требований, который применим на ранних стадиях анализа и специфицирования. Этот подход, называемый методами, облегчающими специфицирование приложений (facilitated application specification techniques - FAST), предполагает создание объединенной бригады заказчиков и разработчиков, которые работают вместе, чтобы идентифицировать проблему, предложить элементы ее решения, договориться о различных подходах и предварительно специфицировать требования к решению. После завершения предварительных совещаний и заказчик, и разработчик пишут одно-двух-страничную “заявку на продукт” (product request). Заявки на продукт рассылаются всем участникам совещания до даты его начала.Эти заявки рассматриваются в течение нескольких дней до совещания. С началом совещания первой темой обсуждения является потребность и обоснование для нового продукта: каждый должен согласиться с тем, что разработка (или приобретение) продукта обоснована. После того, как такое согласие установлено единогласно, каждый участник представляет для обсуждения списки объектов, услуг и ограничений будущего продукта, которые он составлял при рассмотрении заявки. Скачать 1,07 Mb. Поделитесь с Вашими друзьями:
|