Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие автора
Дин Леффингуэлл
Источники предлагаемых методов
Предлагаемый в данной книге материал представляет собой опыт, накопленный множеством людей, занимавшихся определением, разработкой и распространением систем программного обеспечения мирового класса. Эта книга не является академическим исследованием, посвященным управлению требованиями. На протяжении 80-х годов мы с Доном Уидригом (Don Widrig) входили в руководство небольшой компании, занимавшейся созданием программного обеспечения для заказчиков. Разрабатывая многие представленные в книге приемы управления требованиями, мы старались сосредоточить внимание на тех из них, которые важны как для создания систем программного обеспечения, так и с точки зрения результатов, которые необходимо представить заинтересованным лицам. Поскольку функционирование программного обеспечения исключительно важно для успешной работы предприятия в целом, мы старались не отвлекаться на мелочи, избегать предвзятых мнений и экспериментов с непроверенными методами.
За последние десять лет методы претерпели эволюцию. Они были усовершенствованы в результате приобретенного в различных компаниях при разнообразных обстоятельствах опыта. Однако все представленные методы проверены на практике и прошли испытание временем. Возможно, даже более важным является то, что на них практически не повлияли происшедшие за этот период в отрасли технологические изменения. Действительно, большая часть изложенных в книге принципов не зависит от изменений в технологиях программного обеспечения. Поэтому мы надеемся, что полученные знания не утратят со временем своего значения.
Уроки работы с требованиями, извлеченные из создания систем программного обеспечения по заказу других пользователей
Поначалу я возненавидел компьютеры. ("Что? Я проторчал здесь всю ночь и должен снова запускать этот пакет, так как оставил лишний пробел? Вы сошли с ума?") Моим первым "настоящим компьютером" был мини-компьютер, который, хотя и имел чрезвычайно ограниченные возможности по современным меркам, был уникален в том смысле, что я мог его трогать, программировать и заставлять его делать все, что я хотел. Это был мой компьютер.
Мои первые исследования касались применения компьютеров к анализу физиологических сигналов человеческого тела, главным образом, электрокардиограмм, и мой компьютер был прекрасным средством для этих целей. Помимо этого я начал применять свои программистские навыки и опыт в системах реального времени, работающих в промышленности.
Наконец, я вошел в корпорацию RELA и начал долгую и временами невероятно сложную карьеру исполнительного директора по разработке контрактного программного обеспечения. Мой соавтор. Дин Уидриг (Din Widrig), вскоре присоединился ко мне в RELA в качестве вице-президента отдела исследований и разработок. Он внес неоценимый вклад в успех многих разработанных нами систем.
С годами компания быстро расширялась. В настоящее время в ней работают сотни людей, и она перешла от разработки простых систем программного обеспечения к созданию полнофункциональных сложных медицинских приборов и систем, которые наряду с программным обеспечением включают в себя механические, электронные и оптические системы. Однако в сердце любой машины, в том числе и самой современной клинической лаборатории для ДНК-диагностики, находится один или несколько компьютеров, которые постоянно надежно выполняют свои функции в заданном ритме в многозадачной системе реального времени.
Первоначально мы программировали все и для всех, от программного обеспечения для позиционирования антенн до игр с лазерными мишенями, автоматически управляемых движущихся аттракционов, обучающих систем, сварочных роботов и средств автоматизированного управления механизмами. Мы даже разработали крупную распределенную компьютерную систему, которая автоматически выявляла и подсчитывала количество рекламных роликов на телевидении. (Наш девиз выглядел так: "Мы делаем компьютеры, которые будут смотреть рекламу вместо вас!") Возможно, единственной объединяющей особенностью разрабатываемого тогда программного обеспечения было то, что оно разрабатывалось для других, т. е. мы не были экспертами в данной области и не могли покрывать расходы по своему усмотрению. Мы полностью зависели от того, насколько заказчик будет удовлетворен конечным результатом работы. Такие условия во многом благоприятствовали формированию эффективного управления требованиями. И вот почему.
- Мы мало знали о предметной области, поэтому зависели от клиента при определении требований. У нас не было искушения выработать их самостоятельно; нам приходилось спрашивать, и мы должны были учиться задавать нужные вопросы в нужное время.
- Наши клиенты зачастую плохо разбирались в компьютерах, поэтому они зависели от нас в том, что касалось преобразования их потребностей и пожеланий в техническое задание.
- То, что работа оплачивалась, придавало строгость отношениям между разработчиком и клиентом.
- Качество было легко измерить: нам или платили, или нет.
Именно в этой ситуации мы открыли для себя два основных вопроса, с которыми сталкиваются разработчики программного обеспечения во всех проектах. Первый из них руководил нашим поведением многие годы и по сей день остается, пожалуй, сложнейшим вопросом, на который необходимо ответить в любом проекте разработки программного обеспечения.
Что же на самом деле должна делать программа?
Именно для ответа на этот вопрос мы на протяжении более 10 лет разрабатывали принципы и методы, представленные в частях 1, "Анализ проблемы", 2, "Понимание потребностей пользователя", и 3, "Определение системы". Каждый из этих методов доказал свою полезность и продемонстрировал эффективность во многих реальных проектах. Именно в этот период я также впервые познакомился с работами Дональда Гауса (Donald Gause) и Джерри Вайнберга (Jerry Weinberg), в частности с их книгой Exploring Requirements: Quality Before Design (1989). Поскольку она значительно повлияла на нашу работу, мы использовали некоторые ее основные концепции в нашей книге; во-первых, потому, что они работают, а во-вторых, будет хорошо, если вы также воспользуетесь опытом Гауса и Вайнберга.
Уроки, извлеченные из создания высоконадежных систем
Спустя некоторое время корпорация RELA стала специализироваться на разработке различных медицинских приборов и систем, использующих компьютеры: систем искусственной вентиляции легких, инфузионных насосов, водителей ритма, клинических диагностических систем, систем искусственного кровообращения, оборудования, контролирующего состояние пациента, и других диагностических и терапевтических приборов.
Именно в начале работы над проектом системы искусственной вентиляции мы осознали, какая ответственность возложена на нас: Если мы перекроем кран, кто-то умрет! В первую очередь мы думали о пациенте; его жизнь зависела от прибора, для которого мы создавали одну из первых в мире жестко ограниченных по срокам и средствам систем программного обеспечения. (Представьте себе ответственность первопроходца. Вы - первый!)
Понятно, что подобное задание, когда ставки столь высоки, заставило нас очень серьезно подойти к разработке программного обеспечения на самых ранних этапах развития индустрии разработки встроенных систем. Очень быстро выяснилось, что для стабильного успеха необходимо сочетание следующих компонентов.
- Прагматический процесс определения требований к программному обеспечению и управления ими.
- Жесткая методология проектирования и разработки программного обеспечения.
- Применение разнообразных проверенных современных методов верификации и проверки того, что программное обеспечение является правильным и безопасным.
- Высочайшая квалификация и ответственность как команды разработчиков, так и группы, гарантирующей качество программной системы.
Я твердо верил в то время и еще более убежден сегодня, что все эти элементы необходимы для создания любой более-менее надежной программной системы значительного объема. В корпорации RELA это был единственный способ обеспечить безопасность пациентов, выживание нашей компании и экономическое будущее ее служащих.
Добившись успеха в разработке и применении различных методов для ответа на основной вопрос 1, перейдем ко второму фундаментальному вопросу, с которым постоянно сталкивается команда разработчиков программного обеспечения.
Как можно точно у знать, что программа делает именно то, что нужно, и ничего другого?
Методы, используемые для ответа на данный вопрос, составляют основу части о, "Уточнение определения системы", и части 6, "Построение правильной системы".
Итак, вы можете быть уверены, что представленные в данной книге приемы проверены временем и хорошо зарекомендовали себя. Даже если вы не связаны с разработкой высокобезопасных систем, увидите, что это полезные практичные и эффективные (в плане затрат) советы, которые можно использовать для разработки систем программного обеспечения наивысшего качества.
Хотя методы, которые мы заимствовали, модифицировали, разрабатывали и применяли в корпорации RELA для решения двух основных вопросов, были достаточно эффективны, существовала проблема, которая постоянно держала меня в напряжении во время наиболее сложных моментов этих проектов.
При том, что значительная часть действий в процессе определения требований в силу его природы выполняется вручную, сколько времени может пройти, прежде чем мы совершим единственную, но потенциально опасную ошибку?
Существовал также вопрос затрат, так как проводимые вручную испытания были дорогостоящими и не исключали возможности ошибок. За этот период механическое конструирование прошло путь от выполняемых вручную чертежей до трехмерных компьютерных систем автоматического проектирования. За то же время наше продвижение в области программирования (в том, что касается практических целей) ограничилось повышением уровня абстракции наших языков программирования, что, конечно же, хорошо, но такие показатели, как частота ошибок, производительность написания строк кода, а также уровень качества, остались относительно неизменными. Проводимые нами в этот период эксперименты с CASE-средствами принесли неоднозначные результаты. Говоря откровенно, как разработчик программного обеспечения и руководитель, я считал состояние дел в отрасли инженерии программного обеспечения непростым.
Безусловно, автоматизация никогда не устранит потребность в необходимых для разработки программ мыслительных способностях. Тем не менее я согласен с тем, что автоматизация некоторых проводимых вручную операций записи и внесения изменений может высвободить дефицитные ресурсы, чтобы направить их на более продуктивную деятельность. Ну и, конечно, мы ожидали, что затраты на разработку снизятся, а надежность возрастет.
Уроки, извлеченные из деятельности в сфере управления требованиями
В 1993 году была образована корпорация REQUISITE, и некоторых из нас пригласили принять участие в разработке и внедрении нового инструментального средства разработки требований, RequisitePro. Поскольку в это время мы постоянно помогали пользователям в том, что касалось проблем управления требованиями, появилось много дополнительного материала для данной книги. Мы обязаны значительной частью этой работы клиентам корпорации, а также клиентам компании RELA, у которых многому научились.
В это время на мою карьеру большое влияние оказал д-р Алан Дэвис (Alan Davis), главный редактор журнала IEEE Software и заведующий лабораторией программирования им. Эла Помара (El Pomar) университета Колорадо в Колорадо Спрингс. В самом начале он вошел в компанию как директор и советник и в этом качестве оказывал заметное воздействие на нашу технологию и направления развития компании. Д-р Дэвис хорошо известен как специалист в области разработки требований. Он часто выступает в роли консультанта и разработал множество методов, помогающих компаниям усовершенствовать процесс управления требованиями. Эти методы были объединены с некоторыми методами, разработанными в RELA, и стали основой курса профессиональной подготовки "Requirements College", а также некоторых частей данной книги.
Кроме того, следуя недостаточно популярной бизнес-теории, согласно которой профессиональной помощи никогда не бывает слишком много, мы пригласили в компанию известного эксперта и автора книг о программном обеспечении Эда Иордана (Ed Yourdan). Он также оказал большое влияние на выработку курса в том, что касалось технологии и бизнес-направлений. Эд и Алан стояли у истоков этой работы, и многие приводимые в книге высказывания принадлежат им. На самом деле мы хотели выпустить эту книгу совместно с ними несколько лет назад. Но времена меняются, и они любезно предоставили нам возможность распоряжаться их результатами. Поэтому вы часто будете ощущать их присутствие в данной книге.
Начало
Полное содержание
Предисловие
Введение
Об авторах
Заказать книгу в магазине "Мистраль"
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
