ПРОЕКТИРОВАНИЕ ПО ИС

- количеству формализованных процессов (большинство процессов или только основные) и

детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

ПО. Самая распространенная до недавнего времени методология «Как получится». Ее

основные характеристики:
∙ Разомкнутая система управления
∙ Полное доверие техническим лидерам
∙ Представители бизнеса практически не участвует в проекте
∙ Планирование, если оно и есть, то неформальное и словесное
∙ Время и бюджет, как правило, не контролируются
∙ Аналогия: полет ракеты без обратной связи. Можно, но недалеко и неточно
Это не означает, что процесса как такового нет. Он есть и, как правило, обеспечивает разработку ПО при приемлемых затратах и качестве, но этот процесс не документирован, является «знанием стаи», держится на людях и передается из поколения в поколение. Целенаправленная работа по оценке эффективности и улучшению процесса не ведется.

на разработку и сопровождение автоматизированных систем» ориентированы на последовательный подход

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

на проект
Разработка эскизного проекта системы
Разработка технического проекта системы
Разработка и оформление

документации на поставку изделий для комплектования системы
Разработка технической документации на систему и её частей
Ввод разработанной системы в действие: подготовка объекта и персонала, комплектация системы, монтажные работы, пуско-наладочные работы, опытная эксплуатация, приёмочные испытания
Сопровождение системы (гарантийное и постгарантийное)

Комплекс стандарта ГОСТ 34 – этапы и стадии разработки ИС

минувшего столетия Министерство обороны США задумалось о том, как выбирать

разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения. Данная модель определяет пять уровней зрелости процесса разработки ПО:
Начальный — процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей
Повторяемый — установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах.

ПО и управления проектами описаны и внедрены в единую систему

процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект
Управляемый — собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных
Оптимизируемый — постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий
Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться на 5-ый уровень зрелости.

описания уровней зрелости

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

результаты основных этапов проекта.

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

Определенные производственные процессы количественно контролируются. Производится объективная количественная оценка для принятия решений.

SW-СММ. Представление руководства о производственном процессе

Неэффективные и приводящие к дефектам операции выявляются, заменяются и пересматриваются.
SW-СММ.

Представление руководства о производственном процессе

созданная компанией Rational Software.
Принципы:
Ранняя идентификация и непрерывное (до окончания проекта)

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

которого проектная команда должна создать специализированный процесс, ориентированный на ее

потребности.
В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline).
Такой подход в RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

дисциплины:
Бизнес-моделирование (Business Modeling) – определение и описание бизнес-целей, моделирование сущностей

предметной области (сущности и их атрибуты, структура связей, взаимодействие внешних и внутренних сущностей), моделирование функциональных обязанностей бизнес-актеров, анализ и моделирование существующих бизнес-процессов заказчика, а также поиск их возможных улучшений
Разработка и Управление требованиями (Requirements Engineering & Requirements Management) – выявление требований, определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком
Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта

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

моделирование их взаимодействия и структуры связей, моделирование классов бизнес-логики, их иерархий и структуры связей (платформонезависимая модель PIM)
Проектирование (Design) – создание и моделирование платформозависимой архитектуры программной системы (модель PSM).
Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы
Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей

– управление версиями исходного кода и документации, процесс обработки запросов

на изменение (change requests)
Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки

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

всего проекта, но с разной функ-циональной интен-сивностью .

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

и пошаговый процесс разработки. Разработка разбивается на ряд этапов, каждый

из которых состоит из одной или нескольких итераций. Определено четыре основных этапа:
Начало (Inception)
Формируются представление (vision) и границы проекта. Создается экономическое обоснование (business case)
Определяются основные требования, ограничения и ключевая функциональность продукта
Создается базовая версия модели прецедентов
Оцениваются риски.
При завершении начальной стадии оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

предметной области и построение исполняемой архитектуры. Это включает в себя:
Документирование требований

(включая детальное описание для большинства прецедентов)
Спроектированную, реализованную и оттестированную исполняемую архитектуру
Обновленное экономическое обоснование и более точные оценки сроков и стоимости
Сниженные основные риски
Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).
Цели считаются достигнутыми, когда снижены риски и получены большие уверенности в реализуемости остальных планов.

реализация большей части функциональности продукта. Фаза «Построение» завершается первым внешним

релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
Во время фазы «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе «Начало», фаза «Внедрение» повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

годов, когда инженеры и руководители проектов уже располагали всем необходимым

для быстрой и гибкой разработки, возникло совершенно новое течение, в каком-то смысле даже религия, в методиках разработки — «agile». Термин «agile» является зонтичным для целого набора методик.

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

практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Идеология гибкой методологии определяется Agile Manifesto. Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий: Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming.
Agile Manifesto содержит :
4 основные идеи
12 принципов.

экстремального программирования. Автор нескольких книг на эти темы и соавтор

