чвпоьсчанрльчс акл. Жизненный цикл программного продукта
 Скачать 0.74 Mb.
|
|
1.1. Понятие жизненного цикла программного продукта Программный продукт (ПП) представляет собой набор компьютерных программ, процедур и связанной с ними документации и данных. Жизненный цикл программного продукта - это период времени, начинающийся с момента принятия решения о необходимости создания ПП и заканчивающийся в момент его полного изъятия из эксплуатации. Структуру жизненного цикла ПП, состав процессов, действия и задачи, которые должны быть выполнены во время создания ПП, определяет и регламентирует международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» Под процессом понимают совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными, полученными от других процессов, и результатами. Каждый процесс разделен на набор действий, каждое действие - на набор задач. Запуск и выполнение процесса, действия или задачи осуществляются другими процессами. 1.2. Основные процессы жизненного цикла программного продукта Основные процессы включают в себя набор определенных действий и связанных с ними задач, которые должны быть выполнены в течение жизненного цикла ПП. К основным относятся процессы приобретения, поставки, разработки, эксплуатации и сопровождения. Процесс приобретения (acquisition process) охватывает действия заказчика по приобретению ПП. К этим действиям относятся: инициирование приобретения; подготовка заявочных предложений; подготовка и корректировка договора; надзор за деятельностью поставщика; приемка и завершение работ. Инициирование приобретения включает в себя следующие задачи: определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, ПП или услуг; анализ требований к системе; принятие решения относительно приобретения, разработки или усовершенствования существующего ПП; проверку наличия необходимой документации, гарантий, сертификатов, лицензий и поддержки в случае приобретения ПП; подготовку и утверждение плана приобретения, включающего в себя требования к системе, тип договора, ответственность сторон и т.д. Процесс поставки (supply process) охватывает действия и задачи поставщика при снабжении заказчика ПП или услугой. К этим действиям относятся: инициирование поставки; подготовка ответа на заявочные предложения; подготовка договора; планирование; выполнение и контроль; проверка и оценка; поставка и завершение работ. Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения согласиться с выставленными требованиями и условиями или предложить свои. Процесс поставки (supply process) охватывает действия и зада- чи поставщика при снабжении заказчика ПП или услугой. К этим действиям относятся: инициирование поставки; подготовка ответа на заявочные предложения; подготовка договора; планирование; выполнение и контроль; проверка и оценка; поставка и завершение работ. Инициирование поставки заключается в рассмотрении поставщиком заявочных предложений и принятии решения согласиться с выставленными требованиями и условиями или предложить свои. Подготовка ответа на заявочные предложения выполняется в соответствии с принятыми решениями в результате инициирования поставки. Подготовка договора осуществляется после выбора заказчиком конкретного поставщика. Процесс разработки (development process) охватывает действия и задачи разработчика и предусматривает следующие основные направления работ: создание ПП и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и качества ПП; подготовку материалов, необходимых для организации обучения персонала, и т.д. Процесс эксплуатации (operation process) охватывает действия и задачи оператора - организации, занимающейся эксплуатацией разработанного ПП или системы. Процесс сопровождения (maintenance process) охватывает действия и задачи сопровождающей организации (службы сопровождения). Данный процесс активизируется при изменениях (модификациях) ПП и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации либо адаптации ПП. 1.3. Вспомогательные (поддерживающие) процессы жизненного цикла программного продукта Процесс документирования (documentation process) предусматривает формализованное описание информации, созданной в течение жизненного цикла ПП. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как руководство, технические специалисты и пользователи системы. Процесс верификации (verification process) состоит в доказательстве того, что ПП, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, зависящим от предшествующих действий. Верификация может проводиться самим исполнителем или другим специалистом данной организации, а также специалистом сторонней организации. Тут возможны различные вариации, в соответствии с которыми можно говорить о различной степени независимости верификации. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой верификации. Процесс совместной оценки (joint review process) предназначен для оценки состояния работ по проекту и ПП, создаваемому при выполнении данных работ. Он заключается в основном в контроле за планированием и управлением ресурсами, персоналом, аппаратурой и инструментальными средствами проекта. Процесс разрешения проблем (problem resolution process) предусматривает анализ и решение проблем (включая выявленные несоответствия), обнаруженных в ходе разработки, эксплуатации, сопровождения и других процессов, независимо от их происхождения или источника. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена. 1.4. Организационные процессы жизненного цикла программного продукта. Процесс управления (management process) состоит из действий и задач, которые могут выполняться любой стороной, управляющей своими процессами. Данная сторона (менеджер) отвечает за управление выпуском продукта, проектом и задачами соответствующих процессов, таких как приобретение, поставка, разработка, эксплуатация, сопровождение и др. Процесс создания инфраструктуры (infrastructure process) oxватывает выбор и поддержку (сопровождение) технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПП. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменения- ми требований к соответствующим процессам. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией. Процесс обучения (training process) охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Приобретение, поставка, разработка, эксплуатация и сопровождение программного продукта в значительной степени зависят от уровня знаний и квалификации персонала. Например, разработчики ПП должны пройти необходимое обучение методам и средствам программной инженерии. Содержание процесса обучения определяется требованиями к проекту. 1.5. Взаимосвязь между процессами жизненного цикла программного продукта. В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобрешения и поставки. В аспекте управления заказчик, поставщик, разработчик, оперотор, служба сопровождения и другие стороны, участвующие в жизненном цикле ПП, управляют выполнением своих процессов. Менеджер является связующим звеном между организационными и основными процессами. В аспекте эксплуатации оператор, эксплуатирующий систему, предоставляет необходимые услуги пользователям. В инженерном аспекте разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя ПП. В аспекте поддержки службы, реализующие вспомогательные процессы, предоставляют необходимые услуги всем остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПП.  2.2. Характеристика основных этапов Планирование программного проекта. В течение этапа планирования определяются все основные задачи, которые должны быть выполнены в процессе разработки, производится оценка финансовых, людских, технических и нетехнических ресурсов, объемов и сложности разрабатываемого ПП, определяются методы тестирования и критерии приемки ПП, методы и технология выполнения работы, строятся временные графики выполнения работ. Составление требований заказчика. В течение этого этапа разработчики анализируют требования к ПП (форма представления информации, необходимые функции, желательные интерфейсы, существующие ограничения и т.д.). Разработка программного продукта. В процессе выполнения этого этапа разработчики преобразуют результаты этапа проектирования в коды программ на используемом языке программирования в соответствии со стандартами кодирования. Разработчики также взаимодействуют с инженером по тестированию ПП для создания надлежащих условий для тестирования. Кроме этого, разработчики ведут работу по созданию технической документации и начинают планировать и выполнять интеграцию ПП. Тестирование программного продукта. Этап тестирования не имеет четко определенного начала, но чем раньше он начинается, тем больше уверенности, что разрабатываемый ПП будет точно соответствовать требованиям заказчика. Все действия по тестированию должны выполняться специальным работником - тестировщиком. Он разрабатывает тесты, выполняет процедуру тестирования и составляет отчеты о результатах тестирования. Сопровождение программного продукта. На этапе сопровождения основное внимание уделяется внесению изменений в ПП. Эти изменения могут быть связаны с устранением ошибок, дополнительными пожеланиями заказчика, появившимися в результате работы c ПП, изменением среды окружения и функционирования. 3.1. Понятие модели жизненного цикла разработки программного продукта. Обзор существующих моделей Под моделью жизненного цикла разработки ПП понимается структура, определяющая последовательность выполнения и в взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки ПП. Модель жизненного цикла зависит от специфики и сложности выполняемого проекта, а также от условий, в которых создается и будет функционировать ПП.  3.2. Каскадная модель. Принципиальная особенность каскадного подхода: переход на следующий этап осуществляется только после того, как будет полностью завершена работа на текущем этапе, и возвратов на пройденные этапы не предусматривается. Каждый этап заканчивается получением некоторых результатов, которые служат исходными данными для следующего этапа. Требования к разрабатываемому ПП, определенные на этапе формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций технического задания. При этом основное внимание разработчиков сосредотачивается на достижении оптимальных значений технических характеристик разрабатываемого ПП - производительности, объема занимаемой памяти и др.   3.3. V-образная модель Эта модель была разработана как разновидность каскадной модели, в которой особое внимание уделяется верификации и аттестации ПП. Модель показывает, что тестирование продукта обсуждается, проектируется и планируется, начиная с ранних этапов жизненного цикла разработки От каскадной модели V-образная модель унаследовала последовательную структуру, в соответствии с которой каждая последующая фаза начинается только после успешного завершения предыдущей фазы. Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и детальное (низкоуровневое). Разработка включает в себя кодирование, а обзор - различные виды тестирования.  Модель включает в себя следующие фазы: составление требований к проекту и планирование - определяются системные требования и выполняется планирование работ; составление требований к продукту и их анализ – составляется полная спецификация требований к программному продукту; высокоуровневое проектирование - определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции; детальное проектирование - определяется алгоритм работы каждого компонента; кодирование - выполняется преобразование алгоритмов в готовое программное обеспечение; модульное тестирование - выполняется проверка каждого компонента или модуля ПП;интеграционное тестирование - осуществляются интеграция ПП и его тестирование; системное тестирование - выполняется проверка функционирования ПП после помещения его в аппаратную среду в соответствии со спецификацией требований; эксплуатация и сопровождение - запуск ПП в производство. На этой фазе в ПП могут вноситься поправки и может выполняться его модернизация. Преимущества V-образной модели: большая роль придается верификации и аттестации ПП, начиная с ранних стадий его разработки, все действия планируются; предполагаются аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных; ход выполнения работы может легко отслеживаться, так как завершение каждой фазы является контрольной точкой. 3.7. Спиральная модель Для преодоления проблем, связанных с использованием многопроходной модели, в середине 1980-х годов была предложена спиральная модель жизненного цикла. Ее принципиальная особенность заключается в том, что прикладной ПП создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПП. Создание прототипов осуществляется за несколько итераций, или витко спирали. Каждая итерация соответствует созданию фрагмента, или версии ПП, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта с целью определения необходимости выполнения еще одной итерации, степени полноты и точности понимания требований к системе, а также целесообразности прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПП от полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы, позволяя переходить на следующую стадию, не дожидаясь полного завершения работы на текущей стадии, поскольку при итеративном способе разработки недостающую работу можно выполнить на следующей итерации. Главная задача такой разработки - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.  |