Марка HR Близнецов

Методы разработки в проектах программного обеспечения см. в разделе Методология разработки программного обеспечения .

Метод СДМ2.

Cap Gemini SDM , или SDM2 (методология разработки систем) — это метод разработки программного обеспечения , разработанный компанией-разработчиком программного обеспечения Pandata в Нидерландах в 1970 году. Этот метод представляет собой водопадную модель, разделенную на семь этапов, которые имеют четкое начало и конец. На каждом этапе создаются субпродукты, называемые вехами. Он широко использовался в Нидерландах для ИКТ. проекты 1980-х и 1990-х годов. Pandata была приобретена группой Capgemini в 1980-х годах, а последней версией SDM, опубликованной на английском языке, была SDM2 (6-е издание) в 1991 году компанией Cap Gemini Publishing BV. Метод регулярно обучался и распространялся среди консультантов и клиентов Capgemini, пока каскадный метод медленно не вышел из моды вслед за более итеративными экстремальными методами программирования, такими как быстрая разработка приложений , Rational Unified Process и гибкая разработка программного обеспечения .

Cap

В начале и середине 1970-х годов различные общие рабочие этапы методологий разработки систем были заменены рабочими этапами, основанными на различных методах структурированного анализа или структурированного проектирования. SDM, SDM2, SDM/70 и Spectrum превратились в методологии разработки систем, основанные на работах Стивена Уорда, Тома Демарко, Ларри Константина , Кена Орра , Эда Юрдона , Майкла А. Джексона и других, а также методов моделирования данных. разработан Томасом Бахманном и Питером Ченом . SDM — это нисходящая модель. Начиная с системы в целом, ее описание становится более детальным по мере разработки. Этот метод позиционировался как запатентованный метод, который должны были использовать все разработчики компании для обеспечения качества проектов клиентов. Этот метод имеет некоторое сходство с запатентованными методами наиболее важных конкурентов CAP Gemini в 1990 году. Аналогичным каскадным методом, который позже был использован против самой компании в судебных разбирательствах в 2002 году, был CMG:Commander.

История

SDM был разработан в 1970 году компанией, известной как PANDATA, ныне являющейся частью Cap Gemini , которая сама была создана как совместное предприятие трёх голландских компаний: AKZO , Nationale Nederlanden и Posterijen, Telegrafie en Telefonie (Nederland) . Компания была основана с целью развития метода и создания обучающих материалов для его распространения. Он имел успех, но был пересмотрен в 1987 году, чтобы стандартизировать и отделить теорию метода от более технических аспектов, используемых для реализации метода. Эти аспекты были включены в инструмент моделирования процессов под названием «Software Development Workbench», который позже был продан в 2000 году другой голландской компании BWise. Эта пересмотренная версия метода без инструмента широко известна как SDM2 .

Основное различие между SDM и SDM2

Круг Деминга , который с 1980-х годов составляет основу любого процесса управления программными проектами.

Цикл быстрой разработки прикладного программного обеспечения «Планируй-Делай-Проверяй-Действуй», демонстрирующий начало спиралевидного метода.

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

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

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

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

Метод SDM

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

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

Фазы

В методе используются 7 этапов, которые выполняются последовательно, как и в каскадной модели. Фазы:

1. Информационное планирование: определение проблемы и первоначальный план
2. Исследование определения: анализ требований и пересмотренный план
3. Базовый проект: технический проект высокого уровня и пересмотренный план.
4. Детальный проект: построение системы (и пересмотренный план)
5. Реализация: тестирование и приемка (и пересмотренный план)
6. Внедрение: установка, преобразование данных и запуск в производство.
7. Эксплуатация и поддержка: Доставка в отдел поддержки ИКТ.

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

Информационное планирование

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

Исследование определений

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

• Целесообразность — доступны ли ресурсы (время и знания) для завершения проекта.
• Значение. Необходимо ли заменять существующую систему?
• Техника. Может ли имеющееся оборудование соответствовать требованиям, предъявляемым к нему системой?
• Экономика — Затраты на разработку системы ниже прибыли, полученной от ее использования?
• Организация. Сможет ли организация использовать новую систему?
• Юридические вопросы. Противоречит ли новая система существующим законам?

Базовый проект

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

SDM2 разделил этот шаг на две части: одну для фазы BD и одну для фазы DD, чтобы создать документ глобального проектирования.

Детальный проект

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

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

Реализация

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

Реализация

Фаза внедрения или тестирования состоит из двух этапов: испытания системы и приемочного испытания.

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

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

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

Эксплуатация и поддержка

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

Внешние ссылки

• Методология разработки программного обеспечения
• Контрольный список мероприятий SDM (на голландском языке)
• Запись в книге SDM Ассоциации вычислительной техники