Принципы работы с требованиями к ПО. Леффингуэлл (2002) (Принципы работы с требованиями к ПО. Леффингуэлл (2002).djvu), страница 5

Очень быстро выяснилось, что для стабильного успеха необходимо сочетание следующих компонентов. ° Прагматический процесс определения требований к программному обеспечению и управления ими. ° Жесткая методология проектирования и разработки программного обеспечения. ° Применение разнообразных проверенньш современных методов верификации и про. верки того, что программное обеспечение является правильным и безопасным. ° Высочайшая квалификация и ответственность как команды разработчиков, так и группы, гарантирующей качество программной системы. Я твердо верил в то время и еще более убежден сегодня, что осг зти злгмгншы нгобхо.

димы для создояил любзй болггмгкгг нодглслой п)гог(зазсмной сисоимы значительного обагма. В корпорации КЕ!.А это был единственный способ обеспечить безопасность пациентов, выживание нашей компании и экономическое будущее се служащих. Основной вопрос 2. "Как точно узнать, что программа делает именно то, что нужно, и ничего другого!" 26 Предисловие автора Добившись успеха в разработке и применении различных методов для ответа на ос.

новиой вопрос 1, перейдем ко второму фундаментальному вопросу, с которым постоянно сталкивается команда разработчиков программного обеспечения. Климово точкоузкакпь что г1РоеРамма делает именно то, что нужно, и ничего дРузогог Методы, используемые для ответа па данный вопрос, составляют основу части 5, "Уточнение определения системы", и части б, "Построение правильной системы". Итак, вы можете быть уверены, что представленные в данной книге приемы проверены временем и хорошо зарекомендовали себя. Даже если вы не связаны с разработкой высокобезопасных систем, увидите, что это полезные практичные и эффективные (в плане затрат) советы, которые можно использовать для разработки систем программного обеспечения наивысшего качества. Хотя методы, которые мы заимствовали, модифицировали, разрабатывали и применяли в корпорации КЕ Л для решения двух основных вопросов, были достаточно эффективны, существовала проблема, которая постоянно держала меня в напряжении во время наиболее сложных моментов этих проектов.

Пупе том, что значикильная часть дексзпеий е пРоцессе тфеделенил тРебоеаний е силу его пРиРоды еыполклеккл е)зуч кую, сколько ~генезис может пройищ пРежде чем мы соке)пзаси единппеенную, но потенцзшльно опасную отиэкуу Существовал также вопрос затрат, так как проводимые вручную испытания были дорогостояшими и нс исключали возможности он~ибок, За этот период механическое конструирование прошло путь от выполняемых вручную чертежей до трехмерных компьютерных систем автоматического проектирования. За то же время наше продвижение в области программирования (в том, что касается практических целей) ограничилось повышениел~ уровня абстракции наших языков программирования, что, конечно же, хорошо, но такие показатели, как частота ошибок, производительность написания строк кода, а также уровень качества, остались относительно неизменными. Проводимые нами в этот период эксперименты с САБЕ-средствами принесли неоднозначные результаты.

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

Уроки, извлеченные из деятельности в сфере управления требованиями В 1996 году была образована корпорация КЕЯП)Б)ТЕ, и некоторых иэ нас пригласили принять участие в разработке и внедрении нового инструментального средства разра- МЮ фЯЩ ботки требований, Кес)п)з)серго. Поскольку в это время мы постоянно помогали пользователям в том, что касалось проблем управления требованиями, появилось много дополнительного материала для данной книги. Мы обязаны значительной частью этой работы клиентал~ корпорации, а также клиентам кол1панни КЕ).А, у которых многому научились.

