1. Промышленный подход к разработке ПО
реклама
1. Промышленный подход к разработке ПО Глубоко ошибается тот, кто думает, что изделиями программистов являются программы, которые они пишут. Программист обязан создавать заслуживающие доверия решения. Эдсгер Дейкстра 1.1. Основные понятия Те части системы, которые вы можете разбить молотком, называются аппаратным обеспечением; те, которые вы можете только проклинать, называются программным обеспечением. Из фольклора Принято выделять семь видов обеспечения ВС: • математическое: методы, алгоритмы; • лингвистическое: языки, способы взаимодействия; • информационное: данные; • программное: программы; • техническое: аппаратные средства; • методическое: документы, методики; • организационное: правила, регламенты, процедуры. В данном пособии необходимо четко понимать ряд основных терминов, которые мы ниже рассмотрим. Под исполняемой программой (executable program) будем понимать совокупность машинного кода и данных, пригодных для исполнения процессором. Программы делят на компоненты и комплексы (системы). Компонент (component program) – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. Программный комплекс, или программная система (program / software system), – программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса. Прошедшая испытания программа (или программная система), полностью готовая для продажи (поставки) и снабженная всей необходимой документацией, называется программным продуктом, изделием или средством (software product, production program). Программное обеспечение (software 1) – наиболее общее понятие, под которым понимают совокупность программ системы обработки информации и программных доку1 Термин «software» ввел статистик Джон Туки (John Tukey) в 1952 г. ментов, необходимых для их эксплуатации. В зависимости от контекста использования под ПО часто понимают конкретные программы или все программы в совокупности. Технология программирования (software engineering 1) – технологическая дисциплина, изучающая методы программирования и производства ПО. Заметим, что «software engineering» часто переводят (дословно) как «программная инженерия». Организация IEEE определяет термин «software engineering» следующим образом: «(1) Применение систематического, упорядоченного, измеримого подхода к разработке, использованию и сопровождению ПО, то есть использование инженерного искусства в ПО. (2) Создание подходов п. (1)». Предметная (проблемная) область (application/problem domain) – система понятий и объектов конкретной области человеческих знаний. Большинство программных продуктов создаются для применения в рамках конкретной предметной области, будь то геология, бухгалтерия, медицина и т. д. 1 Термин «software engineering» впервые появился в 1968 г. на конференции НАТО, Германия. 1.2. Особенности промышленного ПО и кризис его разработки Если бы строители строили дома так, как программисты пишут программы, один единственный залетевший дятел разрушил бы цивилизацию. Джеральд Вейнберг Во многих случаях программы создаются в единственном экземпляре для решения частных задач, не имеют массового применения и доступны только тем, кто их разработал. Они являются объектами творчества и только в исключительных случаях становятся промышленными изделиями. Совершенно иным классом программ являются полноценные программные средства, которые в настоящее время принято квалифицировать как продукцию производственно-технического назначения. В этом качестве программные продукты являются непосредственной производительной силой и не отличаются от любой другой промышленной продукции [19]. Будем делить программные продукты на небольшие, средние, большие и сверхбольшие. Размер исходного текста небольших программ составляет сотни и тысячи операторов языка высокого уровня, средних – десятки и сотни тысяч, больших – миллионы и сверхбольших – десятки миллионов. Для сравнения: размер Microsoft Windows 98 составляет около 11 млн строк, Microsoft Windows 2000 – около 36 млн строк, Microsoft Windows XP – около 45 млн строк 1. Создание большого программного продукта является весьма трудоёмкой задачей, решение которой не под силу одному человеку 2. Программисты-одиночки могут обладать гениальным даром к быстрой алгоритмизации и кодированию нетривиальных задач, созданию новых методов и идей программирования, приобретая при этом значительную известность. Однако не в их силах в одиночку решать весь комплекс проблем разработки средних и тем более больших программных продуктов за приемлемые сроки. Таким образом, сколько-нибудь значимые продукты создаются коллективами программистов. В таких коллективах в программисте-разработчике ценится не только умение программировать, но такие качества, как дисциплинированность и коммуникабель1 Рулон распечатки 1 млн строк мельчайшим шрифтом (5 мм на строку) составит 50 км в длину. Если набирать по 1 строке кода в 10 секунд, работая круглосуточно, без ошибок, сна и отдыха, на ввод 1 млн строк понадобится около трети года. 2 Скажем, только команда непосредственных разработчиков Microsoft Windows 95 состояла из более чем 200 программистов и тестировщиков. ность. Программисту следует трезво оценивать свои возможности и руководствоваться известной фразой «гении встречаются крайне редко, и нет основания полагать, что в среде программистов их число выше среднего» [4]. Существует также (на первый взгляд) парадоксальное мнение Джеральда Вейнберга: «если программист признан незаменимым, то лучшее, что можно сделать, – избавиться от него как можно скорее». Разумеется, здесь речь идёт не о самой необходимости «избавиться» от незаменимого программиста, а о необходимости такой реорганизации дел, которая его «незаменимость» нивелирует. Сказанное позволяет сделать вывод о том, что подход к разработке программного продукта качественно не должен отличаться от подхода к разработке любого промышленного продукта. Во всех случаях требуется техническая компетентность и грамотное управление. Несмотря на то, что в промышленной разработке всегда есть большой процент творчества, её необходимо понимать и организовывать как строгий технологический процесс. К сожалению, сами разработчики и их руководители часто не осознают этого факта, вследствие чего или разработка не доводится до выпуска продукта, или с неоправданно большими затратами выпускается «сырая», ненадёжная программа, срок жизни которой очень мал, что с юмором показано на рис. 1.1 из [24]. Эта ситуация, получившая в мире название «кризис разработки ПО», существует уже десятки лет (термин software crisis появился в 1968 г. одновременно с самим термином software). Кризис проявляется в том, что в среднем продолжительность проекта превышает плановую на 6–12 месяцев, а стоимость превышает бюджет на 50–100 % [12]. Чего хотел пользователь Как было предложено организатором разработки Как было описано в техническом задании Как было спроектировано ведущим системным специалистом Как было реализовано программистами Как было внедрено Рис. 1.1. Ироническое изображение процесса разработки ПО Например, в 1995 г. ожидалось, что только 9 % проектов, выполняемых крупными компаниями, будут завершены в срок и без превышения запланированного бюджета; 52 % проектов должны были стоить в среднем 189 % от их первоначально оцененной стоимости; в то же время 31 % всех проектов вообще ожидало приостановление или полное прекращение, причем затраты на них – ничем не компенсируемые убытки – оценивались ни много ни мало в 81 млрд долл. Через десятилетие, в 2004 г., 18 % проектов провалились, 53 % (более половины!) – не уложились в заданный бюджет или сроки, только 29 % были признаны успешными. Появился даже устойчивый термин – «безнадёжные проекты». Согласно данному Эдвардом Йорданом определёнию, безнадёжные проекты – это проекты, имеющие отклонение от нормы, как минимум, на 50 % (срок разработки сжат в два раза или людских ресурсов в два раза меньше требуемого) [12]. Причины бед IT-индустрии – вовсе не недостаток инструментов или технологий. Никлаус Вирт главной причиной считает недостаток технической компетентности (профессиональной квалификации). Другой причиной является плохое управление. Не последнюю роль здесь играют амбициозные заявки менеджеров, заболевших «синдромом покорителей Эвереста». Возможность подучиться за счет заказчика (кстати, типичная си- туация для России), заведомо не заботясь о результатах и реальных предпосылках успешной реализации проекта, – также весьма распространённая причина. Множество невыполнимых проектов возникает вследствие того, что разработчики часто дают необоснованные обещания, не подкрепленные реальными возможностями компании. 1.3. Сложность разработки ПО Управление сложностью – суть программирования. Брайан Керниган Существенная черта серьезного программного продукта – уровень сложности: один разработчик не в состоянии охватить все аспекты такой системы. Сложность больших промышленных программ превышает возможности человеческого интеллекта [4]. Э. Дейкстра писал: «Для нас, ученых, слишком велико искушение переложить вину за печальное состояние дел на недостаток образования среднего инженера, недальновидность менеджеров и злой умысел промышленников, но это никуда не годится. Видите ли, в то время, как мы все знаем, что причиной всех бед является неуправляемая сложность, мы не знаем, ни какой степени простоты можно достичь, ни до какой степени внутренняя сложность разработки в целом должна отражаться на видимых интерфейсах. Мы попросту до сих пор не знаем, насколько сможем выпутаться из этого. Мы до сих пор не знаем, можно ли отличить сложность, присущую самой задаче, от случайной сложности. Мы до сих пор не знаем, будут ли возможны компромиссы. Мы до сих пор не знаем, сумеем ли разработать для сложности осмысленную концепцию, на базе которой сможем построить полезную теорию». Даже точно определить само понятие «сложная система» нелегко [32]. Есть «структурное» определение сложности: простая система характеризуется тем, что человек уверенно может перебрать все связи между её элементами, в сложной он этого сделать не в состоянии. Есть «поведенческий» подход: сложная система обладает недетерминированным (точнее, не полностью детерминированным) поведением. На практике в сложных системах сочетается и то и другое. Мало того, что сложность задач предметной области может быть сама по себе велика. Страшнее то, что каждые 25 % увеличения сложности решаемой задачи требуют 100 % увеличения сложности программного решения для этой задачи [39]. Сложности разработки делятся на (1) внутренне присущие природе ПО и (2) сопутствующие производству ПО, но не внутренне ему присущие. Фредерик Брукс назвал эти трудности соответственно «сущностями» и «акциденциями» [3]. В своей известной ста- тье «No silver bullet» 1 он показал, что создание ПО всегда было, есть и будет сложным по самой природе вещей: с этой сложностью можно бороться, но избавиться от неё нельзя. Другую важную мысль подчеркнул Э. Дейкстра: «мне хотелось бы вставить предупреждение для тех, кто отождествляет сложность задачи программирования с борьбой против неадекватности наших нынешних инструментов, потому что они могли бы заключить, что, как только наши инструменты станут более адекватными, программирование перестанет быть проблемой. Программирование останется весьма трудным, потому что как только мы избавимся от обременительных деталей, мы окажемся свободны для того, чтобы приняться за задачи, которые лежат пока за пределами наших возможностей». Итак, сложность разработки ПО вызывается пятью следующими основными причинами. Это: 1. Сложность предметной области. Специалисты годами и десятилетиями изучают свою область знаний, будь это медицина, юриспруденция или нефтедобыча, и при этом только все больше убеждаются в необъятности проблем своей профессии. Часто по тем задачам, которые необходимо автоматизировать, сами специалисты не находят общего языка. Разработчики же программ часто вынуждены изучать предметную область за считанные месяцы. Полноценные, глубокие знания получить при этом практически невозможно. Все эти факторы добавляют в процесс разработки колоссальные трудности. Для их преодоления разработчики часто стараются рабо тать всю жизнь с о дно й и той же предметной областью, то есть иметь узкую специализацию. 2. Внутренняя сложность программ. Программы имеют огромную внутреннюю логическую сложность. Внутри большой программы могут существовать одновременно сотни и тысячи переменных и несколько потоков управления. Полный набор этих переменных, их текущих значений, текущего адреса и стека вызова для каждого процесса описывает состояние прикладной программы в каждый момент времени. Это состояние изменяется миллионами операторов, взаимное влияние которых очень велико: сбой в одном, как правило, приводит к неверной работе остальных. Далее, сложность программных объектов более зависит от их размеров, чем, возможно, для любых других создаваемых человеком конструкций, поскольку практически никакие две их части не схожи между собой (по крайней мере, выше уровня операторов). 1 «Серебряной пули не существует». Эта статья включена в издание [Ошибка! Источник ссылки не найден.]. Программисты борются с этим с помощью подпрограмм, классов, шаблонов, библиотек, компонентов, но все же уровень повторного использования кода чрезвычайно низок даже в пределах одного языка. С учетом наличия множества языков эта проблема стоит ещё острее 1. 3. Отсутствие хороших способов представления больших систем. План здания помогает архитектору и заказчику оценить пространство, возможности перемещения, виды. Становятся очевидными противоречия, можно заметить упущения. Масштабные чертежи механических деталей и объёмные модели молекул, будучи абстракциями, служат той же цели. Но программный продукт невидим и непредставим. Реальность программной системы не встраивается естественным образом в пространство. Поэтому у него нет готового геометрического представления подобно тому, как местность представляется картой и т. д. Как только мы пытаемся графически представить структуру программы, мы обнаруживаем, что требуется не одна, а несколько схем, наложенных одна на другую. Различные схемы могут представлять управляющие потоки, потоки данных, зависимостей, временные последовательности, соотношения пространств имен. Обычно они даже не являются плоскими, не то что иерархическими. За десятилетия программирования предложено множество разнородных графических нотаций, не согласованных друг с другом. В настоящее время одной из попыток унификации «графического языка» представления программных систем является унифицированный язык моделирования UML ( Unified Modeling Language), который фактически стал одним из главных промышленных стандартов [16, 35] UML изначально был создан в компании Rational Software, а теперь сопровождается организацией по стандартизации Object Management Group (OMG). 4. Трудности управления процессом разработки. Организовать плодотворную совместную работу хотя бы двух человек – уже достойная внимания задача. При росте количества разработчиков возникает множество самостоятельных проблем, причем эти проблемы могут из второстепенных легко перерасти в первостепенные. Парадокс состо1 Если бы люди подобным образом создавали, например, некоторый агрегат, то это бы выглядело так. Почти все болты и гайки имеют уникальный размер и резьбу. Серийных, «покупных» деталей либо нет совсем, либо нет информации о них, либо они непозволительно дороги, либо чем-то не подходят. Таким образом, детали и инструменты для их сборки приходится «вытачивать» на специальных станках, также специально созданных для этой цели. Или же представьте строительство крупного дома, при котором каждый кирпич имеет уникальный размер и форму, «стыкуясь» лишь с несколькими соседними кирпичами. Для строителей это был бы кошмар, но в программировании это обычное дело. ит в том, что чем больше людей привлекается в проект для решения проблем одного рода, тем больше проблем другого рода при этом создаётся. Управление коллективами в десятки, сотни и даже тысячи людей (такие проекты известны) требует огромных знаний и ресурсов, а недостатки такого управления могут привести (и часто приводят) к краху самый перспективный проект. 5. Изменение требований к программе в процессе её разработки. Дополнительные сложности возникают в результате изменений требований к программной системе уже в процессе разработки. Требования корректируются даже из-за того, что осуществление программного проекта часто само изменяет текущее состояние дел. Рассмотрение первых результатов (схем, прототипов) и использование системы после того, как она разработана и установлена, заставляют пользователей лучше понять и отчетливей сформулировать то, что им действительно нужно. Как выразился Э. Йордан, «пользователь не знает, чего он хочет, пока не увидит то, что он получил». В то же время этот процесс повышает квалификацию разработчиков в предметной области и позволяет им задавать более осмысленные вопросы, которые проясняют тёмные места в проектируемой системе. Чем создаваемая система больше, тем больше вероятность того, что требования к ней будут корректироваться. Уже для систем среднего размера эта вероятность практически равна единице. 1.4. Характеристики программного продукта Какое бы качество вы ни захотели бы оценить, всегда найдутся по крайней мере три противоречивых критерия его оценки. Из фольклора Наиболее важные характеристики разрабатываемого ПО необходимо предусматривать и учитывать заранее, начиная с самых ранних этапов разработки. В то же время, полная оценка наличия тех или иных свойств может быть выполнена только постфактум, то есть по завершении разработки. Если реализация необходимого свойства будет оценена как неудовлетворительная, то возможно повторение цикла разработки со всеми сопутствующими затратами. Для снижения риска возникновения такой ситуации необходимо запланировать регулярное проведение частичных оценок необходимых свойств с соответствующими коррективами процесса. По словам Эдсгера Дейкстры, «программист должен уметь демонстрировать, что его программа обладает требуемыми свойствами. Если эта мысль приходит к нему слишком поздно, он наверняка не сможет справиться с этой задачей: только если он позволяет этой цели влиять на разработку, есть надежда, что он справится с ней». Наиболее часто оценивают следующие высокоуровневые свойства программы [10]: • функциональные возможности; • надёжность; • практичность; • эффективность; • сопровождаемость; • мобильность. Указанные свойства являются свойствами «верхнего» уровня, то есть каждое из них подразумевает наличие множества второстепенных свойств. Все характеристики за ограниченное время разработки не могут быть обеспечены в одинаково превосходной степени, да это и не нужно. Каждый продукт требует особого внимания к некоторым ключевым характеристикам, которые можно развить за счет меньшего внимания к другим. Текстовому редактору важнее практичность, программе управления ядерным реактором – надёжность, а программе моделирования погоды – эффективность и т. д. Пригодность к развитию (сопровождаемость) кажется не слишком актуальным свойством по сравнению с другими, однако практика показывает, что часто в жизненном цикле ПО именно это требование становится важнейшим. Развиваемое ПО в силу именно этого свойства может быстро приобрести или улучшить любое другое свое качество, то есть стать правильнее, эффективнее, надёжнее и т. д. Накопленный к сегодняшнему дню в промышленном программировании опыт позволяет сделать вывод о том, что любые затраты (временные, финансовые, организационные) на то, чтобы грамотно построить ПО, сделать его сопровождаемым, многократно окупаются в дальнейшем. 1.5. Жизненный цикл программного продукта Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы её переделать, время находится. Закон Мескимена Программа имеет свою «жизнь», она рождается, живет, развивается и умирает. При этом в процессе её «жизни» многие виды связанной с ней человеческой деятельности циклически повторяются. Этот факт привел к появлению обобщающего и широко распространённого понятия жизненный цикл ПО (software life-cycle). Жизненный цикл (ЖЦ) программного средства есть совокупность взаимосвязанных процессов создания и последовательного изменения его состояния – от формирования исходных требований до окончания эксплуатации. Процесс ЖЦ – конкретный вид деятельности, систематически выполняющийся для решения определённых задач ЖЦ. Международный стандарт ISO/IEC 1 12207 «Software Life Cycle Processes» (и его отечественный аналог [9]) описывает следующие 17 процессов жизненного цикла, распределённых по трем категориям. Основные процессы (Primary Processes): • Приобретение (Acquisition). Определяет действия предприятия-покупателя, которое приобретает программный продукт или сервис ПО. • Поставка (Supply). Определяет действия предприятия-поставщика, которое снабжает покупателя программным продуктом или сервисом ПО. • Разработка (Development). Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт. • Функционирование (Operation). Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПО) в процессе её функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации, определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует и выполняет сам в рамках соответствующих обязанностей. • Сопровождение (Maintenance). Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой 1 ISO (International Organization for Standardization) – Международная организация по стандартизации, IEC (International Electrotechnical Commission) – Международная электротехническая комиссия. управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе. Вспомогательные процессы (Supporting Processes): • Документирование (Documentation). • Управление конфигурацией (Configuration Management). • Обеспечение качества (Quality Assurance). • Верификация (Verification). • Аттестация (Validation). • Совместный анализ (Joint Review). • Аудит (Audit). • Решение проблем (Problem Resolution). Организационные процессы (Organizational Processes): • Управление (Management). • Создание инфраструктуры (Infrastructure). • Усовершенствование (Improvement). • Обучение (Training). В данном пособии мы не ставим своей целью изучать вспомогательные и организационные процессы, коснемся лишь некоторых из них. Дадим более подробные определения некоторых вспомогательных процессов: • управление конфигурацией: процесс необходим для выделения элементов продукта, управления и отслеживания их изменений; • обеспечение качества: процесс предоставляет среду для обеспечения соответствия продукта контрактным требованиям и следования установленным планам; • верификация: процесс определяет, являются ли требования к системе полными и корректными и удовлетворяют ли этим требованиям результаты деятельностей по разработке; • аттестация, или валидация: процесс определяет, соответствует ли окончательный продукт конкретным целям его предполагаемого применения 1. Определения некоторых организационных процессов: 1 Если говорить неформально, верификация определяет, получается ли то, что запланировано, а валидация – получается ли то, что на самом деле нужно. Это не всегда одно и то же. управление: все задачи и виды деятельности менеджеров, включая планирование и контроль исполнения; • усовершенствование: процесс направлен на постоянное улучшение всего программного процесса, то есть всех остальных процессов; • обучение: повышение знаний и навыков сотрудников. Разумеется, наибольший для данного пособия интерес представляют основные процессы ЖЦ, а точнее, – основополагающий процесс разработки. Именно ему и будет посвящено данное пособие. • 1.6. Процессы разработки Работа программиста и шамана имеет много общего – оба бормочут непонятные слова, совершают непонятные действия и не могут объяснить, как это работает. Из фольклора Собственно разработку, в свою очередь, традиционно разделяют на специфичные виды деятельности – процессы разработки. Номенклатура и названия процессов разработки варьируются от книги к книге, от автора к автору, от методологии к методологии. Однако эти отличия при тщательном изучении, как правило, несущественны, так как возникают либо за счет объединения нескольких видов деятельности в один (например, программирование, тестирование и отладку вместе называют конструированием), либо за счет разделения процесса на несколько (например, анализ разделяют на анализ требований и системный анализ, а проектирование – на архитектурное и техническое). Иногда в список процессов разработки попадают такие технические виды деятельности, как интеграция программной системы (software integration), которая требуется для соединения в единый продукт независимо разрабатываемых частей. Иногда в список включают внедрение продукта (software deployment), процесс очень важный и зачастую очень сложный, но не относящийся к собственно разработке продукта. Итак, перечислим основные процессы разработки: • анализ; • проектирование; • программирование (кодирование, реализация); • тестирование; 1 • документирование . Далее приведена краткая характеристика указанных процессов. В процессе анализа (analysis) происходит исследование предметной области и выявляются наиболее важные требования к будущему продукту с точки зрения заказчика или пользователей. Конечным результатом анализа является выработка спецификации требований на программный продукт, содержащей требования в формальном виде. Специ1 Стандарт ISO/IEC 12207 относит документирование к вспомогательным процессам, но это должно касаться именно вспомогательной (проектной, организационной и т. п.), а не эксплуатационной (пользовательской) документации. Программный продукт по определёнию включает эксплуатационную документацию как составную часть, следовательно, её изготовление является неотъемлемой частью разработки. Кстати, текст программ также по определёнию является программным документом. фикация задает условия и эффект действия программ, не указывая способов достижения необходимого эффекта. ЕСПД 1 называет такую спецификацию техническим заданием (ТЗ). Спецификация (ТЗ), полученная на этапе системного анализа, является источником информации для процесса проектирования (design). При проектировании внешние, пользовательские требования к программному продукту преобразуются в детальные и конкретные требования к внутреннему устройству и функционированию будущей программы с точки зрения программистов. Проектирование также может быть определено как моделирование будущей системы. Процесс кодирования (coding) при наличии достаточно детального проекта является относительно рутинным. Фактически, кодирование – это процесс реализации проекта на конкретных языках программирования с использованием конкретного инструментария. Результатом кодирования являются собственно программы, как в исходном тексте, так и в бинарном виде, пригодном к исполнению. Процесс тестирования (testing) предназначен для выявления ошибок в программах и документации. Тестирование есть процесс выявления ошибок и (частично) установления соответствия созданного продукта его спецификации. Отладка есть процесс устранения ошибок в программе. Результатом тестирования и отладки являются отлаженные (насколько возможно) программы, для которых тестированием установлено (опять же, насколько возможно) соответствие спецификации. В процессе документирования (documentation) подготавливается документация, разносторонне описывающая будущий продукт как с «внешней», так и с «внутренней» стороны. Каждый документ подготавливается для конкретного типа читателей: менеджеров, конечных пользователей, системных администраторов, программистов и т. д. Традиционно считается, что примерно 20 % усилий уходит на анализ, 20 % – на проектирование, 20 % – на кодирование и 40 % – на устранение ошибок [39]. Впрочем, это соотношение зависит от размера и сложности создаваемой системы. Взаимосвязь процессов разработки и их результатов раскрывается в моделях и методологиях разработки, которые будут рассмотрены далее. 1 ЕСПД (Единая система программной документации) – комплекс государственных стандартов РФ, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации в РФ. 1.7. Модели разработки Контрольные точки должны быть реальными, точными, измеримыми событиями, определёнными с бритвенной остротой. Фредерик Брукс Модель разработки (иногда называемая парадигмой 1 разработки) – наиболее общий принцип организации процессов ЖЦ, обобщенная схема, характеризующая их последовательность и взаимосвязь. Модель разработки определяет концептуальный взгляд на организацию процессов разработки. Самая известная (в чем-то даже печально известная) модель – это так называемая водопадная (waterfall) модель, именуемая также каскадной, или последовательной. Водопадная модель. Главная характеристика водопадной модели (рис. 1.2) – разделение всего процесса на последовательные этапы, причем последующий этап начинается после того, как полностью завершен предыдущий. 1. Анализ 2. Проектирование 3. Программирование 4. Тестирование 5. Документирование Рис. 1.2. Водопадная модель2 В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какоголибо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто 1 Парадигма (от греч. paradeigma – пример, образец) – концепция, модель постановки проблем и их решения, образ мышления. 2 По выражению Ребекки Райордан, внешне водопадная модель просто эстетически прекрасна. выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы [3]. Увы, водопадная модель мало реалистична и может быть использована только для создания небольших систем. Перейдем к рассмотрению других моделей. Несмотря на то, что различные модели разработки известны десятки лет, в различных источниках существует удивительное разнообразие в наименовании, количестве и классификации альтернатив последовательной модели 1. Можно собрать суммарный список из терминов инкрементальная, итеративная, спиральная и эволюционная модели, причем произвольно и различно толкуемых. Также многие ошибочно полагают, что водопадная модель исторически была первой. К счастью, статья [17] расставляет все по местам, и читателю настоятельно рекомендуется прочитать её. Автор согласен с теми, кто называет альтернативой последовательной модели так называемую модель итеративной и инкрементальной разработки (iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Эволюционная (итеративная и инкрементальная) модель. Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом (см. рис. 1.3). Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю 1 Терминологический хаос в некоторых источниках усугубляется отсутствием чёткого разделения на общие модели и конкретные методологии, после чего полученная разнородная куча называется каким-нибудь невнятным термином вроде «стратегий разработки» или «подходов к разработке». требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение – инкремент – к его возможностям, которые, следовательно, развиваются эволюционно. Итак, итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения. Интеграция, тестирование Реализация Анализ Проектирование Рис. 1.3. Возможное представление IID (эволюционной модели) По выражению Т. Гилба, «эволюция – прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте» [17]. Нельзя не отметить, что подход IID имеет и свои отрицательные стороны, которые, по сути, – обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже». Существует много возможных вариантов реализации IID. Например, число итераций может быть запланировано заранее. Минимальный вариант – ровно две: на первой создается макет (прототип) будущей системы с ограниченной функциональностью, который показывается пользователям (заказчику), ревизуется, а затем выполняется вторая, окончательная, итерация. Такой подход настолько распространён, что иногда упоминается под названием «макетирование», или «прототипирование». Другой предельный случай – число итераций не планируется заранее и может быть очень большим, итерации являются очень короткими и добавляются по необходимости. Чтобы дать представление о возможных вариантах количества и длительности итераций процитируем несколько исторических примеров [17]. Компания TRW вела проект стоимостью 100 млн долл. для управления баллистическими ракетами, на что потребовалось 5 итераций, не ограниченных жёстко по времени. В IBM разработали систему для ВМС США в течение 4 лет (трудоёмкостью 200 человеко-лет) в серии из 45 ограниченных по времени итераций, продолжительность которых колебалась в пределах от одной до шести недель. В IBM в течение 31 месяца создали по заказу NASA ПО космических челноков в серии из 17 итераций, продолжительностью по восемь недель. Компания TRW в течение 4 лет вела модернизацию информационной системы командного центра, осуществив 6 итераций примерно по 6 месяцев. Рис. 1.4 схематично демонстрирует, как обычно при следовании IID распределяются ресурсы (люди, время, деньги) во времени [33]. Следует особо отметить, что любой процесс разработки, начавшись, практически никогда не «сходит на нет», то есть выпуск продукта обычно прерывает его в некоторой точке. 3 Затраты ресурсов 2 4 1 Начало 5 Время Рис. 1.4. Примерное распределение ресурсов при следовании IID: 1 – анализ; 2 – проектирование; 3 – конструирование; 4 – документирование; 5 – верификация Выпуск Спиральная модель (модель Боэма). Нельзя не упомянуть наиболее известный авторский вариант IID – спиральную (spiral) модель (см. рис. 1.5). Она была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 г. и впоследствии доработана. Важно понимать, что спиральная модель является не альтернативой модели IID, а специально проработанным вариантом. Увы, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID. Рис. 1.5. Спиральная модель Боэма Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков: 1. Дефицит специалистов. 2. Нереалистичные сроки и бюджет. 3. Реализация несоответствующей функциональности. 4. Разработка неправильного пользовательского интерфейса. 5. Перфекционизм, ненужная оптимизация и оттачивание деталей. 6. Непрекращающийся поток изменений. 7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. 8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. 9. Недостаточная производительность получаемой системы. 10. Разрыв в квалификации специалистов разных областей. В сегодняшней спиральной модели определён следующий общий набор контрольных точек [26]: • Concept of Operations (COO) – концепция (использования) системы; • Life Cycle Objectives (LCO) – цели и содержание жизненного цикла; • Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы; • Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации; • Final Operational Capability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации. 1.8. Методологии разработки Я не буду давать рекомендаций по выбору методологии. Само с у щ е с т в о в а н и е методологии обычно намного важнее, чем выбранная методология. Ребекка Райордан Мы уже выяснили, что модели разработки сами по себе неконкретны. Ту или иную модель трудно непосредственно использовать на практике, слишком много пришлось бы додумывать и «изобретать». А вот та или иная методология разработки в рамках выбранной модели конкретизирует (в идеале) все аспекты организации разработки, в том числе: • последовательность работ и их содержание; • артефакты, которые необходимо создавать в процессе работы: документы, диаграммы, исходные тексты и т. д.; • организацию команды и ролевую ответственность специалистов; • лучшие практики (best practices), позволяющие максимально эффективно воспользоваться методологией и её моделью [26]. Итак, методология разработки вполне конкретна и может быть непосредственно внедрена в организации для производства ПО. За многие десятилетия предложены десятки более или менее известных методологий разработки. Их источниками являлись конкретные авторы, авторские коллективы, коммерческие организации и даже целые страны в лице своих органов по стандартизации. Привести даже обзор всех методологий – крайне объёмная задача. Остановимся лишь на нескольких наиболее известных и практически значимых для российского разработчика методологиях. Следует помнить, что кроме ЕСПД (см. ниже), все современные методологии основаны на принципах IID, поэтому специального упоминания об этом не будет. 1.8.1. Единая система программной документации Единая система программной документации (ЕСПД) – комплекс государственных стандартов РФ, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации в РФ. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, но ЕСПД специфицирует и последовательность этапов разработки, и их содержание, что и позволяет назвать её в определённой мере методологией. ЕСПД, разумеется, в остальном мире малоизвестна, более того, многие стандарты ЕСПД не менялись с 70-х и 80-х гг. прошлого века, их содержание и терминология фактически и морально устарели. Ситуация с обновлением ЕСПД выправляется очень медленно, но есть определённые положительные сдвиги, вводятся стандарты, полностью соответствующие международным нормам, особенно это касается серии стандартов ГОСТ Р, разработанных на основе прямого применения международных стандартов ISO. Сам по себе процесс, описываемый в ЕСПД, является реализацией водопадной модели, поэтому он на практике использоваться по возможности не должен (да и не используется). Однако многие отдельные стандарты на территории России весьма востребованы, особенно стандарты на техническое задание и некоторые другие документы. Следует отметить, что стандарты ЕСПД ныне носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в этой области, поскольку в соответствии с законом РФ «О стандартизации» эти стандарты становятся обязательными на контрактной основе, то есть при ссылке на них в договоре на разработку (поставку) программного средства. 1.8.2. Microsoft Solutions Framework Microsoft в 1994 г. выпустила в свет пакет руководств по разработке, внедрению и сопровождению решений, построенных на основе своих технологий [28, 40]. Методология Microsoft Solutions Framework (MSF), согласно заявлениям компании, суммирует собственный опыт Microsoft. MSF содержит следующие части: • модель проектной группы; • модель процессов; • дисциплина управления проектами; • дисциплина управления рисками; • дисциплина управления подготовкой. Отличительной чертой MSF является тщательная проработка вопросов организации персонала. Модель проектной группы как раз очень подробно описывает этот вопрос. Процесс MSF ориентирован на «вехи» (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата 1. «Живые» документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки. Общеизвестно, что MSF уделяет значительное внимание вспомогательным и организационным процессам. В то же время, слабостью MSF всегда были именно технологические процессы разработки, которым в первых версиях методологии не уделялось вообще никакого внимания. Методология меняется, выходят обновленные версии (на момент написания – четвертая). Процесс разработки проработан теперь гораздо лучше. Сейчас официально объявлены две модификации методологии: MSF for CMMI и MSF for Agile («тяжёлая» и «лёгкая» версии). 1 Мы уже видели такой подход в спиральной модели Боэма. 1.8.3. Экстремальное программирование Существует группа так называемых agile-методологий (переводимых как быстрые, легкие или гибкие методологии), которые ориентированы на минимальный уровень формализации. Их авторы декларируют следующие принципы: 1. Взаимодействие людей важнее процессов и инструментов. 2. Работающая программа важнее исчерпывающей документации. 3. Сотрудничество с заказчиком важнее обсуждения контрактов. 4. Адаптация к изменениям важнее следования планам. Примерами agile-методологий являются Adaptive Software Development (ASD), Lean Development, SCRUM, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal Clear. Однако мы остановимся на наиболее известном представителе – методологии экстремального программирования (eXtreme Programming, XP)1. Автором методологии XP является Кент Бек, но большой вклад внесли Уорд Каннингэм, Мартин Фаулер и др. Авторы сформулировали следующие практики методологии: 1. Планирование замысла (planning game 2). Его задача – как можно быстрее определить объём работ, который нужно сделать до следующей версии. Решение принимается на основе бизнес-приоритетов заказчика и технических оценок. Планы изменяются, как только они начинают расходиться с действительностью или пожеланиями заказчика. 2. Частые выпуски (small releases). Самая первая работающая версия должна появиться как мо жно быстр ее и ту т же до лжна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени. 3. Метафора системы (system metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты. 4. Простой проект (simple design). Правило, предписывающее всегда выбирать самое простое из возможных проектных решений, способное решить текущие задачи3. 1 Которое обязано известностью не в последнюю очередь столь яркому и провокационному названию. Термин, переводимый всюду и всеми по-разному, от «игры в планирование» до «живого планирования». Видимо, просто неоднозначен (и поэтому неудачен) оригинальный английский термин. 3 Крайне похоже на принцип «живи сегодняшним днем», не так ли? И столь же сомнительно… 2 5. Разработка, управляемая тестированием (test-driven development). Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики пишут тесты, демонстрирующие возможности системы. 6. Переработка системы (refactoring). Код с целью улучшения постоянно перерабатывается. 7. Парное программирование (pair programming). Программисты работают в парах, непосредственно кодирует один, но обсуждают код вдвоем. 8. Непрерывная интеграция (continuous integration). Система собирается и проходит интеграционное тестирование как можно чаще, как только программисты оканчивают реализацию очередной функции. 9. Коллективное владение кодом (collective code ownership). Каждый программист имеет возможность в любое время усовершенствовать любую часть кода в системе, если он сочтет это необходимым; он же несет ответственность. 10. Заказчик всегда рядом (on-site customer). Представитель заказчика является частью команды и практически все время работы над системой проводит вместе с командой разработчиков. 11. 40-часовая неделя (40-hour weeks). Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд. 12. Открытое рабочее пространство (open workspace). Команда разработчиков располагается в большом помещении, окруженном комнатами меньшей площади. В центре рабочего пространства устанавливаются компьютеры, на которых работают пары программистов 1. 13. Всего лишь правила (just rules). Команда может в любой момент поменять правила, если её члены достигли принципиального соглашения по поводу внесенных изменений. Разумеется, этим списком методология не исчерпывается, но по сути все остальные материалы по XP являются обсуждением данных практик. 1 Впрочем, в других версиях списка практик XP данная практика отсутствует, зато присутствует другая – Стандарт кодирования (coding standard), означающая, что программисты должны придерживаться единых соглашений о стиле написания кода. Вообще, самое странное (забавное?) с этим списком то, что в различных книгах и статьях постоянно меняется его состав, меняются формулировки и названия принципов. После того, как автор познакомился с третьей-четвёртой версией, захотелось спросить, существует ли вообще такая методология, или каждый понимает её как хочет. Как видим, XP сосредоточена на организационных аспектах и на нюансах кодирования и тестирования, а процессы анализа, проектирования и документирования детально не рассматриваются. Это, увы, прямое следствие философии agile-методологий, которые изо всех сил пытаются уйти от бюрократизации процесса, обеспечивая «легкость». Верно, что проблема с излишней формализацией и бюрократизацией процесса разработки зачастую существует. Долгое время в индустрии бытовало мнение, что чем больше тщательно оформленной документации выпускается в ходе выполнения проекта – тем лучше. Часто на формальную сторону уходило больше времени и усилий, чем надо, в ущерб главной, «выпускающей» деятельности. Наличие самой лучшей документации не всегда спасает. Разработка идет значительно быстрее, а ошибок совершается значительно меньше, если помимо документации есть человек, который знает, что в ней написано, и может объяснить это всем заинтересованным лицам. Поскольку внешним, зримым проявлением бюрократизации является документирование, то оно в XP принципиально отторгается. Следовательно, отторгается формальный анализ и формальное проектирование, поскольку их результаты иначе как в форме документов (электронных или бумажных) формально зафиксированы быть не могут 1. Результат – постоянно меняющиеся требования к продукту и план системы хранятся лишь в «коллективной памяти» разработчиков. Это налагает на квалификацию разработчиков самые высокие требования. Данный факт упускают начинающие программисты, которым методологии типа XP кажутся самыми привлекательными, поскольку внешне не требуют трудных (и скучных!) навыков в анализе, проектировании и документировании. Дилетантам ошибочно кажется, что в XP нужно только и делать, что кодировать – просто рай для вчерашних студентов-недоучек! Однако успешные проекты 2, создаваемые в рамках XP (и agile-методологий вообще), возможны лишь при наличии в команде в немалом количестве высоких профессионалов – аналитиков, проектировщиков и программистов в одном лице, которые, как локомотивы, «тянут» весь проект3. В завершение разговора о agile-методологиях отметим следующее. 1 В книгах по XP дают такой совет: «для разработки общей архитектуры достаточно настенной доски для рисования. Если потребуется, дизайн можно сфотографировать и включить в документацию проекта». Ну, если это считается лучшими практиками, каковы же худшие? 2 И таких, как известно, довольно много. 3 Конечно, такие требуются в любой команде, но в XP они, так сказать, нужнее нужного. 1. Эти методологии имеют свою нишу, в которой могут быть успешными. По мнению автора, совокупность условий, при которых быстрые методологии являются возможным выбором, такова: • сплочённая команда опытных профессионалов; • тесный и постоянный контакт с заказчиком или пользователями; 1 • плохо определённые , постоянно меняющиеся требования; • относительно небольшой размер и срок проекта. 2. Эти методологии, как правило, все же не являются полноценными промышленными методологиями. Часто (как в случае с XP) это скорее набор «best practices», лучших (а иногда и сомнительных) практик, полезных советов, которые всё же не составляют единую самодостаточную систему, что бы там ни утверждали их авторы, и по отдельности могут с успехом применяться (и применяются) в других методологиях. 1 Но только не по вине самих разработчиков! 1.8.4. Rational Unified Process В настоящее время Rational Unified Process (RUP) является фактически стандартной методологией разработки ПО. Это объясняется многими факторами, в том числе следующими: • RUP тщательно описывает все рабочие процессы разработки и все создаваемые в этом процессе артефакты, не упуская практически ничего и не заставляя разработчиков «додумывать»; • методология использует UML как целостный и универсальный графический язык представления артефактов; • с самого начала RUP сопровождался мощной средой Rational Rose, которая обеспечила полную инструментальную поддержку методологии, делая её не только методологией, но и технологией; • основными авторами RUP и UML стали люди, известные и авторитетные в программной индустрии, – «тройка друзей» Г. Буч, А. Якобсон 1 и Дж. Рамбо, а также Кен Хартман и Филипп Крачтен. Официально RUP является продуктом фирмы Rational Software Corp., в настоящее время ставшей подразделением IBM. Формально методология RUP является детализацией более общей методологии Unified Software Development Process (USDP) [35]. В цикле разработки продукта RUP выделяет четыре крупные фазы (показывающие уровень развития продукта), каждая из которых включает в себя одну или несколько итераций. 1. Inception (начало). В данной фазе: • формируются видение и границы проекта; • создается экономическое обоснование (business case); • определяются основные требования, ограничения и ключевая функциональность продукта; • создается базовая версия модели вариантов использования; • оцениваются риски. 1 То Айвар Якобсон, то Ивар Джекобсон, в зависимости от настроения переводчиков. При завершении фазы оценивается достижение вехи целей жизненного цикла (Lifecycle Objective Milestone), которая предполагает соглашение заинтересованных сторон о продолжении проекта. 2. Elaboration (уточнение, детальная проработка). Производится более тщательный анализ предметной области и построение архитектуры. Это включает в себя: • детальное описание большинства вариантов использования (не менее 80 % готовности); • спроектированную осуществимую архитектуру (executable architecture), реализующую архитектурно-значимые варианты использования; • обновленное экономическое обоснование и оценки рисков; • план разработки для всего проекта. Успешное выполнение фазы означает достижение вехи архитектуры жизненного цикла (Lifecycle Architecture Milestone). 3. Construction (построение, конструирование). Во время этой фазы происходит реализация большей части функциональности продукта. Фаза завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability Milestone). 4. Transition (внедрение, передача). Создается финальная версия продукта, которая передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. Если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе «Начало», итерация выполняется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release Milestone) и завершение полного цикла разработки. Значительная часть унифицированного процесса связана с созданием и использованием различных моделей разрабатываемой системы, и здесь «на сцену» выходит UML. RUP полностью «завязан» на UML. Используются модели вариантов использования (основа основ), группы моделей анализа, проектирования, тестирования и развертывания. К сожалению, объём пособия не позволяет рассмотреть RUP детально. Обращайтесь к обширной литературе, в т. ч. [16, 35] 1.9. Выбор и адаптация методологии разработки Легким движением руки брюки превращаются… Из кинокомедии «Бриллиантовая рука» В настоящее время достигнуто понимание того, что в общем случае каждый конкретный проект и каждая конкретная фирма требуют своей методологии, учитывающей всю специфику и фирмы, и проекта. Очевидно, что никакая фирма не способна с легкостью менять методологии, поскольку их внедрение и освоение требуют серьезных затрат времени и денег, да и риск ошибиться слишком велик. Поэтому наилучшим решением является адаптация (tailoring) некоторой принятой в организации методологии к разным проектам. Скажем, Алистер Кокбёрн фактически предложил целое семейство методологий Crystal для проектов разного размера и формальности. Методология RUP по замыслу авторов также является средой (framework), которая может и должна быть адаптирована под конкретную организацию и/или проект. Существуют готовые адаптации, например Agile Unified Process, Open Unified Process (OpenUP) и др. Скажем, OpenUP/Basic является предельно облегченной версией RUP, соперничающей с agile-методологиями, а вариант Enterprise Unified Process рассчитан на самые тяжеловесные проекты. Еще одним вариантом «гибкого RUP» является процесс dX Роберта Мартина; dX – это процесс, полностью соответствующий RUP, и при этом являющийся копией ХР (чтобы понять шутку, переверните «dX»). По словам М. Фаулера, dX создан для тех, кто вынужден использовать RUP, хотя хотел бы работать по XP. Авторы MSF также осознали необходимость вариантов методологии, вследствие чего появились два направления развития: более формальное MSF for CMMI и менее формальное MSF for Agile. Итак, сколько же формализма требуется в зависимости от задачи? А. В. Закис перечисляет следующие факторы, влияющие на оптимальный уровень формализации процесса и, следовательно, на выбор и адаптацию методологии: • Масштаб проекта. Чем больше людей участвует в проекте, тем более формально он должен вестись. • Надёжность программы. Продукты, в которых ошибки могут приводить к тяжёлым последствиям (вплоть до гибели людей), должны создаваться при существенно более высоком уровне формализации, чем те пр одукты, в которых ошибки приводят только к временным неудобствам (как, например, при разработке Web-сайта). • Распределённость команды. Чем компактнее расположены участники, чем легче им общаться между собой, тем менее формализованным может быть проект. • Новизна проекта. Чем более новые для разработчиков технологии используются, чем меньше разработчики знакомы с предметной областью, тем более тщательно надо прорабатывать проектные решения, и соответственно тем более строго это должно происходить. • Требования заказчика. Они существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий. • Долговечность проекта. Если разрабатываемое для конкретного заказчика ПО предполагается через пару лет заменить новым, то вряд ли есть смысл тратить много сил на документацию, которая могла бы значительно удешевить более длительный процесс сопровождения ПО. Если срок жизни проекта предполагается достаточно большим, без хорошей документации не обойтись. Есть системы, созданные десятки лет тому назад и продолжающие эксплуатироваться. В такой ситуации без качественной документации поддержка системы в работоспособном состоянии была бы просто невозможна. ГЛОССАРИЙ Адаптация (tailoring) методологии разработки – Процесс приспособления методологии разработки под специфику конкретной организации и/или конкретного проекта. Акциденции – Сложности разработки, сопутствующие производству программного обеспечения, но не внутренне ему присущие. Анализ требований – Процесс разработки, включающий исследование предметной области, выявление и фиксацию наиболее важных требований к будущему продукту с точки зрения заказчика или пользователей. Архитектурно-значимые проектные решения – Проектные решения, которые являются наиболее важными, определяющими для системы; каждое из них влияет на то, какой будет существенная часть системы или вся система. Безнадёжный проект – Проект, имеющий отклонение от нормы, как минимум, на 50 % (срок разработки сжат в два раза или людских ресурсов в два раза меньше требуемого). Безопасное программирование (defensive programming) – Подход к написанию программ, снижающий ущерб от программных ошибок; при этом программа сама выявляет многие ошибки, сообщает о них пользователю и/или разработчику и даже борется с ними. Валидация – Процесс жизненного цикла, который определяет, соответствует ли окончательный продукт конкретным целям его предполагаемого применения. Вариант использования (Use case) – Формальное описание взаимодействия системы и пользователя при решении конкретной задачи. Каждый ВИ нацелен на конкретную бизнес-цель (конкретную задачу). Верификация – Процесс жизненного цикла, который определяет, являются ли требования к системе полными и корректными и удовлетворяют ли этим требованиям результаты деятельностей по разработке. Водопадная модель разработки – Модель разработки, предполагающая разделение всего процесса на последовательные этапы, причем последующий этап начинается после того, как полностью завершен предыдущий. Восходящее проектирование (bottom-up design) – Проектирование «снизу вверх», при котором выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления. Декомпозиция системы (decomposition) – Разделение системы как целого на совокупность взаимосвязанных элементов. Дефект (ошибка) программы – Отличие между реально существующим и требуемым свойствами программы. Документирование (documentation) – Процесс разработки, в котором для продукта подготавливается эксплуатационная документация. Дружественный (user-friendly) интерфейс пользователя – Интерфейс пользователя, который учитывает психологические и физиологические особенности человека для обеспечения максимально возможного комфорта и эффективности решения его задач. Единая система программной документации (ЕСПД) – Методология разработки, представляющая собой комплекс государственных стандартов РФ, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации в РФ. Жизненный цикл программного средства (software life-cycle) – Совокупность взаимосвязанных процессов создания и последовательного изменения его состояния — от формирования исходных требований до окончания эксплуатации. Зацепление (linkage) модуля/класса – Сила связей модуля (класса) с другими модулями (классами), мера его независимости. Инкрементальная модель разработки – См. Эволюционная модель разработки. Интерфейс пользователя (user interface) – Система правил и средств, соответственно регламентирующих и обеспечивающих взаимодействие пользователя и вычислительной системы в процессе выполнения данной программы. Интуитивно-понятный интерфейс пользователя – Интерфейс пользователя, который позволяет пользователю эффективно применять накопленный опыт, с меньшими усилиями «догадываться» о том, как решить ту или иную задачу, без необходимости специального обучения или чтения документации. Исполняемая программа (executable program) – совокупность машинного кода и данных, пригодных для исполнения процессором. Итеративная модель разработки – См. Эволюционная модель разработки. Качество программы (quality) – Весь объём признаков и характеристик программы, который относится к её способности удовлетворять установленным или предполагаемым потребностям. Кодирование (coding) – Процесс разработки, в котором выполняется реализация проекта на конкретных языках программирования с использованием конкретного инструментария. Конфигурация (configuration) – Совокупность всей информации о проекте в виде файлов и документов проекта. Методология разработки – Конкретизация некоторой модели разработки, увязывающая в идеале все аспекты организации разработки, в том числе: последовательность работ и их содержание; артефакты, которые необходимо создавать в процессе работы: документы, диаграммы, исходные тексты и т. д.; организацию команды и ролевую ответственность специалистов; лучшие практики (best practices), максимально эффективно воспользоваться методологией и её моделью позволяющие Мобильность (Portability) программы – Набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое. Модель разработки – Наиболее общий принцип организации процессов жизненного цикла; обобщенная схема, характеризующая их последовательность и взаимосвязь; концептуальный взгляд на организацию процессов разработки Модуль программы – Единица структуры исходного текста программы, оформляемая, как правило, в виде отдельного файла; является единицей компиляции, описания и администрирования. Надёжность (Reliability) программы – Набор атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени. Нисходящее проектирование (top-down design) – Проектирование «сверху вниз», которое начинается с верхнего уровня абстракции — представления системы как «черного ящика». Система иерархически разбивается на подсистемы/классы и т. д. вплоть до элементов нижнего уровня. Обеспечение качества – Процесс жизненного цикла, который предоставляет среду для обеспечения соответствия продукта контрактным требованиям и следования установленным планам. Открытый стандарт – Общедоступная и не секретная техническая спецификация, у которой либо отсутствует правообладатель (общественное достояние), либо же правообладателем является общественная организация, не совпадающая тождественно с производителем, использующим спецификацию в своих продуктах. Парадигма разработки – См. Модель разработки. Поставка (Supply) – Процесс жизненного цикла, который определяет действия предприятия-поставщика, которое снабжает покупателя программным продуктом или сервисом ПО. Практичность (Usability) программы – Набор атрибутов, относящихся к объёму работ, требуемых для использования и индивидуальной оценки такого использования определённым или предполагаемым кругом пользователей. Предметная (проблемная) область (application/problem domain) – Система понятий и объектов конкретной области человеческих знаний. Приобретение (Acquisition) – Процесс жизненного цикла, который определяет действия предприятия-покупателя, которое приобретает программный продукт или сервис ПО Программа-компонент – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. Программная система (program / software system) – Программа, состоящая из двух или более компонентов и (или) систем, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другой системы. Программное изделие – См. программный продукт. Программное обеспечение (software), ПО – Совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации. Программное средств – См. программный продукт. Программный комплекс – См. программная система. Программный продукт (software product, production program) – Прошедшая испытания программа или программная система, полностью готовая для продажи (поставки) и снабженная всей необходимой документацией. Проект (design) – Результат проектирования; формальная модель (а точнее, совокупность моделей) будущей системы. Проект (project) – Комплекс действий, направленных на создание продукта или услуги Проектирование (design) – Процесс разработки, в котором внешние, пользовательские требования к программному продукту преобразуются в детальные и конкретные требования к внутреннему устройству и функционированию будущей программы с точки зрения программистов; моделирование будущей системы Процесс жизненного цикла – Конкретный вид деятельности, систематически выполняющийся для решения определённых задач жизненного цикла. Разработка (Development) – Процесс жизненного цикла, который определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт. Резервное копирование (backup) – Регулярный процесс создания копии данных на энергонезависимом носителе (жёстком диске и т. д.), предназначенной для восстановления данных в случае их повреждения или разрушения. Риск разработки – Действующий/развивающийся фактор процесса, обладающий потенциалом негативного влияния на ход процесса. Связность (cohesion) модуля/класса – Мера внутренних связей модуля (класса), то есть связей между его элементами. Сложная система – Простая система характеризуется тем, что человек уверенно может перебрать все связи между её элементами, в сложной он этого сделать не в состоянии; сложная система обладает недетерминированным (точнее, не полностью детерминированным) поведением. Сопровождаемость (Maintainability) программы – Набор атрибутов, относящихся к объёму работ, требуемых для проведения конкретных изменений (модификаций). Сопровождение (Maintenance) – Процесс жизненного цикла, который определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе. Спиральная модель разработки – Авторский вариант эволюционной модели разработки, предложенный Б. Боэмом (Barry Boehm), в котором введена концепция контрольных точек и уделено особое внимание рискам разработки. Структура декомпозиции работ (Work Breakdown Structure, WBS) – Описание содержания работ по проекту в виде иерархической структуры. Тест – Эксперимент, выполняемый над программой, для которого определены критерии успешности. Тестирование (testing) – Процесс разработки, в котором выполняется выявление ошибок и (частично) установления соответствия созданного продукта его спецификации. Тестовый сценарий – Спецификация проведения теста, которая описывает порядок ввода тестовых данных и критерии успешности, то есть те признаки, по которым следует судить о правильности работы программы (успех) или о наличии ошибки (неуспех). Техническое задание – Спецификация требований к создаваемому программному продукту с точки зрения заказчика; в РФ обычно подготавливается в соответствие с ЕСПД. Технология программирования (software engineering) – Технологическая дисциплина, изучающая методы программирования и производства программного обеспечения. По определению IEEE, технология программирования есть (1) применение систематического, упорядоченного, измеримого подхода к разработке, использованию и сопровождению ПО, то есть использование инженерного искусства в программном обеспечении и (2) создание подходов п. (1). Унифицированный язык моделирования, UML (Unified Modeling Language) – Язык графического описания для объектного моделирования в области разработки программного обеспечения. Управление конфигурацией (Configuration Management) – Процесс жизненного цикла, который необходим для выделения элементов продукта, управления и отслеживания их изменений. Управление проектом – Процесс жизненного цикла, который включает все задачи и виды деятельности менеджеров, включая планирование и контроль исполнения. Функциональные возможности (Functionality) программы – Набор атрибутов, относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности. Функционирование (Operation) – Процесс жизненного цикла, который определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПО) в процессе её функционирования в интересах пользователей. Целостный интерфейс пользователя – Интерфейс пользователя, обеспечивающий стилевое единство, последовательное, согласованное применением одних и тех же принципов во всех частях интерфейса программы. Шаблон (паттерн) проектирования (design pattern) – Формализованное описание часто встречающейся задачи проектирования, удачное решение данной задачи, а также рекомендации по применению этого решения в различных ситуациях. Эволюционная модель разработки – Модель разработки, которая предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Эффективность (Efficiencies) программы – Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объёмом используемых ресурсов при установленных условиях. Язык программирования – Формальная знаковая система, предназначенная для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, задающих внешний вид программы и действия, которые выполнит исполнитель (компьютер) под ее управлением. Agile-методологии – Группа методологий разработки, которые ориентированы на минимальный уровень формализации. В группу входят методологии Adaptive S oftware Development ( ASD), Le an De velopment, S CRUM, Feature Dr iven De velopment ( FDD), Dynamic Systems Development Method (DSDM), Crystal Clear, eXtreme Programming. Capability Maturity Model, CMM (модель зрелости возможностей) – Модель зрелости процессов создания программных средств, созданная в 1987 г. организацией Software Engineering Institute (SEI): эволюционная модель развития способности компании разрабатывать программное обеспечение. ISO 9000 – Серия стандартов ISO, которые применяются при создании и совершенствовании систем менеджмента качества организаций. Microsoft Solutions Framework (MSF) – Методология разработки, предложенная компанией Microsoft; согласно заявлениям компании, суммирует собственный опыт Microsoft. Object Management Group (OMG) – Консорциум (рабочая группа), занимающийся разработкой и продвижением объектно-ориентированных технологий и стандартов. Некоммерческое объединение, разрабатывающее стандарты для создания интероперабельных, то есть платформо-независимых, приложений на уровне предприятия. Rational Unified Process (RUP) – Методология разработки программного обеспечения, созданная компанией Rational Software (в настоящее время подразделение компании IBM). SPICE (Software Process Improvement and Capability dEtermination) – Единый стандарт ISO оценки программных процессов организации. Возврат из справки Home Панель управления – содержит перечень разделов, а также кнопки навигации, управления программой просмотра и вызова функции поиска по тексту. Нажатие клавиши «Home» на клавиатуре вызывает переход к титульной странице документа. С титульной страницы можно осуществить переход к оглавлению (в локальной версии курса). PgUp Нажатие клавиши «PgUp» («PageUp») или показанных клавиш со стрелками на клавиатуре вызывает переход к просмотру предыдущей страницы относительно просматриваемой в настоящий момент согласно порядку их расположения в документе. PgDn Нажатие клавиши «PgDn» («PageDown») или показанных клавиш со стрелками на клавиатуре вызывает переход к просмотру следующей страницы относительно просматриваемой в настоящий момент согласно порядку их расположения в документе. Просматриваемый в данный момент раздел. Доступные разделы. Alt + F4 В зависимости от текущего активного раздела в перечне могут присутствовать подразделы этого раздела. Нажатие комбинации клавиш «Alt»+«F4» на клавиатуре вызывает завершение работы программы просмотра документа (в локальной версии курса). Кнопка переключения между полноэкранным и оконным режимом просмотра. Нажатие левой клавиши «мыши» или вращение колёсика в направлении «от себя» вызывает переход к просмотру следую щей страницы относительно просматриваемой в настоящий момент согласно порядку их расположения в документе. Кнопки последовательного перехода к предыдущей и следующей страницам. Кнопка возврата к предыдущему виду. Используйте её для обратного перехода из глоссария. Кнопка вызова функции поиска по тексту. Нажатие правой клавиши «мыши» или вращение колёсика в направлении «к себе» вызывает переход к просмотру предыдущей страницы относительно просматриваемой в настоящий момент согласно порядку их расположения в документе. Кнопка перехода к справочной (этой) странице. Кнопка завершения работы.