JUnit.
Майк Бидл – основатель и генеральный директор e-Architects Inc., консалтинговой компании, которая специализируется на разработке распределенного ПО. Он также является соавтором книги «Scrum, Agile Software Development», написанной совместно с Кеном Швабером.
Эйри ван Беннекум участвовал в разработке методологии DSDM с 1997 года. А до этого активно работал над быстрой разработкой (Rapid Application Development).
Алистер Кокбёрн известен исследованиями проектных команд и активным участием в разработке семейства методологий Crystal.
Уорд Каннингем – основатель Cunningham & Cunningham, Inc. Он также широко известен за громадный вклад в развитие объектно-ориентированного программирования, экстремального программирования и концепцию вики.
Джеймс Греннинг – тренер и консультант по гибким методологиям. Является специалистом в области разработки и тестирования встроенного программного обеспечения и автором книги «Test Driven Development for Embedded C».

обеспечение, соавтор метода ООАП Шлаера-Меллора, работал над UML в составе

Object Management Group.
Мартин Фаулер – главный исследователь в компании Thoughtworks. Автор многих работ и книг по паттернам анализа, UML, рефакторингу и XP.
Джим Хайсмит – ведущий разработчик методологии «Adaptive Software Development» и автор соответствующей книги.
Эндрю Хант – соавтор книги «Pragmatic Programmer: From Journeyman to Master» и других работ, связанных с разработкой ПО.
Рон Джеффрис – владелец сайта XProgramming.com, консультант в компании Object Mentor и соавтор книги «Extreme Programming Installed».
Джон Кёрн участвовал во многих проектах по исследованиям и разработки в области авиастроения. Также он является евангелистом ООП с начала 90-х годов.
Брайан Мэрик – программист и консультант по тестированию программного обеспечения. Основной вклад Брайана заключается в исследование процессов тестирования ПО в гибких методологиях разработки.

1970 года. Он является президентом и основателем фирмы Object Mentor

Inc., которая специализируется на консалтинге в области экстремального программирования, гибких методологиях разработки, консалтинге по архитектуре ПО и так далее. Он также является соавтором ряда книг по программированию и разработке ПО.
Кен Швабер – президент компании Advanced Development Methods (ADM), которая занимается улучшением методов разработки ПО. Он является опытным разработчиком, менеджером продуктов и консультантом. В начале 90-х годов он работал с Джеффом Сазерлендом над первыми версиями Scrum. Он также является соавтором книги «Scrum, Agile Software Development».
Джефф Сазерленд – технический директор (CTO) компании PatientKeeper, которая занимается создание ПО для медицинских учреждений. За свою карьеру был техническим директором (или вице-президентом по технологиям) в девяти компаниях. Свою известность приобрел, как изобретатель методологии Скрам.
Дейв Томас верит, что сердцем разработки ПО является не методология, а люди. По этой причине он является соавтором книги «The Pragmatic Programmer».

в конце каждой итерации законченный продукт – функционирующий программный код

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

owner в состоянии предоставить пользовательские требования в форме пригодной для

написания кода
ДА, если требования достаточно конкретизированы и проработаны
ДА, если эксперт в предметной области и бизнеса (product owner) ежедневно доступен для общения
ДА, если объёмы итераций соответствуют производительности команды

гибких методологий разработки программного обеспечения.
Авторы методологии — Кент Бек,

Уорд Каннингем, Мартин Фаулер и другие.
Двенадцать основных приёмов экстремального программирования:
I. Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
II. Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)

metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования

(Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
IV. Социальная защищенность программиста (Programmer welfare)
40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Основа XP — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели.
Область применимости ХР — небольшие и средние проекты.
Основная идея ХР — в XP все принципы, продиктованные здравым смыслом, достигают «экстремальных значений».

а не недели, месяцы или годы
Короткие
итерации
Непрерывная интеграция
Интегрируется и

тестируется несколько
раз в день

Тестирование
интеграции

Вся разработка проводится
на основе простой,
общедоступной истории о том,
как работает вся система

Каждый постоянно работает над
уточнением архитектуры

Архитектура

Самая простая вещь, которая
могла бы работать

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

Простота

Реорганизация (refactoring)

Проектирование является частью
ежедневной деятельности каждого
разработчика

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

Тестирование модуля,
функциональное тестирование

Тестирование выполняется все время,
даже с помощью заказчиков

Тестирование

Парное программирование

Код проверяется все время

Проверки кода

ХР-реализация

ХР-экстремум

Практика
здравого смысла

В XP все принципы, продиктованные здравым смыслом, достигают «экстремальных значений»

Экстремальное программирование (XP)

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

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

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

в инструмент для создания спецификации и архитектуры. Для этого этап

написания тестов переноситься в начала цикла разработки:

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

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

котором сложно допустить ошибки. Нужен минимум тестирования.
Алгоритмы – это код,

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

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

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

гибкость архитектуры и так далее).

XP — это не тот, кто оплачивает счета, а конечный пользователь

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

Игра в планирование (Planning game)

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

двумя разработчиками за одним компьютером, причем один из разработчиков играет

роль «пилота», а второй роль «штурмана»:

поступать в эксплуатацию как можно чаще. Работа над каждой версией

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

итеративно, важно иметь максимально простую архитектуру, в которую будет возможно

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

(Coding standard or Coding conventions) или выбранными шаблонами проектирования (Collective

patterns ownership)

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

40-часовая рабочая неделя (Sustainable pace, Forty hour week)

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