Западные авторы о требованиях

Майерс [28]:

Программные продукты делятся на 3 категории:

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

2. Управляемый пользователем проект – требования формирует заказчик; примеры – правительственные заказы (космонавтика).

3. Контролируемый пользователем проект; требования формируются совместно; примеры – многочисленные АСУ.

Кроме требований обязательным условием успешного проекта является постановка целей. Практика показывает, что самой большой ошибкой проекта является отсутствие явной формулировки целей. При постановке целей работа обычно идет лучше. Цели – не требования. Цели - это явно сформулированное стремление обеспечить заданные качества программного продукта в процессе разработки. Примером может служить цель обеспечить надежность и эффективность проектируемой системы. Цели часто противоречат друг другу. Майерс[28] определяет цели следующим образом: «Цели – это конкретные ориентиры для программного продукта. Процесс постановки целей – это процесс принятия компромиссных решений». Следующая цитата из [28] поясняет эту мысль: «Программное обеспечение State Farm обслуживает порядка 15 000 000 владельцев полисов и обрабатывает страховые премии на сумму порядка 2.3 миллиарда долларов ежегодно. В условиях, когда от аккуратности системы зависит так много долларов и людей, надежность должна предшествовать эффективности. Кроме того, … модификации программы – постоянный процесс, образ жизни. Поэтому удобство сопровождения также более важно, чем эффективность».

Майерс[28] делит множество целей на несколько групп и соотносит с главной целью – обеспечение надежности. Эти цели должны быть сформулированы явно, и разработчик обычно должен отдавать себе отчет, что не все цели могут быть в равной мере достигнуты. Поэтому, как сказано выше, приходится принимать компромиссное решение. В том смысле, как понимает цели Майерс, многие (но не все!) из них можно сформулировать в виде требований. Рассмотрим некоторые из них.

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

Адаптируемость –мера простоты расширения и модификации продукта. Как это ни удивительно, но свойство адаптируемости, по мнению Майерса, хорошо согласуется с надежностью. Очевидно, что адаптируемость может часто формулироваться как одно из требований к системе (если заказчик это понимает!).

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

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

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

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

В остальных случаях к эффективности необходимо относиться разумно. Приведенная выше цитата демонстрирует правильный подход к проблеме эффективности. Требования к эффективности очень редко формулируются явно, если только разрабатываемая система не является системой реального времени. С точки зрения Майерса[28], «следует считать, что всякий разработчик программного обеспечения, жертвуя надежностью ради эффективности, поступает безответственно».

Майерс в качестве целей упоминает ещё стоимость продукта, календарный план и документирование. Поскольку ГОСТ ЕСПД явно задает стандарты для этих вещей, мы не будем рассматривать их в качестве целей.

Литература

Рейнгольд Э. и др. Комбинаторные алгоритмы: теория и практика.

Ахо А., Хопкрофт Дж., Ульман Дж. Построение и анализ вычислительных алгоритмов.

Гудман С., Хидетниеми С. Введение в разработку и анализ алгоритмов.

Вирт Н. Алгоритмы + структуры данных = программы.

Гэри М., Джонсон Д. Вычислительные машины и труднорешаемые задачи.

Niemann,Tomas. Сортировка и поиск: Рецептурный справочник Перевод с английского П.Н.Дубнер (infoscope@glasnet.ru).

СибуяМ., Ямамото Е. Алгоритмы обработки данных.

Aho, Alfred V. and Jeffrey D. Ullman [1983]. Data Structures and Algorithms. Addison-Wesley, Reading, Massachusetts.

Cormen, Thomas H., Charles E. Leiserson and Ronald L. Rivest [1990]. Introduction to Algorithms. McGraw-Hill, New York.

Knuth, Donald E. [1998]. The Art of Computer Programming, Volume 3, Sorting and Searching. Addison-Wesley, Reading, Massachusetts.

Pearson, Peter K. [1990]. Fast Hashing of Variable-Length Text Strings. Communications of the ACM, 33(6):677-680, June 1990.

Pugh, William [1990]. Skip Lists: A Probabilistic Alternative to Balanced Trees. Communications of the ACM, 33(6):668-676, June 1990.

[1] Линус !!!Торвальдсен!!! в одиночку создал ядро операционной системы Linux.