Технология разработки ПО

[alibek]

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

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

Поскольку на форуме (и тем более в данном блоге) я появляюсь редко, тему я сделаю закрытой, чтобы ее не засоряли боты. Продолжения будут выкладываться прямо в данном топике (во всяком случае буду надеятся, что данную тему не постигнет судьба начинаний «[NET] *», остановившихся на третьем дне).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Продолжение следует.

[alibek]

Продолжу.

Существует несколько различных схем разработки программного обеспечения и производства программного продукта.
Их можно поделить на две большие группы, каскадные и итеративная.
В каскадной модели процесс разработки переходит из одной фазы в другую; например, анализ требований и сбор исходных данных > проектирование > разработка > тестирование > выпуск продукта. Такая модель может быть применена для относительно простых проектов и небольшого коллектива.
Но более перспективной является итеративная модель, которая имеет две основные разновидности, спиральную и инкрементальную.
В первом случае последовательность фаз повторяется несколько раз; на первом проходе прорабатываются лишь наброски проекта, на каждом следующем проходе проект детализуется (похоже на прогрессивный JPEG).
Второй случай характерен при разработке программных продуктов, которые постоянно развиваются и выпуск новых версий производится с определенной периодичностью.
Однако следует понимать, что в чистом виде никакая схема не может быть применена в реальной задаче. Для успешной разработки продукта необходимо комбинировать разные подходы, выбирая их оптимальное сочетание. Скажем, в целом сложный проект может разрабатываться итеративно, однако отдельные простые модули разрабатываются отдельным человеком и процесс их разработки характерен для каскадной модели (анализ требований — проектирование/разработка — тестирование — выпуск).

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

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

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

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

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

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


Продолжение следует.