Программный продукт

Что такое программный продукт

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

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

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

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

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

Жизненный цикл программного продукта

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

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

1. Разработка.

2. Использование.

3. Продолжение разработки.

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

Очень часто случается так: когда фирма берется за разработку нового продукта, конкурентов не видно, но где-то в середине пути они появляются. К моменту выхода программа вместо вертикального рынка может оказаться на горизонтальном! Так случилось, например, с продуктом FaxLine фирмы INZER. Осознавая это, фирма-разработчик старается сокращать сроки разработки, чтобы застолбить нишу на рынке. Часто это сказывается на параметрах продукта...

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

Откуда берутся идеи и какие из них выживают

Во многих западных компаниях принято устраивать "мозговые атаки". Часто идеи просто "витают в воздухе", классический пример: создание первой электронной таблицы Деном Бриклиным.

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

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

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

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

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

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

Производство софта - рискованная игра

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

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

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

Разработка программных продуктов

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

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

Гарри Килдал, создатель операционной системы CP/M, например, заявляет: "В программировании есть что-то от искусства Большую часть процесса программирования занимают изобретательство и проектирование. Если же посмотреть на работу группы программистов, то их общение и взаимодействие напомнит вам некое религиозное действо. Они образуют тесное сообщество, придерживаются определенных верований и следуют определенным правилам. И нередко почти боготворят язык, на котором пишут свои программы."

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

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

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

Написание команд -- программы Компоновка Тестирование Документирование

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

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

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

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

Определение требований

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

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

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

Изменения неизбежны

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

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

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

И вдруг мы обнаруживаем, что наш заказчик крайне расстроен тем обстоятельством, что нам пришлось выйти из бюджета! Мы терпеливо объясняли ему, что наш перерасход в 3 млн. долларов сэкономил ему несколько лет труда. Кроме того, мы спасли его от необходимости запускать новый спут-ник, что обошлось бы ему в 50 млн. Нас оправдали, но не-охотно!

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

Определение требований для систем типов I и II -- доста-точно простой процесс, практически всегда он бывает сделан достаточно хорошо. Этого нельзя сказать о больших системах типов III, IV и V. Новизна вычислительной техники комби-нируется с трудностью определения требований для больших систем, которые прежде никогда не строились. Люди никогда раньше не применяли автоматизированные системы в этих областях, поэтому они не сразу могут понять все возможно-сти этих новых для них систем.

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

В действительности лучше было бы задать такой вопрос: «Что же не будет меняться?».

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

О том, как этого добиться, мы поговорим в разделе кни-ги, посвященном проектированию программ.

Кто формулирует требования к программному обеспечению?

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

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

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

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

Предварительный проект

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

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

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

Говоря о структурном анализе и проектировании, нельзя хотя бы не упомянуть о SADT - Structured Analysis & Design Technique (методология структурного анализа и проектирования). SADT - это подход к описанию систем и специальный графический язык, изобретенный для этой цели, которые более 20 лет назад ввел Дугласс Т. Росс (Douglas T. Ross). Впоследствии Министерство обороны США стандартизировало и опубликовало часть этой методологии, касающуюся описания функциональной структуры систем, как IDEF0, а также разработало специальный графический язык для описания структуры данных - IDEF1 и язык описания параллельных процессов (описания динамической структуры систем) - IDEF2. С тех пор технология IDEF применяется тысячами специалистов во всем мире. Причем универсальность оказалась столь велика, что сейчас IDEF используется для разработки и описания систем не только в технике, но и в экономике, управлении и даже техническом писательстве и многих других областях.

О разделении труда

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

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

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

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

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

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

Кодирование - это нетривиально

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

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

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

Внутрифирменное тестирование

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

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

Планирование и руководство разработкой

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

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

1. Эйфория.

2. Разочарование.

3. Поиск виновных.

4. Наказание невиновных.

5. Награждение непричастных к делу."

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

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

Отбор и обучение кадров. Общение в среде программистов

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

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

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

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

Библиография

1. Котлер Ф. Основы маркетинга. - М.: Прогресс, 1992.

2. Марка Д., МакГоуен К. Методология структурного анализа и проектирования. МетаТехнология. - М.: 1993.

3. Фокс Дж. Программное обеспечение и его разработка. М.: Мир, 1985.

4. Внутренняя документация фирмы BIT Software.

5. Lammers S. Programmers at work. - Microsoft Press, 1989.