Предисловие автора 27 В это время на мою карьеру большое влияние оказал д-р Ллан Дэвис (А1ап 1)ат!з), главный редактор журнала 1ЕЕЕ бо(г>гаге и заведующий лабораторией программирования им. Эла Помара (Е1 Рошаг) университета Колорадо в Колорадо Спрингс. В сазгом начале он вошел в компанию как директор и советник и в этом качестве оказывал заметное воздействие на нашу технологию и направления развития компании. Д.р Дэвис хорошо известен как специалист в области разработки требований. Он часто выступает в роли консультанта и разработал множество к>етодов, помогающих компаниям усовершенствовать процесс управления требованиями. Эти методы были обьедннены с некоторыми методами, разработанными в КЕ!.А, и стали основой курса профессиональной подготовки ")(с>)п!гсшсп>з СоНсбе", а также некоторых частей данной книги. Кроме того, следуя недостаточно популярной бизнес-теории, согласно которой в~ю.

фессиопальной памо>дн никогда не бмвае>л сии»хам м>юго, мы нрпгласнлн в компанию известного эксперта и автора книг о программном обеспечении Эда Йордана (Ед '>он>йап). Он также оказал большое влияние па выработку курса в том, что касалось технологии и бизнес.направлений. Эд и Ллан стояли у истоков этой работы, и многие приводимыс в книге высказывания принадлежат им. На самом деле мы хотели выпустить эту книгу совместно с ными несколько лет назад. Но времена меняются, и опн лк>безпо предоставили нам возможность распоряжаться их результатами.

Поэтому вы часто будете ощущать их присутствие в данной книге. Опыт, приобретенный в корпорации Кабопа1 буойъ аге В 1997 году корпорация Ка>!опа) боГ»гаге купила компанию Кс>рнъпе, В Ка>!опа! мы приобрели значительный опыт в управлении требованиями применительно к разработке и реализации полного спектра средств разработки приложений, пойабе дГ)а! прежнему продолжая помогать пользователям в решении их проблем при работе с требованиями. Дон продолжает сотрудничать с нами в вопросах го. вершепствовапия методов. Кроме того, в компш>ни йл>н>па! я имел прекрасную возможность раГ>отать с такими экспертами в области программного оГ>еспсчения и авторами популярных книг, как Грейди Буч (Сга>1у Воосй), Айвар Джсйкобсон (!гаг !агоЬ>ов), Джеймс Рамбо ()ашез КшпЬавяЬ), Уолкер 1'ойс (»>архег Коусе) и Филипп Крачтсп (Р!н)>рре Кгпс!поп). Все они оказали влияние па мое понимание проблемы управления требованиями, а Уолкер н Филипп были первыми читателямп этой кпнгн.

Мы стали обращаться к методу прецедентов для фиксации требований, а также использовать прецеденты в >юдоли проектирования для того, чтоГ>ы обеспечить оГнцук> ло. ш>ческую связь при создании архитектуры, проведении реализации и тестирования. Я также являюсь сторонником принятого в кол>панин Вайопа! киэУюэишвого лидкодг> к раз.

работке программного обеспечения, и мне хочется думать, что как в КЕ1А мы в свое вре>ш были первопроходцами, так это происходит и теперь с йикяк>! Гв!)>од Р>вгегг — процессом, описывающим полный жизненный цикл разработки программного обеспечения, Компания Кайопа! помогла мне завершить данную работу, и я благодарен ей за это. Она также л>обезно разрешила использовать некоторые идеи, тексты и диаграммы. Наконец, мы хотим поблагодарить всех, кто принимал участие в работе пад книгой, в том >псле Ллана Дэвиса (Л1 !)аг)з), Эда Йордана (Ед Ъ'опп!ав), Грсйдн Буча (Огайу к8 Предисловие автора ВоосЬ), Филиппа Крачтена (Ррй!!Рре КгнсМеп), Лесли Пробаско (1.ев!ее РгоЬавсо), Яна Спенса (1ап зрепсе), Джин Белл () еап Ве!!), Уолкера Ройса (Юайсег Коусе), Джо Мараско ()ое Мыавсо), Элмера Ммззинера (Ншег Мабак!пег), а также рецензентов издательства Адйвоп-%ев1еу: Эта Марсония (Аб Магвоп!а), Грэнвилла Миллера (Сгапт!!!е МВ!ег), Фрэнка Армура (РгапЬ Аппонг), д-ра Ральфа Р.

Янга (1Ы(К. Узник) (директора по разработке программного обеспечения компании 1лггоп РКС Зувгешв шн1 Ргосевв Епк!пееппя), профессора Дзвида Райна (1)ат!й Кше) (Университет Джорджа Мэйсона) и Дэна Роусторна (1)ап КанвгЬогп) (АССЕ%). Заключение По сути, большинство идей этой книги не являются оригинальными. Они представляют собой результат обобшения опыта двух десятилетий совместной работы в сфере разработки программного обеспечения, в которой пристальное внимание уделялось целостному подходу к проблеме требований. Мы полагаем, ято нам удалось обьаднннть лучшие иден и практические приемы в этой чрезвычайно важной и сложной области.

