Целью и результатом разработки новых изделий является само изделие. Изделие относится к сфере материальных объектов и служит для удовлетворения требований производства и потребностей человека. Сама разработка нового изделия - это особый этап, относящийся к сфере умственной деятельности.

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

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

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

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

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

Понятие «изделие» также имеет широкий диапазон значений. Изделием называется любой предмет или набор предметов производства, подлежащих изготовлению на предприятии. Под изделием подразумеваются все объекты материального производства и их составные части машины, технологическое оборудование, механизмы, функциональные системы и др. (рис.1). Установлены следующие виды изделий: детали, сборочные единицы, комплексы, комплекты.

Рис. 1. Виды изделий и их структур

Деталью называется изделие, изготовленное из материала одной марки без применения сборочных операций или с использованием местных соединительных операций (сварки, пайки, склеивания и т.п.).

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

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

Комплект - несколько изделий общего функционального назначения вспомогательного характера, не соединяемых на предприятии изготовителе с помощью сборочных операций.

В процессе подготовки производства и изготовления изделий в расчет принимаются и другие принципы классификации изделий: комплектующие изделия, покупные изделия, изделия основного производства, изделия вспомогательного производства, изделия серийного производства и др.

Иногда определенные изделия называют конструкциями, например «металлическая конструкция», «железобетонная конструкция» и др., подразумевая под этим нечто конкретное. Чтобы внести ясность в эти понятия, целесообразно проследить весь процесс создания нового изделия, начиная с зарождения идеи и кончая изготовлением действующего образца. Разработка является мыслительным процессом, умственной деятельностью, в результате которой создается конструкция. Конструкция - это строение, устройство, взаимное расположение частей изделия. Конструкция является одним из основных свойств изделия, позволяющих отличить одно изделие от другого.

Специализация конструкторских организаций

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

Конструкторские организации и подразделения классифицируются по двум главным признакам: подчиненности и специализации.

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

Основная классификация конструкторских организаций осуществляется по специализации. Специализация производства является экономически наиболее целесообразной формой его организации. Специализация конструкторских организаций основывается на разработке конструктивно и технологически подобных по назначению, по типоразмерам изделий.

Определенные этапы разработки новой техники производятся в разных проектно-конструкторских организациях, что и определяет место этих организаций в подготовке производства.

Головной проектный институт (ГИПРО) производит выбор основных направлений и разработку перспективных планов комплексных разработок, а также выполняет разработку рабочих проектов и частей проектов.

Научно-исследовательский институт (НИИ) создает изделия принципиально новой конструкции на базе специальных теоретико-экспериментальных исследований.

Разработки доводятся до изготовления опытного образца.

Научно-исследовательский и проектно-технологический институт (НИПТИ) создает принципиально новые технологические процессы и осуществляет модернизацию существующих. Производит опытные проверки технологических процессов и изготовление необходимой оснастки.

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

Исследовательские проблемные лаборатории и КБ втузов работают над созданием принципиально новой техники и модернизацией существующей; решают вопросы по увеличению надежности. Работы производятся на теоретическом и экспериментальном уровнях.

Проектно-конструкторские подразделения промышленных предприятий и фирм осуществляют создание и модернизацию выпускаемых изделий, создание и модернизацию техники, работающей на предприятии; производят оснащение производства новыми видами нестандартизированного оборудования, приспособлениями, инструментом.

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

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

Предметная специализация имеет следующие преимущества:

1 - возможность параллельной разработки отдельных частей проекта;

2 - сокращение сроков проектирования, обусловленных сокращением межоперационного пролеживания частей проекта при согласовании конструкторской документации;

3 - облегчение управления процессами разработки, так как она проходит в стенах одной организации;

4 - возможность использования в новых разработках типовых и унифицированных деталей и узлов, освоенных ранее;

5 - возможность обширного сбора информации, используемой в разработке;

6 - возможность расширения уровня знании и технического кругозора разработчиков.

Наряду с преимуществами предметная специализация имеет ряд недостатков:

1 - система специализации нерациональна для сложных конструкций, включающих сложные электрические, электронные, гидравлические и другие системы;

2 - не способствует выполнению разработки по всем частям на высоком техническом уровне;

3 - требует руководителя разработки с обширными знаниями по всем частям проекта;

4 - препятствует узкой специализации разработчиков.

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

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

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

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

Привет, Хабр. Меня зовут Владимир Разуваев, я руководитель департамента бизнес-консалтинга. Наша команда занимается тем, что помогает клиентам понимать значимость программных активов и управлять ими. В этом посте я предлагаю поговорить о внутренних разработках, которые в той или иной мере есть практически в любой компании.

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

Опыт последних трёх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный «на коленке» софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения: для них написанное собственной командой программистов ПО – альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки – мы видим это по количеству соответствующих обращений в наш департамент.

Пять шагов к формализации внутренних разработок

Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи - авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.

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

Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чёткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме.

Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно: дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит – либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это – лишние риски, которые ни к чему любой компании.

Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.

Шаг четвертый. На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию.

Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).

Итак, чтобы внутренняя разработка была полностью формализована, она должна быть защищена следующими документами:

1. Служебное задание
2. Докладная записка о выполнении задания
3. Акт приемки программного продукта к эксплуатации в компании
4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс

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

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

На что может рассчитывать рядовой разработчик?

Это очень частый вопрос со стороны программистов: «Какую выгоду я, как создатель, получаю от формализации написанного мною приложения?» Если работодатель, для которого разработчик создал приложение, юридически правильно это приложение формализовал, программисту остается так называемое личное неимущественное право автора. Никаких денежных бенефитов оно с собой, скорее всего, не несет, поскольку создатель уже получил вознаграждение за выполненную работу, и никакими имущественными правами на написанный им софт он уже не обладает. Неимущественные права позволяют потешить собственное эго и добавить проект в портфолио. Например, автор разработки вправе сам предложить название ПО, разрешать указывать свое имя в контексте приложения. Но имейте в виду, что право указывать имя автора, либо его не указывать, тоже регулируется вышеупомянутым трудовым договором. Отмечу ещё, что неимущественные права распространяются в том числе на несколько человек, то есть у продукта может быть несколько авторов.

Обратите внимание, что если на стадии разработки, или в течение трех лет после, работодатель объявил, что программный продукт представляет из себя коммерческую тайну, то разглашать любые сведения о ПО запрещено.

Почему важна бумажная работа?

Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.

Представьте себе ситуацию, что в компанию приходит проверка, которая обнаруживает непонятный «левый» софт, на который нет никакой документации, подтверждающей его лицензионность. Оправдание «это наши программисты разработали» в данном случае не работает, нужны подтверждающие документы. Без них компании может грозить изъятие аппаратно-программного обеспечения до выяснения обстоятельств. Вероятно, компания рано или поздно докажет, что данный софт это их собственная разработка, но силы и время, потраченные на это, не сопоставимы с рисками для непрерывности бизнеса, которые компания может понести. Такая вот страшилка вместо заключения.

Если остались вопросы – пишите в комментариях, я постараюсь ответить.

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

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

Имея дело с разработкой сложной системы, большинство специалистов сегодня полагают, что лучше всего применять компонентно-сервисный подход. Система представляется как набор взаимодействующих между собой агентов – сервисов (компонентов), и главная задача разработчика – определить бизнес-правила и запрограммировать их в виде взаимодействий. Соответственно, процесс разработки становится инкрементальным: сначала программируется одно взаимодействие, затем следующее и т.д. То же самое и с компонентами – они реализуются по мере потребности.

