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

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

Этап планирования

На этой стадии нужно максимально снизить неопределенность.

Фаза планирования – наиболее критичный этап в создании успешной системы. Во время нее вы точно решаете, что хотите сделать и какие проблемы решить. Для этого вам необходимо:

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

• рассмотреть варианты альтернативных решений на встречах с клиентами, поставщиками, консультантами и сотрудниками;

• понять, как сделать ваш продукт лучше, чем у конкурентов;

• провести анализ осуществимости (feasibility study), направленный на изучение возможности создания продукта в соответствии с заданными требованиями заказчика и выделенными ресурсами.

Ведущую роль в разработке концепции играет бизнес-аналитик (или Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка в течение всего срока разработки концепции проводится интенсивная работа с инвестором проекта, чтобы выработать единое ви´дение будущего продукта. Если это заказной продукт, то инвестор – конечный заказчик. Если продукт предназначен для открытого рынка, то ответственны за него учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создает образ будущего продукта. В конце аналитик и экспертная команда определяют границы проекта, которые должны содержать ориентировочные сроки реализации и бюджет продукта.

Результатом разработки концепции является Product Vision Document (если продукт разрабатывается под заказ) или Marketing Requirement Document (если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различие между PVD и MRD состоит в том, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов.

После разработки концепции продукта делается вывод о целесообразности создания продукта. Если принято положительное решение, пишется устав проекта по разработке продукта. PVD/MRD – входной документ устава проекта, описывающий содержание работ.

Входы: идея, концепция, экономическое обоснование.

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

Этап анализа требований

На этом этапе нужно четко определить и задокументировать требования к продукту и утвердить их.

Входы: реестр заинтересованных лиц, дорожная карта.

Выходы: техническое задание.

Этап проектирования

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

Входы: техническое задание.

Выходы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Этап разработки

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

Входы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Выходы: работающая версия ПО, готовая к тестам.

Этап тестирования

На этом этапе проверяется работоспособность системы.

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

Входы: тест-кейсы, версия ПО.

Выходы: отчет о тестировании, баг-репорты.

Этап внедрения и поддержки

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

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

Входы:

• консультирование пользователей;

• исправление дефектов;

• доработка в соответствии с новыми требованиями.

Выходы:

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

• пользовательская документация.

Стандарты жизненного цикла ПО

ГОСТ Р ИСО/МЭК 12207–2010

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

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

➤ Процессы соглашения

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

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

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

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

• процесс менеджмента модели жизненного цикла;

• процесс менеджмента инфраструктуры;

• процесс менеджмента портфеля проектов;

• процесс менеджмента людских ресурсов;

• процесс менеджмента качества.

➤ Процессы проекта

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

Существуют две категории процессов проекта.

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

• Процессы поддержки проекта обеспечивают выполнение специализированных целей менеджмента.

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

• планирование проекта;

• управление проектом и его оценка.

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

• менеджмент решений;

• менеджмент рисков;

• менеджмент конфигурации;

• менеджмент информации;

• измерения.

➤ Технические процессы

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

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

Технические процессы:

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

• анализ системных требований;

• проектирование архитектуры системы;

• реализация;

• комплексирование системы;

• квалификационное тестирование системы;

• инсталляция программных средств;

• поддержка приемки программных средств;

• функционирование программных средств;

• сопровождение программных средств;

• изъятие программных средств из обращения.

➤ Процессы реализации программных средств

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

➤ Процессы поддержки программных средств

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

➤ Процессы повторного применения программных средств