Мы верим, что результат — имсэгь неэбходиммл команде для вффекмкзного ун)вааввнял явремв еаниами набврое нрофвссиояавьнмл нркенее- поможет вам создать качественную систему программного обеспечения, уложившись в отведенные сроки и бюджет. Зо Введение Поначалу кажется, что это совсем несложно Садимся вместе с заказчиком. Записываем, что, по его мнению, должна делать система. Используем "классные" новые языки программирования н средства разработки прсь грачмного обеспечения, которых пару лет назад еще не было.

Создаем приложение, применяя зти самые современные языки н средства разработки. Быстро н эффективно проводим имитационные эксперименты и отладку. Производим загрузку нового клиентского приложения с удаленного компьютера. Сидим и ждем вознаграждения. Все идет просто замечательно. Итог — отличные премиальные! Реальное положение вещей выглядит совсем иначе Однако ситуация, как правило, оказывается совсем иной. В нашей жизни преобладают работа по ночам, меняющиеся требования, непостоянство заказчиков, серьезные проблемы с качеством программного обеспечения, технология, которая устаревает прежде, чем ее успевают применить, значительные задержки в реализации проекта и невыполненные обязательства.

В лучшем случае наши заказчики довольны, и мы получаем хо. рошее вознаграждение. Но даже тогда это нам дорого обходится. и мы уверены, что могли сделать лучше. В худшем случае мы получаем остановленные проекты н сплошное разочарование. Давайте следующий проект! Слава Богу, мы любим этот бизнес! Темы, рассматриваемые во введении В главе 1 вводится понятие управления требованиями, а также описываются некоторые основные проблемы разработки программного обеспечения, обуславливающие успешное илн неуспешное завершение проелта.

В этой главе также содержатся рекомендации, на что стоит тратить вреьш н ресурсы при разработке требований к приложеннзо. Есш вы — опытный раз. работчик программного обеспечения илн имеетс опыт руководства проектами либо работали в любой другой сфере прогртмлзирования и принизили участие во многих сложных проектах, вы можстс пропустить эту главу и сразу перейти к главе 2. Но сслн вы новичок нли по роду своей деятельности далеки от сферы разработки программного обеспечения вашей компании (например вы — сотрудник отдела маркетинга и вам пор! ~сп выбор нового программного обеспечения или вы работаете в отделе обеспечения качества и вам нужно пройти через процесс аккредитации компании по стандарту!ЬО 9000 или же вы работаете в "отделе-пользователе", которолгу для обеспечения его деятельности необходимы информационные системы), вам следует прочитать главу 1, равно как н всю остальную книгу! Вы, скорее всего, знаетс, что проекты разработки систем могут быль сложными, дорогостошцпми, а также могут сопровождаться высоким риском и могут быть подвержены сбоям, но вы можстс не знать, лечечу это типично для большинства организаций.