Все, конечно, верно. Вместо функций и процедур теперь программист оперирует с интерфейсами компонент, бизнес-объектов, сервисов, что позволяет ему в кратчайшие сроки создавать сложные программные комплексы. Однако «интеллекта» в этих комплексах не больше, чем в самой примитивной бактерии. Такие прикладные системы как Facebook и Amazon – не более чем нагромождение различного функционала для структурированного сбора, хранения и представления данных. При работе с ними человека данные становятся информацией. Без человека эти системы – просто наборы нулей и единиц. Поэтому ценность таких систем определяется ценностью для человека организуемой ими информации. При этом идеи организации информации принадлежат тому же человеку, а не системам.

Но идеи организации не проектируются, не разрабатываются как ПО. Они рождаются в головах изобретателей в результате творческого процесса. Далее такие идеи реализуются в системах типа Oracle, DB2, AutoC AD, Microsoft Windows и т.д. А эти системы уже не строятся на базе компонентно-сервисного подхода. Здесь все куда более сложно! Ни одна из имеющихся методологий разработки программного обеспечения не в состоянии полноценно поддерживать процесс создания системного ПО. Тут у каждой фирмы свое ноу-хау, своя история.

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

Ситуация во многом напоминает проблему вокруг самосовершенствования личности. Тысячи гуру, тренеров, коучеров, мастер-классов и т.п. неустанно работают над поиском универсальной формулы, что поможет человеку стать успешным и счастливым. Многие люди по-настоящему верят, что такая формула существует. А невезение связано с «дурным» временем, агрессивной внешней средой, досадными случайностями.

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

Нужно ли заказчику понимание проблем разработки ПО? Конечно, нужно, если он «грамотный» заказчик. Например, когда потенциальный исполнитель ему с гордостью заявляет о своей приверженности к Agile и Scrum, есть над чем задуматься. Во-первых, у исполнителя явно не все в порядке с организацией собственного производства. Во-вторых, исполнитель не умеет и не хочет работать с клиентом. Есть еще и в-третьих, и в-четвертых...

«Грамотный» заказчик всегда пытается найти «грамотного» исполнителя. И критерием отбора здесь отнюдь не является знание Scrum. Имеется множество факторов, на которые заказчик обращает внимание. Но это уже коммерческая информация – не для статьи.

Модель жизненного цикла информационной системы

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

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

Среди основных процессов жизненного цикла наибольшую важность имеют три: разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.

Разработка информационной системы включает в себя все работы по созданию информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для тестирования разработанных программных продуктов; разработку материалов, необходимых для обучения персонала.

Разработка является одним из важнейших процессов жизненного цикла информационной системы и, как правило, включает в себя стратегическое планирование, анализ, проектирование и реализацию (программирование).

Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:

• конфигурирование базы данных и рабочих мест пользователей;
• обеспечение пользователей эксплуатационной документацией;
• обучение персонала.

Основные эксплуатационные работы включают:

• непосредственно эксплуатацию;
• локализацию проблем и устранение причин их возникновения;
• модификацию программного обеспечения;
• подготовку предложений по совершенствованию системы;
• развитие и модернизацию системы.

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

Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией. Это тот вспомогательный процесс, который поддерживает основные процессы жизненного цикла информационной системы, прежде всего процессы разработки и сопровождения. При разработке проектов сложных информационных систем, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и, следовательно, иметь несколько вариантов реализации и/или несколько версий одной реализации, возникает проблема учета их связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты информационной системы на всех стадиях ее жизненного цикла.

Процесс разработки программного обеспечения (англ. software development process, software process) – структура, согласно которой построена разработка программного обеспечения (ПО).

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

Выделяют следующие основные модели процесса или методологии разработки ПО:

• Каскадная разработка или модель водопада (англ. waterfall model) – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
• Итеративная разработка (англ. iteration – повторение) – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование – Реализация – Проверка – Оценка (англ. plan-do-check-act cycle).

Каскадная модель

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал, как эта модель может быть доработана до итеративной модели.

В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.

Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные методы проектирования хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографиях, стандартах, учебниках. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими.

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

Основные этапы разработки по каскадной модели. За десятилетия существования каскадной модели разбиение работ на стадии и названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее, все же можно выделить ряд устойчивых этапов разработки, практически не зависящих от предметной области:

