основные стадии жизненного цикла приложения включают
Разработка ПО и стадии жизненного цикла программного обеспечения
При этом важно отметить, что существует множество моделей жизненного цикла, например:
Любая модель регулирует лишь реализацию стадий жизненного цикла, но не сам жизненный цикл, который в принципе остается неизменным.
Жизненный цикл программного обеспечения
Итак, жизненный цикл программного обеспечения — это 6 основных стадий, через которые проходит любая разработка ПО:
Сбор и анализ требований к программному продукту.
Разработка документации для всех требований к продукту.
Разработка дизайна продукта.
Разработка программного обеспечения.
Прохождение различных тестов.
Ввод в эксплуатацию и поддержка ПО.
Сбор и анализ требований к программному продукту
Данная стадия является одной из самых основных, потому что именно она формирует дальнейший подход к разработке ПО. Все собранные на этой стадии сведения определяют:
каким должен получиться продукт «на выходе», отталкиваясь от его качества;
требования к разработчикам;
потенциальный бюджет разработки;
отношения между заказчиком и разработчиком;
В общем, данная стадия — это фундамент всех дальнейших работ.
Разработка документации для всех требований к продукту
Первую стадию прошли? Отлично! Но нужно все задокументировать, чтобы в дальнейшем не возникало не нужных проблем. Именно на этом этапе все требования к продукту и к команде разработчиков прописываются на бумаге и утверждаются с обеих сторон.
подписываются договор ы ;
прописывается план и график работ.
Разработка дизайна продукта
Под этой стадией понимают разработку внутренней архитектуры продукта, а не внешний дизайн. Важно, чтобы архитектура ПО способствовала реализации всего функционала, возложенного на сам программный продукт. Поэтому всегда предлагают несколько архитектурных вариантов, чтобы можно было выбрать лучший, который будет способен обеспечить эффективную связь со всеми подключаемыми дополнительными модулями.
На этом же этапе подбирается стек необходимых технологий и инструментов.
Разработка программного обеспечения
Требования прописаны, стек технологий выбран, что еще остается? Правильно, ко д инг! Это одна из самых «длинных» стадий жизненного цикла программного обеспечения, так как именно на этом этапе происходит реализация ПО при помощи кода.
Все фичи, модули, функционал, интерфейс и т. д. разрабатываются именно на этой стадии. Результатом конца это го этапа является готовый работающий программный продукт.
Эта стадия очень сильно отражает качество предыдущих стадий. Все ли было оговорено? Все ли задокументировано? Все ли идет четко по плану?
Именно на этом этапе могут возникать конфликты между заказчиком и разработчиком из-за:
дополнительно внедренных фич;
несоблюдени я сроков;
излишней требовательности заказчика;
Жизненный цикл разработки ПО: прохождение различных тестов
Если продукт дошел до этой стадии, то это уже успех. Однако это тоже очень важный этап, так как именно он отвечает за то, насколько качественной была разработка и насколько качественным «выйдет» программное обеспечение.
Тестирование бывает разных видов: от простого автоматизированного и до сложного ручного. Цель любого тестирования — найти возможные ошибки в программе, которые нужно исправить перед релизом ПО. Важно, чтобы продукт вышел «в руки» с минимальным количеством багов, поэтому тестированию уделяется очень много внимания.
Ввод в эксплуатацию и поддержка ПО
Если продукт разработан, прошел тестирование, если исправлены ошибки, то он выходит на последнюю стадию — релиз.
Релиз может быть разным:
поэтапным, когда ПО выпускают в ограниченный круг пользователей;
масштабным, когда ПО доступно для всех и активно рекламируется.
Довольны ли пользователи?
Требуются ли улучшения?
Обычно после релиза ПО в работу подключаются команды техподдержки, которые помогают пользователям с вопросами эксплуатации и следят за стабильной работы своего продукта.
Заключение
Жизненный цикл программного обеспечения одинаковый абсолютно для всех IT-проектов — от этого никуда не деться. Единственное — в зависимости от выбранных моделей разработки, больше или меньше внимания будет уделяться тем или иным стадиям самого цикла.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Что такое SDLC? Этапы, методология и процессы жизненного цикла программного обеспечения
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?
Ответить можно так: направить ваш рабочий процесс в верном направлении поможет подходящий фреймворк. В наши дни довольно сильным и популярным фреймворком является SDLC – жизненный цикл программного обеспечения.
Принципы работы SDLC и почему им пользуются
На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.
В целом, SDLC это такой замкнутый цикл, в котором каждый этап влияет на действия в последующих и дает перспективные указания на будущее. Для получения ответов на конкретные вопросы и обеспечения согласованности вашего процесса разработки все шесть этапов стараются эффективно и последовательно друг на друга влиять.
Я постараюсь абстрагироваться от тонкостей и предоставить общие примеры, подходящие для студентов и разработчиков ПО. Например, если вы по аналогии с Zoomshift пробуете создать приложение, рассчитанное на работников с почасовой оплатой, или приложение для учета времени, начать вам нужно будет с этапа анализа требований.
На этом самом основном уровне вы сможете понять каковы должны быть требования к работникам в вопросах учета времени и труда, для чего полезно будет опросить как самих работников, так и их руководящих менеджеров. Так же для большего понимания проблем текущих приложений в области вы можете протестировать ваши решения на рынке, а создание диаграмм, графиков и в целом ведение записей поможет вам более глубоко понимать количественную и качественную обратную связь. Только после осознания этих критических особенностей вы будете готовы перейти к следующему этапу SDLC – планированию.
Фаза анализа требований может оказаться очень утомительной, но проходя через эти шаги, вы добиваетесь множества результатов: снижаете время выхода продукта на рынок, обеспечиваете большую его производительность, экономите бюджет и повышаете вероятность вхождения продукта на рынок.
Мыслите за пределами обычного приложения по отслеживанию времени — думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.
Этапы SDLC и лучшие практики и методологии
В ходе разработки перед переходом от текущего этапа к следующему необходимо выполнить каждый его шаг, для чего их следует лучше понимать. В этом отношении первые три этапа стараются дать ответы на проверочные вопросы, а последние три оптимизированы для достижения фактических результатов.
Давайте детальнее рассмотрим каждый этап и разберем проверочные вопросы и результаты, некоторые из которых вы можете захотеть оптимизировать под вашу конкретную ситуацию.
Этап #1: Анализ требований
На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.
Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.
Этап #2: Планирование
На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.
Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.
Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.
Этап #3: Проектирование и дизайн
К этому этапу вы уже должны знать требования вашего продукта и в целом понимать чего вы вообще хотите, и прежде чем приступить к написанию кода, этого понимания должно быть достаточно для ответа на следующий вопрос: «Как мы добьемся наших целей?» Иначе говоря, вам необходимо понять, что именно вы оптимизируете и проектировать соответствующе.
Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.
После фазы дизайна вы наконец-то сможете засесть за клавиатуры, и внесение изменений в отношении времени и потраченных ресурсов будет неуклонно расти, а также буду постепенно накапливаться всевозможные малые факторы. В этой фазе для принятия окончательных решений по вопросам дизайна я рекомендую учитывать несколько основных его элементов: операционное превосходство, безопасность, надежность, эффективность производительности, и оптимизация затрат.
Этап #4: Разработка ПО
На этапе разработки вы стремитесь не столько отвечать на вопросы, сколько произвести результаты, или, говоря точнее, вам необходимо склоняться к действиям и создать прототип или систему, испытать которую смогут другие. На этом этапе ваша задача – заручиться доверием заинтересованных сторон через воплощение образа мышления разработчика. Для соответствия результата ожиданиям критично при начале разработки следовать первым трем этапам.
Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.
Этап #5: Тестирование
Сотрудники в футболках с надписями вида «Разрабатывать круто, тестировать не очень» были для меня привычным зрелищем, но вы должны понимать, что не получится создать финальную версию продукта, пока вы на нем собаку не съедите. По завершению этого этапа вы должны будете в состоянии обеспечить рабочее состояние продукта. Отслеживайте ошибки и неточности, выслушивайте чужие точки зрения, и глубоко погружайтесь в вопрос с целью поиска тормозящих выход финального продукта ошибок. Вам просто необходимо обеспечить прочную основу.
Этап #6: Развертывание
Возьмите ваш продукт и пользуйтесь им. Предложите заинтересованным сторонам из первого этапа пользоваться вашим продуктом в естественных условиях, начните отслеживать вовлеченность в продажи. Снова и снова прислушивайтесь к пользователям, ведь благодаря обратной связи через опросы и рекомендации вы сможете вернуться к первой фазе и начать собирать новые требования. И не забудьте отпраздновать релиз.
Объединяя все вместе: подход SDLC
Фреймворк SDLC существует для помощи в сокращении времени вывода продукта на рынок, обеспечении более качественной производительности, экономии бюджета и повышения потенциальной пользы вашего продукта для заинтересованных сторон, о которых вы заботитесь. Особенно хорошо SDLC помогает при разработке ПО, поскольку он заставляет вас трудиться в строгих рамках. Другими словами, для обеспечения корректных действий в корректное время и по корректным причинам SDLC заставит вас следовать каждому необходимому шагу. Думайте о SDLC как о плане по достижению успеха: слепое ему следование ничего вам не гарантирует, но повышает вероятность что вы останетесь довольны результатами.
Разработка ПО, как все мы с вами знаем, это тема обширная, и она может затрагивать вопросы от инструментов веб-дизайна и онлайн форм до более надежного машинного обучения или систем бэкенда. Пишете ли вы код в браузере или занимаетесь более надежной разработкой, план действий вам необходим.
Разработка ПО может быть трудным, и в то же время полезным занятием.
SDLC это план по ведению технических работ, но если смотреть шире, то можно воспринимать его как руководство по жизни. Применять SDLC можно к множеству тем, например, создание контента в SaaS модели ведется по циклу SDLC. Перед написанием контента автор сначала определяет требования, планирует, что именно он будет писать, и лишь затем фактически прикладывает перо к бумаге. Также SDLC отлично подходит для технологических предпринимателей.
Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: «Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?»
Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.
Затем он перешел к созданию самого лучшего сервиса по росту на Instagram, но его интересы постоянно развиваются, и сейчас уже есть программы-планировщики деятельности в социальных сетях в любом масштабе. И в итоге ему придется вернуться к основам: анализу требований.
Принятие пользователями его технологий доказывает, что при правильном применении SDLC можно достичь основательных технологических и финансовых результатов. Однако, как и при развитии бизнеса, разработка ПО никогда не заканчивается.
Следовательно, цикл продолжается.
Вне зависимости от того что вы создаете, компанию ли, инструмент, сложную программу либо полностью новый продукт, чтобы обеспечить качество и сосредоточиться на пользователях, хорошим решением будет взять на вооружение SDLC.
Фраза «Создавать круто» должна стать вашей путеводной звездой, а SDLC – инструментом и помощником.
Что включает в себя жизненный цикл проекта в IT
Разработка успешного продукта – сложный многоступенчатый процесс. Только в кино начинающие бизнесмены придумывают крутую идею, попивая кофе из Starbucks. По сюжету, они играючи находят инвестиции и выпускают приложение, которое захватывает мир. В реальности всё не так просто.
Создание и развитие любого продукта происходит постепенно, проходя ряд обязательных этапов, часть из которых может идти параллельно. Приложениям, которые вы любите, и на которые охотно тратите время, понадобился не один год, чтобы обрести текущий визуальный облик и наполнение. Едва ли их разработчики остановятся на достигнутом и перестанут добавлять улучшения.
Жизненный цикл проекта в IT – непрерывный процесс, который заканчивается, лишь когда его решают закрыть. Если вы придумали идею продукта и обратились к команде разработчиков, приготовьтесь, впереди много работы. О Силиконовой долине помечтаем позже. : )
Как разработчики, мы нередко сталкиваемся с непониманием фаз жизненного цикла продуктов.
Приходится опровергать представление о том, что после релиза проекта разработка завершена. По опыту знаем, что в первые месяцы жизни продукта может понадобиться допилить или переделать функционал, пофиксить баги.
Чтобы передать наше видение жизненного цикла разработки, мы поговорили с главными разработчиками Azoft и попросили поделиться представлениями об этом. Текст статьи будет полезен и для бизнеса, и для наших коллег.
Итак, что же входит в жизненный цикл продукта?
Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) – условная схема, включающая фазы создания программного обеспечения. Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. На выходе должен получиться экономически выгодный продукт, отвечающий требованиям заказчика.
В структуру цикла разработки входят все этапы жизни программного обеспечения от его рождения в виде идеи до условной “смерти” (этапы до разработки, во время разработки и после неё).
Погружение команды в бизнес-контекст – важная фаза цикла разработки программного обеспечения, с которой начинается рабочий процесс. Клиент должен понимать, что он тратит время и ресурсы на этом этапе не просто так. Ему важно, чтобы команда проекта погрузилась в детали бизнеса и тщательнее разобралась, для какого рынка готовится продукт, как сделать его по-настоящему полезным. Это актуально для любой отрасли.
Сбор и анализ требований – одна из наиболее важных фаз SDLC. Она выполняется при участии клиентов, отдела продаж и отдела аналитики. На этом этапе важно максимально точно и однозначно определить требования к проекту и для команды проекта, и для бизнеса. Аналитики помогают определить конечные цели и задачи работы. Подробнее об этом этапе вы можете прочитать в нашей статье.
Дизайн. К этому этапу переходят, когда есть четкое понимание целей проекта, и достаточно подробно сформулированы его требования. На основании требований обычно предлагается несколько подходов к проектированию архитектуры продукта. Внутренний дизайн всех модулей архитектуры должен быть четко определен и описан в деталях.
Реализация или кодирование. Это этап непосредственной разработки системы – написание кода на выбранном с учётом стоящих задач языке программирования.
Тестирование. Система запускается в бой. Этот этап сопровождается проверкой работоспособности системы, выявлением, фиксацией и исправлением багов до тех пор, пока продукт не достигнет требуемых стандартов качества. В этот период обычно возникает много несостыковок, белых пятен, багов. Их нужно оперативно устранить.
Внедрение. Когда продукт протестирован и готов к развертыванию, его выпускают на рынке. Иногда развертывание продукта происходит последовательно в рамках бизнес-стратегии клиента. Продукт может быть сначала выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, затем, основываясь на отзывах, он может быть выпущен как есть либо с предлагаемыми улучшениями.
Сопровождение. На этом этапе жизненного цикла осуществляется периодическая техническая поддержка системы. Это позволяет убедиться, что система не устарела и отвечает современным стандартам и технологиям. Сюда входит постоянная оценка производительности и апдейты компонентов.
Помимо основных указанных фаз, мы выделяем и фазу маркетингового продвижения. Маркетинговая деятельность является сквозной и проводится на протяжении всего жизненного цикла проекта. Клиенту важно создать осведомленность о продукте среди его целевой аудитории, привлечь потенциальных пользователей. Ни для кого не секрет, что клиентская база нарабатывается постепенно.
Все процессы разработки типовые, но подходы к работе бывают разные. И в зависимости от подхода определяется то, какой длины будут этапы, будут ли они делаться последовательно или итеративно, и как их будут выполнять.
Мы не раз сталкивались с тем, что клиенты, прежде всего, стартапы обращаются с предложением разработать продукт, но изначально не планируют его сопровождение. Они не закладывают время и бюджет на его развитие в ходе эксплуатации. В результате бизнес может столкнуться с ситуацией, когда все средства потрачены на разработку, а на поддержку или пиар проекта нет средств, как и договоренностей с командой о дополнительных работах.
Рады отметить, что сейчас такие ситуации возникают реже. Как правило, клиенты знают, что нужно предусматривать и обсуждать с деловыми партнерами будущее проекта. Они понимают, что жизнь продукта начинается с его идеи, а эксплуатация является важной частью жизненного цикла. Продукт – это всегда шире, чем разработка.
Не всегда верные представления о жизненном цикле ПО имеют и разработчики. Некоторые из них думают: ну что ж, я написал код, выложился по максимуму, а что с продуктом будет дальше, уже не должно меня беспокоить. На самом деле, программисты всегда должны быть готовы к постоянному взаимодействию с клиентами – к поддержке и сопровождению созданных решений.
У Azoft сложился опыт долговременного партнерства со многими крупными компаниями. Например, мы успешно осуществляем поддержку персонального кабинета для программы лояльности «Спасибо от Сбербанка».
Постоянное сотрудничество выгодно и нам, и клиентам Azoft. При таком подходе мы постоянно находимся в контексте проектов, над которыми работаем. Клиенту не нужно погружать в процессы сторонних разработчиков, тратить дополнительные усилия. Мы уверены, что крепкие партнерские отношения важны на всех фазах работы, а не только на старте, и всегда рекомендуем бизнесу сразу думать о том, кто будет поддерживать будущий проект.
8. Жизненный цикл программного обеспечения. Процессы жизненного цикла, связь между процессами. Основные, вспомогательные, организационные процессы, модели и стадии жизненного цикла. Взаимосвязь между стадиями и процессами.
Жизненный цикл – это модель создания и использования программной системы. Он отражает различные состояния программной системы, начиная с момента возникновения необходимости в этой программной системе и принятия решения о ее создании и заканчивая полным изъятием программной системы из эксплуатации.
Международный стандарт ISOIES 12207 регламентирует структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. По этому стандарту жизненный цикл программного обеспечения базируется на трех группах процессов:
основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;
вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;
организационные процессы, то есть управление проектами, создание инфраструктуры проекта и обучение.
Разработка включает в себя все работы по созданию программного обеспечения в соответствии с заданными требованиями. Сюда включаются оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и качества программных продуктов.
Основные этапы процесса разработки:
анализ требований заказчика;
Процесс эксплуатации включает в себя работы по внедрению программного обеспечения в эксплуатацию, в том числе конфигурирование рабочих мест, обучение персонала, локализация проблем эксплуатации и устранение причин их возникновения, модификация программного обеспечения в рамках установленного регламента и подготовка предложений по модернизации системы.
Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными и результатами.
Жизненный цикл программного обеспечения носит, как правило, итерационный характер, то есть реализуются этапы, начиная с самых ранних, которые циклически повторяются в соответствии с изменением требований внешних условий и введением ограничений.
Модели жизненного цикла программного обеспечения
Существует несколько моделей жизненного цикла, которые определяют порядок исполнения этапов разработки и критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили две модели жизненного цикла: каскадная и спиральная.
В существующих ранее однородных информационных системах каждое приложение представляло собой единое целое. Для разработки таких приложений применялась каскадная модель жизненного цикла, которую также называют классической или водопадной.
При использовании каскадной модели разработка рассматривалась как последовательность этапов, причем переход на следующий более низкий этап происходит только после того, как полностью завершены все работы на текущем этапе. Подразумевается, что в каскадной модели разработка начинается на системном уровне и происходит через анализ, проектирование, кодирование, тестирование и сопровождение.
Рисунок 1– Основные этапы разработки каскадной модели
1. Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку программное обеспечение рассматривается как часть большой системы, то анализ начинается с определения требований по всем системным элементам. Необходимость системного анализа явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами, т.е. с аппаратурой или базами данных. На этом же этапе начинается решение задач планирования проекта. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к отдельному программному элементу. На этом этапе уточняются и детализируются функции каждого элемента, его характеристики и интерфейс. На этом же этапе завершается решение задачи планирования проекта.
2. Проектирование состоит в создании:
архитектуры программного обеспечения;
модульной структуры программного обеспечения;
алгоритмической структуры программного обеспечения;
входного/выходного интерфейса (входных/выходных форм данных).
При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.
4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.
5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:
адаптации к изменениям внешней для программного обеспечения среды;
усовершенствование программного обеспечения в соответствии с требованиями заказчика.
Достоинства применения каскадной модели:
дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;
на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;
выполняемые в логической последовательности этапы работы позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадная модель хорошо себя зарекомендовала при построении информационных систем, для которых в самом начале разработки можно достаточно точно сформулировать все требования в системе, например, сложные расчетные системы, различные системы реального времени и т.д.
Недостатки каскадной модели:
реальные проекты часто требуют отклонений от стандартной последовательности шагов;
каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
результаты реализации проекта доступны заказчику только после завершения всех работ.
Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2).
Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели
Спиральная модель жизненного цикла
Спиральная модель является классическим примером эволюционной стратегии конструирования программного обеспечения.
Спиральная модель базируется на лучших свойствах каскадной модели жизненного цикла и макетирования, к которым добавляется анализ риска.
Спиральная модель включает четыре основных этапа, которые периодически повторяются:
планирование – это определение целей, вариантов и ограничений;
анализ риска – это анализ вариантов и распознавание риска;
конструирование – это разработка программного продукта следующего уровня;
оценивание – это оценка заказчика текущих результатов конструирования.
При движении по спирали строятся все более полные версии программного обеспечения при продвижении от центра к периферии. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, то на помощь заказчику и разработчику приходит макетирование. Заказчик оценивает инженерную или конструкторскую работу и вносит предложения по модификации.
Следующая фаза планирования и анализа риска базируется на предложении заказчика. Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. Количество действий по разработке возрастает по мере продвижения от центра спирали.
Рисунок 4 – Этапы спиральной модели
Достоинства спиральной модели:
наиболее реально отображает процесс разработки программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
использует моделирование для уменьшения риска и совершенствования программного продукта.
Недостатки спиральной модели:
повышенное требование к заказчику;
трудности контроля и управления временем разработки.
ВЗАИМОСВЯЗИ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО
Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (или в различных аспектах), который показан на рис. 1.2. Такими аспектами являются:
1) договорной аспект;
2) аспект управления;
3) аспект эксплуатации;
4) инженерный аспект;
5) аспект поддержки.
В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки.
Рис. 1.2. Связи между процессами жизненного цикла ПО
В аспекте управления заказчик, поставщик, разработчик, оператор, служба сопровождения и другие участвующие в ЖЦ ПО стороны управляют выполнением своих процессов. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя программные продукты. В аспекте поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПО, включающий пять процессов: обеспечение качества, верификация, аттестация, совместная оценка и аудит. Организационные процессы, показанные в нижней части рис. 1.2, выполняются на корпоративном уровне или на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования остальных процессов ЖЦ ПО.
Процессы и реализующие их организации (или стороны) связаны между собой чисто функционально, при этом внутренняя структура и статус организаций никак не регламентируются. Одна и та же организация может выполнять различные роли: поставщика, разработчика и другие, и наоборот, одна и та же роль может выполняться несколькими организациями.
Взаимосвязи между процессами, описанные в стандарте, носят статический характер. Более важные динамические связи между процессами и реализующими их сторонами устанавливаются в реальных проектах. Соотношение процессов ЖЦ ПО и стадий ЖЦ, характеризующих временной аспект ЖЦ системы, рассматривается в рамках модели ЖЦ ПО.
Значение данного стандарта трудно переоценить, поскольку он формирует подход к выбору и оценке всех современных технологий и процессов создания и сопровождения ПО. Безусловно, на выбор конкретной технологии в проекте влияет целый ряд факторов, но принципы реализации и состав процессов ЖЦ ПО остаются стабильными. Большинство технологий, поставляемых ведущими производителями (IBM, Oracle, Microsoft и др.), соответствуют требованиям этого стандарта. Анализ различных технологий показывает, что общие принципы описания процессов ЖЦ ПО в стандарте ISO 12207 прошли практическую апробацию и стали общепризнанными.
Таблица 1. Содержание основных процессов ЖЦ ПО АИС (ISO/IEC 12207):
Процесс (испол- нитель)
Приобретение (действия и задачи заказчика, приобретающего ИС)
Инициирование. Подготовка заявочных предложений. Подготовка договора. Контроль деятельности поставщика. Приемка ИС.
Решение о начале работ. Результаты обследования. Результаты анализа рынка ИС/ тендера. План поставки/ разработки. Комплексный тест.
Технико-экономическое обоснование внедрения. Техническое задание. Договор на поставку/ разработку. Акты приемки этапов работы. Акт приемно-сдаточных испытаний.
Поставка (поставщик снабжает заказчика прогр. продуктом или услугой)
Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка.
Техническое задание. Решение руководства об участии в разработке. План управления проектом. Разработанная ИС и документация.
Решение об участии в разработке. Коммерческие предложения/ конкурсная заявка. Договор на поставку/ разработку. План управления проектом. Реализация/ корректировка. Акт приемо-сдаточных испытаний.
Разра-ботка (разработчик создает ПО, оформляет проектную и эксплуатационную документацию, подготавливает тестовые и учебные материалы и др.)
Подготовка. Анализ требований ТЗ. Проектирование архитектуры. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование ИС.
Техническое задание на ИС. Модель ЖЦ. Подсистемы ИС. Спецификации требования к компонентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты.
Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам. Тексты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ.
В соответствии с ИСО 12207 основные процессы так же:
Эксплуатация (действия и задачи организации, эксплуатирующей систему).
Вспомогательные процессы жизненного цикла ИС:
Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)
Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями).
Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
Аудит (определение соответствия требованиям, планам и условиям договора)
Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
Организационные процессы жизненного цикла ИС:
Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
1. Инициирование приобретения.
2. Подготовка заявочных предложений.
3. Подготовка и корректировка договора.
4. Надзор за деятельностью поставщика.
5. Приемка и завершение работ.
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
1. Формирование требований к системе.
2. Формирование списка программных продуктов.
3. Установление условий и соглашений.
4. Описание технических ограничений (среда функционирования системы и т. д.).