• анализ требований заказчика
• проектирование
• разработка
• тестирование и опытная эксплуатация
• сдача готового продукта.

Рис. Каскадная модель разработки

На первом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.

На втором этапе разрабатываются проектные решения, удовлетворяющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реализации проекта.

Третий этап – реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.

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

Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования выполнены в полной мере.

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

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

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

Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов.

Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

В каскадной модели процесса разработки программного обеспечения процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. На основе такой методологии построены российские стандарты и ГОСТы по созданию автоматизированных систем (34-й и 19-й серий), например

ГОСТы 34-й серии:

• ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;
• ГОСТ 34.201-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем»;
• ГОСТ 34.320-96 «Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы»;
• ГОСТ 34.321-96 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными».

ГОСТы 19-й серии:

• ГОСТ 19.001-77 «Единая система программной документации. Общие положения»;
• ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов»;
• ГОСТ 19.102-77 «Стадии разработки»;
• ГОСТ 19.103-77 «Обозначения программ и программных документов»;
• ГОСТ 19.104-78 «Основные надписи»;
• ГОСТ 19.105-78 «Общие требования к программным документам»;
• ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»;
• ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению»;
• ГОСТ 19.202-78 «Спецификация. Требования к содержанию и оформлению» и др.

Методические указания:

• РД-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы требования к содержанию документов».

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

Основные достоинства каскадной модели. Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим ее основные достоинства.

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

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

Данная модель разработки хороша в следующих ситуациях:

• при внедрении для проектов длительностью от нескольких недель до 2–3 месяцев, т. к. описанные требования не успевают устареть;
• при внедрении систем, где нет подзадач и нескольких этапов разработки функционала (например, после разработки основного функционала СЭД нужно будет доработать ее взаимодействие с системой бухгалтерского учета, а требований к этому взаимодействию пока нет);
• когда требования к создаваемой системе четко определены и зафиксированы.

Несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно последовательным процессом разработки.

Недостатки каскадной модели. Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:

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

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

Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.

Возврат на более ранние стадии. Данный недостаток каскадной модели в общем-то является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы.

Самым же неприятным является то, что недоработки предыдущего этапа могут обнаруживаться не сразу на последующем этапе, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области). Это означает, что часть проекта должна быть возвращена на начальный этап работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап, поэтому в реальности каскадная схема разработки выглядит так, как показано на рис.

Рис. Реальный процесс разработки по каскадной схеме.

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

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

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

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

Следует также отметить, что, помимо изучения нового материала, не отпадает необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.

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

В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени.

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

Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки – этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено, запоздалая оценка порождает серьезные проблемы при выявлении ошибок анализа и проектирования – требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. Причем возврат проекта на доработку вследствие этих причин не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится», и система никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.

Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

Помимо рассмотренных существует еще один серьезный недостаток, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с конфликтом (не всегда явным) между разработчиками, участвующими в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифицировать ответственного за ошибки можно далеко не всегда, попытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т.п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проектом начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным их исполнением. Тот, кто не умеет организовать работу, обречен бороться за дисциплину. И здесь возникает проблема несовместимости дисциплины и творчества. Чем строже дисциплина, тем менее творческой становится атмосфера в коллективе. Такое положение вещей может привести к тому, что наиболее одаренные кадры со временем покинут коллектив.

Модель итеративной и инкрементальной разработки

Альтернативой каскадной модели является модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение – инкремент – к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция – прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определенный успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, – обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ все же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «все равно все можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

Итак, итеративные или инкрементальные модели предполагают разбиение создаваемой системы на набор кусков, которые разрабатываются с помощью нескольких последовательных проходов всех работ или их части.

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

Рис. Возможный ход работ по итеративной модели

Каскадная модель с возможностью возвращения на предшествующий шаг при необходимости пересмотреть его результаты, становится итеративной.

Итеративный процесс предполагает, что разные виды деятельности не привязаны намертво к определенным этапам разработки, а выполняются по мере необходимости, иногда повторяются, до тех пор, пока не будет получен нужный результат.

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

Спиральная модель

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

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

Спиральная модель основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

Название «спиральная» эта модель получила из-за изображения хода работ в «полярных координатах», в которых угол соответствует выполняемому этапу в рамках общей структуры итераций, а удаление от начала координат – затраченным ресурсам.

Рис. Изображение хода работ по спиральной модели согласно Боему

Рисунок изображает вариант классической спиральной модели Боэма, ориентированный на работы процесса разработки, соответствующие СТБ ИСО/МЭК 12207-2003.

Рисунок показывает возможное развитие проекта по спиральной модели. Количество витков, а также расположение и набор видов деятельности в правом нижнем квадранте могут изменяться в зависимости от результатов планирования и анализа рисков, проводимых на предыдущих этапах.

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

1. Постановка задач (Objective setting) – определяются цели этой фазы, то есть витка, ограничения процесса, результаты, план управления, потенциальные риски и альтернативные стратегии, исходя из рисков.

2. Оценивание и сокращение рисков (Risk assessment and reduction) – для каждого найденного риска делается анализ, предпринимаются некоторые действия для сокращения рисков (например, риск, чьи требования не являются адекватными: изготавливается прототип).

3. Разработка и проверка достоверности (Development and validation) – выбирается модель разработки, исходящая из оцененных рисков (модель должна быть такой, чтобы помочь снизить риски). Например, если в пользовательском интерфейсе имеется самый большой риск, то тогда может помочь прототипирование.

4. Планирования (Planning) – проект рассматривается и делается решение о том, переходить ли на следующий виток, если решают продолжить, делается план для следующей фазы.

Итак, модель поделена на четыре квадранта. В каждый квадрант модели входят основные и вспомогательные действия по разработке продукта или системы.

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

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

Определяются риски, связанные с недостатком опыта в данной предметной области, применением новой технологии, жесткими графиками, недостаточно хорошо организованными процессами.

В квадранте 2 – оценка альтернативных вариантов, идентификация и разрешение рисков – выполняется оценка альтернативных вариантов, рассмотренных в предыдущем квадранте; оценка возможных вариантов разрешения рисков. Выполняется прототипирование как основа для работ следующего квадранта.

В квадрант 3 – разработка продукта текущего уровня – включаются действия по непосредственной разработке системы или программного продукта: проектирование системы и ее программных компонентов, разработка и тестирование исходных текстов программ, интеграция тестирование и квалификационные испытания продукта или системы и т.п.

В квадранте 4 – планирование следующей фазы – выполняются действия, связанные с разработкой планов проекта, управления конфигурацией, тестирования, установки системы.

Наиболее важным отличием этой модели от других является учет рисков. Риск – это вероятность того, что что-то может пойти не так. Из-за материализации рисков превышаются сроки, и происходит перерасход средств, поэтому необходимо учитывать риски и принимать меры по их смягчению.

Боэм формулирует десять наиболее распространенных (по приоритетам) рисков:

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача – как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

• небольшую команду программистов (от 2 до 10 человек)
• короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев)
• повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:

• фаза определения требований и анализа
• фаза проектирования
• фаза реализации
• фаза внедрения.

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.

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

Для каждого цикла модели анализируются требования, альтернативные варианты и ограничения, определяются и разрешаются риски, разрабатывается версия продукта или системы этого цикла спирали и подтверждается ее правильность; планируется следующий цикл и выбираются методы его осуществления.

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

Количество итераций модели выбирается в соответствии со сложностью проекта. Работы каждой итерации должны бать адаптированы под конкретный проект.

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

Итерации. Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой.

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

Рис. Спиральная модель жизненного цикла информационной системы.

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

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

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

При использовании спиральной модели при выполнении соответствующего ей проекта проявляются следующие ее преимущества:

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

Рассмотрим преимущества итерационного подхода более подробно:

• Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
• При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40 % всех затрат в конце проекта).
• Уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый уровень рисков снижается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели снижение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации, и на начальных итерациях выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т.п.
• Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет снижения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным в условиях конкурентной борьбы, когда необходимо противостоять продвижению изделия, предлагаемого конкурентами.
• Итерационный подход упрощает повторное использование компонентов (реализует компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться.
• Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы.
• Итерационный подход дает возможность совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.

Недостатки спиральной модели. При использовании спиральной модели применительно к неподходящему ей проекту, проявляются следующие ее недостатки:

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

Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться в бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее – враг хорошего». Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена.

Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Область применения спиральной модели. Применение спиральной модели целесообразно в следующих случаях:

• при разработке проектов в организации, обладающей навыками, требуемыми для адаптации модели;
• при разработке проектов, связанных со средней и высокой степенью риска;
• при разработке проектов, использующих новые технологии;
• при разработке проектов, в которых необходимо протестировать базовые концепции;
• при разработке больших проектов;
• при разработке проектов со слишком сложными требованиями;
• при разработке новой серии продуктов или систем;
• при разработке проектов в случае, если пользователь не уверен в своих потребностях;
• при разработке проектов с ожидаемыми существенными изменениями или дополнениями требований;
• при разработке проектов в условиях отсутствия возможности заблаговременного выделения всех необходимых для выполнения проекта денежных средств,
• для выполнения долгосрочных проектов;
• при разработке проектов, в которых необходима демонстрация качества и версий системы или продукта через короткий период времени;
• при разработке систем, требующих большого объема вычислений;
• при выполнении бизнес-проектов, проектов в области аэрокосмической промышленности, обороны и инжиниринга;
• при разработке проектов, для которых необходим подсчет затрат, связанных с оценкой и разрешением рисков.

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

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

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

Проекты, над которыми я работаю, чаще всего связаны с разработкой заказного или инвестиционного программного обеспечения. Также мне приходилось работать с встроенным ПО и программами, ориентированными на выпуск «хитов» (что, с лёгкой руки Джоэля Спольски, я называю далее игровым ПО, хотя на самом деле некоторые игровые проекты ближе к инвестиционным).

Заказное программное обеспечение может быть предназначено для внутреннего или внешнего заказчика. Эксклюзивные права на разработанную систему получает заказчик, и работа над развитием системы в дальнейшем может быть передана другому исполнителю.

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

Встроенное программное обеспечение поставляется вместе с аппаратной частью и, грубо говоря, не подлежит сопровождению, поскольку отзыв партии устройств производителем – дело очень затратное и потому исключительное.

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .

В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.

Наш процесс представляет собой последовательность определённых этапов. Приведённая мной классификация ПО сделана только, чтобы показать возможную разницу в организации разработки различных программных средств. Делая обзор процесса разработки, я остановлюсь только на различиях именно самого процесса касаемо разных видов ПО. Однако надо помнить, что различия между процессами разработки разных видов ПО гораздо глубже, поэтому при планировании каждого этапа необходимо учитывать эти нюансы.

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

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

Не нужно тратить время и ресурсы на проект, чья концепция признаётся невостребованной или нереализуемой. Такой проект должен быть завершён. В ряде случаев требуется некоторая итеративная работа с заказчиком по коррекции концепции проекта, пока либо не будет достигнут приемлемый баланс требований заказчика и затрат исполнителя, либо не будет принято решение о сворачивании работ.

Проект, концепция которого выглядит приемлемой для реализации, выходит на этап разработки требований. На этом этапе исполнитель должен сформировать перечень всех явных и скрытых потребностей заказчика. Часто оказывается, что заказчик либо не определился со своими потребностями, либо его потребности вступают в противоречие между собой, с возможностями заказчика или с возможностями исполнителя. Целями этапа являются выявление всех скрытых потребностей, решение конфликтов требований, формирование целостного технического решения и анализ реализуемости подготовленного решения.

Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.

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

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

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

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

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

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

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

Процесс разработки инвестиционного ПО

Процесс разработки инвестиционного ПО отличается тем, что параллельно может идти работа сразу над несколькими версиями продукта: пока первая версия сопровождается, вторая уже реализуется, а для третьей формулируются требования. Процесс показан на рисунке 2.

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

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

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

В принципе, можно перенести начало работ над следующей версией на более поздний срок. Например, вполне допустимо сначала ввести текущую версию в опытную или даже промышленную эксплуатацию, и только после этого начать работу над следующей версией. Но нужно помнить, что такое решение неприменимо в случае высокой конкуренции: вас просто опередят и выдавят с рынка. Решение нужно принимать, исходя из всего комплекса обстоятельств, влияющих на ваш бизнес.

Говоря о процессе разработки инвестиционного ПО, нужно понимать, что работа над несколькими версиями имеет ряд явных и скрытых взаимозависимостей между параллельными ветками процесса.

Во-первых, исправления несоответствий, выявленных в ранней версии, должны вноситься и в версию, где они были обнаружены, и во все более поздние версии, включая разрабатываемые. Это касается не только кода программы, но и всех остальных артефактов проекта: технической и пользовательской документации, справочной системы, оценок и планов работ и т.п. Причём исправления должны вноситься немедленно, поскольку уменьшить стоимость исправлений вам не удастся, но, если не внести исправления сразу, их стоимость на более поздних стадиях может увеличиться в десятки и даже сотни раз.

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

Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.

В-третьих, в работе над несколькими версиями могут быть одновременно задействованы одни и те же участники. Имеется большой риск, что ключевой сотрудник может погрязнуть в работе над одной версией программы и допустить существенное превышение сроков по задачам, связанным с другой версией.

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

Процесс разработки встроенного ПО

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

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

Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.

Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

Поставка игрового программного обеспечения происходит в рамках одного единственного этапа. Даже если сначала создаётся некое ядро, «движок» игровой системы, его работу невозможно проверить без реализации всего функционала системы.

Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.

Заключение

В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.

Отмечу, что рассматриваемая здесь схема процесса является результатом обобщения моего личного опыта разработки различных программных средств. Как любое обобщение, моя схема является абстракцией. И, как любая абстракция, у неё есть свои границы применимости. Нельзя бездумно применять эту схему к конкретному проекту. Важно понимать, что каждый проект имеет свои нюансы, влияющие на организацию процесса разработки. И поэтому для каждого проекта приведённую здесь схему нужно адаптировать, а в ряде случаев потребуется разработать принципиально другой подход.

Эта методология проектирования соединяет в себе объектную декомпозицию, приемы представления физической, логической, а также динамической и статической моделей системы.

Типовой проект включает в себя следующие этапы разработки программного обеспечения :

• анализ требований к проекту;
• проектирование;
• реализация;
• тестирование продукта;
• внедрение и поддержка.

Анализ требований к проекту

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

В рамках данного этапа не только фиксируются требования заказчика, но и проводится их формирование - клиентам подбирается оптимальное решение их проблем, определяется необходимая степень автоматизации, выявляются наиболее актуальные для автоматизации бизнес-процессы.

При анализе требований определяются сроки и стоимость разработки ПО, формируется и подписывается ТЗ на разработку программного обеспечения.

Проектирование

На основе предыдущего этапа проводится проектирование системы. Эта методология проектирования соединяет в себе объектную декомпозицию, приемы представления физической, логической, а также динамической и статической моделей системы.

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

Реализация

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

Тестирование продукта

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

• установка системы,
• обучение пользователей,
• эксплуатация.

К любой разработке прилагается полный пакет документации, который включает в себя описание системы, руководства пользователей и алгоритмы работы.

Поддержка функционирования ПО должна осуществляться группой технической поддержки разработчика.

Материал не является исчерпывающим и предоставлен лишь для ознакомления с основными проблемами, существующими в данной сфере. Для получения подробной информации о сотрудничестве обратитесь к нашим менеджерам или звоните по нижеуказанному номеру.